| name | requirements_verify |
| description | Скилл BABOK 7.2 — Верификация требований. Используй этот скилл когда BA хочет проверить качество написанных требований: атомарность, однозначность, тестируемость, полноту, консистентность. Отличие от валидации: верификация — про качество формулировок, не про ценность для бизнеса. Триггеры: «верификация требований», «verify requirements», «качество требований», «requirements quality», «проверить требования», «чеклист».
|
| project | AI-powered Platform AInalyst (AI Платформа AIналитик) |
| copyright | Copyright (c) 2026 Anatoly Chaussky. Licensed under AGPL v3. Commercial licensing: chaussky@gmail.com |
SKILL.md — BABOK 7.2 Verify Requirements
Суть задачи
Верификация требований отвечает на вопрос: «Правильно ли написаны требования?»
Отличие от задачи 7.3 (Validate):
- 7.2 Verify: правильно ли написано требование? (качество формулировки)
- 7.3 Validate: правильное ли это требование? (соответствие бизнес-потребности)
Входные данные: требования из репозитория 5.1 (созданные в 7.1).
Выходные данные: статус verified в 5.1, Verification Report → 5.5 (Approve) и 7.3 (Validate).
9 характеристик качества BABOK
| Характеристика | Группа | Как проверяем |
|---|
| Атомарность | A | MCP: стоп-слова |
| Однозначность | A | MCP: слова-сигналы |
| Тестируемость | A | MCP: структура + AC |
| Приоритизированность | A | MCP: поле priority в 5.1 |
| Краткость | A | MCP: длина + сигналы |
| Согласованность | B | MCP: статусы + граф 5.1 |
| Полнота | B | MCP: source_artifact + links |
| Выполнимость | C | Чеклист BA (см. references/) |
| Понятность | C | Чеклист BA (см. references/) |
Детали правил — в references/quality_rules.md.
Чеклисты по типам — в references/checklist_templates.md.
Pipeline задачи 7.2
check_req_quality → автоматические проверки Группы A+B
↓ (если есть проблемы)
open_verification_issue → фиксируем каждую проблему
↓ (BA исправляет требования)
check_model_consistency → cross-model проверка файлов из 7.1
↓ (если есть рассинхрон)
open_verification_issue → фиксируем model inconsistency
↓ (BA исправил)
resolve_verification_issue → закрываем issue
↓
mark_req_verified → статус draft → verified в 5.1
↓
get_verification_report → сводный отчёт → 5.5 + 7.3
Инструменты MCP
check_req_quality(project_id, req_ids?, req_type?)
Проверяет одно требование, список или все req проекта по 9 характеристикам.
Умный батч: если req_ids не задан — берёт все draft req из репозитория 5.1.
Если задан req_type — фильтрует по типу (user_story / functional / non_functional и т.д.).
Возвращает:
- Результаты проверок по каждому req (Группы A+B)
- Список blockers и majors для каждого
- Подсказки для Claude Code: что именно нарушено и как исправить
- Напоминание пройти чеклисты Группы C (Выполнимость + Понятность)
Паттерн использования:
# Проверить всё
check_req_quality(project_id="my_project")
# Проверить конкретные req
check_req_quality(project_id="my_project", req_ids='["US-001", "FR-001"]')
# Проверить только User Stories
check_req_quality(project_id="my_project", req_type="user_story")
check_model_consistency(project_id)
Сравнивает артефакты из 7.1: .md и .puml файлы в governance_plans/{project}_specs/.
Что проверяет:
- Сущности в DD vs ERD (рассинхрон имён)
- Use Cases vs UC Diagram (UC без актора в диаграмме)
- Участники бизнес-процесса vs акторы в UC Diagram
Важно: Парсинг регулярками по шаблонам из 7.1. Работает для стандартного форматирования. Нестандартные форматы — Claude Code интерпретирует предупреждения вручную.
open_verification_issue(project_id, req_id, issue_type, description, severity, assigned_to?)
Фиксирует проблему, найденную при верификации.
issue_type: ambiguity / not_testable / not_atomic / missing_ac / model_inconsistency / other
severity: blocker / major / minor
Когда открывать:
- После
check_req_quality — для каждой автоматически найденной проблемы
- После ручной проверки чеклистов Группы C
- После
check_model_consistency — для рассинхронов моделей
Присвоение assigned_to: как правило — тот BA кто создавал требование (владелец).
resolve_verification_issue(project_id, issue_id, resolution_note)
Закрывает issue после того как BA исправил требование.
resolution_note — что именно было исправлено (для аудита).
Важно: После закрытия всех blocker-issues по req — можно вызывать mark_req_verified.
mark_req_verified(project_id, req_ids)
Меняет статус draft → verified в репозитории 5.1.
Предусловие: MCP проверит наличие открытых blocker-issues по каждому req.
Если blocker есть — предупреждение, но не блокировка (BA принимает решение).
# Верифицировать список
mark_req_verified(project_id="my_project", req_ids='["US-001", "US-002", "FR-001"]')
get_verification_report(project_id)
Сводный отчёт по верификации проекта.
Содержит:
- % verified из всех req (показатель готовности к 5.5)
- Топ-проблемы по типам характеристик
- Список req с открытыми blocker-issues
- Открытые issues с деталями
- Вердикт: готово ли к Approve (5.5)
Сохраняет Markdown через save_artifact — передать в 5.5 и 7.3.
Типичный сценарий работы
Шаг 1. Запускаешь проверку всех требований:
check_req_quality(project_id="crm_2024")
Claude Code читает результат и объясняет каждую проблему понятным языком.
Шаг 2. Для критичных проблем открываешь issues:
open_verification_issue(
project_id="crm_2024",
req_id="US-003",
issue_type="missing_ac",
description="User Story не содержит Acceptance Criteria — нет критериев приёмки",
severity="blocker"
)
Шаг 3. Исправляешь требование (в файле или через инструмент 7.1). Затем закрываешь issue:
resolve_verification_issue(
project_id="crm_2024",
issue_id="VI-001",
resolution_note="Добавлено 3 Acceptance Criteria: успешная авторизация, неверный пароль, блокировка"
)
Шаг 4. Проверяешь согласованность моделей:
check_model_consistency(project_id="crm_2024")
Шаг 5. Проходишь чеклисты Группы C из references/checklist_templates.md — Выполнимость и Понятность для каждого типа требований.
Шаг 6. Верифицируешь требования без блокеров:
mark_req_verified(project_id="crm_2024", req_ids='["US-001", "US-002", "FR-001"]')
Шаг 7. Генерируешь отчёт для передачи в 5.5:
get_verification_report(project_id="crm_2024")
Связь с другими задачами BABOK
Входящие связи:
- Репозиторий 5.1 — список req со статусами
- Файлы из 7.1 — спецификации в
governance_plans/{project}_specs/
Исходящие связи:
- → 5.5 (Approve Requirements): Verification Report как входной артефакт
- → 7.3 (Validate Requirements): верифицированные req как входные данные
Важно: 7.2 и 7.3 можно запускать итеративно и параллельно. Если в процессе валидации (7.3) выясняется что требование сформулировано плохо — возвращайся в 7.2.
Хранение данных
| Что | Где | Формат |
|---|
| Verification issues | governance_plans/{project}_verification_issues.json | JSON |
| Статусы req | Репозиторий 5.1 ({project}_traceability_repo.json) | JSON (поле status) |
| Verification Report | governance_plans/ через save_artifact | Markdown |
Подсказки для Claude Code при интерпретации результатов
При ambiguity (слово-сигнал):
Объясни BA что конкретно размыто и предложи переформулировку с метрикой.
Пример: «быстро» → «в течение 2 секунд при нагрузке до 1000 пользователей».
При missing_ac:
Предложи 2-3 примера AC в формате Given/When/Then или просто нумерованных условий.
При not_atomic:
Укажи где именно союз делит требование на два. Предложи разбить на req_id_a и req_id_b.
При not_testable (FR без метрики):
Уточни у BA что является измеримым результатом. Пример: «система сохраняет» → «система сохраняет в течение X секунд с вероятностью Y%».
При model_inconsistency:
Покажи конкретно: в каком файле что написано и что расходится. BA исправляет в нужном файле.
