Skip to content

Plano de Gerenciamento Requisitos

Josue Nascimento edited this page Sep 27, 2017 · 5 revisions
Data Versão Descrição Autor
02/09/2017 1.0 Primeira versão completa do documento Josué Nascimento da Silva

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 3 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

Clone this wiki locally