[A finalidade deste documento é coletar, analisar e definir necessidades e recursos de nível superior do <<Nome do Sistema>>. Ele se concentra nos recursos necessários aos envolvidos e aos usuários-alvo e nas razões que levam a essas necessidades. Os detalhes de como o <<Nome do Sistema>> satisfaz essas necessidades são descritos no caso de uso e nas especificações suplementares.]

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

1.1 Finalidade

[Especifique a finalidade deste documento Visão.]

1.2 Escopo

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

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

[Esta subseção fornece as definições de todos os termos, acrônimos e abreviações necessárias à adequada interpretação do documento Visão. Essas informações podem ser fornecidas fazendo referências ao Glossário do projeto.]

1.4 Referências

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

1.5 Visão Geral

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

2. Posicionamento

2.1 Oportunidade de Negócios

[Faça uma breve descrição da oportunidade de negócios atendida por este projeto.]

2.2 Descrição do Problema

[Forneça uma descrição resumindo o problema que está sendo resolvido pelo projeto. Poderá ser usado este formato:]

O problema de	[descreva o problema]
afeta	[os envolvidos afetados pelo problema]
cujo impacto é	[qual é o impacto do problema?]
uma boa solução seria	[liste alguns dos principais benefícios de uma boa solução]

2.3 Sentença de Posição do Produto

[Forneça uma sentença geral resumindo, no nível mais alto, a posição exclusiva que o produto pretende ocupar no mercado. Poderá ser usado este formato:]

Para	[cliente-alvo]
Que	[indique a necessidade ou oportunidade]
O (nome do produto)	é um(a) [categoria do produto]
Que	[indique o principal benefício; ou seja, a razão convincente que motiva a compra]
Diferente de	[principal alternativa da concorrência]
Nosso produto	[indique a principal diferença]

[Uma sentença de posição do produto comunica o objetivo do aplicativo e a importância do projeto para todo o pessoal envolvido.]

3. Descrições dos Envolvidos e dos Usuários

[Para fornecer, de maneira eficiente, produtos e serviços que atendam às reais necessidades dos usuários e dos envolvidos, é necessário identificar e considerar todos os envolvidos como parte do processo de Modelagem de Requisitos. É necessário também identificar os usuários do sistema e assegurar que a comunidade de envolvidos os represente adequadamente. Esta seção fornece um perfil dos envolvidos e dos usuários que integram o projeto, e dos principais problemas que, de acordo com o ponto de vista deles, poderão ser abordados pela solução proposta. Ela não descreve as solicitações ou os requisitos específicos dos usuários e dos envolvidos, já que eles são capturados em um artefato individual de solicitações dos evolvidos. Em vez disso, ela fornece a base e a justificativa que explicam por que os requisitos são necessários.]

3.1 Demografia dos Mercados

[Resuma as principais demografias do mercado que motivam as decisões do produto. Descreva e posicione os segmentos do mercado-alvo. Avalie o tamanho e o crescimento do mercado utilizando o número de usuários em potencial ou o montante que seus clientes gastam tentando suprir necessidades que podem ser atendidas pelo seu produto ou melhoria. Revise as principais tendências e tecnologias do setor. Responda a estas perguntas estratégicas:

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

• Qual você gostaria que fosse?

• De que maneira este produto ou serviço o ajuda a atingir suas metas?]

3.2 Resumo dos Envolvidos

[Há uma série de envolvidos que se interessam pelo desenvolvimento e nem todos eles são usuários finais. Apresente uma lista resumida desses envolvidos que não são usuários. (O resumo dos usuários encontra-se na seção 3.3.)]

Nome

Descrição

Responsabilidades

[Especifique o nome do tipo de envolvido.]

[Descreva brevemente o envolvido.]

[Resuma as principais responsabilidades do envolvido no que diz respeito ao sistema que está sendo desenvolvido; ou seja, seu interesse como envolvido. Por exemplo, este envolvido:

- assegura que o sistema poderá ser mantido

- assegura que haverá uma demanda de mercado pelos recursos do produto

- monitora o andamento do projeto

- aprova financiamentos

- e assim por diante]

