<Nome do Projeto>

Visão

Versão <1.0>

[Nota: O gabarito a seguir é fornecido para utilização com o Rational Unified Process. O texto em azul exibido entre colchetes e em itálico (style=InfoBlue) foi incluído para orientar o autor e deve ser excluído antes da publicação do documento. Um parágrafo digitado após esse estilo será automaticamente definido como normal (style=Body Text).]

[Para personalizar campos automáticos no Microsoft Word (que exibem um segundo plano cinza quando selecionados), selecione File>Properties e substitua os campos Title, Subject e Company pelas informações apropriadas para este documento. Depois de fechar o diálogo, os campos automáticos podem ser atualizados no documento inteiro, selecionando Edit>Select All (ou Ctrl-A) e pressionando F9 ou simplesmente clique no campo e pressione F9. Esse procedimento deverá ser executado separadamente para os Cabeçalhos e Rodapés. Alt-F9 alterna entre a exibição de nomes de campos e do conteúdo dos campos. Consulte a Ajuda do Word para obter informações adicionais sobre como trabalhar com campos.]

Histórico da Revisão

Data	Versão	Descrição	Autor
<dd/mmm/aa>	<x.x>	<detalhes>	<nome>

Índice

1.	Introdução	5

1.1	Objetivo	5

1.2	Escopo	5

1.3	Definições, Acrônimos e Abreviações	5

1.4	Referências	5

1.5	Visão Geral	5

2.	Posicionamento	5

2.1	Oportunidade de Negócio	5

2.2	Declaração do Problema	5

2.3	Declaração da Posição do Produto	5

3.	Descrições do Investidor e do Usuário	6

3.1	Demográficos de Mercado	6

3.2	Resumo do Investidor	6

3.3	Resumo de Usuários	7

3.4	Ambiente do Usuário	7

3.5	Perfis do Investidor	7

3.5.1	<Nome do Investidor>	7

3.6	Perfis de Usuários	8

3.6.1	<Nome do Usuário>	8

3.7	Necessidades Principais do Investidor ou Usuário	8

3.8	Alternativas e Competição	9

3.8.1	<aCompetitor>	9

3.8.2	<anotherCompetitor>	9

4.	Visão Geral do Produto	9

4.1	Perspectiva do Produto	9

4.2	Resumo de Recursos	9

4.3	Premissas e Dependências	10

4.4	Custo e Preço	10

4.5	Licença e Instalação	10

5.	Recursos do Produto	10

5.1	<aFeature>	11

5.2	<anotherFeature>	11

6.	Restrições	11

7.	Intervalos de Qualidade	11

8.	Precedência e Prioridade	11

9.	Outros Requisitos de Produto	11

9.1	Padrões Aplicáveis	11

9.2	Requisitos do Sistema	11

9.3	Requisitos de Desempenho	11

9.4	Requisitos Ambientais	12

10.	Requisitos de Documentação	12

10.1	Manual do Usuário	12

10.2	Ajuda On-line	12

10.3	Guias de Instalação, Configuração e Arquivo LEIA-ME	12

10.4	Etiquetagem e Empacotamento	12

A Atributos de Recursos	12

A.1	Status	12

A.2	Benefício	13

A.3	Esforço	13

A.4	Risco	13

A.5	Estabilidade	14

A.6	Release de Destino	14

A.7	Designado Para	14

A.8	Motivo	14

Visão

Introdução

[O objetivo deste documento é coletar, analisar e definir necessidades e recursos de alto nível do <<Nome do Sistema>>. Ele está focalizado nos recursos necessários aos investidores e usuários de destino e por que essas necessidades existem. Os detalhes de como o <<Nome do Sistema>> atende essas necessidades são explicados nas especificações de caso de uso e suplementares.]

[A introdução do documento Visão fornece uma visão geral de todo o documento. Ela inclui o objetivo, o escopo, as definições, os acrônimos, as abreviações, as referências e a visão geral deste documento Visão.]

Objetivo

[Especifique o objetivo deste documento Visão.]

Escopo

