существуют разные документы, предназначенные для:
1. заказчика
2. для имплементации бизнес-логики в системе.
3. сношений с тестированием
4. приёмок и прочего.
...
 никогда не будет одного документа, эффективно читаемого как заказчиком, так и разработкой

Согласен, если есть много денег, много времени, и необходимо строго, однозначно и формально фиксировать все факты принятия проектных решений и моменты передачи ответственности за них, то без всего этого не обойтись.  Потому что в процессе такой разработки, кроме продукта, должны появиться и документы, на основании которых прокурор мог бы подписать постановление, если не дай бог, применение продукта принесет кому-либо существенный вред (например, потерю серьезных денег, что возможно в банковских системах, не говоря уже про военные приложения и АСУ).
Но мне кажется полезным всегда помнить, что заказчику нужен в первую очередь работающий продукт, а порождение разнообразных документов является неизбежным злом, которое нужно стараться минимизировать, настолько, насколько это возможно в данном конкретном случае.

а что до взаимных обвинений в кривомозгости, то я с вами не соглашусь - в ЛЮБОМ сложном проекте с внешним заказчиком, наступает момент таких обвинений.

Вы же помните из курса логики, что для опровержения логического утверждения с квантором общности ("ЛЮБОЙ") достаточно единственного примера обратного?
У меня каждый второй примерно проект с внешним заказчиком обходился без  "взаимных обвинений в кривомозгости", в том числе и достаточно сложные, дорогие, и с непростыми госзаказчиками ... тут скорее дело в индивидуальном стиле общения.

не могу не согласиться. я, конечно, несколько утрировал пассаж про "обвинения". у нас, как у аффилированного МТС разработчика OSS/BSS решений так происходит постоянно но это наша специфика работы.
я не совсем корректно выразил мысль - "обвинениям в кривомозгости" свойственно возникать, когда скоуп проекта бесконтрольно расширяется и сроки начинают срываться. у нас так довольно часто происходит.
в принципе, "обвинения" - это элемент кранча, который легко можно устранить.

а что касается спецификации документов под разные проектные активности, то, естественно, тут играет роль бюджет и сроки.
но я бы очень внимательно просчитал, что дешевле - общий для всех функционеров проекта документ-спецификация требований или несколько, ориентированных на разные активности. но это, опять же, зависит от сложности реализуемой задачи. слона лучше есть по частям

Забавно, только что попался под руку в книжке Mike Cohn. User Stories Applied For Agile Software Developmet раздел, в котором Майк обращает внимание на взаимосвязь между тем, что

существуют разные документы, предназначенные для:
1. заказчика
2. для имплементации бизнес-логики в системе.
3. сношений с тестированием
4. приёмок и прочего.

, и тем что

"обвинениям в кривомозгости" свойственно возникать, когда скоуп проекта бесконтрольно расширяется и сроки начинают срываться.

" ... the Product Management (or similar) group writes a requirements specification that is given to the developers. The developers then rewrite the document so that it conveys their interpretation of the requirements ... The developers are always careful to give their document a completely different name (something like Functional Specification) to hide that is is the same document ... just written from the perspective of a different group.
...
Both groups know that a requirement specification is too difficult to read and fully understand and impossible to write with the desired precision.
When the project is finished and blame is being allocated they will point to sections of the document and claim that missing features were implied. Or they will claim that expected funcionality is out clearly out of scope because of a sentence buried somewhere in the document.
...
Most of the times when I see two groups writing separate versions of essentially the same document I already know they are positioning themselves for the end-of-project blame sessions..."

Про сношения с тестированием ты это хорошо сказал:)

Наболевшее