Документация

Руководство пользователя СУТР Навигатор

1. Начало работы

Обзор

СУТР Навигатор — система управления требованиями, разработанная для обеспечения соответствия КТ-178С при разработке авиационного программного обеспечения. Система предоставляет инструменты для управления требованиями, трассируемости, контроля изменений, документов жизненного цикла и сертификационных артефактов.

Главная страница

Главная страница представляет четыре ключевые возможности СУТР Навигатор: Редактор документов, Трассируемость требований, Соответствие КТ-178С и Импорт/экспорт. Нажмите «Попробовать бесплатно» для регистрации или «Вход» для входа в систему.

Регистрация

Для создания учётной записи укажите имя, адрес электронной почты и пароль. После регистрации на указанный адрес будет отправлено письмо для подтверждения. Перейдите по ссылке в письме для активации учётной записи.

Вход в систему

Введите адрес электронной почты и пароль для входа в систему. Используйте флажок «Запомнить меня» для сохранения сессии. Если вы забыли пароль, нажмите «Забыли пароль?» для сброса.

2. Навигация

Боковая панель

После входа рабочее пространство организовано вокруг боковой панели, у которой три яруса. Сверху — **глобальный хаб**, не зависящий от выбранного пространства: «Дашборд» (`/dashboard`) и «Мои ФИ» (`/inspections`). Под ним — **переключатель пространства**: пространства переключаются здесь, отдельным пунктом основной навигации они не являются. Далее — **навигация внутри пространства**: «Документы», «Проекты», «Спецификации», «Изменения», «Сертификация», «Документы ЖЦ», «Импорт», ниже — «Корзина», а в самом низу — «Настройки» рядом со «Справкой» и меню профиля. Боковую панель можно свернуть до режима иконок. Используйте Ctrl+K для вызова глобального поиска из любого места.

3. Документы

Управление документами

Раздел «Документы» — это область общего управления документами. Создавайте документы, организуйте их в папки, фильтруйте по типу/статусу/сортировке, ищите по названию, переключайте вид между списком и сеткой. Каждый документ имеет статус (Черновик, Опубликован, Архивный), автора и дату изменения.

Редактор документов

Редактор документов основан на TipTap (ProseMirror) и поддерживает форматирование: заголовки, списки, таблицы, изображения, блоки кода и многое другое. Все изменения сохраняются автоматически с историей версий.

4. Пространства

Рабочие пространства

Пространства — это изолированные рабочие области для командной работы. Каждое пространство имеет свои документы, спецификации, требования, участников, запросы на изменение, сообщения о проблемах и сертификационные артефакты. Роли пространства: **Владелец**, **Администратор**, **Участник** и **Наблюдатель** — именно «Участник», а не «Редактор». Роль задаёт базовый доступ к спецификациям пространства (участник → редактирование, наблюдатель → просмотр, владелец и администратор → утверждение); поверх этого базового уровня действуют командные права на конкретную спецификацию (VIEW / EDIT / REVIEW / APPROVE).

5. Спецификации и требования

Список спецификаций

Спецификации — это контейнеры для требований. Каждая спецификация имеет уникальный код (например, SRS-001), тип (SRS, SDD, HLR, LLR, IRS, STP, STD, SVP) и версию.

Детали спецификации

При открытии спецификации отображаются: заголовок с кодом и статусом, карточки статистики с количеством требований, кнопки действий (Инспекции, Базовые линии, Матрица трассируемости, Анализ покрытия, Импорт, Экспорт) и список требований в режиме Дерево или Таблица.

Статус самой спецификации

У спецификации есть собственный статус, отдельный от статусов объектов внутри неё. Значений пять: **Черновик** (DRAFT), **На инспекции** (IN_REVIEW), **Утверждено** (APPROVED), **Выпущено** (RELEASED), **Устарело** (OBSOLETE). Он показан плашкой рядом с кодом — на карточке в списке спецификаций и в заголовке открытой спецификации. Только что созданная спецификация всегда «Черновик». Не путайте его со статусом объекта внутри спецификации (Черновик → Готово к инспекции → На инспекции → Утверждено / Отклонено / Устарело): статусом объекта движут повседневная работа и формальная инспекция, а статус спецификации — подпись для документа целиком. Формулировка «На инспекции» есть в обоих словарях и означает разное. Знать про этот статус стоит две вещи. Первое: **он ничего не блокирует** — при отказе в правке он не проверяется нигде. Документ замораживает отдельная заморозка («Заморозить», значок замка — см. «Настройки») и шлюз ЗИ, а объект защищён собственным статусом «На инспекции». Спецификация в «Выпущено» или «Устарело» остаётся полностью редактируемой, пока не заморожена. Второе: **в веб-интерфейсе нет элемента, который его меняет** — ни выпадающего списка в заголовке спецификации, ни пункта в меню «Настройки», и в диалоге создания его тоже не выбрать. Меняется он через REST API (`PATCH /api/v1/specifications/:id`) или MCP-инструментом `update_specification`, обладателем права на правку (EDIT), причём сервер разрешает только такие переходы: Черновик → На инспекции / Устарело; На инспекции → Утверждено / Черновик / Устарело; Утверждено → Выпущено / Устарело; Выпущено → Устарело; «Устарело» — конечный. Автоматически его не выставляет ничто: старт формальной инспекции переводит в «На инспекции» *объекты*, а спецификацию не трогает; утверждение базовой версии записывает спецификации только номер версии; заморозка статус не меняет. Статус спецификации проставляется вручную и ни на что не влияет; жизненный цикл утверждённой конфигурации документа ведут рабочие и базовые версии документа (см. «Базовые линии»), а не это поле. Ничего он и не фильтрует: в списке спецификаций фильтра по статусу нет, а «Устарело» спецификацию не прячет.

Табличный вид

Табличный вид предоставляет табличный интерфейс с колонками: Код, Описание, Статус, DAL, Верификация, Безопасность, Производное, Связи и Комментарии. Добавляйте требования, нажав «+ Добавить требование...» внизу таблицы. Кнопка «Фильтры» в тулбаре открывает быстрые фильтры: по типу объекта (требование, раздел, текст, допущение), по связям (есть/нет, входящие/исходящие, тип связи) и по разделу документа — выберите раздел, чтобы работать только с его поддеревом. При активном фильтре счётчик показывает «N из M», чтобы скрытые строки не выглядели потерянными; кнопка «Сбросить» снимает все фильтры одним действием.

Фильтры: выключение без сброса и разделы-контекст

Настроенный фильтр можно временно выключить, не теряя условий: рядом с кнопкой «Фильтры» показывается переключатель (он появляется, только когда фильтр настроен). Пока фильтр выключен, показывается полный список — кнопка приглушена, бейдж числа условий серый, а рядом со счётчиком стоит плашка «фильтр выключен»; включение возвращает ровно тот же срез — сохраняются и быстрые фильтры, и правила конструктора. «Сбросить» остаётся отдельным действием и очищает условия. Если задать условия при выключенном фильтре, он включится сам. Состояние переключателя хранится по каждой спецификации и переживает уход со страницы. Вторая настройка — чек-бокс «Показывать разделы» в панели фильтра (включён по умолчанию): к найденным объектам добавляются разделы, в которых они находятся, — вся цепочка предков до корня документа, чтобы у каждого совпадения был виден его адрес в документе. Разделы-контекст не считаются совпадениями: счётчик показывает только найденное («показано 3 из 5»), а рядом отдельной приглушённой подписью идёт «+N для контекста». Впервые появившиеся контекстные разделы раскрываются автоматически, чтобы найденное внутри свёрнутого раздела не осталось невидимым; ручное сворачивание при этом не отменяется.

Показ удалённых объектов в спецификации

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

Удаление объектов: что мешает удалить

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

Перемещение объектов и уровни

Любой объект — требование, раздел, обычный текст, допущение — можно переместить в другой раздел через контекстное меню: правый клик по строке → «Переместить…». Пункт доступен и в дереве, и в таблице, работает для одного объекта и для мультивыбора: выделите объекты галочками и сделайте правый клик по любой из выделенных строк — пункт «Переместить…» покажет число выбранных. В диалоге «Переместить в раздел» предлагаются только разделы документа и первым пунктом — «В корень документа»: родителем объекта может быть только раздел или корень документа; перемещаемые объекты и их потомки из списка исключены. Перемещённые объекты встают в конец выбранного раздела, сохраняя взаимный порядок, а нумерация пересчитывается автоматически. Для перемещения достаточно обычного права редактирования спецификации. Перетаскивание мышью — отдельный механизм: оно меняет только порядок среди объектов одного родителя. Уронить строку к другому родителю нельзя — цель подсвечивается красным с запрещающим курсором, а при отпускании появляется подсказка, что для смены раздела есть «Переместить…». Смена уровня — в подменю контекстного меню «Уровень в дереве»: пункты «Повысить уровень» и «Понизить уровень (сделать подразделом)» доступны для всех видов объектов; понижение вкладывает объект в предшествующий раздел.

