На самом деле всё зависит от масштабов работы.
Например всё очень удобно делать через календарный план. Там вы расписываете этапы работы по срокам. Вначале подготовительные этапы. Когда начинается очередной этап разработки, то после передачи продукта заказчику он должен заполнять акт сдачи-приёмки.

Приведу основные этапы нашего последнего проекта (в скобках основная отчётная документация):

1. Изучение объекта (Отчёт по результатам анализа. Описание решений по интеграции.)

2. Разработка и утверждение технического задания и технического проекта (ТЗ, ТП (Описание автоматизируемых функций, Описание организации информационной базы)).

3. Разработка рабочей документации на систему, разработка или адаптация программ (Руководство администратора, Руководство пользователя + сам Опытный Образец ПО, Задание по безопасности, Протокол оценки задания по безопасности)

4.1. Интеграция и проведение предварительных испытаний (Программа и методика испытаний. Акт предварительных испытаний. Доработанный Опытный Образец (далее — ОО), Доработанный комплект рабочей документации (далее — РД))

4.2. Проведение опытной эксплуатации, приемочных испытаний (Акт завершения опытной эксплуатации, Доработанный ОО, Доработанный комплект РД, Акт приемочных испытаний.)

5. Ввод в промышленную эксплуатацию (Акт приёмки в Промышленную эксплуатацию)

Но это кусочки. Проект был большой, длился год. Там очень много другой, более специфической документации. То что приведено выше — основные элементы, которые вы можете взять себе на вооружение.

Советовал бы взять за шаблон хорошего ТЗ упрощённые рекомендации PMBoK к проекту, а именно:

1. Разработка устава проекта (документация первоначальных требований, экономического обоснования, составление перечня заинтересованных лиц)
2. Разработка плана проекта, т.е. определяем в первом приближении как будет производится разработка и как будет производится контроль.
3. Собираем требования.
4. Определяем содержание, разбиваем его на операции, оцениваем ресурсы и время на каждую операцию.
4.1. Технические подробности, как должна себя вести система в тех или иных случаях, описать требования к дизайну.
5. Оцениваем весь бюджет разработок.
6. Желательно как-нибудь описать качество (какие-нибудь характеристики, вроде времени обрабатывания запроса) итогового продукта.
7. Готовим подробную смету по проекту (включая туда сотрудников, которые будут работать над проектом, и их з/п на время проекта).
8. Перечень лиц, кто отвечает за контроль хода выполнения работы и качества выполненной работы.

Всю информацию сводим в единый документ. Тогда и проблем будет по минимуму.

В PMBoK также советовал бы глянуть раздел про риски и про то, как их грамотно задокументировать, чтобы снизить их возможное наступление и последствия.

Всё это актуально вне зависимости от методологии разработки.

Была статья на Хабре, но в избранное в своё время забыл добавить, но смысл таков:
— А мой друг или дядя, Пётр, специалист в этом деле, он говорит, что лучше так сделать…
— Да ваш друг гений, дайте мне его контакты, я его найму себе, ведь он в несколько секунд оценил технологии разработки, время на саму разработку, предвидел возможные доработки и заложил их в проект. А также столь скорый и поверхностный анализ гарантированно защищает от различных факапов.

На Хабре была хорошая статья по ТЗ (но я не сохранил, может кто поможет найти) на сайт (свой, извини)