Области знаний
Партнёрские проектыМатериалы БРЭСпецпроектыСтать автором
Настроить видСменить языкИнформация
О РУВИКИ
Найти статью

Матрица трассируемости

Pause

Матрица трассируемости (англ. traceability matrix, TM) — это документ, обычно оформляемый в виде таблицы, который помогает определить полноту связей между двумя закреплёнными версиями документов. Для этого проводится сопоставление элементов через сравнение «многие—ко-многим» между различными артефактами разработки. Такой подход широко применяется в процессе соотнесения высокоуровневых требований, детализированных требований к продукту и их соответствия частям архитектуры, проектной документации, планам тестирования и наборам тестов. В структуру матрицы трассируемости включаются бизнес-требования, критерии приёмки и нефункциональные требования. Помимо разработки программного обеспечения, инструмент применяется в таких отраслях, как автомобилестроение и медицина[1][2].

Виды трассируемости

  • Прямая трассируемость (англ. forward traceability) — отслеживание от исходных требований к их реализации и тест-кейсам. Позволяет убедиться, что все потребности заказчика учтены, реализованы и покрыты тестами, а также гарантирует развитие проекта в нужном направлении[2].[3].
  • Обратная трассируемость (англ. backward traceability) — отслеживание от готового кода, функциональности и тест-кейсов обратно к исходным требованиям. Помогает выявить избыточную работу и убедиться, что в продукт не добавляются функции или тесты, не предусмотренные изначальными требованиями[2].[3].
  • Двунаправленная трассируемость (англ. bidirectional traceability) — отслеживание связей в обоих направлениях. Обеспечивает полную видимость связей, гарантируя покрытие всех требований тестами и обоснованность каждого теста. Ключевое преимущество двунаправленной трассируемости заключается в возможности отследить влияние любых изменений в обе стороны (от бизнес-требований к тестам и реализации и наоборот), что позволяет точно определить все затронутые компоненты системы[2].[3][4].

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

Структура и элементы

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

  • Бизнес-требования — определяют потребности бизнеса и выступают исходной точкой, напрямую связываясь с функциональными требованиями[2].[5]
  • Функциональные требования — детализируют бизнес-требования и служат центральным связующим звеном, к которому привязываются критерии приёмки, пользовательские сценарии и тест-кейсы[2].[4]
  • Критерии приёмки — связываются с функциональными требованиями для обеспечения прослеживаемости от исходных целей до оценки готового продукта[2].
  • Варианты использования (пользовательские сценарии) — применяются для проверки соответствия бизнес-требований функциональным[4].[5]
  • Сценарии тестирования (тест-кейсы) — проверяют реализацию связанных требований, позволяя выявить непокрытые или избыточные элементы системы[4].[5]

Для прослеживания нефункциональных требований (NFR) и метрик качества (например, производительности или безопасности) в матрице используются специальные колонки, связывающие требования с конкретными показателями мониторинга (SLI) или алертами[6]. Например, требование к производительности может фиксироваться через метрику в колонке мониторинга, а требование к безопасности — через соответствующий алерт.

Пример матрицы трассируемости

Согласно современным стандартам, шаблон матрицы трассируемости (RTM) включает столбцы, покрывающие все ключевые аспекты разработки:[7]

Идентификатор (Requirement ID) Описание требования (Requirement statement) Источник (Source) Бизнес-владелец Приоритет Рабочий элемент (Deliverable/Code ID) Критерии приёмки (Acceptance criteria) Метод проверки Статус История изменений
REQ-014 Менеджеры должны одобрять счета подрядчиков на сумму свыше 2500 долларов до того, как финансовый отдел произведёт оплату. Финансовая политика и ТЗ подрядчика Руководитель финансовых операций Обязательно Процесс утверждения счетов с пороговой суммой Тестовый счёт направляется менеджеру, фиксирует одобрение и блокирует оплату до утверждения Сценарий UAT Готово к UAT -

В матрице трассируемости для нефункциональных требований (NFR) рекомендуется использовать идентификаторы, состоящие из префикса категории и порядкового номера (например, NFR-PERF-001, NFR-SEC-002)[8]. Примеры кодировки:

  • Производительность (Performance) — NFR-PERF
  • Безопасность (Security) — NFR-SEC
  • Доступность (Accessibility) — NFR-ACCESS

Применение

Матрица трассируемости требований может использоваться для проверки соответствия текущих требований к проекту, а также для создания запроса на предложение, спецификации программных требований[9], различных проектных документов и задач плана проекта[10].

При адаптации для гибких методологий разработки (Agile) матрица интегрируется в стандартный рабочий процесс через таск-трекеры, что позволяет избежать избыточной бюрократии. В такой среде высокоуровневые требования напрямую связываются с пользовательскими историями (User Stories), конкретными задачами спринта и сценариями тестирования. Критерии готовности (Definition of Done) встраиваются непосредственно в задачи в виде критериев приёмки[11].

В разработке критически важного программного обеспечения матрица трассируемости является обязательным инструментом для подтверждения безопасности и соответствия отраслевым стандартам[12][13]:

  • По стандарту DO-178C требуется обязательная двунаправленная трассировка между системными, высокоуровневыми (HLR) и низкоуровневыми (LLR) требованиями, исходным кодом и тестами. Матрица должна доказывать, что каждое требование верифицировано, а в сертифицируемой сборке отсутствует недокументированный или неиспользуемый код[12].[13]
  • По стандарту ISO 26262 строгость двунаправленной трассировки зависит от уровня полноты безопасности (ASIL). Для наивысшего уровня (ASIL D) матрица обеспечивает сквозную связь между анализом рисков (HARA), целями безопасности, функциональными и техническими требованиями, архитектурой, реализацией и результатами верификации[14].[15]

