EC205 Cap 5 Engenharia de Requisitos A2013 S2 - A

Prévia do material em texto

w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Capítulo 4 
Engenharia de Requisitos 
Adaptado do material dos professores Guilherme A. B. Marcondes e Valeska P. P. Marcondes 
Baseado no livro: Engenharia de Software – Roger S. Pressman – Sexta Edição 
Prof. Afonso Celso Soares 
EC205 – Engenharia de 
Software I 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Como podemos ter certeza de que o sistema que foi 
especificado corresponde exatamente às necessidades e 
anseios do cliente? 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Relatório CHAOS 
Fonte: The Standish Group; The CHAOS report(1994) 
Projetos finalizados dentro do prazo e 
custo estimados, com todas as 
características e funções inicialmente 
especificadas. 
16,2% 
Projetos cancelados 
31,1% 
Projetos finalizados além do prazo e custo 
estimados e com poucas características 
originalmente especificadas. 
52,7% 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
• Requisitos incompletos (13,1 %) 
• Falta de envolvimento dos usuários (12,4 %) 
• Falta de recursos (10,6 %) 
• Falsas expectativas (9,9 %) 
• Falta de suporte da gerência (9,3%) 
• Mudança nos requisitos e especificações (8,7 %) 
• Falta de planejamento (8,1 %) 
• Sistema desnecessário (7,5 %) 
 
Causas de falhas nos projetos de software 
Fonte: The Standish Group; The CHAOS report(1994) 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Engenharia de Requisitos 
Sistema 
Necessidade 
do Cliente 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Engenharia de Requisitos 
Sistema 
Engenharia 
de Requisitos 
Necessidade 
do Cliente 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Estudo de casos 
 California DMV 
•Department of Motor Vehicles (DMV) 
•Início em 1987 
•Cancelado em 1993 
•$45 milhões de dólares gastos 
Fonte: The Standish Group; The CHAOS report(1994) 
•Falta de apoio da gerência executiva 
•Falta de envolvimento dos usuários 
•Fraco planejamento 
•Fracas especificações de projeto 
•Falta de clareza nos objetivos 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Estudo de casos 
Fonte: The Standish Group; The CHAOS report(1994) 
•Envolvimento dos usuários 
•Suporte da gerência executiva 
•Claro entendimento dos requisitos 
•Planejamento adequado 
•Pequenos marcos de projeto 
Hotel Hyatt 
•Moderno sistema de reservas 
•Dentro do prazo 
•Dentro do orçamento ($15 milhões) 
•Com características extras 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
• Entender o que o cliente quer; 
• Analisar as necessidades do cliente; 
• Avaliar a viabilidade; 
• Negociar uma solução; 
• Especificar uma solução de forma clara; 
• Validar a especificação; 
• Gerenciar os requisitos. 
 
É preciso 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
 “Requisito é 
(1) Uma condição ou capacitação necessária a um usuário para 
solucionar um problema ou encontrar um objetivo. 
(2) Uma condição ou capacitação que um sistema ou componente do 
sistema precisa atender ou ter para satisfazer um contrato, padrão, 
especificação, ou outro documento formalmente estabelecido. 
O conjunto de todos os requisitos formam a base para o posterior 
desenvolvimento do sistema ou componente do sistema. 
[IEEE 83]” 
 
Requisito: uma definição 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Funcionais: o que o sistema deve fazer? 
Tipos de requisitos 
Especificam as funções que o sistema ou componente do sistema 
deve ser capaz de executar. 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Imprimir 
Salvar 
Selecionar 
Abrir 
Recortar 
Colar 
Copiar 
Desenhar círculo 
Desenhar quadrado 
Alterar cor 
Alterar zoom 
Girar imagem 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Não Funcionais: Como o sistema deve se comportar? 
 Estão atrelados à qualidade do software. 
 Restrições aos serviços ou funções oferecidas pelo sistema. 
Tipos de requisitos 
Estão relacionados a itens como: 
•Desempenho esperado. 
•Confiabilidade. 
•Segurança. 
•Manutenibilidade. 
•Restrições de projeto. 
•Requisitos não técnicos (acordos, condições, contratos, etc). 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tipos de requisitos não funcionais 
Fonte: Engenharia de Software – Ian Sommerville – Pearson Prentice Hall – 9ª Edição 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Como a Engenharia de Requisitos pode ajudar? 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
A engenharia de Requisitos pode ser descrita pelas 
seguintes etapas: 
•Identificação dos requisitos (levantamento); 
•Análise e Negociação dos requisitos; 
•Especificação dos requisitos; 
•Modelo do sistema; 
•Validação dos requisitos; 
•Gerência dos requisitos; 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tarefas 
Concepção 
• Foco no entendimento do problema. 
• A necessidade de negócio é identificada ou novo 
 serviço ou mercado descoberto. 
