| name | requirements_spec |
| description | Скилл BABOK 7.1 — Спецификация и моделирование требований. Используй этот скилл когда BA переводит результаты выявления в формальные спецификации: user stories, use cases, бизнес-правила, data definitions, процессные модели (BPMN). Триггеры: «спецификация требований», «user story», «use case», «бизнес-правила», «specify requirements», «написать требования», «оформить требования», «BPMN», «модели».
|
| 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.1: Specify and Model Requirements
Что делает эта задача
Задача 7.1 превращает подтверждённые результаты выявления (4.2/4.3) в формальные
спецификации требований. Вход — «что сказали стейкхолдеры», выход — «требования
в стандартных нотациях с моделями».
Это мост между выявлением (Глава 4) и верификацией/валидацией (7.2, 7.3).
Когда вызывать эти инструменты
Вызывай инструменты 7.1, когда:
- Есть подтверждённые результаты выявления (артефакты 4.3)
- Нужно передать требования разработчикам, архитекторам, тестировщикам
- Нужны трассируемые формальные спецификации
- Надо проверить, что все бизнес-цели из выявления покрыты требованиями
Рекомендуемый порядок работы
Шаг 1 — Анализ контекста
Начни с analyze_elicitation_context. Инструмент прочитает артефакты 4.3
и предложит список требований-кандидатов с классификацией.
analyze_elicitation_context(
project_id="crm_2024",
context_text="" # оставить пустым — инструмент найдёт файл сам
)
Если файл 4.3 не найден, инструмент попросит передать текст вручную:
analyze_elicitation_context(
project_id="crm_2024",
context_text="[скопируй сюда содержимое артефакта 4.3]"
)
Шаг 2 — Создание артефактов
Создавай требования по одному или группами, используя нужный инструмент.
Каждый созданный артефакт автоматически регистрируется в репозитории 5.1
со статусом draft. Тебе не нужно вручную вызывать инструменты 5.1.
Как выбрать тип артефакта → смотри references/modeling_guide.md.
Шаблоны каждого артефакта → смотри references/templates.md.
Шаг 3 — Диаграммы (по необходимости)
- После создания Use Cases → вызови
generate_use_case_diagram для сводной диаграммы
- Business Process создаёт
.puml файл Activity Diagram автоматически
- ERD создаёт
.puml файл автоматически
Шаг 4 — Проверка покрытия
В конце вызови build_coverage_matrix. Инструмент покажет:
- 🟢 Бизнес-цели, покрытые требованиями
- 🔴 Бизнес-цели без ни одного требования (нужно создать)
- 🟡 Бизнес-цели с 10+ требованиями (возможный over-engineering)
Инструменты
analyze_elicitation_context
Анализирует подтверждённые результаты выявления и предлагает список требований.
analyze_elicitation_context(
project_id="crm_2024", # обязательно
context_text="" # опционально: текст если файл не найден
)
Возвращает:
- Список бизнес-целей из 4.3
- Требования-кандидаты с рекомендуемым типом и ID-префиксом
- Пробелы: темы выявления без конкретных требований
create_user_story
create_user_story(
project_id="crm_2024",
story_id="US-001",
title="Подать заявку на кредит",
role="Менеджер по заявкам",
action="создать новую заявку на кредит с заполнением всех полей",
benefit="заявка была зарегистрирована и передана на рассмотрение",
acceptance_criteria_json='["Система сохраняет заявку с уникальным ID", "Система отправляет подтверждение на email менеджера"]',
priority="High",
source_artifact="governance_plans/4_3_crm_confirmed.md",
notes=""
)
create_functional_requirement
create_functional_requirement(
project_id="crm_2024",
req_id="FR-001",
req_type="functional", # functional | non_functional | business_rule
title="Автоматическое распределение заявок",
description="Система ДОЛЖНА автоматически распределять входящие заявки между менеджерами по алгоритму round-robin с учётом текущей загрузки.",
rationale="Снижает время ожидания клиента, исключает ручной контроль.",
priority="High",
owner="Руководитель отдела продаж",
source_artifact="governance_plans/4_3_crm_confirmed.md",
constraints="",
related_ids_json='["BR-001", "UC-001"]'
)
Формулировки по типу:
functional: «Система ДОЛЖНА [действие]...»non_functional: «Система ДОЛЖНА обрабатывать не менее [N] запросов в секунду при [условии]»business_rule: «[Субъект] [ограничение/правило]» — без привязки к системе
create_use_case
create_use_case(
project_id="crm_2024",
uc_id="UC-001",
title="Рассмотреть заявку на кредит",
primary_actor="Кредитный аналитик",
secondary_actors="Служба безопасности, Система скоринга",
precondition="Заявка имеет статус 'На рассмотрении'",
postcondition="Заявка получает статус 'Одобрена' или 'Отклонена'",
trigger="Аналитик открывает заявку в системе",
main_scenario="1. Аналитик открывает заявку.\n2. Система отображает данные клиента и документы.\n3. Аналитик проверяет скоринговый балл.\n4. Система запрашивает проверку в Службе безопасности.\n5. Аналитик принимает решение.\n6. Система фиксирует решение и меняет статус.",
alt_scenarios="3а. Скоринговый балл недоступен: Аналитик запрашивает повторный расчёт.",
exc_scenarios="4а. Служба безопасности не отвечает более 24ч: Система уведомляет руководителя.",
business_rules="Решение должно быть принято в течение 3 рабочих дней.",
priority="High",
source_artifact="governance_plans/4_3_crm_confirmed.md"
)
generate_use_case_diagram
Генерирует сводную PlantUML Use Case Diagram по всем UC проекта из репозитория 5.1.
generate_use_case_diagram(
project_id="crm_2024",
system_boundary="CRM-система",
diagram_name="crm_use_cases"
)
Результат: файл {project}_specs/uc_diagram_{diagram_name}.puml
create_business_process
Создаёт два файла: текстовое описание .md + Activity Diagram .puml.
create_business_process(
project_id="crm_2024",
bp_id="BP-001",
title="Жизненный цикл заявки",
process_owner="Руководитель отдела продаж",
trigger="Клиент обращается за кредитом",
outcome="Кредит выдан или заявка закрыта с отказом",
participants="Менеджер, Кредитный аналитик, Служба безопасности",
steps="1. Менеджер: принять обращение клиента.\n2. Менеджер: создать заявку в CRM.\n3. Система: назначить аналитика.\n4. Аналитик: проверить документы.\n5. ...",
business_rules="Срок рассмотрения — 3 рабочих дня.",
metrics="Среднее время: 2 дня. Конверсия в одобрение: 65%.",
exceptions="Если клиент не предоставил документы в течение 5 дней — автозакрытие.",
priority="Medium",
source_artifact="governance_plans/4_3_crm_confirmed.md"
)
create_data_dictionary
create_data_dictionary(
project_id="crm_2024",
dd_id="DD-001",
title="Сущность Заявка (Application)",
entities_json='[{"name": "Application", "description": "Заявка на кредит", "attributes": [{"name": "id", "type": "Integer", "required": true, "constraints": "PK, AUTO_INCREMENT", "description": "Уникальный идентификатор"}, {"name": "status", "type": "Enum", "required": true, "constraints": "draft|submitted|approved|rejected", "description": "Статус заявки"}], "business_rules": ["Статус меняется только по бизнес-правилам перехода"]}]',
source_artifact="governance_plans/4_3_crm_confirmed.md"
)
create_erd
Создаёт два файла: описание связей .md + ER Diagram .puml.
create_erd(
project_id="crm_2024",
erd_id="ERD-001",
title="Основные сущности CRM",
entities_json='[{"name": "Application", "pk": "id", "attributes": ["client_id FK", "manager_id FK", "status Enum", "created_at DateTime"]}, {"name": "Client", "pk": "id", "attributes": ["name String", "inn String UNIQUE"]}]',
relations_json='[{"from": "Application", "to": "Client", "cardinality": "many-to-one", "label": "belongs to"}]',
source_artifact="governance_plans/4_3_crm_confirmed.md"
)
build_coverage_matrix
Строит матрицу покрытия «бизнес-цель → требования».
build_coverage_matrix(
project_id="crm_2024"
)
Сигналы:
- 🔴 Бизнес-цель не покрыта — создай хотя бы одно требование
- 🟡 10+ требований на одну цель — возможен over-engineering, стоит пересмотреть
- 🟢 1–9 требований на цель — нормальное покрытие
Хранение артефактов
Все артефакты сохраняются в: governance_plans/{project_id}_specs/
governance_plans/crm_2024_specs/
├── US-001_submit_application.md
├── FR-001_auto_distribution.md
├── UC-001_review_application.md
├── uc_diagram_crm_use_cases.puml ← сводная UC Diagram
├── BP-001_application_lifecycle.md
├── BP-001_application_lifecycle.puml ← Activity Diagram
├── DD-001_application_entity.md
├── ERD-001_core_entities.md
└── ERD-001_core_entities.puml ← ER Diagram
Автоматическая регистрация в 5.1
Каждый созданный артефакт автоматически регистрируется в репозитории 5.1
(файл governance_plans/{project_id}_traceability_repo.json) со статусом draft.
Ты можешь:
- Сразу добавить связи через
add_trace_link (5.1)
- Изменить статус через
update_requirement (5.2) когда требование готово к верификации
- Проверить покрытие через
check_coverage (5.1)
Связи с другими задачами
| Откуда | Что берём |
|---|
| 4.2/4.3 | Подтверждённые результаты выявления (вход для analyze_elicitation_context) |
| 5.1 | Репозиторий трассировки (7.1 пишет в него автоматически) |
| Куда | Что передаём |
|---|
| 7.2 | Спецификации требований для верификации |
| 7.3 | Спецификации требований для валидации |
| 5.3 | Список draft-требований для приоритизации |
Справочники
references/modeling_guide.md — как выбрать тип артефактаreferences/templates.md — шаблоны каждого артефакта и PlantUML-диаграмм