3.3 Resumo dos Usuários

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

Nome

Descrição

Responsabilidades

Envolvido

[Informe o tipo de usuário.]

[Descreva brevemente o que ele representa no que diz respeito ao sistema.]

[Liste as principais responsabilidades do usuário em relação ao sistema que está sendo desenvolvido; por exemplo:

- percebe os detalhes

- elabora relatórios

- coordena o trabalho

- e assim por diante]

[Se o usuário não for representado diretamente, identifique o envolvido responsável por representar os interesses dele.]

3.4 Ambiente do Usuário

[Descreva o ambiente de trabalho do usuário-alvo. A seguir são apresentadas algumas sugestões:

Número de pessoas envolvidas na execução da tarefa? Isso está mudando?
Qual é a duração de um ciclo de tarefas? Qual é o tempo gasto em cada atividade? Isso está mudando?
Quaisquer restrições ambientais exclusivas: telefone celular, ambientes ao ar livre, uso em aeronaves e assim por diante?
Quais plataformas de sistema estão sendo utilizadas atualmente? Plataformas futuras?
Que outros aplicativos estão em uso? É necessário que o seu aplicativo interaja com eles?

Nesse ponto, você poderá incluir textos provenientes do Modelo de Negócios para descrever a tarefa e os trabalhadores de negócio envolvidos, entre outros.]

3.5 Perfis dos Envolvidos

[Descreva aqui cada envolvido no sistema preenchendo a tabela abaixo para cada um deles. Lembre-se de que os tipos de envolvidos poderão ser os mais diversos como, por exemplo, usuários, departamentos e desenvolvedores técnicos. Um perfil completo deve abranger os tópicos abaixo para cada tipo de envolvido.]

3.5.1 <Nome do Envolvido>

Representante	[Quem é o representante do envolvido no projeto? (Opcional se já estiver documentado em outro lugar.) Especifique aqui o nome da pessoa.]
Descrição	[Breve descrição do tipo de envolvido.]
Tipo	[Qualifique a habilidade, a formação técnica e o grau de sofisticação do envolvido - ou seja, se ele é um guru, executivo, especialista, usuário eventual e assim por diante.]
Responsabilidades	[Liste as principais responsabilidades do envolvido no que diz respeito ao sistema que está sendo desenvolvido - ou seja, seu interesse como envolvido.]
Critérios de Sucesso	[Como o envolvido define sucesso? De que forma o envolvido é recompensado?]
Envolvimento	[Qual é o grau de comprometimento do envolvido no projeto? Faça referência, quando possível, aos papéis exercidos no Rational Unified Process - ou seja, Revisor de Requisitos etc.]
Produtos Liberados	[Existem outros produtos liberados exigidos pelo envolvido? Eles podem ser produtos liberados do projeto ou saídas do sistema em desenvolvimento.]
Comentários / Problemas	[Os problemas que interferem no bom andamento do projeto e outras informações relevantes serão relacionados aqui.]

3.6 Perfis dos Usuários

[Descreva cada usuário único do sistema preenchendo a seguinte tabela para cada tipo de usuário. Lembre-se de que os tipos de usuário poderão ser os mais diversos como, por exemplo, gurus e principiantes. Por exemplo, um guru poderá precisar de uma ferramenta flexível sofisticada com suporte a plataformas cruzadas, enquanto um principiante poderá precisar de uma ferramenta amigável e de fácil utilização. Um perfil completo abrangerá os seguintes tópicos para cada tipo de usuário.]

3.6.1 <Nome do Usuário>

