Матрица трассируемости требований с ИИ строится так: зафиксируйте утверждённую базу, присвойте уникальные ID и определите допустимые связи. ИИ может предложить связь только с цитатой и местом в источнике. Владельцы требований, дизайна, реализации, тестов и профильных гарантий должны подтвердить каждую связь и результат.

RTM — это инфраструктура доказательств, а не таблица, которую один раз генерируют в конце. Она обеспечивает прямую трассировку от требования к дизайну, реализации, проверке и доказательству, а также обратную — от реализации и тестов к утверждённому требованию. ИИ может сократить рутинную работу, но не должен придумывать требования, связи, результаты тестов, исключения или выводы о соответствии. Общие границы задаёт руководство по использованию ИИ. Расписание ведите в плане проекта, а утверждение версии — через процесс с участием человека.

Ключевые выводы:

Начинайте с утверждённой базы требований с уникальными ID.

Каждая связь должна опираться на цитату и место в источнике.

Связи от ИИ — только кандидаты, пока их не подтвердят владельцы.

Проверяйте и прямое покрытие, и обратное обоснование.

Отличайте запланированную проверку от выполненного и рассмотренного доказательства.

Поддерживайте матрицу при каждом изменении требований или последующих артефактов.

Шаг 1: Зафиксируйте базу и уникальные ID

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

Присвойте каждому требованию уникальный стабильный ID. Не используйте номер строки, который меняется при сортировке. Зафиксируйте точный текст, место в источнике, обоснование, владельца, приоритет или критичность, если они утверждены, и текущий статус жизненного цикла.

Руководство NASA по управлению требованиями описывает установление, контроль, верификацию, валидацию и трассировку требований на протяжении жизненного цикла.［1］ Этот взгляд важен: RTM должна отражать контролируемые изменения, а не просто последнюю подборку предложений.

Отделяйте требования от пояснений, целей, проектных идей, допущений и примеров. ИИ может распознать предложение, похожее на требование, но принять его может только уполномоченный процесс управления требованиями. Помещайте неутвержденных кандидатов в очередь на рассмотрение, а не присваивайте им незаметно ID требований.

Шаг 2: Проверьте атомарность и проверяемость

Проверьте, что каждое требование содержит одну ограниченную обязанность, определенный субъект, ясные условия и проверяемый результат. Составное утверждение, соединенное несколькими «и», может потребовать утвержденной декомпозиции. Сохраняйте связи «родитель — потомок» и исходный текст; не позволяйте ИИ переписывать договорные или регулируемые формулировки так, будто переписанный текст авторитетен.

Задайте вопросы:

Ясны ли исполнитель или граница системы?
Наблюдаемо ли требуемое поведение или качество?
Определены ли условия срабатывания и исключения?
Однозначны ли единицы, пороги и допуски?
Может ли метод проверки определить «пройдено» или «не пройдено»?
Не противоречит ли оно другому утвержденному требованию и не дублирует ли его?

Руководство NASA по валидации требований направлено на то, чтобы требования были правильно сформулированы, ясны, полны, согласованы, реализуемы и проверяемы до того, как на них будут опираться последующие этапы.［3］ Записывайте дефекты и передавайте их владельцу требования; не исправляйте их только внутри матрицы.

Шаг 3: Определите поля и статусы

Выберите поля до извлечения. Полезный шаблон:

ID требования	Источник	Текст	Обоснование	Владелец	Статус	Дизайн	Реализация	Тест/доказательство	Результат	Версия
REQ-001	SPEC-3.2	Точный утверждённый текст	Утверждённая причина	Владелец продукта	База	DES-014	MOD-07	TP-031 / EV-031	Проверено: пройдено	2.1

Используйте пример только как формат. Определите допустимые значения, например candidate, reviewed, approved, implemented, verified, deferred и retired, и кто может устанавливать каждое из них. Избегайте общего «готово». Требование может быть реализовано, но не проверено, или протестировано, но с неудачным результатом.

Представляйте связи стабильными ID артефактов с версиями, а не неформальными описаниями. Если документ дизайна или тест изменился, матрица должна показывать, действует ли прежняя проверка. Указывайте точное место доказательства — раздел, тестовый сценарий, запись о результате или контролируемый URL, — чтобы другой проверяющий мог его открыть.

Шаг 4: Пусть матрица трассируемости требований с ИИ содержит только кандидатные связи

Передавайте только утвержденные или явно помеченные артефакты, глоссарий, схему и правила связей. Разбивайте большие наборы источников на пакеты, которые можно проверить, сохраняя ID артефактов и метаданные версий.

Контролируемый запрос:

Для каждого утверждённого требования предложи кандидатные связи с предоставленными артефактами. Верни ID требования, ID и версию целевого артефакта, тип связи, точную подтверждающую цитату с местом и краткое обоснование. Используй только предоставленный текст. Если подтверждение неоднозначно или отсутствует, верни UNRESOLVED. Не создавай требования, ID требований, артефакты, результаты тестов, статусы, исключения или выводы о соответствии.

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

Защищайте чувствительные спецификации и проекты безопасности в соответствии с правилами об утвержденных инструментах, доступе, хранении и местоположении данных. Минимизируйте передаваемые материалы. Профиль NIST по генеративному ИИ выделяет риски конфабуляций, приватности, информационной безопасности и целостности информации, требующие управления и человеческого надзора.［4］

Шаг 5: Разберите неоднозначности, дубликаты и пробелы

Проверяйте кандидатные связи небольшими пакетами. Для каждой связи выберите: принять, отклонить, требуется уточнение или требуется владелец. Записывайте проверяющего, дату, причину и версию матрицы. Никогда не считайте оценку уверенности модели утверждением.

