Техническое задание на разработку ПО

Что это

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

Зачем это нужно

ТЗ решает сразу несколько проблем. Во-первых, снимает неопределённость: когда требования записаны, меньше споров о том, что входило в объём работ. Во-вторых, защищает обе стороны юридически — ТЗ часто является приложением к договору. В-третьих, помогает оценить стоимость и сроки: чем точнее описана задача, тем реалистичнее смета. Исторически в России ТЗ на программные системы регулировалось ГОСТом 34.602-89, который действовал десятилетиями и до сих пор используется в госзаказе. В коммерческой разработке жёсткого стандарта нет, поэтому структура документа варьируется от компании к компании.

Как это устроено

Классическое ТЗ состоит из нескольких блоков. Сначала идёт общее описание: цели проекта, целевая аудитория, контекст использования. Затем — функциональные требования: что система должна уметь делать (например, «пользователь может зарегистрироваться через email или Google-аккаунт»). Следом — нефункциональные требования: производительность, безопасность, доступность, совместимость с браузерами или устройствами. Отдельно описываются ограничения: стек технологий, бюджет, сроки, интеграции с внешними сервисами. В конце — критерии приёмки: по каким признакам заказчик поймёт, что работа выполнена. Хорошее ТЗ однозначно, проверяемо и не содержит формулировок вроде «удобный интерфейс» без расшифровки.

Примеры применения

Интернет-магазин: ТЗ описывает каталог товаров, корзину, интеграцию с платёжной системой (например, ЮKassa), личный кабинет и логику расчёта доставки.
Мобильное приложение для банка: документ фиксирует требования к авторизации по биометрии, лимиты операций, поведение при отсутствии сети и совместимость с iOS 15+ и Android 10+.
Корпоративная CRM: ТЗ определяет роли пользователей (менеджер, руководитель, администратор), права доступа к данным и форматы экспорта отчётов.
Государственный портал: разработка ведётся строго по ГОСТ 34.602-89, ТЗ согласовывается с несколькими ведомствами и проходит экспертизу.
Стартап с Agile-процессом: вместо классического ТЗ используется облегчённый вариант — product backlog с user stories, но ключевые технические ограничения всё равно фиксируются отдельным документом.

Связанные понятия

Функциональные требования — описание того, что система делает.
Нефункциональные требования — ограничения на качество: скорость, надёжность, безопасность.
User story — короткое описание функции с точки зрения пользователя, альтернатива классическому ТЗ в Agile.
Acceptance criteria — критерии приёмки, по которым проверяется выполнение требований.
SRS (Software Requirements Specification) — международный аналог ТЗ, описанный в стандарте IEEE 830.
Прототип / wireframe — визуальное дополнение к ТЗ, показывающее интерфейс до начала дизайна.

Частые ошибки

Самая распространённая ошибка — расплывчатые формулировки: «система должна быть быстрой» без указания конкретных метрик (например, «страница загружается не дольше 2 секунд при 1000 одновременных пользователях»). Вторая ошибка — ТЗ пишет только заказчик без участия разработчиков: в итоге документ содержит технически нереализуемые требования или противоречия. Третья — замороженное ТЗ в проектах с изменчивыми требованиями: если продукт развивается, документ нужно обновлять, иначе он превращается в артефакт, которым никто не пользуется. Наконец, нередко путают ТЗ с техническим проектом: ТЗ отвечает на вопрос «что», а технический проект — на вопрос «как».