Técnicas de validação
Revisões dos requisitos Uma equipe de revisores pode analisar sistematicamente a especificação produzida de forma a garantir que esta corresponde ao sistema pretendido; em revisões informais, a equipe de revisores pode simplesmente ter uma conversa, envolvendo o maior número possível de representantes das partes interessadas, acerca dos requisitos produzidos; em revisões formais, a equipe de revisores deve confirmar junto do cliente um conjunto de critérios que todos os requisitos devem cumprir, nomeadamente: verificabilidade, compreensibilidade (por parte dos utilizadores finais), rastreabilidade (a origem dos requisitos deve ser identificável) e adaptabilidade (capacidade de sofrer alterações sem produzir efeitos em todos os outros requisitos).
Prototipificação
(Ou prototipação) A implementação de um protótipo (por exemplo, da interface do sistema) pode ser útil para os utilizadores finais (e demais interessados), já que se trata do elemento do sistema final com o qual terão mais contacto quando o sistema estiver operacional; esta técnica também é eficaz, embora tenha desvantagens: o tempo gasto na sua implementação pode não justificar o seu uso, pode enviesar os utilizadores (levando a desilusões com a versão final do sistema, no caso de esta ser muito diferente do protótipo) e pode ainda levar os programadores a cair na tentação de usar o protótipo para continuar o desenvolvimento do sistema (pelo que, idealmente, o protótipo deva ser implementado noutra linguagem que não aquela usada pelo sistema, eliminando por completo esta tentação).
Geração de casos de teste
Uma vez que cada requisito deve ser testável, deveria ser possível criar (desenhar) os respectivos testes desde a fase de validação de requisitos; se isto não for possível, é sinónimo de que a implementação deste requisito será difícil e que este poderá ter de ser reconsiderado.
Análise de consistência automática
Através da especificação formal de modelos para o sistema é possível, recorrendo a ferramentas adequadas (como as ferramentas CASE), testar de forma automática a consistência dos modelos criados; apenas a consistência é testada nesta técnica, pelo que tem de ser complementada com uma das outras técnicas referidas.
Item correto.
Técnicas de Validação de Requisitos.
• Revisões de Requisitos: análise sistemática e manual dos requisitos.
Um grupo de revisores é alocado para examinar a especificação dos requisitos do software: verificando que esse documento satisfaz os critérios de qualidade desejados; procurando por: erros no conteúdo ou de interpretação; hipóteses confusas ou equivocadas; falta de clareza na descrição dos requisitos; desvios em relação aos padrões estabelecidos no processo ou projeto; falta de alguma informação; inconsistências entre requisitos; requisitos não alcançáveis.
• Prototipação: utilização de um modelo do sistema para validar seus requisitos.
Meio de validar a interpretação do analista de requisitos sobre os requisitos do software.
Vantagem: as hipóteses e interpretações do analista de requisitos sobre os requisitos do software são mais facilmente visualizadas, permitindo identificar onde ele está enganado, se for o caso. Desvantagem: perigo da atenção do usuário desviar-se das funcionalidades do sistema para questões cosméticas ou problemas de qualidade do protótipo.
• Validação do Modelo de Análise: validação dos modelos produzidos durante a Análise de Requisitos.
A qualidade dos modelos desenvolvidos durante a Análise de Requisitos normalmente também é validada. Se notações formais foram utilizadas para especificar os requisitos do software é possível utilizar procedimentos automatizados para provar algumas características do modelo de análise.
• Geração de Testes de Aceitação: desenvolvimento de testes para os requisitos.
Propriedade essencial de todo requisito de software: deve ser possível validar que o produto final o satisfaz. Essa técnica consiste em desenhar testes de aceitação que serão utilizados para verificar a conformidade do produto final com cada requisito de software. Requisitos que não podem ser validados por meio de testes de aceitação não são requisitos.
Bibliografia
PRESSMAN, Roger S. Engenharia de Software. 5ª ed., Rio de Janeiro: McGraw Hill, 2002, capítulos 10 e 11.
IEEE. SWEBOK: Guide to the Software Engineering Body of Knowledge. 2004,capítulo 2.