Автоматизация и современные подходы

Ручное ведение матрицы трассируемости (например, в таблицах Excel) часто приводит к ошибкам из-за человеческого фактора, рассинхронизации данных и быстрого устаревания информации. Подобные таблицы изолированы от трекеров задач и систем тестирования, а одновременная работа нескольких пользователей вызывает конфликты версий. В современных DevOps-практиках статичные таблицы заменяются интегрированными платформами, где матрица строится динамически на основе связей между объектами. Сквозная трассируемость обеспечивается автоматическим связыванием требований с рабочими элементами, ветками кода, коммитами, pull-реквестами, сборками и релизами[2].[16][17]

Методы связывания требований с исходным кодом (Requirement-to-Code) интегрируют трассируемость непосредственно в системы контроля версий (например, Git и GitHub) и архитектуру проектов. Требования могут генерироваться в виде нативных артефактов языка программирования, на которые разработчики ссылаются в коде и тестах. При изменении или удалении требования используются механизмы аннотаций языка (например, @Deprecated), что позволяет выявлять устаревшие связи на этапе сборки и компиляции[17].[18]

Современные системы управления тестированием (TMS) предлагают широкие возможности автоматизации работы с требованиями. Среди них — генерация тест-кейсов и шагов тестирования из требований с помощью искусственного интеллекта, автономная оркестрация тестов, создание скриптов автоматизации и интеграция с рабочими средами разработчиков[19].[20]

Для визуализации данных трассируемости применяются как усовершенствованные табличные форматы, так и графовые модели. В табличном виде используются интерактивные ячейки на пересечении требований и тест-кейсов для быстрого перехода к деталям, а также фильтры и индикаторы состояния для отображения метрик покрытия[21]. В качестве альтернативы применяются карты зависимостей и графы (с использованием таких инструментов, как Neo4j, Graphviz, Gephi или D3.js), которые обеспечивают интерактивную визуализацию, динамическую фильтрацию и анализ сложных связей[22].[23]

Примечания

  1. ↑ All About Requirements Traceability Matrix. Cloudfresh. Дата обращения: 27 августа 2026.
  2. ↑ 1 2 3 4 5 6 7 8 9 Матрица трассируемости требований (RTM): что это, зачем нужна и как составить. SimpleOne. Дата обращения: 27 августа 2026.
  3. ↑ 1 2 3 Матрица трассируемости требований (RTM): что это, зачем нужна и как составить. QARocks. Дата обращения: 27 августа 2026.
  4. ↑ 1 2 3 4 5 Матрица отслеживания требований (Requirements Traceability Matrix): что это и зачем нужно. Управление проектами. Дата обращения: 27 августа 2026.
  5. ↑ 1 2 3 Шаблон матрицы трассировки требований. datafinder.ru. Дата обращения: 27 августа 2026.
  6. ↑ Модуль 15. Структура требований и трассируемость. datafinder.ru. Дата обращения: 27 августа 2026.
  7. ↑ Requirements Traceability Matrix Template: The Ultimate Guide. WorkHint Blog (23 августа 2023). Дата обращения: 27 августа 2026.
  8. ↑ Non-Functional Requirements. Better Software (15 января 2022). Дата обращения: 27 августа 2026.
  9. ↑ DI-IPSC-81433A, DATA ITEM DESCRIPTION SOFTWARE REQUIREMENTS SPECIFICATION (SRS). everyspec.com (15 декабря 1999). Дата обращения: 4 апреля 2013. Архивировано 20 сентября 2025 года.
  10. ↑ Carlos, Tom. Requirements Traceability Matrix – RTM (англ.), PM Hut (21 октября 2008). Архивировано 13 февраля 2009 года. Дата обращения: 27 августа 2026.
  11. ↑ Адаптация RTM для Agile-команд. Atlassian. Дата обращения: 27 августа 2026.
  12. ↑ 1 2 DO-178C Requirements Traceability. RTMify. Дата обращения: 27 августа 2026.
  13. ↑ 1 2 Bidirectional Traceability Guide. Jama Software. Дата обращения: 27 августа 2026.
  14. ↑ Traceability in Compliance Projects. Trace.Space. Дата обращения: 27 августа 2026.
  15. ↑ Requirements Traceability Matrix. Perforce. Дата обращения: 27 августа 2026.
  16. ↑ Трассировка требований. Devprom. Дата обращения: 27 августа 2026.
  17. ↑ 1 2 End-to-end traceability. Microsoft Learn. Дата обращения: 27 августа 2026.
  18. ↑ ReqToCode: Making Requirements Traceability an Intrinsic Property of the Codebase. arXiv. Дата обращения: 27 августа 2026.
  19. ↑ Top 10 Test Management Tools in 2026. TestCollab. Дата обращения: 27 августа 2026.
  20. ↑ Best Test Management Tools in 2026. QA Sphere. Дата обращения: 27 августа 2026.
  21. ↑ Матрица трассировки требований в DoQA. DoQA. Дата обращения: 27 августа 2026.
  22. ↑ Requirements Traceability Analysis with Neo4j. ReqView. Дата обращения: 27 августа 2026.
  23. ↑ Dependency Graph Visualization. Tom Sawyer Software. Дата обращения: 27 августа 2026.

Литература

  • Gotel, Orlena; Cleland-Huang, Jane; Hayes, Jane Huffman; Zisman, Andrea; Egyed, Alexander; Grünbacher, Paul; Dekhtyar, Alex; Antoniol, Giuliano; Maletic, Jonathan. Software and Systems Traceability. Springer London, 2012. ISBN 9781447122388. doi:10.1007/978-1-4471-2239-5_1.

Ссылки

Категории

Pause