Просмотр связей из таблицы

Связи трассировки видны прямо в табличном виде, без открытия редактора требования. Клик по значку связей в колонке «Связи» открывает всплывающее окно со списком связей требования, разделённым на «Входящие» и «Исходящие»; в каждой строке — тип связи, код целевого объекта и целевой документ, подозрительные связи помечены янтарным. Клик по строке открывает целевую спецификацию в табличном виде с прокруткой к целевому объекту и его подсветкой (строка становится текущей и дополнительно заливается мягким цветом, затухающим через несколько секунд). Повторные переходы в тот же документ не плодят вкладки: вкладка целевого документа именована, и следующий переход переиспользует уже открытую — в том числе вкладку, которую вы открыли сами. Если целевой объект находится в открытом сейчас документе, навигации не происходит вовсе — строка просто фокусируется. Ctrl/Cmd-клик и «открыть в новой вкладке» из меню браузера работают как обычно и открывают новую вкладку. Для постоянного обзора включите колонку «Связи (подробно)» через меню «Столбцы» (по умолчанию она скрыта): в ней все связи перечислены строками «документ/код», каждая — переход к цели. Там же доступна колонка «Связанные» — только с кодами целевых объектов.

Подписи таблиц и рисунков, перекрёстные ссылки

У таблицы и рисунка может быть подпись, а текст может на них ссылаться. Чтобы задать подпись таблице, поставьте курсор внутрь любой её ячейки — над таблицей появится панель с кнопкой подписи; для рисунка выделите изображение и воспользуйтесь полем подписи в его меню. Чтобы сослаться на таблицу или рисунок из текста, нажмите на панели кнопку «Вставить ссылку на таблицу/рисунок» либо выберите ту же команду в слэш-меню и укажите цель в списке; цели собираются по всей спецификации, поэтому сослаться можно и на таблицу из другого объекта. Номер нигде не хранится: в редакторе ссылка показывается плейсхолдером («Таблица ?»), а сквозной номер подставляется при выгрузке в HTML, Markdown, DOCX и PDF. Именно поэтому вставка и удаление объектов ссылку не ломают — в отличие от номера, вписанного в текст руками: такой номер никем не поддерживается и молча расходится с документом. В нумерации участвуют и предлагаются в списке целей только объекты, у которых задана подпись.

Переход к объекту (Ctrl+G)

В открытой спецификации нажмите Ctrl+G (Cmd+G на macOS), чтобы перейти к объекту по его коду. Введите полный код (например, FSCUR-SYS-REQ-042), его часть (OFP) или просто номер (42 — сопоставляется с числовым хвостом кода); список подсказок обновляется по мере ввода. Enter — переход к первому совпадению (стрелками можно выбрать другое), Esc — закрыть окно. Работает в видах «Дерево» и «Таблица»; найденная строка прокручивается на экран и кратко подсвечивается. Сочетание не срабатывает, пока фокус находится в текстовом поле или редакторе.

Детали требования

Каждое требование имеет: Код (автогенерируемый), Содержание (с форматированием), Статусный процесс (Черновик → Готово к инспекции → На инспекции → Утверждено), Уровень DAL (A-E), Флаг безопасности, Флаг производного, Метод верификации, Обоснование, Родитель и Трассировочные связи.

Виды объектов

Строка в спецификации — не всегда требование. Видов четыре: **Требование** — проверяемое утверждение, несущее трассируемость и покрытие; **Раздел** — структурный заголовок, по которому нумеруется документ; **Обычный текст** — вводная или поясняющая проза, которая должна быть в документе, но не верифицируется; **Допущение** — у него своя дорожка валидации (статус валидации и связи BASED_ON, Р-4754А §5.4.2(d)) и отдельная вкладка «Допущения». Вид можно изменить у существующей строки, но превращение требования в не-требование выводит строку из проверяемого набора требований и из покрытия трассируемости; если строка уже входит в базовую версию, система предупредит, что это изменение, требующее управления изменениями (КТ-178С §7.2.4). Инспектируются требования, разделы и обычный текст; допущения — нет. От вида зависит и то, обязателен ли на самом деле пользовательский атрибут, отмеченный «Обязательный» в схеме спецификации: обязательность действует **только у вида «Требование»**. У раздела, обычного текста и допущения то же поле по-прежнему показывается и его можно заполнить, но звёздочкой оно не помечается и пустое значение сохранение не блокирует — схема описывает инженерные свойства требования (владелец, компонент аппаратуры и тому подобное), а раздел и обычный текст — это структура и проза, и пустое поле у них честно означает «неприменимо». Никакой заглушки система не подставляет: подставленное значение попало бы в выгрузки и матрицы и было бы неотличимо от осознанно заполненного. Превращение существующего раздела в требование из-за незаполненных обязательных атрибутов не отклоняется: строка сохраняется, а пустое поле просто появляется со звёздочкой в форме правки. Прежних видов «Примечание» и «Пример» больше нет.

Как удалить объект и вернуть его из корзины

Удалить один объект: правый клик по строке в дереве или в таблице → **«Удалить»**. Удалить несколько: отметьте их галочками в таблице и нажмите «Удалить» на панели массовых действий либо сделайте правый клик по любой выделенной строке — пункт тогда называется «Удалить (N)». На странице требования есть своя кнопка удаления с подтверждением браузера. Диалог называется «Удаление объектов» и спрашивает «Вы уверены, что хотите удалить выбранные объекты (N)?». Удаление мягкое: объект уходит в корзину пространства с датой удаления, и его можно восстановить; необратимо только окончательное удаление, которое делается позже в корзине. Одиночное удаление никогда не каскадное — объект с живыми потомками просто не удалится. Массовое удаление поддерево удаляет, но только если всё поддерево попало в выборку; иначе операция отклоняется и мешающие объекты названы поимённо. Все связи трассировки удалённого объекта — и входящие, и исходящие — помечаются подозрительными, чтобы объекты на другом конце увидели, что под ними что-то изменилось. Вернуть удалённый объект можно из двух мест. Внутри спецификации: включите «Показывать удалённые» в панели фильтров табличного вида, найдите приглушённую строку и выберите в её контекстном меню «Восстановить» (см. отдельный раздел). Либо из корзины пространства: **«Корзина»** в боковой панели (`/<space>/trash`), вкладка «Требования»; в том же контекстном меню строки есть пункт «Открыть в корзине» — он открывает корзину, уже суженную до текущей спецификации. Для восстановления нужно право на правку документа — то же, что и для удаления. Если родитель объекта всё ещё удалён, объект возвращается в корень документа, и дальше его переносят куда нужно; если удалена вся спецификация — сначала восстанавливают спецификацию, восстановить отдельный объект в удалённой спецификации нельзя. Окончательное удаление — отдельная история. «Удалить навсегда» у строки и «Очистить корзину» доступны владельцу пространства или администратору, а в подтверждении требуется вручную набрать код объекта. Окончательное удаление стирает объект вместе с его уже удалёнными потомками и освобождает их коды — именно это разблокирует повторный импорт. Оно запрещено для объекта, который участвовал в формальной инспекции, входит в базовую версию либо связан с сообщением о проблеме или запросом на изменение: сертификационный след не должен исчезать. «Очистить корзину» такие объекты не удаляет, а пропускает, не срывая всю операцию. Срока хранения нет: объекты спецификаций и сами спецификации лежат в корзине бессрочно, по таймеру их не удаляет ничто. Через MCP ассистент может мягко удалить, восстановить и посмотреть корзину (`delete_requirement`, `restore_requirement`, `list_trash`), а окончательное удаление ему намеренно запрещено — его выполняет человек в веб-корзине.

Массовое выделение и массовые операции