• Permite a identificação das características 
 fundamentais que a solução deverá prover. 
• Permite a identificação da abrangência e 
 profundidade da solução. 
• Possibilita uma análise “grosseira” de 
 viabilidade. 
• Resulta em uma descrição primária de escopo. 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tarefas 
Concepção 
Levantamento ou 
identificação dos 
requisitos 
•Alguns aspectos a serem investigados junto 
 ao cliente, usuários e outros, seriam: 
• Objetivo. 
• Resultado a ser conseguido. 
• Como o sistema se encaixa nas 
 necessidades do negócio. 
• Como será usado no dia-a-dia. 
• Etc, 
Parece simples, mas não é! 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tarefas 
Concepção 
- Qual o limite do sistema? 
- O que a solução proposta 
deverá resolver e o que não 
poderá resolver? 
Levantamento ou 
identificação dos 
requisitos 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tarefas 
Concepção 
O que o sistema 
deve fazer? 
Levantamento ou 
identificação dos 
requisitos 
Cliente/usuários: 
-Não sabem exatamente do 
que precisam. 
-Têm pouca compreensão das 
capacidades e limitações 
tecnológicas. 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tarefas 
Concepção 
Cliente/usuários: 
-Não têm pleno entendimento 
do domínio do problema. 
-Têm dificuldade em explicar 
..(detalhes técnicos 
....desnecessários podem 
....confundir em vez de esclarecer) 
- Omitem informações 
..“óbvias”. 
Levantamento ou 
identificação dos 
requisitos 
O que o sistema 
deve fazer? 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tarefas 
Concepção 
O que o sistema 
deve fazer? 
Levantamento ou 
identificação dos 
requisitos 
Cliente/usuários: 
-Especificam requisitos 
.ambíguos, conflitantes ou 
.impossíveis de testar. 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tarefas 
Concepção 
Blax tuax fox ic jac 
poc = IDDC. 
Ad ied ud god 
ted rug mihrr! 
Levantamento ou 
identificação dos 
requisitos 
Cliente/usuários: 
-Utilizam a linguagem do.domínio de negócios e que 
.nem sempre pode ser 
.entendida pelo analista de 
.software; 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tarefas 
Concepção 
Levantamento ou 
identificação dos 
requisitos 
Requisitos podem mudar ao 
longo do tempo. 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tarefas 
Concepção 
Levantamento 
• As informações obtidas são expandidas e 
 refinadas. 
• Pode exigir o desenvolvimento de um 
 modelo técnico – modelagem, ou 
 protótipos. 
• A criação de cenários do comportamento 
 do sistema interagindo com usuários ou 
 outras interfaces melhora o entendimento 
 do sistema. 
Análise 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tarefas 
Concepção 
Levantamento 
• Devem ser consideradas limitações 
 de recursos (materiais e humanos); 
• Possibilita a definição de prioridades. 
• Permite a identificação de riscos. 
• Possibilita a realização de 
 estimativas “grosseiras” de esforço. 
• Pode demandar ajustes nos 
 requisitos. 
Análise 
Negociação 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tarefas 
Concepção 
Levantamento 
• Define o que será feito 
 em maiores detalhes. 
• O escopo primário é 
 refinado. 
Análise 
Negociação 
Especificação 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tarefas 
Concepção 
Levantamento 
Elaboração 
Negociação 
Especificação 
Validação 
• Realizada por uma revisão 
 técnica formal. 
• Tem como objetivo garantir 
que não haja inconsistências, 
ambiguidades, omissões e 
 erros. 
• Pode incluir, também, cliente 
 e usuários. 
• Ponto de partida para o 
 desenvolvimento. 
• Define o que será feito. 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tarefas 
Concepção 
Levantamento 
Análise 
Negociação 
Especificação 
Validação 
• Tem como objetivo garantir a 
 implementação de todos os 
 requisitos. 
• Possibilita o controle das 
 mudanças de requisitos. 
• Pode utilizar uma tabela de 
rastreamento: requisitos x 
casos de uso. 
Gestão dos 
Requisitos 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tarefas 
Concepção 
Levantamento 
Análise 
Negociação 
Especificação 
Validação 
Gestão dos 
Requisitos 
A01 A02 A03 A04 ........ An 
ReqF01   
ReqF02   
ReqF03   
ReqF04  
 
ReqFn  
 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
