DVP - Documento de Visão do Produto (MODELO)

O Documento de Visão do Produto, em geral, fornece uma base de alto nível para os requisitos técnicos mais detalhados, definindo a visão que os envolvidos têm do produto a ser desenvolvido, em termos das necessidades e características mais importantes.

2.1. Perspectiva do Negócio

[Detalhar o que é o negócio e como ele é executado, isto é, o cenário atual do negócio a ser apoiado pelo produto. Sugere-se estruturar as informações em forma de texto dissertativo, apresentando os macroprocessos que envolvem o negócio. Não se deve, neste momento, entrar no mérito das funcionalidades esperadas pelo produto, tampouco no detalhamento dos problemas e necessidades a serem apoiados por ele.]

2.2. Motivações, Necessidades e Problemas

[A partir do cenário apresentado acima, identificar as possíveis motivações, necessidades e problemas decorrentes. Não se deve, neste momento, entrar no mérito das funcionalidades esperadas pelo produto, apenas nos pontos que, possivelmente, ele deve apoiar. Sugere-se estruturar as informações em tópicos sucintos.]

3. Visão Geral do Produto
3.1. Perspectiva do Produto

[Apresentar o que é o produto me como ele apoiará o negócio, isto é, quais soluções ele objetiva apresentar para resolver ou mitigar as necessidades e problemas do negócio. Especificar, também, a relação que o produto tem com outro produtos e o ambiente do usuário. Sugere-se estruturar as informações em forma de texto dissertativo, apresentando os processos de negócio que o produto pretende apoiar.]

3.2. Oportunidades de Negócio

[Tendo em vista as soluções propostas pelo produto, considere as oportunidades e benefícios que possam advirem dos desdobramentos da sua implantação. Ou seja, além das motivações originais, outros benefícios colaterais que possam vir a ser obtidos a posteriori e que representem ganhos adicionais para a sua execução. Sugere-se estruturar as informações em tópicos sucintos.]

4. Requisitos Funcionais do Produto
4.1. Estórias do usuário

[Listar as Estórias solicitadas por seus requisitantes e classifica-las em temas. Estórias representam as necessidades dos clientes do produto. Os temas agrupam estórias com finalidades comuns, facilitando seu manuseio. As estórias devem possuir identificadores únicos e serem escritas no formato COMO x QUERO y PARA z, onde x, y e z indicam, respectivamente, quem desempenhará a funcionalidade, o que é a sua funcionalidade e sua finalidade. Esta seção deve ser constantemente atualizada ao longo do projeto de desenvolvimento do produto, representando as inclusões e mudanças de requisitos dos clientes, bem como alterações em sua priorização. Para cada estória aqui descrita um Documento de Estória de Usuário deverá ser criado com vistas a detalhar melhor a estória.]

IDEstória do usuárioTemaPrioridade
5. Requisitos Não-Funcionais do Produto
5.1. Requisitos Legais e de Padrões

[Liste os dispositivos legais e padrões com os quais o produto deverá estar em conformidade. Entre os padrões, poderão estar incluídos padrões de comunicações, padrões de qualidade, padrões de segurança, etc.]

5.2. Requisitos de Sistema e de Infraestrutura

[Defina os requisitos de sistema e de infraestrutura necessários para o desenvolvimento, suporte e uso do produto. Pode abranger software, hardware, redes, telecomunicações, infraestrutura física quando aplicável, dentre outras. Requisitos associados a linguagens de programação e tecnologias a serem utilizadas também devem ser abordadas nesta subseção.]

5.3. Requisitos de Desempenho

[Descreva os requisitos de desempenho esperados para o produto. Itens referente a carga do usuário, largura da banda, taxa de transferência e tempos de resposta podem ser bordados nesta subseção. É necessário que sejam descritos em termos quantitativos, baseados em uma ou mais unidades de medida escolhidas.]

5.4. Requisitos de Usabilidade e Acessibilidade

[Informe os requisitos referentes à usabilidade e acessibilidade do produto, isto é, aquilo que é associado a sua facilidade de uso, apreensibilidade, possibilidades e modos de acesso/operação. Requisitos de usabilidade geralmente precisam ser escritos em termos quantitativos, baseados em uma ou mais unidades de medida escolhidas.]

5.5. Requisitos de Confiabilidade

[Escreva os requisitos de confiabilidade acordados com o cliente. Devem ser incluídos nesta subseção requisitos que tratem sobre possibilidade de recuperação, tempo médio entre falhas, frequência e gravidade de falhas, dentre outros. Estes requisitos de usabilidade geralmente precisam ser escritos em termos quantitativos, baseados em uma ou mais unidades de medida escolhidas.]

5.6. Requisitos de Segurança

[Informe os requisitos de segurança do produto, referentes a aspectos como: integridade, confidencialidade, autenticidade, disponibilidade e não repúdio. Portanto, questões relacionadas a criptografia de dados e autenticação devem ser abordadas aqui..]

6. Arquitetura do produto
6.1. Descrição da arquitetura

[A arquitetura define a estrutura de produto de software, que compreende os componentes com suas propriedades visíveis externamente e os relacionamentos entre eles. Uma descrição sucinta dela deve ser apresentada aqui. Decisões tais como se o sistema será cliente-servidor, distribuído, orientado a serviços, baseado em plug-ins ou em camadas devem ser apresentadas. A arquitetura está intrinsecamente associada a requisitos não-funcionais como desempenho, confiabilidade, segurança, etc.]

7. Aprovações
Interessadoe-mailRamalResponsabilidade