Representante	[Quem é o representante do usuário no projeto? (Opcional se estiver documentado em outro lugar.) Freqüentemente refere-se ao Envolvido que representa o conjunto de usuários como, por exemplo, Envolvido: Envolvido1.]
Descrição	[Uma breve descrição do tipo de usuário.]
Tipo	[Qualifique a experiência do usuário, sua formação técnica e grau de sofisticação - ou seja, guru, usuário eventual etc.]
Responsabilidades	[Liste as principais responsabilidades do usuário no que diz respeito ao sistema que está sendo desenvolvido - ou seja, se ele captura detalhes, produz relatórios, coordena o trabalho etc.]
Critérios de Sucesso	[Como o usuário define o sucesso? Como o usuário é recompensado?]
Envolvimento	[Como o usuário está envolvido no projeto? Faça referência, quando possível, aos papéis exercidos no Rational Unified Process - ou seja, Revisor de Requisitos etc.]
Produtos Liberados	[O usuário produz algum produto que é liberado? Em caso positivo, para quem?]
Comentários / Problemas	[Problemas que interferem no sucesso e quaisquer outras informações relevantes devem ser especificados aqui. Entre eles poderão estar incluídas tendências que facilitam ou dificultam o trabalho do usuário.]

3.7 Principais Necessidades dos Usuários ou dos Envolvidos

[Liste os principais problemas com as soluções existentes conforme o ponto de vista do envolvido. Esclareça as seguintes questões referentes a cada problema:

• Quais são as causas deste problema?

• Como ele está sendo resolvido agora?

• Que soluções o envolvido ou o usuário deseja?]

[É importante compreender a importância relativa exercida pelo usuário ou pelo envolvido na resolução de cada problema. As técnicas de ordenação e votação cumulativa indicam os problemas que devem ser resolvidos versus problemas que eles gostariam que fossem resolvidos.

Preencha a tabela a seguir — se estiver usando o Rational RequisitePro para capturar as Necessidades, pode ser um fragmento ou relatório dessa ferramenta.]

Necessidade	Prioridade	Preocupações	Solução Atual	Soluções Propostas
Transmitir mensagens

3.8 Alternativas e Concorrência

[Identifique as alternativas disponíveis consideradas pelos envolvidos. Isso inclui adquirir um produto do concorrente, desenvolver uma solução própria ou simplesmente manter o estado atual. Liste todas as opções conhecidas que a concorrência oferece ou que podem se tornar disponíveis. Inclua os principais pontos fortes e pontos fracos de cada concorrente segundo o ponto de vista do envolvido ou do usuário final.]

3.8.1 <aCompetitor>

3.8.2 <anotherCompetitor>

4. Visão Geral do Produto

[Esta seção fornece uma visão de nível superior dos recursos, interfaces com outros aplicativos e configurações de sistemas do produto. Ela geralmente é constituída destas três subseções:

• Perspectiva do produto

• Funções do produto

• Suposições e dependências]

4.1 Perspectiva do Produto

[Esta subseção do documento Visão analisa o produto em relação a outros produtos relacionados e ao ambiente do usuário. Se o produto for independente e totalmente auto-suficiente, exponha isso aqui. Se o produto for um componente de um sistema maior, esta subseção relatará como esses sistemas interagem e identificará as interfaces relevantes entre os sistemas. Uma maneira fácil de exibir os principais componentes do sistema maior, suas interconexões e interfaces externas é através de um diagrama de bloco.]

4.2 Resumo dos Recursos

[Resuma os principais benefícios e recursos que o produto fornecerá. Por exemplo, um documento Visão referente a um sistema de suporte ao cliente poderá usar esta parte para abordar a documentação de problemas, o roteamento e a elaboração de relatórios de status sem mencionar a quantidade de detalhes necessária a cada uma dessas funções.

Organize as funções de modo que a lista possa ser compreendida pelo cliente ou por qualquer pessoa que esteja lendo o documento pela primeira vez. Uma tabela simples relacionando os principais benefícios e seus recursos de suporte poderá ser suficiente. Por exemplo:]

Tabela 4-1 Sistema de Suporte ao Cliente

