| name | requirements_traceability |
| description | Скилл BABOK 5.1 — Трассировка требований. Используй этот скилл когда BA хочет построить или обновить граф связей между артефактами проекта, добавить трассировочную ссылку, провести impact analysis или экспортировать матрицу трассировки. Триггеры: «трассировка», «trace requirements», «traceability matrix», «связи требований», «impact analysis», «откуда это требование», «coverage», «граф требований».
|
| project | AI-powered Platform AInalyst (AI Платформа AIналитик) |
| copyright | Copyright (c) 2026 Anatoly Chaussky. Licensed under AGPL v3. Commercial licensing: chaussky@gmail.com |
SKILL: BABOK 5.1 — Trace Requirements
Задача: управление трассировкой требований на протяжении жизненного цикла.
MCP-сервер: requirements_traceability_mcp.py
Reference: references/traceability_guide.md
Суть задачи
Трассировка — это граф связей между всеми артефактами проекта.
Бизнес-потребность
└─[derives]→ Бизнес-требование (BR)
└─[derives]→ Требование стейкхолдера (SR)
└─[derives]→ Требование к решению (FR/NFR)
├─[satisfies]← Компонент / модуль
└─[verifies]← Тест (TC)
Плюс горизонтальные связи: depends между требованиями одного уровня.
Главная ценность: когда приходит CR или требование меняется — BA мгновенно
видит что затронуто: какие требования, тесты, компоненты. Без трассировки — гадание.
Когда активируется этот скилл
- BA добавляет новое требование в проект
- Требование изменилось (CR или уточнение)
- Нужно оценить влияние изменения (→ передаётся в 5.4)
- Нужно проверить покрытие перед приоритизацией (5.3) или утверждением (5.5)
- Запрос на матрицу трассировки для стейкхолдеров или аудита
Три режима работы
Режим A — Первичная трассировка нового требования
Когда: получено подтверждённое требование из 4.3 или новое требование при CR.
Алгоритм:
- Определить тип требования:
business / stakeholder / solution / transition
- Задать вопрос: откуда оно взялось? → найти родителя для
derives-связи
- Задать вопрос: из чего оно следует или что требует? → горизонтальные
depends
- Задать вопрос: какой компонент это реализует? (если уже известно) →
satisfies
- Задать вопрос: какой тест это проверяет? (если уже известно) →
verifies
- Вызвать
add_trace_link для каждой связи
- Если репозиторий создаётся впервые → сначала
init_traceability_repo
📌 Если ответа на вопросы 4-5 нет — это нормально. Связи satisfies и verifies
добавляются позже. Orphan-требование без satisfies/verifies — это ожидаемое
состояние на ранних этапах. Orphan без derives — это уже проблема.
Режим B — Поддержание трассировки (изменение требования)
Когда: требование обновилось (версия, статус, содержание).
Алгоритм:
- Обновить запись требования: новая версия, новый статус
- Вызвать
run_impact_analysis — получить список всех затронутых артефактов
- Для каждого затронутого артефакта: актуальна ли связь?
- Если связь устарела → обновить
rationale или удалить через add_trace_link с флагом remove
- Если появились новые связи → добавить
- Если изменение пришло как CR → результат
run_impact_analysis передаётся в 5.4
для экспертной оценки: брать/не брать, какова цена
⚠️ Режим B — самая частая причина «мёртвой трассировки». BA обновляет требование,
но забывает обновить граф. Claude должен напомнить: «это требование изменилось —
нужно проверить связи».
Режим C — Аудит покрытия
Когда: перед приоритизацией (5.3), перед утверждением (5.5), после серии CR.
Алгоритм:
- Вызвать
check_coverage
- Интерпретировать результаты:
- 🔴 Orphan без источника → выяснить бизнес-обоснование или заморозить
- 🟡 Нет реализации → уточнить у разработчика или добавить в backlog
- 🟡 Нет теста → уточнить у QA или создать тест
- 🟢 Полное покрытие → готово к следующему шагу
- Принять решение по каждому проблемному требованию
- При необходимости →
export_traceability_matrix для отчёта
Уровни формальности — выбери перед стартом
Если контекст проекта неизвестен — спроси BA. Правильный пресет экономит
часы ненужной работы или защищает от пропущенных связей.
| Вопрос для BA | Если ответ... | Рекомендуй |
|---|
| Есть регуляторные требования? (GDPR, ФЗ, ISO) | Да | Full |
| Внешний аудит или compliance? | Да | Full |
| Команда > 20 человек? | Да | Standard → Full |
| Есть выделенный QA? | Да | Standard |
| Agile, спринты, стартап? | Да | Lite |
BA всегда принимает финальное решение. Скилл рекомендует, не навязывает.
Прочитай детали пресетов: references/traceability_guide.md → раздел «Пресеты формальности»
Интеграция с другими задачами
Откуда приходят требования:
4.3 save_confirmed_elicitation_result → подтверждённые артефакты → добавляем в репозиторий (Режим A)4.2 save_cr_elicitation_analysis → требования при CR → обновляем трассировку (Режим B)
Mapping из 4.3 в репозиторий трассировки
Артефакт 4.3 хранит требования в структуре {functional: [...], non_functional: [...]}.
При добавлении в репозиторий трассировки конвертируй так:
| Поле в 4.3 | Поле в репозитории 5.1 |
|---|
functional[].id → FR-001 | id |
"FR" / "NFR" | type: "solution" |
functional[].statement | title |
"confirmed" (final_readiness) | status: "confirmed" |
| путь к файлу 4.3 | source_artifact |
Бизнес-требования (BR) и требования стейкхолдеров (SR) идут из ранних сессий выявления (4.2).
Их type: "business" и "stakeholder" соответственно.
Куда уходят результаты:
5.3 Приоритизация → учитывай depends-связи: нельзя приоритизировать выше зависимость5.4 Оценка изменений → передай результат run_impact_analysis как технический input5.5 Утверждение → используй export_traceability_matrix для пакета согласования6.x User Stories / Use Cases → каждый артефакт трассируется к FR/SR
MCP-инструменты
| Инструмент | Режим | Когда вызывать |
|---|
init_traceability_repo | A | Один раз при старте проекта |
add_trace_link | A, B | При каждом новом/изменённом требовании или связи |
run_impact_analysis | B | Пришло изменение, нужно понять что затронуто |
check_coverage | C | Аудит перед приоритизацией / утверждением / после CR |
export_traceability_matrix | C | Нужна матрица для стейкхолдеров или аудита |
Чего 5.1 НЕ делает
- Не приоритизирует требования — это 5.3
- Не оценивает стоит ли брать CR — это 5.4 (5.1 даёт технический input)
- Не утверждает требования формально — это 5.5
- Не создаёт требования — это 4.2/4.3
- Не управляет конфигурацией кода — это за пределами BABOK
Быстрый старт для нового проекта
1. BA передаёт подтверждённые артефакты из 4.3
2. Выбрать уровень формальности (Lite / Standard / Full)
3. init_traceability_repo — создать репозиторий
4. Для каждого требования: add_trace_link (Режим A)
5. check_coverage — убедиться что orphan-требований нет
6. export_traceability_matrix — сохранить исходное состояние