A Engenharia de requisitos não é composta por uma 
sequência linear das atividades: elas não podem ser 
separadas e executadas sequencialmente. 
As tarefas são intercaladas e executadas 
repetidamente. 
Algumas partes do produto podem ser analisadas e 
especificadas enquanto outras ainda estão sendo 
analisadas. 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Por onde começar? 
Quem são os 
Interessados? 
• Quem se beneficia com o sistema (direta ou 
indiretamente)? 
• Listar pessoas que fornecerão informações. 
• Lista pode crescer à medida que se 
 conversa com interessados. 
• Exemplos: Gerentes da área de 
 negócio e de produto, 
 marketing, clientes (externos 
 e internos), 
 usuários, 
 engenheiros de 
 produto, de 
 suporte, etc. 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Problema 
Por onde começar? 
• Cada um pode ter um interesse diferente no 
 sistema. 
• Todos contribuirão para a definição dos 
 requisitos. 
• Pode haver inconsistências, 
devendo ser eliminadas. 
• Priorizar requisitos para 
 definições. 
Diversos Pontos 
de Vista 
Quem são os 
Interessados? 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Por onde começar? 
• Identificar requisitos com os quais todos 
 concordam. Começar. por eles. 
• Requisitos conflitantes ou inconsistentes 
 merecem maior atenção. 
• Negociar. 
• Deve haver alguém que tome a 
 decisão final (quais requisitos 
 serão implementados 
 e quais ficarão de fora). Busca da 
Colaboração 
Quem são os 
Interessados? 
Diversos Pontos 
de Vista 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Por onde começar? 
Primeiras 
Perguntas 
Quem são os interessados e quais são as 
metas globais e benefícios? 
• Quem solicitou? 
• Quem vai usar? 
• Qual o benefício econômico? 
• Há outra fonte para a solução? 
??? 
Blá-blá-blá 
Blá-blá-blá 
Quem são os 
Interessados? 
Diversos Pontos 
de Vista 
Busca da 
Colaboração 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Por onde começar? 
Primeiras 
Perguntas 
??? 
Blá-blá-blá 
Blá-blá-blá 
Quem são os 
Interessados? 
Diversos Pontos 
de Vista 
Busca da 
Colaboração 
 Melhor Entendimento do Problema 
• Como caracterizar boas saídas para a 
 solução? 
• Que problema(s) esta solução irá tratar? 
• Pode descrever o ambiente de 
 negócio em que a solução
 será usada? 
• Há restrições ou problemas de 
 desempenho que 
 afetam a solução? 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Por onde começar? 
Primeiras 
Perguntas 
??? 
Blá-blá-blá 
Blá-blá-blá 
Quem são os 
Interessados? 
Diversos Pontos 
de Vista 
Busca da 
Colaboração 
 Efetividade da Comunicação 
• Você é a pessoa certa para estas perguntas? 
• Estas respostas são “oficiais”? 
• As questões levantadas são 
 relevantes ao 
problema? 
• Alguém mais pode fornecer 
 informações 
 adicionais? 
• Algum outro 
 ponto 
 relevante? 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Um guia para o levantamento dos requisitos 
• Entenda qual é o problema. 
• Avalie o negócio e a viabilidade técnica da solução proposta. 
• Identifique um vocabulário comum. 
• Identifique as pessoas que irão ajudar na especificação e entenda seus 
 interesses organizacionais. 
• Defina o ambiente técnico (arquitetura, sistema operacional etc.) dentro 
 do qual o sistema irá operar. 
• Identifique as restrições do sistema (hardware, interfaces, e outros) que 
 limitam as funcionalidades ou seu desempenho. 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
• Defina um ou mais métodos para identificar os requisitos (entrevistas, 
 reuniões, etc.). 
• Solicite a participação de várias pessoas para que os requisitos sejam 
 definidos a partir de diferentes pontos de vista. 
• Identifique os requisitos mais complexos como candidatos à 
 prototipação. 
• Crie cenários para ajudar os clientes e usuários a identificarem melhor 
 os requisitos principais. 
Um guia para o levantamento dos requisitos 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
• Uma declaração da necessidade e viabilidade do sistema. 
• Uma declaração do escopo do sistema. 
• Uma lista de clientes, usuários e outros que irão participar da 
 identificação dos requisitos. 
• Uma descrição do ambiente técnico do sistema. 
• Uma lista de requisitos. 
• Um conjunto de cenários que fornecem uma visão do funcionamento do 
 sistema. 