Benefício para o Cliente	Recursos de Suporte
Novas equipes de suporte poderão ficar rapidamente informadas do processo.	Uma base de conhecimentos ajuda o pessoal de suporte a identificar rapidamente ações corretivas e soluções conhecidas.
A satisfação do cliente é melhorada porque nada é negligenciado.	Os problemas são relacionados como itens únicos, classificados e monitorados ao longo de todo o processo de resolução. São emitidas notificações automáticas para os problemas que têm seus prazos expirados.
O gerenciamento pode identificar áreas de problemas e estimar a carga de trabalho da equipe.	Os relatórios de tendências e de distribuição permitem revisões de nível superior do status dos problemas.
Equipes de suporte distribuídas podem trabalhar em conjunto para solucionar problemas.	Um servidor de duplicação permite que as informações atuais do banco de dados sejam compartilhadas pela empresa.
Os clientes têm autonomia para resolver seus problemas, o que reduz os custos de suporte e melhora o tempo de resposta.	Uma base de dados pode ser disponibilizada na Internet. Ela contém recursos de pesquisa de hipertexto e um mecanismo de consulta gráfico.

4.3 Suposições e Dependências

[Liste cada fator que afeta os recursos especificados no documento Visão. Liste as suposições que, se sofrerem mudanças, alterarão o documento Visão. Por exemplo, uma suposição poderá estabelecer que um sistema operacional específico estará disponível para o hardware projetado para o produto de software. Se o sistema operacional não estiver disponível, o documento Visão terá que ser alterado.]

4.4 Custos e Preços

[Para produtos vendidos para clientes externos e para muitos aplicativos internos, as questões de custos e preços poderão exercer impacto direto na definição e na implementação dos aplicativos. Nesta seção, registre quaisquer restrições de custo e de preços que sejam relevantes. Por exemplo, os custos de distribuição (número de disquetes, número de CD-ROMs, masterização de CDs) ou outras restrições de custo de produtos vendidos (manuais, embalagem) poderão ser importantes para o êxito dos projetos, ou irrelevantes, dependendo da natureza do aplicativo.]

4.5 Licenciamento e Instalação

[As questões de licenciamento e de instalação poderão exercer impacto direto no esforço de desenvolvimento. Por exemplo, a necessidade de suportar a serialização, a segurança das senhas ou o licenciamento de rede criará requisitos adicionais do sistema que deverão ser considerados no esforço de desenvolvimento.

Os requisitos de instalação também poderão afetar a codificação ou criar a necessidade de softwares de instalação individual.]

5. Recursos do Produto

[Liste e descreva brevemente os recursos do produto. Trata-se dos recursos de nível superior do sistema que são necessários para propiciar benefícios aos usuários. Cada recurso é um serviço desejado externamente que normalmente exige uma série de entradas para alcançar os resultados desejados. Por exemplo, um dos recursos de um sistema de rastreamento de problemas poderá ser a capacidade de fornecer relatórios de tendências. À medida que o modelo de casos de uso for desenvolvido, atualize a descrição para fazer referência aos casos de uso.

Como o documento Visão é revisado por uma ampla variedade de pessoas envolvidas, o nível de detalhamento terá que ser genérico o bastante para que todos possam compreendê-lo. No entanto, devem estar disponíveis detalhes suficientes para fornecer à equipe as informações necessárias para criar um modelo de casos de uso.

Para gerenciar a complexidade dos aplicativos de maneira eficiente, é recomendável para qualquer sistema novo, ou para uma adição que complemente um sistema existente, que seja utilizado um grau de abstração de nível suficientemente elevado de modo a resultar em 25 a 99 recursos. Esses recursos serão a base fundamental do gerenciamento do projeto, do gerenciamento do escopo e da definição do produto. Cada recurso será descrito mais detalhadamente no modelo de casos de uso.

Em toda esta seção, cada recurso será percebido externamente por usuários, operadores ou outros sistemas externos. Esses recursos deverão incluir uma descrição da funcionalidade e de todas as questões de usabilidade relevantes que deverão ser abordadas. As seguintes diretrizes se aplicam:

• Evite o design. Mantenha as descrições dos recursos em um nível geral. Concentre-se nos recursos necessários e no porquê (e não em como) eles deverão ser implementados.

• Se estiver usando o kit de ferramentas do Rational RequisitePro, tudo terá que ser selecionado como requisitos de tipo para facilitar a consulta e o rastreamento.]

5.1 <aFeature>

5.2 <anotherFeature>

6. Restrições

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

7. Intervalos de Qualidade

[Defina os intervalos de qualidade para desempenho, robustez, tolerância a erros, usabilidade e características semelhantes que não são capturadas no Conjunto de Recursos.]

