Идеальное ТЗ

Такого не существует :-)
Точнее не существует общего решения на все случае.

А вообще есть вот такой документ.

Тз идеальное если исполнители поняли, что вы хотите получить на выходе.

Ну во-первых, я думаю что вы конечно знаете про agile и прочие «гибкие» методологии разработки — в этом случае детализированное ТЗ вообще отсутствует (используются user stories, скетчи и т.п.) — см. например 6 причин, по которым вам не стоит писать функциональные спецификации и множество подобных материалов на Хабре

Во-вторых, что касается структуры документа, предлагаемого ГОСТ-ом — по моему опыту не совсем удобно — нужно все таки называть вещи своими именами.

Лучше все это разделить на несколько документов:
— envisioning (концепция) — обобщенный документ, в котором рассказано что, зачем и какими силами/средствами мы хотим достичь
— функциональная спецификация (как правило это и называется ТЗ) — что собственно делать система должна, как выглядеть и т.п.
— техническая спецификация (если необходима) — в основном этот документ для самих девелоперов, но может использоваться для согласования использования фреймворков, СУБД и т.п.
— если проект может быть разделен на блоки, спецификаций может быть несколько — каждого блока.

В спецификациях, как правило, применяются UML диаграммы (но опять же, на Хабре некоторые считают что «UML умер»).

В общем — основная идея спецификации — чтобы заказчик и исполнитель говорили на одном и том же языке (см. ubiquitous language в концепции Domain Driven Design) и одинаково понимали что же нужно сделать.

Удачи Вам в этом нелегком деле :)

Лет пять как использую для составления ТЗ ментальные карты
Это куда удобнее чем составлять многостраничный документ, который потом сложно поддерживать в актуальном состоянии и по которому невозможно ориентироваться.
Клиенты довольны, программисты довольны, я как менеджер проектов просто в восторге :)

Вот пример такого ТЗ в свободном доступе от сервиса mindmeister.com
Сама я использую для работы MindJet MindManager Pro и его онлайн-версию