Ответ.

История вопроса:

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

Проблема:

В отсутствие трассировки теряется связь между требованиями различных уровней: бизнес-цели → функциональные требования → технические требования → тестовые сценарии. Это приводит к ошибкам, «потерянным» требованиям и некачественной реализации.

Решение:

Трассировка требований строится как цепочка соответствий с помощью матриц, специализированных инструментов (Jama, DOORS, Jira/Zephyr) и шаблонов:

Создается матрица трассируемости (traceability matrix), где простейшая структура —

Бизнес-цель Функциональное требование Тестовый сценарий
BC-1 FR-1 TC-1
Применяется тегирование артефактов в инструментах.
На каждом изменении любого уровня производится пересмотр цепочки — должна быть связь.
Важно регулярно проводить ревизии, чтобы выявить « висящие» требования или тесты без привязки к целям.

Ключевые особенности:

Явная сквозная связь от потребностей до результата
Автоматизированное отслеживание в инструментах
Контроль полноты и обоснованности требований и тестов

Вопросы с подвохом.

Можно ли обойтись без матрицы трассируемости на небольшом проекте?

Нет, даже на малых проектах отсутствие трассировки часто приводит к потере требований.

Достаточно ли один раз построить трассируемость в начале проекта?

Нет, матрица требует регулярного обновления по мере изменения требований и тестов.

Влияет ли трассируемость только на завершение тестирования?

Нет, она важна на всех этапах — от проектирования до сопровождения, помогает оценивать влияние изменений и планировать работы.

Типовые ошибки и анти-паттерны

Случайная, а не системная трассировка
Отсутствие ревизий цепочек на изменениях
Игнорирование нерелевантных или висящих требований

Пример из жизни

Негативный кейс:

В проекте не построили матрицу трассируемости, тестировщики исходили только из спецификации. Несколько требований реализовали, но не проверили, из-за чего фичи в проде работали не так, как нужно.

Плюсы:

Быстрее стартовали проект

Минусы:

Пропущенные критические ошибки, фрустрация у заказчика

Положительный кейс:

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