Перейти к основному содержимому

Спецификация по ГОСТ 19.202-78

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Руководителю Аналитику Техническому писателю

Спецификация программного обеспечения

ГОСТ
Основано на ГОСТ 19.202-78.

Спецификация - это список всех деталей и инструкций к ним, которые входят в поставку программы. Опись того, за что платят и что получают.

Нужна, чтобы:

  • заказчик знал, что именно он получает;
  • исполнитель знал, что именно он должен передать;
  • сопровождение было возможным через год.

Существует единый стандарт (ЕСПД, единая система программной документации) на оформление бумажек к программам. ГОСТ 19.202-78 как раз один из этих стандартов.

Руководство по составлению в соответствии с ГОСТ 19.202-78​

1. Краткий обзор стандарта ГОСТ 19.202-78​

1.1. История и актуальность​

ГОСТ 19.202-78 введён в действие с 1 января 1980 года (Постановление Госстандарта СССР № 3351 от 18.12.1978) и до сих пор действует в Российской Федерации как часть Единой системы программной документации (ЕСПД).

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

Стандарт полностью соответствует международному (советскому) стандарту СТ СЭВ 2090-80, что подтверждает его гармонизацию с практиками стран СЭВ.

1.2. Назначение документа «Спецификация»​

Спецификация — это основной программный документ для:

  • программных комплексов (совокупностей взаимосвязанных программ, объединённых общей задачей);
  • компонентов, применяемых самостоятельно (например, библиотеки, утилиты, автономные модули).

Для компонентов, не имеющих спецификации (например, простые скрипты, макросы), основным документом считается «Текст программы» (ГОСТ 19.401-78).

🔑 Ключевая функция спецификации — перечислить все программные и документационные компоненты, входящие в состав системы/комплекса, и установить их взаимосвязи.
Это — составной документ: он фиксирует структуру изделия как набор элементов.

1.3. Область применения​

Спецификация применяется при:

  • проектировании и сдаче-приёмке ПО;
  • сертификации и экспертизе;
  • сопровождении и модернизации (особенно при замене компонентов);
  • интеграционных работах, когда необходимо чётко определить состав поставки.

1.4. Общая структура документа по ГОСТ 19.202-78​

Структура и оформление — согласно ГОСТ 19.105-78: титульный лист, лист регистрации изменений, содержание (необязательно), основная часть.

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

РазделОбязательностьКраткое содержание
Документация✔ ОбязательныйСписок всех программных документов (кроме Спецификации и ТЗ), входящих в поставку
Комплексы△ УсловноСсылки на спецификации вложенных комплексов (если текущий документ — спецификация комплекса верхнего уровня)
Компоненты✔ ОбязательныйПеречень всех программных компонентов: модулей, библиотек, утилит, со ссылками на их ОПД (основные программные документы, чаще — «Текст программы»)

📌 Примечание:

  • Заголовки разделов пишутся в графе «Наименование» и подчёркиваются при печатном оформлении.
  • После каждого раздела оставляется несколько свободных строк — для внесения изменений в будущем.
  • Графа «Примечание» может содержать номера сносков с расшифровкой в конце раздела или на отдельных листах.

2. Пошаговое руководство по составлению спецификации​

Шаг 1. Подготовка​

  1. Убедитесь, что определена граница системы:
    • Что входит в поставку?
    • Какие компоненты считаются внешними и не включаются в спецификацию (например, СУБД, ОС, сторонние SDK)?
  2. Получите утверждённый перечень:
    • всех программных модулей;
    • всех программных документов (ГОСТ 19.101-77: ПЗ, РП, АП, ТП и др.);
    • всех вложенных комплексов (если иерархия многоуровневая).

⚠ Важно: спецификация не содержит техническое задание и не дублирует саму себя — ТЗ и Спецификация исключаются из раздела Документация.

Шаг 2. Оформите титульную часть​

По ГОСТ 19.105-78:

  • Указывается наименование документа: «СПЕЦИФИКАЦИЯ»
  • Обозначение документа (пример): Система_Х.СП.001-01
  • Наименование разработчика
  • Инв. №, дата, лист, утверждающие лица и т.п.

Шаг 3. Заполните раздел «Документация»​

Порядок внесения записей:​

  1. Собственные документы — в порядке возрастания кода вида документа (см. ГОСТ 19.101-77):

    ПЗ → РП → АП → ТП → ИО → ПО и т.д.

    Например:

    • Система_Х.ПЗ.001-01 — пояснительная записка
    • Система_Х.РП.001-01 — руководство программиста
    • Система_Х.ТП.001-01 — техническое описание

  2. Заимствованные документы — сначала по возрастанию кода организации-разработчика, затем по коду вида документа. Например:

    • ООО-Альфа.ПЗ.007-02
    • НИИ-Бета.РП.115-01