Массовое выделение есть **только в табличном виде**. Дерево и Markdown-вид работают с одним текущим объектом, и действие контекстного меню там всегда применяется к одной строке. В таблице первый столбец — столбец с галочками, он закреплён слева рядом со столбцами «№», «Тип» и «Код». **Галочки «выделить всё» в шапке нет**: чтобы выделить всё, щёлкните внутри таблицы и нажмите Ctrl+A (Cmd+A на macOS) — выделятся показанные сейчас строки, то есть то, что осталось после активного фильтра, и только внутри раскрытых разделов; объекты, спрятанные в свёрнутом разделе, не выделяются. Диапазон выделяется как в таблицах: щёлкните первую галочку, затем щёлкните последнюю с зажатым Shift. Ctrl-клик по строке ничего не выделяет — выделение только галочками, обычный клик просто переносит фокус. Удалённые строки, показанные чек-боксом «Показывать удалённые», галочкой поодиночке не выбираются, но Ctrl+A их выделяет, и массовая операция над таким выделением отказывает целиком, — снимите показ удалённых перед выделением. Как только выделена хотя бы одна строка, внизу экрана появляется тёмная панель: счётчик «N выбрано», «Изменить статус», «Изменить DAL», кнопка «...», «Удалить» и крестик, снимающий выделение. В «Изменить статус» предлагаются только нефинальные статусы — Черновик, Готово к инспекции, На инспекции, — потому что финальные проставляются по итогам формальной инспекции; выбор «На инспекции» не пишет статус напрямую, а открывает диалог отправки на инспекцию. Кнопка «...» открывает диалог массового редактирования, и здесь важное ограничение: диалог меняет **по одному полю за раз** — выбор «Поле», элемент «Значение» и кнопка «Применить к N требованиям». Предлагаются поля Тип, Статус, Уровень DAL, Метод верификации, Требование безопасности, Производное требование, Номер ЗИ (с переключателем «Режим» — «Дописать новой строкой» или «Заменить») и все пользовательские атрибуты этой спецификации; встроенные атрибуты, скрытые в настройках спецификации, не предлагаются. Для «Статуса» список — пересечение переходов, разрешённых для всех выделенных объектов; остальные показаны неактивными с пояснением причины. Поэтому «выделить все требования и сделать идентичные изменения во всех колонках» делается повторными применениями по одному полю, а не одной операцией, — а текст объекта, его код и его связи трассировки массово не правятся вообще. Массовая правка текста — отдельный инструмент, «Найти и заменить», и работает он по всем живым объектам спецификации, а не по выделению (и недоступен при включённом шлюзе ЗИ). Контекстное меню тоже действует на всё выделение, если сделать правый клик по одной из отмеченных строк: «Переместить…», «Связать с якорем», «Изменить статус», «Удалить (N)». Объекты «На инспекции» отметить галочкой можно, но сервер отклонит всю пачку — единственное исключение — возврат их в «Черновик». Правило «всё или ничего» здесь общее: один недопустимый переход, один потомок вне выборки — и не применится ничего. За одну операцию обрабатывается не более 500 объектов.

Нумерация объектов и коды

Столбец «№» — **только для разделов**. Раздел получает иерархический номер — 1, 1.1, 1.1.1, — а объекты остальных видов для нумерации прозрачны: у требования, обычного текста и допущения номера нет вовсе, а вложенные в них объекты сохраняют номер объемлющего раздела. Номер нигде не хранится: он вычисляется по дереву каждый раз при показе документа, поэтому вставка, перемещение и удаление объектов перенумеровывают всё сами, и номера физически не могут разойтись со структурой. По той же причине **номер нельзя вписать или назначить руками** — ячейка «№» не редактируется, номера не импортируются, и никакой настройки «нумерация» у требования нет. Так сделано намеренно: требование опознаётся кодом, а не номером пункта; код остаётся при нём навсегда, а номер пункта меняется от каждой вставки выше. Если нужно назвать место требования в документе, его адресуют номером раздела плюс кодом. Код присваивается автоматически каждому объекту — требованию, разделу, обычному тексту, допущению — из единого сквозного счётчика спецификации в порядке создания. Вид кода задаёт **шаблон кода** спецификации: откройте спецификацию → «Настройки» → «Шаблон кода». В диалоге видны сам шаблон, следующий код, который будет выдан, и плейсхолдеры: `{NNN}` — счётчик, `{NNN:N}` — счётчик с ведущими нулями до N знаков (число после двоеточия — общая длина: `{NNN:3}` и `{NNN:03}` одинаково дают `001`; шаблон по умолчанию — `REQ-{NNN:03}`), `{GROUP}` — код группы, берущийся от ближайшего объемлющего раздела. Плейсхолдер счётчика обязателен и должен быть ровно один; в литеральной части допустимы буквы, цифры и разделители `. _ / -`. Если в шаблоне есть `{GROUP}`, счётчик ведётся по группам, а не по всей спецификации. Когда шаблон не задан, коды выглядят как `REQ-001`. Смена шаблона действует **только на новые объекты** — существующие коды остаются как были. Перегенерация — отдельное явное действие: «Перекодировать существующие требования…» в том же диалоге; оно показывает предпросмотр («Старый код» / «Новый код», «Изменится кодов: X из Y») и требует подтверждения. Трассировка это переживает — связи хранятся по идентификаторам объектов, а не по кодам, — но ранее выгруженные документы и снимки базовых версий сохранят старые коды, а пока объекты на инспекции, перекодирование отклоняется. Отдельный код можно поправить и вручную: двойной клик по ячейке «Код» в таблице. Ещё одно, что полезно знать про импорт: идентификатор из исходного документа Word кодом объекта не становится — коды всегда выдаёт шаблон, — а номер пункта из документа сохраняется отдельным служебным полем и используется при импорте для сопоставления межтекстовых связей; в интерфейсе он не показывается и на «№» не влияет. Номера таблиц и рисунков — третий, самостоятельный механизм, не связанный ни с тем, ни с другим; см. «Подписи таблиц и рисунков, перекрёстные ссылки».

6. Трассируемость и покрытие

Матрица трассируемости

Матрица трассируемости показывает связи между требованиями различных спецификаций. Типы связей: SATISFIES (зелёный), DERIVES_FROM (синий), VERIFIED_BY (фиолетовый), IMPLEMENTS (индиго), REFINES (голубой), CONFLICTS (красный), DEPENDS_ON (жёлтый) и TRACES_TO (серый). Подозрительные связи автоматически помечаются при изменении связанных требований. Набор типов, предлагаемых при создании связи, владелец или администратор пространства может сузить на странице «Настройки пространства → Типы связей»; скрытие мягкое — существующие связи скрытого типа продолжают жить, отображаться, попадать в матрицу, а фильтры по типу связи по-прежнему предлагают все типы.

Двухпанельный режим

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

Работа с подозрительными связями

Трассировочная связь помечается подозрительной автоматически, когда у одного из связанных требований меняется значимое поле — содержимое, обоснование, статус, уровень DAL или признак безопасности. Версия требования инкрементируется, а все его трассировочные связи получают признак «подозрительная» с причиной (какие поля изменились) и датой («Подозрительна с»). Признак означает, что связь должна быть ре-валидирована инженером — по КТ-178С §5.5 (трассируемость) и §6.3 (рассмотрения и анализы): изменение наверху могло нарушить корректность связи. Связь остаётся подозрительной, пока человек её не подтвердит, — автоматически пометка не снимается. Порядок действий, чтобы сделать связь не подозрительной: (1) Найдите подозрительные связи — либо на панели трассировочных связей конкретного требования (значок ⚠), либо во вкладке «Подозрительные связи» Матрицы трассируемости / во вкладке «Пробелы» страницы трассируемости проекта; каждая строка показывает откуда, куда, тип, «Подозрительна с» и причину. (2) Откройте оба связанных требования и убедитесь, что связь по-прежнему корректна после изменения — что содержимое, обоснование и верификация остаются согласованными. Это инженерное рассмотрение, а не клик «для галочки». (3) Если связь больше не верна — сначала поправьте требование или связь (или удалите связь, если она ошибочна). (4) Когда связь подтверждена как корректная, нажмите «Снять подозрение» в её строке. Это сбрасывает признак, убирает причину и дату, фиксирует, кто и когда снял подозрение, и пишет запись в журнал аудита (SUSPECT_CLEARED). Требуется право EDIT на исходную спецификацию. (5) Для распределений DAL аналог — обновление распределения: изменение IDAL снимает признак подозрительности, выставленный при изменении FDAL.

Анализ покрытия

Анализ покрытия показывает процент требований, покрытых верификационными мероприятиями. Это поддерживает Таблицу A-7 КТ-178С, выявляя непокрытые требования, полностью покрытые требования и общий процент покрытия.

7. Системная инженерия (Р-4754А / Р-4761)

Системные проекты

Системный проект (Р-4754А / ARP4754A) находится над программным контуром и объединяет спецификации, функции системы, интерфейсы и оценки безопасности одной системы. Дашборд проекта показывает системный DAL (уровень гарантии разработки), число функций, спецификаций и оценок безопасности, привязанные спецификации по доменам (ПО / Аппаратура / Система) и сводку покрытия трассируемостью. СУТР Навигатор хранит артефакты системной инженерии и связи между ними и не диктует методологию обеспечения безопасности.

Функции системы и FHA

Функции системы образуют иерархию, полученную из оценки функциональных опасностей (FHA, Р-4761 / ARP4761). Каждая функция имеет FDAL (функциональный уровень гарантии разработки, A–E), серьёзность отказного состояния (катастрофический / опасный / существенный / незначительный / без последствий) и статус (Выявлена → Проанализирована → Распределена → Верифицирована → Закрыта). Список показывает FDAL и серьёзность рядом, что делает назначение уровня гарантии по серьёзности проверяемым. FHA/PSSA/SSA — это мероприятия оценки безопасности, они отмечаются на оценке, а не на функции.

