Техническое задание на разработку ПО: структура, ГОСТ и пример

Техническое задание на разработку программного обеспечения — документ, в котором заказчик и исполнитель фиксируют, что именно строится, для кого, с какими ограничениями и как будет проверяться результат. Для веб-сервиса, CRM или личного кабинета ТЗ важнее, чем для сайта: логики больше, ролей больше, интеграций больше, и каждое «само собой разумеется» превращается в спор о деньгах. Разберём, когда нужен ГОСТ, из каких разделов состоит рабочее ТЗ для бизнеса, как писать требования на примерах «плохо → хорошо», кто его готовит и сколько стоит аналитика.

Если вы заказываете сайт, а не сервис, удобнее начать с отдельного разбора технического задания на сайт: там подробно про структуру страниц, дизайн, контент и SEO. Здесь — про программное обеспечение: веб-приложения, порталы, CRM, интеграции.

Чем ТЗ на разработку ПО отличается от ТЗ на сайт

На сайте основная ценность — страницы и контент, на сервисе — поведение системы. Поэтому у ТЗ на ПО другой центр тяжести:

• Роли и права. Кто что видит и может менять: клиент, менеджер, руководитель, бухгалтер, партнёр, администратор.
• Сценарии и статусы. Жизненный цикл заявки, заказа или сделки с переходами, условиями и уведомлениями.
• Данные. Какие сущности хранятся, откуда приходят, кто источник истины — система или 1С.
• Интеграции. Обмен с 1С, оплатой, доставкой, телефонией, мессенджерами — с направлением, частотой и поведением при сбое.
• Нефункциональные требования. Нагрузка, скорость, доступность, безопасность, персональные данные. На сайте ими часто можно пренебречь, в сервисе — нет.

ГОСТ 34.602-2020 и ГОСТ 19.201-78: какой стандарт выбрать для ТЗ

В России для технических заданий на ПО используют два стандарта. Они не конкурируют, а описывают разные объекты.

ГОСТ 34.602-2020 — ТЗ на автоматизированную систему

Межгосударственный стандарт «Техническое задание на создание автоматизированной системы» действует в России с 1 января 2022 года (приказ Росстандарта от 19.11.2021 № 1522-ст) и заменил ГОСТ 34.602-89. Он описывает не только программу, но и систему целиком: людей, процессы, оборудование, ввод в действие. Обязательные разделы — десять:

1. Общие сведения.
2. Цели и назначение создания системы.
3. Характеристика объекта автоматизации.
4. Требования к системе.
5. Состав и содержание работ по созданию системы.
6. Порядок разработки системы (новый раздел по сравнению с версией 1989 года).
7. Порядок контроля и приёмки.
8. Требования к подготовке объекта автоматизации к вводу системы в действие.
9. Требования к документированию.
10. Источники разработки.

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

ГОСТ 19.201-78 — ТЗ на программу

Стандарт из Единой системы программной документации (ЕСПД) описывает ТЗ на отдельную программу или программное изделие. Разделы: введение, основания для разработки, назначение разработки, требования к программе, требования к программной документации, технико-экономические показатели, стадии и этапы разработки, порядок контроля и приёмки. Документ компактнее и подходит, когда разрабатывается модуль, утилита или библиотека, а не система с процессами вокруг неё.

Когда ГОСТ нужен, а когда избыточен

ГОСТ оправдан, если его прямо требует закупочная документация, если систему будут принимать комиссией и проверять аудиторы, если проект долгий и переходит между подрядчиками. Для CRM на 30 сотрудников или сервиса с личным кабинетом полный ГОСТ 34 избыточен: половина разделов (подготовка объекта автоматизации, источники разработки) заполняется формально, а на написание уходит месяц, который лучше потратить на прототип. Разумный компромисс — взять из ГОСТ логику разделов и требования к качеству формулировок, а форму оставить рабочей.

Структура технического задания на разработку ПО для бизнеса

Рабочий шаблон, который закрывает те же вопросы, что и ГОСТ, но читается владельцем бизнеса и разработчиком одинаково:

