Техническое задание (ТЗ) — это официальный документ, который фиксирует требования к разрабатываемой программе и порядок её приёмки. Техническое задание ГОСТ 34 разработка по 2026 регулируется двумя ключевыми стандартами: ГОСТ 34.602-2026 задаёт содержание и структуру документа, а ГОСТ 34.601-2026 определяет стадии создания автоматизированных систем. В 2026 году ТЗ по ГОСТ 34 обязательно для госзакупок в рамках 44-ФЗ и 223-ФЗ, а также служит эталоном для крупных корпоративных ИТ-проектов. Корректно составленное техзадание сокращает споры на приёмо-сдаточных испытаниях в среднем на 40–60% и предотвращает до 70% отклонений по срокам разработки.
- Минимальный набор разделов включает «Общие сведения», «Назначение и цели», «Характеристика объекта», «Требования к системе», «Состав и содержание работ», «Порядок контроля и приёмки», «Требования к документированию».
- Допустимо дополнять структуру разделами под специфику проекта.
- ТЗ согласуется заказчиком и разработчиком в 5–7 рабочих дней.
- Шаблон ТЗ можно адаптировать для итеративных методологий (Scrum, Kanban) путём выделения верхнеуровневых требований и ссылок на бэклог.
Статья адресована техническим директорам, руководителям проектов и специалистам по закупкам, которым нужен не пересказ стандарта, а рабочий чек-лист. Мы разберём структуру обязательных разделов, покажем на примерах, как писать измеримые требования и встраивать ТЗ в гибкие процессы. Отдельно остановимся на типовых ошибках, из-за которых документ возвращают на доработку, и на регламенте согласования.
Зачем ТЗ по ГОСТ 34 в 2026 году: сфера применения
ГОСТ 34 — семейство стандартов на автоматизированные системы, унаследованное ещё от советских АСУ. Однако в 2026 году оно остаётся основным ориентиром для государственных и окологосударственных ИТ-проектов. Его применение прямо предписано постановлениями правительства и техническими заданиями госзаказчиков. Даже в коммерческом секторе формат ГОСТ 34 ценят за чёткую структуру, которая помогает избежать размытых формулировок и облегчает приёмку.
По данным отраслевых опросов, в 2025–2026 годах более половины крупных ИТ-госконтрактов содержали требование оформить ТЗ именно по ГОСТ 34. Кроме того, Минцифры учитывает наличие документации по стандарту при включении ПО в реестр отечественного софта. Импортозамещающие проекты практически всегда опираются на ГОСТ 34, поскольку он обеспечивает прозрачность для регуляторов и заказчика.
Ситуации, в которых ТЗ по ГОСТ 34 необходимо или желательно:
- Госзакупки по 44-ФЗ и 223-ФЗ.
- Проекты с бюджетным финансированием любого уровня.
- Контракты в оборонной, атомной и аэрокосмической отраслях.
- Внедрение крупных корпоративных ERP- и MES-систем.
- Импортозамещение ключевого ПО.
Структура ТЗ по ГОСТ 34.602: обязательные разделы
Содержание ТЗ по ГОСТу 34 регламентирует ГОСТ 34.602-2026. Он выделяет семь обязательных разделов, плюс приложения. Ниже — сводка того, что должен включать каждый раздел.
| Раздел ТЗ | Содержание | Типовая ошибка |
|---|---|---|
| Общие сведения | Полное наименование системы, шифр, заказчик, разработчик, плановые сроки, основание для разработки | Не указан номер контракта или договора |
| Назначение и цели создания | Основная цель автоматизации, критерии достижения цели | Цели сформулированы общими словами («повысить эффективность») |
| Характеристика объекта автоматизации | Описание бизнес-процессов «как есть», условия эксплуатации | Смешаны текущее состояние и желаемое |
| Требования к системе | Функциональные, нефункциональные, к видам обеспечения — вплоть до подразделов по каждому виду | Требования не измеримы («система должна быть быстрой») |
| Состав и содержание работ по созданию системы | Стадии и этапы, перечень документов на каждом этапе | Пропущена стадия опытной эксплуатации |
| Порядок контроля и приёмки | Виды испытаний, состав приёмочной комиссии, критерии успешности | Отсутствуют количественные критерии приёмки |
| Требования к документированию | Перечень итоговой документации (руководств, инструкций) и форматы сдачи | Не учтён формат файлов (PDF, DOCX) и требования к ЭП |
Ключевой раздел — «Требования к системе». В него по новому стандарту рекомендуется включать подразделы: требования к функциям, к надёжности, к защите информации, к эргономике, к совместимости, к эксплуатации и техническому обслуживанию. Каждое требование должно быть сформулировано однозначно. Например, вместо «высокая скорость» пишут «время отклика на поисковый запрос не превышает 2 секунд при нагрузке до 500 одновременных пользователей».
Стандарт разрешает добавлять приложения: расчёт экономической эффективности, макеты экранных форм, протоколы обмена данными. Это часто используют для визуальных и интеграционных требований, которые удобнее описать графически.
Пошаговый план: как написать техзадание на программу (образец)
Ниже — алгоритм, который позволяет получить документ, готовый к согласованию с первой итерации. Укрупнённо он выглядит так:
- Собрать исходные данные: провести интервью с заказчиком, выписать бизнес-цели и ключевые показатели.
- Определить границы системы: сформулировать, что автоматизируется, а что остаётся за рамками (раздел «Характеристика объекта»).
- Заполнить разделы по шаблону, начиная с «Общих сведений» и заканчивая «Требованиями к документированию». На этом этапе удобно использовать корпоративный шаблон, уже прошедший юридическую экспертизу.
- Сформулировать требования измеримо: для каждой функции указать входные данные, ожидаемый результат и ограничения. Шаблон: «Система должна [действие] при [условие] с результатом [критерий]».
- Добавить критерии приёмки в раздел «Порядок контроля». Если тест-кейсы уже известны, можно сослаться на них в приложении.
- Провести внутреннее рецензирование: техлид проверяет техническую реализуемость, аналитик — полноту покрытия бизнес-процессов.
- Передать заказчику на согласование. Сопроводить письмом с указанием срока ответа — например, 5 рабочих дней.
Пример измеримого требования: «Модуль регистрации обращений должен обеспечивать ввод не менее 200 обращений в час одним оператором с задержкой сохранения не более 0,5 с». Плохой вариант: «Удобный ввод заявок с высокой скоростью». Сравнение хорошо видно на реальных кусках ТЗ: чем больше конкретных цифр, тем меньше споров на финише.
При подготовке первого техзадания стоит опираться на референсные образцы коллег или отраслевые шаблоны. Многие компании накапливают собственный банк формулировок, прошедших приёмку. Главное — адаптировать образец под конкретный проект, а не копировать бездумно: объём документа может варьироваться от 30 до 150 страниц в зависимости от сложности системы.
Адаптация ТЗ к гибким методологиям: Agile и ГОСТ
Распространённое опасение: ГОСТ 34 несовместим с Agile, потому что фиксирует требования на старте. На практике методологии разработки Agile ГОСТ можно совместить, если отделить стабильную часть от изменяемой. ГОСТ 34.602 не запрещает вносить изменения в утверждённое ТЗ — процедура описана в разделе «Порядок контроля и приёмки» и может ссылаться на дополнительное соглашение к договору.
Практический приём: в ТЗ фиксируют верхнеуровневые бизнес-требования, архитектурные ограничения и нефункциональные характеристики (надёжность, производительность, безопасность). Детальные пользовательские истории, критерии приёмки спринтов и дизайн-макеты выносят в бэклог продукта. В самом ТЗ делают ссылку: «Детализация функциональных требований приведена в бэклоге, который является приложением к ТЗ и актуализируется по итогам каждого спринта».
| Аспект | Традиционное ТЗ | Agile-адаптированное ТЗ |
|---|---|---|
| Уровень детализации | Полное описание всех экранов и алгоритмов | Верхнеуровневые требования + ссылки на артефакты |
| Процесс изменений | Формальное допсоглашение | Итеративная актуализация бэклога с периодическим переутверждением |
| Критерии приёмки | Описаны в самом ТЗ для всей системы | Привязаны к спринтам, сводные критерии в ТЗ |
| Сроки | Директивные даты всего проекта | Диапазоны дат с возможностью пересмотра |
Опыт показывает: суды и приёмочные комиссии принимают такое комбинированное ТЗ, если в нём чётко прописан механизм изменения и есть актуальное приложение на момент испытаний. Важно только не забывать периодически — раз в квартал — утверждать обновлённую версию у заказчика.
Согласование и утверждение ТЗ: регламент и сроки
Этапы согласования ТЗ на разработку ПО по ГОСТ 34 жёстко не регламентированы, но сложилась устойчивая практика:
- Разработчик готовит проект ТЗ и направляет заказчику с сопроводительным письмом.
- Заказчик в течение 5–7 рабочих дней рассматривает документ и направляет замечания. Для сложных систем срок может быть увеличен до 15 рабочих дней — это нужно зафиксировать в договоре.
- Разработчик дорабатывает ТЗ и передаёт финальную версию. Если замечаний нет, стороны сразу переходят к подписанию.
- ТЗ утверждается руководителями с обеих сторон (обычно не ниже уровня директора проекта) и становится неотъемлемой частью договора или государственного контракта.
В 2026 году нормальным стало использование электронного документооборота с квалифицированной электронной подписью (ЭДО с КЭП). Это сокращает логистические задержки и позволяет иметь юридически значимый экземпляр ТЗ в цифровом виде. При ЭДО важно проверить, что подписанный файл не был изменён после подписания — системы вроде Диадока или Такском хранят историю версий.
Частая ловушка: подписание ТЗ без письменного заключения технического руководителя. Устные договорённости о том, что «потом уточним», на приёмке не работают. Если какое-то требование не удаётся сформулировать к моменту подписания, лучше явно указать, что оно будет уточнено на этапе технического проектирования, чем оставить пробел.
Типовые ошибки при составлении ТЗ и как их избежать
Даже опытные команды регулярно наступают на одни и те же грабли. Ниже — список самых «дорогих» промахов, каждый из которых может затянуть приёмку или привести к штрафам.
- Требования не измеримы. Фразы вроде «интуитивно понятный интерфейс» или «быстрая работа» необходимо заменять на численные показатели или конкретные условия.
- Нет критериев прекращения работ. Если система не достигает целевых показателей на приёмке, а ТЗ не говорит, что делать, заказчик может бесконечно требовать доработок.
- Смешение пользовательских и системных требований. Пользовательские описывают, что видит конечный потребитель, системные — как это реализовано внутри. Смесь усложняет понимание и тестирование.
- Избыточная детализация на раннем этапе. Попытка описать каждый экран до деталей чревата тем, что через пару месяцев проект уйдёт в сторону от ТЗ. Лучше оставить пространство для проектирования.
- Пропущены требования к переносимости, безопасности и локализации. В 2026 году почти любой госпроект требует работу на российских ОС (Альт, Ред ОС) и соблюдение норм ФСТЭК. Их отсутствие — гарантированный возврат на доработку.
Проверка ТЗ по этому списку перед отправкой заказчику экономит до двух итераций согласования.
Взаимосвязь с другими стандартами: ГОСТ 19 и ISO/IEC 12207
Кроме серии 34, разработчики часто сталкиваются с ГОСТ 19 (на программную документацию) и ISO/IEC 12207 (процессы жизненного цикла ПО). Их совместное применение может сбить с толку.
| Параметр | ГОСТ 34.602 | ГОСТ 19.201 |
|---|---|---|
| Объект | Автоматизированная система в целом (ПО + техника + персонал) | Программный продукт |
| Обязательность | Госзаказ, бюджетные проекты | Добровольно, если не указано в контракте |
| Содержание ТЗ | Структура жёсткая, 7 обязательных разделов | Более свободная форма, ориентирована на ПО |
| Стадии разработки | ГОСТ 34.601 | Не регламентирует |
На практике в госконтрактах часто ссылаются на оба стандарта. Тогда ТЗ оформляют по ГОСТ 34, но в части документирования может применяться ГОСТ 19 для руководств и инструкций. ISO 12207 чаще используют в международных проектах; в России он адаптирован как ГОСТ Р ИСО/МЭК 12207-2010 и может служить мостиком при экспорте ПО.
Совет: при формировании конкурсной документации смотрите, какие стандарты прямо названы в техническом задании заказчика. Если фигурирует и 34-я, и 19-я серия, разумно подготовить ТЗ по ГОСТ 34 с явной отсылкой к ГОСТ 19 для программной документации. Это снимет вопросы у приёмочной комиссии.
Чек-лист готового ТЗ: 10 точек контроля перед подписанием
Перед тем как ставить финальную подпись, пройдитесь по списку. Каждый пункт отвечает на один из ключевых вопросов, который задаст заказчик или комиссия.
-
- Все функциональные требования сформулированы в формате «система должна [действие] при [условие] с результатом [критерий]».
-
- Для каждого нефункционального требования указан количественный порог (время, нагрузка, объём).
-
- В разделе «Порядок контроля и приёмки» перечислены конкретные тесты или сценарии, успешное выполнение которых означает приёмку.
-
- Раздел «Состав и содержание работ» покрывает все стадии от проектирования до опытной эксплуатации и передачи в промышленную среду.
-
- Указан допустимый технологический стек и требования совместимости с импортозамещённым окружением (ОС, СУБД, серверы приложений).
-
- Прописаны требования к информационной безопасности: аттестация, класс защищённости, шифрование.
-
- Явно зафиксирован перечень итоговой документации и форматы сдачи.
-
- ТЗ содержит механизм внесения изменений: как инициировать, кто утверждает, сроки.
-
- Дата и номер версии документа указаны на титульном листе и в колонтитулах.
-
- На последней странице есть место для подписей обеих сторон (или ссылка на ЭДО).
Если хотя бы по одному пункту ответ неуверенный — документ ещё не готов. Доработка на этом этапе обходится в разы дешевле, чем разбирательства на приёмочных испытаниях.