| name | requirements_maintain |
| description | Скилл BABOK 5.2 — Поддержка требований. Используй этот скилл когда BA хочет обновить атрибуты требования, депрекировать устаревшие требования, проверить здоровье реестра или найти кандидатов на повторное использование в новом проекте. Триггеры: «обновить требование», «maintain requirements», «депрекировать», «здоровье требований», «requirements health», «reuse», «повторное использование».
|
| 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.2 — Maintain Requirements
Задача: поддержание актуальности требований и их атрибутов на протяжении жизненного цикла.
MCP-сервер: requirements_maintain_mcp.py
Reference: references/lifecycle_guide.md
Суть задачи
5.1 построил граф связей. 5.2 — не даёт этому графу и самим требованиям протухнуть.
Требования живут, меняются, стареют. Задача BA — быть «смотрителем» реестра:
обновлять статусы, версии, атрибуты, помечать устаревшее, выявлять кандидатов
на повторное использование. И делать это регулярно, не только при CR.
Три элемента по BABOK:
- Поддержание содержания — требование остаётся корректным и актуальным
- Поддержание атрибутов — метаданные актуальны даже если содержание не менялось
- Повторное использование — требования доступны и понятны для других инициатив
Когда активируется этот скилл
- Изменился статус требования (confirmed → approved, approved → on_hold...)
- Требование устарело или заменено другим → нужно пометить deprecated/superseded
- Пришёл CR → нужно обновить версии затронутых требований (после 5.4)
- Перед приоритизацией (5.3) → нужна актуальность атрибутов priority и stability
- Перед утверждением (5.5) → нужен чистый реестр без мусора
- BA хочет найти требования для повторного использования в новой инициативе
- Регулярный аудит «здоровья» реестра
Четыре режима работы
Режим A — Обновление требования или атрибутов
Когда: изменился статус, приоритет, owner, формулировка, или любой атрибут.
Алгоритм:
- Определить что изменилось: содержание или только атрибут?
- Если содержание → новая версия (1.0 → 1.1 или 2.0)
- Если только атрибут (статус, приоритет) → версия не меняется
- Вызвать
update_requirement — обновит атрибуты, запишет в историю
- Если изменение пришло из CR → предварительно выполнить
run_impact_analysis (5.1)
📌 Правило версионности:
Minor (1.0→1.1): уточнение формулировки, изменение критериев приёмки
Major (1.0→2.0): изменение сути, слияние или разделение требований
Подробнее: references/lifecycle_guide.md → «Версионность»
Режим B — Deprecation (устаревание/замена)
Когда: требование больше не актуально, или заменено другим.
Алгоритм:
- Определить причину: устарело само по себе? Заменено другим? CR его убрал?
- Выбрать правильный финальный статус:
deprecated — устарело, нет заменыsuperseded — заменено другим требованием (указать чем)retired — проект завершён, требование в архив
- Вызвать
deprecate_requirements — пометит и запишет причину в историю
- Проверить в 5.1: нет ли активных связей с deprecated требованием
⚠️ Deprecated требование не удаляется из репозитория — только помечается.
История должна быть сохранена для аудита и трассировки.
Режим C — Аудит здоровья реестра
Когда: перед 5.3 (приоритизация), перед 5.5 (утверждение), регулярно раз в спринт/этап.
Алгоритм:
- Вызвать
check_requirements_health
- Интерпретировать результаты:
- 🔴 Высокая волатильность → выяснить первопричину у стейкхолдера
- 🟡 Давно не обновлялись → проверить актуальность у owner
- 🟡 Долго в draft → либо подтвердить, либо заморозить
- 🟢 Здоровые требования → готовы к следующему шагу
- По каждой проблеме принять решение: обновить, заморозить, deprecated
Режим D — Повторное использование
Когда: начинается новая инициатива, или BA ищет готовые требования.
Алгоритм:
- Вызвать
find_reusable_requirements с фильтром по типу или теме
- Для каждого кандидата проверить:
- Сформулировано без привязки к конкретной системе/подразделению?
- Статус
approved или implemented?
- Низкая волатильность (версия ≤ 1.1)?
- Стейкхолдеры проверяют отобранные требования перед включением в новую инициативу
- При включении → создать новую запись с
source указывающим на оригинал
📌 Чем выше уровень абстракции — тем лучше для reuse.
Требование «Пользователь должен авторизоваться» → enterprise-уровень.
«Кнопка входа в SAP модуле X» → только эта инициатива.
Атрибуты требования — минимальный набор
| Атрибут | Обязателен | Кто заполняет | Когда меняется |
|---|
status | Всегда | BA | При каждом переходе |
version | Всегда | BA | При изменении содержания |
source | Всегда | BA | Один раз при создании |
priority | Standard+ | BA (после 5.3) | При приоритизации и CR |
owner | Standard+ | BA | При назначении/смене |
stability | Standard+ | BA / автоматически | Пересчитывается по версиям |
reuse_candidate | Standard+ | BA | При выявлении или аудите |
reuse_scope | Full | BA | При маркировке reuse |
complexity | Full | BA | При первичном анализе |
Полное описание атрибутов: references/lifecycle_guide.md → «Атрибуты требования»
Интеграция с другими задачами
Откуда приходят обновления:
4.3 → status: confirmed (после внутренней проверки BA)5.1 run_impact_analysis → список затронутых требований при CR5.3 → обновлённые приоритеты5.4 → решение по CR: какие требования меняются, какие deprecated5.5 → status: approved после формального согласования
Куда уходят результаты:
5.3 — актуальные stability и priority для правильной приоритизации5.5 — чистый реестр для пакета согласования6.x — reuse-кандидаты для User Stories и Use CasesConfluence — через хук экспорта (после подключения integrations/confluence_mcp.py)
Хуки для внешних хранилищ
После каждого обновления требований MCP вызывает хук экспорта.
Пока integrations/confluence_mcp.py не подключён — хук возвращает local_only.
После подключения — автоматически синхронизирует с Confluence.
Подключение интеграции не требует изменений в 5.2 — только добавить модуль.
MCP-инструменты
| Инструмент | Режим | Когда вызывать |
|---|
update_requirement | A | Изменился статус, версия, атрибуты |
deprecate_requirements | B | Требование устарело или заменено |
check_requirements_health | C | Аудит перед 5.3, 5.5, после серии CR |
find_reusable_requirements | D | Новая инициатива, поиск готовых требований |
Чего 5.2 НЕ делает
- Не приоритизирует — это 5.3 (но поддерживает атрибут
priority)
- Не оценивает CR — это 5.4 (но обновляет требования по результату)
- Не утверждает формально — это 5.5 (но готовит реестр к утверждению)
- Не строит граф связей — это 5.1 (но работает с тем же репозиторием)
- Не публикует в Confluence напрямую — это
integrations/confluence_mcp.py