8. Precedência e Prioridade

[Defina a prioridade dos diferentes recursos do sistema.]

9. Outros Requisitos do Produto

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

9.1 Padrões Aplicáveis

[Liste todos os padrões com os quais o produto deverá estar em conformidade. Entre eles, poderão estar incluídos padrões legais e reguladores (FDA, UCC), padrões de comunicações (TCP/IP, ISDN), padrões de conformidade com plataformas (Windows, UNIX etc) e padrões de qualidade e de segurança (UL, ISO, CMM).]

9.2 Requisitos do Sistema

[Defina todos os requisitos do sistema necessários para suportar o aplicativo. Entre eles, poderão estar incluídos os sistemas operacionais de host e as plataformas de rede suportados, configurações, memória, periféricos e software fornecido.]

9.3 Requisitos de Desempenho

[Use esta seção para descrever os requisitos de desempenho. Os problemas de desempenho podem abranger itens como fatores de carga do usuário, largura de banda ou capacidade de comunicação, taxa de transferência, precisão e confiabilidade ou tempos de resposta em uma série de condições de carregamento.]

9.4 Requisitos Ambientais

[Descreva os requisitos ambientais quando necessário. Para sistemas baseados em hardware, as questões ambientais poderão incluir temperatura, choques, umidade, radiação etc. 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 recuperação e tratamento de erros.]

10. Requisitos de Documentação

[Esta seção descreve a documentação que deverá ser desenvolvida para suportar a implantação bem-sucedida de aplicativos.]

10.1 Manual do Usuário

[Descreva a finalidade e o conteúdo do Manual do Usuário. Discuta questões como o tamanho desejado, o nível de detalhamento, a necessidade de um índice, o uso de um glossário de termos, estratégia de tutorial versus de manual de referência etc. As restrições de formatação e de impressão também deverão ser identificadas.]

10.2 Ajuda On-line

[Muitos aplicativos fornecem um sistema de ajuda on-line para auxiliar o usuário. A natureza desses sistemas é exclusiva do desenvolvimento do aplicativo já que eles combinam aspectos de programação (hyperlinks etc) com aspectos de escrita técnica como, por exemplo, organização e apresentação. Muitos perceberam que o desenvolvimento de um sistema de ajuda on-line é um projeto que está contido em outro projeto, beneficiando-se do gerenciamento adiantado do escopo e da atividade de planejamento.]

10.3 Guias de Instalação e de Configuração, e Arquivo Leiame

[Um documento que inclua instruções de instalação e diretrizes de configuração é importante para se oferecer uma solução completa. Além disso, um arquivo Leiame é normalmente incluído como um componente padrão. O arquivo Leiame poderá incluir uma seção "O Que Há de Novo Neste Release" e uma discussão dos problemas de compatibilidade em relação aos releases anteriores. A maior parte dos usuários também considera desejável que o arquivo Leiame documente erros e soluções conhecidos.]

10.4 Rotulação e Embalagem

[Os aplicativos modernos atuais apresentam uma aparência consistente que é percebida inicialmente na embalagem do produto e se propaga pelos menus de instalação, telas iniciais, sistemas de ajuda, caixas de diálogo GUI etc. Esta seção define as necessidades e os tipos de rotulação a serem incorporados no código. Como exemplos, podemos citar observações sobre direitos autorais e patentes, logotipos corporativos, ícones padronizados, outros elementos gráficos etc.]

A Atributos de Recursos

[São designados atributos para os recursos que podem ser usados para avaliar, rastrear, priorizar e gerenciar os itens do produto cuja implementação foi proposta. Todos os atributos e tipos de requisitos são descritos no Plano de Gerenciamento de Requisitos. No entanto, talvez seja conveniente listar e descrever brevemente os atributos referentes aos recursos que foram escolhidos. As subseções a seguir representam um conjunto de atributos de recursos sugeridos.]

A.1 Status

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