Содержание граф:​

ГрафаЧто указывать
ОбозначениеПолное обозначение документа (в одну строку!)
НаименованиеНаименование программы + наименование вида документа: «Система Х. Пояснительная записка» или «Библиотека CryptoLib. Руководство программиста»
ПримечаниеИсточник заимствования, версия, ограничения использования и др.

✅ Пример корректной записи:

Обозначение: Система_Х.РП.001-01  
Наименование: Система Х. Руководство программиста  
Примечание: Версия 2.3. Актуально для релиза 2025.04

Шаг 4. Заполните раздел «Комплексы» (если применимо)​

Заполняется только если специфицируемый объект — комплекс верхнего уровня, включающий другие комплексы.

❗ Многие ошибаются: не каждый набор программ — «комплекс».
По ГОСТ 19.101-77, комплекс программ — это совокупность программ или программных документов, предназначенных для решения определённой задачи и поставляемых вместе как единое изделие с собственной спецификацией.

Что вносить:​

  • Обозначения спецификаций вложенных комплексов (не их компонентов!).

Графы:​

ГрафаСодержание
ОбозначениеКомплекс_А.СП.001-01 — обозначение спецификации комплекса А
НаименованиеПолное наименование комплекса: «Комплекс обработки входящих заявок»
ПримечаниеСтепень интеграции, версия, интерфейсы и т.п.

⚠ Внимание: не вносите сюда компоненты комплексов — они должны быть в разделе Компоненты той спецификации, что относится к этому комплексу.

Шаг 5. Заполните раздел «Компоненты»​

Это — основной раздел практически любой спецификации.

Принцип:​

Каждая запись — один компонент, применяемый самостоятельно или как часть комплекса.

Обязательно включать:​

  • исполняемые модули (EXE, DLL, JAR, SO);
  • конфигурационные файлы, если они являются отдельными артефактами поставки;
  • сценарии развёртывания/миграции, если они оформлены как ПО (не просто инструкции);
  • тестовые наборы, если передаются как ПО.

Графы:​

ГрафаЧто указывать
ОбозначениеОбозначение основного программного документа компонента — чаще всего «Текст программы» (ТП), например: Система_Х.МодульАвторизации.ТП.001-01
НаименованиеПолное наименование программы + вид документа: «Модуль авторизации. Текст программы»
ПримечаниеЯзык, платформа, версия, зависимости, сборочная конфигурация

✅ Хорошая практика: в примечании указывать версию сборки и сборочную метку (например, Git-хэш или номер CI-билда).

3. Типичные ошибки и как их избежать​

№ОшибкаПоследствияРешение
1Включение ТЗ и самой спецификации в раздел ДокументацияНарушение требований п. 5 ГОСТСознательно исключайте их. Проверяйте перечень по видам документов.
2Перечисление компонентов во вложенном комплексе в родительской спецификацииДублирование, нарушение иерархииВ Комплексы вносится только ссылка на спецификацию комплекса, а не его содержимое.
3Пропуск заимствованных документовНеполнота комплекта поставки, риски при приёмкеСобирайте документы по лицензионным соглашениям, не только по исходному коду.
4Запись в несколько строк в графе ОбозначениеНарушение п. 8 ГОСТ (требуется одна строка!)Если обозначение длинное — сокращайте по внутренним правилам, но сохраняя уникальность и соответствие ЕСПД.
5Отсутствие свободных строк после разделовНевозможность внести изменения без перепечаткиОставляйте ≥ 3 строки в конце каждого раздела (п. 6 ГОСТ).
6Неправильная сортировка (не по коду вида документа)Затруднён поиск, нарушение стандартаИспользуйте справочник кодов из ГОСТ 19.101-77: ПЗ=1, РП=2, АП=3, ТП=4, ИО=5, ПО=6, ФО=7, АН=8, СП=9, ЭД=10 и др.
7Указание произвольного документа для компонентаНарушение п. 7: требуется основной программный документ (чаще — Текст программы)Уточните в техпроцессе, какой документ считается ОПД для компонента. Для большинства — ТП.

📌 Совет для обучения:
Проводите «ревизию спецификации» в формате перекрёстной проверки:

  • один участник составляет документ,
  • другой — сверяет по чек-листу (см. ниже),
  • третий — проверяет иерархию комплексов.

4. Пример: Спецификация для вымышленной системы «Арктур»​

