O desenvolvimento de software nos dias atuais demanda por prazos e custos reduzidos, e qualidade elevada. Conjugar esses três fatores no processo de desenvolvimento não é tarefa fácil e  uma das coisas que pode ajudar a obter um software de qualidade é exatamente a qualidade do requisito que foi elicitado. Veja abaixo oito características de um bom requisito:
 

1. viável – pode ser realizado dada as restrições de recursos, orçamento, conhecimento, cronograma e tecnologia disponível para o projeto

2. válido – é um requisito que o sistema “deve” atender, sendo revisado pelo solicitante do produto a ser desenvolvido. Deve-se diferenciar dos requisitos “desejáveis” , os quais acarretam custos sem agregar valor e podem atrasar a entrega do projeto

better

3. inequívoco – requisitos devem ter uma interpretação única, sem ambiguidades: exemplos:

–o sistema de dados deve resistir a uma catastrofe (incêndio e ou inundação?)

–o relógio deve ser a prova d’agua (a qual profundidade?)

Requisitos ambíguos trazem como consequências atrasos no projeto e aumento de custos

4. verificável – ocorre quando o produto final pode ser testado para garantir que ele atende aos requisitos especificados. Exemplos: a) o carro deve ter freios (verificável); b) o carro deve parar completamente a 60 Km por hora em 5 segundos (inequívoco e verificável)

5. modificável – especificação do requisito de forma coerente, com fluxo claramente definido e sem redundância. A informação é colocada em apenas um lugar, sendo que se houver necessidade de alteração não há cascateamento para outros requisitos

6. consistente – não há conflitos com outros documentos do projeto ou da organização

7. completo – todos os requisitos corretos e relevantes estão presentes e há informação suficiente para a construção do produto. Completude implica em:

–respostas esperadas do sistema para as diversas variáveis de entrada (entradas válidas e inválidas)

–descrição completa de figuras, tabelas e diagramas, bem como glossário de termos e unidade de medidas

–quantificação dos requisitos não funcionais: critérios testáveis devem ser definidos para todos requisitos não funcionais

8. rastreável – a fonte do requisito pode ser identificado; qualquer componente que implemente o requisito pode ser identificado; todos os casos de testes que verificam esse requisito podem ser identificados