Импорт требований из Word (.docx)

Импорт из Word применяют, когда документ уже написан: ТЗ по ГОСТ, документ с требованиями к системе или аппаратуре, описание проекта ПО, — и его разделы и требования нужно перенести в СУТР Навигатор без ручного ввода. Импорт читает .docx напрямую: конвертер и промежуточный JSON не нужны. Что получается: заголовки становятся разделами с сохранением иерархии, текст и таблицы под заголовком попадают в содержимое раздела, а с шаблоном карточек каждая таблица-карточка становится объектом-требованием с заполненными полями. Импорт повторяемый. Объекты ключуются идентификатором из документа, поэтому загрузка исправленной версии того же файла обновляет уже созданные объекты, а не плодит дубликаты.

Мастер спрашивает шаблон: набор правил, по которым структура документа раскладывается на объекты СУТР. Шаблоны названы по результату, доступны четыре: • «Каждый абзац отдельным объектом» (gost-tz-text). Заголовки становятся разделами, каждый абзац и каждый пункт перечня отдельным объектом «обычный текст» с сохранением вложенности перечней, таблицы и рисунки тоже отдельными объектами. Требования не размечаются. Объектов выходит больше всего, порядка числа абзацев: на сотню страниц несколько сотен. Подходит документам, где связи трассируемости ведут на отдельный абзац. • «Тело раздела одним объектом» (gost-tz-merged). Та же структура, но все абзацы и перечни раздела складываются в ОДИН объект «обычный текст», а таблицы и рисунки остаются отдельными объектами. Объектов выходит в разы меньше, порядка числа разделов, таблиц и рисунков: на сотню страниц около двух сотен. Подходит документам, где связи трассируемости ведут на раздел целиком. • «Требования из карточек» (gost-tz-cards). Каждая таблица-карточка становится требованием с заполненными полями и атрибутами, остальной текст раздела складывается в один объект «обычный текст». Это шаблон для документа с требованиями. • «Описание проекта ПО (БУТС), §6 ТНУ» (buts-sdd). Узкий шаблон под структуру описания проекта, где в §6 «Требования низкого уровня» лежат таблицы LLR_…. Заодно переименованы два идентификатора: `gost-tz` стал `gost-tz-text`, `gosniias-sdd` стал `buts-sdd` (ГосНИИАС это отдельная организация, шаблон назван по изделию БУТС). Загрузка со старым идентификатором продолжает работать: он приводится к действующему шаблону. Всем шаблонам, кроме buts-sdd, нужно указать в мастере целевую спецификацию: импорт выполняется в неё.

Заголовки разделов оформляйте штатными стилями Word («Заголовок 1…4»). Вложенность берётся из уровня заголовка, поэтому документ, где нумерация набрана руками в обычных абзацах, импортируется одним плоским разделом. Всё, что стоит между двумя заголовками, относится к предыдущему разделу: абзацы, перечни, таблицы, изображения. Текст до первого заголовка (титульный лист, оглавление) пропускается, и это отражается в отчёте об импорте. Так и задумано.

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

Полями считаются ровно эти метки (регистр не важен, всегда в виде «Метка: значение»): • Обоснование → обоснование требования • Родительское требование → связь на вышестоящее требование. Значение «Производное» помечает требование производным (это флаг, а не связь: у производного требования вышестоящего звена нет по определению); плейсхолдер вида «—» или «назначается в СУТР» оставляет родителя незаполненным • Безопасность → «Да» / «Нет» выставляют признак требования безопасности; «N/A» и прочие значения игнорируются • Номер ЗИ → поле с номером запроса на изменение • Назначение, Компонент, Статус валидации, Комментарии → пользовательские атрибуты требования, схема атрибутов спецификации пополняется автоматически • Комментарий (в единственном числе) → добавляется абзацем в конец текста требования Любая другая строка вида «Метка: значение» полем не считается: её текст уходит в тело требования. В одном ряду может стоять две пары «метка — значение», как в примере выше.

Перечни должны быть настоящими списками Word (нумерация, а не набранные руками маркеры): импорт читает уровень вложенности и восстанавливает подпункты под их пунктом. Сохраняются и нумерованные, и маркированные перечни, в том числе буквенная нумерация вида «а)». Подпись «Таблица N …» или «Рисунок N …», стоящая рядом со своей таблицей или картинкой, привязывается к ней, а не превращается в отдельный абзац. Формулы, набранные редактором формул Word, переводятся в LaTeX и отображаются в СУТР формулами. Картинки в формате EMF (обычно диаграммы Enterprise Architect) конвертируются в SVG во время импорта.

1. Откройте пространство и выберите «Импорт» в левом меню (либо «Импорт из Word» на странице спецификации; откроется тот же мастер с уже выбранной спецификацией). 2. Останьтесь на вкладке «Word (.docx)» и приложите файл. 3. Выберите шаблон разбора. 4. Выберите целевую спецификацию. Для всех шаблонов, кроме «Описание проекта ПО (БУТС), §6 ТНУ», это обязательно. 5. Нажмите «Предварительный просмотр»: документ разбирается и подсчитывается без записи и без конвертации изображений. Он ничего не меняет, поэтому повторять его можно сколько угодно раз. 6. Сверьте числа и предупреждения и нажмите «Импортировать». Импорт выполняется фоновой задачей: конвертируются диаграммы и создаются объекты, страница показывает ход выполнения, а затем отчёт.

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

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

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

• Выбран шаблон «Каждый абзац отдельным объектом» или «Тело раздела одним объектом». Оба по устройству не размечают требования. Переключитесь на «Требования из карточек». • Идентификатор не похож на код: строчные буквы, пробелы, точки или дефисы, либо короче 5 символов. • Меньше двух рядов таблицы начинаются с известной метки поля: обычная таблица данных требованием не становится, именно это и удерживает глоссарии и таблицы меток ARINC вне списка требований. • Требование набрано обычными абзацами. Шаблон карточек распознаёт только таблицы.

Всё легло в один плоский раздел или отчёт полон строк «Параграф вне раздела пропущен»: заголовки документа оформлены не стилями заголовков. Примените к ним «Заголовок 1…4» и повторите предпросмотр. Несколько строк «Параграф вне раздела пропущен» в начале — это норма: титульный лист и оглавление.

Строка карточки вида «Метка: значение» становится пользовательским атрибутом, только если метка входит в список распознаваемых; иначе текст остаётся в теле требования. Если у известной встроенной метки значение не входит в допустимый набор (например «Статус валидации: Внесено»), значение сохраняется как пользовательский атрибут, а в предупреждении сказано почему.

Тот же разборщик доступен администратору скриптом командной строки: удобно прогнать документ вхолостую, прежде чем отдавать мастер команде, или загрузить пачку файлов скриптом. Поддерживаются предпросмотр, выгрузка промежуточного bundle.json и прямой POST в экземпляр.