-
Notifications
You must be signed in to change notification settings - Fork 18
Plano de Gerenciamento dos Requisitos
Data | Versão | Descrição | Autor |
---|---|---|---|
27/09/2017 | 0.1 | Elaboração do Plano de Gerenciamento de Requisitos | Lucas Martins |
- Introdução
- Requisitos
- Atributo dos Requisitos
- Rastreabilidade
- Técnicas de Elicitação
- Gerenciamento de mudanças nos requisitos
- Referências
Este documento tem como objetivo descrever todo gerênciamento dos requisitos do projeto, desde a coleta até a implementação do mesmo. Para que este objetivo seja alcançado é necessário, estabelecer rastreabilidade, escolher atributos de requisitos e por fim a elaboração do plano.
Dentro do contexto do projeto os requisitos serão classificados em 5 níveis de rastreabilidade, sendo eles: Problema, Necessidades, Características, Requisitos Funcionais e Não-Funcionais e por fim Casos de Uso.
Ao chegar no nivel dos casos de uso é possível notar que cada UC define uma sequência de ações realizadas pelo sistema e que produzem um resultado de valor observável para determinado ator.
Para controlar as informações associadas a um item de rastreabilidade são usados os atributos de requisitos. Os atributos que srão usados no projeto são:
-
Risco
-
Benefício
-
Esforço
-
Estabilidade
-
Impacto na Arquitetura
Além disso, cada cama de requisito possui atributos que são usados para descrição dos requisito. Segue abaixo a definição de cada um deles:
Dentro do contexto do projeto, os Problemas são o nível mais alto de requisito. Os Problemas geralmente descrevem um contexto indesejado que levou à demanda de uma solução de software. Sua documentação deve conter os seguintes campos:
-
Identificador: deve-se usar a sigla PB + número do requisito de acordo com a sequência crescente dos identificadores.
PB n
-
Nome: nome do requisito;
-
Descrição: descrição do problema;
-
Partes afetadas:
-
Impactos: os impactos identificados no qual o problema causa se não for solucionado.
As Necessidades são requisitos potenciais, que visam com a sua completude sanar um determinado problema. Sua documentação deve conter os seguintes campos:
- Identificador: deve-se usar a sigla NE + número do requisito de acordo com a sequência crescente dos identificadores.
NE n
- Nome: nome do requisito;
- Descrição: informação resumo da necessidade;
- Contexto atual: soluções atuais da necessidade;
A Característica é o requisito onde podem ser definidos os elementos e atributos que compõem uma solução de software, baseado nas necessidades a serem atendidas. Sua documentação deve conter os seguintes campos:
- Identificador
Deve-se usar a sigla CA + número do requisito de acordo com a sequência crescente dos identificadores.
CA n
- Nome
Nome do requisito;
- Descrição
Descrição do requisito;
Os Requisitos Funcionais mapeiam as características do sistema em funcionalidades requeridas que derivarão ações a serem executadas, ou em atributos não funcionais que caracterizam o sistema. Sua documentação deve conter os seguintes campos:
- Identificador
Para identificação de Requisitos Funcionais deve-se usar a sigla RF + número do requisito de acordo com a sequência crescente dos identificadores. Para identificação de Requisitos Não-Funcionais deve-se usar a sigla RNF + número do requisito de acordo com a sequência crescente dos identificadores.
RE n
- Nome
Nome do requisito;
- Descrição
Descrição do requisito;
O Caso de Uso é o nível mais baixo dentro da rastrabilidade de requisitos desenvolvida no projeto, estes requisitos podem ser caracterizados dentro do sistema como ações a serem realizadas por um determinato Ator. A Documentação dos UC devem ser feitas da seguinte forma:
- Identificador
Deve-se usar a sigla UC + número do requisito de acordo com a sequência crescente dos identificadores.
UC n
-
Descrição
-
Ator Principal
-
Condições
- Pré-Condições
- Pós-Condições
-
Fluxo de Eventos
- Fluxo Básico
- Fluxo Alternativo
- Fluxo de Exceção
A rastreabilidade serve para rastrear um elemento do projeto com outros elementos correlatos. Para compreender a origem dos requisitos, cada requisito terá uma chave de identificação de acordo com:
-
Problema
-
Necessidade
-
Característica
-
Requisito
-
Caso de uso
Dessa forma é possível montar uma matriz de rastreabilidade sabendo a quais níveis superiores cada UC pertence. Um requisito pode ter relação hierarquica com mais de um requisito, ou seja, um caso de uso pode estar associado a mais de um requisito.
Há também a possibilidade de um requisitor ter relação de dependência com outros requisitos, neste caso os requisitos mais prioritários devem ser implementados primeiro.
Para a elaboração da matriz de rastreabilidade deve-se elaborar uma tabela no qual, a linha será o requisito no nível hierárquico mais baixo e nas colulas os de nível hierárquico mais alto.
Problema 1 | Problema 2 | |
---|---|---|
Necessidade 1 | X | |
Necessidade 2 | X |
Para conseguir extrair os requisitos do cliente as seguintes técnicas de elicitação de requisitos serão utilizadas:
Brainstorming | Todos os envolvidos devem expressar tudo o que acham importante para o projeto por um curto período de tempo, cerca de 15 minutos. Após todos os participantes exporem suas ideias, um facilitador conduz o grupo para priorização dos resultados. |
Entrevista | Com a aplicação de entrevistas é possível ter certeza da informação que se deseja alcançar, logo as perguntas devem ser elaboradas com o objetivo de extrair informações do entrevistado. |
Os requisitos são mantidos de acordo com a hierarquia: Problema>Necessidade>Característica>requisito>Caso de uso. Tanto os clientes quanto as equipes do projeto podem identificar possíveis mudanças nos requisitos do projeto em qualquer nível da hierarquia. De acordo com a tabela abaixo, as mudanças devem ser avaliadas e classificadas.
Nível | Impacto no projeto |
---|---|
Problema | Altíssimo |
Necessidade | Alto |
Característica | Alto |
Requisito | Médio |
Caso de uso | Baixo |
Atividade: Desenvolver Plano de Gerenciamento de Requisitos. RUP, 2001.
Artefato: Caso de Uso. RUP, 2001.
Conceitos: Rastreabilidade. RUP, 2001.
Detalhamento do Fluxo de Trabalho: Analisar o Problema. RUP, 2001.
Orientações de Trabalho: Brainstorming e Filtro de Idéias. RUP, 2001.
- Folha de Estilo
- Esquema de Cores
- Como Usar o Docker
- O Padrão Adapter
- Links e Comandos Úteis
- O Padrão Observer
- Product Backlog
- Quadro Kanban
- Priorização das Histórias
- Sistema de Pontuação
- EVM Agile
- Roadmap
- Post Mortem - Release II
- Termo de Abertura do Projeto
- Plano de Gerenciamento do Projeto
- Plano de Gerenciamento do Escopo
- Plano de Gerenciamento de Requisitos
- Plano de Gerenciamento de Tempo
- Plano de Gerenciamento das Partes Interessadas
- Plano de Gerenciamento de Comunicação
- Plano de Gerenciamento das Aquisições
- Plano de Gerenciamento de Recursos Humanos
- Plano de Gerenciamento dos Riscos
- Plano de Gerenciamento de Configuração de Software
- Plano de Gerenciamento da Qualidade
- Plano de Gerenciamento dos Custos