Wylie College
Plano de Gerenciamento de Requisitos
Versão 2.0
Histórico da Revisão
|
Data |
Versão |
Descrição |
Autor |
|---|---|---|---|
|
08/Jan/1999 |
1.0 |
Release Inicial |
Simon Jones |
|
10/Fev/1999 |
2.0 |
Plano de Extensão |
Simon Jones |
|
|
|
|
|
|
|
|
|
|
Índice
1.3 Definições, Acrônimos e Abreviações
2. Gerenciamento de Requisitos
2.1 Organização, Responsabilidades e Interfaces
2.2 Ferramentas, Ambiente e Infra-estrutura
3. O Programa de Gerenciamento de Requisitos
3.1 Identificação de Requisitos
3.2.1 Critérios para Requisitos do Produto
3.2.2 Critérios para Requisitos de Caso de Uso
3.2.3 Critérios para Casos de Teste
3.3.1 Atributos para Requisitos de Caso de Uso
3.3.2 Atributos para Casos de Teste
3.5 Gerenciamento de Mudanças de Requisitos
Plano de Gerenciamento de Requisitos
As Diretrizes de Atributos de Requisitos identificam e descrevem os atributos que serão utilizados para gerenciar os requisitos para todos os projetos de software do Wylie College. Além disso, este documento esboça a rastreabilidade de requisitos que será mantida em projetos durante o desenvolvimento.
Os atributos designados a cada requisito serão utilizados para gerenciar o desenvolvimento do software e para priorizar os recursos para cada release.
O objetivo da rastreabilidade de requisitos é reduzir o número de defeitos localizados no final do ciclo de desenvolvimento. Assegurar que todos os requisitos do produto sejam capturados nos requisitos do software, no design e nos casos de teste aprimora a qualidade do produto.
As diretrizes de rastreabilidade e atributos neste documento são aplicadas aos requisitos do produto, aos requisitos de software e aos requisitos de teste para todos os projetos de software do Wylie College.
Utilizamos os termos definidos na documentação do Rational Unified Process e do Rational RequisitePro.
As seguintes referências podem ser encontradas no Web site de Processo de Software do Wylie College.
1. Plano de Gerenciamento de Configuração do Wylie College.
2. Rational Unified Process.
3. Caso de Desenvolvimento do Wylie College
Abrangidas pelo Plano de Desenvolvimento de Software do projeto individual.
O Rational RequisitePro será utilizado para gerenciar os atributos de requisitos e a rastreabilidade. Outros detalhes de infra-estrutura são abrangidos no Web site de Processo de Software do Wylie College.
Cada projeto irá identificar e gerenciar os seguintes tipos de requisitos:
| Produtos de Trabalho
|
Tipo de Requisito |
Descrição |
|---|---|---|
|
Visão |
Requisitos do Produto |
Recursos do produto, restrições, intervalos de qualidade e outros requisitos do produto. |
|
Modelo de Caso de Uso |
Caso de Uso |
Casos de Uso, documentados no Rational Rose |
|
Plano de Teste |
Casos de Teste |
Casos que descrevem como verificaremos se o sistema se comporta como esperado. |
Os requisitos de produto definidos no Documento de Visão serão rastreados para o caso de uso ou requisitos complementares correspondentes nas Especificações de Caso de Uso e para a Especificação Complementar.
Cada requisito de produto é rastreado para 1 ou mais requisitos de caso de uso e requisitos complementares.
Cada requisito de produto é rastreado para 1 ou mais requisitos de caso de uso e requisitos complementares.
Os requisitos de caso de uso definidos nas Especificações de Caso de Uso e na Especificação Complementar serão rastreados para os casos de teste correspondentes especificados no Plano de Teste.
Cada requisito de caso de uso é rastreado para 1 ou mais casos de teste do sistema.
Os casos de teste especificados no Plano de Teste são rastreados de volta para os requisitos de produto (a partir da Visão) e para os requisitos de caso de uso que estão sendo verificados pelo caso de teste específico.
Um caso de teste pode ser rastreado de volta para 1 ou mais requisitos de caso de uso e produto. No caso em que o caso de teste está verificando um requisito derivado ou o design, o caso de teste pode não ter rastreabilidade de volta aos requisitos originais do produto ou aos requisitos do caso de uso.
Os requisitos de caso de uso e a Especificação Complementar serão gerenciados utilizando os atributos definidos nesta seção. Esses atributos são úteis para gerenciar o esforço de desenvolvimento, determinar o conteúdo da iteração e associar casos de uso a seus modelos Rose específicos.
Definido depois que a análise faz o rascunho dos casos de uso. Rastreia o progresso do desenvolvimento do caso de uso desde o rascunho inicial do caso de uso até a validação final do caso de uso.
|
Proposto |
Os Casos de Uso que foram identificados, porém ainda não revisados e aprovados. |
|---|---|
|
Aprovado |
Casos de Uso aprovados para design e implementação adicionais. |
|
Validado |
Casos de Uso que foram validados em um teste do sistema. |
Definida pelo Coordenador de Projeto. Determina a prioridade do caso de uso em termos da importância da designação de recursos de desenvolvimento para o caso de uso e da monitoração do progresso do desenvolvimento do caso de uso. A prioridade normalmente tem como base o benefício percebido pelo usuário, o release planejado, a iteração planejada, a complexidade do caso de uso (risco) e o esforço para implementar o caso de uso.
|
Alto |
O Caso de Uso tem alta prioridade relativa para assegurar que a implementação do caso de uso é monitorada com atenção e que os recursos estão designados apropriadamente à tarefa. |
|---|---|
|
Médio |
O Caso de Uso tem média prioridade relativa a outros casos de uso. |
|
Baixo |
O Caso de Uso tem baixa prioridade. A implementação desse caso de uso é menos crítica e pode ser substituída ou replanejada para iterações ou releases subseqüentes. |
Definido pela equipe de desenvolvimento. Como alguns casos de uso requerem mais tempo e recursos 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 forma de medir a complexidade e definir as expectativas do que pode ou não ser realizado em um determinado prazo. Utilizado no gerenciamento do escopo e na determinação da prioridade do desenvolvimento. O Coordenador de Projeto utiliza essas estimativas de esforço para determinar o planejamento do projeto e para planejar efetivamente os recursos das tarefas.
Estimativa de esforço em Dias por Pessoa (suponha 7,5 horas em um dia útil).
Definido pela equipe de desenvolvimento com base na probabilidade de que o caso de uso tenha eventos não desejados, tais como excessos de esforço, falhas de design, alto número de defeitos, qualidade ruim, desempenho ruim etc. Eventos não desejados como esses normalmente são resultado de requisitos mal entendidos ou definidos, conhecimento insuficiente, falta de recursos, complexidade técnica, nova tecnologia, novas ferramentas ou novos equipamentos.
Os projetos do Wylie College irão categorizar os riscos técnicos de cada caso de uso como alto, médio ou baixo.
|
Alto |
O impacto do risco combinado com a probabilidade de ocorrência do risco é alto. |
|---|---|
|
Médio |
O impacto do risco é menos grave e/ou a probabilidade de ocorrência do risco é menor. |
|
Baixo |
O impacto do risco é mínimo e a probabilidade de ocorrência do risco é baixa. |
Iteração de Desenvolvimento de Destino
Registra a iteração de desenvolvimento na qual o caso de uso será implementado. É previsto que o desenvolvimento para cada release será executado por várias iterações de desenvolvimento durante a Fase de Construção do projeto.
O número da iteração designado a cada caso de uso é utilizado pelo Coordenador de Projeto para planejar as atividades da equipe do projeto.
Os valores possíveis estarão no formato <letra>-<número da iteração> em que letra é I, E, C, T para iniciação, elaboração, construção e transição, respectivamente. Por exemplo:
|
E-1 |
Planejado para Fase de Elaboração, Iteração 1 |
|
C-1 |
Planejado para Fase de Construção, Iteração 1 |
|
C-2 |
Planejado para Fase de Construção, Iteração 2 |
|
C-3 |
Planejado para Fase de Construção, Iteração 3 |
Os casos de uso são designados a indivíduos ou equipes de desenvolvimento para análise, design e implementação adicionais. Uma lista de opções simples ajudará todos na equipe do projeto a melhor entender as responsabilidades.
Identifica o modelo de caso de uso Rose associado ao requisito de caso de uso.
Definido pelo Líder do Teste. Rastreia o status de cada caso de teste.
|
Não Testado |
O Caso de Teste não foi executado. |
|---|---|
|
Falhou |
O teste foi conduzido e falhou. |
|
Aprovação Condicional |
O teste foi concluído com problemas. O status designado do teste foi Aprovado com a condição de que algumas ações sejam concluídas. |
|
Aprovado |
O teste foi concluído com êxito. |
Registra o build do sistema no qual o caso de teste específico será verificado.
Indivíduo designado para executar e verificar o caso de teste. Essa lista de opções simples ajudará todos na equipe do projeto a melhor entender as responsabilidades.
Data planejada do teste ou data real do teste.
Quaisquer notas associadas ao planejamento ou execução do teste.
A Definir
Consulte o Plano de Gerenciamento de Configuração do Wylie College.
Consulte o Caso de Desenvolvimento do Wylie College.
Isso está descrito no Plano de Desenvolvimento de Software de cada projeto.
Isso está descrito no Plano de Desenvolvimento de Software de cada projeto.