Ну во-первых, я думаю что вы конечно знаете про agile и прочие «гибкие» методологии разработки — в этом случае детализированное ТЗ вообще отсутствует (используются user stories, скетчи и т.п.) — см. например
6 причин, по которым вам не стоит писать функциональные спецификации и множество подобных материалов на Хабре
Во-вторых, что касается структуры документа, предлагаемого ГОСТ-ом — по моему опыту не совсем удобно — нужно все таки называть вещи своими именами.
Лучше все это разделить на несколько документов:
— envisioning (концепция) — обобщенный документ, в котором рассказано что,
зачем и какими силами/средствами мы хотим достичь
— функциональная спецификация (как правило это и называется ТЗ) — что собственно делать система должна, как выглядеть и т.п.
— техническая спецификация (если необходима) — в основном этот документ для самих девелоперов, но может использоваться для согласования использования фреймворков, СУБД и т.п.
— если проект может быть разделен на блоки, спецификаций может быть несколько — каждого блока.
В спецификациях, как правило, применяются UML диаграммы (но опять же, на Хабре некоторые считают что «UML умер»).
В общем — основная идея спецификации — чтобы заказчик и исполнитель говорили на одном и том же языке (см. ubiquitous language в концепции
Domain Driven Design) и одинаково понимали что же нужно сделать.
Удачи Вам в этом нелегком деле :)