Распределение DAL: FDAL → IDAL

Распределение DAL отображает каждую функцию системы на спецификации, которые её реализуют, присваивая каждому элементу-исполнителю IDAL (уровень гарантии разработки элемента). IDAL может быть ниже FDAL функции при обосновании архитектурой — независимостью или резервированием элементов; в этом случае требуется обоснование и устанавливается признак независимости (Р-4754А). Вкладка «Матрица» трассируемости показывает функции × спецификации с IDAL в каждой ячейке, помечает ячейки, где IDAL < FDAL, и подсвечивает распределения, ставшие подозрительными после изменения FDAL функции и требующие ре-валидации.

Оценка отказобезопасности (FHA → PSSA → SSA → CCA)

Оценки отказобезопасности следуют жизненному циклу Р-4761 / ARP4761: FHA → PSSA → SSA, а также CCA (анализ общих причин). Каждая оценка проходит статусы Черновик → В работе → Завершена → Утверждена и содержит замечания, классифицированные по серьёзности и категории (вид отказа, общая причина, независимость, пробел покрытия, ошибка проектирования). Замечание можно связать с требованиями, которые его парируют или которых оно касается, — это делает результат оценки безопасности трассируемым на набор требований. СУТР Навигатор хранит результаты оценки и связи; сам анализ остаётся зоной ответственности инженера. PSSA отображается как чек-лист разделов (перечень функций, требования безопасности, FMEA, распределение DAL, общий режим, допущения, FTA, распределение вероятностей); каждый раздел либо Нативно — закрывается данными СУТР, либо Документ — закрывается приложенным файлом. FTA и распределение вероятностей по умолчанию — Документ, до появления нативных моделей. Готовность считается по разделам, поэтому доказательство, приложенное документом, засчитывается как закрытие, а не пробел. Для раздела FTA есть нативный редактор дерева неисправностей — стройте вентили и события (Р-4761 D.4) с авто-диаграммой сверху вниз; это закрывает раздел без вложения. Редактор также выполняет количественную оценку (Р-4761 D.11): вероятность верхнего события, минимальные сечения и вероятности узлов по интенсивности отказов λ, времени миссии и логике вентилей; узлы без данных помечаются.

Деревья неисправностей (FTA)

Редактор FTA (открывается из раздела FTA у PSSA) строит деревья неисправностей структурным аутлайном с авто-диаграммой сверху вниз по символам Р-4761 D.4: вентили (И / ИЛИ / Приоритетное И / Блокировка) и события (основное / неразрабатываемое / дом / условное). Задайте интенсивность отказов λ на основных событиях, время миссии на дереве, k для Приоритетного И и условные вероятности. Панель «Анализ» считает количественный результат (Р-4761 D.11): вероятность верхнего события, минимальные сечения с их вероятностями и вероятности узлов; узлы без данных помечаются. Нативное дерево закрывает раздел FTA в PSSA без вложения.

FMEA и FMES

Рабочие листы FMEA (Р-4761) фиксируют по каждому элементу или функции вид отказа с локальным эффектом, эффектом на следующем уровне и конечным эффектом, серьёзность, интенсивность отказов λ, обнаруживаемость и парирование. Запись FMEA можно связать с требованием, которое её парирует (MITIGATES), — так парирование становится трассируемым. Записи сворачиваются в сводку FMES: Σλ по конечным эффектам. Оба анализа связаны с деревом неисправностей: основное событие может брать λ из связанной записи FMES, поэтому пересчёт FMES обновляет интенсивности на связанных узлах, а не оставляет дерево незаметно устаревшим. Показатель RPN доступен, но помечен как **не метод Р-4761** — Р-4761 ранжирует по серьёзности и интенсивности отказов, а не по числу приоритета риска. Про охват: у FMEA/FMES пока нет отдельного экрана в веб-интерфейсе — рабочие листы и записи ведутся через REST API, а их результат попадает в интерфейс через интенсивности узлов FTA и раздел FMEA в PSSA.

Интерфейсы и ICD

Системные интерфейсы фиксируют связи между элементами (аппаратура ↔ ПО, система ↔ система): тип (данные / сигнал / питание / управление), исходную и целевую спецификации, протокол и детали ICD (Interface Control Document) — шина, формат данных, частота. Изменение интерфейса помечает связанные трассировочные связи подозрительными, чтобы зависимые требования прошли ре-валидацию.

Межуровневая трассируемость: Система ⇄ ПО

Страница трассируемости проекта имеет четыре вкладки: «Матрица» (функции × спецификации с IDAL), «Покрытие», «Пробелы» и «Система ⇄ ПО». Вкладка «Система ⇄ ПО» — это межуровневая матрица требований к системе × требований высокого уровня к ПО (HLR), и она реализует КТ-178С §5.5 (а) — двустороннюю трассируемость между требованиями к системе, отнесёнными к ПО, и требованиями высокого уровня. Вкладка «Покрытие» показывает четыре показателя (функции с распределением DAL, замечания с привязкой к требованиям, покрытие трассируемостью Система → ПО и покрытие верификацией по §6.4). Вкладка «Пробелы» перечисляет требования к системе без трассировки, HLR без вышестоящего требования, открытые замечания и подозрительные связи с указанием причины — связи, помеченные для ре-валидации после изменения связанного требования.

Пробелы и подозрительные связи

Вкладка «Пробелы» — рабочий список для закрытия системного контура: требования к системе без трассировки, орфанные HLR без вышестоящего требования к системе, неверифицированные требования, открытые и непривязанные замечания, подозрительные связи. Требования с признаком «производное» намеренно исключены из списка орфанных HLR — по КТ-178С §5.1.2 (b) / §5.2.2 у производного требования по определению нет вышестоящего требования, поэтому отсутствие трассировки вверх для него не пробел. Трассировочная связь или распределение DAL становятся подозрительными при изменении связанного требования или FDAL функции; после рассмотрения связь ре-валидируется, и пометка снимается.

8. Базовые линии

Базовые линии

Базовые линии фиксируют состояние требований на определённый момент времени. Процесс: Черновик → Ожидание утверждения → Утверждена (или Отклонена). Утверждённые базовые линии неизменяемы. Вы можете сравнить любую базовую линию с текущей версией.

Рабочие и базовые версии

Версии спецификации бывают рабочие и базовые. Рабочая версия — снимок состояния, которое уходит на формальную инспекцию; создаётся без ограничений и включает все объекты. Базовая версия — утверждённая конфигурация; её можно создать, только когда по каждому объекту спецификации принято решение по итогам инспекции, и в неё входят лишь утверждённые объекты. Номер присваивается автоматически: базовая версия поднимает старшую часть номера (2.0 → 3.0), рабочая — младшую (2.0 → 2.1). Номер базовой версии становится версией самой спецификации.

9. Формальные инспекции

Формальная инспекция

Формальные инспекции реализуют мероприятие «Рассмотрения и анализы» КТ-178С (§6.3) — формальную инспекцию выходных результатов. Инспекции живут на спецификации: вкладка «Формальные инспекции» (`/<space>/specifications/<specId>/reviews`). Свои инспекции видны на странице «Мои ФИ» (`/inspections`) — с разделами «Мои ФИ», «Адресованные мне замечания», «Замечания на мою проверку», «ФИ, готовые к закрытию» и «Аудит ФИ». У инспекции есть номер, сквозной в пределах пространства, — отображается как «ФИ-12»: в заголовке инспекции, в списке инспекций и на «Мои ФИ», а также в адресе (`/reviews/12`) вместо технического идентификатора. Старые ссылки с идентификатором продолжают работать. У каждого выставленного замечания тоже есть номер, сквозной в пределах инспекции, — отображается как «№12» в списке замечаний и на «Мои ФИ». Номер выдаётся в момент выставления замечания (перевода из черновика) и больше не меняется, поэтому на него можно ссылаться при обсуждении. Черновик номера не имеет.

Как отправить объекты на инспекцию

Основной режим — **весь документ целиком**: создание инспекции **фиксирует рабочую версию** спецификации (мастер показывает будущий номер, например 2.0 → 2.1), и инспекция ссылается на неё — инспектируемая редакция конфигурационно идентифицирована, версия видна на карточке ФИ. Объекты в «Черновике» переводятся в «Готово к инспекции» автоматически; до создания мастер показывает сводку: сколько объектов войдёт, сколько поднимется из «Черновика», что не вошло и почему. Если у спецификации есть базовые версии, последняя автоматически прикладывается во входные данные как контекст. **Ручной выбор объектов** («На инспекцию» из табличного вида или ручной режим в мастере) доступен, только пока у спецификации нет ни одной версии; после первой версии новые инспекции создаются только по версии, а выбранные строки можно добавить в уже открытую инспекцию. Завершение цикла: когда все объекты приняты, базовая версия создаётся существующей кнопкой. Инспектируются требования, разделы и обычный текст; допущения не инспектируются — у них своя дорожка валидации.

