Algumas interpretações sobre "Requisitos"

Um problema com a industria de software é a definição para termos que usamos para descrever aspectos de nosso trabalho. Observadores diferentes podem descrever o mesmo problema como um requisito de usuário, requisito de software, requisito funcional, requisito de sistema, requisito técnico, requisito de negocio ou requisito de produto.
O usuário acredita que requisitos sejam algo como conceitos de auto nível do produto. A noção do desenvolvedor está mais para uma interface detalhada que atenda o usuário. Esta diversidade de definições deixa confusa e frustrante a comunicação.

O conceito chave é que requisitos precisão ser documentados. Já estive em projetos em que a experiência ia junto com a rotatividade dos desenvolvedores. Quando um analista vai consultar o cliente sobre requisitos e ele vai dizer “Eu já falei sobre esses seus requisitos agora me faça esse sistema!” Dessa forma só resta trabalhar com pilhas de e-mails desconexos, conversas de corredor, post-its e outros artifícios informais para tentar conhecer os requisitos.

Algumas Interpretações

O IEEE define requisitos como:

1. Uma condição ou capacidade que o usuário necessita para resolver um problema ou atingir um objetivo.
2. Uma condição ou capacidade que precisa ser conhecida ou processada pelo sistema ou componente para satisfazer um contrato, padrão, especificação, ou outro documento formal.
3. A representação documentada de uma condição ou capacidade em 1 ou 2.

Sommerville e Sawyer definem como:

Uma especificação do que precisa ser implementado. Eles são uma descrição do que o sistema precisa ter, ou sobre uma propriedade ou atributo do sistema. Eles devem ser uma constante no processo de desensenvolvimento de sistemas.

Claramente, não existe uma definição universal sobre o que é requisito. Para facilitar a comunicação, precisamos concordar com uma definição comum para que tanto a equipe de desenvolvimento e cliente fale a mesma língua.