Engenharia de Requisitos, SI

Prévia do material em texto

E h i d R i itEngenharia de Requisitos
Prof. Humberto Torres Marques Neto
Profª. Maria Augusta Vieira Nelson
Fevereiro / 2008Fevereiro / 2008
PUC-MINAS
Principais ObjetivosPrincipais Objetivos
9Di ti l õ9Discutir e propor soluções para os 
principais problemas do processo de 
id tifi ã ifi ã didentificação e especificação de 
requisitos de Sistemas de Informação
Referências Bibliográficasf g f
PRESSMAN, Roger S. Software Engineering: a 
practitioner’s approach. Fifth edition. (s.l.) 
McGraw-Hill, 2001.
BOOCH, Grady, RUMBAUGH, James,BOOCH, Grady, RUMBAUGH, James, 
JACOBSON, Ivair. UML: Guia do Usuário. Rio 
de Janeiro: Campus, 2000.
JACKSON, Michael. “Software Requirements and 
Specifications: A Lexicon of Practice, p ,
Principles, and Prejudices”, 1995.
Requisitos de Softwareq f
9O é?9O que é?
– característica observável do sistema
– efeito que um sistema deve exercer sobre 
o mundo real
– classificação
„ funcionais: o que o software deve fazer„ funcionais: o que o software deve fazer 
„ não-funcionais: o que se espera do sistema e 
normas/padrões que devem conduzir o seu 
funcionamento e construção
Requisitos de Softwareq
9Características
– Clareza
– Ser completo
Sem ambigüidade– Sem ambigüidade
– Implementável
– Consistente
– Verificável
– Rastreável
Engenharia de RequisitosEngenharia de Requisitos
9A engenharia de requisitos se concentra 
em problemas e objetivos do mundo 
real para definir funções e restrições
dos sistemas de software.
Requisitos são importantesRequisitos são importantes
Custo de reparar defeitos
100
120
Custo de reparar defeitos
40
60
80
100
C
u
s
t
o
0
20
40
t o s i g n ã o d e ã o ã o
R e
q u
i s i
t o
D e
s i g
m p
l e m
e n
t a ç
ã
t e s
 d e
 u n
