Трассировка требований

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

Кейс: что затронет сдвиг правила отмены

Владелец «Узелка» просит изменить правило отмены заказа: разрешить её не только до передачи курьеру, но и в течение короткого времени после. Команда оформила запрос на изменение (статья 02-20), и первый вопрос звучит просто: что именно придётся менять? Одни вспоминают задачу по кнопке отмены, другие помнят про сообщение об отказе, про возврат оплаты никто не уверен. Тест на отмену есть, но подходит ли он под новое правило, непонятно. (Правило, номера и состав задач в примере условные: мы взяли их для иллюстрации.)

Если бы связи между целью, требованием, задачей и тестом были записаны, ответ нашёлся бы за минуту. Такая запись называется трассировкой.

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

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

В нашем примере цепочка такая. Цель Ц-1 «Покупатель сам отменяет заказ» уточняется требованием ФТ-12 «Отмена до передачи курьеру». Требование реализуется задачей ЗД-48 «Кнопка отмены и проверка статуса» и проверяется тестом ТК-31. Если одно звено потеряно, цепочка рвётся, и мы не можем сказать, всё ли учтено.

Матрица трассировки

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

Для небольшой команды можно ограничиться меньшим набором: требование, цель, задача, тест и статус. В примере три требования «Узелка». ФТ-12 имеет задачу и тест, и мы видим статус «покрыто». У ФТ-13 есть задача, но нет теста: требование «Сообщение об отказе в отмене» пока ничем не проверяется. Для ФТ-14 пока нет ни задачи, ни теста: о возврате оплаты при отмене ещё только договорились.

Главная польза матрицы в пустых ячейках. Они показывают, где требование ещё не превращено в работу или не проверяется.

Два направления

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

• Прямая трассировка идёт от требования к задаче и тесту. Вопрос: сделано ли и проверено ли требование.
• Обратная трассировка идёт от задачи или теста к требованию и цели. Вопрос: зачем это сделано.

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

В нашем случае задача ЗД-52, у которой нет требования, повод спросить: зачем её взяли в работу.

Как вести матрицу без лишней бюрократии

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

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

Матрица нужна для проверки полноты, а не для отчёта ради отчёта. Если по ней никто не принимает решений, её ведение становится лишним.

Что даёт трассировка при изменениях и приёмке

При изменении требования по строке матрицы видно, что затронуто: какие задачи нужно пересмотреть и какие тесты обновить. Так анализ влияния из статьи 02-20 занимает минуты, а не часы поиска по переписке. Трассировка улучшает понимание того, как изменение требований влияет на другие продукты.

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

Где это встречается в работе

• Анализ влияния запроса на изменение (статья 02-20).
• Подготовка к приёмке: проверка, что все требования покрыты тестами.
• Планирование релиза: видно, какие требования уже превращены в задачи.
• Разбор спорной функции: по обратной трассировке понятно, откуда она взялась.
• Аудит и регуляторные проверки в проектах, где нужно доказать выполнение требований.

Итог

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

Что дальше

Дальше разберём, как разбить крупную задачу на небольшие и оценить их (статья 02-23), и как вывести тест-кейсы из требований (статья 02-25).