Você está na página 1de 26

Engenharia de Requisitos

Verificação e Validação
Verificação X Validação
• Verificação
– Estamos construindo o produto de maneira certa?
(em relação a outros produtos)

• Validação
– Estamos construindo o produto certo? (em
relação a intenção dos fregueses)

2
O Processo de Engenharia de Requisitos
Engenharia de Requisitos
Verificação de requisitos
• Objetivo:
– Avaliar se os requisitos realmente representam o
sistema que o usuário deseja;
– Descobrir problemas;
– Revisar os requisitos identificados.

5
Validação de requisitos
• Objetivo:
– Dedica-se a mostrar que os requisitos definem o
sistema que o cliente realmente deseja.
– Custos de erros de requisitos são altos e, desse
modo, a validação é muito importante.
– O custo da reparação de um erro de requisitos
depois da entrega pode equivaler a 100 vezes o
custo de reparação de um erro de implementação.
– Requer a aprovação do cliente
• Ajuste no documento → Adicionar lista de aprovadores.
6
Verificação de requisitos
• Verificação de completeza.
– Todas as funções requisitadas pelo cliente foram
incluídas?
– Técnica: Reunião de inspeção
• Verificação de realismo.
– Os requisitos podem ser implementados com o
orçamento e a tecnologia disponíveis?
– Técnica: Estudo de viabilidade

7
Verificação de requisitos
• Facilidade de verificação.
– Os requisitos podem ser verificados?
– Técnica: Reunião de inspeção
– Técnica: Geração de casos de testes

• Verificação de consistência
– Existe algum tipo de conflito de requisitos?
– Técnica: Reunião de inspeção
– Técnica: Geração de casos de testes
8
Validação de requisitos
• Verificação de validade
– O sistema fornece as funções que melhor apóiam
as necessidades do cliente?
– Técnica: Criar um protótipo e solicitar que o
usuário use o protótipo para realizar as
funcionalidades solicitadas
– Técnica: Reunião de inspeção

9
Técnicas de VeV de requisitos
• Estudo de Viabilidade
• Prototipação
– Uso de um modelo executável do sistema para
verificar requisitos.
• Pode ser de alta ou baixa fidelidade
• Reunião de Inspeção
– Análise manual sistemática dos requisitos.
• Geração de casos de teste.
– Desenvolvimento de testes para requisitos a fim de
verificar a testabilidade. 10
O Processo de Engenharia de Requisitos
Prototipação
• Elicitar reações do tipo “sim, mas…”
• O protótipo pode ser:
– Passivo: o usuário não pode interagir com o aplicativo;
– Ativo ou interativo: o usuário interage com o aplicativo
• Identifica atores, explica o que acontece a eles e
descreve como acontece;
• Mais eficazes se o projeto tiver conteúdo inovador
ou desconhecido
• Tipo: baixa fidelidade x alta fidelidade

12
Protótipos
• Vantagens:
– Barato
– Amigável, informal e interativo
– Fornece uma crítica das interfaces do sistema
cedo no desenvolvimento
– Fácil de criar e modificar

13
Protótipos
• Links interessantes:
• Baixa fidelidade:
– http://www.youtube.com/watch?v=6RBXWXA95gE
– http://www.youtube.com/watch?v=pLe81h7wTF4
– http://www.youtube.com/watch?v=XkBGNN7G-rY
• Alta fidelidade
– http://www.youtube.com/watch?v=ZrRlWh9ENog
– http://www.youtube.com/watch?v=AvZrFevPiRA
O Processo de Engenharia de Requisitos
Inspeção de requisitos
• Inspeções regulares devem ser feitas enquanto a
definição de requisitos está sendo formulada (de
preferência a cada etapa concluida).
• Os stakeholders devem ser envolvidos nas reuniões
• As inspeções podem ser formais (com documentos
completos) ou informais. Uma boa comunicação
entre desenvolvedores, clientes e usuários pode
resolver problemas nos estágios iniciais.

16
Inspeções
• Criadas em 1972 por Fagan, na IBM, para melhoria
da qualidade de código
• Hoje são utilizadas em qualquer tipo de artefato
gerado pelo processo de desenvolvimento
• Inspeção pode detectar de 30% a 90% dos erros
existentes
• Técnica de leitura aplicável a um artefato, buscando a
localização de erros ou defeitos no mesmo, segundo
um critério pré-estabelecido

17
Inspeções em Requisitos
Planeja- Visão Detecção Coleção Correção Acompa-
mento geral nhamento

•Organizador
•Moderador
Processo
•Inspetor • a serem
Papéis Inspeção Artefatos inspecionados
•Autor
• para conduzir a
•Secretário inspeção
•Relator Técnicas de leitura
• Documento completo
• Check lists
• Seguindo os erros encontrados

18
Inspeções em Requisitos
• Tipos de inspeção:
– Informal
• O autor solicita, por email por exemplo, que o moderador
inspecione o artefato desejado.
• Após a avaliação do artefato o moderador envia um email
com a lista de erros/melhorias identificados
• O autor corrige e envia o artefato atualizado para o
moderador
• O moderador verifica se os itens levantados foram
corrigidos.

19
Inspeções em Requisitos
• Tipos de inspeção:
– Formal (mini)
• O autor prepara o doc de inspeção que consta: o documento a ser
inspecionado, os papéis (autor e moderador são obrigatórios), o
checklist indicado para o artefato
• O autor agenda uma reunião com o moderador para a inspeção
• O moderador avalia os artefatos de acordo com o doc de inspeção
• Durante a reunião o moderador levanta os erros/melhorias e
anota no doc de inspeção.
• O autor corrige e envia o artefato atualizado para o moderador
• O moderador verifica se os itens levantados foram corrigidos.

20
Inspeções em Requisitos
• Tipos de inspeção:
– Formal
• Similar a mini inspeção
• Exige a presença de inspetores além do moderador

21
Inspeções em Requisitos
• Inspeções baseadas em check lists:
– Inspetores utilizam uma lista com os itens a serem
verificados
– Cada artefato tem uma lista específica (Documento de
Requisitos, Casos de Uso, Modelos, etc)
– Os defeitos são anotados no artefato sendo analisado
– Após a revisão, é realizada uma reunião onde os
problemas encontrados são relatados aos desenvolvedores

22
Checklist
• Pontos a serem avaliados/observados durante
o processo de inspeção
• Depende do material a ser inspecionado
(casos de uso, cenários, código, etc)
• Depende do enfoque da inspeção
• Taxonomia dos defeitos - o que procurar

23
Exemplo Checklist
• Checklist Requisitos:
– Os requisitos estão claros e precisos?
– Os requisitos são testáveis?
– Há requisitos conflitantes?
– A descrição dos requisitos está suficiente para o
entendimento da funcionalidade?
– Os requisitos seguem uma sequencia lógica?
– Há erros de português?

24
Geração de Casos de Teste
• Para todos os requisitos, funcionais e não
funcionais são descritos cenários de possíveis
testes.
• Para cada teste é necessário descrever:
– Ambiente
– Estado do sistema
– Valores de entrada de dados
– Passo a passo da execução
– Resultados esperados.
25
Exercício
• Baseado nos casos de uso e nas telas feitas no
seu projeto, agora faça o protótipo.
– Pode ser ativo ou passivo;
– De baixa ou alta fidelidade;