Requerimentos não são Requisitos

Apesar da aparentemente óbvia a diferença entre solicitação de mudança e requisito, vamos definir os dois termos:
Requisito: uma condição que deve ser atendida ou entregue;
Requerimento: uma "requisição" para que algo seja cumprido.

Vejo com frequência o uso de ambos como sinônimos. E podem até ser (acho que o são mesmo), mas neste post chamo de Requerimento o ATO de solicitar algo. Você pode fazer um "requerimento de mudança" no software e/ou projeto e, como resultado, ter um ou mais requisitos alterados e/ou criados. Então temos: Requerimento = Solicitação <> Requisito

A troca de um pelo outro ou a tentativa de resolver o problema de um lado sem cuidar do outro tem causado um bom estrago nas empresas: desde uma burocratização do processo de desenvolvimento até compra desnecessária de ferramentas.

Hoje em dia é bastante difundido que mais da metade dos problemas em projetos de software tem por causa raiz os requisitos (fonte: Chaos Report em http://www.standishgroup.com/) . Seja por falha na definição, no entendimento ou no gerenciamento. Não vou entrar no mérito neste post e acredito até que por essa informação estar bem difundida hoje em dia, é que a reação natural de toda empresa é achar que *todos* (ou quase) os problemas do desenvolvimento de software tem origem nos requisitos.

Ocorre que em qualquer empresa que possua software desenvolvido internamente temos um cenário onde 80%-90% do esforço de desenvolvimento é para manutenção de software e somente 10%-20% são novos desenvolvimentos. Portanto, se temos muito software com requisitos mal definidos ou, o que é bastante comum, nenhum requisito documentado, temos muita modificação no software sem manutenção nos respectivos requisitos (por que ou não existem ou estão desatualizados).

Portanto, quando uma organização decide "entrar de cabeça" no gerenciamento de requisitos, esquece que 80% a 90% do esforço é despendido MODIFICANDO requisitos existentes. Ora, se os requisitos não estão documentados, como proceder então? Estou para ver empresa que tope investir para fazer a engenharia reversa da documentação dos requisitos. Portanto, sobra somente uma alternativa: não modificar o requisito, mas somente a mudança no software.

A resposta certa para este imbróglio é uma abordagem mista: passa-se a documentar os requisitos dos novos desenvolvimentos (ou re-desenvolvimentos de coisas velhas) e catalogar as mudanças em softwares existentes.

Por isto vos digo: você sabe que tem problemas com requisitos, mas vá com calma. Atacar o touro de frente pode não ser a melhor alternativa neste caso: é necessário comer pelas beiradas. Passe a catalogar e controlar mudanças (prática de CM ou Change Management) para todo o backlog de desenvolvimento e documentar requisitos (direito) apenas para os novos desenvolvimentos. Adicionalmente, você pode descobrir que determinados softwares ou cenários recebem mais modificações e pode decidir investir algum tempo para documenta-los e poder avaliar impactos com mais precisão.