Skip to content

Plano de Gerenciamento de Requisitos

Phelipe Wener edited this page Apr 2, 2017 · 12 revisions

Histórico de Revisão

Data Versão Modificação Autor
21/03/2017 0.0.1 Criação do documento Filipe Ribeiro
21/03/2017 0.0.2 Adicionando Introdução Filipe Ribeiro
21/03/2017 0.0.3 Adicionando Processo de Coleta Filipe Ribeiro
22/03/2017 0.0.4 Adicionando Rastreabilidade Filipe Ribeiro

1. Introdução

Requisitos são uma parte fundamental de qualquer projeto que envolva o desenvolvimento de algum produto. São eles os responsáveis por fornecer características, restrições e todas as outras particularidades do produto. Em desenvolvimento de projetos de Software as coisas não são diferentes, os requisitos devem mostrar como o Software deve se comportar, funcionalidades do mesmo, como deve ser o desempenho dele etc.

Tendo em mente que Requisitos são fatores primordiais para o sucesso de um projeto, eles merecem um cuidado especial no que se refere a seu gerenciamento. Deste modo, esse plano têm como objetivo descrever como os requisitos serão analisados, documentados e gerenciados.

2. Processo de coleta e de documentação dos requisitos

Levando em conta que existem pessoas externas ao desenvolvimento interessadas no bom andamento do projeto, os chamados stakeholders, faz-se necessário que seja estabelecida uma interação com os mesmos para elicitação dos requisitos, assumindo os mesmos como clientes, pessoas com interesse no produto final.

Para coletar esses requisitos, se faz necessário o uso das chamadas técnicas de elicitação. Para melhor definir a técnica a ser utilizada, deve-se estudar as técnicas que se encaixam melhor de acordo com a interação entre a equipe e o cliente e de acordo com os níveis de conhecimento e de abstração dos requisitos a serem obtidos (FALBO, 2012).

Serão realizadas entrevistas para elicitação de requisitos, visto que esse tipo de técnica permite uma compreensão das necessidades e dos requisitos em visões mais específicas, e em um menor nível de abstração. No contexto deste projeto é uma boa técnica dada a interação que foi estabelecida com os clientes.

As entrevistas podem ser fechadas, abertas ou mistas. As entrevistas fechadas possuem perguntas predefinidas. Já nas entrevistas abertas as perguntas são criadas de acordo com os tópicos explorados. As entrevistas mistas combinam os dois tipos, ou seja, algumas perguntas são definidas anteriormente e de acordo com os assuntos levantados nas reuniões novas perguntas são criadas (SOMMERVILLE, 2007).

Serão realizadas entrevistas mistas, pois como esta técnica será combinada com outras duas, algumas perguntas podem ser predefinidas baseadas nas elicitações realizadas anteriormente e há a possibilidade de criação de novas perguntas.

Brainstorming é uma técnica para geração de idéias. Ela consiste em uma ou várias reuniões que permitem que as pessoas sugiram e explorem idéias (BEDANI, 2008). Essa técnica será utilizada em conjunto com a entrevista.

3. Gerenciamento de priorização e configuração dos requisitos

A priorização de requisitos têm como objetivo apontar quais requisitos são os mais cruciais no que se refere ao bom andamento do projeto, aqueles que possuem maior complexidade, maior valor para o cliente, que demandam maior esforço para o desenvolvimento etc. Todas essas características devem ser levadas em conta para o processo de priorização de requisitos.

Com os requisitos já definidos e priorizados, se faz necessário a criação de uma forma de manter o rastreio de requisitos de modo que seja possível identificar quais requisitos se comunicam entre si tendo como base a hierarquia de Problema -> Necessidade -> Característica -> Casos de uso, onde o requisito de mais alto grau de abstração é o Problema e os Casos de Uso podem ser considerados os de mais baixo grau hierárquico.

Para estabelecer uma forma eficiente de rastreabilidade, foram criadas siglas para a já citada hierarquia de requisitos acompanhado de um identificador. Portanto as Necessidades serão identificadas como N, as Características como C e os Casos de Uso como UC.

Para gerenciar a rastreabilidade dos requisitos, vamos utilizar os seguintes padrões de código:

  • Necessidade [Nx]
  • Características [Cy]
  • Casos de uso [UCz]

Tal que (x, y, z) representa o código do requisito.

4. Matriz de Rastreabilidade

A matriz de rastrabilidade de requisitos é uma tabela que liga os requisitos de produto desde as suas origens até as entregas que os satisfazem(PMI, 2013).

4.1 Versão 1

Primeira matriz de rastreabilidade

4.2 Versão 2

Segunda matriz de rastreabilidade

5. Gerenciamento de Mudanças de Requisitos

Como em qualquer artefato, os requisitos do projeto podem mudar, para tal deve-se tomar algumas medidas para controlar bem essas mudanças. Primeiramente, será mantida a Baseline da matriz de rastreabilidade nos tópicos acima, de forma que seja possível mostrar grandes mudanças em interdependências dos requisitos.

Quando surgir mudanças em qualquer requisito dos listados na matriz de rastreabilidade, os seguintes procedimentos devem ser tomados:

Processo de mudança

Ferramenta utilizada: https://www.draw.io/

6. Referências Bibliográficas

  • FALBO, R. A. Engenharia de Requisitos: Notas de Aula. UFES - Universidade Federal do Espírito Santo. 2012.

  • SOMMERVILLE, I. Engenharia de Software, 8ª. edição. Capítulo 7. 2007.

  • BEDANI, Janaína. Revista engenharia de software Edição nº 2. Rio de Janeiro; 2009. Intodução a abordagens de identificação de requisitos. p 54-58.

  • PMI. Um guia do conhecimento em gerenciamento de projetos. Guia PMBOK 5a.ed. EUA: Project Management Institute, 2013. Program evaluation and review technique. (2017, March 1).

Release 01

Artefatos de Gerência

Planos de Projeto

Artefatos de Desenvolvimento

Casos de Uso

Casos de Teste

Protótipo

Cliente

Apresentação

Release 2

Planejamento

Fechamento

Legenda

✅ Finalizado ☑️ Não finalizado

Clone this wiki locally