Validação de requisitos

A validação de requisitos ou validação de software é um Processo da Engenharia de Requisitos . Este processo trata, tal como o seu nome indica, da validação quanto à consistência, precisão, contextualização de requisitos levantados no processo de identificação e descoberta e de análise e negociação de requisitos. Este processo envolve uma revisão de todos os requisitos levantados e negociados, assim como uma prototipagem e validação de modelos e teste de requisitos.

Este processo é um dos mais importantes na Engenharia de Requisitos. Isto porque tal como um documento de requisitos bem definido permite a correcção de incoerências e inconformidades no desenvolvimento de um produto de software, a validação permite minimizar o tempo gasto na detecção dessas incoerências e inconformidades devido à sua alta eficiência na sua descoberta. Também porque como é este processo que permite a identificação destas mesmas incoerências na fase anterior à versão final do relatório de requisitos, minimiza grandemente o risco de encontrar estas incoerências numa fase tardia, ou até mesmo na terminação, do desenvolvimento do sistema. É fácil entender que um erro encontrado numa fase tardia do desenvolvimento do projecto pode ser desastroso, pois a sua alteração poderá ser bastante custosa, se não incomportável, em termos temporais.

Poderemos afirmar que o processo de Validação de requisitos está para o documento de requisitos assim como a fase de testes unitários e de sistema está para a fase de desenvolvimento de um projeto de software.

Problemas Comuns Resolvidos no Processo de Validação

O processo de análise e negociação de requisitos agrega um grande volume de informação pouco estruturada e informal cedida pelos Stakeholders e tenta ir ao encontro das reais necessidades destes, através da estruturação, organização e interpretação desta informação e através da negociação desta nova reformulação da informação com os StakeHolders. Podemos fazer uma analogia, talvez algo rebuscada, com um Datamining de uma base de dados. Resumidamente o datamining é um processo que automaticamente procura em grandes volumes de dados padrões de informação através da utilização de regras lógicas e retira uma informação resumida organizada e estruturada desses grandes volumes de dados. Com o processo de análise e negociação o conceito é basicamente o mesmo. Recebe-se grandes volumes de dados dos StakeHolders e procura-se padrões de informação nesses, de maneira a chegar a regras que nos indiquem o real interesse do StakeHolder. Após o processo de análise e negociação de requisitos obtemos um rascunho final do nosso documento de requisitos. Então os problemas que podem ser resolvidos no processo de validação podêm ser os seguintes:

1. O não seguimento das normas de qualidade do projecto e da empresa
2. Descrição pouco clara dos requisitos
3. Falhas na modelação dos requisitos
4. Conflitos entre requisitos que não foram detectados no processo de análise
5. Requisitos não realistas
6. Falta de informação

Métodos de Resolução

Para resolver os problemas anteriormente descritos:

O não seguimento das normas de qualidade do projeto e da empresa

Deve-se reformular todos os incumprimentos do documento com as normas de qualidade, mas tendo atenção para não alterar os conceitos, definições que a estruturação do documento em incumprimento têm, de maneira a que esta resolução não crie outros problemas.

Descrição pouco clara de algum requisito

Clarificação do requisito com o equipamento e com o resto da equipe. Se necessário contactar novamente com os Stakeholders. Reescrita do requisito após clarificado e discutido a sua nova descrição.

Falhas na modelação dos requisitos

Reformulação dos modelos utilizados para a representação dos requisitos, utilizando a solução descrita no ponto anterior (2.1.2).

Conflitos entre requisitos que não foram detectados no processo de análise

Neste caso, a comunicação com os stakeholders é essencial para a resolução dos conflitos entre os requisitos. Esta solução pode voltar a necessitar de alguns dos métodos usados no processo de Análise e negociação.

Requisitos não realistas

Deve ser estudado uma reformulação destes requisitos de forma a tornar este mais realista. Caso não seja possível, este deve ser simplesmente retirado.

Falta de informação

Deve ser identificada toda a informação em falta e adicionar esta ao documento, tendo atenção para não criar inconsistências nos requisitos já existentes.

Técnicas no Processo de Validação

Consegue-se entender então que o processo de Validação de Requisitos têm como "variáveis" de entrada o esboço vindo do processo de Análise e Negociação de Requisitos, as normas de qualidade da organização/projecto em que se insere e do conhecimento empírico obtido de outros projectos. Este processo "retorna" uma lista de problemas que devem ser resolvidos. Iterativamente o processo vai finalizar com o "retorno" de uma versão final do documento de requisitos. Mas falta ainda saber quais as técnicas eficazes utilizadas para realizar este processo. Existem algumas técnicas possíveis como por exemplo as explicadas em pormenor em priscilla_pagliuso.pdf [1].

