ТЗ по ГОСТ 34 или свободное ТЗ: когда стандарт обязателен, а когда только мешает

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

Обязан ли заказчик писать ТЗ по ГОСТ?

Нет, если никто не требует этого письменно. По ч. 1 ст. 26 закона о стандартизации документы национальной системы стандартизации применяются добровольно. ГОСТ-формат становится обязательным, когда на него ссылается договор, документация закупки или внутренний стандарт заказчика, — тогда по нему сверяют результат при приёмке.

Текст статьи — в ст. 26 Федерального закона 162-ФЗ «О стандартизации в Российской Федерации». Там же есть важная оговорка: исполнитель, который сам публично заявил о соответствии своей продукции стандарту, обязан этот стандарт соблюдать. Для ТЗ это значит простую вещь: если на титульном листе написано «разработано в соответствии с ГОСТ 34.602-2020», проверять документ будут по стандарту, а не по здравому смыслу.

Отдельный случай — госзакупки. В п. 2 ч. 1 ст. 33 Федерального закона № 44-ФЗ сказано, что при описании объекта закупки используют показатели, требования и терминологию из технических регламентов и документов по стандартизации, а если заказчик берёт другие — он обязан это обосновать. Прямого требования «оформить ТЗ строго по ГОСТ 34» в этой норме нет, но многие заказчики выбирают стандарт как каркас, чтобы не писать обоснование. Как устроена сама закупка, разобрано в статье о закупке разработки по 44-ФЗ и 223-ФЗ.

Чтобы понять, нужен ли вам ГОСТ, задайте три вопроса:

• Есть ли в договоре, техзадании закупки или регламенте заказчика ссылка на конкретный стандарт?
• Будет ли систему принимать комиссия, служба информационной безопасности или аудитор, которые работают по своим методикам?
• Встраивается ли новая разработка в систему, документация на которую уже оформлена по ГОСТ?

Если на все три ответа «нет», стандарт для вас — источник полезных идей, а не обязанность.

Какие разделы есть в ТЗ по ГОСТ 34?

По п. 4.1 ГОСТ 34.602-2020 в ТЗ на автоматизированную систему десять разделов: от общих сведений и целей до порядка приёмки, документирования и источников разработки. Если требований по разделу нет, раздел всё равно сохраняется. Можно добавлять свои разделы, подразделы — вводить, исключать и объединять, а объёмные части — выносить в приложения.

Стандарт полностью называется «Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». В России он введён в действие приказом Росстандарта 1522-ст от 19.11.2021 и действует с 1 января 2022 года, заменив ГОСТ 34.602-89. Текст можно посмотреть на странице стандарта в базе нормативов; перед использованием сверьте редакцию с официальным изданием Росстандарта.

На что обратить внимание, если вы встречали только старые шаблоны:

• Шаблоны 1989 года устарели. В новой редакции появился отдельный раздел «Порядок разработки АС», которого не было в версии 1989 года. Шаблон из интернета со ссылкой на ГОСТ 34.602-89 стоит сверить с действующим текстом.
• Главный раздел — требования к системе. В нём четыре блока: структура системы, функции, виды обеспечения (информационное, программное, техническое, организационное и другие) и общие технические требования — к персоналу, надёжности, безопасности, эргономике, защите информации.
• Сохранность данных при сбоях — отдельный пункт. Стандарт просит перечислить события, при которых информация должна сохраниться: аварии, отказы оборудования, потерю питания. Этот пункт полезен в любом ТЗ, не только в ГОСТ-формате.
• Изменения — только дополнением. По п. 3.5 изменения оформляют дополнением к ТЗ, и согласуют его тем же порядком, что и само ТЗ.

Ниже — все десять разделов с пометкой, насколько подробно их стоит писать, если система небольшая. Это не разрешение выкинуть раздел, а подсказка, где хватит пары строк.

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

Чем ГОСТ 34 отличается от ГОСТ 19?

ГОСТ 34.602-2020 описывает автоматизированную систему: программы вместе с людьми, данными, регламентами и подготовкой организации к запуску. ГОСТ 19.201-78 из Единой системы программной документации описывает одну программу или программное изделие. Поэтому ТЗ по ГОСТ 19 короче и почти не касается того, как поменяется работа сотрудников.

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