[Uma breve descrição do escopo deste documento Visão; a qual(is) Projeto(s) ele está associado e tudo mais que seja afetado ou influenciado por este documento.]

Definições, Acrônimos e Abreviações

[Esta subseção fornece as definições de todos os termos, acrônimos e abreviações requeridos para interpretar adequadamente o documento Visão. Essas informações podem ser fornecidas em relação ao Glossário do projeto.]

Referências

[Esta subseção fornece uma lista completa de todos os documentos mencionados em outra parte no documento Visão. Identifique cada documento por título, número do relatório se aplicável, data e organização da publicação. Especifique as origens a partir das quais as referências podem ser obtidas. Essas informações podem ser fornecidas por um anexo ou outro documento.]

Visão Geral

[Esta subseção descreve o que o restante do documento Visão contém e explica como o documento é organizado.]

Posicionamento

Oportunidade de Negócio

[Descreva resumidamente a oportunidade de negócio que está sendo atendida por este projeto.]

Declaração do Problema

[Forneça uma declaração resumindo o problema que está sendo resolvido por este projeto. O formato a seguir pode ser utilizado:]

O problema de	[descreva o problema]
afeta	[os investidores afetados pelo problema]
o impacto é o seguinte	[qual é o impacto do problema?]
uma solução bem-sucedida seria	[liste alguns benefícios chave de uma solução bem-sucedida]
Declaração da Posição do Produto

[Forneça uma declaração geral resumindo, no nível mais alto, a posição exclusiva que o produto pretende ocupar no marketplace. O formato a seguir pode ser utilizado:]

Para	[cliente de destino]
Quem	[declaração da necessidade ou oportunidade]
O (nome do produto)	é um [categoria do produto]
Que	[declaração do benefício chave, isto é, o motivo que leva a comprar]
Diferente	[principal alternativa competitiva]
Nosso produto	[declaração da diferenciação principal]
[Uma declaração da posição do produto comunica a intenção do aplicativo e a importância do projeto para todo o pessoal interessado.]

Descrições do Investidor e do Usuário

[Para fornecer produtos e serviços que efetivamente atendam as necessidades reais de seus investidores e usuários, é necessário identificar e envolver todos os investidores como parte do processo de Modelagem de Requisitos. Você deve também identificar os usuários do sistema e garantir que a comunidade de investidores os represente adequadamente. Esta seção fornece um perfil dos investidores e usuários envolvidos no projeto e os problemas chave que eles observam para que sejam tratados pela solução proposta. Não descreve os pedidos ou requisitos específicos uma vez que estes são capturados em um artefato separado de pedidos do investidor. Em vez disso, fornece o segundo plano e a justificativa de por que os requisitos são necessários.]

Demográficos de Mercado

[Resuma os demográficos chave de mercado que motivam as decisões do produto. Descreva e posicione os segmentos de mercado de destino. Faça uma estimativa do tamanho e do crescimento do mercado utilizando o número de usuários potenciais ou o valor em dinheiro que seus clientes gastam tentando atender as necessidades que seu produto ou aprimoramento poderia suprir. Reveja as principais tendências e tecnologias do segmento de mercado. Responda estas perguntas estratégicas:

•	Qual é a reputação da sua organização nesses mercados?

•	Qual você gostaria que fosse?

•	Como este produto ou serviço suporta suas metas?]

Resumo do Investidor

[Há vários investidores com interesse no desenvolvimento e nem todos eles são usuários finais. Apresente uma lista de resumo desses investidores não-usuários. (Os usuários estão resumidos na seção 3.3.)]

Nome	Descrição	Responsabilidades
[Nomeie o tipo do investidor.]	[Descreva resumidamente o investidor.]	[Resuma as principais responsabilidades do investidor com relação ao sistema que está sendo desenvolvido, isto é, seu interesse como um investidor. Por exemplo, este investidor:

garante que será possível manter o sistema

garante que haverá uma demanda de mercado para os recursos do produto

monitora o andamento do projeto

aprova o fundo

e assim por diante]
Resumo de Usuários

[Apresente uma lista de resumo de todos os usuários identificados.]