Proposto	[Usado para descrever recursos que estão sendo discutidos, mas que ainda não foram revisados e aceitos pelo "canal oficial" como, por exemplo, um grupo de trabalho formado por representantes da equipe do projeto, do gerenciamento do produto e da comunidade de usuários ou de clientes.]
Aprovado	[Recursos que são considerados úteis e viáveis, e cuja implementação foi aprovada pelo canal oficial.] ]
Incorporado	[Recursos incorporados à baseline do produto em um momento específico no tempo.]

A.2 Benefício

[Definido pelo departamento de marketing, pelo gerente do produto ou pelo analista de negócios. Todos os requisitos diferem entre si. A classificação dos requisitos por seu benefício relativo para o usuário final inicia um diálogo com os clientes, analistas e membros da equipe de desenvolvimento. Usado no gerenciamento do escopo e na determinação da prioridade de desenvolvimento.]

Crítico	[Recursos essenciais. Sua não implementação implica que o sistema não atenderá às necessidades do cliente. Todos os recursos críticos deverão ser implementados no release ou a programação será retardada.]
Importante	[Recursos importantes para a eficácia e a eficiência do sistema da maior parte dos aplicativos. A funcionalidade não poderá ser fornecida facilmente de outra maneira. Caso um recurso importante não seja incluído, a satisfação do cliente ou do usuário, ou até a receita, poderão ser afetadas, mas isso não retardará o release.]
Útil	[Os recursos que são úteis em aplicativos menos típicos ou para os quais possam se obter soluções razoavelmente eficientes serão usados com menor freqüência. Não se pode esperar nenhum impacto significativo na receita ou na satisfação do cliente se esse tipo de recurso não for incluído em um release.]

A.3 Esforço

[Definido pela equipe de desenvolvimento. Como algumas funcionalidades necessitam de mais tempo e de mais recursos do que outras, estimar o número de semanas de participação de cada pessoa ou equipe, as linhas de código necessárias ou os pontos de função, por exemplo, é a melhor maneira de avaliar a complexidade e definir expectativas do que poderá ou não ser feito em um determinado período de tempo. Usado 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 ocorrerem eventos indesejáveis no projeto como, por exemplo, custos excessivos, atrasos na programação ou até cancelamentos. A maior parte dos gerentes de projeto considera que a categorização dos riscos em altos, médios e baixos é suficiente, embora sejam possíveis gradações ainda mais específicas. Freqüentemente os riscos poderão ser avaliados indiretamente medindo-se o grau de incerteza (intervalo) da estimativa de programação da equipe dos projetos.]

A.5 Estabilidade

[Este atributo é definido pelo analista e pela equipe de desenvolvimento com base na probabilidade de o recurso sofrer mudanças ou na probabilidade de a equipe vir a compreender o recurso de uma forma diferente. É usado para ajudar a estabelecer prioridades de desenvolvimento e determinar os itens para os quais uma averiguação adicional é a próxima ação apropriada.]

A.6 Release-alvo

[Registra a versão planejada do produto em que o recurso aparecerá pela primeira vez. Este campo poderá ser usado para alocar recursos de um documento Visão em um release de baseline específico. Quando for usado em conjunto com o campo de status, sua equipe poderá propor, registrar e discutir vários recursos do release sem que tenham que ser necessariamente desenvolvidos. Somente serão implementados os recursos cujo Status estiver definido como Incorporado e cujo Release-alvo estiver definido. Quando ocorrer o gerenciamento de escopo, o Número da Versão do Release-alvo poderá ser aumentado de modo que o item permaneça no documento Visão, mas seja programado para um release posterior.]

A.7 Atribuído a

[Em muitos projetos, os recursos serão atribuídos a "equipes de recursos" responsáveis por averiguar e por escrever os requisitos do software, e também por sua implementação. Esta lista suspensa simples ajudará a todos da equipe do projeto a compreenderem melhor suas responsabilidades.]

A.8 Razão

[Este campo de texto é usado para rastrear a origem do recurso solicitado. Os requisitos existem devido a razões específicas. Este campo registra uma explicação ou uma referência a uma explicação. Por exemplo, a referência poderá ser ao número de uma linha e de uma página de uma especificação de requisitos do produto ou a um minúsculo marcador em um vídeo de uma entrevista com um cliente importante.]