Участники и роли

Роли: **Инспектор**, **Ведущий ФИ**, **Автор**, **Наблюдатель**, **Инженер по безопасности**, **Аудитор**. Минимум один независимый инспектор — требование КТ-178С §6.3. Участники добавляются кнопкой «Добавить участника» из числа участников пространства: если нужного человека нет в выпадающем списке, сначала добавьте его в пространство (`/spaces/<slug>/members`). Кнопки участников и проверочных перечней видны всем, у кого есть право редактирования спецификации, а не только создателю инспекции; «Завершить инспекцию» требует более строгого права — Утверждение (APPROVE), либо доступно создателю инспекции.

Проверочные перечни

Перечень прикрепляется к инспекции кнопкой «Прикрепить перечень»: «Из шаблона» (шаблоны пространства, включая системные по КТ-178С) или «Свой перечень». Шаблоны пространства ведутся на странице «Шаблоны проверочных перечней» (`/spaces/<slug>/settings/checklist-templates`). Перечень можно импортировать из текста: каждый пункт с новой строки, начиная с «1.», «2.» …, подпункты — со знака «•». Замечания привязываются к конкретным вопросам перечня.

Входные данные и их версии

Входные данные — исходные материалы, на которые опирается инспекция: вышестоящие требования, план верификации, стандарт на разработку требований, файл из SVN/Git. Они заводятся, пока инспекция в статусе «Планирование», и показываются таблицей с постоянными колонками «Входное данное», «Версия», «Примечание», «Добавил»; пустая ячейка рисуется прочерком — незаполненная версия видна, а не пропадает с экрана. **Версия фиксируется в момент добавления** и дальше за источником не следует: у спецификации это номер выбранной базовой версии, у файла из SVN/Git — ревизия, у остальных источников — ручной ввод. Выбор базовой версии не обязателен: у спецификации может не быть ни одной. Обозначение, полученное из живой базовой версии, кликабельно и ведёт на неё (адрес — по номеру базовой версии); если базовую версию потом удалить, ссылка погаснет, а обозначение останется текстом — запись о том, что рассматривали, не теряется. Смысл колонки — конфигурационная идентификация рассматриваемого материала (КТ-178С §7.2.5 п. a).

Ход инспекции

Статусы инспекции: **Ожидание** → **В процессе** → **Завершена**; отдельно — **Отменена**. «Начать инспекцию» доступно, когда назначен Ведущий ФИ, указан автор, назначен хотя бы один Инспектор, есть хотя бы один элемент инспекции, прикреплён хотя бы один проверочный перечень и заполнено описание; сама кнопка есть у Ведущего ФИ (участника с этой ролью) и у обладателя права Утверждение на спецификацию. По каждому объекту выставляется вердикт: **Утверждено**, **Требует доработки** (вернуть автору на исправление, затем повторная инспекция — КТ-178С §7.2.3) или **Отклонено** (объект исключается целиком — §7.2.4). Замечания проходят путь Черновик → Адресовано → Исправлено → Закрыто (либо Отменено, либо Создано СП). Формальная инспекция проводится в рамках запроса на изменение — без выбранного ЗИ создать инспекцию нельзя (ЗИ, синхронизированный из Redmine, выбирается так же, как заведённый вручную).

Возврат инспекции в планирование

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

Ответы чек-листа и отклонённый ЗИ

На вопрос чек-листа отвечают **Да**, **Нет** или **Не применимо**. Ответ **«Нет» ставит система**: как только по вопросу заведено замечание, ответ становится «Нет» — и **остаётся «Нет» после исправления замечания**, потому что фиксирует факт обнаруженного несоответствия, а не текущее состояние объекта (иначе исправленные замечания исчезают из картины, и по чек-листу выходит, что нарушений не было). Поэтому кнопка «Нет» сразу открывает форму замечания. **«Не применимо»** ставится вручную и требует комментария — почему вопрос неприменим. Участник может исправить ошибочный ответ, в том числе снять системное «Нет»; каждая смена ответа попадает в журнал изменений. Если связанный **запрос на изменение отклонён**, инспекция **не прекращается автоматически**: в ней показывается предупреждение, а решение о судьбе инспекции принимает ведущий — досрочное прекращение остаётся ручным действием с обязательной причиной.

Список элементов и форма замечания

В списке элементов инспекции разделы отображаются заголовками — тем же стилем и с тем же уровнем, что и в спецификации, — поэтому инспектор видит структуру документа, а не сплошную ленту одинакового текста. Если родительский раздел не включён в инспекцию, цепочку предков восстановить не из чего — такой раздел показывается заголовком первого уровня. В форме замечания блок «Требования» свёрнут по умолчанию: в его заголовке видны счётчик выбранных объектов и их коды (при пустом выборе — «не выбрано»); блок раскрывается по клику, а список внутри ограничен по высоте со своей прокруткой, поэтому форма не растягивается даже на инспекциях с сотнями элементов. Предвыбранные требования (когда замечание создаётся из конкретного элемента инспекции) сохраняются и видны прямо в свёрнутом заголовке. Блок «Вопросы чек-листа» имеет такой же заголовок со счётчиком, но остаётся развёрнутым — привязка замечания к вопросу чек-листа обязательна для его адресации.

Что заблокировано, пока объект «На инспекции»

Пока объект находится в статусе «На инспекции», инспектируется его зафиксированное состояние (КТ-178С §7.2.4), поэтому менять объект нельзя — ни поодиночке, ни массовыми операциями, и исключений нет ни для владельца, ни для администратора пространства. Заблокированы: редактирование полей, удаление, перемещение в другой раздел, а также перестановка, если она меняет номер объекта на инспекции (перестановка соседей, не задевающая его номер, разрешена). Смена статуса запрещена, кроме возврата в «Черновик» — вернуть объект на доработку можно всегда. Сохранение Markdown-вида отказывает целиком, если правка задевает инспектируемые объекты, и называет их поимённо; правка, не затрагивающая объекты на инспекции, сохраняется как обычно. Заморожены и исходящие связи трассировки такого объекта: их нельзя создавать, менять и удалять (исходящей считается связь, где объект стоит потомком, `from`). Входящие связи разрешены — их владелец другой объект, и инспектируемый при их создании не меняется. Пометка связи подозрительной и снятие подозрения не блокируются: это служебная отметка недоверия, а не изменение трассировки. В интерфейсе запрещённые действия недоступны заранее с подсказкой-причиной («На инспекции — верните в Черновик для правки»), а не падают ошибкой после клика.

Как править объект по замечанию: вернуть его в «Черновик»

Ждать, пока все инспекторы закончат проверку, и переводить в «Черновик» всю спецификацию не нужно. Отдельный объект выводится из инспекции сам по себе: во вкладке «Элементы» инспекции у объекта в статусе «На инспекции» есть действие **«Вернуть в Черновик»**. Оно доступно всем, у кого есть право на редактирование спецификации; там, где права нет, кнопка не прячется, а показывается отключённой с причиной. После возврата объект выходит из инспекции, правится как обычно и затем возвращается на инспекцию, а остальные объекты инспекции всё это время остаются «На инспекции». Ничего не теряется: замечания по объекту, его вердикт и сама инспекция сохраняются, а уже возвращённый объект помечается в списке как «Правится по замечанию» — видно, что он правится. Панель свойств рядом со списком намеренно остаётся только для чтения: объект на инспекции правится через этот возврат, а не редактированием панели. Чтобы попасть к самому замечанию, открывайте его со страницы «Мои ФИ»: клик по строке в разделах «Замечания мне» и «Замечания на мою проверку» открывает инспекцию сразу на вкладке «Замечания» с подсветкой нужного замечания.

Правка объекта по замечанию: что происходит с вердиктом

Вердикт (Утверждено / Требует доработки / Отклонено) привязан к той редакции объекта, на которой он вынесен. В момент, когда объект возвращается в «Черновик» для правки по замечанию, вердикты во всех инспекциях, где он состоит, аннулируются — элемент возвращается в «Ожидание», а факт аннулирования остаётся записью в истории элемента, а не пропадает бесследно. Как только объект поправлен и возвращается обратно — автоматически, как только все замечания к нему в этой инспекции доходят до статуса «Исправлено», или вручную кнопкой «Вернуть на инспекцию» рядом с бейджем «Правится по замечанию», — объект снова «На инспекции», и по нему нужен новый вердикт. По той же причине «Завершить инспекцию» может отказать: если хоть один вердикт в списке относится к устаревшей редакции, завершение блокируется, а затронутые объекты называются поимённо — вместо того чтобы проставить финальный статус по вердикту, который уже не соответствует тексту.

