Шаблон: матрица трассировки

Матрица трассировки требований (Requirements Traceability Matrix, RTM) — сводный индекс связей «источник → требование → решение → проверка». Строка матрицы — атомарное FR, NFR или (в story-centric режиме) user story; столбцы — уровни цепочки: BRD, SRS, спецификации 10.01, тесты, релиз. RTM не дублирует содержимое SRS, API spec или Use Case — в ячейках только стабильные ID и ссылки на профильные артефакты. Определения forward/backward traceability и зрелость трассировки — в 02.03.04 Трассировка требований (концепция).

1. Назначение

Документ ведёт системный аналитик (или PO/BA с участием QA); его читают разработка, тестировщики, архитектор, PM, аудит/compliance и владелец продукта на этапах планирования релиза, change control и приёмки.

Шаблон закрывает четыре задачи:

• Индекс связей по ID — от BR/регуляторики до spec и test без копирования текстов требований.
• Контроль scope и CR — по ID находите затронутые FR, спеки и тесты; gaps, waiver и исключения из релиза явно помечены.
• Release gate — для must-have in scope есть solution link и test (или waiver); coverage summary считается по согласованным правилам (§3.5).
• Склейка артефактов 10.01 — единая цепочка ID между User Story, API, БД, BPMN, NFR и тестами.

Формулировки требований — в SRS и 10.01.01 Шаблон User Story; контракты — в 10.01.04 Шаблон спецификации REST API и соседних спеках; пороги качества — в 10.01.12 Шаблон нефункциональных требований (NFR).

2. Когда использовать

Подходит, если:

• enterprise- или regulated-проект с формальным SRS, несколькими командами и смешанными артефактами (API, БД, Kafka, BPMN, FE);
• нужен gate «готовность к разработке» или приёмка релиза с доказуемым покрытием must-have (10.04 Чеклист аналитика перед стартом разработки);
• частые CR и параллельные спеки — без RTM теряется связь «кто от чего зависит»;
• аудит, compliance или контракт требуют трассировку BRD → test (08.06 Юридические и регуляторные требования РФ (PCI-DSS));
• ALM (Jira, Azure DevOps, Polarion) генерирует links — шаблон задаёт обязательные типы связей и поля; маппинг link types инструмента на derives/implements/tests — 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence).

Не подходит или требует упрощения, если:

• один сервис, 5–10 FR, одна команда — достаточно таблицы в SRS §Traceability или links в Jira без отдельного master RTM;
• проект на стадии discovery без baseline BRD/SRS — RTM будет пустой «для галочки»; сначала зафиксируйте scope (02.01.04 Определение границ решения (Scope Modelling));
• нужна только трассировка терминов Term ID ↔ поле — это 10.01.14 Шаблон глоссария и словаря данных; RTM дополняет, не заменяет;
• трассировка только на уровне epic без декомпозиции — связь с API/тестами теряется; либо укрупняйте осознанно, либо детализируйте строки.

Входные условия: согласована схема ID требований, есть baseline версия BRD/SRS (или release scope), назначен владелец RTM, выбран режим строк (§3.2) и правила знаменателя coverage (§3.5).

Agile и частые изменения US:

PI baseline RTM (v1.0 Baseline)
  → sprint delta: changelog + новые/изменённые строки в том же документе
  → PI re-baseline (v2.0): superseded-строки, пересчёт coverage, новая версия RTM

Split/merge story: старый US-ID → статус superseded, новые ID со ссылкой на parent FR; жизненный цикл и baseline — 02.05.05 Жизненный цикл требования. Пересчёт coverage — на границе PI или release (05.02 Scrum и Kanban (аналитик в Agile)). Приоритеты при CR — 02.05.02 Управление приоритетами в условиях изменчивости.

Критерий качества RTM: для каждого must-have FR in scope релиза есть путь до проверяемого артефакта (test, documented verification или waiver register); изменение в API spec через RTM находит затронутые FR без ручного поиска по тексту.

3. Структура документа

Пояснение полей — §3.1–3.7; готовый скелет для копирования — §3.8. Поля с пометкой обяз. нужны для enterprise gate; на малых проектах — минимальный набор (см. §3.8). Одна master RTM на продукт или major release; фильтры по epic/sprint — представления, а не копии матрицы.

