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

Требование меняется в пятницу вечером. Заказчик просит присылать статус заказа ещё и в SMS — почты мало. Тимлид задаёт нормальный вопрос: что сломается? И оказывается, что ответить некому. Аналитик помнит про письмо, тестировщик — про свои кейсы, разработчик — про сервис, который дёргает шлюз. Целиком картинку не держит в голове никто.

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

На собеседовании про неё спрашивают часто, а отвечают обычно половиной: «таблица, где требования сопоставлены с тестами». Это правда. Но это самая скучная её половина, и по ней сразу слышно, что человек матрицу видел на слайде, а не вёл.

Что она связывает на самом деле

Определение из ISO/IEC/IEEE 29148:2018 — международного стандарта по работе с требованиями — звучит сухо, зато точно: трассируемость это идентификация и документирование пути вывода вверх и пути распределения вниз внутри набора требований. Требование, из которого выведено другое, стандарт зовёт родительским, выведенное — дочерним.

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

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

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

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

Матрица — не отчётность для галочки. Это единственное место, где на вопрос «что сломается» отвечают за минуту, а не за день.

Пример: пять строк, с которых можно начать

Интернет-магазин. Цель квартала — разгрузить поддержку: слишком много обращений «где мой заказ».

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

Вернёмся к пятничной просьбе про SMS. Смотришь строку FR-13: вверх от неё SH-4, вниз — шаблон письма и один тест. Значит, добавляется брат FR-13, а не правка FR-12; экран не трогаем, NFR-3 про пять минут остаётся в силе и распространяется на новый канал. Ответ тимлиду занял минуту.

Обрати внимание на строку BG-1. В колонке реализации пусто — и это нормально: бизнес-цель не реализуют кодом, её проверяют метрикой. Пустая клетка здесь означает не дыру, а границу.

Что о трассировке говорит BABOK

В BABOK трассировка — не приём, а отдельная задача: 5.1 Trace Requirements в области знаний «Управление жизненным циклом требований». Там же названы типы отношений. Их ровно четыре: derive, depends, satisfy и validate.

• Derive — одно требование выведено из другого, между ними разные уровни абстракции. FR-12 выведено из SH-4.
• Depends — требование зависит от другого. Два подвида: necessity, когда реализовывать его в одиночку бессмысленно, и effort, когда можно, но вместе дешевле.
• Satisfy — связь элемента реализации с требованием, которое он закрывает. Сервис статусов закрывает FR-12.
• Validate — связь требования с тест-кейсом, который подтверждает, что решение требованию отвечает.

Разница между necessity и effort — вопрос на уровень глубже, и на нём обычно видно, вёл человек трассировку или пересказывает главу.

Сам свод смотрит на трассировку шире, чем «связать требование с тестом». Задача 5.1 нужна ему, чтобы управлять объёмом работ и риском его расползания, находить пробелы, оценивать влияние изменений, понимать статус каждого требования и распределять требования по релизам и компонентам. Это инструмент управления, а не документирования.

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

Инструменты свод не называет вовсе, и это осознанно. Про хранилище трассируемости сказано ровно одно: в сложных случаях его автоматизируют. Третья редакция вышла в 2015 году и до сих пор актуальна — ждать от неё списка современных систем бессмысленно, она задаёт правила, а не продукты.

Про сам свод знаний и то, зачем он аналитику, — в статье Что такое BABOK и как мы его используем.

Что она ловит

Три вещи, ради которых её заводят.

Сирот. Требование без единой связи вниз — никто не реализовал и никто не проверил. Тест-кейс без связи вверх — тестируем то, чего не просили. Стандарт предлагает это даже мерить: доля родителей без детей и среднее число дочерних требований на родителя, где второе — индикатор сложности дизайна. В нашей таблице сироту видно глазами: если бы у FR-13 в колонке проверки было пусто, письмо о смене статуса ушло бы в релиз непротестированным, и заметили бы это клиенты.

Влияние изменений. Та самая пятница с SMS. Без матрицы вопрос «что сломается» превращается в опрос трёх человек и всё равно заканчивается словом «вроде».

Покрытие. Когда заказчик через полгода спрашивает «а это вы сделали?», матрица отвечает строкой, а не воспоминаниями команды.

Сколько это стоит и когда не надо

Теперь честная часть, которую проговаривают редко. Связи не появляются сами и не поддерживаются сами. Каждая новая строка — работа, которую кто-то делает вручную и потом обновляет при каждом изменении.

Чем сложнее сеть связей, тем дороже её держать живой — ровно поэтому свод и требует определить уровень формальности заранее, а не по ходу дела. Решение принимается один раз и осознанно: что трассируем, до какого уровня, чем.

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

С чего начать, если матрицы нет

Не начинай с истории. Восстановить связи по трём годам разработки нельзя: попытка съест месяц и закончится ничем.

Возьми ближайший релиз. Выпиши его требования с идентификаторами — просто пронумеруй, если номеров не было. Каждому проставь источник: чья это потребность и из какого решения выросла. Потом — чем проверяется. Всё, матрица есть.

Дальше начнётся интересное: часть клеток останется пустой. Это не провал упражнения, это его результат. Пустая клетка в колонке источника означает требование, которое непонятно зачем. Пустая в колонке проверки — то, что уедет в прод непроверенным. С этими двумя списками уже можно идти на встречу команды, и разговор там будет предметный.

Как это делается сегодня: трассировка с моделью

Самая скучная часть трассировки — не думать, а сопоставлять. Шестьдесят требований, двести тест-кейсов, и надо понять, что с чем связано. Именно здесь языковая модель экономит часы, а не изображает интеллект.

Три приёма, которые действительно работают.

Первичное сопоставление. Даёшь модели список требований и список тест-кейсов, просишь связать и вернуть две таблицы: что сопоставилось и что нет. Ценность — во второй. Это готовый список кандидатов в сироты, который вручную собирался бы полдня.

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

Черновик анализа влияния. «Меняем FR-13, вот матрица — что затронуто?» На выходе список кандидатов, который ты проверяешь глазами. Минуты вместо переписки с тремя коллегами.

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

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

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

Почему я трассирую не только требования

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

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

Со статьями то же самое. У нас есть правило: тема без реального поискового запроса на сайт не идёт. Запрос записан в самом файле статьи — рядом с текстом, а не в чьей-то голове. Эта статья тоже написана под конкретный запрос, и через три месяца можно будет открыть замер и проверить, сработало ли. Пустая клетка «зачем» здесь означает то же, что и в проекте: работу, которую делают по инерции.

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

Как это звучит на собеседовании

Слабый ответ — «таблица, где требования сопоставлены с тестами». Формально верно, дальше разговор не идёт.

Сильный короче, чем кажется: связь вверх и вниз, один пример из своего проекта, четыре типа связей, если спросят глубже. И отдельно ценится честное «на последнем проекте мы её не вели, потому что команда была из четырёх человек и всё держалось в Jira». Это ответ практика, а не пересказ главы.