Nome	Descrição	Responsabilidades	Investidor
[Nomeie o tipo de usuário.]	[Descreva resumidamente o que representam com relação ao sistema.]	[Liste as principais responsabilidades do usuário com relação ao sistema que está sendo desenvolvido, por exemplo:

captura detalhes

produz relatórios

coordena o trabalho

e assim por diante]	[Se o usuário não for diretamente representado, identifique qual investidor é responsável por representar o interesse do usuário.]

Ambiente do Usuário

[Detalhe o ambiente de trabalho do usuário de destino. A seguir, são apresentadas algumas sugestões:

Número de pessoas envolvidas na conclusão da tarefa? Isso está mudando?

Qual é a duração de um ciclo de tarefa? Período de tempo gasto em cada atividade? Isso está mudando?

Alguma restrição ambiental exclusiva: móvel, ao ar livre, em vôo e assim por diante?

Quais plataformas de sistemas estão em uso hoje? Plataformas futuras?

Que outros aplicativos estão em uso? Seu aplicativo precisa se integrar a eles?

Aqui é onde as extrações do Modelo de Negócio podem ser incluídas para esboçar a tarefa e as funções envolvidas e assim por diante.]

Perfis do Investidor

[Descreva cada investidor no sistema aqui preenchendo a seguinte tabela para cada investidor. Lembre-se de que os tipos de investidor podem ser tão diferentes quanto usuários, departamentos e desenvolvedores técnicos. Um perfil completo cobriria os seguintes tópicos para cada tipo de investidor.]

<Nome do Investidor>

Representante	[Quem é o representante do investidor para o projeto? (Opcional se documentado em outro lugar.) O que queremos aqui são nomes.]
Descrição	[Uma breve descrição do tipo de investidor.]
Tipo	[Qualifique o conhecimento do investidor, o background técnico e o grau de sofisticação—isto é, guru, negócios, especialista, usuário casual e assim por diante.]
Responsabilidades	[Liste as principais responsabilidades do investidor com relação ao sistema que está sendo desenvolvido—isto é, seu interesse como investidor.]
Critérios de Êxito	[Como o investidor define o êxito?

Como o investidor é recompensado?]
Envolvimento	[Como o investidor está envolvido no projeto? Relacione, onde possível, com funções do Rational Unified Process—isto é, Revisor de Requisitos e assim por diante.]
Distribuíveis	[Há algum distribuível adicional requerido pelo investidor? Podem ser distribuíveis ou saídas do projeto do sistema em desenvolvimento.]
Comentários / Problemas	[Problemas que interferem no êxito e qualquer outra informação relevante devem ser colocados aqui.]

Perfis de Usuários

[Descreva cada usuário exclusivo do sistema aqui preenchendo a seguinte tabela para cada tipo de usuário. Lembre-se de que os tipos de usuários podem ser tão diferentes quanto gurus e aprendizes. Por exemplo, um guru pode precisar de uma ferramenta sofisticada, flexível com suporte de plataforma cruzada enquanto que um aprendiz pode precisar de uma ferramenta fácil de utilizar e simples. Um perfil completo deve cobrir os seguintes tópicos para cada tipo de usuário.]

<Nome do Usuário>

Representante	[Quem é o representante do usuário para o projeto? (Opcional se documentado em outro lugar.) Isso, freqüentemente, refere-se ao Investidor que representa o conjunto de usuários, por exemplo, Investidor: Investidor1.]
Descrição	[Uma breve descrição do tipo de usuário.]
Tipo	[Qualifique o conhecimento do usuário, o background técnico e o grau de sofisticação—isto é, guru, usuário casual e assim por diante.]
Responsabilidades	[Liste as principais responsabilidades do usuário com relação ao sistema que está sendo desenvolvido— isto é, captura detalhes, produz relatórios, coordena o trabalho e assim por diante.]
Critérios de Êxito	[Como o usuário define o êxito?

Como o usuário é recompensado?]
Envolvimento	[Como o usuário está envolvido no projeto? Relacione, onde possível, com funções do Rational Unified Process—isto é, Revisor de Requisitos e assim por diante.]
Distribuíveis	[Há algum distribuível que o usuário produz e, se houver, para quem?]
Comentários / Problemas	[Problemas que interferem no êxito e qualquer outra informação relevante devem ser colocados aqui. Esses incluiriam tendências que tornam o trabalho do usuário mais fácil ou mais difícil.]

