Algum tempo atrás Martin Fowler publicou um artigo denominado "A nova Metodologia". No trecho abaixo, extraído e adaptado desse artigo, foi abordado um aspecto que costumo enfatizar nas aulas de Engenharia de Requisitos.

Há um comentário que eu escuto em todos os projetos problemáticos que encontro . Os desenvolvedores vêm a mim e dizem: "o problema com este projeto é que os requisitos estão sempre mudando". O que acho surpreendente a respeito dessa situação é que alguém ainda se surpreende com ela. Se mudanças em requisitos de negócio ao construir software são a regra, a pergunta é o que devemos fazer a esse respeito.

Um caminho é tratar requisitos mutantes como resultado de uma engenharia de requisitos pobre. A idéia por trás da engenharia de requisitos é a de obter uma visão completamente clara dos requisitos antes de começar a construir o software, obter uma aprovação do cliente destes requisitos, e depois implantar procedimentos que limitam mudanças nestes requisitos.

Um problema com isto é que apenas entender as opções para os requisitos já é difícil. E é ainda mais difícil pois normalmente a empresa que desenvolve o software não provê as informações do custo dos requisitos. Você acaba em uma situação onde você tem uma certa vontade de comprar um teto solar para o seu carro, mas o vendedor não pode lhe dizer se isso aumenta o custo do carro em $10 ou $10.000. Sem muita idéia do custo, como você pode decidir se realmente quer pagar pelo teto solar?

Estimativas são difíceis por vários motivos. Parte é por que desenvolvimento de software é uma atividade de design, portanto difícil de planejar ou custear. Parte é por que os materiais básicos se mantêm sempre mudando rapidamente. Parte é por que depende muito de quais pessoas estão envolvidas, e pessoas são difíceis de prever ou quantificar.

A natureza intangível do software também contribui. É muito difícil ver o valor de uma funcionalidade do software até que ela seja materializada. Apenas quando você vê uma versão preliminar do software você realmente começa a entender que funcionalidades são valiosas e quais não são.

Isso leva ao ponto irônico onde as pessoas esperam que os requisitos sejam mutáveis. Afinal de contas, o software deve ser "soft". Assim não somente os requisitos são mutáveis, mas espera-se que assim o sejam. Gasta-se muita energia para que os clientes consertem os requisitos. É ainda pior se eles já estiveram de alguma forma envolvidos em desenvolvimento de software, pois aí eles "sabem" que é fácil de modificar software.

Mas mesmo que você pudesse concordar e realmente conseguisse um conjunto preciso e estável de requisitos, ainda assim isso provavelmente não seria suficiente. Na economia de hoje, as forças de negócio fundamentais estão mudando o valor dos requisitos de software muito rapidamente. O que pode ser um bom conjunto de requisitos agora, não será um bom conjunto de requisitos em seis meses. Mesmo que os clientes possam fixar seus requisitos, o mundo dos negócios não vai parar para eles. E muitas mudanças no mundo dos negócios são completamente imprevisíveis: qualquer um que diga o contrário está ou mentindo, ou já conseguiu um bilhão de dólares no mercado de ações .

Tudo mais no desenvolvimento de software depende dos requisitos. Se você não pode obter requisitos estáveis, então você não pode ter um plano de projeto estável.