Спецификация по ГОСТ 19.202-78
ERD и словарь сущностей — Entity Relationship, нормализация, SQL. Карта — о разделе.
Спецификация программного обеспечения
Спецификация (ГОСТ 19.202) — опись состава поставки — какие программы, модули, носители и сопроводительные документы входят в комплект. ТЗ фиксирует что должно работать; спецификация — что именно передаётся на носителях и в репозитории.
Проще всего воспринимать спецификацию как "акт состава": по ней заказчик и команда одинаково понимают, что входит в релиз и что должно быть передано вместе с программой.
Основано на ГОСТ 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. Подготовка
- Убедитесь, что определена граница системы:
- Что входит в поставку?
- Какие компоненты считаются внешними и не включаются в спецификацию (например, СУБД, ОС, сторонние SDK)?
- Получите утверждённый перечень:
- всех программных модулей;
- всех программных документов (ГОСТ 19.101-77 — ПЗ, РП, АП, ТП и др.);
- всех вложенных комплексов (если иерархия многоуровневая).
⚠ Важно: спецификация не содержит техническое задание и не дублирует саму себя — ТЗ и Спецификация исключаются из раздела
Документация.
Шаг 2. Оформите титульную часть
По ГОСТ 19.105-78:
- Указывается наименование документа: "СПЕЦИФИКАЦИЯ"
- Обозначение документа (пример):
System_Х.СП.001-01 - Наименование разработчика
- Инв. №, дата, лист, утверждающие лица и т.п.
Шаг 3. Заполните раздел "Документация"
Порядок внесения записей
- Собственные документы — в порядке возрастания кода вида документа (см. ГОСТ 19.101-77):
ПЗ → РП → АП → ТП → ИО → ПО и т.д.
Например:
System_Х.ПЗ.001-01— пояснительная запискаSystem_Х.РП.001-01— руководство программистаSystem_Х.ТП.001-01— техническое описание
- Заимствованные документы — сначала по возрастанию кода организации-разработчика, затем по коду вида документа. Например:
ООО-Альфа.ПЗ.007-02НИИ-Бета.РП.115-01
Содержание граф
| Графа | Что указывать |
|---|---|
| Обозначение | Полное обозначение документа (в одну строку!) |
| Наименование | Наименование программы + наименование вида документа: "Система Х. Пояснительная записка" или "Библиотека CryptoLib. Руководство программиста" |
| Примечание | Источник заимствования, версия, ограничения использования и др. |
✅ Пример корректной записи:
Шаг 4. Заполните раздел "Комплексы" (если применимо)
Заполняется только если специфицируемый объект — комплекс верхнего уровня, включающий другие комплексы.
❗ Многие ошибаются: не каждый набор программ — "комплекс".
По ГОСТ 19.101-77, комплекс программ — это совокупность программ или программных документов, предназначенных для решения определённой задачи и поставляемых вместе как единое изделие с собственной спецификацией.
Что вносить
- Обозначения спецификаций вложенных комплексов (не их компонентов!).
Графы
| Графа | Содержание |
|---|---|
| Обозначение | Комплекс_А.СП.001-01 — обозначение спецификации комплекса А |
| Наименование | Полное наименование комплекса: "Комплекс обработки входящих заявок" |
| Примечание | Степень интеграции, версия, интерфейсы и т.п. |
⚠ Внимание: не вносите сюда компоненты комплексов — они должны быть в разделе
Компонентытой спецификации, что относится к этому комплексу.
Шаг 5. Заполните раздел "Компоненты"
Это — основной раздел практически любой спецификации.
Принцип
Каждая запись — один компонент, применяемый самостоятельно или как часть комплекса.
Обязательно включать
- исполняемые модули (
EXE,DLL,JAR,SO); - конфигурационные файлы, если они являются отдельными артефактами поставки;
- сценарии развёртывания/миграции, если они оформлены как ПО (не просто инструкции);
- тестовые наборы, если передаются как ПО.
Графы
| Графа | Что указывать |
|---|---|
| Обозначение | Обозначение основного программного документа компонента — чаще всего "Текст программы" (ТП), например: System_Х.МодульАвторизации.ТП.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 часа — если вы можете однозначно восстановить по ней:
- что входит в поставку,
- где лежат документы,
- какие компоненты какие документы имеют,
— документ составлен корректно.
Дополнение — спецификация как инструмент контроля поставки
Что часто забывают включить
- версии внешних библиотек и лицензии;
- утилиты миграции и их документацию;
- шаблоны конфигурации для стендов и продакшена;
- контрольные суммы артефактов.
Быстрая ревизия перед сдачей
- Сверьте фактические артефакты со списком в спецификации.
- Проверьте работоспособность ссылок на документы.
- Убедитесь, что у каждого пункта есть владелец и версия.