3.1. Метаданные

3.2. Правила трассировки (операционные)

Полные определения связей, bidirectional traceability и критерии зрелости — 02.03.04 Трассировка требований (концепция); в RTM — только поля и выход анализа (Orphans, Gaps), не переопределение теории.

3.3. Легенда типов связей (для ALM и комментариев)

Краткий набор имён для ячеек и link types. Bidirectional analysis, зрелость трассировки и orphan hunt как процесс — 02.03.04 Трассировка требований (концепция); здесь только поля RTM и регистры Orphans/Gaps как выход заполнения матрицы.

Не смешивать: out_of_scope — «не делаем в v2.1»; deferred — «делаем позже, release TBD» (ещё в roadmap продукта). Одновременно оба статуса на строке — ошибка заполнения.

MoSCoW / приоритет — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано).

3.4. Основная матрица (ядро артефакта)

Каждая строка — одно трассируемое требование в выбранном режиме (§3.2).

Горизонтальная трассировка (SRS ↔ API на одном уровне):

• Одна широкая таблица — до ~25–30 колонок, одна команда/домен, audit не требует отдельного view SRS↔API.
• Sub-matrix — несколько доменов, разные владельцы spec, regulated audit: master RTM (вертикаль BR → test) + отдельная матрица «SRS REQ-ID ↔ API/DB ID». Не дублировать тексты spec — только перекрёстные ссылки по Requirement ID.

Пример перекрёстной ссылки (sub-matrix):

Правило ячеек: в колонках спецификаций — только ID и ссылка на документ, не фрагменты OpenAPI, DDL или описания событий. Несколько ID одного класса в ячейке — все с типом implements; NFR в колонке FR — тип related. Пояснения без ID — в «Комментарий».

3.5. Сводки и отчёты

3.6. История изменений RTM

3.7. Чеклист качества перед baseline / release gate

RTM закрывает trace index, coverage math, gaps/waivers/orphans; 10.04 Чеклист аналитика перед стартом разработки — broader readiness (DoR stories, spec completeness, окружения, риски). Gate-листы не дублируют: RTM — доказательство трассировки; 10.04 — готовность команды к старту.

• Все связи по ID, не по тексту формулировок.
• Режим строк (FR-centric / US-centric) зафиксирован в метаданных; нет смешения FR- и US-строк без правила §3.2.
• Каждый must-have FR in scope: Source + forward link (spec или gap с owner).
• Release-critical: TC-xxx, DV-xxx или waiver register; тип verification понятен QA/compliance.
• Release-critical NFR — отдельные строки с типом verification (08.02 Нефункциональные требования (НФТ) — классификация и стандарты).
• out_of_scope и deferred разведены; не удалены «молча».
• Coverage summary: знаменатель согласован с scope релиза (§3.5).
• Orphan tests и orphan specs проверены (08.03 Тестирование требований (статическое тестирование)).
• Baseline BRD/SRS в метаданных; статический review матрицы — 08.04 Рецензирование и инспекции (техники Фейгана).

3.8. Скелет для копирования (consolidated blank)

Метаданные (шапка документа):

ID документа: RTM-___________
Продукт / релиз: ___________
Версия RTM / статус / дата: ___________
Baseline upstream (BRD, SRS): ___________
Scope релиза: ___________
Режим строк: FR-centric | US-centric
Владелец RTM: ___________
Golden source: ___________

Основная матрица — ядро + опциональные колонки в одной таблице (лишние колонки удалите или оставьте пустыми):

Минимальный набор (малый проект): Requirement ID, Краткая формулировка, Тип, Источник, Приоритет, Solution (или gap), Test/DV (или waiver), Статус, Release/Sprint, Owner.

Сводки (ниже матрицы): Coverage summary · Orphans · Gaps register · Waiver register (при необходимости) · Changelog.

4. Пример заполнения

Сокращённый фрагмент RTM для HR Portal — релиз v2.1, модуль Leave Management (данные условны).

