Урок 03.03: Матрица трассировки требований

Цель урока

Освоить концепцию трассировки (прослеживаемости) требований — от бизнес-целей до кода и тест-кейсов. Научиться строить и поддерживать матрицу трассировки (RTM — Requirements Traceability Matrix) и понять, как она помогает управлять изменениями (Change Management) и доказывать полноту реализации.

Ключевые понятия

• Трассировка требований (Requirements Traceability) — способность проследить связь требования от его источника (бизнес-цель, стейкхолдер) через спецификацию и дизайн до реализации (код) и верификации (тест)
• RTM (Requirements Traceability Matrix) — таблица, в которой каждое требование связано с вышестоящими и нижестоящими артефактами
• Forward Traceability (прямая трассировка) — от источника к реализации: бизнес-требование → ФТ → дизайн → код → тест
• Backward Traceability (обратная трассировка) — от реализации к источнику: тест → ФТ → бизнес-требование
• Coverage Analysis (анализ покрытия) — проверка, что все требования реализованы и протестированы (или что нет «лишнего» кода)
• Impact Analysis (анализ влияния изменений) — оценка того, какие компоненты будут затронуты при изменении конкретного требования
• Baselined Requirement (замороженное требование) — требование, которое утверждено и не может быть изменено без формальной процедуры

---

1. Что такое трассировка и зачем она нужна?

1.1. Определение

Трассировка требований — это способность установить и проследить сквозную связь между:

Бизнес-цель → Бизнес-требование → Функциональное требование → 
→ Компонент / Модуль → Тест-кейс → Результат теста

Или, если представить это как «слои» проекта:

┌─────────────────────────────────────┐
│  Бизнес-цели / Vision Document      │
└────────────────┬────────────────────┘
                 ↓ (зачем?)
┌─────────────────────────────────────┐
│  Бизнес-требования / User Stories   │
└────────────────┬────────────────────┘
                 ↓ (что?)
┌─────────────────────────────────────┐
│  Функциональные требования (SRS)    │
└────────────────┬────────────────────┘
                 ↓ (где?)
┌─────────────────────────────────────┐
│  Компоненты / API / Модули          │
└────────────────┬────────────────────┘
                 ↓ (чем?)
┌─────────────────────────────────────┐
│  Тест-кейсы / QA                    │
└─────────────────────────────────────┘

1.2. Почему это важно? (Три причины)

Причина 1: Полнота реализации

Без трассировки вы не знаете, все ли требования реализованы.

Вопрос	С трассировкой	Без трассировки
«Мы сделали всё, что заказывал заказчик?»	✅ Пробежались по RTM — каждое FR покрыто тестом	❌ «Вроде да... А про это требование мы забыли»
«Этот тест-кейс к чему относится?»	✅ «К FR-012»	❌ «Не помню, на всякий случай запускаем»
«У нас есть код, который ни на что не завязан — зачем он?»	✅ «Это избыточный код»	❌ «Наверное, нужен...»

Причина 2: Анализ влияния изменений (Impact Analysis)

Когда заказчик говорит: «Давайте поменяем требование FR-012», вы должны ответить:

• Какие тест-кейсы нужно переписать? (TC-045, TC-046)
• Какие компоненты нужно изменить? (Auth Service)
• Какие другие требования будут затронуты? (FR-013, FR-014)
• Сколько это займёт времени?

Без RTM ответа на эти вопросы нет — есть только гадание.

Причина 3: Аудит и Compliance

В регулируемых отраслях (медицина, банки, авиация) трассировка обязательна:

• FDA (медицинские системы) — требует доказать, что каждое требование реализовано и протестировано
• Банк России — требует трассировку для систем, обрабатывающих платежи
• ISO 13485 (медицинские изделия) — обязательная трассировка

Без RTM вы не пройдёте аудит.

---

2. Типы трассировки

2.1. Прямая трассировка (Forward Traceability)

Направление: Источник → Реализация

Вопрос: «Какие требования нужно реализовать, чтобы удовлетворить бизнес-цель?»

Пример:

Бизнес-цель: «Увеличить скорость обработки заказов на 30%»
    → Бизнес-требование BR-001: «Автоматизировать создание заказа»
        → Функциональное требование FR-012: «Автокомплит клиента по ИНН»
            → Компонент: Customer Service
                → Тест-кейс TC-045: «Автокомплит по ИНН — успешный поиск»

