--- 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. Алгоритм: 1. Определить **тип требования**: `business` / `stakeholder` / `solution` / `transition` 2. Задать вопрос: **откуда оно взялось?** → найти родителя для `derives`-связи 3. Задать вопрос: **из чего оно следует или что требует?** → горизонтальные `depends` 4. Задать вопрос: **какой компонент это реализует?** (если уже известно) → `satisfies` 5. Задать вопрос: **какой тест это проверяет?** (если уже известно) → `verifies` 6. Вызвать `add_trace_link` для каждой связи 7. Если репозиторий создаётся впервые → сначала `init_traceability_repo` > 📌 Если ответа на вопросы 4-5 нет — это нормально. Связи `satisfies` и `verifies` > добавляются позже. Orphan-требование без `satisfies`/`verifies` — это ожидаемое > состояние на ранних этапах. Orphan без `derives` — это уже проблема. ### Режим B — Поддержание трассировки (изменение требования) **Когда:** требование обновилось (версия, статус, содержание). Алгоритм: 1. Обновить запись требования: новая версия, новый статус 2. Вызвать `run_impact_analysis` — получить список всех затронутых артефактов 3. Для каждого затронутого артефакта: актуальна ли связь? - Если связь устарела → обновить `rationale` или удалить через `add_trace_link` с флагом `remove` - Если появились новые связи → добавить 4. Если изменение пришло как CR → результат `run_impact_analysis` передаётся в 5.4 для экспертной оценки: брать/не брать, какова цена > ⚠️ Режим B — самая частая причина «мёртвой трассировки». BA обновляет требование, > но забывает обновить граф. Claude должен напомнить: «это требование изменилось — > нужно проверить связи». ### Режим C — Аудит покрытия **Когда:** перед приоритизацией (5.3), перед утверждением (5.5), после серии CR. Алгоритм: 1. Вызвать `check_coverage` 2. Интерпретировать результаты: - 🔴 **Orphan без источника** → выяснить бизнес-обоснование или заморозить - 🟡 **Нет реализации** → уточнить у разработчика или добавить в backlog - 🟡 **Нет теста** → уточнить у QA или создать тест - 🟢 **Полное покрытие** → готово к следующему шагу 3. Принять решение по каждому проблемному требованию 4. При необходимости → `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` как технический input - `5.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 — сохранить исходное состояние ```