Dividir para conquistar

Qualquer especificação de sistema ("A especificação"), costuma ser grande e cheia de furos, faltando detalhes importantes, explicando parcialmente o processo, assumindo conhecimento comum em partes que somente um especialista de negócio saberia entre outros horrores.

Particularmente, penso que o problema está no tamanho da coisa. É meio simplória a idéia, mas veja:
1 - Qto maior, naturalmente mais complexo (senão é encheção de linguiça), portanto, mais difícil de estimar. É por isso que costumamos quebrar em funcionalidades primeiro.
2 - Em uma massaroca de detalhes, é fácil deixar escapar alguns importantes, tb é fácil deixar de incluir algum importante inadvertidamente.
3 - O mesmo texto frequentemente mistura overview do sistema com detalhes dos módulos, quando mal redigido (e frequentemente é), causa uma tremenda confusão. Já vi especificações que não seguiam uma linha de pensamento, descrevendo módulos e funcionalidades ao léu.

Pois bem, parte do problema seria resolvido se a mesma pessoa que redige a especificação fosse um especialista no sistema E um bom escritor. Porém, mais frequentemente do que eu gostaria, é um analista de sistema que não é nem uma coisa, nem outra.

Inspirado em User Stories e Use Cases, fico imaginando se "A" especificação não deveria na verdade ser toda picotada. Textos menores descrevendo casos de uso ou funcionalidades, mais um overview que juntasse as partes. Fica mais fácil avaliar e pensar em cada parte e verificar os detalhes, tudo porque um texto menor e mais focado é menos em que se pensar.

Será que consigo fazer um teste com isso?