<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).]
Histórico da Revisão
Data |
Versão |
Descrição |
Autor |
<dd/mmm/yy> |
<x.x> |
<details> |
<name> |
|
|
|
|
|
|
|
|
|
|
|
|
Índice
1.3 Definições, Acrônimos e Abreviações
2.1.2 Justificativa para Alteração
2.3 Declaração de Posição do Produto
3. Descrições do Envolvido e do Usuário
3.7 Necessidades Principais do Envolvido ou do Usuário
3.8 Alternativas e Concorrência
3.9 Alternativas de Desenvolvimento Consideradas
9. Outros Requisitos do Produto
10. Requisitos de Documentação
10.3 Guias de Instalação, Configuração e Arquivo Leia-me
10.4 Etiquetagem e Empacotamento
Visão
[A finalidade deste documento é coletar, analisar e definir necessidades e recursos de alto nível do <<Nome do Sistema>>. Ele está focado nos recursos necessários aos envolvidos e usuários alvo e no porquê da existência dessas necessidades. Os detalhes de como o <<Nome do Sistema>> atende a essas necessidades são mostrados nas especificações suplementares e de caso de uso. Nota: esse gabarito de Visão tenta abranger todos os tipos de desenvolvimento, desde produtos vendidos em pacotes, desenvolvidos de maneira especulativa para uma necessidade de mercado percebida, até sistemas únicos, desenvolvidos sob contrato, para os requisitos específicos de um cliente. Conseqüentemente, as palavras "produto" e "sistema" podem ser utilizadas sem diferenciação cuidadosa, significando uma "coisa a ser desenvolvida". É esperado que a adequação do documento restringiria isso para um aplicativo específico.]
[A introdução do documento Visão fornece uma visão geral do documento inteiro. Ela deve incluir 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.]
[Especifique o objetivo deste documento de Visão.]
[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.]
[Esta subseção fornece as definições de todos os termos, acrônimos e abreviações requeridos para interpretar adequadamente o documento Visão. Estas informações podem ser fornecidas em referência ao Glossário do projeto.]
[Esta subseção fornece uma lista completa de todos os documentos mencionados em outra parte no documento Visão. Identifique cada documento pelo seguinte: título, número do relatório (se for o caso), data e organização responsável pela 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.]
[Esta subseção descreve o que o restante do documento Visão contém e explica como o documento é organizado.]
[Descreva resumidamente a oportunidade de negócio que está sendo atendida por este projeto.]
[Nesta subseção, descreva o segundo plano, o objetivo e o escopo do sistema existente ou circunstância de negócio, incluindo, conforme aplicável, as políticas que se aplicam, os recursos do sistema atual, os envolvidos comprometidos e questões de suporte.]
[Nesta subseção, descreva as novas circunstâncias ou necessidades que surgiram, em um sentido de negócios ou operacional, que justificam uma alteração. Identifique brevemente as alterações propostas e rejeitadas e o fundamento lógico associado. Se algum estudo de troca (sobre necessidades de alteração) foi feito, ele deve ser referenciado.]
[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 envolvidos 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] |
[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] |
Que |
[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] |
A menos que |
[principal alternativa competitiva] |
Nosso produto |
[declaração da diferenciação principal] |
[A declaração de posição de um produto ou sistema comunica a intenção do sistema e a importância do projeto para todo o pessoal envolvido.]
[Para fornecer produtos e serviços que efetivamente atendam as necessidades reais dos envolvidos e dos usuários, é necessário identificar e comprometer todos os envolvidos como parte do processo de Modelagem de Requisitos. Você deve também identificar os usuários do sistema e garantir que a comunidade de envolvidos os represente adequadamente. Esta seção fornece um perfil dos envolvidos e usuários comprometidos com o 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 envolvido. Em vez disso, fornece o segundo plano e a justificativa de por que os requisitos são necessários.]
[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 esse produto ou serviço suporta suas metas?]
[Há vários envolvidos com interesse no desenvolvimento e nem todos eles são usuários. Apresente uma lista de resumo desses envolvidos não-usuários. (Os usuários estão resumidos na seção 3.3.) ]
Nome |
Descrição |
Responsabilidades |
[Nomeie o tipo do envolvido.] |
[Descreva resumidamente o envolvido.] |
[Resuma as responsabilidades principais do envolvido em relação ao sistema que está sendo desenvolvido; ou seja, seus interesses como envolvido. Por exemplo, esse envolvido: - assegura que será possível manter o sistema - assegura que haverá uma demanda de mercado para os recursos do produto - monitora o progresso do projeto - aprova o financiamento] |
[Apresente uma lista de resumo de todos os usuários identificados.]
Nome |
Descrição |
Responsabilidades |
Envolvido |
[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 trabalho] |
[Se o usuário não for diretamente representado, identifique qual envolvido é responsável por representar os interesses 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?
Quaisquer restrições ambientais exclusivas: 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 sistemas/aplicativos estão em utilização? Seu sistema precisa ser integrado a eles?
É onde os extratos do Modelo de Negócios poderiam ser incluídos para descrever a tarefa e os trabalhadores de negócios envolvidos e assim por diante.]
[Descreva aqui cada envolvido no sistema preenchendo a seguinte tabela para cada envolvido. Lembre-se de que os tipos de envolvido 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 envolvido.]
Representante |
[Quem é o representante do envolvido no projeto? (Opcional se for documentado em algum outro lugar.) O que queremos aqui são nomes.] |
Descrição |
[Breve descrição do tipo de envolvido.] |
Tipo |
[Qualifique o conhecimento do envolvido, 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 envolvido com relação ao sistema que está sendo desenvolvido?isto é, seu interesse como um envolvido.] |
Critérios de Êxito |
[Como o envolvido define o êxito? Como o envolvido é recompensado?] |
Envolvimento |
[Como o envolvido está comprometido com o projeto? Relacione, onde possível, com funções do Rational Unified Process?isto é, Revisor de Requisitos e assim por diante.] |
Distribuíveis |
[Existe algum distribuível adicional requerido pelo envolvido? 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.] |
[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 abrange os seguintes tópicos para cada tipo de usuário.]
Representante |
[Quem é o representante do usuário no projeto? (Opcional se for documentado em algum outro lugar.) Isso freqüentemente refere-se ao Envolvido que representa o conjunto de usuários, por exemplo, Envolvido: Envolvido1.] |
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 com o 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.] |
[Liste os principais problemas com soluções existentes conforme observado pelo envolvido. Explique as seguintes questões para cada problema:
? Quais são as razões para esse problema?
? Como isso está resolvido agora?
? Quais soluções o envolvido ou o usuário desejam?]
[É importante entender a importância relativa que o envolvido 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. Ao utilizar 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 |
|
|
|
|
|
[Identifique as alternativas das percepções do interessado, conforme disponíveis. Elas podem incluir a compra de um produto do concorrente, a compra de uma solução desenvolvida internamente ou simplesmente a manutenção do status quo. Liste todas as opções competitivas conhecidas que existem ou que podem se tornar disponíveis. Inclua as principais forças e fraquezas de cada concorrente, conforme percebido pelo envolvido ou usuário.]
[Nesta subseção, descreva quaisquer alternativas ao produto proposto que foram consideradas e quaisquer estudos de troca associados.]
[Esta seção fornece uma visão de alto nível dos recursos do produto, das interfaces com outros sistemas e das configurações dos sistemas.]
[Essa subseção do documento de Visão coloca o produto na perspectiva de outros produtos relacionados e no 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 relatará como esses sistemas interagem e identifica as interfaces relevantes entre os sistemas. Uma maneira fácil de exibir os principais componentes do sistema maior, as interconexões e as interfaces externas é com um diagrama de bloco.
Identifique os impactos operacionais, organizacionais e de desenvolvimento nos envolvidos e outros sistemas.]
[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 entrar no ritmo. |
A base de conhecimento auxilia o pessoal de suporte na rápida identificação de correções e soluções alternativas conhecidos. |
A satisfação do cliente é aprimorada porque nada é deixado para trás. |
Os problemas são exclusivamente relacionados, classificados e monitorados durante 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 em conjunto 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, reduzindo os custos de suporte e aprimorando o tempo de resposta. |
A base de conhecimento pode ser disponibilizada pela Internet. Inclui recursos de procura de hipertexto e mecanismo de consulta gráfica. |
[Liste cada um dos fatores que afetam os recursos indicados no documento Visão. Liste premissas que, se alteradas, mudarão o documento Visão. Por exemplo, a Visão é construída no contexto de alguma corporação maior e, se algo for alterado nesse contexto, a Visão poderá precisar ser alterada. Isso pode incluir, por exemplo, fatores econômicos, políticos, jurídicos ou ambientais. A Visão também pode ter dependências na disponibilidade do equipamento, software ou outros componentes do sistema, ou ainda a disponibilidade de conhecimentos ou habilidades específicos.]
[Para produtos vendidos para clientes externos e para muitos sistemas internos, os problemas de custo e preço podem impactar diretamente a definição e a implementação do sistema. Nesta seção, registre quaisquer restrições de custo e preço que sejam relevantes. Por exemplo, custos de distribuição (nº de disquetes, nº de CD-ROMs, manipulação de CD) ou outras restrições de custo de mercadorias vendidas (manuais, embalagem) podem ser materiais para o êxito dos projetos ou irrelevantes, dependendo da natureza do sistema.]
[Os problemas de licença e instalação também podem impactar diretamente o esforço de desenvolvimento. Por exemplo, a necessidade de suportar controles de acesso, 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 construção do software ou criar a necessidade de um software de instalação separado. Sistemas físicos também podem impor requisitos especiais de instalação, se estiverem sujeitos a restrições específicas de segurança ou capacidade de sobrevivência, por exemplo.]
[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. Além disso, descreva com cada recurso quaisquer características de desempenho associadas - informe "até que ponto" algo deve ser feito, juntamente com alguma dimensão: por exemplo, juntamente com a dimensão de tempo, tempo de resposta, taxa de transações. A palavra "recurso" não foi escolhida por ter algum significado especial; você pode preferir "capacidade" ou "função", todas descrevendo algo que o sistema ou o produto deve fazer. 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 rastreio 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, recomenda-se para todo novo sistema, ou um incremento a um sistema existente, que os recursos sejam abstraídos a um nível alto o suficiente que resulte em 25 a 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 ou em linguagem natural, digamos, se o projeto eleger não produzir casos 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. Concentre-se nos recursos necessários e no porquê (não como) eles devem ser implementados.
? Se estiver utilizando o toolkit do Rational RequisitePro, tudo precisa ser selecionado como requisitos de tipo para fácil referência e monitoramento.]
[Descreve alguns usos do produto ou sistema que ilustrem algumas interações interessantes ou importantes entre o sistema e seus usuários, seu ambiente e/ou outros sistemas.]
[Nesta subseção, descreva como, em conceito, o suporte deverá ser fornecido, incluindo descrições de organização de suporte, equipamento, ciclos de manutenção e disposições de suprimentos.]
[Observe as restrições de design, restrições externas ou outras dependências.]
[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.]
[Defina a prioridade dos diferentes recursos do sistema.]
[Em um nível alto, liste padrões aplicáveis, requisitos de hardware ou plataforma, requisitos de desempenho e requisitos ambientais.]
[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).]
[Para o desenvolvimento de sistema de software, 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.]
[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.]
[Detalhe os requisitos ambientais conforme necessário. Para sistemas físicos, os problemas ambientais podem incluir temperatura, choque, umidade, radiação e assim por diante. Para sistemas de software, os fatores ambientais podem incluir condições de uso, ambiente do usuário, disponibilidade de recursos, problemas de manutenção e identificação e recuperação de erros.]
[Se houver algum requisito físico, tais como peso ou limites de massa ou limites de tamanho, descreva-o nesta subseção.]
[Esta seção descreve a documentação que deve ser desenvolvida para suportar a implantação do aplicativo com êxito.]
[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 impressão também devem ser identificadas.]
[Muitos sistemas fornecem ajuda on-line para auxiliar o usuário. A natureza desses sistemas não é usual, uma vez que eles combinam aspectos de programação (hyperlinks e assim por diante) com aspectos de escrita 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 com antecedência e da atividade de planejamento.]
[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 Neste 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.]
[Os sistemas modernos esforçam-se em fornecer uma aparência e comportamento consistentes que começam com a embalagem 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 sistema. Exemplos incluem observações sobre direitos autorais e patentes, logotipos corporativos, ícones padronizados e outros elementos gráficos e assim por diante.]
[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 são 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.]
[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.]
Proposto |
[Utilizado para descrever recursos que estão em discussão, mas que ainda não foram revisados e aceitos pelo "canal oficial", tal como um grupo de trabalho que consiste em representantes da equipe do projeto, gerenciamento do produto e comunidade de usuários ou clientes.] |
Aprovado |
[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.] |
[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 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 usos. 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 suportam menos uso típico e em conseqüência, serão utilizados com menos freqüência ou para os quais podem ser alcançadas soluções alternativas razoavelmente eficientes. 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.] |
[Definido pela equipe de desenvolvimento. Como alguns recursos requerem mais tempo e recursos que outros, estimar o número semanas por equipe ou pessoa, ou alguma medida de tamanho que seja correlacionada ao esforço (tal como linhas de código requeridas ou pontos de função para software) é a melhor maneira de calibrar a complexidade e definir as expectativas daquilo que pode ou não pode ser ser feito em um determinado período de tempo. Utilizado no gerenciamento do escopo e na determinação da prioridade de desenvolvimento.]
[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 projetos considera suficiente a categorização dos riscos como alta, média e baixa, embora outras gradações mais refinadas sejam possíveis. O risco pode freqüentemente ser avaliado indiretamente medindo a incerteza (intervalo) da estimativa de planejamento da equipe de projetos.]
[Definido pelo analista e pela equipe de desenvolvimento com base na probabilidade de o recurso ser alterado ou no entendimento da equipe de que o recurso será alterado. Usado para ajudar a estabelecer as prioridades de desenvolvimento e a determinar os itens que deverão ser extraídos.]
[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 ocorrer o gerenciamento de escopo, o Número da Versão do Release de Destino poderá ser aumentado para que o item permaneça no documento Visão, mas será planejado para uma liberação posterior.]
[Em muitos projetos, os recursos serão designados a "equipes de recurso" responsável por extração adicional, capturando e refinando os requisitos e a implementação. Esta simples lista suspensa ajudará a todos na equipe do projeto a entender melhor as responsabilidades.]
[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.]