GCC244-Requisitos

Prévia do material em texto

Engenharia de Requisitos no 
MR-MPS-SW:2021
REQ – Engenharia de Requisitos no 
MR-MPS-SW:2021
O propósito do processo Engenharia de Requisitos é definir,
gerenciar e manter atualizados os requisitos das partes
interessadas e do produto, garantindo que inconsistências entre
os requisitos, os planos e os produtos de trabalho sejam
identificadas e tratadas.
PROPÓSITO
Problema
Problema
Visões para Requisitos
Requisitos são a ponte que liga um problema do mundo real a um sistema de 
software que o soluciona.
Visões para Requisitos
Requisito = Declaração para ser entendida pelos usuários ou pelos
desenvolvedores?
▪ Requisitos do usuário: declarações, em formato ou linguagem inteligível pelo
cliente, sobre as funções que o sistema deve oferecer e as restrições sob as quais
deve operar.
▪ Requisitos de produto: estabelecem detalhadamente as funções e as restrições do
produto em um formato mais apropriado para a implementação.
Requisitos funcionais e não-funcionais
Requisitos Funcionais
▪ Requisitos diretamente ligados às funcionalidades do software
▪ Descrevem as funções que o software deve executar
▪ Um requisito funcional descreve uma interação entre o software e seu ambiente
Exemplo: “O software deve prover um relatório com os
resultados dos testes clínicos de um paciente”
Requisitos funcionais e não-funcionais
Requisitos Não-Funcionais
▪ São requisitos que expressam condições que o software deve atender ou qualidades
específicas que o software deve ter
▪ Em vez de informar o que o software fará, os requisitos não-funcionais colocam
restrições no produto
Exemplo: “As consultas ao sistema devem ser respondidas
em menos de três segundos”
Atores do Processo de Requisitos
Stakeholders (Partes interessadas)
▪ Alguém que ganha ou perde algo com o resultado do projeto:
▪ Funcionalidade
▪ Rendimento
▪ Status
▪ ...
Interessado (stakeholder): indivíduo ou organização impactado pelo
processo, atividade, produto de trabalho ou decisão.
CMMI Institute. CMMI Development v2.0, 2018
Atores do Processo de Requisitos
Exemplos típicos de stakeholders:
▪ Usuários – grupo que irá usar o software
▪ Clientes – grupo que encomendou o software ou que representa o público
alvo do mesmo
▪ Autoridades de regulamentação – para aplicações com regulamentações
próprias, como transporte público
▪ Desenvolvedores
▪ Outros engenheiros de software
Identificação de Stakeholders
▪ O contato inicial normalmente indica pessoas com quem se deve
falar, seus papéis e seus interesses
▪ Stakeholders incluem usuários diretos do sistema e interessados
indiretos também
▪ Stakeholders podem sugerir outras pessoas que devem ser
consultadas
Atividades da Engenharia de Requisitos
Desenvolvimento de Requisitos
(Elicitação, Análise, Modelagem e Validação)
Gerência de Requisitos
Novos 
requisitos 
elicitados
Versões aceitas, 
rastreabilidade, 
mudanças
◼ Desenvolvimento de Requisitos cria e interpreta os requisitos
◼ Gerência de Requisitos organiza e mantém registro dos mesmos
Comunicação e entendimento dos 
Requisitos
Fornecedores de Requisitos
▪ São as fontes oficiais de requisitos – pessoas selecionadas das quais se
obtém os requisitos
▪ Devem ser identificados explicitamente
▪ Discussões “não oficiais” sobre requisitos muitas vezes resultam em uma
expansão do escopo do projeto
Comunicação e entendimento dos 
Requisitos
▪ Comunicação em duas vias entre fornecedores de requisitos e a
equipe do projeto é crítica para assegurar um entendimento
equivalente
▪ Esta comunicação deve tratar:
▪ definição de requisitos
▪ aprovação de requisitos
▪ solicitação de mudança nos requisitos
As comunicações devem ser registradas formalmente através de:
▪ Atas de reunião
▪ Documentos (devem ser aprovados/assinados)
▪ Emails (devem ser armazenados)
Comunicação e entendimento dos 
Requisitos
É importante a comprovação de que os interessados estão de
acordo com o conteúdo registrado
Devem ser definidos e evidenciados os meios e formas de
comunicação, momentos e/ou freqüências para as
comunicações
Comunicação e entendimento dos 
Requisitos
▪ Para o conjunto de requisitos especificados, é necessário
rever com o cliente se as necessidades e expectativas estão
sendo atendidas com os requisitos propostos.
▪ Como comprovação deste entendimento deve-se ter um
documento de requisitos e registro da aprovação.
Rastreabilidade
Objetivo
▪ Criar vínculos (links) entre os requisitos e outros produtos de trabalho.
Importante para:
▪ Auxiliar a avaliar o impacto de mudanças nos requisitos.
▪ Demonstrar a completa satisfação dos requisitos.
▪ Facilitar a manutenção do produto
Rastreabilidade
Requisitos do 
Usuário
Projeto do 
Produto
Especificações 
do Produto
AVALIAR O IMPACTO DE MUDANÇA
DEMONSTRAR SATISFAÇÃO DOS REQUISITOS
RASTREAR A ORIGEM DE UM COMPONENTE
Código do 
Produto
Rastreabilidade
Rastreabilidade Horizontal
▪ Links de dependência entre elementos de um mesmo nível.
▪ Exemplos: requisitos do cliente X requisitos do cliente,
caso de uso X caso de uso.
Rastreabilidade Vertical
▪ Links de dependência entre elementos de diferentes níveis.
▪ Exemplos: requisito do cliente X caso de uso,
Matriz de Rastreabilidade
• Tabela utilizada para documentar os relacionamentos entre os 
elementos.
R1 R2 R3
Caso de Uso 1 x
Caso de Uso 2 x
Caso de Uso 3 x x
Matriz de Rastreabilidade de Requisitos
ID Nome do Requisito Descrição do Requisito Tipo Caso de Uso Caso de Teste Componente
1
2
3
4
Relação de Casos de Uso
Código Nome Descrição Documento
Relação de Casos de Teste
Código Nome Descrição Documento
Matriz de Rastreabilidade de Requisitos
ID
Nome do 
Requisito
Descrição do Requisito (se pertinente) Tipo
Requisito 
Relaciona
do
História
Caso de 
Uso
Sprint 
Caso de 
Teste
Compon
ente
1
<nome do 
Requisito>
<preencher com uma descrição do 
requisisito>
<F ou 
NF>
<ID de 
requisitos 
relacionad
os>
<ID da 
História>
<ID do Caso 
de Uso>
<Sprint que 
tratará o 
requisito>
<ID do 
Caso de 
Teste>
<ID do 
Compon
ente>
2
Controle de Mudanças
▪ O impacto de cada mudança deve ser analisado antes de ser
realizada considerando:
▪ Produtos que deverão ser modificados com a mudança
▪Tempo, esforço e custos necessários, analisando as atividades
do cronograma já realizadas
▪ A análise deve considerar a matriz de rastreabilidade
Exemplo de Documento de Controle de 
Mudanças
Versão do 
Modelo
Descrição das 
modificações
Data Autor
1.0 Versão Inicial
Modelo (Controle de Mudanças)
(Obs: excluir esta página de registro de versão do modelo do 
documento quando for gerar o documento)
1. Objetivo
Este documento tem como objetivo registrar o histórico de mudanças ocorridas durante
o projeto.
2. Identificação do Projeto
3. Histórico de Mudanças
Nome do Projeto
Sigla do Projeto
Cliente
Gerente do Projeto
Identificação da Mudança:
Solicitante:
Data:
Registro da Solicitação: ( ) Ata de reunião: Data: XX/XX/XXXX 
( ) E-mail: Data: XX/XX/XXXX
Descrição:
Justificativa:
Implica em Alteração de Requisitos? ( )SIM ( ) NÃO
Produtos de trabalho a serem alterados ( ) Plano do Projeto 
( ) Cronograma 
( ) Estrutura para Rastreabilidade
( ) Implementação 
( ) Outros [liste]: 
Impacto no Esforço: [Indicar HH para realizar a mudança]
Impacto no Cronograma: [Indicar tempo para realizar a mudança]
Impacto no Custo: [Indicar o custo para realizar a mudança]
Situação:
( ) Aprovada pelo Cliente 
( ) Não Aprovada pelo Cliente
Data:
Responsável pela aprovação:
( ) Comprometimento dos envolvidos na 
Empresa
Data:
[Obs: guardar ata de reunião ou e-mail de todos os 
envolvidos]
Acrescentar ao documento
uma nova tabela a cada
mudança
Exemplo de Especificação de 
Requisitos
Versão Descrição das modificações Data Autor
< Cada nova versão deve ser identificada acima>
Nome Funçãona Organização Contato
3. Escopo do Produto
<Incluir o objetivo do produto e seu escopo>
4. Requisitos Funcionais
RF1: Descrição RF1.
RF2: Descrição RF2.
5. Requisitos Não-Funcionais: 
Atributo 1
RNF1: Descrição RNF1.
RNF2: Descrição RNF2.
RNF4: Descrição RNF4.
RNF5: Descrição RNF5.
Atributo 2
<Em atributo, colocar conforme pertinente por exemplo: segurança, desempenho, etc>
1. Projeto:
<Incluir o nome do produto>
2. Fornecedores de Requisitos
Especificação de Requisitos
6. Identificação dos Atores
Nome Descrição
7. Diagrama de Casos de Uso
8. Lista de Casos de Uso
Identificador Nome Descrição
UC1
UC2
Engenharia de Requisitos no 
MR-MPS-SW:2021
O propósito do processo Engenharia de Requisitos é definir,
gerenciar e manter atualizados os requisitos das partes
interessadas e do produto, garantindo que inconsistências entre
os requisitos, os planos e os produtos de trabalho sejam
identificadas e tratadas.
PROPÓSITO
REQ 1 2 3 4 5 6 7
G -> E
D -> A + + +
EVOLUÇÃO NOS NÍVEIS MPS
EVOLUÇÃO DOS 
RESULTADOS
Modelo MR-MPS.BR
Engenharia de Requisitos
Elicitação de Requisitos 
com o Cliente
Especificação de 
Requisitos do Software
DOCUMENTO DE REQUISITOSRequisitos do Cliente
V&V e Aprovação do 
Cliente
Comprometimento 
da Equipe Técnica
Atividades de Gerência 
de Requisitos
Engenharia de Requisitos
REQ 1 As necessidades, expectativas e restrições
das partes interessadas, tanto em relação ao
produto quanto a suas interfaces, são
identificadas.
DOCUMENTO DE REQUISITOS
Requisitos do Cliente
REQ 3 Os requisitos são entendidos e
analisados junto aos fornecedores de
requisitos.
REQ 3+ Os requisitos são entendidos e
analisados junto aos fornecedores de
requisitos para garantir que sejam claros,
necessários e suficientes e para balancear
as necessidades das partes interessadas
com as restrições existentes.
REQ 4 Os requisitos são aprovados pelos
fornecedores de requisitos.
REQ 4+ Os requisitos são validados.
REQ 5 O compromisso da equipe
técnica com a implementação
dos requisitos é obtido.
REQ 6 A rastreabilidade bidirecional entre requisitos, atividades e
produtos de trabalho do projeto é estabelecida e mantida.
REQ 7 Os planos, atividades e produtos de trabalho relacionados são
revisados visando identificar e tratar inconsistência em relação aos
requisitos
REQ 2 Os requisitos são especificados, priorizados
e mantidos atualizados a partir das necessidades,
expectativas e restrições identificadas para o
produto e suas interfaces.
REQ2+ Os requisitos são especificados, priorizados,
refinados, alocados para implementação e
mantidos atualizados a partir das necessidades,
expectativas e restrições identificadas, o que inclui
a especificação de conceitos operacionais, cenários
e interfaces internas e externas.
REQ – Engenharia de Requisitos do 
nível G ao nível E
REQ 1 2 3 4 5 6 7
G -> E
D -> A + + +
REQ – Engenharia de Requisitos do 
nível G ao nível E
REQ 1 As necessidades, expectativas e restrições
das partes interessadas, tanto em relação ao
produto quanto a suas interfaces, são
identificadas.
DOCUMENTO DE REQUISITOS
Requisitos do Cliente
REQ 3 Os requisitos são entendidos e
analisados junto aos fornecedores de
requisitos.
REQ 4 Os requisitos são aprovados pelos
fornecedores de requisitos.
REQ 5 O compromisso da equipe
técnica com a implementação
dos requisitos é obtido.
REQ 6 A rastreabilidade bidirecional entre requisitos, atividades e
produtos de trabalho do projeto é estabelecida e mantida.
REQ 7 Os planos, atividades e produtos de trabalho relacionados são
revisados visando identificar e tratar inconsistência em relação aos
requisitos
REQ 2 Os requisitos são especificados, priorizados
e mantidos atualizados a partir das necessidades,
expectativas e restrições identificadas para o
produto e suas interfaces.
Elicitação de Requisitos com o Cliente
▪ Objetivo:
▪ garantir um entendimento comum dos requisitos.
▪ Técnicas de elicitação de requisitos:
▪ entrevistas
▪ questionários
▪ construção de protótipos
▪ observação do trabalho
▪ consulta a leis, padrões, literatura técnica
▪ Requisitos do cliente incluem:
▪ requisitos técnicos (exemplos: funcionalidades, qualidade e interfaces)
▪ requisitos não técnicos (exemplo: custo)
▪ Importante: identificar e registrar quem são os fornecedores de requisitos
REQ 1 As necessidades, expectativas e restrições das partes interessadas,
tanto em relação ao produto quanto a suas interfaces, são identificadas.
Especificação de Requisitos do 
Software
• Objetivo:
▪ Priorizar os requisitos
▪ Produzir o documento de requisitos
• Importante:
▪ Prioridades devem orientar a definição das iterações ou sprints do projeto.
▪ Definir os canais apropriados de recebimento de solicitações de mudanças nos
requisitos.
REQ 2 Os requisitos são especificados, priorizados e mantidos atualizados a
partir das necessidades, expectativas e restrições identificadas para o produto
e suas interfaces.
Documento de Requisitos
Avaliação e Aprovação pelo Cliente
Importante:
▪ Ter critérios para avaliação e aceitação dos requisitos. 
Exemplos: 
▪ Não ambiguidade
▪ Completude
▪ Consistência entre os requisitos
▪ Testáveis
▪ ...
REQ 3 Os requisitos são entendidos e analisados junto aos fornecedores de
requisitos.
REQ 4 Os requisitos são aprovados pelos fornecedores de requisitos.
Documento de Requisitos aprovado pelos fornecedores de requisitos 
Comprometimento da Equipe Técnica
Objetivo:
▪ Obter o comprometimento da equipe de que podem implementar os requisitos
▪ O comprometimento deve ficar registrado e pode ser através de:
▪ Reuniões com ata
▪ Assinatura em documentos
▪ E-mails
REQ 5 O compromisso da equipe técnica com a implementação dos requisitos é
obtido.
Registro do comprometimento da equipe com a possibilidade de
implementar os requisitos aprovados.
À medida que o projeto evolui ou são realizadas alterações nos requisitos a equipe 
deve se comprometer com os requisitos e as mudanças resultantes no Plano do 
Projeto, atividades e produtos de trabalho
Atividades de Gerência de Requisitos
Objetivo:
▪ Garantir que planos e produtos de trabalho se mantenham consistentes com os
requisitos
REQ 6 A rastreabilidade bidirecional entre requisitos, atividades e produtos
de trabalho do projeto é estabelecida e mantida.
REQ 7 Os planos, atividades e produtos de trabalho relacionados são
revisados visando identificar e tratar inconsistência em relação aos requisitos
Estrutura para Rastreabilidade
Registro da avaliação e de ações corretivas
REQ – Engenharia de Requisitos a partir do 
nível D
REQ 1 2 3 4 5 6 7
G -> E
D -> A + + +
REQ – Engenharia de Requisitos a 
partir do nível D
REQ 1 As necessidades, expectativas e restrições
das partes interessadas, tanto em relação ao
produto quanto a suas interfaces, são
identificadas.
DOCUMENTO DE REQUISITOS
Requisitos do Cliente
REQ 3 Os requisitos são entendidos e
analisados junto aos fornecedores de
requisitos.
REQ 3+ Os requisitos são entendidos e
analisados junto aos fornecedores de
requisitos para garantir que sejam claros,
necessários e suficientes e para balancear
as necessidades das partes interessadas
com as restrições existentes.
REQ 4 Os requisitos são aprovados pelos
fornecedores de requisitos.
REQ 4+ Os requisitos são validados.
REQ 5 O compromisso da equipe
técnica com a implementação
dos requisitos é obtido.
REQ 6 A rastreabilidade bidirecional entre requisitos, atividades e
produtos de trabalho do projeto é estabelecida e mantida.
REQ 7 Os planos, atividades e produtos de trabalho relacionados são
revisados visando identificar e tratar inconsistência em relação aos
requisitos
REQ 2 Os requisitos são especificados, priorizados
e mantidos atualizados a partir das necessidades,
expectativas e restrições identificadas para o
produto e suas interfaces.
REQ2+ Os requisitos são especificados, priorizados,
refinados, alocados para implementação e
mantidos atualizados a partir das necessidades,
expectativas e restrições identificadas,o que inclui
a especificação de conceitos operacionais, cenários
e interfaces internas e externas.
Especificação de Requisitos de Software
Objetivos:
▪ Descrever os requisitos em termos técnicos necessários para o projeto da solução.
▪ Identificar , registrar e manter atualizados requisitos para interfaces internas e externas
▪ Alocar requisitos para implementação com base na arquitetura
REQ2+ Os requisitos são especificados, priorizados, refinados, alocados para
implementação e mantidos atualizados a partir das necessidades, expectativas e
restrições identificadas, o que inclui a especificação de conceitos operacionais,
cenários e interfaces internas e externas.
Documento de Requisitos
Cenários: sequência de eventos que incluem interações do usuário com o produto
Conceitos operacionais: 
▪visão do produto sob a perspectiva do usuário
▪Contexto para desenvolver ou avaliar um conjunto de cenários.
Avaliação e Aprovação pelo Cliente
Validação de requisitos:
▪ Validar os requisitos para assegurar que a solução irá funcionar como desejado no 
ambiente alvo.
▪ Envolver usuários
▪ Técnicas de validação:
▪ Protótipos
▪ Demonstrações
REQ 3+ Os requisitos são entendidos e analisados junto aos fornecedores de
requisitos para garantir que sejam claros, necessários e suficientes e para
balancear as necessidades das partes interessadas com as restrições
existentes.
REQ 4 + Os requisitos são validados.
Documento de Requisitos aprovado pelos fornecedores de requisitos