• Algum protótipo desenvolvido para melhor definir o requisito. 
Como resultado do levantamento dos requisitos tem-se: 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Negociação 
• Balancear asnecessidades do cliente com a viabilidade de execução. 
• Funcionalidades/Desempenho x Custo/Prazo. 
• Nenhum dos lados deve sentir-se prejudicado. Buscar o “ganha-ganha”. 
• Quando não é possível fazer tudo, deve-se priorizar. 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Especificação dos requisitos 
• Uma maneira de fácil entendimento e consistente de apresentar os 
 requisitos. 
• Pode ser tanto um documento escrito, quanto um modelo gráfico, um 
 modelo matemático, uma coleção de cenários, um protótipo ou a 
 combinação desses. 
• Produz-se a Especificação do Sistema. 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
• Cada requisito está consistente com o objetivo geral do sistema? 
• Todos os requisitos foram especificados no apropriado nível de 
 abstração? 
• O requisito é essencial ao sistema, ou ele é uma característica a mais? 
• Cada requisito está dentro do escopo do sistema e de forma clara? 
• Cada requisito é limitado e não ambíguo? 
Validação 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
• Há conflito de requisitos? 
• Cada requisito é realizável? 
• Cada requisito pode ser testado? 
• O modelo de requisito reflete adequadamente a informação, a função e 
 o comportamento da sistema? 
Validação 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Modelo do sistema 
• Representação gráfica e textual do sistema. 
• Facilita a comunicação entre clientes, analistas, projetistas e 
 desenvolvedores. 
• Melhora o entendimento de sistemas complexos. 
• Utiliza uma notação, por exemplo UML (Unified Modeling Language). 
• Exemplos de modelos: diagramas de Casos de Uso (Use Cases), 
 diagramas de classes, modelos de dados, diagramas de estado etc. 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Exemplo de Diagrama de Caso de Uso 
Sacar dinheiro 
Consultar Saldo 
Transferir dinheiro 
Cliente 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Exemplo de Fluxo de Eventos: 
Sacar dinheiro 
Cliente 
Ações Recebidas Ações Realizadas
1. O Cliente solicita o saque de dinheiro 2. O sistema solicita que ele passe o cartão
3. O Cliente passa o cartão solicitado 4. O sistema verifica os dados do cartão.
5. Se os dados estiverem corretos, o sistema solicita
a senha do cliente.
6. O Cliente digita a senha 7. O sistema verifica se a senha está correta.
8. Caso esteja correta, o sistema solicita que o
cliente digite a quantia desejada.
9. O Cliente digita a quantia 10. O sistema verifica se existe saldo suficiente.
11. Caso exista, o valor é liberado.
12. A use case é finalizada.
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Gerência de Requisitos 
• Conjunto de atividades que ajudam a equipe de projeto a identificar, 
 controlar e acompanhar os requisitos e as mudanças nos requisitos 
 durante todo o desenvolvimento do sistema. 
• Identificação única dos requisitos. Exemplo: 
Req[F/NF][00]-[nome] 
ReqF01-Gerar relatórios 
• Criação de tabelas de acompanhamento. 
• Cada tabela de acompanhamento relaciona os requisitos identificados 
 com algum aspectos do mesmo. 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tabela genérica de acompanhamento: 
• Requisitos X Características 
• Requisitos X Fontes 
• Requisitos X Dependências 
• Requisitos X Casos de Uso 
• Requisitos X Interfaces 
 
A01 A02 A03 A04 An 
ReqF01   
ReqF02   
ReqF03   
ReqF04  
 
ReqFn  
 
Requisitos 
Aspectos do Sistema 
ReqF01 depende de ReqF02 e 
ReqF03 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tabela genérica de acompanhamento: 
• Requisitos X Características 
• Requisitos X Fontes 
• Requisitos X Dependências 
• Requisitos X Casos de Uso 
• Requisitos X Interfaces 
 
A01 A02 A03 A04 An 
ReqF01   
ReqF02   
ReqF03   
ReqF04  
 
ReqFn  
 
Requisitos 
Aspectos do Sistema 
UC01 implementa: 
 - ReqF01 
 - ReqF05 
 - ReqF07 
 - ReqNF04 
w
w
w
.i
n
a
te
l.
b
r 
Engenharia de Requisitos 
Tabela genérica de acompanhamento: 
• Requisitos X Características 
• Requisitos X Fontes 
• Requisitos X Dependências 
• Requisitos X Casos de Uso 
• Requisitos X Interfaces 
 
A01 A02 A03 A04 An 
ReqF01   
ReqF02   
ReqF03   
ReqF04  
 
ReqFn  
 
Requisitos 
Aspectos do Sistema 
Sistema interage com equipamento 
usando protocolo SNMP. 
 - ReqF03 
 - ReqF04 
 - ReqF09