Necessidades Principais do Investidor ou Usuário

[Liste os problemas chave com soluções existentes conforme observado pelo investidor ou usuário. Explique as seguintes questões para cada problema:

•	Quais são os motivos para este problema?

•	Como ele é resolvido agora?

•	Quais soluções o investidor ou o usuário deseja?]

[É importante entender a importância relativa que o investidor ou o usuário coloca em resolver cada problema. Técnicas de classificação e votação acumulativa indicam problemas que devem ser resolvidos contra problemas que eles gostariam que fossem tratados.

Preencha a tabela a seguir—se estiver utilizando o Rational RequisitePro para capturar as Necessidades, isso poderia ser uma extração ou relatório dessa ferramenta.]

Necessidade	Prioridade	Assuntos	Solução Atual	Soluções Propostas
Mensagens de difusão

Alternativas e Competição

[Identifique alternativas que o investidor observa como disponíveis. Estas podem incluir comprar o produto de um concorrente, construir uma solução própria ou simplesmente manter o status quo. Liste todas as opções competitivas conhecidas que existem ou que podem se tornar disponíveis. Inclua os principais pontos fortes e fracos de cada concorrente conforme observado pelo investidor ou usuário final.]

<aCompetitor>

<anotherCompetitor>

Visão Geral do Produto

[Esta seção fornece uma visualização de alto nível dos recursos do produto, interfaces com outros aplicativos e configurações do sistema. Esta seção, geralmente, consiste em três subseções, como segue:

•	Perspectiva do produto

•	Funções do produto

•	Premissas e dependências]

Perspectiva do Produto

[Esta subseção do documento Visão coloca o produto em perspectiva com outros produtos relacionados e o ambiente do usuário. Se o produto for totalmente independente, declare isso aqui. Se o produto for um componente de um sistema maior, esta subseção deverá relatar como esses sistemas interagem e deverá identificar as interfaces relevantes entre os sistemas. Uma maneira fácil de exibir os principais componentes do sistema maior, interconexões e interfaces externas é com um diagrama de bloco.]

Resumo de Recursos

[Resuma os principais benefícios e recursos que o produto fornecerá. Por exemplo, um documento Visão para um sistema de suporte ao cliente pode utilizar esta parte para tratar da documentação, da rota e do relatório de status do problema sem mencionar a quantidade de detalhes que cada uma dessas funções requer.

Organize as funções de modo que a lista seja compreensível para o cliente e para qualquer outra pessoa que esteja lendo o documento pela primeira vez. Uma tabela simples listando os principais benefícios e seus recursos de suporte pode ser suficiente. Por exemplo:]

Tabela 4-1 Sistema de Suporte ao Cliente

Benefício do Cliente	Recursos de Suporte
A nova equipe de suporte pode rapidamente alcançar velocidade.	A base de conhecimento ajuda o pessoal de suporte a identificar rapidamente correções conhecidas e soluções alternativas.
A satisfação do cliente é aprimorada porque nada é deixado para trás.	Os problemas são exclusivamente relacionados por itens, classificados e rastreados em todo o processo de resolução. A notificação automática ocorre para problemas de qualquer período.
O gerenciamento pode identificar áreas de problemas e determinar a carga de trabalho da equipe.	Os relatórios de tendência e distribuição permitem uma revisão de alto nível do status do problema.
As equipes de suporte distribuídas podem trabalhar juntas para resolver problemas.	O servidor de replicação permite que informações do banco de dados atual sejam compartilhadas na empresa.
Os clientes podem se ajudar, baixando os custos do suporte e aprimorando o tempo de resposta.	A base de conhecimento pode ser disponibilizada através da Internet. Inclui recursos de pesquisa de hipertexto e mecanismo de consulta gráfica.
Premissas e Dependências

