| name | requirements_architecture |
| description | Скилл BABOK 7.4 — Определение архитектуры требований. Используй этот скилл когда BA хочет выстроить целостную картину из разрозненных требований: определить слои архитектуры, задать представления (views), связать требования с компонентами системы. Триггеры: «архитектура требований», «requirements architecture», «слои требований», «структура требований», «views», «как организовать требования», «requirements structure».
|
| 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.4 Define Requirements Architecture
Суть задачи
Архитектура требований отвечает на вопрос: «Как наши требования образуют целостную картину?»
Место в цепочке:
- 7.1 Specify → Создаём требования (артефакты: BP, US, FR, BR, DD, ERD)
- 7.2 Verify → Проверяем качество формулировок
- 7.3 Validate → Проверяем ценность для бизнеса
- 7.4 Architecture → Организуем требования в связную структуру ← мы здесь
- 7.5 Design Options → Определяем варианты решения
Ключевые понятия:
- Viewpoint (точка зрения) — перспектива, с которой стейкхолдер смотрит на систему
- View (представление) — подмножество req для конкретного viewpoint
Разные стейкхолдеры видят систему по-разному: заказчик — через процессы, разработчик — через функции,
архитектор данных — через модели данных. 7.4 организует требования так, чтобы каждый видел «своё».
Автоматический маппинг по типам артефактов
Платформа автоматически распределяет req по точкам зрения:
| Тип артефакта | Точка зрения |
|---|
business_process (BP) | Бизнес-процессы |
data_dictionary (DD), erd (ERD) | Данные и информация |
user_story (US), use_case (UC) | Пользователи и взаимодействие |
functional (FR), non_functional (NFR) | Функциональность |
business_rule (BR) | Бизнес-правила |
business (BG-узлы) | Не включается в viewpoints |
Pipeline (шаги по порядку)
1. analyze_requirements_architecture ← автоматически строит viewpoints из репозитория 5.1
2. add_custom_viewpoint ← [необязательно] добавить специфическую точку зрения
3. check_architecture_gaps ← найти разрывы: матрица покрытия + семантика
4. save_architecture_snapshot ← зафиксировать архитектуру → передать в 4.4 и 7.5
Инструменты MCP
1. analyze_requirements_architecture
Когда: в начале работы над архитектурой — строит полную картину из репозитория.
analyze_requirements_architecture(project_id = "crm_upgrade")
Что делает:
- Читает все req из репозитория 5.1 (
{project}_traceability_repo.json)
- Распределяет по viewpoints согласно VIEWPOINT_MAP (ADR-034)
- Строит матрицу покрытия: BG × точки зрения
- Показывает кастомные viewpoints если они уже добавлены
- Учитывает business_context из 7.3 (BG-список)
Что возвращает:
- Сводная таблица: viewpoint → количество req → список ID
- Coverage matrix: какие BG покрыты какими точками зрения
- Кастомные viewpoints (если есть)
- Подсказка: какие разрывы стоит проверить
2. add_custom_viewpoint
Когда: проект требует дополнительной точки зрения (регуляторные требования, безопасность, миграция).
add_custom_viewpoint(
project_id = "crm_upgrade",
viewpoint_id = "security",
label = "Безопасность и доступ",
description = "Требования к аутентификации, авторизации, шифрованию данных",
req_ids_json = '["NFR-003", "NFR-007", "FR-015", "BR-002"]',
stakeholder_roles = "Архитектор безопасности, CISO"
)
Важно (ADR-036): кастомные точки зрения задаются через req_ids, а не через типы.
«Безопасность» — это срез поверх FR/NFR/BR, только BA знает какие именно req входят.
Валидация: инструмент проверяет что все переданные req_ids существуют в репозитории 5.1.
3. check_architecture_gaps
Когда: после analyze_requirements_architecture — найти слабые места.
check_architecture_gaps(project_id = "crm_upgrade")
Два уровня проверки (ADR-038):
Уровень 1 — Матрица покрытия:
- Стейкхолдер без представления →
critical
- BG без покрытия viewpoint →
warning
- Пустая точка зрения →
info
Уровень 2 — Семантические разрывы (использует граф 5.1):
- UC без соответствующего BP →
warning
- NFR без привязки к FR →
warning
- FR без UC/US →
info
- Стейкхолдер в реестре без ни одного req →
critical
⚠️ Интерпретация: уровень 2 зависит от полноты связей в 5.1.
Если BA не добавлял трассировку через 5.1 — много ложных срабатываний. Учитывай это.
4. save_architecture_snapshot
Когда: архитектура готова — перед передачей в 4.4 (коммуникация) и 7.5 (дизайн).
save_architecture_snapshot(
project_id = "crm_upgrade",
version = "v1.0",
notes = "Первая версия архитектуры требований. Покрыто 5 viewpoints, 2 critical gaps устранены.",
author = "Иванов А."
)
Что создаёт:
- Снапшот в
{project}_architecture.json (история не перезаписывается, ADR-037)
- Markdown-документ через
save_artifact → передаётся в 4.4 и 7.5
Типичный рабочий сценарий
Начало работы
- Убедись что в 7.1 созданы артефакты разных типов (BP, US, FR и т.д.)
- Вызови
analyze_requirements_architecture — получи полную картину
Если проект стандартный
check_architecture_gaps — найди разрывы- Устрани critical gaps: создай недостающие req (7.1) или добавь трассировку (5.1)
save_architecture_snapshot(version="v1.0") — зафиксируй
Если проект регуляторный (банк, медицина, государственный)
add_custom_viewpoint — добавь точки зрения «Безопасность», «Аудит и compliance»check_architecture_gaps — проверь с учётом кастомных viewpointssave_architecture_snapshot — зафиксируй
Agile-проект (итерационная работа)
- Вызывай
analyze_requirements_architecture в конце каждого спринта
- Делай снапшот после каждого значимого прироста req
- Передавай Architecture Document в Planning следующего спринта
Файлы, которые создаёт задача 7.4
| Файл | Содержит |
|---|
{project}_architecture.json | Viewpoints, views, gaps, история снапшотов |
7_4_architecture_*.md | Architecture Document → 4.4, 7.5 |
Связи с другими задачами
| Откуда | Что приходит |
|---|
| 5.1 | Репозиторий req — основа для viewpoint-маппинга и BFS-анализа разрывов |
| 4.2 | Реестр стейкхолдеров — проверка покрытия |
| 7.1 | Типы артефактов — автоматический маппинг на viewpoints |
| 7.3 | business_context (BG) — матрица покрытия |
| Куда | Что передаём |
|---|
| 4.4 | Architecture Document — артефакт для коммуникации со стейкхолдерами |
| 7.5 | Architecture Document — входной артефакт для Design Options |
Детальная методология
- Viewpoints, маппинг типов, разрывы, фреймворки, паттерны проблем →
references/architecture_guide.md