Редакции объекта и блок сравнения на вкладке «Элементы»

Под каждым объектом на вкладке «Элементы» стоит строка редакций — четыре разных понятия процедуры, каждое подписано полными словами. **«Начальная версия»** — редакция, взятая на инспекцию при включении объекта в неё; **«Текущая версия»** — редакция, которая лежит в спецификации прямо сейчас; **«Принятая версия»** — редакция, к которой относится текущий вердикт инспектора; **«Результирующая версия»** — редакция, зафиксированная как итог инспекции, она показывается только у завершённой инспекции. Пустое значение объясняется словами, а не прочерком: «не зафиксирована» или «вердикт не вынесен». Если текущая и принятая редакции разошлись, обе подсвечиваются, а рядом появляется пометка «объект изменился после вердикта» — пока это так, инспекцию завершить нельзя, вердикт нужно вынести заново. Клик по строке редакций разворачивает блок сравнения: заголовок называет базу сравнения — «Что изменилось с момента замечания», если по объекту есть открытое замечание, иначе «Что изменилось с начала инспекции», — ссылку на страницу полного сравнения редакций (у завершённой инспекции есть ещё и «Сравнить начальную и результирующую») и хронологию замечаний объекта (статус · редакция · автор, открытые замечания выше закрытых). Объект без сохранённой базы (заведён до этой возможности, замечаний нет) вместо сравнения показывает честную заглушку «Редакция на момент замечания не сохранена».

Завершение: две отметки подтверждения

Две отметки, которые легко перепутать. **«Готово к инспекции» внутри инспекции** — отметка автора: «я заполнил инспекцию со своей стороны», сигнал Ведущему ФИ; инспекцию она **не запускает**. (Та же формулировка есть и как статус требования — это другое.) Вторая — отметка участника о том, что он закончил свою часть инспекции, и она **блокирует завершение**: пока её не поставили все учитываемые участники, «Завершить инспекцию» отказывает. Отметка положена участнику с любой ролью, кроме Наблюдателя, и подписывается по роли — тем, что человек на самом деле удостоверяет. Инспектор, Инженер по безопасности и Аудитор нажимают **«Подтвердить завершение экспертизы»** и получают бейдж «Экспертиза завершена»; Автор — **«Подтвердить завершение доработок»** («Доработки завершены»); Ведущий ФИ — **«Подтвердить приёмку инспекции»** («Инспекция принята»). Автор объекта относительно него не независим (КТ-178С, глоссарий: независимость), поэтому его отметка — не экспертиза; если человек совмещает роли, отметка подписывается наименее независимой из них: у Автора, который заодно Инспектор, это завершение доработок. Ставится и снимается отметка («Снять отметку») только пока инспекция «В процессе». О простановке уведомляется Ведущий ФИ, а и простановка, и снятие записываются в журнал изменений инспекции (КТ-178С §7.2.4 п. e, §7.2.6 п. a). «Досрочно прекратить» переводит инспекцию в «Отменена»: открытые замечания отменяются, а объекты возвращаются из «На инспекции» в «Черновик».

Инспекция не завершается: что делать

«Завершить инспекцию» проверяет условия ниже именно в таком порядке, и в отказе названо то, которое не выполнено. **Статус** — завершить можно инспекцию в «Планировании» или «В процессе». **Право** — завершает создатель инспекции либо обладатель права Утверждение (APPROVE) на спецификацию; кнопкам участников и перечней хватает права редактирования. **Незакрытые замечания** — ни одно замечание не должно остаться в статусе Черновик, Адресовано или Исправлено; доведите каждое до Закрыто, Отменено или Создано СП (последние два терминальные и завершению не мешают). **Объекты без итогового вердикта** — ни один элемент не должен остаться в статусе Ожидание или Требует доработки; вынесите по каждому вердикт. **Отметки участников** — в сообщении люди сгруппированы по тому, чего от них ждут: «Ожидается: завершение экспертизы — Анна, Борис; завершение доработок — Виктор; приёмка инспекции — Ведущий»; попросите поставить отметку именно названных (и поставьте свою, если вы в списке). **Разошедшиеся редакции** — если объект изменили после вынесения вердикта или он вышел из инспекции, завершение отказывает и объекты называются поимённо (первые — кодами, остальные счётчиком); на вкладке «Элементы» у них стоит пометка «объект изменился после вердикта», а лечится это повторным вынесением вердикта. Учтите: раздел «ФИ, готовые к закрытию» на странице «Мои ФИ» собирается только по замечаниям и вердиктам, поэтому инспекция может быть в нём и всё равно не завершиться — из-за отметок или редакций.

Почему с меня сняли отметку

Отметка не устаревает и никогда не зачёркивается: она либо стоит, либо снята. Снимают её три события по замечаниям, и всегда адресно, у конкретных людей. Замечание **выставлено исполнителю** (переведено из черновика в «Адресовано») — снимается отметка **исполнителя** этого замечания. Замечание **возвращено на доработку** инспектором — снова снимается отметка **исполнителя**. Исполнитель отметил замечание **«Исправлено»** — снимаются отметки **инспекторов этого замечания**: им предстоит проверить исправление. Больше отметок не трогает ничто: ни приём исправления, ни отмена замечания, ни перевод в «Создано СП», ни создание черновика замечания, ни правка объекта, ни добавление объекта в инспекцию и удаление из неё. Расхождение материала ловится не отметкой, а пообъектно — строкой редакций на вкладке «Элементы». Каждое снятие записывается в журнал изменений инспекции вместе с событием и замечанием, которое его вызвало. Что делать: закончив свою часть заново, поставьте отметку снова — прежняя не «просрочена», её просто нет.

Где кнопка «Одобрить» и три разных утверждения

Кнопки **«Одобрить» в формальной инспекции нет вообще** — эта формулировка относится к двум соседним местам: к утверждению базовой версии и к утверждению запроса на изменение (ЗИ). Внутри инспекции используется слово «Утвердить» / «Утверждено», и стоят за ним три разные вещи, которые легко перепутать. **Первое — ваш собственный ответ как участника.** На вкладке «Участники» у вашей строки есть кнопка «Ваш ответ», открывающая выбор «Утвердить» / «Отклонить» / «Воздержаться» с необязательным комментарием (и с электронной подписью, если ввести пароль). Она предлагается только вам, только пока ваш ответ в состоянии «Ожидание» и инспекция уже начата. Она фиксирует ваш статус участника и уведомляет создателя инспекции — и всё: инспекцию она не запускает, вердикт ни по чему не выносит и завершение не блокирует. Завершение блокирует другая отметка — «Подтвердить завершение экспертизы» / «…доработок» / «…приёмку инспекции», о ней сказано выше. **Второе — вердикт по объекту.** На вкладке «Элементы» у каждого объекта есть переключатель вердикта, где «Утверждено» — одно из положений наряду с «Требует доработки» и «Отклонено». Он положен участнику с ролью Инспектор или Ведущий ФИ и работает, пока инспекция «В процессе». Утвердить объект нельзя, пока у него есть открытые замечания («Нельзя одобрить требование с открытыми замечаниями») и пока объект выведен на правку. Вердикт запоминает редакцию объекта, на которой он вынесен, — поэтому последующая правка объекта вердикт обесценивает. Учтите: сам по себе вердикт статус требования сразу не меняет — статусы проставляются по вердиктам, когда завершается вся инспекция. **Третье — завершение инспекции**: кнопка «Завершить инспекцию» в заголовке, и вот она и есть утверждение результата — именно она переводит объекты в «Утверждено» / «Отклонено» и закрывает инспекцию.

Действие «Вернуть» у замечания

«Вернуть» — это ответ инспектора на исправление, которое он не принимает. Пункт появляется у замечания, которое исполнитель отметил как «Исправлено», и переводит замечание обратно в «Адресовано»: исправление не принято, работа по замечанию начинается заново. Условий три: инспекция «В процессе», замечание в статусе «Исправлено», и вы — инспектор **именно этого замечания** (список инспекторов задаётся у самого замечания; автор замечания добавляется в его инспекторы при создании, поэтому вернуть он может, пока его из инспекторов не убрали). Причина обязательна — поле «Причина возврата» должно быть заполнено, иначе возврат отклоняется; исполнитель получит эту причину в уведомлении. Возврат заодно сбрасывает уже поставленные приёмки других инспекторов этого замечания и снимает зафиксированные редакции, в которых исправление считалось сделанным, — следующий круг оценивается заново. Номер у замечания сохраняется: номер выдаётся один раз, при первом выставлении замечания, и возврат нового не выдаёт. Ещё возврат снимает отметку о завершении у исполнителя (см. «Почему с меня сняли отметку»). Не путайте «Вернуть» с соседними действиями: «Принять» — противоположный ответ, он закрывает замечание, но только когда приняли все его инспекторы; «Отменить» снимает само замечание как необоснованное (автор или Ведущий ФИ, с обязательной причиной); «Создать СП» выводит замечание из инспекции в сообщение о проблеме (только Ведущий ФИ).