[Liste cada um dos fatores que afetam os recursos declarados no documento Visão. Liste premissas que, se alteradas, mudarão o documento Visão. Por exemplo, uma premissa pode declarar que um sistema operacional específico estará disponível para o hardware designado para o produto de software. Se o sistema operacional não estiver disponível, o documento Visão precisará ser alterado.]

Custo e Preço

[Para produtos vendidos para clientes externos e para muitos aplicativos internos, os problemas de custo e preço podem impactar diretamente a definição e a implementação do aplicativo. Nesta seção, registre quaisquer restrições de custo e preço que sejam relevantes. Por exemplo, custos de distribuição, (# de disquetes, # de CD-ROMs, controle do CD) ou outras restrições de custo de mercadorias vendidas (manuais, pacote) podem ser materiais para o êxito dos projetos ou irrelevantes, dependendo da natureza do aplicativo.]

Licença e Instalação

[Os problemas de licença e instalação também podem impactar diretamente o esforço de desenvolvimento. Por exemplo, a necessidade de suportar serialização, segurança de senha ou licença de rede criará requisitos adicionais do sistema que devem ser considerados no esforço de desenvolvimento.

Os requisitos de instalação também podem afetar a codificação ou criar a necessidade de um software de instalação separado.]

Recursos do Produto

[Liste e descreva resumidamente os recursos do produto. Recursos são as capacidades de alto nível do sistema que são necessárias para fornecer benefícios aos usuários. Cada recurso é um serviço desejado externamente que, geralmente, requer uma série de entradas para alcançar o resultado desejado. Por exemplo, um recurso de um sistema de rastreamento de problema pode ser a habilidade de fornecer relatórios de tendências. Conforme o modelo de caso de uso toma forma, atualize a descrição para se referir aos casos de uso.

Como o documento Visão é revisado por uma ampla variedade de pessoas envolvidas, o nível de detalhes deve ser geral o suficiente para que todos entendam. Porém, detalhes suficientes devem estar disponíveis para fornecer à equipe as informações necessárias para criar um modelo de caso de uso.

Para gerenciar efetivamente a complexidade do aplicativo, recomenda-se para todo novo sistema, ou um incremento a um sistema existente, recursos abstraídos a um nível alto o suficiente que resultem 25-99 recursos. Estes recursos fornecem a base fundamental para definição do produto, gerenciamento de escopo e gerenciamento de projeto. Cada recurso será expandido em maiores detalhes no modelo de caso de uso.

Em toda esta seção, cada recurso será externamente observável por usuários, operadores ou outros sistemas externos. Estes recursos devem incluir uma descrição de funcionalidade e problemas de utilidade relevantes que devem ser tratados. As seguintes diretrizes se aplicam:

•	Evite o design. Mantenha as descrições do recurso em um nível geral. Focalize nos recursos necessários e por que (não como)	eles devem ser implementados.

•	Se você estiver utilizando o toolkit Rational RequisitePro, tudo deverá ser selecionado como requisitos de tipo para fácil referência e rastreamento.]

<aFeature>

<anotherFeature>

Restrições

[Observe as restrições de design, restrições externas ou outras dependências.]

Intervalos de Qualidade

[Defina os intervalos de qualidade quanto ao desempenho, força, tolerância a falhas, utilidade e características semelhantes que não são capturadas no Conjunto de Recursos.]

Precedência e Prioridade

[Defina a prioridade dos diferentes recursos do sistema.]

Outros Requisitos de Produto

[Em um nível alto, liste padrões aplicáveis, requisitos de hardware ou plataforma, requisitos de desempenho e requisitos ambientais.]

Padrões Aplicáveis

[Liste todos os padrões com os quais o produto deve estar em conformidade. Estes podem incluir padrões de comunicações legais e reguladores (FDA, UCC) (TCP/IP, ISDN), padrões de conformidade com a plataforma (Windows, UNIX e assim por diante) e padrões de qualidade e segurança (UL, ISO, CMM).]

Requisitos do Sistema

[Defina os requisitos do sistema necessários para suportar o aplicativo. Estes podem incluir os sistemas operacionais de host suportados e plataformas de rede, configurações, memória, periféricos e software associado.]

Requisitos de Desempenho

[Utilize esta seção para detalhar os requisitos de desempenho. Os problemas de desempenho podem incluir itens como fatores de carregamento de usuário, capacidade de largura de banda ou comunicação, rendimento do processamento, exatidão e confiabilidade ou tempos de resposta sob uma variedade de condições de carregamento.]

Requisitos Ambientais

[Detalhe os requisitos ambientais conforme necessário. Para sistemas baseados em hardware, os problemas ambientais podem incluir temperatura, choque, umidade, radiação e assim por diante. Para aplicativos de software, os fatores ambientais podem incluir condições de uso, ambiente do usuário, disponibilidade de recursos, problemas de manutenção e manipulação e recuperação de erros.]

Requisitos de Documentação

[Esta seção descreve a documentação que deve ser desenvolvida para suportar a implementação do aplicativo bem-sucedida.]

Manual do Usuário

[Descreva o objetivo e o conteúdo do Manual do Usuário. Discuta a extensão desejada, o nível de detalhes, a necessidade do índice, o glossário de termos, o tutorial contra a estratégia manual de referência e assim por diante. As restrições de formatação e de impressão também devem ser identificadas.]

Ajuda On-line

[Muitos aplicativos fornecem um sistema de ajuda on-line para auxiliar o usuário. A natureza desses sistemas é exclusiva para o desenvolvimento do aplicativo uma vez que eles combinam aspectos de programação (hyperlinks e assim por diante) com aspectos de gravação técnica, como organização e apresentação. Muitos descobriram que o desenvolvimento de um sistema de ajuda on-line é um projeto dentro de um projeto que se beneficia do gerenciamento de escopo up-front e da atividade de planejamento.]

Guias de Instalação, Configuração e Arquivo LEIA-ME

[Um documento que inclui instruções de instalação e orientações de configuração é importante para uma oferta de solução completa. Além disso, um arquivo LEIA-ME é, geralmente, incluído como um componente padrão. O arquivo LEIA-ME pode incluir uma seção "O Que Há de Novo com este Release” e uma discussão dos problemas de compatibilidade com releases anteriores. A maioria dos usuários também gosta da documentação que define os erros conhecidos e soluções alternativas no arquivo LEIA-ME.]

Etiquetagem e Empacotamento

[Os aplicativos atualizados fornecem uma aparência e comportamento consistentes que começam com o empacotamento do produto e se manifesta nos menus de instalação, telas iniciais, sistemas de ajuda, diálogos de GUI e assim por diante. Esta seção define as necessidades e os tipos de etiquetagem a serem incorporados no código. Exemplos incluem observações sobre direitos autorais e patentes, logotipos corporativos, ícones padronizados e outros elementos gráficos e assim por diante.]

A Atributos de Recursos

[Os recursos recebem atributos que podem ser utilizados para avaliar, rastrear, priorizar e gerenciar os itens de produtos propostos para implementação. Todos os tipos e atributos de requisitos devem ser esboçados no Plano de Gerenciamento de Requisitos; porém, você pode listar e descrever resumidamente os atributos para os recursos escolhidos. As subseções a seguir representam um conjunto de atributos de recursos sugeridos.]

A.1	Status

[Defina após a negociação e a revisão pela equipe de gerenciamento do projeto. Controla o andamento durante a definição da linha de base do projeto.]

Propostos	[Utilizado para descrever recursos que estão em discussão, mas que ainda não foram revisados e aceitos pelo "canal oficial", como um grupo de trabalho que consiste em representantes da equipe do projeto, gerenciamento de produtos e comunidade de usuários ou clientes.]
Aprovados	[Recursos que foram julgados úteis e possíveis e que foram aprovados para implementação pelo canal oficial.]
Incorporado	[Recursos incorporados na linha de base do produto em um momento específico.]
A.2	Benefício

[Definido pelo Marketing, o gerente de produto ou o analista de negócio. Todos os requisitos não são criados iguais. Classificar requisitos por seu benefício relativo para o usuário final abre um diálogo com clientes, analistas e membros da equipe de desenvolvimento. Utilizado no gerenciamento do escopo e na determinação da prioridade de desenvolvimento.]

Crítico	[Recursos essenciais. Falha na implementação significa que o sistema não atenderá as necessidades do cliente. Todos os recursos críticos devem ser implementados no release ou o planejamento falhará.]
Importante	[Recursos importantes para a eficiência e a eficácia do sistema para a maioria dos aplicativos. A funcionalidade não pode ser facilmente fornecida de outra maneira. A falta de inclusão de um recurso importante pode afetar a satisfação do cliente ou do usuário ou mesmo a receita, mas o release não será atrasado por causa da falta de nenhum recurso importante.]
Útil	[Recursos que são úteis em aplicativos menos típicos serão utilizados com menor freqüência ou para os quais soluções alternativas razoavelmente eficientes podem ser alcançadas. Nenhum impacto significativo de receita ou de satisfação do cliente poderá ser esperado se tal item não for incluído em um release.]

A.3	Esforço

[Definido pela equipe de desenvolvimento. Como mais recursos requerem mais tempo e recursos do que outros, estimar o número de semanas por equipe ou pessoa, linhas de código requeridas ou pontos de função, por exemplo, é a melhor maneira de calcular complexidade e definir expectativas do que pode e não pode ser realizado em um determinado quadro de tempo. Utilizado no gerenciamento do escopo e na determinação da prioridade de desenvolvimento.]

A.4	Risco

[Definido pela equipe de desenvolvimento com base na probabilidade de que o projeto experimentará eventos indesejáveis, como overruns de custo, atrasos no planejamento ou até mesmo cancelamentos. A maioria dos gerentes de projeto acha que categorizar os riscos como alto, médio e baixo é o suficiente, embora graduações mais refinadas sejam possíveis. O risco pode freqüentemente ser avaliado indiretamente medindo a variabilidade (intervalo) da estimativa de planejamento da equipe de projetos.]

A.5	Estabilidade

[Definida pelo analista e pela equipe de desenvolvimento, baseia-se na probabilidade de que os recursos serão alterados ou o entendimento da equipe sobre o recurso será alterado. Usado para ajudar a estabelecer as prioridades de desenvolvimento e a determinar os itens que deverão ser extraídos.]

A.6	Release de Destino

[Registra a versão do produto pretendida na qual o recurso aparecerá primeiro. Este campo pode ser utilizado para alocar recursos de um documento Visão em um release de linha de base particular. Quando combinado com o campo de status, sua equipe pode propor, registrar e discutir vários recursos do release sem confirmá-los para o desenvolvimento. Apenas os recursos cujo Status é definido como Incorporado e cujo Release de Destino é definido serão implementados. Quando ocorre o gerenciamento do escopo, o Número de Versão do Release de Destino pode ser aumentado de forma que o item permanecerá no documento Visão, mas será planejado para um release posterior.]

A.7	Designado Para

[Em muitos projetos, os recursos serão designados a "equipes de recursos" responsáveis por uma extração maior, gravando os requisitos e a implementação do software. Esta simples lista suspensa ajudará a todos na equipe do projeto a entender melhor as responsabilidades.]

A.8	Motivo

[Este campo de texto é utilizado para rastrear a origem do recurso solicitado. Os requisitos existem por motivos específicos. Este campo registra uma explicação ou uma referência a uma explicação. Por exemplo, a referência pode ser a uma página e número de linha de uma especificação de requisito do produto ou a um marcador de minuto em um vídeo de uma entrevista importante do cliente.]

<Nome da Empresa>

<Nome do Projeto>	Versão: <1.0>
Visão	Data: <dd/mmm/aa>
<identificador do documento>

Confidencial	(<Nome da Empresa>, 2006	Página 14

Visão

<Nome do Projeto>

Luis Tadeu Castilho

2005-11-10

Rational

<Company Name>