Стандарты не конкурируют, а дополняют друг друга. В самом ГОСТ 34.602-2020 есть ссылка на ГОСТ 19.201: ТЗ на информационные изделия, входящие в систему, составляют по нему. На практике это выглядит так:

• заказчик внедряет систему учёта заявок для всей компании — ТЗ на систему по ГОСТ 34;
• внутри неё нужен отдельный модуль обмена с бухгалтерией — частное ТЗ на программу, в том числе по ГОСТ 19;
• заказчик покупает одну утилиту, которая конвертирует файлы, — достаточно ГОСТ 19 или свободного ТЗ.

Если в требованиях закупки написано «ТЗ по ГОСТ» без номера, уточните номер вопросом к заказчику до подачи предложения: от ответа зависит объём документа и срок его подготовки.

	ГОСТ 34.602-2020	ГОСТ 19.201-78	Свободное ТЗ
Что описывает	Автоматизированную систему: программы, данные, людей, регламенты	Программу или программное изделие	Что угодно: сайт, кабинет, бот, интеграцию
Число разделов	10 обязательных, пустой раздел сохраняется	8 разделов плюс приложения	Сколько договорились стороны
Можно ли менять состав	Добавлять разделы и приложения; подразделы вводить, исключать, объединять	Уточнять, вводить новые и объединять разделы	Да
Где встречается	Госзаказ, крупные компании, внедрение учётных и управленческих систем	Отдельные программы, учебные и научные работы, часть госзаказа	Коммерческие проекты малого и среднего бизнеса
Главный риск	Объём ради объёма, требования «не предъявляются» по половине разделов	Не покрывает людей, процессы и данные	Пропущены приёмка и границы работ

Кто и когда требует ТЗ по ГОСТ?

Обычно ГОСТ-формат требуют заказчики с формальной приёмкой: государственные и муниципальные организации, госкомпании, банки и крупный бизнес со своими регламентами закупки ИТ. Ещё один повод — разработка встраивается в существующую систему, документация на которую уже ведётся по стандарту.

Типичные ситуации, когда без стандарта не обойтись или он заметно упрощает жизнь:

• Закупка по 44-ФЗ или 223-ФЗ. Описание объекта закупки должно опираться на терминологию стандартов, и ГОСТ 34 даёт готовый каркас. Детали — в документации конкретной закупки.
• Внутренний регламент крупной компании. Служба ИТ или безопасности часто принимает только документы определённой структуры. Регламент заказчика здесь важнее любой статьи: запросите его до оценки работ.
• Требования к защите информации. По ГОСТ 34.602-2020 в них включают нормы, действующие в отрасли или ведомстве заказчика. Если такие нормы есть, их удобнее перечислить в разделе стандарта, чем придумывать свой.
• Развитие уже работающей системы. По п. 3.1 стандарт подходит и для ТЗ на развитие или модернизацию: вид работ указывают в названии документа.

Обратная ситуация тоже частая: предприниматель видит в интернете «ТЗ по ГОСТ» и решает, что так солиднее. Если ни договор, ни заказчик этого не требуют, документ на 40 страниц защищает не сильнее ясных 5 страниц — он просто дольше согласуется.

Как совместить ТЗ по ГОСТ с гибкой разработкой?

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

1. Рамочное ТЗ. Цели, границы системы, роли пользователей, общие требования к надёжности и безопасности, порядок приёмки. Эти вещи меняются редко.
2. Очередь или итерация. Для каждой — частное ТЗ или дополнение: какие функции входят, как их проверить, что передаётся. По п. 4.2 в ТЗ на составную часть не повторяют то, что уже есть в ТЗ на систему.
3. Приёмка по очередям. Каждую очередь принимают по её документу, а не по всему ТЗ сразу.
4. Изменения. Новое требование — дополнение к ТЗ с тем же порядком согласования. Зато через полгода видно, кто и когда изменил требования.

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

Как не превратить ГОСТ-ТЗ в бумагу ради бумаги?

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

Ошибки, которые встречаются в ГОСТ-ТЗ чаще всего:

• Шаблон вместо содержания. Скачанный документ с чужими подсистемами, ссылками на отменённую редакцию и разделами, которые не относятся к проекту.
• «Требования не предъявляются» в половине разделов. Формально раздел сохранён, по сути заказчик отказался от требований к надёжности или защите данных и потом не может их предъявить.
• Слова без меры. «Высокая производительность», «удобный интерфейс», «надёжное хранение». Нужны числа и условия: сколько пользователей одновременно, за сколько секунд открывается отчёт, как часто делаются резервные копии.
• Реализация вместо требований. ТЗ описывает таблицы базы данных и кнопки, а цель — что должен получить сотрудник — потерялась. Проектирование стоит оставить исполнителю и согласовать отдельно.
• Приёмка «по согласованию сторон». Без списка проверок и ответственных акт превращается в переговоры.
• Названия брендов в закупке. В госзаказе конкретные продукты допускаются только с оговорками закона, поэтому описывайте функции.

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

Что взять из ГОСТ в обычное ТЗ?

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

Чек-лист для свободного ТЗ с полезным из ГОСТа:

• Цель с показателем. Не «автоматизировать заявки», а «менеджер видит все заявки в одном списке, ответ клиенту уходит из системы».
• Как сейчас. Кто участвует в процессе, где хранятся данные, что ломается. Это аналог раздела о характеристике объекта автоматизации.
• Роли и функции. Кто заходит в систему и что каждый делает. Здесь же — интеграции с внешними системами.
• Общие требования. Устройства и браузеры, число пользователей, резервные копии, что должно сохраниться при сбое сервера или обрыве связи.
• Порядок приёмки. Какие сценарии проверяет заказчик, на каких данных, сколько дней на проверку, как оформляются замечания.
• Документы. Инструкция администратора, краткая инструкция пользователя, доступы.
• Что не входит. Отдельной строкой: тексты, фото, лицензии сторонних сервисов, работы на стороне чужих систем.
• Как меняем ТЗ. Любое новое требование — письменно и с оценкой.

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

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

Сколько стоит подготовка ТЗ и входит ли она в разработку?

У Roboweb подготовка ТЗ в обычном формате входит в стоимость разработки: например, на тарифе веб-приложения от 160 000 ₽ первый этап так и называется — «Бриф и ТЗ: роли, сценарии, модель данных, интеграции». ТЗ в формате ГОСТ 34 с полным набором разделов оцениваем отдельно после брифа, потому что объём зависит от требований заказчика.

Что влияет на трудоёмкость ГОСТ-ТЗ:

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

Для сравнения: корпоративный сайт в прайсе — от 56 000 ₽ за 3–4 дня, и его структура согласуется на этапе брифа. Писать к нему ТЗ по ГОСТ 34 — обычно затратнее по времени, чем сама вёрстка, поэтому без внешнего требования это не имеет смысла.

Когда ТЗ по ГОСТ вам не нужно?

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

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

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

Короткие ответы на частые вопросы

Обязательно ли писать ТЗ на сайт по ГОСТ?

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

Какой ГОСТ на техническое задание действует сейчас?

Для автоматизированных систем — ГОСТ 34.602-2020: в России он действует с 1 января 2022 года и заменил ГОСТ 34.602-89. Для отдельных программ продолжает действовать ГОСТ 19.201-78 из Единой системы программной документации.

Чем отличается ТЗ по ГОСТ 34 от ТЗ по ГОСТ 19?

ГОСТ 34.602-2020 описывает систему целиком: процессы, людей, данные, подготовку организации к запуску. ГОСТ 19.201-78 описывает только программу: её назначение, требования к ней, документацию и приёмку.

Можно ли выкинуть ненужные разделы из ГОСТ 34?

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

Можно ли вести гибкую разработку по ТЗ по ГОСТ?

Можно. Стандарт допускает отдельные ТЗ на составные части системы и дополнения к ТЗ, которые согласуются тем же порядком, что и основное ТЗ. Поэтому рамочное ТЗ на систему и уточнения по очередям уживаются в одном проекте.

Услуги и кейсы по теме: заказная разработка · типовые договоры и акт сдачи-приёмки · цены и сроки