Resumindo, por que então descrevemos casos de uso? Porque nos ajuda a entregar um software de qualidade com um prazo/custo menor do que se deixássemos tudo emergir, confiando na refatoração de código - que apesar de ser totalmente viável, por causa do nível de desacoplamento que adotamos, tem um custo elevado dentro do processo de desenvolvimento de sistemas grandes e complexos.
Além das descrições de casos de uso, trabalhamos com outros tipos de artefatos que chamamos generalizadamente de ARCs - Artefatos de Representação do Conhecimento (evitamos propositalmente a palavra documentação), que utilizamos para construir e representar esse conhecimento que depois será mapeado em software pelos programadores - que obviamente precisarão tomar muitas decisões de construção, mas partirão de um problema discutido e mapeado previamente, consistente o suficiente para dar fluidez no planejamento da construção.
Pode parecer estranho para alguns, mas no nosso contexto é natural que existam questões que levarão muitos dias ou semanas para serem respondidas, dependendo de várias reuniões com diferentes pessoas do cliente. Independentemente de quem irá conduzir essas reuniões, o fato é que, neste caso, deixar esse problema emergir no meio da construção para, então, ser analisado me parece muito improdutivo.