Система «Арктур» — распределённая система мониторинга критической инфраструктуры (промышленные объекты).
Состоит из:

  • центрального сервера (CoreHub),
  • модуля сбора телеметрии (TelemCollector),
  • конфигуратора политик (PolicyEditor),
  • веб-интерфейса (WebUI),
  • встроенного комплекса аналитики (AnalyticsSuite — отдельный комплекс).

Спецификация оформлена как Арктур.СП.001-01.

4.1. Титульный лист (сокращённо)​

ГОСТ 19.202-78

СИСТЕМА «АРКТУР»
СПЕЦИФИКАЦИЯ

Обозначение: Арктур.СП.001-01

Разработал: ООО «Небесный Свод»
Дата: 11.11.2025
Лист 1
Изм. 0

4.2. Раздел: Документация​

ОбозначениеНаименованиеПримечание
Арктур.ПЗ.001-01Система «Арктур». Пояснительная запискаВерсия 1.2. Актуальна для релиза R2025Q4
Арктур.РП.001-01Система «Арктур». Руководство программистаВключает описание API и точек расширения
Арктур.АП.001-01Система «Арктур». Руководство администратораДля развёртывания на ОС Astra Linux 1.7
Арктур.ИО.001-01Система «Арктур». Инструкция по эксплуатацииДля персонала диспетчерской службы
Библиотека-КриптоЛайт.РП.105-02Библиотека КриптоЛайт. Руководство программистаВерсия 3.1. LGPLv3. От ООО «КриптоСфера»

(оставлено 4 свободных строки)

4.3. Раздел: Комплексы​

ОбозначениеНаименованиеПримечание
Арктур.Аналитика.СП.001-01Комплекс аналитики «Гелиос»Версия 2.0. Интеграция через REST/gRPC v2

(оставлено 3 свободных строки)

4.4. Раздел: Компоненты​

ОбозначениеНаименованиеПримечание
Арктур.CoreHub.ТП.001-01Ядро централизованной обработки. Текст программыC#, .NET 8, Linux/Windows. Хэш сборки: a3f8c21
Арктур.TelemCollector.ТП.001-01Модуль сбора телеметрии. Текст программыRust, systemd-service. Поддержка Modbus/OPC UA
Арктур.PolicyEditor.ТП.001-01Конфигуратор политик безопасности. Текст программыJava 17, JavaFX. Требует JRE 17+
Арктур.WebUI.ТП.001-01Веб-интерфейс контроля. Текст программыTypeScript + React 18, Node.js backend. Docker-образ: arcturus/webui:v4.2
Арктур.CommonLibs.ТП.001-01Общая библиотека сервисов. Текст программы.NET Standard 2.1. Shared assembly

(оставлено 5 свободных строк)

4.5. Примечания (по номерам, если не влезли в графу)​

1. Все исполняемые компоненты собираются в CI/CD на основе pipeline #ARCT-PIPE-2025.
2. Конфигурационные файлы поставляются отдельно в составе комплекта «Арктур.КОМПЛЕКТ.001».
3. Модуль PolicyEditor требует лицензионного ключа, поставляемого отдельно.

5. ✅ Проверочный чек-лист для составления спецификации​

№Пункт проверкиВыполнено?
1Есть титульный лист по ГОСТ 19.105-78☐
2Обозначение документа соответствует внутренней системе и включает .СП.☐
3Раздел Документация не содержит ТЗ (ТЗ) и саму Спецификацию (СП)☐
4Собственные документы отсортированы по возрастанию кода вида (ПЗ → РП → АП → ТП …)☐
5Заимствованные документы отсортированы по коду организации, затем по коду вида☐
6В Комплексы указаны только обозначения спецификаций, а не компоненты☐
7В Компоненты для каждого элемента указано обозначение основного документа (обычно .ТП.)☐
8Графа Обозначение — всегда в одну строку☐
9После каждого раздела — ≥ 3 свободных строки☐
10Все записи имеют непустые Наименование и корректные Примечания (или ссылки на сноски)☐
11При наличии сносок — они пронумерованы и расшифрованы☐
12Таблица оформлена без слияния ячеек, шрифт — моноширинный или стандартный (Courier/Consolas) для кодов☐
13Документ утверждён согласно внутреннему регламенту (подписи, дата)☐

📌 Финальная проверка:
Откройте спецификацию через 24 часа — если вы можете однозначно восстановить по ней:

  • что входит в поставку,
  • где лежат документы,
  • какие компоненты какие документы имеют,
    — документ составлен корректно.

См. также

Другие статьи этого же раздела в боковом меню (как на странице «О разделе»).

Ещё 8 статей в разделе

Освоение главы0%