2.2. Обратная трассировка (Backward Traceability)

Направление: Реализация → Источник

Вопрос: «Зачем был написан этот код / этот тест? Какое бизнес-требование его обосновывает?»

Пример:

Тест-кейс TC-045 (провалился)
    → Какому FR он соответствует? → FR-012
        → Какое бизнес-требование? → BR-001
            → Какая бизнес-цель? → «Увеличить скорость обработки заказов на 30%»

Обратная трассировка помогает, когда нужно понять ценность каждого элемента. Если вы находите код, который не ведёт ни к какому бизнес-требованию — это, скорее всего, лишний код (gold-plating), который можно удалить.

2.3. Горизонтальная трассировка (Cross- Traceability)

Вопрос: «Какие требования связаны друг с другом?»

Пример: FR-012 (автокомплит по ИНН) зависит от FR-010 (справочник контрагентов) — если мы меняем FR-010, это влияет на FR-012.

---

3. RTM — Requirements Traceability Matrix

3.1. Что такое RTM?

RTM (Матрица трассировки требований) — это таблица (обычно в Excel, Google Sheets или Confluence), где:

• Строки — требования (функциональные, нефункциональные)
• Столбцы — связанные артефакты (бизнес-требования, компоненты, тест-кейсы, статус)

3.2. Полный пример RTM в Markdown-таблице

Проект: Интернет-магазин (MVP) Легенда: Создаётся MVP интернет-магазина на 5 функциональных требований.

ID Требования	Описание требования	Источник (BR / User Story)	Приоритет	Компонент / Сервис	Тест-кейсы	Статус реализации	Статус теста
BR-001	Увеличить скорость обработки заказов на 30% за счёт автоматизации	Vision Document v1.0	—	—	—	—	—
BR-002	Обеспечить прозрачность статуса заказа для клиента	Интервью с РОП	—	—	—	—	—
FR-001	Система должна позволять авторизоваться по email и паролю	User Story US-001 (BR-001)	High	Auth Service	TC-001 (успешный вход), TC-002 (неверный пароль), TC-003 (блокировка после 5 попыток)	✅ Реализовано	✅ PASS
FR-002	Авторизованный пользователь должен создать заказ, выбрав товары, адрес и способ оплаты	User Story US-002 (BR-001)	High	Order Service	TC-010 (создание заказа), TC-011 (пустая корзина), TC-012 (неверный адрес)	✅ Реализовано	⚠️ TC-011 FAIL
FR-003	Система должна отправлять email-уведомление при смене статуса заказа	User Story US-003 (BR-002)	High	Notification Service	TC-020 (статус изменён → письмо отправлено), TC-021 (SMTP недоступен — retry)	🟡 В разработке	❌ Не протестировано
FR-004	Пользователь должен видеть историю своих заказов	User Story US-004 (BR-002)	Medium	Order Service	TC-030 (история отображается), TC-031 (пустая история)	✅ Реализовано	✅ PASS
FR-005	Администратор должен иметь дашборд с количеством заказов по статусам	User Story US-005 (BR-001)	Low	Dashboard Service	TC-040 (дашборд загружается), TC-041 (данные соответствуют БД)	🔴 Не начато	❌
NFR-001	Время загрузки страницы каталога не превышает 2 секунды (95-й перцентиль)	Соглашение SLA (BR-001)	High	Frontend + API	TC-100 (нагрузочный тест — 100 RPS)	🟡 Частично	⚠️ P95 = 2.3 сек
NFR-002	Доступность системы — 99.5% в месяц	SLA (BR-001)	Medium	Инфраструктура	TC-101 (мониторинг аптайма за месяц)	🟡 Настраивается	❌

3.3. Разбор колонок таблицы

Колонка	Что означает	Зачем нужна
ID Требования	Уникальный идентификатор (FR-001, NFR-001)	Единая ссылка для всех артефактов
Описание требования	Краткое, однозначное описание	Чтобы не перечитывать SRS
Источник (BR / User Story)	Ссылка на вышестоящее требование (бизнес-требование или User Story)	Обратная трассировка — откуда взялось
Приоритет	High / Medium / Low	Кто виноват, если не сделали в срок
Компонент / Сервис	Какой модуль/система отвечает за реализацию	Impact Analysis — что сломается при изменении
Тест-кейсы	Ссылки на конкретные тесты	Покрытие — каждый тест закрывает требование
Статус реализации	Реализовано / В разработке / Не начато	Мониторинг готовности
Статус теста	PASS / FAIL / Не тестировалось	Quality Gate

