Владислав

А ТЗ на что: сайт, приложение, софтина какая-нибудь? В любом случае, сделайте прототип - без ТЗ, на основании требований к проекту (бриф-то есть?) и задушевных бесед с заказчиком. Так вы визуализируете свои требования. А уже на основании прототипа - ТЗ. Это будет гораздо легче, потому что в голове сложится структура и логика будущего продукта. Опишете подробно свой прототип - вот вам и ТЗ. Я обычно пишу два: дизайнеру и программисту.
ТЗ начинается с общих требований (кроссбраузерность, языки, верстка, пользователи и проч.) и заканчивается подробным описанием каждой страницы/экрана, либо каждой функции (авторизация, внесение контента, обратная связь и т.д.).
Если проект огромный, то да - итерации. Первое ТЗ будет не слишком подробным - на некий каркас проекта, который потом будет развиваться и обрастать функционалом. Как-то так.

Мне показалось что человек спрашивал как описать ТЗ а не как его оформить по ГОСТу. Если я прав, то советую взять листок бумаги написать главную цель ТЗ, далее разбиваете эту цель на подзадачи и так в виде дерева до самого низкого уровня который сможете описать. Данное дерево будет основой ТЗ, условно можно представить что каждая задача пункт ТЗ, подзадача подпункт, но тут от уровня погружения зависит. Чем подробнее будет такое дерево тем качественнее получится итоговый продукт, остальное что касается оформления и структуры носит больше формальный характер.