-
Notifications
You must be signed in to change notification settings - Fork 7
Plano de Gerenciamento de Requisitos
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 |
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.
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.
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.
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).
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:
Ferramenta utilizada: https://www.draw.io/
-
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).
- ✅ #UC1 - Visualizar Caderno
- ✅ #UC2 - Manter atividade
- ✅ #UC3 - Manter Caderno
- ✅ #UC4 - Gerar E-book
- ✅ #UC5 - Manter usuário
-
Sprints
- Sprint 00
- Sprint 01
- Sprint 02
- Sprint 03
- Sprint 04
- Sprint 05
- Sprint 06
- Sprint 07
✅ Finalizado ☑️ Não finalizado