Skip to content

Plano de Gerenciamento dos Requisitos

MatheusRich edited this page Jan 30, 2018 · 1 revision

Histórico de modificações

Data Versão Descrição Autor
27/09/2017 0.1 Elaboração do Plano de Gerenciamento de Requisitos Lucas Martins

Sumário

  1. Introdução
  2. Requisitos
  3. Atributo dos Requisitos
  4. Rastreabilidade
    1. Matriz de rastreabilidade
  5. Técnicas de Elicitação
  6. Gerenciamento de mudanças nos requisitos
  7. Referências

1 - Introdução

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.

2 - Requisitos

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.

3 - Atributo dos Requisitos

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:

3.1 - Problema

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.

3.2 - Necessidades

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;

3.3 - Características

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;

3.4 - Requisitos Funcionais e Não-Funcionais

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;

3.5 - Caso de Uso

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

4 - Rastreabilidade

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:

  1. Problema

  2. Necessidade

  3. Característica

  4. Requisito

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

4.1 - Matriz de rastreabilidade

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

5 - Técnicas de Elicitação

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.

6 - Gerenciamento de mudanças nos requisitos

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

7 - Referências

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.

Falko

Cronograma Versão 3


Acesso à aplicação


Equipe

Release 02

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5

Sprint 6

Sprint 7

Sprint 8

Sprint 9

Release 01

Gerenciamento do Projeto

Artefatos de Desenvolvimento

Encerramento

Clone this wiki locally