Plano de Gerenciamento de Requistos

Prévia do material em texto

Universidade Tecnológica Federal do Paraná
Campus Cornélio Procópio
MBA em Engenharia de Software – Turma III
Disciplina: CEES-MBA04 - Gestão de Requisitos de Software
Docente: Flávia Belintani Blum Haddad
Discente: Luana de Quadros
Data: 03/07/2020
Atividade: Criar um documento que especifique quais as atividades do processo de requisitos devem ser executas em um projeto, documentos que serão gerados, modelos de documentos que devem ser considerados para a realização das atividades de requisitos (se houver), técnicas utilizadas para elicitação, negociação, priorização e rastreabilidade dos requisitos, ferramentas de apoio e responsáveis (papéis) para o gerenciamento dos requisitos.
	Plano de Gerenciamento de Requisitos	
1. Objetivo
Esta especificação de plano de gerenciamento de requisitos tem como principal objetivo descrever todas as atividades do processo de requisitos que devem ser executas em um projeto, documentos que serão gerados, modelos de documentos que devem ser considerados para a realização das atividades de requisitos, técnicas utilizadas para elicitação, negociação, priorização e rastreabilidade dos requisitos, ferramentas de apoio e envolvidos com seus respectivos papéis e responsabilidades para o gerenciamento dos requisitos.
2. Principais atividades
	2.1 Controle de mudanças
· Propor mudanças
· Analisar impactos
· Tomar decisões
· Atualizar documentos de requisitos
· Atualizar plano de projeto 
2.2 Controle de mudanças
· Definir o esquema de identificação de versão
· Identificar versão do documento de requisitos
· Identificar versão de cada requisito
2.3 Acompanhar o estado de requisito
· Definir possíveis estados para um requisito
· Armazenar o estado de cada requisito
· Documentar os estados de todos os requisitos
2.4 Rastrear requisitos
· Definir ligações com outros requisitos
· Definir ligações com outros elementos
3. Etapas do ciclo de vida da gerencia de requisitos
	3.1 Elicitação de requisitos
		3.1.1 Objetivo: As necessidades dos clientes, o domínio e restrições do negócio devem ser detectados, com o objetivo de fornecer o mais correto entendimento do que é
