--- 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:** 1. **Поддержание содержания** — требование остаётся корректным и актуальным 2. **Поддержание атрибутов** — метаданные актуальны даже если содержание не менялось 3. **Повторное использование** — требования доступны и понятны для других инициатив --- ## Когда активируется этот скилл - Изменился статус требования (confirmed → approved, approved → on_hold...) - Требование устарело или заменено другим → нужно пометить deprecated/superseded - Пришёл CR → нужно обновить версии затронутых требований (после 5.4) - Перед приоритизацией (5.3) → нужна актуальность атрибутов priority и stability - Перед утверждением (5.5) → нужен чистый реестр без мусора - BA хочет найти требования для повторного использования в новой инициативе - Регулярный аудит «здоровья» реестра --- ## Четыре режима работы ### Режим A — Обновление требования или атрибутов **Когда:** изменился статус, приоритет, owner, формулировка, или любой атрибут. Алгоритм: 1. Определить что изменилось: содержание или только атрибут? 2. Если содержание → новая версия (1.0 → 1.1 или 2.0) 3. Если только атрибут (статус, приоритет) → версия не меняется 4. Вызвать `update_requirement` — обновит атрибуты, запишет в историю 5. Если изменение пришло из CR → предварительно выполнить `run_impact_analysis` (5.1) > 📌 Правило версионности: > Minor (1.0→1.1): уточнение формулировки, изменение критериев приёмки > Major (1.0→2.0): изменение сути, слияние или разделение требований > Подробнее: `references/lifecycle_guide.md` → «Версионность» ### Режим B — Deprecation (устаревание/замена) **Когда:** требование больше не актуально, или заменено другим. Алгоритм: 1. Определить причину: устарело само по себе? Заменено другим? CR его убрал? 2. Выбрать правильный финальный статус: - `deprecated` — устарело, нет замены - `superseded` — заменено другим требованием (указать чем) - `retired` — проект завершён, требование в архив 3. Вызвать `deprecate_requirements` — пометит и запишет причину в историю 4. Проверить в 5.1: нет ли активных связей с deprecated требованием > ⚠️ Deprecated требование не удаляется из репозитория — только помечается. > История должна быть сохранена для аудита и трассировки. ### Режим C — Аудит здоровья реестра **Когда:** перед 5.3 (приоритизация), перед 5.5 (утверждение), регулярно раз в спринт/этап. Алгоритм: 1. Вызвать `check_requirements_health` 2. Интерпретировать результаты: - 🔴 Высокая волатильность → выяснить первопричину у стейкхолдера - 🟡 Давно не обновлялись → проверить актуальность у owner - 🟡 Долго в draft → либо подтвердить, либо заморозить - 🟢 Здоровые требования → готовы к следующему шагу 3. По каждой проблеме принять решение: обновить, заморозить, deprecated ### Режим D — Повторное использование **Когда:** начинается новая инициатива, или BA ищет готовые требования. Алгоритм: 1. Вызвать `find_reusable_requirements` с фильтром по типу или теме 2. Для каждого кандидата проверить: - Сформулировано без привязки к конкретной системе/подразделению? - Статус `approved` или `implemented`? - Низкая волатильность (версия ≤ 1.1)? 3. Стейкхолдеры проверяют отобранные требования перед включением в новую инициативу 4. При включении → создать новую запись с `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` → список затронутых требований при CR - `5.3` → обновлённые приоритеты - `5.4` → решение по CR: какие требования меняются, какие deprecated - `5.5` → status: `approved` после формального согласования **Куда уходят результаты:** - `5.3` — актуальные stability и priority для правильной приоритизации - `5.5` — чистый реестр для пакета согласования - `6.x` — reuse-кандидаты для User Stories и Use Cases - `Confluence` — через хук экспорта (после подключения `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`