Plano de Gerenciamento de Requisitos v1.0

Prévia do material em texto

PRESTÍGIO SISTEMAS 
 
 
ZIMMER – ALUGUEL DE QUARTOS 
Plano de Gerenciamento de Requisitos 
 
Versão 1.0 
 
 
<Nome do Projeto> Versão: 1.0 
Plano de Gerenciamento de Requisitos Data: 18/07/2017 
 
Confidencial @Prestígio Sistemas, 2017 Página 2 de 8 
 
Histórico da Revisão 
Data Versão Descrição Autor 
18/07/2017 1.0 Criação do Plano de Gerenciamento de 
Requisitos 
Juliane Frabel, 
Jefferson Duarte, 
Ronaldo Bonfim, Paulo 
Henrique Alipio, Alex 
da Silva 
 
<Nome do Projeto> Versão: 1.0 
Plano de Gerenciamento de Requisitos Data: 18/07/2017 
 
Confidencial @Prestígio Sistemas, 2017 Página 3 de 8 
 
Índice 
1. Introdução 4 
1.1 Objetivo 4 
1.2 Escopo 4 
1.3 Definições, Acrônimos e Abreviações 4 
1.4 Referências 4 
1.5 Visão Geral 4 
2. Gerenciamento de Requisitos 4 
2.1 Organização, Responsabilidades e Interfaces 4 
2.2 Ferramentas, Ambiente e Infra-estrutura 4 
3. O Programa de Gerenciamento de Requisitos Erro! Indicador não definido. 
3.1 Identificação de Requisitos 4 
3.2 Rastreabilidade 5 
3.2.1 Critérios para <item de rastreabilidade> 5 
3.3 Atributos 5 
3.3.1 Atributos para <item de rastreabilidade> Erro! Indicador não definido. 
3.4 Relatórios e Medidas 7 
3.5 Gerenciamento de Mudanças de Requisitos 8 
3.5.1 Processamento e Aprovação de Controles de Mudanças 8 
3.5.2 CCB (Conselho de Controle de Mudanças) 8 
3.5.3 Linhas de Base do Projeto 8 
3.6 Atividades e Tarefas 8 
4. Marcos 8 
5. Treinamento e Recursos 8 
<Nome do Projeto> Versão: 1.0 
Plano de Gerenciamento de Requisitos Data: 18/07/2017 
 
Confidencial @Prestígio Sistemas, 2017 Página 4 de 8 
 
Plano de Gerenciamento de Requisitos 
1. Introdução 
Este documento visa especificar o processo de gerenciamento de requisitos do Projeto Zimmer 
Aluguel de Quartos. 
1.1 Objetivo 
Descrever os atributos que serão utilizados para gerenciar os requisitos para o Projeto Zimmer – 
Aluguel de Quartos. Este documento também tem por objetivo esboçar a rastreabilidade de requisitos para 
manutenção do projeto durante o seu desenvolvimento. 
1.2 Escopo 
Este plano pertence a todas as fases do projeto. 
1.3 Definições, Acrônimos e Abreviações 
As definições, acrônimos e abreviações serão utilizadas conforme termos definidos na 
documentação do Rational Unified Process. 
1.4 Referências 
1. Rational Unified Process. 
 2. Caso de Desenvolvimento. 
1.5 Visão Geral 
Esse documento foi desenvolvido com para organizar o levantamento de requisitos para o 
Projeto Zimmer, onde o mesmo apresenta as etapas necessárias conforme o RUP. Dessa forma 
várias etapas abaixo serão estruturadas e desenvolvidas. O documento está organizado de 
forma a seguir a sequência do projeto. 
 
2. Gerenciamento de Requisitos 
2.1 Organização, Responsabilidades e Interfaces 
Ronaldo Bonfim – Organização 
 Paulo Henrique Valentim Alipio – Interfaces 
 Juliane Castro Frabel do Nascimento – Responsabilidades 
2.2 Ferramentas, Ambiente e Infraestrutura 
Será utilizado o Microsoft Word para documentar os requisitos, auxiliando no versionamento dos 
documentos. 
 Os documentos, artefatos e estrutura do projeto estarão disponíveis através do link: 
http://187.19.101.151:9051 onde serão disponibilizadas as versões mais atuais dos diagramas, 
protótipos e versões atualizadas. 
Para os diagramas utilizaremos o PowerDesign para o projeto. 
3. O Programa de Gerenciamento de Requisitos 
3.1 Identificação de Requisitos 
Elementos de projeto representados no PowerDesign. 
<Nome do Projeto> Versão: 1.0 
Plano de Gerenciamento de Requisitos Data: 18/07/2017 
 
Confidencial @Prestígio Sistemas, 2017 Página 5 de 8 
 
 
Produto de Trabalho 
(Tipo de Documento) 
Item de Rastreabilidade Descrição 
Visão (VIS) Necessidade dos Envolvidos 
(NEED) 
Necessidade principal do 
investidor. 
Modelo de Caso de 
Uso 
Caso de Uso (UC) Casos de uso para este release, 
documentados no PowerDesign 
Especificação 
Suplementar (SS) 
Requisito Suplementar (SUPP) Requisitos não funcionais que 
não são capturados no modelo de 
caso de uso. 
 
3.2 Rastreabilidade 
 
 
3.2.1 Critérios para Necessidades dos Envolvidos (NEED) 
As necessidades serão rastreadas para os casos de uso, e também poderão ser requisitos 
suplementares. 
3.2.2 Critérios para Casos de Uso (UC) 
Os casos de uso poderão ser rastreados para requisitos suplementares. 
3.2.3 Critérios para Requisito Suplementar (SUPP) 
Os requisitos suplementares serão estudados para implementação. 
3.3 Atributos 
3.3.1 Atributos para Requisitos de Caso de Uso 
Os requisitos de caso de uso serão gerenciados conforme os atributos abaixo. Esses atributos 
<Nome do Projeto> Versão: 1.0 
Plano de Gerenciamento de Requisitos Data: 18/07/2017 
 