3.4. Как строить RTM: пошаговая инструкция

Шаг 1: Определите уровни трассировки

Решите, какие слои вы связываете. Минимальный набор для большинства проектов:

Бизнес-требование (BR) → Функциональное требование (FR) → Тест-кейс (TC)

Для compliance-проектов добавляем:

... → Компонент (модуль) → Релиз / Версия

Шаг 2: Создайте таблицу (Excel / Google Sheets / Confluence)

Колонки: ID, Описание, Источник, Приоритет, Компонент, Тест-кейсы, Статус реализации, Статус теста.

Шаг 3: Внесите все требования из SRS

Каждая строка — одно функциональное или нефункциональное требование. Группируйте по модулям.

Шаг 4: Заполните колонку «Источник»

Для каждого ФТ укажите бизнес-требование, из которого оно выведено. Используйте ID:

FR-001 → BR-001
FR-002 → BR-001
FR-003 → BR-002

Шаг 5: Заполните колонку «Компонент»

Для каждого ФТ укажите, какой компонент/сервис будет его реализовывать.

Шаг 6: Добавьте тест-кейсы

Когда QA написал тесты, укажите их ID в колонке «Тест-кейсы».

Шаг 7: Поддерживайте в актуальном состоянии

RTM — живой документ. Обновляйте его при:

• Добавлении нового требования
• Изменении требования
• Реализации требования (статус)
• Написании тест-кейса
• Прохождении / падении теста

---

4. RTM и управление изменениями (Change Management)

4.1. Кейс: как RTM спасает проект при изменении требований

Ситуация: В пятницу вечером заказчик звонит и говорит:

«Слушайте, мы пересмотрели процесс. Заказ теперь может создать не только авторизованный пользователь, но и гость. Для этого нужно...»

Без RTM: — Разработчик: «Надо посмотреть код... (2 дня анализа)... Кажется, надо менять Order Service, Auth Service, Notification… ну и тесты переписать. Сколько? Не знаю, недели две?» — Заказчик: «Две недели? Вы что, там же кнопку добавить!» — Конфликт.

С RTM:

Аналитик открывает RTM и видит:

Действие	Результат по RTM
Какое требование меняется?	FR-002: «Только авторизованный пользователь создаёт заказ»
Какие компоненты затронуты?	Order Service (авторизация), Notification Service (кто получает уведомление), Auth Service (гость без auth)
Какие тест-кейсы нужно переписать?	TC-010, TC-011, TC-012 (Order) + TC-020 (Notification)
С какими ещё требованиями связан?	FR-003 (уведомление гостю — некуда), FR-001 (гость не авторизован)
Какие бизнес-требования затрагивает?	BR-002 (прозрачность статуса для гостя? или только для клиента?)

Аналитик за 15 минут даёт ответ:

«Изменение FR-002 затрагивает 2 компонента и 5 тест-кейсов. Нужно также уточнить BR-002 — отправлять ли уведомления гостю (ему некуда). Оценка: 5 дней + 2 дня на тесты. И нужно согласовать с юристом: работа с гостями — 152-ФЗ».

4.2. Как RTM помогает при Change Request

Процесс управления изменениями (Change Management) с RTM:

1. Запрос на изменение (CR)
   ↓
2. Поиск в RTM: какие требования затрагивает?
   ↓
3. Impact Analysis: какие компоненты, тест-кейсы, другие требования?
   ↓
4. Оценка трудозатрат (на основе Impact Analysis)
   ↓
5. Решение: принять / отклонить / отложить CR
   ↓
6. Если принято — обновить RTM (добавить/изменить строки)

Без RTM шаги 2, 3 и 4 выполняются «на глаз» — это главный источник срыва сроков и бюджетов.

4.3. Что показывает RTM при анализе изменений

Вопрос для Impact Analysis	Что смотрим в RTM
Какие компоненты нужно менять?	Колонка «Компонент»
Сколько тест-кейсов переписать?	Колонка «Тест-кейсы»
Какие ещё требования зависят от изменяемого?	Колонка «Источник» — если у двух FR один источник BR
Какой код «ничей» и не будет затронут?	Строки без тест-кейсов — лишний код
Какое бизнес-требование перестанет выполняться после удаления этого ФТ?	Обратная трассировка: FR → BR

