Техническое задание по ГОСТ 34.602 — это основной документ, определяющий требования заказчика к автоматизированной системе и регламентирующий её разработку, внедрение и приёмку. Стандарт входит в комплекс «Информационная технология. Комплекс стандартов на автоматизированные системы» и применяется для систем любого масштаба — от учётных модулей до ERP-платформ. Документ состоит из обязательных разделов: общие сведения, цели создания, характеристика объектов автоматизации, требования к системе, состав работ, порядок контроля и приёмки. Грамотно составленное ТЗ снижает риски разночтений между заказчиком и разработчиком и служит основой для приёмо-сдаточных испытаний.
Статья адресована руководителям проектов, системным аналитикам, техническим писателям и представителям бизнеса, которые впервые сталкиваются с ГОСТ 34.602 или хотят систематизировать подход. Вы узнаете, из каких разделов состоит ТЗ, какие требования обязательны, как избежать типовых ошибок и как проверить документ перед утверждением.
Что такое ГОСТ 34.602 и где применяется
ГОСТ 34.602 — это российский стандарт, описывающий структуру и содержание технического задания на создание автоматизированной системы (АС). Документ входит в 34-ю серию ГОСТов и обязателен при выполнении государственных и муниципальных контрактов, а также часто используется в крупных коммерческих проектах как общепринятая рамка. В отличие от произвольного ТЗ, формат по ГОСТ 34.602 гарантирует, что ни одно ключевое требование не будет пропущено: от общих сведений до порядка испытаний.
Текущая редакция — ГОСТ 34.602-2021, введённая в действие 1 марта 2022 года. Она учитывает современные подходы к проектированию систем и согласована с другими стандартами серии, например ГОСТ 34.601-2022 «Автоматизированные системы. Стадии создания». Это не просто шаблон, а методологическая основа, которая помогает заказчику и разработчику говорить на одном языке.
Применять стандарт необходимо в следующих случаях:
- при подготовке технического задания для госзакупок и конкурсной документации;
- при создании информационных систем с высокими требованиями к надёжности (банковские, промышленные, объекты КИИ);
- при регламентированной договором разработке, когда заказчик настаивает на формализованном процессе приёмки;
- в проектах с несколькими подрядчиками, где нужна единая точка сборки требований.
Структура ТЗ по ГОСТ 34.602
Стандарт ГОСТ 34.602-2021 выделяет девять обязательных разделов. Каждый раздел раскрывает свою группу требований, пропуск любого из них превращает документ в неполный с точки зрения стандарта. Ниже — навигационная таблица по содержанию разделов с краткими пояснениями.
| Раздел | Содержание |
|---|---|
| Общие сведения | Наименование системы, заказчик, разработчик, плановые сроки |
| Назначение и цели создания системы | Для чего создаётся система, какие задачи решает |
| Характеристика объектов автоматизации | Описание объекта, где будет внедрена система |
| Требования к системе | Функциональные, нефункциональные, по надёжности, безопасности, эргономике и т.д. |
| Состав и содержание работ по созданию системы | Этапы разработки, внедрения, обучения, кто и когда делает |
| Порядок контроля и приёмки системы | Критерии приёмки, перечень испытаний |
| Требования к документированию | Какая документация будет создана и в каком объёме |
| Источники разработки | Нормативные и технические документы, использованные при составлении ТЗ |
| Ожидаемая эффективность | Планируемые показатели улучшения деятельности |
Эта структура не догма: если система простая, часть разделов можно объединить или сократить, однако каждый из девяти элементов всё равно должен быть отражён, пусть и кратко. Подход «напишу по факту» без опоры на список разделов — главная причина, по которой в ТЗ забывают описать требования к документированию или порядок приёмки.
Раздел «Общие сведения» и «Назначение и цели»
Раздел «Общие сведения» задаёт контекст проекта. В нём указывают полное и краткое наименование системы, версию, реквизиты заказчика и разработчика, плановые даты начала и окончания работ, а также ссылку на договор или основание для проведения работ. Образец заполнения может выглядеть так:
- Полное наименование: «Автоматизированная система управления складскими запасами ООО «Промлогистика» (АС УСЗ)».
- Заказчик: ООО «Промлогистика», ИНН 7700000000.
- Разработчик: ООО «ИТ-интегратор».
- Плановый срок начала работ: 01.09.2026, окончания: 28.02.2027.
- Основание: договор № 45-АС от 15.08.2026.
Раздел «Назначение и цели создания системы» должен отвечать на вопрос «зачем» в измеримых терминах. Хорошая формулировка цели включает конкретный бизнес-эффект. Пример: «Сократить время обработки заказа с 2 часов до 20 минут за счёт автоматической маршрутизации заданий» вместо абстрактного «Автоматизировать работу отдела продаж».
Здесь же перечисляют задачи, которые система будет решать, и при необходимости указывают показатели, по которым будет оцениваться достижение целей. Важно не смешивать задачи системы с функциональными требованиями — задачи отвечают на «что система должна дать бизнесу», а функции на «как именно это будет реализовано».
Раздел «Характеристика объектов автоматизации»
В этом разделе описывают текущее состояние организации или процесса, который будет автоматизирован. Цель — дать разработчику понимание контекста. Включают организационную структуру подразделений, состав оборудования, имеющееся ПО, потоки данных, регламенты работы.
Типичная ошибка — копировать сюда должностные инструкции или устав компании. Нужна только та информация, которая влияет на проектные решения. Например, если учёт ведётся в 1С:Бухгалтерии, а новая система должна получать оттуда данные учёта, стоит описать версию конфигурации, объём транзакций, интерфейсы обмена.
Если объектом автоматизации служит производственный цех, укажите планировку, типы станков, протоколы связи. Чем точнее характеристика, тем меньше вероятность, что на этапе опытной эксплуатации выяснится: система не стыкуется с реальным оборудованием.
Раздел «Требования к системе»
Это самый объёмный раздел ТЗ. Стандарт требует описать требования по следующим направлениям:
- функциональные;
- к надёжности;
- к безопасности;
- к эргономике и интерфейсу;
- к условиям эксплуатации;
- к защите информации;
- к тестированию.
Функциональные требования удобно оформлять в виде сценариев. Вместо перечисления «система должна делать А, Б, В» применяйте формат: «При получении нового заказа система автоматически проверяет наличие товара на складе и, если позиций недостаточно, формирует уведомление менеджеру закупок». Такой подход сокращает неоднозначности при кодировании.
Требования к надёжности задают метрики: время восстановления после сбоя, коэффициент готовности. Для промышленных MES-систем часто прописывают «коэффициент готовности не ниже 0,999». В требованиях к безопасности учитывайте класс защищённости по документам ФСТЭК, если система обрабатывает персональные данные или относится к объектам КИИ.
Объём раздела может достигать нескольких десятков страниц. Рекомендуем группировать требования по подсистемам или бизнес-процессам — это упростит навигацию.
Нефункциональные требования и условия эксплуатации
Нефункциональные требования описывают, как система должна работать, а не что она делает. Сюда входят:
- производительность (время отклика, пропускная способность);
- масштабируемость (сколько пользователей выдерживает);
- совместимость с ОС, браузерами, СУБД;
- требования к аппаратному обеспечению.
Пример: «Время отклика интерфейса на типовую операцию не должно превышать 2 секунд при одновременной работе не менее 50 пользователей». Условия эксплуатации определяют климатические параметры, режим работы (круглосуточно, 24/7), требования к персоналу (квалификация, обучение).
Раздел «Состав работ и порядок приёмки»
Здесь перечисляют этапы жизненного цикла: разработку, тестирование, опытную эксплуатацию, ввод в промышленную эксплуатацию. Для каждого этапа указывают содержание работ, сроки, ответственных и ожидаемые результаты. Это превращает ТЗ в рабочий план, по которому можно управлять проектом.
Порядок приёмки фиксирует, как будут проходить испытания и кому предъявляются результаты. Обычно перечисляют виды испытаний (предварительные, приёмочные, опытной эксплуатации) и критерии, при которых система считается годной. Например: «Система считается принятой в промышленную эксплуатацию, если в течение 30 календарных дней опытной эксплуатации не зафиксировано критических отказов, а количество некритических отказов не превышает 5».
Не пренебрегайте этим разделом — без чётких критериев приёмки вы рискуете подписать акт на систему, которая формально соответствует ТЗ, но не выполняет реальные бизнес-задачи.
Раздел «Требования к документированию и источники разработки»
ТЗ само является документом, но стандарт обязывает описать, какая ещё документация будет выпущена в ходе проекта. Обычно это руководство пользователя, администратора, программиста, описание архитектуры, программы испытаний. Укажите форматы (DOCX, PDF), объём (не менее 100 страниц) и способ передачи.
Источники разработки — это перечень ГОСТов, технических регламентов, ТУ, справочных документов, которые были использованы при составлении ТЗ. Например: ГОСТ 34.602-2021, ГОСТ 34.601-2022, постановление Правительства № 123 и т.д. Раздел помогает проверяющим удостовериться, что ТЗ не составлено «с потолка», а опирается на нормативную базу.
Совет: сразу вносите сюда ссылки на отраслевые требования. Если система связана с бухгалтерским учётом, полезно указать регламенты Минфина и ФНС; для медицинских систем — нормы Минздрава. Это упростит последующее согласование с ведомствами.
Частые ошибки при составлении ТЗ по ГОСТ 34.602
Ошибки, которые чаще всего встречаются в практике:
- Отсутствие измеримых целей: «повысить эффективность» вместо конкретных KPI.
- Смешение функциональных и нефункциональных требований в одном списке без группировки.
- Пропуск раздела «Характеристика объектов автоматизации» — разработчик вынужден додумывать контекст.
- Неописанный порядок приёмки: стороны имеют разное представление, когда система считается готовой.
- Игнорирование требований к документированию: потом оказывается, что руководство пользователя отсутствует, а администратор не знает архитектуры.
- Копирование «рыбы» из предыдущих проектов без адаптации к особенностям новой системы.
Эти промахи приводят либо к затягиванию сроков, либо к неработающему продукту. Вложения времени в качественное ТЗ на старте окупаются десятикратно на этапе сдачи.
Чек-лист проверки готовности ТЗ перед утверждением
Перед тем как отдать документ на подписание заказчику и разработчику, пройдите по этому чек-листу. Каждый пункт должен быть закрыт утвердительно.
- Присутствуют все девять обязательных разделов, каждый наполнен содержанием.
- Цели создания системы сформулированы в измеримых показателях.
- Характеристика объекта автоматизации содержит актуальные данные (не устаревшие инструкции).
- Функциональные требования описаны сценариями, а не общими фразами.
- Нефункциональные требования задают конкретные числовые метрики.
- Указан класс защищённости по ФСТЭК, если система обрабатывает ПДн.
- Состав работ содержит все этапы с датами и ответственными.
- Порядок приёмки перечисляет виды испытаний и критерии успешности.
- Требования к документированию прописаны, форматы и объём указаны.
- Источники разработки содержат ссылки на действующие нормативные акты.
- Документ проверен юристом на предмет соответствия договору и законодательству.
- Все лица, чьи интересы затрагивает система, ознакомлены с ТЗ и дали письменные замечания.
Прохождение этого чек-листа не гарантирует, что система будет идеальной, но кратно снижает риск конфликтов на финальных стадиях.