requirements-assess-changes

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: [e-mail]

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)

Когда: получен запрос на изменение, нужно его зарегистрировать.

Алгоритм:

1. Определить тип изменения: новое требование / изменение существующего / удаление / архитектурное
2. Определить инициатора и затронутые области
3. Определить уровень формальности (читай references/cr_assessment_guide.md → «Формальность оценки»):
   • Predictive + близко к релизу → высокая формальность
   • Agile + начало итерации → стандартная
   • Регуляторный CR → всегда высокая, Urgency = Critical автоматически
4. Вызвать open_cr

Результат: CR зарегистрирован как узел в репозитории 5.1, статус open.

📌 CR — новый тип узла в репозитории 5.1. Связывается с затронутыми требованиями через связь типа modifies (добавляется в run_cr_impact).

---

Шаг 2 — Анализ влияния (run_cr_impact)

Когда: CR открыт, нужно понять масштаб изменения.

Алгоритм:

1. Вызвать run_cr_impact с ID CR и списком целевых требований
2. Инструмент выполняет BFS-обход графа 5.1 от каждого целевого требования
3. Изучить результат:
   • Список затронутых требований по типам связей
   • depends → что потеряет смысл
   • verifies → какие тесты нужно переписать
   • satisfies → какой код нужно переделать
   • derives → какие дочерние требования затронуты
4. Проверить: есть ли среди затронутых требования без трассировки к BR?
5. Проверить: есть ли среди затронутых волатильные требования (из 5.2)?

📌 Если масштаб неожиданно большой — сообщи инициатору до score_cr. Многие CR снимаются с рассмотрения именно на этом шаге.

---

Шаг 3 — Скоринг CR (score_cr)

Когда: impact analysis завершён, известен реальный масштаб.

Алгоритм:

1. Технические оси заполнены автоматически (Impact + Schedule из шага 2)
2. Ввести бизнес-оси вручную:
   • Benefit: High / Medium / Low — что получает бизнес?
   • Cost: Low / Medium / High — полная стоимость включая альтернативные затраты
   • Urgency: Critical / High / Normal — насколько срочно?
3. Вызвать score_cr
4. Получить:
   • Числовой 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)

Когда: решение принято уполномоченным стейкхолдером.

Алгоритм:

1. Получить решение от уполномоченного (из governance 3.3)
2. Вызвать resolve_cr с параметрами:
   • decision: Approved / Approved_with_Modification / Deferred / Rejected
   • decided_by: кто принял решение
   • rationale: обоснование (обязательно — для аудита)
3. Инструмент автоматически:
   • При Approved: меняет статус затронутых требований на under_change
   • Генерирует CR Decision Record (Markdown) → save_artifact
   • Обновляет статус CR-узла в репозитории 5.1
4. После Approved: обновить содержание требований через update_requirement (5.2)
5. После Approved: запустить start_prioritization_session (5.3) если приоритеты затронуты
6. 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 явно укажет если обнаружены конфликты с приоритетами.