Как найти требование внутри инспекции

**Счётчики над списком и есть фильтр.** «Всего элементов», «Утверждено», «Отклонено», «Требует доработки», «Ожидание» стали кнопками: щелчок по счётчику вердикта оставляет на вкладке «Элементы» только объекты с этим вердиктом, повторный щелчок по активному счётчику снимает отбор, а «Всего элементов» всегда возвращает весь список. Пока фильтр включён, над списком идёт строка о том, какой вердикт показан и сколько объектов из скольких осталось, рядом с ней кнопка «Сбросить фильтр»; сами счётчики при этом продолжают показывать полные числа по всей инспекции. Счётчики доступны с клавиатуры как обычные кнопки. **Поля поиска по объектам на странице по-прежнему нет.** Список остаётся плоским, в порядке добавления объектов, поэтому вместе с фильтром в вашем распоряжении: Ctrl+F браузера по открытой вкладке, раскрытие строки «галочкой»-шевроном, чтобы прочитать объект, и ссылки в строке «Перейти к требованию» и «Показать свойства требования». Для полнотекстового поиска идите в саму спецификацию, где эти инструменты есть: поле «Поиск по коду или названию...» над таблицей, панель фильтров и Ctrl+G для перехода к объекту по коду. У замечаний, в отличие от объектов, адресация есть: уведомление или ссылка с `?remark=` открывает инспекцию на нужном замечании и прокручивает к нему.

Работа с замечаниями, пока не все инспекторы ответили

Да, автор может работать с замечаниями, никого не дожидаясь. **Ответ участника («Ваш ответ» — Утвердить / Отклонить / Воздержаться) не блокирует ничего**: он не проверяется ни при старте инспекции, ни при создании и переводе замечаний, ни при вынесении вердикта, ни при завершении инспекции. Единственный гейт для работы с замечаниями — статус самой инспекции: замечания создаются и переводятся, только пока она «В процессе», и только участником инспекции. Ограничено другое: **текст замечания правит только его автор и только пока замечание в статусе «Черновик»**. После выставления формулировка заморожена для всех, включая Ведущего ФИ, — именно это делает замечание записью, а не подвижной целью. Дальше обсуждение идёт в комментариях к замечанию, а всякая смена курса выражается действием с причиной: «Вернуть» с «Причиной возврата», «Отменить» с причиной. Автор инспекции, который по умолчанию является исполнителем всех замечаний, отвечает на замечание действием «Исправлено» — оно доступно только исполнителю и только из статуса «Адресовано». Итого порядок такой: замечание пишется черновиком, выставляется исполнителю, автор правит объект и отмечает «Исправлено», инспекторы замечания принимают исправление или возвращают его — и ни один из этих шагов не ждёт ответов об участии.

10. Импорт и экспорт

Обмен данными

Форматы экспорта: CSV, XLSX, ReqIF (с трассировочными связями), DOCX, HTML, Markdown, PDF (Список требований или Матрица трассируемости). Форматы импорта: Word (.docx), Markdown, XMI, перенос проекта целиком, а также CSV (с мастером сопоставления колонок) и ReqIF (с сохранением структуры и связей).

Загрузка документа Word (.docx): с чего начать

Загрузка из Word встроена в систему, писать скрипт-конвертер не нужно. Загрузить документ может любой участник пространства с правом на правку документов, отдельных прав для этого не требуется. На странице спецификации (и в обычном, и в табличном виде) нажмите «Импорт из Word»: откроется страница загрузки с уже выбранным форматом .docx и подставленной целевой спецификацией. Та же страница доступна из бокового меню по пункту «Импорт» (`/<space>/import`), вкладка Word стоит первой и выбрана по умолчанию. Порядок действий: выбрать файл .docx, выбрать шаблон разбора, выбрать целевую спецификацию, если вы обновляете уже загруженный документ, нажать «Предварительный просмотр» и посмотреть, что получится, и только затем нажать «Импорт». Загрузка сохраняет структуру разделов, таблицы, изображения (в том числе EMF и WMF, они преобразуются в SVG), формулы и подписи к рисункам, включая подписи, набранные надписью Word.

Выбор шаблона разбора

Шаблон определяет, что станет отдельным объектом в СУТР. Это главное решение при загрузке: от него зависят и вид документа, и объём будущей формальной инспекции по нему. Шаблоны названы по тому, что получится. «Каждый абзац отдельным объектом»: заголовки становятся разделами, каждый абзац и каждый пункт перечня становятся отдельным объектом вида «обычный текст». Подходит документам, где связи трассируемости ведут на отдельный абзац; объектов выходит больше всего, на сотню страниц несколько сотен. «Тело раздела одним объектом»: та же структура, но все абзацы и перечни раздела складываются в один объект «обычный текст», таблицы и рисунки остаются отдельными объектами. Подходит документам, где связи трассируемости ведут на раздел целиком; объектов выходит в разы меньше, на сотню страниц около двух сотен. «Требования из карточек»: каждая таблица-карточка требования превращается в требование с заполненными полями (код, текст, обоснование, родительское требование, признак безопасности), остальной текст раздела складывается в один объект. Подходит техническим заданиям и документам требований к программному обеспечению, где требования оформлены карточками. «Описание проекта ПО (БУТС), §6 ТНУ»: разбор описания проекта программного обеспечения, разделы, требования нижнего уровня из §6, связи трассируемости, диаграммы. Подходит только документам этой структуры. Под выбранным шаблоном в мастере показано его описание, прочитайте его перед загрузкой. Если не уверены, какой шаблон подходит, прогоните документ предварительным просмотром по очереди с каждым и сравните, сколько объектов получается.

Предварительный просмотр: безопасный первый шаг

Предварительный просмотр ничего не записывает, пользуйтесь им столько раз, сколько нужно. Он показывает сводку по числу объектов: сколько будет создано, сколько обновлено, сколько удалено, отдельно по требованиям, связям трассируемости и другим сущностям. На что смотреть в сводке. Если «создано» много, а документ обновляется, скорее всего выбран неподходящий шаблон или неверная целевая спецификация: объекты не сопоставились со старыми и лягут рядом. Если «удалено» много, проверьте, что загружаете документ целиком. Если «обновлено» примерно совпадает с числом объектов в документе, так выглядит нормальное обновление.

Повторная загрузка того же документа

Если в поле «Целевая спецификация» выбрать уже существующий документ, СУТР обновит его, второй документ рядом при этом не появится. Объекты сопоставляются по внутренним идентификаторам, унаследованным из структуры исходного файла, поэтому существующие объекты сохраняются вместе со своей историей. Связи трассируемости сохраняются, проставлять их заново не нужно. Объекты, которых больше нет в новом файле, удаляются, новые абзацы добавляются. Отдельного режима «очистить документ перед загрузкой» в мастере нет: повторная загрузка всегда работает обновлением.

Если разбор получился не таким

Напишите нам, приложив файл и указав, что вы ожидали увидеть. Разбор настраивается: например, по просьбе заказчика перечни из Word стали собираться в один объект вместо отдельного объекта на каждый пункт. Загруженный документ можно загрузить повторно с другим шаблоном, поэтому неудачная попытка ничего не ломает безвозвратно.

Частые вопросы о загрузке Word

Рисунки и таблицы попадут в СУТР? Да. Рисунки переносятся вместе с подписями, таблицы становятся таблицами внутри объектов. Что будет с нумерацией разделов? СУТР показывает фактические номера из Word, заново они не пересчитываются. Можно ли загрузить документ, по которому идёт формальная инспекция? Лучше дождаться её завершения: загрузка перезапишет объекты, включённые в инспекцию, и инспектор увидит уже другой текст. Какой размер файла допустим? До 64 мегабайт, документ в несколько мегабайт с рисунками загружается штатно.

Где какой формат импорта

На уровне пространства, страница «Импорт» (`/<space>/import`): Word (.docx), Markdown, XMI и перенос проекта целиком (JSON, описан в руководстве администратора). На уровне спецификации, мастер «Импорт» на странице спецификации: CSV с мастером сопоставления колонок и ReqIF с сохранением структуры и связей.

11. Управление изменениями (КТ-178С)

Панель управления

Управление изменениями реализует процесс SCM по КТ-178С. Панель показывает сводную статистику по запросам на изменение (ЗИ) и сообщениям о проблемах (СП).

Запросы на изменение

Запрос на изменение документирует предлагаемую модификацию. Процесс: Черновик → Подан → На рассмотрении → Утверждён → В работе → Проверен → Закрыт (или Отклонён). Поля: Код, Название, Тип, Приоритет, Статус, Инициатор.

Сообщения о проблемах

