Написание ТЗ. Нужно учить матчасть

Столкнулся с проектом средней тяжести реализации. Разработку запланировано вести в несколько самостоятельных стабильных промежуточных этапов.
Для того чтобы не держать кучу информации в голове (тем более, что это невозможно для обычного человека), а также, чтобы согласовать все с заказчиком и зафиксировать в письменном виде, мы решили составить полноценное Техническое Задание. Казалось бы, как можно вобще работать без ТЗ? Но на моей практике такое случается сплошь и рядом, хотя, конечно, в маленьких проектах.
Итак, первое ТЗ состоит из следующих разделов:

• Введение. В основном, здесь идет описание наших целей. Т.е. что это будет за сайт и какие у него будут цели существования, потенциальная аудитория.
• Общие требования к сайту. В этот раздел попадает список общих для всего сайта требований, таких как структура URI, критичная скорость загрузки, принципы шаблонизации и безопасности. Безопасность, впрочем, можно вынести и в отдельный раздел, но в моем случае практически ничего кроме шифрования паролей в md5 не указывалось (используемый PHP-фреймворк by default закрывает проверку входящих данных и т.п.).
• Пользовательские роли. Тут описывается практически вся реализация пользовательской части. В моем случае это описание основных групповых политик и ролей.
• Объекты. В данной части подробно описываются объекты сайта (новость, событие, пользователь,товар...) с указанием всех полей (в т.ч. обязательных) и состояний. При разработке повлияет на ОО-структуру и схему базы данных.
• Страницы и модели поведения. Этот раздел описывает основные страницы (ведь сайт, это по сути набор страниц или фактических состояний). Для примера, зафиксировано, что на странице новостей будет выводится список из 10 последних по дате новостей. Список будет состоять из даты новости, ее заголовка и текста аннотации и т.д. и т.п. вплоть до модели поведения системы при клике на заголовке новости. В этом же разделе можно описать систему администрирования.

Чего здесь не хватает? После нескольких редакций документ разросся и ему не хватает подробного содержания и краткого руководства "Как пользоваться этим документом". Еще здесь не хватает следующих вещей:

• Требований к дизайну и юзабилити (в частности, как будет выглядеть и логически работать календарь для выбора даты).
• Более научного подхода, к примеру UML диаграмм не только классов, но и Cases, т.е. тех самых моделей поведения, записанных не на словах, а в диаграммах.

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

Сейчас планирую дополнительно изучить литературу по выработке, фиксации и контролю исполнения требований к ПО. В частности это будет часть книги Лешека Мацяшека и еще пару изданий.