Техническое задание на разработку: структура и пример

Техническое задание (ТЗ) на разработку — документ, который описывает, что должна делать система, для кого и с какими требованиями. ТЗ защищает обе стороны: заказчик получает то, что ожидает, а разработчик понимает, что от него требуется и как будет приниматься работа.

Структура

• Цель проекта и проблема, которую он решает
• Пользователи и их роли
• Функциональные требования
• Сценарии использования
• Интеграции с другими системами
• Требования к данным
• Требования к безопасности и доступам
• Требования к скорости и нагрузке
• Критерии приёмки

Пользователи и роли

Кто будет работать с системой: менеджеры, кладовщики, руководители, клиенты. Что каждая роль может видеть и делать.

Функции и сценарии

Функции лучше описывать через сценарии: кто, что делает, что видит, что получает. Сценарий понятнее абстрактного списка функций и проще проверяется.

Пример фрагмента

«Менеджер открывает карточку заказа и нажимает "Отправить на сборку". Система проверяет наличие всех позиций на складе. Если все позиции есть — заказ получает статус "На сборке", кладовщик получает уведомление. Если какой-то позиции нет — система показывает менеджеру список недостающих позиций и не меняет статус».

Критерии приёмки

Как проверить, что функция сделана правильно. Конкретные условия и ожидаемые результаты. Без критериев приёмка превращается в спор о вкусах.

Чего избегать

Расплывчатых формулировок: «удобный интерфейс», «быстрая работа». Требований без приоритетов: важно отметить, что обязательно, а что желательно. ТЗ на сотни страниц, которое никто не читает.

Кто пишет ТЗ

Лучше всего — вместе: заказчик знает процессы, аналитик разработчика умеет переводить их в требования. Если у заказчика нет опыта, стоит заказать этап анализа и подготовки ТЗ отдельно.

Изменения

Требования меняются в процессе. Договоритесь, как вносятся изменения, как они влияют на сроки и стоимость.