esperado do sistema de software a ser produzido. Podem ser utilizadas as seguintes técnicas para elicitação de requisitos: Descoberta de requisitos (pontos de vista); Entrevistas; Cenários; Casos de uso; Etnografia.
		3.1.2 Artefato: Caso de uso
	3.2 Análise e negociação de requisitos
		3.2.1 Objetivo: Após a elicitação dos requisitos do sistema, segue-se à etapa de análise dos requisitos e negociação que tem como objetivo classificar, resolver conflitos de negociação, priorizar e confirmar a completude dos requisitos, sua consistência e validade (de acordo com o que se pretende do sistema. 
		3.2.2 Boas práticas de negociação
· Evitar embates pessoais, remetendo a sua resolução para mais tarde, fora da reunião, de preferência nunca tomando partido;
· fomentar a justificação das posições tomadas pelos intervenientes na negociação;
· encontrar e salientar os benefícios que uma solução apresenta para todos os envolvidos;
· relaxar restrições, buscando o consenso.
		3.2.3 Artefato
	3.3 Documentação de requisitos
		3.3.1 Objetivo: Os requisitos devem ser documentados a fim de servir de base para o restante do processo de desenvolvimento. O documento abrange os requisitos de usuário, requisitos de domínio e requisitos do sistema, deve conter todas as definições de requisitos, deve ser clara e concisa para que todos os envolvidos possam compreender
o seu teor, deve conter o entendimento dos stakeholders e as negociações realizadas e tem como público-alvo clientes, usuários, gerentes e desenvolvedores.
		3.3.2 Artefato
	3.4 Validação de requisitos
		3.4.1 Objetivo: É o estágio final da engenharia de requisitos. Concentra-se na checagem final da documentação de requisitos e na resolução dos requisitos que estão incompletos ou inconsistentes. Procura responder se os requisitos levantados estão ou não corretos e verifica se os requisitos definem o sistema que o cliente realmente deseja. A validação dos requisitos é importante para garantir que as necessidades dos clientes sejam atendidas e pode ajudar a diminuir ou a evitar o custo com erros de requisitos. E a não validação dos requisitos pode acarretar em implementação de requisitos incompletos. 
A validação de requisitos pode ser feita confrontando os artefatos versus casos de uso, interfaces versus casos de uso ou via execução de checklists.
		3.4.2 Ferramenta: Ferramenta indicada para construção do mockup (protótipo navegável) para validação dos requisitos considerando os casos de uso descritos. (https://www.invisionapp.com/ ). Isso permitirá determinar se as necessidades dos usuários e da aplicação estão sendo atendidas antes
que os próximos processos possam utilizar as interfaces.
3.4.3 Artefato: 
4. Papéis e reponsabilidades
 Página | 1
Template - Lista 
caso de uso .odt
Template - 
Documento inicial de Requisitos.docx
	Documento Inicial de Requisito
	
	
	Revisão: 05
	Data: 03/07/2020
Família de Sistemas: SAJ
Sistema: SG5
	
	Julho / 2020
	
1. Introdução
Este documento objetiva criar funcionalidade para evolução do software
2. Envolvidos 
	Nome
	Cargo e Instituição
	E-mail
	Luana de Quadros
	Analista de Sistemas 
	
	Elmo Vendrame
	Analista de Negócios
	
3. Escopo
3.1 Necessidades
O sistema deve ...
3.2 Características a Serem Atendidas
3.3 Impacto
3.4 Restrições 
Sem restrições.
4. Fora de Escopo
Não se aplica. 
5. Revisões
	Descrição
	Versão
	Data
	Autor
	Elaboração do documento
	1
	03/07/2020
	Luana de Quadros
Template - Regra 
de Negocio_ERS.docx
Universidade Tecnológica Federal do Paraná
Campus Cornélio Procópio
MBA em Engenharia de Software – Turma III
ERS - Especificação de Requisitos de Software
Índice
1. Introdução	1
2. Requisitos Funcionais	1
3. Requisitos Não funcionais	2
4. Requisitos de Negócio	2
5. Versão	2
1. Introdução
Descreve qual é o objetivo/ação que a especificação irá realizar para um determinado software ou uma funcionalidade do software. 
2. Requisitos Funcionais
Descrevem ações que o sistema irá executar (funcionalidades do sistema)
2.1. Requisito funcional 
“Ex.: O sistema deve permitir a emissão de documentos para processos sem partes relacionadas.”
2.2. Validação de emissão de documento
“Ex.: Caso não tenha parte relacionada ao documento o sistema emite uma mensagem de orientação.”
3. Requisitos Não funcionais
Expressam restrições que o software deve atender a qualidade específicas que o software deve possuir.
3.1 Usabilidade 
“Facilidade de aprender: Associado ao tempo e esforço mínimo exigido para alcançar um determinado nível de desempenho no uso do sistema.”
3.2 Confiabilidade
“Operação do software: Probabilidade de o software não causar uma falha no sistema durante um determinado período de tempo sob condições especificadas.”
3.3 Desempenho
“Operação desejada no software: Ex.: Tempo limite para processamento de todos os lotes de fatura na rotina diária”
3.4 Reusabilidade
“Reutilização de componentes: Componentes que já tenham sido desenvolvidos e testados podem ser reutilizados”
3.5 Segurança
“Segurança de dados: É assegurada a integridade do sistema quanto a ataques intencionais ou acidentes. Ex.: Autenticação de usuário para consumo de webservices do sistema por sistemas externos”
3.6 Portabilidade
“Facilidade do software: o software é dito portável se ele pode ser executado em ambientes distintos.”
3.7 Manutenibilidade
“Manutenção do software: modificações feitas após o sistema de software ter sido disponibilizado para uso”
4. Requisitos de Negócio
“As regras de negócio definem como o sistema fará o atendimento às necessidades/exigências definidas; uma regra de negócio pode ser compreendida quanto a como um requisito funcional se realizará.”
5. Versão
	Descrição
	Versão
	Data
	Autor
	Elaboração do documento
	1
	03/07/2020
	Luana de Quadros
 Página | 1
Template - 
Validaçãode requisitos por caso de uso .odt