Quando requisitos ruins acontecem para pessoas boas

A maior conseqüência de requisitos ruins é o retrabalho – fazer novamente algo que você já tinha acabado. Retrabalho pode consumir de 30 a 50 por cento do custo total de desenvolvimento (Boehm e Papaccio 1988), e erros de requisitos representam de 70 a 85 por cento do custo do retrabalho (Leffingwell 1997). É bem mais caro corrigir um erro no meio do projeto do que se fosse corrigido um pouco antes de sua criação. (Grandy 1999). Prevenindo erros de requisitos e os identificando logo no inicio, é um esforço super favorável para evitar o retrabalho. Imagine como seria diferente sua vida se pudesse reduzir o retrabalho quase por completo! Você poderia construir produtos de forma mais ágil, construindo mais e melhor no mesmo período de tempo, e talvez até possa ir pra casa ocasionalmente.

Todo projeto tem requisitos!

Frederick Brooks declarou de forma eloquente a regra principal sobre requisitos de software em seu clássico de 1987 de forma bem simples, "Não existe bala de prata: Essência e Acidentes da Engenharia de Software":

A parte mais difícil de construir um software é decidir precisamente o que construir. Nenhuma outra parte do trabalho conceitual é mais difícil do que estabelecer em detalhes dos requisitos técnicos, incluindo todas as interfaces para pessoas, maquinas, e outros sistemas. Não existe outra parte do trabalho que foda tanto com o sistema se for feito errado. Não existe parte mais difícil para refazer.

Todo software ou componente de software tem usuários que contam com suas funcionalidades para facilitar suas vidas. O tempo gasto para entender as necessidades dos usuários é um alto investimento para o sucesso do projeto. Se os desenvolvedores não escrevem requisitos que os clientes concordem, como podem satisfazer seus clientes?

Também é impossível especificar completamente os requisitos depois do inicio da construção. Em alguns casos é possível a aplicação de métodos incrementais e iterativos para escrever requisitos parte por parte, recebendo a aprovação do cliente a cada ciclo de iteração. Mas isso não é desculpa para começar a escrever código antes de escrever a parte dos requisitos referente a iteração. Interagir com código é muito mais complicador que interagir com conceitos.

Muitas vezes as pessoas encaram como um obstáculo gastar tempo escrevendo requisitos, mas escrever requisitos não é a parte mais difícil, difícil é descubrir os requisitos. Escrever requisitos é esclarecer, elaborar e transcrever. O entendimento sólido dos requisitos do produto assegura que seu time vai trabalhar no problema certo e que vão encontrar a melhor solução para o problema. Requisitos deixam você priorizar o trabalho e estimar o esforço e os recursos necessários para o projeto. Sem entender os requisitos você não consegue dizer se o projeto está acabado, determinar se atingiu seus objetivos, ou tomar decisões quando uma redução do escopo é necessária