Ищите в первую очередь:

требования без дизайна, реализации, теста или доказательства;
один тест, связанный со многими требованиями без доказательства каждого условия;
дублирующиеся требования с разными ID;
противоречащие требования или версии;
реализацию, выходящую за утвержденный охват или противоречащую ему;
тесты, проверяющие поведение, которого не требует ни одно требование;
связи, основанные только на похожих словах;
результаты, скопированные из плана, а не из записи о выполнении.

Артефакт без связей — сигнал для проверки, а не автоматическое доказательство сбоя. Недавно включенное в базу требование может законно ждать дизайна. И наоборот, реализация без требования может быть необходимой инфраструктурой, исправлением дефекта, недокументированным требованием или несанкционированным расширением охвата. Передайте ее ответственному владельцу.

Если матрица ссылается на внешние стандарты или утверждения, используйте контроль фактов. Сводка стандарта, подготовленная ИИ, не заменяет утвержденное толкование.

Шаг 6: Установите прямую трассировку

Прямая трассировка отвечает на вопрос, есть ли у каждого утвержденного требования подходящая последующая реализация и проверка. Проследите цепочку:

от требования к архитектурному или проектному решению;
от дизайна к компоненту реализации или конфигурации;
от требования к методу проверки и процедуре тестирования;
от процедуры к записи о выполнении и доказательству;
от доказательства к рассмотренному результату и решению.

Не пропускайте различие между процедурой и результатом. ID тестового сценария доказывает только то, что тест запланирован. Отметка «пройдено» требует выполненного результата, привязанного к правильной версии и среде, и проверки по процессу проекта.

Для проверки без тестов — осмотра, анализа, демонстрации или сертификации — явно записывайте метод и доказательство. Ссылка на папку обычно слишком широка; укажите артефакт и раздел, который демонстрирует выполнение требования.

Руководство NASA по двусторонней трассировке подчеркивает трассировку процедур тестирования ПО к требованиям и требований к процедурам тестирования с поддержкой этих связей на протяжении жизненного цикла.［2］ Конкретные артефакты зависят от проекта, но оба направления должны быть доступны для проверки.

Шаг 7: Выполните обратную трассировку

Начните с дизайнов, реализованных компонентов, конфигураций, процедур тестирования и доказательств. Спросите, какое утвержденное требование разрешает или требует каждый артефакт. Так выявляются избыточные доработки, устаревшие тесты, недокументированное поведение и случайное расширение охвата.

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

связан и подтвержден;
общая инфраструктура с задокументированным обоснованием;
исправление дефекта, связанное с утвержденной проблемой или требованием;
кандидат в новое требование, ожидающий утверждения;
устаревший или вне охвата;
не решено.

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

Шаг 8: Поддерживайте матрицу при изменениях

Назначьте владельца каждого требования и владельца матрицы как контролируемого артефакта. Определите события для проверки: изменение базы, пересмотр дизайна, изменение кода, изменение теста, неудачный результат, исключение, кандидат в релиз или запрос аудита.

Когда что-то меняется:

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

Автоматизированные инструменты могут отмечать устаревшие связи, пустые поля, дублирующиеся ID или недопустимые статусы. Они не могут решить, что изменившиеся доказательства по-прежнему достаточны. Это решение остается за названными проверяющими.

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

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

Контрольный список утверждения

Перед релизом или формальной проверкой подтвердите, что:

база и включенные версии определены;
все ID требований уникальны и утверждены;
каждая принятая связь содержит ID цели и доказательство проверки;
у всех требований есть подходящее решение по прямой трассировке;
обратная трассировка не выявила необъясненного объема реализации или тестов;
запланированные тесты не выданы за пройденные;
неудачные, отложенные, исключенные и нерешенные элементы остаются видимыми;
чувствительные артефакты защищены;
профильные проверяющие утвердили необходимые толкования в области безопасности или соответствия;
выгрузка и запись об утверждении относятся к одной и той же версии матрицы.

Часто задаваемые вопросы (FAQ)

Что такое RTM?

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

Может ли ИИ писать требования?

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

Что означает двусторонняя трассировка?

Прямая трассировка проверяет, что требования реализованы и проверены. Обратная — что дизайн, реализация и тесты опираются на утвержденные требования или задокументированное обоснование.

Может ли один тест покрывать несколько требований?

Да, если проверяющие подтвердили, что процедура и доказательства проверяют каждое связанное условие. Не делайте вывод о покрытии по общей лексике.

Достаточно ли ссылки на план тестирования?

Нет. План показывает намеченную проверку. Отдельно записывайте выполненный результат, среду и версию, место доказательства и рассмотренное решение.

Когда обновлять RTM?

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

Что делать с требованием без связей?

Назначьте владельца и решение: нужен дизайн, нужен тест, отложено, выведено из базы, дубликат, недействительно или не решено. Не скрывайте его и не просите ИИ выдумать связь.

Доказывает ли RTM соответствие требованиям регулятора?

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

Источники

NASA, Requirements Management — https://www.nasa.gov/reference/6-2-requirements-management/
NASA Software Engineering Handbook, Bidirectional Traceability Between Software Test Procedures and Software Requirements — https://swehb.nasa.gov/spaces/7150/pages/16449898/SWE-072%2B-%2BBidirectional%2BTraceability%2BBetween%2BSoftware%2BTest%2BProcedures%2Band%2BSoftware%2BRequirements
NASA Software Engineering Handbook, Requirements Validation — https://swehb.nasa.gov/spaces/SWEHBVD/pages/102695440/SWE-055%2B-%2BRequirements%2BValidation
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 29 августа 2026 г.

Матрица трассируемости требований с ИИ: как её построить