Сообщение о проблеме документирует дефект или аномалию. Процесс: Открыт → Подтверждён → Анализ → Исправление → Решён → Проверен → Закрыт (или Отложен). Уровни серьёзности по КТ-178С: Катастрофический, Опасный, Существенный, Незначительный, Без эффекта.

12. Сертификация (КТ-178С)

Панель сертификации

Модуль сертификации управляет артефактами, необходимыми для сертификации по КТ-178С, предоставляя обзор конфигурационных единиц, библиотек, релизов и подписей.

Конфигурационные единицы

Конфигурационные единицы (КЕ) — артефакты под управлением конфигурацией. Атрибуты: Номер КЕ, Название, Тип, Версия, Статус и Категория контроля (CC1 для DAL A-C, CC2 для DAL D-E).

Релизы

Релизы отслеживают формальные сборки ПО, привязанные к базовым линиям требований. Процесс: Черновик → Ожидание авторизации → Авторизован → Выпущен → Архивирован. Каждый релиз связан с базовой линией.

Электронные подписи

Электронные подписи обеспечивают утверждения в соответствии с КТ-178С. Каждая подпись содержит: тип, значение, подписываемый объект, временную метку и статус действительности и хранится в неизменяемом журнале. Вместе с базовыми версиями, запросами на изменение (ЗИ) и сообщениями о проблемах (СП) подписи дают проверяемую запись о том, кто и когда что утвердил, — свидетельства управления конфигурацией, ожидаемые по §7 и Таблице А-8 Приложения A.

13. Документы жизненного цикла (КТ-178С)

Список документов

КТ-178С требует документы жизненного цикла: PSAC, SDP, SVP, SCMP, SQAP, SReqS, SDS, SCS, SCI, SECI, SAS, HDD, SVD. Нажмите «Инициализировать шаблоны» для автоматического создания всех документов. Панель показывает количество документов, средства разработки и процент готовности к сертификации.

Детали документа

Каждый документ жизненного цикла содержит структурированные разделы на основе требований КТ-178С. Редактируйте разделы непосредственно в редакторе. Каждый документ показывает прогресс-бар полноты.

Средства разработки (SECI)

Страница средств разработки реализует SECI по КТ-178С. Все средства разработки и верификации должны быть идентифицированы, а те, чей выход является частью бортового ПО, должны быть квалифицированы. Атрибуты: Название, Версия, Поставщик, Назначение и Статус квалификации.

14. Интеграции (MCP, СКВ)

Интеграция с LLM через MCP

СУТР Навигатор включает встроенный MCP-сервер (Model Context Protocol) — де-факто стандарт подключения больших языковых моделей к корпоративным данным — с примерно двадцатью инструментами. Ассистент может искать требования, выявлять возможные противоречия и дубликаты, оценивать влияние изменения и готовить черновик отчёта об изменениях, работая в рамках той же модели прав, что и пользователь. Граница полномочий явная: ассистент только читает и предлагает — он не верифицирует, не утверждает и не подписывает артефакты; эти решения остаются за инженером. Для такого режима «чтение и подсказка» квалификация инструмента не требуется; квалификация по Р-330 нужна лишь тогда, когда инструмент автоматизирует мероприятие ЖЦ и его выход принимается в зачёт без верификации (КТ-178С §12.2).

Интеграция с СКВ (SVN / Git / Redmine)

СУТР Навигатор поддерживает как SVN, так и Git-репозитории (Gitea, GitHub, GitHub Enterprise, GitLab), а также трекеры задач (Redmine). Процесс одинаков для обоих типов СКВ: коммиты, в сообщении которых упоминается код Заявки на Изменение (ЗИ), привязываются к этой ЗИ и отображаются на вкладке «Коммиты» карточки ЗИ. Доступны полный текст commit message, список изменённых файлов и unified diff. Если коммит затрагивает файл, на который ссылается ссылка на исходный код, привязанная к требованию, эта ссылка автоматически помечается подозрительной — сигнализируя, что требование может быть затронуто изменением и требует ре-валидации. Требования таким образом трассируются на коммиты, тесты, запросы на изменение и сообщения о проблемах, которые их реализуют или верифицируют. Страница «Средства разработки» (SECI) регистрирует задействованные инструменты со статусом квалификации. Это сохраняет связь набора требований с кодом и тестами без дублирования этих артефактов внутри СУТР Навигатор.

15. Настройки

Настройки

Пользовательские настройки (`/settings`) разделены на секции: **Профиль** (`/settings` — имя, email, аватар, язык), **Безопасность** (`/settings/account` — изменение пароля), **Уведомления** (`/settings/notifications`), **Внешний вид** (`/settings/appearance` — тема), **API-токены** (`/settings/api-tokens` — токены для REST API и MCP) и **Интеграции** (`/settings/integrations`) — именно там подключается своя LLM через MCP, и это путь для всего, что меняет данные. Администраторам ассистента «Вася» дополнительно виден пункт **Ассистент «Вася»** (`/settings/assistant`); остальным он не показывается. Настройки уровня пространства — отдельные, они живут по адресу `/spaces/<slug>/settings`.

16. Руководство по процессу КТ-178С

Фаза 1: Планирование

Создайте пространство для проекта. Инициализируйте документы ЖЦ (PSAC, SDP, SVP, SCMP, SQAP и др.). Зарегистрируйте средства разработки со статусом квалификации. Заполните планы содержанием проекта.

Фаза 2: Разработка требований

Создайте спецификации (SRS, HLR, LLR, IRS). Напишите требования с уровнем DAL, флагом безопасности и методом верификации. Установите трассировочные связи между спецификациями. Отметьте производные требования с обоснованием.

Фаза 3: Формальная инспекция требований

Переведите требования в статус «На инспекции». Создайте формальную инспекцию, назначьте инспекторов (минимум один независимый по КТ-178С). Используйте проверочные перечни. Устраните замечания и утвердите требования.

Фаза 4: Установление базовых линий

После утверждения требований создайте базовую линию с версией и названием этапа. Подайте на утверждение. Утверждённые базовые линии неизменяемы и служат официальной записью конфигурации.

Фаза 5: Контроль изменений

Создайте запросы на изменение для изменений после базовой линии. Проведите анализ воздействия. После утверждения ЗИ реализуйте изменения. Проверьте Матрицу трассируемости на подозрительные связи. Создайте сообщения о проблемах для дефектов.

Фаза 6: Верификация

Используйте Анализ покрытия для проверки верификационных связей. Экспортируйте Матрицу трассируемости в PDF для сертификационных доказательств. Экспортируйте требования в ReqIF для обмена с другими инструментами.

Фаза 7: Сертификация

Убедитесь, что все документы ЖЦ утверждены или выпущены. Создайте конфигурационные единицы для всех артефактов. Создайте релиз, привязанный к базовой линии. Подпишите релиз электронными подписями. Экспортируйте Итоговый отчёт по ПО (SAS). Проверьте процент готовности к сертификации.

Карта соответствия целям (Приложение A)

Эта карта связывает возможности СУТР Навигатор с таблицами целей КТ-178С (Приложение A), а на системном уровне — с Р-4754А / Р-4761. СУТР Навигатор хранит свидетельства и связи, поддерживающие эти цели; сам по себе он их не закрывает — мероприятия ЖЦ (формальные инспекции, испытания, анализы) остаются зоной ответственности проекта.

Возможность СУТР Навигатор	Цель — таблица / раздел	Статус
Планы ЖЦ (PSAC, SDP, SVP, SCMP, SQAP) и журнал	Таблица А-1 (планирование); §11.1–11.5	Есть
Требования (HLR/LLR), производные требования, трассируемость на требования к системе	Таблица А-2 (разработка); §5.1, §5.2, §5.5	Есть
Формальные инспекции требований, статусы, трассируемость §5.5	Таблицы А-3 / А-4 (верификация требований и проектирования); §6.3	Есть
Связи требований с тестами и покрытие трассируемостью; нативное управление тестами	Таблицы А-6 / А-7 (тестирование, покрытие); §6.4	Есть — тест-кейсы, импорт прогонов (JSON / JUnit XML), верификационная матрица. Прогон тестов выполняется вне системы, структурное покрытие импортируется, а не вычисляется. Тест-кейсы ведутся через API / MCP, отдельного экрана нет
Базовые версии, версии требований, запросы на изменение, сообщения о проблемах	Таблица А-8 (управление конфигурацией); §7.2.2–7.2.4	Есть
Проверочные перечни формальных инспекций, независимость инспектора	Таблица А-9 (гарантия качества); §8	Есть
Документы ЖЦ, итоговое заключение (SAS), электронные подписи	Таблица А-10 (взаимодействие при сертификации); §11	Есть
Функции системы, FHA, распределение FDAL→IDAL, оценки безопасности	Р-4754А, Р-4761 (системный уровень)	Есть