1. Цели и границы проекта. Какую бизнес-проблему решаем, как измерим успех (например, «время обработки заявки — с 40 до 10 минут»), что точно не входит в проект.
2. Роли и пользователи. Список ролей, их задачи и матрица прав: кто создаёт, видит, редактирует, удаляет.
3. Пользовательские сценарии. Основные пути каждой роли от начала до результата, включая ошибки и исключения.
4. Функциональные требования. Модули и функции, сгруппированные по сценариям, с приоритетом.
5. Нефункциональные требования. Нагрузка, скорость, доступность, безопасность, персональные данные, поддерживаемые браузеры и устройства.
6. Интеграции и API. С какими системами обмен, в какую сторону, как часто, что происходит при недоступности.
7. Модель данных. Основные сущности и их поля, источник истины, объём, миграция из старой системы.
8. Прототип или ссылки на макеты. Картинка экономит страницы текста и снимает половину разночтений.
9. Критерии приёмки. Как проверяется каждое требование, на каких данных, кто принимает.
10. Этапы и передаваемые результаты. Что сдаётся на каждом этапе: код, доступы, документация.

Пользовательские сценарии и user stories

Сценарий описывает, чего хочет пользователь и что делает система, а не какие кнопки нарисованы. Удобный формат — user story с критериями приёмки:

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

Критерии: в карточке отображаются заявки со всех каналов (сайт, телефон, Telegram) в хронологическом порядке; у каждой видны дата, канал, статус и ответственный; заявка появляется в карточке не позже чем через минуту после поступления.

Отдельно пропишите альтернативные ветки: что если клиент с таким телефоном уже есть, что если оплата не прошла, что если менеджер уволился и его сделки нужно передать. Именно на исключениях чаще всего всплывают незаложенные в смету работы.

Функциональные требования: пример формулировок «плохо → хорошо»

Главная проблема большинства ТЗ — не отсутствие разделов, а размытые формулировки, которые нельзя проверить. Фрагменты-образцы:

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

Нефункциональные требования: нагрузка, безопасность, 152-ФЗ

Их пропускают чаще всего, а они сильнее всего влияют на архитектуру и цену. Минимальный набор:

• Производительность и нагрузка: сколько пользователей работает одновременно сейчас и через два года, допустимое время отклика ключевых экранов, пиковые периоды.
• Доступность: допустимый простой в месяц, окно для обновлений, требования к резервному копированию и сроку восстановления.
• Безопасность: авторизация (пароль, двухфакторная, вход через корпоративный каталог), журнал действий пользователей, ограничение доступа по ролям, защита API.
• Персональные данные: если система хранит данные клиентов или сотрудников, она подпадает под 152-ФЗ — базы с данными граждан РФ должны находиться в России, нужны согласие на обработку и модель угроз. С 30 мая 2025 года действуют повышенные штрафы за утечки по ст. 13.11 КоАП (420-ФЗ), а при повторной утечке — оборотные, поэтому требования лучше заложить в ТЗ, а не дорабатывать после запуска. Проверить готовую систему можно через аудит на соответствие 152-ФЗ.
• Окружение: где размещается система (российское облако или сервер заказчика), поддерживаемые браузеры, нужна ли мобильная версия.

Интеграции, API и данные

По каждой интеграции в ТЗ нужна отдельная карточка: система и её версия, направление обмена, передаваемые данные, частота или событие-триггер, способ (API, файловый обмен, вебхуки), поведение при ошибке, кто предоставляет доступы и документацию. Отдельно фиксируется источник истины: если цена есть и в 1С, и в CRM, какая из них главная при расхождении.

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

Критерии приёмки: как проверить результат

Приёмка — единственное место, где ТЗ работает как юридический инструмент. Хорошие критерии:

• привязаны к конкретным требованиям и сценариям, а не к «системе в целом»;
• описывают тестовые данные: сколько записей, какие роли, какие граничные случаи;
• разделяют дефекты по критичности: критичный блокирует приёмку, незначительный исправляется в гарантийный период;
• фиксируют сроки: сколько дней у заказчика на проверку и что происходит, если он не ответил.

Связка ТЗ и договора определяет, как считается оплата при изменениях объёма. Этот выбор подробно разобран в статье про Fixed price и Time & Material.

ТЗ или бэклог: как это работает при гибкой разработке

