Об актуальности ГОСТ 34

---

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

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

Два подхода к документированию требований

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

Инженерный подход
Писательскому подходу противопоставлен инженерный подход, развившийся в рамках системной и программной инженерии. Он включает разнообразные методологии и инструменты, например IBM DOORS (IBM Rational DOORS). В центре внимания оказываются не выходные документы, а сами требования. Требования должны быть атомарными и образовывать базу данных, где каждому соответствует отдельная запись. Требования снабжаются атрибутами, отражающими их свойства. Между ними устанавливаются зависимости, выполняется трассировка — от высокоуровневых бизнес-требований до низкоуровневых функциональных и нефункциональных. Это предотвращает потерю смысла одного требования в отсутствие другого. Результирующие документы формируются автоматически путём отбора и выгрузки необходимых требований.

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

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

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

Эволюция стандарта: от ГОСТ 34.602-89 к ГОСТ 34.602-2020
Межгосударственный стандарт ГОСТ 34.602-89 «Информационные технологии» был принят 24 марта 1989 года и действовал с января 1990-го. Последняя редакция датируется июнем 2009 года. С начала 2022 года его применение в качестве национального стандарта прекращено. На смену пришёл документ с аналогичным названием и близким номером: ГОСТ 34.602-2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». Оба стандарта ссылаются на ГОСТ 19.201-78, устанавливающий порядок построения и оформления технического задания на разработку программного обеспечения.

Как и предшественник, ГОСТ 34.602-2020 допускает включать в ТЗ приложения, делить разделы на подразделы (с возможностью исключения или объединения), оформлять разделы ТЗ в виде приложений и вводить дополнительные разделы. Однако новый стандарт жёстче: при отсутствии требований по обязательному разделу он сохраняется с записью «Требования не предъявляются». Так раздел закрепляется в структуре выходных документов.

Ключевые изменения в ГОСТ 34.602-2020

• Меньше ссылок на другие стандарты. ГОСТ 34.602-2020 ссылается только на ГОСТ 19.201-78, тогда как версия 1989 года упоминала ещё семь стандартов.
• Критерии хорошего требования в разделе «Общие положения»: единичность, непротиворечивость, актуальность, выполнимость, проверяемость, однозначность.
• Порядок согласования и утверждения изменений в виде дополнений к ТЗ, который не должен отличаться от процедуры для исходного документа.
• Новый раздел, регламентирующий порядок разработки автоматизированной системы. В нём приводятся сведения об организации разработки, перечни исходных и итоговых документов, программы метрологического и эргономического обеспечения, обеспечения надёжности, технико-экономической оценки, а также данные о макетах, методиках испытаний, процессах детализации и экспертизы технической документации.
• Недопустимость исключения обязательных разделов. При отсутствии требований делается запись «Требования не предъявляются».
• Новый подраздел «Общие технические требования к автоматизированной системе» в разделе «Требования к автоматизированной системе». Здесь перечисляются требования к численности и квалификации персонала и пользователей, показатели назначения, надёжности, безопасности и другие нефункциональные требования, описывающие качество и условия эксплуатации. В ГОСТ 34.602-89 эти требования также присутствовали, но в составе других подразделов.
• Изменение структуры и содержания отдельных подразделов, в том числе требований к информационному, лингвистическому, программному, методологическому, организационному и методическому обеспечению.

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

Краткие итоги

Стандарты серии ГОСТ 34 прошли путь от инструмента жёсткой регламентации проектной документации к платформе, способной вобрать инженерную культуру управления требованиями. Многолетняя востребованность ГОСТ 34.602-89 объясняется не косностью отрасли, а тем, что формализованный текстовый документ остаётся универсальным юридическим артефактом, фиксирующим обязательства сторон. Однако присущая такому подходу длительная последовательная выверка томов ТЗ вступает в противоречие с итеративными и гибкими методологиями, где ценность поставляется инкрементально, а обратная связь непрерывна. Попытка простого расширения состава разделов без изменения парадигмы работы с требованиями лишь увеличила бы объём «бумажной» работы, не решив проблему синхронизации ожиданий.

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

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