Revisão dos Requisitos

A revisão de requisitos deverá ser feito numa reunião formal onde deverá estar presentes um utilizador final ou um representante deste, um especialista do domínio, um representante do cliente, os responsáveis pelo desenho do sistema e os engenheiros de requisitos. É importante que esta reunião seja conduzida por alguém que esteja dentro do projecto mas não esteve envolvido na realização do documento de requisito, de forma a este conduzir a reunião de uma forma rigorosa e "livre de vícios". Antes da realização da reunião formal é necessário existir um planejamento cuidadoso da revisão a ser efetuada na reunião. Neste planeamento devem ser preparadas checklists de revisão genéricas e não deverão incidir sobre requisitos individuais mas sim nas relações dos requisitos, assim como as propriedades de qualidade do documento. Os seguintes atributos de qualidade deverão ser tomados em conta na formulação da checklist:

1. compreensibilidade
2. redundância
3. completude
4. consistência
5. organização
6. conformidade com as normas
7. rastreabilidade

Na tabela em baixo poderá ser visto um modelo de questões a seguir na formulação dos atributos de qualidade das checklists:

Questões	Atributo de Qualidade
questões atributo de qualidade	rastreabilidade, conformidade com normas
os termos especializados aparecem no glossário	compreensibilidade
o requisito depende de outros para se compreender o seu significado?	compreensibilidade, completude
há requisitos que usam omesmo termo com senti dos diferentes?	ambiguidade
o mesmo serviço é solicitado em vários requisitos? há contradições nestas solicitações?	consistência, redundância
se os requisitos fazem referência a outras facilidade,isso está descrito algures no documento?	completude
os requisitos relacionados estão agrupados? se não como se referenciam mutuamente?	organização, rastreabilidade

Devem ser distribuídos os documentos necessários para a reunião a todos os futuros envolvidos nesta assim como haver uma preparação prévia de todos. Na reunião cada requisito deve ser apresentado à vez para discussão pelo grupo, sendo tomado nota de todos os problemas identificados. As soluções para os problemas identificados apenas serão discutidos no final de todos os requisitos serem apresentados.

Prototipagem

No processo de análise e negociação de requisitos desenvolveu-se um protótipo para facilitar na recolha de requisitos pois é usalmente mais fácil para os Stakeholders conseguirem identificarem exatamente o que querem de uma forma visual e aproximada do que poderá ser o produto final. Logo também será mais fácil na fase de validação de requisitos validar estes através do mesmo processo. Obviamente que através do prototipo visual é mais fácil detectar inconsistências e problemas nos requisitos. É também de referir a possibilidade de iniciar-se já nesta fase os manuais de utilização (pois normalmente são implementadas as interfaces). Deve-se notar duas pequenas desvantagens na utilização desta técnica. A implementação de um prototipo poderá levar a desilusões para os utilizadores finais, quando as interfaces da versão final não correspondem exactamente às do prototipo e poderá tentar os programadores a utilizar o protótipo como uma continuação do desenvolvimento do sistema. Também se deverá ter em conta o tempo gasto na implementação do prototipo e medir se este tempo no final será compensado pelas vantagens trazidas por este.

Validação de Modelos

Uma especificação de requisitos de um sistema pode ser constituída por variadíssimos modelos, que obviamente necessitam de ser validados. Essa validação deverá avaliar individualmente a consistência de cada modelo assim como a consistência entre os vários modelos do sistema. Deverá também verificar se estes modelos realmente representam os requisitos reais dos stakeholders.

Testes de Requisitos

Para cada requisito funcional deve ser possível definir um ou mais testes a serem realizados no sistema final para ser possível verificar se o sistema cumpre o requisito na integra. Se este teste não for possível ser definido isso vai significar que o requisito necessita de ser clarificado pois muito provavelmente irá criar problemas no desenvolvimento do produto. Na definição de cada teste deverá ser tomado em conta os seguintes pontos:

1. identificador do requisito
2. requisitos relacionados
3. descrição do teste
4. problemas na realização do teste
5. comentário e recomendações

Referências

1. Acetatos do Professor António Lucas Soares 2006, Disciplina de ERSS da Faculdade de Engenharia da Universidade do Porto
2. http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER03/priscilla_pagliuso.pdf
3. http://citeseer.ist.psu.edu/72242.html
4. Kotonya e Sommerville (1998). Requirements Engineering: Processes and Techniques. Gerald Kotonya, Ian Sommerville. Wiley. 1998.
5. Sommerville (2001). Software Engineering. Ian Sommerville. Addison Wesley. 2001.