Трассировка требований без матрицы ради матрицы: как доказать, что изменение системы решает бизнес-проблему

Фраза «сделаем интеграцию с новым провайдером» звучит как задача для разработки. Но сама по себе она ничего не говорит о результате. Как поймём, что система изменилась правильно? Как отличим выполненное требование от правдоподобной имитации? И кто примет остаточный риск, если формальные проверки зелёные, а пользовательский исход не наступил?

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

1. Начинаем с наблюдаемого исхода

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

В синтетическом кейсе Acme Pay исход можно сформулировать так: после успешной авторизации покупатель видит подтверждение заказа с тем же курсом и идентификатором, который использован при расчёте. Если запрос повторяется, система не создаёт второй заказ. Эти утверждения уже можно проверить.

Я фиксирую пять полей:

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

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

2. Сначала определяем, каким источникам можно верить

В папке проекта редко лежит один непротиворечивый документ. В примере есть официальная документация Acme Pay v2.1, старая внутренняя страница про v1, код прототипа и переписка с поддержкой.

Читать их подряд недостаточно. Для каждого источника я записываю идентификатор, дату, владельца, область действия и статус. В карте сразу видно, что S01 — базовый источник по API, S02 и S03 описывают прошлую версию, а S04 уточняет лимит частоты запросов, но не является контрактом.

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

3. Требование связываем со сценарием, а не с названием функции

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

Связь должна быть независима от реализации. Сценарий описывает границу поведения, а не конкретный класс, endpoint или промпт. Если меняется модель или библиотека, сценарий остаётся ориентиром, пока не изменился бизнес-исход.

У каждого сценария должны быть также ошибочные ветки: тайм-аут, частичный ответ, повторная доставка вебхука, отказ внешнего сервиса. Иначе happy path создаёт иллюзию покрытия. Восстановление — часть требования: нужно заранее решить, когда система повторяет действие, когда останавливается и когда зовёт человека.

4. Non-functional требования переводим в evidence

«Быстро», «надёжно» и «безопасно» — не критерии, пока не названы субъект, область и способ измерения. Для каждого NFR я задаю проверяемое свидетельство: метрику, лог, трассировку, снимок состояния или воспроизводимый тест.

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

AI-агент может собрать измерения и показать пропуски. Он не должен превращать отсутствие данных в «прошло». Для каждого уровня проверки нужен собственный знаменатель и понятная граница применимости.

5. Что делает агент и где заканчивается его право

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

Но агент не наделяет источник полномочием, не выбирает бизнес-исход и не принимает результат за пользователя. Автор реализации не должен единолично переписывать oracle или объявлять, что критерий выражает потребность. Эти решения требуют именованного владельца и явного основания.

В TDPD эта граница оформляется как последовательность проверок: актуальный контекст, покрытие evidence, сценарии, независимая верификация, затем Green и UAT. Green означает, что технические условия выполнены. UAT означает, что человек подтвердил соответствие исходной задаче.

6. Impact trace после изменения источника

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

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

Полезно различать состояния «реализовано», «проверено» и «принято». Технически зелёный тест не доказывает, что проверялось ещё действующее требование. Decision Log хранит дату, автора, альтернативы, основание и затронутые артефакты. Благодаря этому повторная приёмка имеет понятную границу.

7. Минимальная трассировка, которая выдерживает работу

Для каждой связи достаточно зафиксировать:

1. идентификатор проблемы или пользовательского исхода;
2. авторитетный источник и его область действия;
3. требование и связанный сценарий;
4. ожидаемый артефакт и проверяемые критерии;
5. ошибочные ветки и правило восстановления;
6. evidence с версией и датой;
7. нерешённые конфликты и именованного принимающего.

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

Что остаётся человеческим решением

Трассировка не отменяет анализа. Она делает его проверяемым. Человек формулирует проблему, выбирает авторитет, принимает компромисс и отвечает за остаточный риск. Агент ускоряет поиск, сборку и проверку, но не получает право незаметно изменить смысл задачи.

Если связь от бизнес-проблемы до принятого результата разорвана, статус «готово» описывает только внутреннее движение команды. Надёжная система заканчивается не зелёной галочкой, а доказательством того, что именно изменилось, почему это нужно пользователю и кто подтвердил, что этого достаточно.