<Nome do Projeto>

Plano de Gerenciamento de Requisitos

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	4

1.1	Objetivo	4

1.2	Escopo	4

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

1.4	Referências	4

1.5	Visão Geral	4

2.	Gerenciamento de Requisitos	4

2.1	Organização, Responsabilidades e Interfaces	4

2.2	Ferramentas, Ambiente e Infra-estrutura	4

3.	O Programa de Gerenciamento de Requisitos	4

3.1	Identificação de Requisitos	4

3.2	Rastreabilidade	5

3.2.1	Critérios para <item de rastreabilidade>	5

3.3	Atributos	5

3.3.1	Atributos para <item de rastreabilidade>	5

3.4	Relatórios e Medidas	7

3.5	Gerenciamento de Mudanças de Requisitos	7

3.5.1	Processamento e Aprovação de Controles de Mudanças	7

3.5.2	CCB (Conselho de Controle de Mudanças)	7

3.5.3	Linhas de Base do Projeto	7

3.6	Atividades e Tarefas	8

4.	Marcos	8

5.	Treinamento e Recursos	8

Plano de Gerenciamento de Requisitos

Introdução

[A introdução do Plano de Gerenciamento de Requisitos 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 Plano de Gerenciamento de Requisitos.]

Objetivo

[Especifique o objetivo deste Plano de Gerenciamento de Requisitos.]

Escopo

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

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 Plano de Gerenciamento de Requisitos. 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 Plano de Gerenciamento de Requisitos. 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 Plano de Gerenciamento de Requisitos contém e explica como o documento é organizado.]

Gerenciamento de Requisitos

Organização, Responsabilidades e Interfaces

[Descreva quem será responsável pela execução de várias tarefas nas atividades de requisitos.]

Ferramentas, Ambiente e Infra-estrutura

[Descreva o ambiente de computação e as ferramentas de software a serem utilizados no preenchimento de funções de Gerenciamento de Requisitos em todo o projeto ou ciclo de vida do produto.

Descreva as ferramentas e os procedimentos utilizados para os itens Requisitos de controle de versão gerados em todo o projeto ou ciclo de vida do produto.]

O Programa de Gerenciamento de Requisitos

Identificação de Requisitos

[Descreva os itens de rastreabilidade e defina como eles devem ser nomeados, marcados e numerados. (Um item de rastreabilidade é qualquer elemento do projeto que precisa ser explicitamente rastreado de outro item textual ou de modelo para controlar as dependências entre eles. Em relação ao Rational Requisite Pro, essa definição pode ser reformulada como: qualquer elemento de projeto representado no RequisitePro por uma instância de um tipo de requisito RequisitePro.)]

[Para cada tipo de produto de trabalho de requisito no projeto, liste os itens de rastreabilidade contidos nele e explique resumidamente para que ele é utilizado. Talvez seja necessário listar também a função responsável.]

Produto de Trabalho

(Tipo de Documento)	Item de Rastreabilidade	Descrição
Pedidos do Envolvido (STR)	Pedido do Envolvido (STRQ)	Pedidos chave, incluindo Controles de Mudanças, de investidores

[Se você utilizar uma ferramenta Gerenciamento de Controles de Mudanças, como Rational ClearQuest, os pedidos do envolvido serão freqüentemente armazenados nessa ferramenta e não serão duplicados na ferramenta de gerenciamento de requisitos.]
Visão (VIS)	Necessidade dos Envolvidos (NEED)	Necessidade principal do investidor ou usuário
Visão (VIS)	Recurso (FEAT)	Condições ou recursos deste release do sistema
Modelo de Caso de Uso	Caso de Uso (UC)	Casos de uso para este release, documentados no Rational Rose
Especificação Suplementar (SS)	Requisito Suplementar (SUPP)	Requisitos não funcionais que não são capturados no modelo de caso de uso

Rastreabilidade

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

Critérios para <item de rastreabilidade>

[Para cada item de rastreabilidade identificado, liste as regras ou orientações adicionais que se aplicam aos links de rastreabilidade. Descreva as restrições aplicáveis, como “cada recurso aprovado deve ser rastreado para um ou mais Casos de Uso ou para um ou mais Requisitos Suplementares”.]

Atributos

Atributos para <item de rastreabilidade>

[Para cada item de rastreabilidade identificado, liste quais atributos serão utilizados e explique resumidamente o que eles significam. Por exemplo, os atributos a seguir podem ser especificados para um item de rastreabilidade de “recurso”.]

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.]
Rejeitado	[Rejeitado pelo canal oficial.]
Incorporado	[Recursos incorporados na linha de base do produto em um momento específico.]
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 ou para os quais soluções alternativas razoavelmente eficientes podem ser alcançadas serão utilizados com menor freqüência. 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.]
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.]

Risco

[Definido pela equipe de desenvolvimento e baseado 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) do planejamento estimado da equipe de projetos.]

Estabilidade

[Definida pelo analista e pela equipe de desenvolvimento, baseia-se na probabilidade de que o recurso será alterado 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.]

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 permaneça no documento Visão, mas seja planejado para um release posterior.]

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

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

Relatórios e Medidas

[Descreva o conteúdo, o formato e o objetivo dos relatórios ou medidas solicitadas.]

Gerenciamento de Mudanças de Requisitos

Processamento e Aprovação de Controles de Mudanças

[Descreva o processo pelo qual os problemas e as alterações são enviados, revisados e dispostos. Isso deve incluir o processo de negociação de alterações de requisitos com clientes e os processos, atividades e restrições contratuais.]

CCB (Conselho de Controle de Mudanças)

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

Linhas de Base do Projeto

[As linhas de base fornecem um padrão oficial no qual o trabalho subseqüente está baseado e no qual são feitas apenas alterações autorizadas.

Descreva em que pontos durante o projeto ou o ciclo de vida do produto as linhas de base devem ser estabelecidas. As linhas de base mais comuns seriam no final das fases de Iniciação, Elaboração, Construção e Transição. As linhas de base também poderiam ser geradas no final de iterações nas várias fases ou até mesmo com maior freqüência.

Descreva quem autoriza uma linha de base e o que aparece nela.]

Atividades e Tarefas

[Descreva as atividades e as tarefas que se aplicam ao gerenciamento de requisitos.

Descreva as tarefas de revisão, incluindo objetivos, responsabilidades, sincronização e procedimentos da revisão.]

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 próprio Plano de Gerenciamento de Requisitos deve ser atualizado.]

Treinamento e Recursos

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

<Nome da Empresa>

<Nome do Projeto>	Versão: <1.0>
Plano de Gerenciamento de Requisitos	Data: <dd/mmm/aa>
<identificador do documento>

Confidencial	(<Nome da Empresa>, 2006	Página 8 de 2

Plano de Gerenciamento de Requisitos

<Nome do Projeto>

Luis Tadeu Castilho

2005-11-10

Rational

<Company Name>