---

5. Дополнительные срезы RTM

5.1. RTM по тест-кейсам (матрица покрытия)

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

Тест-кейс	FR-001	FR-002	FR-003	FR-004	FR-005
TC-001 (успешный вход)	✅	—	—	—	—
TC-002 (неверный пароль)	✅	—	—	—	—
TC-010 (создание заказа)	—	✅	—	—	—
TC-011 (пустая корзина)	—	✅	—	—	—
TC-020 (уведомление по email)	—	—	✅	—	—
TC-030 (история заказов)	—	—	—	✅	—
Coverage	100%	100%	100%	100%	0% (FR-005 не покрыта!)

Красный флаг: FR-005 не покрыта тестами. Значит, она либо не реализована, либо не тестировалась.

5.2. RTM по релизам

Помогает понять, что в каком релизе выходит:

FR	Релиз 1 (MVP)	Релиз 2	Релиз 3
FR-001	✅	—	—
FR-002	✅	—	—
FR-003	✅	—	—
FR-004	—	✅	—
FR-005	—	—	✅

---

6. Инструменты для ведения RTM

Инструмент	Плюсы	Минусы	Для чего подходит
Excel / Google Sheets	Простота, гибкость, умеют все	Тяжело поддерживать при 500+ требований, нет связей	Небольшие проекты (до 100 требований)
Confluence + плагины (e.g., Requirements)	Связи между страницами, история изменений	Требует настройки, плагины платные	Средние проекты
Jira + Structure	Связь с задачами, автоматизация	Дорого, сложно	Крупные проекты с Agile
DOORS (IBM)	Промышленный стандарт, traceability на уровне ядра	Очень дорого, сложно	Регулируемые отрасли (авиация, медицина)
Arena PLM / Codebeamer	PLM-системы с RTM	Дорого	Хардвер + софт
Test Management (TestRail, Zephyr)	RTM для тестов	Не закрывает FR → BR	QA-департаменты

Лучшая практика для 90% проектов: Google Sheets для RTM (простота, доступность, лёгкий экспорт для аудита) + Jira для связи с задачами.

---

7. Типичные ошибки в RTM

Ошибка	❌ Пример	✅ Как правильно
RTM как отдельный «бумажный» документ	Написали в начале проекта, положили на полку, забыли	RTM живёт и обновляется параллельно с проектом
Только один срез (FR → TC)	Нет связи с бизнес-требованиями	Добавить колонку «Источник (BR / US)»
Пропущенные NFR	В RTM только функциональные требования	NFR тоже нужно трассировать (для аудита это обязательно)
Огромная таблица без фильтров	500 строк в Excel без группировки, искать невозможно	Использовать фильтры, группировку по модулям, conditional formatting
Нет статусов	Просто список связей, непонятно, что сделано	Добавить «Статус реализации» и «Статус тестов»
RTM заполняется постфактум	«Допишем, когда проект закончится»	RTM не допишут никогда. Заполнять по мере уточнения требований

---

8. Практический пример: как RTM выявила проблему

Реальный кейс:

В проекте внедрения CRM было 47 FR. Команда разрабатывала 3 месяца. За день до релиза QA запустила полный регресс.

Проблема: 3 заказа из 30 «зависали» в статусе «В обработке» и никогда не переходили дальше.

Анализ через RTM:

FR-022	Система должна переводить заказ в статус «Доставлен» после подтверждения получения клиентом	High

TC-100	Проверка статуса «Доставлен» при подтверждении клиента	FR-022	❌ FAIL

Причина падения: Разработчик реализовал FR-022 через 2 дня (событие → смена статуса), но в RTM не обновил. Позже архитектор изменил модель событий, и реализация FR-022 «сломалась», но никто этого не заметил, так как тест-кейс для FR-022 больше не работал, а в RTM значился как PASS (устаревшая запись).

Лечение: RTM нужно обновлять при каждом изменении. Если тест упал — RTM должна это отражать.

Вывод: RTM — это не «декорация» для отчёта. Это рабочий инструмент, который помогает находить расхождения между планом и реальностью.

---

9. Вопросы к RTM для самопроверки проекта

Периодически задавайте эти вопросы, глядя на RTM:

1. Сколько требований имеют статус «Не начато»? (Риск срыва сроков)
2. Сколько требований не имеют тест-кейсов? (Риск неоттестированного функционала)
3. Есть ли тест-кейсы, которые не ведут ни к одному требованию? (Лишние тесты)
4. Есть ли код, который не ведёт ни к одному требованию? (Gold-plating)
5. Какие требования изменились за последнюю неделю? (Динамика)
6. Сколько требований имеют FAIL-тесты? (Качество)

Эти вопросы — основа для регулярного Quality Gate (контрольная точка качества).

---

Вопросы для самопроверки

1. Что такое трассировка требований? Какие 3 причины делают её обязательной?
2. В чём разница между Forward Traceability и Backward Traceability? Приведите пример для каждой.
3. Какие колонки должна содержать RTM (минимум 5)?
4. Как RTM помогает при Change Request? Опишите процесс Impact Analysis с RTM.
5. Что означает строка в RTM, где у требования стоит Статус теста = FAIL? Какие действия должен предпринять аналитик?
6. Почему RTM должна быть живым документом и что произойдёт, если её «написать и забыть»?

---

Практическое задание

Кейс: Вы аналитик в проекте «Мобильное приложение для доставки еды». У вас есть следующий набор требований:

Бизнес-требования:

• BR-001: Увеличить количество заказов за счёт мобильного приложения
• BR-002: Сократить нагрузку на колл-центр через онлайн-самообслуживание

Функциональные требования (черновик):

• FR-001: Пользователь должен зарегистрироваться по номеру телефона
• FR-002: Пользователь должен просматривать меню ресторана
• FR-003: Пользователь должен добавить товар в корзину
• FR-004: Пользователь должен оформить заказ с выбором способа оплаты
• FR-005: Пользователь должен отслеживать статус заказа на карте (GPS курьера)

Нефункциональные требования:

• NFR-001: Время загрузки меню не более 2 секунд
• NFR-002: Приложение должно работать офлайн-режиме для просмотра сохранённого меню

Тест-кейсы (есть, но не привязаны):

• TC-001: Регистрация по номеру — успешный сценарий
• TC-002: Регистрация по номеру — неверный код из SMS
• TC-003: Загрузка меню при скорости интернета 3G
• TC-004: Оформление заказа с оплатой картой
• TC-005: Статус заказа на карте обновляется в реальном времени
• TC-006: Офлайн-режим — отображение сохранённого меню

Задание 1. Постройте RTM

Создайте Markdown-таблицу RTM для этого проекта. Включите колонки:

• ID требования
• Описание
• Источник (BR)
• Приоритет (назначьте сами — H/M/L)
• Компонент (предположите: Frontend / Backend / API / Mobile)
• Тест-кейсы
• Статус реализации (предположите: ✅ / 🟡 / 🔴)
• Статус теста (предположите: ✅ / ❌)

Дополните таблицу 2–3 требованиями от себя (на основе логики: что ещё нужно для полноты?).

Задание 2. Impact Analysis

Представьте, что заказчик просит изменить FR-004: «Мы решили, что оплата должна быть только после получения заказа (наличными курьеру), а не онлайн».

Опишите:

1. Какие компоненты будут затронуты? (на основе вашей RTM)
2. Какие тест-кейсы нужно переписать?
3. Какие ещё требования могут быть затронуты косвенно?
4. Какое бизнес-требование (BR) может быть поставлено под сомнение этим изменением?

Задание 3. Анализ покрытия

Проверьте вашу RTM на:

• Какие требования не имеют тест-кейсов? (слепые зоны)
• Есть ли тест-кейсы, которые ни к чему не привязаны? (избыточные)

Напишите 1–2 предложения: какие риски вы видите из этого анализа.

Формат: Один файл (md) с тремя разделами.

---

Дополнительные материалы

• Стандарт: ISO/IEC/IEEE 29148:2018 — раздел про трассировку
• Книга: «Software Requirements» — Karl Wiegers, Joy Beatty, глава 15 «Requirements Traceability»
• BABOK 3.0: Глава 7.2 — Traceability and Monitoring
• Статья: «Requirements Traceability Matrix — RTM and its Importance» — PMI
• Шаблон: RTM Template (Google Sheets / Excel) — скачать по запросу
• PMLC: «Using Traceability to Manage Change Impact» — Project Management Institute