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

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

Техническое задание на разработку ПО: структура и примеры ниже построены именно по этой логике. Это не замена договору, SLA, спецификации API или программе испытаний. Это документ, который связывает бизнес-задачу, архитектурные ограничения, backlog и критерии приемки в единую систему требований.

ГОСТ 34.602-2020: база для структуры, не шаблон для любого SaaS

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

Попытка перенести документ в проект без адаптации обычно создаёт два дефекта:

• ТЗ разрастается до формального архива, который не используют команда и Product Owner.
• Критичные для SaaS разделы остаются недоописанными: tenancy model, API limits, миграции данных, observability, rollback, модель доступа, эксплуатация в cloud-инфраструктуре.

Стандарт полезен другим. Он дисциплинирует границы системы. В нём зафиксировано требование к качеству самих требований: они должны быть единичными, непротиворечивыми, актуальными, выполнимыми, проверяемыми и однозначными.

Для веб-сервиса это означает следующее. Требование «система должна поддерживать интеграцию с CRM» не имеет проектной ценности. Оно не задаёт:

• инициатора обмена;
• направление передачи данных;
• объекты синхронизации;
• частоту или событие запуска;
• протокол и механизм авторизации;
• поведение при сетевой ошибке;
• допустимую задержку;
• идемпотентность;
• правила разрешения конфликтов;
• владельца интеграции;
• критерий завершения приемки.

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

ТЗ фиксирует не интерфейс ожиданий, а наблюдаемый контракт между заказчиком, командой и системой.

Анатомия ТЗ: 10 разделов и их прикладное содержание

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

Общие сведения: зона контроля документа

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

Минимальный набор:

• идентификатор проекта и версия документа;
• владелец требований со стороны заказчика;
• порядок согласования изменений;
• перечень приложений: BPMN-схемы, wireframes, ERD, OpenAPI, прототипы, политика ИБ;
• глоссарий;
• список систем, названия которых используются в документе;
• правила приоритизации: Must / Should / Could либо иной согласованный метод.

Глоссарий нужен не для формальности. В enterprise-проектах один термин часто обозначает разные сущности. «Заказ» может быть заявкой в CRM, корзиной в e-commerce, юридически значимым документом в ERP или записью в очереди обработки. В ТЗ должна существовать одна трактовка.

Цели и назначение: не список функций

Цель должна быть измеримой на уровне бизнеса или операционного процесса. Формулировка «разработать современный личный кабинет» не описывает целевое состояние.

Рабочая структура цели:

1. Какой процесс изменяется.

2. Какой результат получает организация или пользователь.

3. Какая метрика покажет достижение результата.

4. Какие ограничения не могут быть нарушены.

Пример формулировки:

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

Метрика не обязана быть известна до discovery. Если baseline отсутствует, это нужно зафиксировать как отдельную работу первого этапа. Подменять неизвестную цифру произвольным KPI нельзя.

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

Граница особенно критична для web-проектов. Иначе в разработку незаметно попадают CMS, аналитическая платформа, CRM, help desk, PIM, биллинг и data warehouse одновременно.

Требования к системе: разделять функции, качество и ограничения

В ГОСТ 34.602-2020 требования к АС сгруппированы в четыре блока:

• требования к структуре системы;
• требования к функциям и задачам;
• требования к видам обеспечения;
• общие технические требования.

Для SaaS это удобная декомпозиция. Она отделяет поведение продукта от условий его реализации.

Как описать функциональные требования в ТЗ

Функциональное требование отвечает на вопрос: что система делает и какой наблюдаемый результат выдаёт.

Одна функция должна быть единичной. Не следует объединять регистрацию, авторизацию, восстановление доступа и управление профилем в одно требование «система должна обеспечивать работу пользователей».

Практический шаблон функционального требования:

• идентификатор;
• название;
• роль или субъект;
• предусловия;
• инициирующее событие;
• основной сценарий;
• альтернативные сценарии и ошибки;
• входные данные;
• правила валидации;
• результат;
• выходные данные;
• права доступа;
• связанные интеграции;
• критерий приемки;
• приоритет;
• связь с бизнес-целью или epic.

Пример.

FR-ORD-014. Создание заявки из внешнего канала

• Субъект: интеграционный сервис партнёра.
• Предусловие: партнёр зарегистрирован, API key активен, лимит запросов не превышен.
• Событие: внешняя система отправляет запрос на создание заявки.
• Вход: идентификатор партнёра, внешний идентификатор заявки, тип услуги, контактные данные, состав позиций.
• Правила: внешний идентификатор уникален в пределах партнёра; обязательные поля валидируются до записи; невалидные данные не создают частичную сущность.
• Результат: создана заявка со статусом new; сформирован внутренний идентификатор.
• Ошибки: при повторной передаче того же внешнего идентификатора возвращается ранее созданный объект, если payload не изменён; при конфликтующем payload возвращается ошибка валидации.
• Приемка: запрос с валидным набором данных создаёт одну заявку; повторный идентичный запрос не создаёт дубликат; ответ содержит внутренний идентификатор и текущий статус.

