Validação de Requisitos
Objetivo: A validação de requisitos tem como objetivo validar a consistência, completeza e precisão dos requisitos a partir do documento de especificação de requisitos de software.
Envolvidos: Clientes, engenheiro de requisitos e engenheiro de software validam o SRS a fim de descobrir problemas, omissões e ambiguidades nos requisitos.
Análise versus Validação
Foram elicitados os requisitos corretos?
Os requisitos foram elicitados corretamente?
Inputs e outputs
![[Início da descrição]
A validação de requisitos: Especificação, Conhecimento da organização, Padrões, Lista de problemas, Plano de ação.
[Fim da descrição]](img/img-1.jpg)
Revisão de requisitos
- Técnica mais comum na validação de requisitos.
- Trata-se da revisão da Especificação por um grupo de pessoas as quais se reúnem para discutir os problemas encontrados e definir soluções para os mesmos.
Processos/Etapas de revisão de requisitos
![[Início da descrição]
*Processos/Etapas de revisão de requisitos*
Início SRS:
1. Planejamento.
2. Distribuição.
3. Revisão.
4. Avaliação.
5. Encaminhamento.
6. Revisão: Fim SRS novo.
[Fim da descrição]](img/img-2.jpg)
Definição das pessoas a serem envolvidas, data e local da reunião de avaliação.
2. Distribuição da Especificação
Distribuição da documentação de requisitos para os revisores.
Cada revisor revisa a especificação a fim de detectar problemas.
Cada revisor expõe os problemas encontrados e juntos decidem como encaminhar cada um deles.
O coordenador da revisão dá encaminhamento as ações.
A especificação é revisada a fim de certificar-se que os problemas foram corrigidos.
Possíveis ações
- Reescrita: o autor do requisito deve reescrevê-lo a fim de melhorar sua descrição
- Complementação: o autor do requisito deve acrescentar informações
- Correção: erros e conflitos devem ser discutidos com os clientes
- Exclusão: requisito não viáveis devem ser “excluídos”
Pré-visão
- É recomendado que uma pessoa faça uma pré-revisão da documentação antes de passar para os revisores
- Tem como objetivo detectar não conformidades com o modelo de documentação utilizado
- Evita que vários revisores reportem os mesmos problemas referentes a documentação
Seleção de pessoal
- Idealmente a equipe deve ser multidisciplinar
- Usuário-final
- Cliente
- Analista de negócio
- Engenheiro de software
- Gerente de desenvolvimento
- Engenheiro de requisitos
Checklist
deve ter como foco a qualidade da documentação:
- clareza
- redundância
- completeza
- ambigüidade
- consistência
- organização
- conformidade com o padrão
- rastreabilidade
deve ter como foco a qualidade da documentação:
- clareza
- redundância
- completeza
- ambigüidade
- consistência
- organização
- conformidade com o padrão
- rastreabilidade
- Cada requisito possui identificação única?
- Todos os termos específicos estão no glossário?
- É possível entender os requisitos individualmente?
- Há algum termo utilizado de diferentes formas?
- Uma função aparece em mais de um requisito?
- Existe alguma contradição entre os requisitos?
- As relações entre os requisitos estão claras?
Outras técnicas
- Prototipação
- Desenvolvimento de manual do usuário
- Criação de planos de teste
Referências
- KOTONYA, G., SOMMERVILLE, I. Requirements Engeneering: processes and techniques. Chichester: John Wiley & Sons, 1998. 282p.
- SOMMERVILLE, I. Engenharia de Software. 6a ed., [S. L.]: Addison-Wesley, 2000. 693p