| name | requirements_assess_changes |
| description | Скилл BABOK 5.4 — Оценка изменений требований (Change Request). Используй этот скилл когда поступил запрос на изменение требований: нужно оценить impact, провести анализ последствий, проскорить CR и сформировать рекомендацию (Approve/Defer/Reject). Триггеры: «change request», «CR», «запрос на изменение», «impact analysis», «оценка изменений», «assess change», «изменение требований», «новый CR».
|
| 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.4 — Assess Requirements Changes
Задача: оценка последствий предлагаемого изменения требований и дизайнов (Change Request).
MCP-сервер: requirements_assess_changes_mcp.py
Reference: references/cr_assessment_guide.md
Суть задачи
5.4 — привратник изменений. Каждый CR проходит через четыре шага:
open_cr → run_cr_impact → score_cr → resolve_cr
Что делает BA в 5.4:
- Регистрирует CR и определяет уровень формальности
- Анализирует влияние через граф трассировки 5.1
- Оценивает CR по пяти осям (Benefit / Cost / Impact / Schedule / Urgency)
- Получает рекомендацию и передаёт на решение уполномоченному стейкхолдеру
- Фиксирует решение с rationale, обновляет статусы требований
Что 5.4 НЕ делает:
- Не принимает финальное решение — только даёт рекомендацию
- Не вносит изменения в содержание требований (это BA через 5.2 после Approved)
- Не переприоритизирует требования (это 5.3 — запустить после resolve_cr)
- Не согласовывает требования формально (это 5.5)
Результат 5.4: CR Decision Record → уходит в 4.4 (коммуникация) и 5.5 (аудит).
Входы из других задач
| Задача | Что даёт |
|---|
| 5.1 | Граф трассировки → BFS-обход для impact analysis |
| 5.2 | Стабильность требований → флаги риска для волатильных |
| 5.3 | Приоритеты → проверка конфликтов CR с Must/Won't |
| 3.3 | Governance approach → кто уполномочен принимать решения по CR |
| 4.5 | Decision Log → куда записывается финальное решение |
Когда активируется этот скилл
- Стейкхолдер запрашивает добавление новой функциональности
- Обнаружено изменение бизнес-стратегии или скоупа
- Изменились законодательные/нормативные требования
- Разработчик выявил техническое ограничение, требующее пересмотра требований
- Появились новые данные меняющие понимание бизнес-потребности
- Тестирование выявило несоответствие требований реальности
Четыре шага pipeline
Шаг 1 — Открыть CR (open_cr)
Когда: получен запрос на изменение, нужно его зарегистрировать.
Алгоритм:
- Определить тип изменения: новое требование / изменение существующего / удаление / архитектурное
- Определить инициатора и затронутые области
- Определить уровень формальности (читай
references/cr_assessment_guide.md → «Формальность оценки»):
- Predictive + близко к релизу → высокая формальность
- Agile + начало итерации → стандартная
- Регуляторный CR → всегда высокая, Urgency = Critical автоматически
- Вызвать
open_cr
Результат: CR зарегистрирован как узел в репозитории 5.1, статус open.
📌 CR — новый тип узла в репозитории 5.1. Связывается с затронутыми требованиями
через связь типа modifies (добавляется в run_cr_impact).
Шаг 2 — Анализ влияния (run_cr_impact)
Когда: CR открыт, нужно понять масштаб изменения.
Алгоритм:
- Вызвать
run_cr_impact с ID CR и списком целевых требований
- Инструмент выполняет BFS-обход графа 5.1 от каждого целевого требования
- Изучить результат:
- Список затронутых требований по типам связей
depends → что потеряет смыслverifies → какие тесты нужно переписатьsatisfies → какой код нужно переделатьderives → какие дочерние требования затронуты
- Проверить: есть ли среди затронутых требования без трассировки к BR?
- Проверить: есть ли среди затронутых волатильные требования (из 5.2)?
📌 Если масштаб неожиданно большой — сообщи инициатору до score_cr.
Многие CR снимаются с рассмотрения именно на этом шаге.
Шаг 3 — Скоринг CR (score_cr)
Когда: impact analysis завершён, известен реальный масштаб.
Алгоритм:
- Технические оси заполнены автоматически (Impact + Schedule из шага 2)
- Ввести бизнес-оси вручную:
- Benefit: High / Medium / Low — что получает бизнес?
- Cost: Low / Medium / High — полная стоимость включая альтернативные затраты
- Urgency: Critical / High / Normal — насколько срочно?
- Вызвать
score_cr
- Получить:
- Числовой CR Score и предварительный вердикт (Approve/Modify/Defer/Reject)
- Текстовое обоснование Claude с учётом контекста
- Автоматические проверки (трассировка к потребности, конфликты с приоритетами)
Шкала скоринга:
- ≥ 8.0 → ✅ Approve
- 4.0–7.9 → 🟡 Modify
- 1.0–3.9 → ⏳ Defer
- < 1.0 → ❌ Reject
📌 Формула — предварительный вердикт. Claude может скорректировать
с явной причиной. BA принимает финальное решение о том, что передать на одобрение.
Справка по осям: references/cr_assessment_guide.md → «Пять осей анализа влияния»
Шаг 4 — Зафиксировать решение (resolve_cr)
Когда: решение принято уполномоченным стейкхолдером.
Алгоритм:
- Получить решение от уполномоченного (из governance 3.3)
- Вызвать
resolve_cr с параметрами:
decision: Approved / Approved_with_Modification / Deferred / Rejecteddecided_by: кто принял решениеrationale: обоснование (обязательно — для аудита)
- Инструмент автоматически:
- При Approved: меняет статус затронутых требований на
under_change
- Генерирует CR Decision Record (Markdown) →
save_artifact
- Обновляет статус CR-узла в репозитории 5.1
- После Approved: обновить содержание требований через
update_requirement (5.2)
- После Approved: запустить
start_prioritization_session (5.3) если приоритеты затронуты
- CR Decision Record отправить через
prepare_communication_package (4.4)
📌 Rejected и Deferred CR не удаляются из репозитория.
История CR — часть audit trail проекта.
MCP-инструменты
| Инструмент | Шаг | Что делает |
|---|
open_cr | 1 | Зарегистрировать CR в репозитории 5.1 |
run_cr_impact | 2 | BFS-обход графа, построить список затронутых, создать modifies-связи |
score_cr | 3 | Рассчитать CR Score, получить рекомендацию + автопроверки |
resolve_cr | 4 | Зафиксировать решение, обновить статусы, сгенерировать Decision Record |
Mapping из 5.1 — типы связей при impact analysis
| Тип связи | Что означает при CR |
|---|
depends | Зависимое требование может потерять смысл |
verifies | Тест-кейсы нужно пересмотреть/переписать |
satisfies | Компонент кода нужно переделать |
derives | Дочерние требования могут унаследовать изменение |
modifies | Прямая связь CR → изменяемое требование (создаётся в шаге 2) |
Mapping из 5.2 — стабильность как фактор риска
| Stability (из 5.2) | Поведение в 5.4 |
|---|
Stable (версия < 1.3) | Без дополнительных флагов |
Volatile (версия 1.3) | 🟡 Предупреждение: нестабильное требование + CR = двойная неопределённость |
Volatile (версия ≥ 1.4) | 🔴 Высокий риск: рекомендуется стабилизировать требование перед CR |
Типичные вопросы BA
«CR маленький — нужно ли проходить все четыре шага?»
Да — все четыре шага. Для малого CR pipeline проходится быстро.
Impact часто оказывается больше ожидаемого — граф это покажет.
«Кто может быть decided_by?»
Определяется в задаче 3.3 (Governance). Обычно: Спонсор, Product Owner, или CCB.
Если unclear — уточни у Project Manager.
«Что делать если несколько CR затрагивают одни и те же требования?»
Оценивать совместно: передай related_cr_ids в open_cr.
Суммарный impact может быть нелинейным — лучше видеть картину целиком.
«После Approved CR — когда обновлять требования в 5.2?»
Сразу после resolve_cr. Статус under_change означает «требование в процессе изменения».
Не оставляй требования в under_change дольше одной итерации.
«Нужно ли переприоритизировать после CR?»
Если CR меняет Must/Won't или добавляет новые требования — да, запускай 5.3.
resolve_cr явно укажет если обнаружены конфликты с приоритетами.