Это длиннее, чем «создать API для заявок». Но именно этот уровень детализации сокращает трактовки при реализации и QA.

Нефункциональные требования: измеримые ограничения

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

Фраза «система должна быть высокопроизводительной» не является требованием. У неё нет объекта измерения, условий нагрузки, метода проверки и критерия результата.

Конкретные значения для latency, доступности, RPO или RTO не являются универсальной нормой. Они выводятся из критичности процесса, профиля нагрузки, бюджета инфраструктуры и допустимой стоимости простоя.

Если цифры не определены, в ТЗ нужно записать способ их определения: нагрузочное обследование, измерение текущего процесса, capacity planning, пилот или отдельный architecture spike. Не маскировать пробел словом «оптимально».

Нефункциональное требование без метода измерения — это пожелание, а не объект приемки.

Требования к архитектуре: фиксировать границы, не навязывать реализацию

ТЗ не обязано диктовать стек: PostgreSQL вместо другой СУБД, k8s вместо managed platform, REST вместо GraphQL. Такие решения оправданы, если существуют ограничения: корпоративная платформа, лицензирование, компетенции эксплуатации, требования ИБ, vendor lock-in или совместимость с действующим контуром.

Вместо фиксации случайного инструмента следует описать архитектурный инвариант:

• сервис должен поддерживать изоляцию данных арендаторов;
• пользовательские сессии не должны зависеть от конкретного pod;
• фоновые операции должны быть отделены от синхронного HTTP-потока;
• критичные операции должны иметь идемпотентный механизм повторной обработки;
• все внешние вызовы должны иметь timeout, retry policy и контролируемую деградацию;
• конфигурация окружений не хранится в исходном коде;
• deployment выполняется через CI/CD с возможностью rollback;
• логи, метрики и трассировки доступны эксплуатационной команде.

Это требования к свойствам системы. Архитектор может выбрать реализацию внутри согласованных ограничений.

Интеграции и данные: самая дорогая часть недоописанного ТЗ

UI редко становится источником системного риска. Им становятся данные и связи между системами. Для web-сервисов структура ТЗ должна выделять их в самостоятельный контур.

ГОСТ требует описывать способы и средства информационного взаимодействия компонентов, связи со смежными системами, интероперабельность, совместимость и обмен информацией. Формат API стандарт не предписывает. OpenAPI, REST, GraphQL, SOAP, очереди, SFTP-обмен или event bus выбираются по контексту.

Карта интеграции должна отвечать на конкретные вопросы

Для каждой внешней системы зафиксируйте:

• владелец системы и технический контакт;
• назначение обмена;
• направление: inbound, outbound или bidirectional;
• инициатор: пользователь, scheduler, webhook, очередь, batch job;
• синхронность: synchronous или asynchronous;
• транспорт и формат данных;
• механизм аутентификации и ротации credentials;
• перечень сущностей и атрибутов;
• source of truth для каждого атрибута;
• правила создания, обновления, удаления и архивирования;
• ограничения rate limit, размер сообщений, окна доступности;
• обработка ошибок;
• retry policy и dead-letter queue при наличии очереди;
• журналирование и correlation ID;
• тестовый контур, test data и условия доступа;
• версия контракта и правила обратной совместимости.

Пример слабого требования: «Интегрировать с 1С для передачи заказов».

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

Для data model отдельно описываются:

• ключевые сущности;
• атрибуты и типы данных;
• справочники и их источник;
• классификация данных;
• сроки хранения;
• правила удаления и обезличивания;
• резервное копирование и восстановление;
• миграция исторических данных;
• контроль качества данных;
• права доступа на уровне tenant, роли, объекта и поля, если это требуется.

Нельзя писать «данные хранятся безопасно». Нужно указать, какие классы данных существуют, кто имеет доступ, какие операции журналируются, какие данные запрещено передавать во внешние контуры и что происходит при удалении учётной записи.

Приемка: от демонстрации к верификации

В ТЗ по ГОСТ раздел контроля и приемки должен содержать виды, состав и методы испытаний системы и её частей, общие требования к приемке и порядок согласования приемочной документации.

Это ключевой раздел для контракта. Если функциональность нельзя проверить, её нельзя формально принять.

NIST относит к проверяемым свойствам требований полноту, согласованность, корректность, модифицируемость, приоритизацию, трассируемость, однозначность, понятность и верифицируемость. На практике это означает: каждое существенное требование получает идентификатор и связь с тестом, пользовательским сценарием или результатом испытаний.

Что должно входить в критерии приемки

Для каждого функционального блока фиксируются:

1. Тестовые условия. Роль, набор исходных данных, состояние системы, версия интеграционного контура.

