Plano de Gerenciamento Requisitos

1 - Introdução

Este documento tem como objetivo descrever como será gerenciado os requisitos do projeto quero cultura Para que este objetivo seja alcançado é necessário, estabelecer rastreabilidade, escolher atributos de requisitos.

2 - Requisitos

Dentro do contexto do projeto os requisitos serão classificados em 5 níveis de rastreabilidade, sendo eles: , Necessidades 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

Requisitos não são determinados apenas pelas suas especificações e detalhes do que é extraído do cliente, mas também por um conjunto de informações a respeito deles, os quais permitem uma melhor interpretação e entendimento, essas informações são definidas como atributos de rastreabilidade de requisitos.

• Risco
• Benefício
• Esforço
• Prioridade
• Status

3.1 - Necessidades

As Necessidades são requisitos que visam atender a demanda para resolver o problema proposto:

• identificador: NE_# , onde # é o numero atribuído aquela necessidade

• Nome: nome do requisito;

• Descrição: informação resumo da necessidade;

• Contexto atual: soluções atuais da necessidade;

3.2 - 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: Os Requisitos Funcionais mapeiam as características do sistema em funcionalidades requeridas que derivarão ações a serem executadas.

• Identificador : RNF_# , onde # é o numero atribuído ao requisito não funcional

• Nome: Nome do requisito;

• Descrição: Descrição do requisito;

• Identificador : RF_# , onde # é o numero atribuído ao requisito não funcional

• Nome: Nome do requisito;

• Descrição: Descrição do requisito;

3.3 - 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: UC_# , onde # é o numero atribuído ao requisito não funcional

• 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

Rastreabilidade pode ser definida como sendo a técnica usada para promover relacionamento entre requisitos, arquiteturas e implementação final do sistema (Edwards, 1991). Ela auxilia na compreensão dos relacionamentos existentes entre requisitos do software ou entre artefatos de requisitos, arquitetura e implementação. Esses relacionamentos permitem aos projetistas mostrar que o projeto atende aos requisitos. A rastreabilidade também apóia a detecção precoce daqueles requisitos não atendidos pelo software (Palmer, 1997). A rastreabilidade de

1. Necessidade

2. Requisito não funcional

3. Caso de uso

A Rastreabilidade de Requisitos também é definida como a capacidade de descrever e seguir o ciclo de vida de um requisito em ambas as direções: na capacidade de rastrear um artefato em direção à sua implementação (forward traceability); ou na capacidade de rastrear um artefato à sua origem (backward traceability); passando entre todas as especificações relatadas (GOTEL, 1994).

Dessa forma é possível montar uma matriz de rastreabilidade sabendo a quais níveis superiores cada UC pertence.

4.1 - Matriz de rastreabilidade

A matriz de rastreabilidade seguira o modelo a seguir:

-	Necessidade 1	Necessidade 2
Caso de Uso 1	X
Caso de Uso 2		X

5 - Técnicas de Elicitação

Para se fazer p levantamento dos requisitos serão utilizadas as seguintes tecnicas:

Tecnica	Descrição
Brainstorming	Brainstorming é uma técnica de grupo utilizada para criar novas ideias para o projeto e/ou encontrar soluções para um problema específico, além de possibilitar o diagnóstico de problemas em pouco tempo. São conduzidos como uma conferência reunindo de seis a dez membros, onde cada membro tem o direito de explanar suas ideias em um certo período de tempo. Esta reunião possui um mediador, que define a questão a ser discutida (GUNDA, 2008).
Entrevista	Este método tem como objetivo descobrir fatos e opiniões de stakeholders sobre o sistema em desenvolvimento (PAETSCH, 2003). É muito popular e considerado como uma técnica importante para obter e validar requisitos. A entrevista consiste em uma conversa face a face onde se discute com diferentes tipos de stakeholders, buscando entender os requisitos do sistema e seus objetivos para solucionar o problema.

6 - Gerenciamento de mudanças nos requisitos

Os requisitos serão mantidos da seguinte forma de acordo com a ordem hierarquica :Necessidade>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. Segundo a tabela a baixo serão avaliados os impactos dessas mudanças no projeto

Nível	Impacto no projeto
Necessidade	Alto
Requisito não funcional	Médio
Caso de uso	Baixo

7 - Referências

modelo de plano seguido:

GOTEL, l O. e Finkelstein C. (1994) “An analysis of the requirements traceability problem”, Proceedings of the First International Conference on Requirements Engineering (IEEE).

GUNDA, S. G. Requirements Engineering: Elicitation Techniques. Trollhättan, Suécia: 2008. 38 p.

PAETSCH, F. Requirements Engineering in Agile Software Development. Calgary: 2003. 72p.

PALMER , J.D "Traceability". In: Software Requeriments Eng., R.H. Thayer and M. Dorfman, eds., 1997. pp. 364-374

Edwards, M & Howell, S., "A Methodology for System Requeriments Specification and Traceability for Large Real-Time Complex Systems", tecnical report, U.S Naval Surface Warface Centrer-Dahlgren Division, Dahlgren, Va., 1991