Requisitos muitas vezes parecem progresso.

Workshops acontecem.
Partes interessadas contribuem.
As listas crescem.

O que emerge é um catálogo de desejos.

Uma pessoa fica encarregada de dar sentido a isso.

Reunir tudo.
Estruturar.
Encontrar a solução que satisfaça a todos.

Esse papel já nasce fadado ao fracasso.

Porque o problema não é falta de estrutura.

É falta de decisões.

A maioria do que chamamos de requisitos, na verdade, não são requisitos.

São:

• suposições

• preferências

• conflitos não resolvidos

Registrados no papel em vez de decididos.

Então a lista cresce.

E, com ela:

• complexidade

• expectativas

• custo

Sem aumentar a clareza.

Uma abordagem melhor é desconfortável.

Reduza a lista.

Identifique um conjunto limitado de requisitos significativos.

Não centenas.

Muitas vezes, menos de cem.

Cada um precisa ser:

• fundamentado em um problema real

• claramente distinto

• relevante para a tomada de decisão

Isso força alinhamento.

O que importa fica.
O que não importa, desaparece.

Nesse ponto, a avaliação se torna possível.

Não:

“Este sistema consegue fazer tudo?”

Mas:

“Quão bem ele corresponde aos requisitos característicos?”

Se uma solução atende bem a esses pontos,
provavelmente cobrirá o restante a um custo razoável.

Na prática, essa seleção precisa de um lugar para existir.

Não em slides.

Ela se torna um conjunto de trabalho de requisitos de referência:

cada requisito é:

• formulado com clareza

• ligado a um problema

• atribuído com importância relativa

Quando as soluções são avaliadas, elas não são comparadas de forma genérica.

Elas são testadas contra esse conjunto.

A cobertura fica visível.
As lacunas ficam explícitas.
Os trade-offs podem ser discutidos.

Isso transforma a avaliação em uma conversa estruturada.

Não uma negociação de opiniões.

A diferença é pequena.

O efeito, não.