6.04. Спецификация по ГОСТ 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. Подготовка
- Убедитесь, что определена граница системы:
- Что входит в поставку?
- Какие компоненты считаются внешними и не включаются в спецификацию (например, СУБД, ОС, сторонние SDK)?
- Получите утверждённый перечень:
- всех программных модулей;
- всех программных документов (ГОСТ 19.101-77: ПЗ, РП, АП, ТП и др.);
- всех вложенных комплексов (если иерархия многоуровневая).
⚠ Важно: спецификация не содержит техническое задание и не дублирует саму себя — ТЗ и Спецификация исключаются из раздела
Документация.
Шаг 2. Оформите титульную часть
По ГОСТ 19.105-78:
- Указывается наименование документа: «СПЕЦИФИКАЦИЯ»
- Обозначение документа (пример):
Система_Х.СП.001-01 - Наименование разработчика
- Инв. №, дата, лист, утверждающие лица и т.п.
Шаг 3. Заполните раздел «Документация»
Порядок внесения записей:
-
Собственные документы — в порядке возрастания кода вида документа (см. ГОСТ 19.101-77):
ПЗ → РП → АП → ТП → ИО → ПО и т.д.Например:
Система_Х.ПЗ.001-01— пояснительная запискаСистема_Х.РП.001-01— руководство программистаСистема_Х.ТП.001-01— техническое описание
-
Заимствованные документы — сначала по возрастанию кода организации-разработчика, затем по коду вида документа. Например:
ООО-Альфа.ПЗ.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 часа — если вы можете однозначно восстановить по ней:
- что входит в поставку,
- где лежат документы,
- какие компоненты какие документы имеют,
— документ составлен корректно.