15_-_Validacao_de_Requisitos

Prévia do material em texto

Validação de 
Requisitos
identificação
, descoberta 
de requisitos
análise e 
negociação 
de requisitos
documentação 
de requisitos
validação de 
requisitos
documento 
de requisitos
necessidades dos usuários, 
sistemas legados,
informação do domínio, 
normas organizacionais, 
etc.
Processo da Engenharia de Requisitos
(Kotonya e Sommerville, 1998; SWEBOK)
Processo de Engenharia de Requisitos: 
modelo em espiral
Validação de requisitos
• validação de requisitos diz respeito à
verificação do documento de requisitos
quanto à sua consistência, completude e 
precisão
• Técnicas
� revisão de requisitos
� prototipagem
� validação de modelos
� definição de testes de aceitação
Análise X Validação
(Kotonya e Sommerville, 1998; SWEBOK)
análise e 
negociação 
de requisitos
assegurar que os 
requisitos vão ao 
encontro das 
necessidades dos 
stakeholders
requisitos em "bruto",
informais e pouco estruturados,
escritos numa mistura de notações 
stakeholders
validação de 
requisitos
draft final do documento de 
requisitos,
isento de inconsistência e 
incompletude,
segue normas de qualidade,
assegurar que os 
requisitos estão 
corretamente descritos
temos os requisitos certos?
temos os requisitos corretamente?
Análise X Validação
• exemplos de problemas que aparecem na 
fase de validação
� não conformidade com normas de qualidade
� requisitos mal descritos, ambíguos
� erros na modelagem do sistema ou problema 
� conflitos entre requisitos que não foram 
detectados no processo de análise
Processo de validação
validação de 
requisitos
documento de 
requisitos
conhecimento 
organizacional
normas da 
organização
lista de problemas
ações acordadas
Kotonya, 1998
Revisão de requisitos
planejar
revisão
distribuir
documentos
preparar para
a revisão
reunião 
de revisão
ações de
continuidade
rever o
documento
Revisão de requisitos
• reunião de revisão de requisitos
� a reunião de revisão é uma reunião formal
� deve ser conduzida por alguém que não 
esteve envolvido na produção dos requisitos
� cada requisito deve ser apresentado por vez 
para discussão pelo grupo
� Um membro do grupo deve executar o papel
de relator e anotar os problemas identificados
para posterior discussão
Revisão de requisitos
requisitos mal escritos
falta de informação
conflitos
requisitos não realistas
esclarecimento, reescrita 
dos requisitos
descobrir a informação 
que falta no documento
os stakeholders devem 
negociar para resolver o
conflito
o requisito deve ser
modificado ou removido
problemas ações
Revisão de requisitos: equipe
equipe de
revisão de
requisitos
usuário-final
ou representante
especialista do
domínio
representante
do cliente
responsáveis pelo 
desenho do sistema
engenheiro de
requisitos
Revisão de requisitos: checklists
• checklists de revisão
� devem ser genéricos
� não devem incidir sobre requisitos 
individualmente mas com as propriedades 
de qualidade do documento como um todo 
e com as relações entre requisitos
Revisão de requisitos: checklists
• atributos de qualidade dos requisitos
� compreensibilidade
� redundância
� completude
� não ambiguidade
� consistência
� organização
� conformidade com as normas
� rastreabilidade
Revisão de requisitos: checklists
• Compreensibilidade
� Os leitores do documento entendem o que os
requisitos significam?
� Redundância
� Há informações desnecessariamente repetidas no 
documento?
� Completude
� O verificador sabe de algum requisito ausente ou há
alguma informação faltando na descrição?
Revisão de requisitos: checklists
• Não ambiguidade
� Os requisitos são descritos usando termos que são
claramente definidos?
� Leitores com diferentes níveis de conhecimento e 
formação podem fazer interpretações diferentes dos 
requisitos?
� Consistência
� As descrições de diferentes requisitos apresentam
contradições?
� Há contradições entre requisitos individuais e 
requisitos gerais do sistema?
Revisão de requisitos: checklists
• Organização
� O documento está organizado de forma a facilitar sua
leitura e compreensão?
� As descrições de requisitos estão organizadas de 
forma que requisitos relacionados estejam agrupados?
� Haveria uma alteranativa de estruturação que tornaria
o documento mais fácil de entender?
� Conformidade com padrões
� O documento de requisitos e os requisitos individuais
estão em conformidade com os padrões definidos?
� Se há um não conformidade, ela foi justificada?
Revisão de requisitos: checklists
• Rastreabilidade
� Os requisitos estão identificados de forma não
ambígua?
� Os relacionamentos entre requisitos estão claramente
estabelecidos?
� Há uma referência à fonte dos requisitos e à
justificativa de sua existência?
� Há uma associação clara entre os requisitos do 
software e requisitos mais gerais definidos na
engenharia de sistemas?
Revisão de requisitos: checklists
questões atributo de qualidade
rastreabilidade, conformidade com normas
compreensibilidade
compreensibilidade, completude
ambiguidade
consistência, redundância
completude
organização, rastreabilidade
cada requisito está identificado de 
forma única?
os termos especializados aparecem 
no glossário?
o requisito depende de outros para se 
compreender o seu significado?
há requisitos que usam o mesmo termo com 
sentidos diferentes?
o mesmo serviço é solicitado em vários 
requisitos? há contradições nestas solicitações?
se os requisitos fazem referência a outras facilidades, 
isso está descrito em outro lugar no documento?
os requisitos relacionados estão agrupados? se não 
como se referenciam mutuamente?
Critérios de qualidade em listas
de verificação de requisitos
O requisito pode ser testado? Há informação suficiente para que
testes possam ser criados para verificá-lo?Testável
A especificação trata da definição do produto e não com questões
de desenho, arquitetura e código?
Independência
de código
O requisito pode ser implementado com os recursos disponíveis?Viabilidade
O requisito é realmente necessário? Há alguma necessidade de 
interessados que o sustentam?Relevância
A descrição é feita de forma que não haja inconsistências na
própria descrição ou com outros itens da especificação?Consistência
A descrição do requisito não é vaga, inexata? Tem uma única
interpretação? É facil de ler e entender?
Precisão e 
clareza
O requisito define apropriadamente seu objetivo? Não há erros na
sua especificação?Acurácia
Há algum requisito ausente ou esquecido?Completeza
O que deve ser consideradoAtributo
Problemas nos requisitos: exemplos
o que acontece se os dados da encomenda forem introduzidos antes
de ser conhecido o estado do crédito do cliente? 
o que significa "congelar" a encomenda? 
o requisito 13.2 diz que a interface com o usuário deve ser 
através de browser, e o requisito 23.1 diz que a interface deve ser em html
requisito não completo
ambiguidade
conflito, compreensibilidade
Prototipagem
• se num projeto já foram usados protótipos 
para a identificação de requisitos, então faz 
sentido que o sejam também na validação 
Prototipagem
selecionar os 
testadores
do protótipo
desenvolver
cenários de
teste
executar
cenários
documentar 
problemas
documentar e estender os protótipos
Prototipagem
• Elaboração de um rascunho do manual do usuário
durante a prototipação:
– reescrita dos requisitos noutro formato pode ajudar a 
validá-los 
– é necessário compreendê-los bem o que pode revelar 
conflitos, omissões e inconsistências
– Informações que devem ser incluídas no manual
• descriçãodas funcionalidades implementadas e da forma de as 
aceder (interfaces)
• menção às partes do sistema não implementadas
• como recuperar de dificuldades
• como instalar o protótipo
Verificação de modelos
• parte da especificação de requisitos de um 
sistema pode ser constituída por vários 
modelos
• a validação de modelos tem como objetivos
– 1. avaliar individualmente a consistência de 
cada modelo
– 2. avaliar a consistência externa (entre modelos)
– 3. mostrar que os modelos refletem os 
requisitos reais dos stakeholders
Teste de requisitos
• um requisito "testável" significa que se pode 
definir um ou mais testes a realizar no 
sistema final de forma a poder ser 
verificado se o sistema cumpre o requisito
– cada requisito funcional no documento de 
requisitos deve ser analisado e um teste ser 
definido de forma a ser verificado 
objetivamente se o sistema satisfaz o 
requisito 
Teste de requisitos
• registro de caso de teste
– 1. identificador
– 2. requisitos testados (ou cenários/casos de utilização*)
– 3. descrição do teste
– 4. dados de teste (dados de entrada e saídas esperadas)
– 5. procedimento de teste
– 6. dependências em relação a outros casos de teste
(*) abordagem recomendada: 
- testes baseados em cenários de utilização
- testar cenários normais e excepcionais
Teste de requisitos: exemplo
R9.5 - o sistema deve permitir ao administrador mudar as permissões 
de acesso de um usuário e assim proibir o acesso a uma ou mais opções do menu
teste aplicado: para cada classe de
usuário proibir e permitir o acesso a
três opções; verificar se as permissões 
dos outros usuários funcionam de
acordo com o esperado
problema: as permissões são
aplicáveis a todas as opções? 
como aplicar permissões a um
conjuntos de opções?