Популярный аргумент «мы работаем по agile, ТЗ не нужно» верен наполовину. Бэклог — живой список задач, который меняется каждый спринт. Он хорош для развития продукта, но плохо подходит для фиксированного бюджета: без рамок у заказчика нет понимания, сколько будет стоить результат.

Рабочая схема для заказной разработки — ТЗ по этапам:

1. Концепция и границы всего продукта: цели, роли, список модулей, нефункциональные требования, архитектура. Это фиксируется сразу.
2. Детальная спецификация первого этапа (обычно MVP): сценарии, прототипы, критерии приёмки. По ней считается фиксированная смета этапа.
3. Разработка спринтами по одной-две недели с демонстрацией результата на тестовом сервере.
4. Спецификация следующего этапа пишется с учётом обратной связи от реальных пользователей.

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

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

Возможны три варианта, и у каждого своя цена ошибки.

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

Сколько стоит предпроектная аналитика и ТЗ

Отдельной «цены за ТЗ» на рынке нет — стоимость зависит от объёма системы, числа ролей и интеграций. Ориентир по рынку: аналитика и проектирование занимают около 5–15% бюджета разработки и 2–6 недель. Для сервиса или CRM стоимостью 1–2 млн ₽ это примерно 50–300 тыс. ₽. Полное ТЗ по ГОСТ 34 для госзаказа стоит заметно дороже из-за объёма оформления.

Для сравнения порядка сумм: заказная CRM стоит от 450 000 ₽, MVP веб-сервиса — от 900 000 ₽, полноценный сервис среднего класса — от 1,5 до 3 млн ₽. Точная цена зависит от логики, интеграций и нагрузки и называется после аналитики. Экономия на аналитике почти всегда возвращается переделками: изменение требования на этапе прототипа стоит часы, после разработки — недели.

Типовые ошибки в ТЗ на программное обеспечение

• Описано решение вместо задачи. «Сделайте как в amoCRM» не объясняет, какую проблему решаем, и копирует чужие ограничения.
• Нет ролей и прав. Права доступа всплывают на приёмке и ломают половину экранов.
• Интеграции одной строкой. «Интеграция с 1С» может означать и два дня работы, и два месяца.
• Нет цифр в нефункциональных требованиях. Нагрузка, скорость и доступность описаны прилагательными.
• Не описаны исключения. Есть только «счастливый путь», а ошибки оплаты, дубли и отмены додумываются на ходу.
• Нет критериев приёмки. Результат оценивается по ощущениям, отсюда бесконечные доработки.
• ТЗ на весь продукт сразу на год вперёд. К середине проекта документ расходится с реальностью, а каждое изменение превращается в допсоглашение.
• Формальный ГОСТ там, где он не нужен. 80 страниц шаблонного текста вместо 20 страниц точных требований и прототипа.

Чек-лист: проверьте ТЗ перед подписанием

• Цели проекта сформулированы в измеримых показателях, границы проекта и то, что в него не входит, записаны явно.
• Перечислены все роли, есть матрица прав доступа.
• Ключевые сценарии описаны вместе с ошибками и исключениями.
• Каждое функциональное требование можно проверить без трактовок.
• Нагрузка, время отклика и доступность указаны цифрами.
• Учтены требования 152-ФЗ, если система хранит персональные данные.
• По каждой интеграции указаны направление, данные, частота и поведение при сбое.
• Определён источник истины для данных и план миграции.
• Есть прототип ключевых экранов.
• Критерии приёмки, тестовые данные и сроки проверки зафиксированы.
• Понятен порядок изменений: как оформляются и оцениваются новые требования.
• Если нужен ГОСТ — указан конкретный стандарт и обязательные разделы.

ТЗ на разработку ПО — это не формальность и не толстый документ ради документа, а договорённость о том, что будет сделано и как это проверить. ГОСТ 34.602-2020 нужен там, где его требует заказчик или закупка, в остальных случаях достаточно структурированного бизнес-ТЗ с ролями, сценариями, измеримыми нефункциональными требованиями, интеграциями и критериями приёмки. Для продуктов, которые будут развиваться, удобнее всего детальная спецификация по этапам: зафиксированные рамки всего проекта и точное описание ближайшего релиза.