[A introdução do Plano de Gerenciamento de Requisitos fornece uma visão geral de todo o documento. Ela contém a finalidade, o escopo, as definições, os acrônimos, as abreviações, as referências e a visão geral deste Plano de Gerenciamento de Requisitos.]

1.1 Finalidade

[Especifique a finalidade deste Plano de Gerenciamento de Requisitos.]

1.2 Escopo

[Uma breve descrição do escopo deste Plano de Gerenciamento de Requisitos.]

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 Plano de Gerenciamento de Requisitos. Essas informações podem ser fornecidas mediante referência ao Glossário do projeto.]

1.4 Referências

[Esta subseção deve fornecer uma lista completa de todos os documentos mencionados em qualquer outra parte do Plano de Gerenciamento de Requisitos. Cada documento é identificado 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 Plano de Gerenciamento de Requisitos contém e explica como o documento está organizado.]

2. Gerenciamento de Requisitos

2.1 Organização, Responsabilidades e Interfaces

[Descreva quem será responsável por executar as diversas atividades descritas nos fluxos de trabalho de requisitos.]

2.2 Ferramentas, Ambiente e Infra-estrutura

[Descreva o ambiente computacional e as ferramentas de software a serem usadas na execução das funções de Gerenciamento de Requisitos durante todo o ciclo de vida do produto ou do projeto.

Descreva as ferramentas e os procedimentos usados para controlar a versão dos itens de Requisitos gerados durante todo o ciclo de vida do produto ou do projeto.]

3. O Programa de Gerenciamento de Requisitos

3.1 Identificação dos Requisitos

[Descreva os itens de rastreabilidade e defina como eles devem ser nomeados, marcados e numerados. (Um item de rastreabilidade é qualquer elemento de projeto que necessite ser explicitamente rastreado a partir de outro item textual ou de modelo, a fim de manter-se um controle das dependências entre eles. Em relação ao Rational RequisitePro, essa definição pode ser reformulada da seguinte maneira: qualquer elemento de projeto representado no RequisitePro por uma instância de um tipo de requisito do RequisitoPro.)]

[Paca cada tipo de artefato ou documento de requisitos do projeto, liste os itens de rastreabilidade contidos nele e explique brevemente para que ele é usado. Também poderá ser conveniente listar o papel responsável.]

Artefato (Tipo de Documento)	Item de Rastreabilidade	Descrição
Solicitações dos Principais Envolvidos (STR)	Solicitação do Envolvido (STRQ)	As principais solicitações, incluindo Solicitações de Mudança, dos envolvidos. [Se você usar uma ferramenta de Gerenciamento de Solicitações de Mudança, como o Rational ClearQuest, as solicitações dos principais envolvidos serão freqüentemente armazenadas nessa ferramenta e não serão duplicadas na ferramenta de gerenciamento de requisitos.]
Visão (VIS)	Necessidade dos Envolvidos (NEED)	A principal necessidade dos envolvidos ou dos usuários
Visão (VIS)	Recurso (FEAT)	Condições ou recursos desse release do sistema
Modelo de Casos de Uso	Caso de Uso (UC)	Os casos de uso desse release, documentados no Rational Rose
Especificação Suplementar (SS)	Requisito Suplementar (SUPP)	Os requisitos não-funcionais que não são capturados no modelo de casos de uso

3.2 Rastreabilidade

[Visão geral de rastreabilidade; por exemplo, um gráfico de rastreabilidade.]

3.2.1 Critérios de <item de rastreabilidade>

[Para cada item de rastreabilidade identificado, liste todas as regras ou diretrizes adicionais que se aplicam aos vínculos de rastreabilidade. Descreva todas as restrições aplicáveis como, por exemplo, "cada recurso aprovado deve estar relacionado a um ou mais Casos de Uso ou a um ou mais Requisitos Suplementares."]

3.3 Atributos

3.3.1 Atributos de <item de rastreabilidade>

[Para cada item de rastreabilidade identificado, liste os atributos que você usará e explique brevemente o que significam. Por exemplo, poderão ser especificados os seguintes atributos para um item de rastreabilidade de "recurso".]

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 que foram aprovados para implementação pelo canal oficial.]
Rejeitado	[Rejeitado pelo canal oficial.]
Incorporado	[Recursos incorporados à baseline do produto em um momento específico no tempo.]

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. A 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 podem 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.]

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.]

Risco

[Definido pela equipe de desenvolvimento e baseado 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 programação estimada das equipes dos projetos.]

Estabilidade

[Este atributo é definido pelo analista e pela equipe de desenvolvimento. Baseia-se 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.]

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.]

Atribuído A

[Em muitos projetos, os recursos serão atribuídos a "equipes de recursos" responsáveis por averiguar e 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.]

Motivo

[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 importante cliente.]

3.4 Relatórios e Medidas

[Descreva o conteúdo, o formato e a finalidade dos relatórios/medidas solicitados.

3.5 Gerenciamento de Mudança de Requisitos

3.5.1 Processamento e Aprovação de Solicitações de Mudança

[Descreva o processo através do qual os problemas e mudanças são enviados, revisados e organizados. Nessa descrição, deverá estar incluído o processo para negociar mudanças de requisitos com os clientes e quaisquer processos, atividades e restrições contratuais].

3.5.2 Comitê de Controle de Mudança (CCB)

[Descreva a participação e os procedimentos para processar solicitações e aprovações de mudança a serem seguidos pelo CCB.]

3.5.3 Baselines do Projeto

[As baselines funcionam como um padrão oficial no qual os trabalhos subseqüentes são baseados. Somente mudanças autorizadas podem ser efetuadas nas baselines.

Descreva em que pontos do ciclo de vida do projeto ou produto as baselines devem ser estabelecidas. As baselines mais comuns devem ser definidas ao final de cada uma das fases de Iniciação, Elaboração, Construção e Transição. Elas também podem ser geradas no final de iterações ocorridas dentro das várias fases ou com freqüência ainda maior.

Descreva quem autoriza uma baseline e o que ela contém.]

3.6 Fluxos de Trabalho e Atividades

[Descreva os fluxos de trabalho e as atividades que se aplicam ao gerenciamento de requisitos.

Descreva as atividades de revisão, incluindo seus objetivos, responsabilidades, andamento e procedimentos].

4. Marcos

[Identifique os marcos internos e do cliente relacionados ao esforço de Gerenciamento de Requisitos. Esta seção deve incluir detalhes sobre quando o Plano de Gerenciamento de Requisitos propriamente dito deverá ser atualizado.]

5. Treinamento e Recursos

[Descreva o treinamento, o pessoal e as ferramentas de software necessários para implementar as atividades de Gerenciamento de Requisitos especificadas.]