i d a
d e
s d
e a
c e
i t a
ç ã
o
M a
n u
t e n
ç ã
I m
p
T e
s t e
T e
s t e
s 
Barry Boehm e Victor Basili
“Software defect reduction top 10 list”
Custo de reparar defeitosCusto de reparar defeitos
9É melhor prevenir do que remediar
– Para cada dólar gasto com a prevenção dePara cada dólar gasto com a prevenção de 
defeitos,
– Custo total de reparo de defeitos é reduzido de 3 p
a 10 dólares
Capers Jones (1994)
9Tempo de reparar um defeito
– 30 minutos na fase de requisitos
– 5 a 17 horas na fase de testes
Kelly, Sherif, and Hops (1992)
Requisitos são importantesRequisitos são importantes
9Erros introduzidos durante a etapa 
de requisitos podem causar:
– perda de vidas
– prejuízos financeiros
– atrasos nas entregas
– aumento de riscos
– baixa qualidadeq
Perdas de vidas atribuídas a softwarePerdas de vidas atribuídas a software
9Therac-25
3 mortes 8 pessoas gravemente– 3 mortes, 8 pessoas gravemente 
contaminadas
– especificação incompleta interface ruimespecificação incompleta, interface ruim
9Sistema de Ambulâncias de Londres
11 mortes (estimado)– 11 mortes (estimado)
– inúmeros problemas, inclusive especificação 
incompletaincompleta
Prejuízos financeiros atribuídos a SWPrejuízos financeiros atribuídos a SW
9 Ariane 5
– $500 milhões de dólares
– overflow durante conversão de ponto flutuante p/ inteiro
9 Sonda Orbital de Marte 
– $125 milhões de dólares
t l ét i– um componente usou escala métrica
e outro a escala imperial
– software correto mas especificaçãosoftware correto, mas especificação
incorreta
Terminologia da engenharia de requisitosTerminologia da engenharia de requisitos
propriedades do domínio
requisitos do cliente
computador
programa
especificação
propriedades do domínio computador
domínio de aplicação do cliente domínio da máquina
Onde pode dar errado?Onde pode dar errado?
No computador (muito raro)
Causas:
falha na energia
falha nos dispositivos de hardware
f lh i t i lfalha no sistema operacional
falha na rede
requisitos do cliente programa
especificação
propriedades do domínio computador
domínio de aplicação do cliente domínio da máquina
Onde pode dar errado?Onde pode dar errado?
No programa (não tão raro)
Causas:
erros de programação
especificação mal entendida
ê i d t l d dausência de controle de mudanças
Detecção:
testes do programa em relação á especificação
inspeções alkthro ghsinspeções, walkthroughs
especificação
propriedades do domínio
requisitos do cliente
computador
programa
especificação
p p p
domínio de aplicação do cliente domínio da máquina
Onde pode dar errado?Onde pode dar errado?
Na especificação (comum)p ç ( )
Causas:
requisitos mal entendidos
escolha inadequada da linguagem de especificação
especificação ambígua, inconsistente ou incompleta
Detecção:
inspeções, verificação formal
especificação
propriedades do domínio
requisitos do cliente
computador
programa
especificação
p p p
domínio de aplicação do cliente domínio da máquina
Onde pode dar errado?Onde pode dar errado?
Nos requisitos (comum)q ( )
Causas:
comunicação insuficiente com o cliente/usuários
ausência de análise
falha ao lidar com as mudanças
Detecção:
inspeções, revisões feitas pelo cliente, modelagem, 
lid ã f l t tivalidação formal, prototipagem
especificação
propriedades do domínio
requisitos do cliente
computador
programa
especificação
p p p
domínio de aplicação do cliente domínio da máquina
Onde pode dar errado?Onde pode dar errado?
Nas propriedades do domínio (muito comum)p p ( )
Causas:
Ausência de especialistas no domínio
Premissas que não foram questionadas
Análise do domínio insuficiente
Detecção:
comunicação com os especialistas que detêm a 
i f ãinformação
especificação
propriedades do domínio
requisitos do cliente
computador
programa
especificação
p p p
domínio de aplicação do cliente domínio da máquina
Engenharia de RequisitosEngenharia de Requisitos
9Principais etapas:
Identificação– Identificação
– Análise e 
negociaçãonegociação
– Especificação
– Modelagem
– Validaçãoç
– Gerenciamento
Identificação de RequisitosIdentificação de Requisitos
9Por que é tão difícil?
Problemas de escopo– Problemas de escopo
– Problemas de entendimento do que 
realmente é necessário fazerrealmente é necessário fazer
– Problemas de volatibilidade
Como fazer para identificar os requisitos p q
de um Sistema de Informação?
9Avaliar o negócio e a viabilidade técnica 
do sistema propostodo s ste a p oposto
9 Identificar as pessoas certas que 
participarão desse processoparticiparão desse processo
9Definir o ambiente tecnológico necessário 
(visão geral)(visão geral)
9 Identificar restrições do domínio do 
bl ( t í ti d ó i )problema (características do negócio)
Como fazer para identificar os requisitos p q
de um Sistema de Informação?
9Escolher os métodos que serão utilizados 
(entrevistas JAD reuniões etc )(entrevistas, JAD, reuniões, etc.)
9Envolver pessoas que podem ter pontos 
de vistas diferentes acerca do que estáde vistas diferentes acerca do que está 
sendo identificado
9 Identificar a existência de requisitos9 Identificar a existência de requisitos 
ambíguos
9Criar cenários para facilitar a análise dos9Criar cenários para facilitar a análise dos 
envolvidos no processo
Análise e Negociação de RequisitosAnálise e Negociação de Requisitos
9Questões que devem ser respondidas:
Os requisitos identificados estão de acordo com o– Os requisitos identificados estão de acordo com o 
objetivo do sistema?
– O nível de abstração de cada requisito está ç q
adequado para se iniciar a sua análise?
– Existe a possibilidade de integrar e simplificar 
i it id tifi d ?requisitos identificados?
– Qual a inter-relação dos requisitos?
Qual o impacto da retirada de cada um?– Qual o impacto daretirada de cada um? 
(minimizar custo e prazo de entrega)
Especificação dos RequisitosEspecificação dos Requisitos
9Documentação escrita
9Modelagem gráfica9Modelagem gráfica
9Modelagem matemática
9P ó i9Protótipos
9Combinação dos anteriores
ModelagemModelagem
9 Diagrama de casos de uso 
(diagrama de contexto)(diagrama de contexto)
9 Modelo de domínio
9 Diagrama de atividades
9 Diagrama de pacotes
9 Diagrama de integração deDiagrama de integração de 
sistemas de informação
Validação e Gerenciamento dos ç
Requisitos identificados
9Validação
– Tudo que foi especificado pode ser interpretado q p p p
corretamente?
– O desenvolvimento do requisito é factível tanto no 
âmbito do negócio e quanto no da tecnologia?âmbito do negócio e quanto no da tecnologia?
9Gerenciamento
– O que fazer com a volatibilidade das premissas 
que geraram um requisito?
é é á ó– Até que ponto é necessário manter um histórico 
das modificações?