2. Действие. Что выполняет пользователь, внешний сервис или оператор.

3. Ожидаемый результат. Созданный объект, изменение статуса, отказ с конкретной причиной, отправленное событие.

4. Допустимые отклонения. Если они предусмотрены.

5. Метод проверки. UI-проверка, API-вызов, анализ audit log, нагрузочный тест, тест восстановления.

6. Приемочный артефакт. Протокол, отчёт тестирования, экспорт, запись лога, подписанный документ.

7. Ответственный за подтверждение. Заказчик, QA, ИБ, владелец интеграции, эксплуатационная команда.

Приемка не должна сводиться к демонстрации happy path. Для критичных функций необходимо включать негативные сценарии:

• попытка доступа ролью без прав;
• дублирующий запрос;
• невалидный payload;
• недоступность внешнего API;
• таймаут;
• частично выполненная операция;
• восстановление после отказа;
• повторная обработка сообщения;
• корректность audit trail.

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

Ошибки при составлении ТЗ на IT-проект

Большинство срывов scope начинается не с неверной оценки. Они начинаются с требований, в которых отсутствует объект управления.

Функции описаны через интерфейс

«На странице должны быть кнопки “Создать”, “Редактировать”, “Удалить”». Это описание макета, не функции.

Нужно фиксировать бизнес-действие, субъект, правила, ограничения прав и результат. Интерфейс может измениться после UX-тестов. Бизнес-правило — нет.

В одном пункте смешаны несколько требований

Формулировка «система должна автоматически проверять клиента, создавать договор, отправлять уведомление и формировать отчёт» содержит минимум четыре функции с разными ошибками, ответственными и условиями приемки.

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

Нет владельца данных

При интеграции двух или трёх систем без source of truth неизбежно возникает конфликт. Одна система считает статус актуальным, другая перезаписывает его по расписанию, третья показывает кеш.

Для каждого объекта нужно определить:

• master-систему;
• потребителей;
• разрешённые операции;
• событие изменения;
• механизм синхронизации;
• правило разрешения конфликта.

Нефункциональные требования вынесены в приложение без связи с функциями

Производительность не существует отдельно от операций. Нельзя принять общий пункт «система работает за две секунды», если не указано, для каких endpoint, с каким объёмом данных, при какой нагрузке и на какой среде.

Время выполнения следует связывать с конкретной функцией: поиск, создание заявки, генерация отчёта, загрузка файла, импорт, расчёт.

Интеграция обозначена одной строкой

В реальности интеграция состоит из контрактов, ошибок, повторов, версий, доступа и владения данными. Один пункт в ТЗ приводит к тому, что исполнитель оценивает transport layer, а заказчик ожидает полноценную end-to-end автоматизацию с reconcilliation.

В ТЗ отсутствует change management

Требования меняются. Это нормальное свойство разработки. Ненормально менять их через комментарии в мессенджере, устные решения на demo или «небольшие правки» в макете.

Порядок изменений должен содержать:

• источник change request;
• оценку влияния на scope, сроки, бюджет и архитектуру;
• владельца решения;
• правила приоритизации;
• версионирование ТЗ и приложений;
• способ включения изменения в релиз.

Документация не входит в Definition of Done

Если API contract, runbook, описание ролей, схема данных и инструкция администратора не указаны как результаты работ, они появятся в лучшем случае частично. Для SaaS это создаёт операционный долг сразу после релиза.

Минимальный набор зависит от системы. Но для production-сервиса обычно выделяют:

• описание архитектурных компонентов и внешних зависимостей;
• API documentation;
• модель ролей и прав;
• runbook для инцидентов и штатных операций;
• правила deployment и rollback;
• описание мониторинга и алертов;
• руководство администратора;
• пользовательские инструкции для критичных процессов.

Оптимальная модель ТЗ для веб-сервиса

Практичная структура не обязана быть одним монолитным файлом. Для сложного продукта эффективнее набор согласованных артефактов с единым реестром требований:

• базовое ТЗ с целями, scope, ограничениями, ролями, приемкой и порядком изменений;
• backlog функциональных требований с ID и приоритетами;
• BPMN или иные схемы процессов;
• прототипы интерфейсов;
• ERD и словарь данных;
• спецификации интеграций;
• каталог NFR;
• модель угроз и требования ИБ, если контур этого требует;
• план испытаний;
• эксплуатационная документация.

Главное условие — трассируемость. Бизнес-цель должна связываться с функцией. Функция — с экраном или API contract. Требование — с тест-кейсом. Тест — с результатом приемки. Без этой цепочки ТЗ остаётся текстом, а не системой управления поставкой.

Формальная полнота десяти разделов сама по себе не гарантирует успех. Но отсутствие цели, границ, владельцев данных, измеримых NFR и критериев приемки гарантированно создаёт неопределённость. В enterprise-разработке она всегда конвертируется в сроки, бюджет и операционные риски.

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