ТЗ по ГОСТ 34: когда нужен и как выглядит

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

Когда он нужен

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

Структура по редакции 1989 года

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

Требования к системе

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

Чем отличается от свободного ТЗ

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

Другие стандарты

Для программ, а не автоматизированных систем целиком, применяют стандарт ГОСТ 19.201 из Единой системы программной документации. Стадии создания системы описывает ГОСТ 34.601. Если заказчик пишет «по ГОСТу», уточните, какой именно стандарт он имеет в виду.

Как использовать разумно

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

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

Типичные ошибки

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

Итог

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