Confidencial @Prestígio Sistemas, 2017 Página 6 de 8 
 
são para gerenciar os trabalhos de desenvolvimento, determinar o conteúdo da iteração. 
 
Status 
Os requisitos receberão o status após a negociação e serão revisados pela equipe de gerenciamento 
do projeto. Abaixo os status dos documentos de requisitos. 
Implementação O requisito recebe este status quando o mesmo está em fase de 
criação. 
Para validar O requisito recebe este status após o término de sua 
implementação (criação). 
Validado O requisito recebe este status após ele ser validado, completo e 
correto. 
Finalizado O requisito recebe este status após ser finalizado, não podendo ser 
alterado. 
Prioridade 
Definida pelo coordenador do projeto. Determina a prioridade do caso de uso conforme a 
importância do recurso de desenvolvimento para o caso de uso e da monitoração do progresso do 
desenvolvimento do caso de uso. 
 A prioridade normalmente tem como base o benefício percebido pelo usuário, o release 
planejado, iteração planejada, complexidade do caso de Uso (risco) e o esforço para 
implementação. 
Crítico Essa prioridade assegura que a implantação seja monitorada com 
maior atenção. Assim garantiremos que os recursos estão designados 
apropriadamente à tarefa. 
Importante Prioridade que garante a efetividade e eficácia do sistema para a 
maioria das funções. A funcionalidade não pode ser facilmente fornecida de 
outra forma. A falta de inclusão de um recurso importante pode afetar a 
satisfação do cliente ou até mesmo a receita, mas não atrasará a liberação. 
Útil Nenhum impacto Significante na receita ou na satisfação do cliente. 
Os recursos são úteis em aplicações menos comuns ou importantes, poderão ser 
usados com menos frequência, as soluções podem ser alternativas ou 
razoavelmente eficientes. 
 
 
<Nome do Projeto> Versão: 1.0 
Plano de Gerenciamento de Requisitos Data: 18/07/2017 
 
Confidencial @Prestígio Sistemas, 2017 Página 7 de 8 
 
Esforço 
 Como alguns recursos requerem mais tempo que outros, é necessário estimar o número 
de semanas ou de pessoas na equipe ou as linhas de código ou até mesmo os pontos de 
função, para assim calibrar a complexidade e ajustar a expectativas daquilo que pode ou não ser 
feito em determinado período. 
 Com isso é possível gerenciar o escopo na determinação das prioridades de 
desenvolvimento. 
Risco 
Os riscos dos requisitos serão definidos pela equipe de desenvolvimento nos seguintes níveis: 
 Alto – grande importância e impacto, complexidade alta ou tempo elevado de 
entrega. 
 Médio – média importância e impacto, complexidade média ou tempo médio de 
entrega. 
 Baixo – baixa importância e impacto, complexidade baixa ou tempo baixo de 
entrega. 
Estabilidade 
 Configurada pela equipede desenvolvimento conforme a probabilidade de esforço ou 
entendimento dos recursos necessários. Será usado para estabelecer as prioridades do 
desenvolvimento e também para definir o que não deverão ser extraídos. 
Liberação de Destino 
Apresenta a versão do produto que irá receber o recurso primeiro. Esse campo poderá ser utilizado 
para alocar os recursos a partir dos documentos visão em uma liberação específica de linha de base. 
Quando vinculada ao Status, a equipe pode registrar e discutir diversas liberações sem confirma-las no 
desenvolvimento. Deverão ser implantados apenas recursos cujo Status estiver definido como Finalizado e 
a liberação já tenha sido definida. O número da versão de liberação de destino (Release) pode ser 
aumentado para que o item permaneça no documento visão, mas deverá ser liberado posteriormente. 
Designado para 
Os recursos do projeto poderão ser designados às “equipes de recursos”, assim gravando esses 
recursos e implementação. Essas listas têm por função ajudar a todos dentro da equipe a entenderem melhor 
seu papel e função dentro do projeto. 
Motivo 
É utilizado para rastrear a origem do recurso solicitado. Esse campo deverá registrar ou fazer 
referência a uma explicação. Por exemplo, uma referência a uma página de outro documento, ou linha 
dentro do código ou até mesmo um marcador de minutos em um vídeo ou áudio da gravação da entrevista 
com o cliente. 
3.4 Relatórios e Medidas 
A Definir. 
<Nome do Projeto> Versão: 1.0 
Plano de Gerenciamento de Requisitos Data: 18/07/2017 
 
Confidencial @Prestígio Sistemas, 2017 Página 8 de 8 
 
3.5 Gerenciamento de Mudanças de Requisitos 
3.5.1 Processamento e Aprovação de Controles de Mudanças 
Toda alteração de requisitos deverá ser analisada o grau de alteração e o impacto da alteração pelo 
comitê de mudanças. 
3.5.2 CCB (Conselho de Controle de Mudanças) 
O comitê de aprovação de mudanças será composto pelo analista, gerente de projetos e um 
desenvolvedor. O comitê deverá analisar a mudança e tomar decisão se as mudanças serão ou não 
realizadas, em reuniões semanais. 
3.5.3 Linhas de Base do Projeto 
Existirá uma base line na fase inicial, duas na fase elaboração e uma na fase de construção 
3.6 Atividades e Tarefas 
 
4. Marcos 
 
5. Treinamento e Recursos