Метаданные: RTM-HR-PORTAL-v2.1 · HR Portal · v1.0 Baseline · 2026-03-15 · Upstream: BRD-HR-v3, SRS-HR-LEAVE-v2 · Scope: epic EP-015 · Режим: FR-centric · Owner: SA Петрова · Golden source: Confluence (RTM page); Jira — authoritative links.

Правила ID: BR-###, FR-###, US-###, API-###, DB-###, TC-###, DV-###, EVT-###. Must-have in scope: Source → spec или gap → test, DV или waiver. Колонка AC-ID в фрагменте опущена (trace через US-0247 → 10.01.01 Шаблон User Story).

4.1. FR-centric (фрагмент основной матрицы)

Sub-matrix RTM-SRS-API-LEAVE (фрагмент):

4.2. US-centric (одна строка — тот же epic, другой режим)

Если команда выбрала US-centric, не дублируйте строки FR-044/FR-045 — одна story покрывает оба parent FR через колонку Parent FR:

Waiver register (фрагмент):

Gaps register (фрагмент):

Coverage summary (по must-have in scope в фрагменте §4.1): знаменатель — 5 (FR-044, FR-045, FR-046, FR-047, NFR-SEC-002; исключены FR-050 out_of_scope, FR-051 deferred); с solution link — 4 (FR-047 — gap); с test, DV или waiver — 5 (FR-046 — DV-AUDIT-001 + waiver register).

CR impact (фрагмент): CR-2026-089 (payload API-LEAVE-003) → FR-044, FR-045, TC-INT-008 → specs обновлены, regression запланирован.

5. Связанные артефакты

На входе (upstream)

На выходе (downstream)

Типичный порядок работы аналитика

1. Зафиксировать схему ID, режим строк (FR/US-centric) и правила coverage до массового заполнения.
2. Импортировать FR/NFR из baseline SRS (CSV или экспорт RM) → строки RTM с Source и приоритетом.
3. По мере появления User Story, API, БД — forward links; gaps с owner, не пустые ячейки без комментария.
4. С QA — test IDs и DV-xxx; backward check на orphans перед planning (08.03 Тестирование требований (статическое тестирование)).
5. При CR — обновить RTM до merge спеки (02.05.02 Управление изменениями (Change Control Board), 02.05.02 Управление приоритетами в условиях изменчивости).
6. Release gate: coverage summary, waivers, baseline RTM; Agile — delta между PI baseline (05.02 Scrum и Kanban (аналитик в Agile)).

6. Связи с другими разделами базы

• Концепция и bidirectional traceability — 02.03.04 Трассировка требований (концепция)
• Жизненный цикл, split/superseded — 02.05.05 Жизненный цикл требования
• Many-to-many FR ↔ spec — 02.05.01 Управление зависимостями между требованиями
• ALM, link types, экспорт RTM — 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence)
• V&V, test ↔ requirement — 02.04.01 Верификация и валидация (V&V)
• NFR verification — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты
• Regulated-проекты — 08.06 Юридические и регуляторные требования РФ (PCI-DSS)
• Agile, PI/sprint delta — 05.02 Scrum и Kanban (аналитик в Agile)
• Чеклист broader readiness — 10.04 Чеклист аналитика перед стартом разработки

7. Источники и дополнительные материалы

URL из отчёта исследования; перед публикацией перепроверьте актуальность вручную.

Книги и стандарты

• ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering — https://standards.ieee.org/standard/29148-2018.html
• IIBA — BABOK® Guide — Requirements Analysis and Design Definition — https://www.iiba.org/standards-and-resources/babok/
• ГОСТ Р ISO/IEC/IEEE 29148-2017 — текст стандарта RE (RU) — https://docs.cntd.ru/document/1200151608

Статьи и практики

• Requirements traceability — обзор forward/backward (Wikipedia) — https://en.wikipedia.org/wiki/Requirements_traceability
• Requirements traceability matrix — ReQtest — https://reqtest.com/requirements-blog/requirements-traceability-matrix/
• Requirements traceability — IBM Think — https://www.ibm.com/think/topics/requirements-traceability
• Link issues in Jira — основа trace links в ALM — https://support.atlassian.com/jira-software-cloud/docs/link-issues-to-check-their-relationship/