Модуль 11.1. Сквозной кейс (Capstone)
Задача: спроектировать и довести до «релиз-готовности» продукт в выбранном домене.
Артефакты (минимум): Vision → SRS → BPMN/DMN → ER → OpenAPI → NFR → RTM → тест-сценарии → план UAT → C4.
Практика: защита проекта с live-ревью.
Цель и формат капстона
В этом модуле вы проходите полный цикл системной аналитики «как на работе»: от замысла и границ — до релизного пакета артефактов, тестов, UAT и архитектурного контекста. Итог — релизный пакет и презентация-защита перед «советом» (PO/архитектор/QA/SRE — роли наставников).
Допустимые домены (выберите 1)
- Fintech/Банк: «Инвойс→Оплата→Возврат» с KYC/AML и учётом.
- E-commerce/Логистика: «Корзина→Заказ→Доставка→Возврат».
- 1C/ERP/CRM: «CRM→1C:ERP: заказ→счёт→отгрузка→оплата».
- DWH/BI/AI: «CDC→Витрина→Метрики→Export API» (stream + batch).
Рекомендуем взять тот трек, где вы планируете карьеру/вакансию: это добавит ценность в резюме и портфолио.
План работ (календарь и контрольные точки)
Этапы и артефакты
|
Неделя |
Что делаем |
Артефакты и критерии качества |
|---|---|---|
|
W1 |
Определяем Vision и границы |
Vision v1.0, глоссарий, персоны, бизнес-цели/метрики, риски, out-of-scope |
|
W2 |
Пишем SRS (скелет) и C4 L1–L2 |
SRS секции 1–3, C4 L1/L2, RTM-каркас |
|
W3 |
Процессы и правила: BPMN/DMN, Use Cases |
BPMN «happy/alt», DMN таблицы, UC с альтернативами |
|
W4 |
Данные: ER + словари, интеграции |
ER v1.0, словарь атрибутов, DQ, справочники/ключи |
|
W5 |
OpenAPI/Events, NFR, AC/BDD |
Контракты, коды ошибок, токены/идемпотент, NFR-каталог, 10 AC |
|
W6 |
RTM и тест-дизайн, план UAT |
RTM связки, 20 тест-кейсов (10+ негативов), UAT план |
|
W7 |
Релиз-пакет и репетиция защиты |
Release Notes, Change Log, Go/No-Go чек-лист |
|
W8 |
Защита (live-ревью) |
Питч 15 мин + Q&A 15 мин, демо артефактов |
Definition of Done (для капстона)
- Все артефакты согласованы между собой (термины/версии/ссылки).
- Есть RTM: REQ→AC/BDD→Тесты→Интерфейсы/Метрики.
- NFR проверяемы (метрики/окна/порог/метод проверки).
- Контракты идемпотентны, версии отмечены (semver), есть Change Log.
- UAT план имеет вход/выход, роли, критерии sign-off, риск-матрицу.
Структура репозитория (Docs-as-Code)
capstone/ README.md # краткая карта артефактов vision/vision.md srs/srs.md # + changelog.md c4/context_l1.puml c4/containers_l2.puml processes/bpmn_order.bpmn rules/dmn_tables.dmn data/er_diagram.puml data/dictionary.md contracts/openapi.yaml contracts/events_schemas/... quality/nfr_catalog.md quality/rtm.csv tests/ac_bdd/*.feature tests/test_cases.xlsx uat/uat_plan.md release/release_notes.md
Шаблоны (копируйте и заполняйте)
Vision (одна страница)
Продукт: <название>, Домены: <...> Цели (business outcomes): ↑конверсия X→Y, ↓SLA инцидентов, новая выручка Персоны: <покупатель>, <оператор саппорта>, <бухгалтер> ... Границы: в скоупе / вне скоупа (чётко) Ключевые метрики: GMV, on-time delivery %, NPS, p95 latency < 2.0s Риски (топ-5): PSP задержки, дубликаты, DQ, комплаенс, PII Assumptions: <...> Dependencies: <...> Roadmap (этапы/релизы): R1, R2, R3
Каркас SRS (минимум)
1. Введение (назначение, глоссарий, ссылки) 2. Общее описание (персоны/контекст/зависимости) 3. Внешние интерфейсы (API/Events/UI) 4. Функциональные требования (REQ-XXX, shall + мера + метод проверки) 5. Нефункциональные (SLO/SLA, безопасность, наблюдаемость, локаль, a11y) 6. Данные (ER, словарь атрибутов, справочники, DQ) 7. Сценарии/Состояния (UC + State) 8. Ограничения проектирования (обоснованные) 9. Трассируемость (RTM) 10. Критерии приёмки (AC, Given-When-Then) Приложения: OpenAPI/DMN/BPMN, Change Log
BPMN — Full Cycle (фрагмент чек-листа)
- Пулы: Пользователь, Витрина/Чекаут, Платежи, Склад, Перевозчик, Саппорт.
- Таймеры: cut-off, SLA PSP, SLA доставки.
- Пограничные события ошибок: PSP Timeout, Carrier Webhook Fail.
- Компенсации: отмена резерва, отмена этикетки.
- Сообщения/события: order.placed, payment.captured, shipment.created, return.requested, refund.issued.
DMN — пример таблицы SLA (hit policy F)
|
zone |
service |
beforeCutoff? |
onStock? |
promisedMin |
promisedMax |
|---|---|---|---|---|---|
|
A |
SameDay |
true |
true |
today 20:00 |
today 22:00 |
|
* |
* |
false |
* |
+1d |
+1d |
ER — минимальный контур (пример сущностей)
Order (PK), OrderItem, Payment, Shipment, Parcel, Return, Refund, Customer, Warehouse, Stock
OpenAPI — фрагмент
openapi: 3.0.3
info: {title: Orders API, version: 1.0.0}
paths:
/v1/orders:
post:
summary: Place order
parameters:
- in: header
name: Idempotency-Key
required: true
schema: {type: string, maxLength: 128}
- in: header
name: X-Correlation-Id
required: true
schema: {type: string}
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/PlaceOrderRequest'
responses:
"201": {description: Created}
"202": {description: Accepted (async payment)}
"422": {description: Validation}
NFR — каталог (шаблон)
|
ID |
Область |
Требование |
Окно/условия |
Метод проверки |
|---|---|---|---|---|
|
NFR-PERF-001 |
Latency |
p95 POST /orders < 900ms |
08–23, EU/Stockholm |
нагрузочный тест + SLI |
|
NFR-SEC-003 |
Auth |
OAuth2 + JWT RS256, scope orders:write |
всё время |
инспекция + e2e |
|
NFR-OBS-002 |
Logs |
JSON-логи со схемой, traceId |
прод |
инспекция + log-парсеры |
RTM — формат CSV
REQ_ID, Description, AC_ID, TestCase_ID, API/Schema Ref, Metric/Alert, Status
Тест-сценарии (пример)
- Позитивы (10): «Успешный заказ с картой», «СБП 202→получен коллбек», «Частичный возврат».
-
Негативы (10): «Неверный SKU», «Недостаточный лимит KYC», «PSP timeout», «Дедуп вебхука» и т. п.
Формат: Preconditions → Steps → Expected → Data.
План UAT (шаблон)
Цель: подтвердить, что фича закрывает бизнес-цели Vision Объём: сценарии критического пути + регресс по интеграциям Роли: Бизнес-заказчик (A), SA (Driver), QA (C), DevOps (C) Вход: релиз-кандидат v1.0.0, тест-окружение, тестовые учётки/данные Выход: Sign-off, список дефектов (S1..S3), решение Go/No-Go Календарь: T-7 план, T-3 dry-run, T-0 сессия 2 часа Критерии приёмки: 0 S1, ≤ N S2, метрики SLO «зеленые» Риски/план: резерв слотов, откат фичефлага, fallback UX
C4 — контекст/контейнеры (критерии)
- L1: кто с кем говорит и зачем (5–7 узлов, протоколы).
- L2: сервисы/БД/очереди, внешние зависимости, потоки (sync/async).
Пример «мини-решения» (E-commerce, выдержки)
Vision (кратко): повысить on-time доставку до 94% и сократить отмены на 20%.
Ключевые REQ (фрагмент):
- REQ-ORD-001: Система ДОЛЖНА принимать POST /v1/orders с Idempotency-Key, X-Correlation-Id; 201/202/4xx. Проверка: контракт-тесты.
- REQ-SLA-002: Расчёт обещанной даты ДОЛЖЕН укладываться в p95<200ms и учитывать календари и cut-off. Проверка: DMN тесты + нагрузка.
-
REQ-PAY-003: При таймауте PSP возвращать 202 и публиковать payment.pending.v1. Проверка: e2e + метрики очередей.
DMN: таблица SLA как в §4.4.
ER: сущности из §4.5.
OpenAPI: как в §4.6 + POST /payments, POST /returns.
NFR: latency, error-rate, а11y формы возврата, аудит.
RTM: связки REQ→AC/BDD→OpenAPI endpoints→метрики.
UAT: две сессии — «заказ→доставка» и «возврат→рефанд».
Риски (capstone анти-паттерны и как их гасить)
|
Анти-паттерн |
Симптом |
Как исправить |
|---|---|---|
|
Несогласованный UL |
Разные термины в SRS/API/ER |
Вынести глоссарий, прогон по всем артефактам |
|
«Счастливые» диаграммы |
Нет таймаутов/ошибок |
Добавьте альтернативы/пограничные события |
|
NFR «вода» |
«быстро/надёжно» |
Формализуйте p95/p99/SLO, метод проверки |
|
Нет идемпотентности |
Дубли заказов/вебхуков |
Idempotency-Key, реестр, дедуп ключи |
|
RTM пустой |
Нельзя проследить покрытие |
Заполнить REQ→AC→Tests→Interfaces |
|
Нет Change Log |
Непонятно, что поменялось |
Вести CHANGELOG.md и релиз-ноты |
|
UAT «для галочки» |
Нет выхода/критериев |
Чёткий вход/выход/роль/метрики, sign-off |
|
Переоцененный объём |
Не успеваете к защите |
Cut-line: ядро MVP + флаги на второстепенное |
Гайд по защите (live-ревью)
Питч 15 минут (структура)
- Проблема и цели (Vision, метрики успеха).
- Контекст (C4 L1–L2) и ключевые зависимости.
- Процессы (BPMN) и правила (DMN) — 1–2 слайда «смысл».
- Модель данных (ER) — 6–8 сущностей и ключи.
- Контракты (OpenAPI/Events) — 3–5 эндпоинтов/событий + ошибки/идемпотентность.
- NFR и наблюдаемость — что и как измеряем.
- RTM и тесты — покрытие, негативы.
- UAT план — вход/выход/критерии sign-off.
- Риски/антипаттерны — как гасите.
- Что вырезали (cut-line) и зачем.
Q&A 15 минут — ожидаемые вопросы
- Чем это лучше альтернативы? Где компромиссы?
- Что сломается при росте нагрузки ×10?
- Как вы откатываете фичу? Где kill-switch?
- Как обеспечена совместимость версий?
- Какие DQ-правила и где алерты?
Оценивание (рубрика, 100 баллов)
- Согласованность артефактов (UL, ссылки, версии) — 20
- Контракты и процессы (альтернативы, ошибки, идемпотентность) — 20
- Данные и NFR (ER, DQ, метрики, проверяемость) — 20
- RTM/Тесты/UAT (полнота и реалистичность) — 20
-
Презентация/Риски/Решения — 20
Порог зачёта: 70. Отлично: ≥90.
Вопрос–Ответ
В: С чего начать — с данных или с процессов?
О: С Vision/UL, затем контекст (C4) и процессы (BPMN). Данные (ER) лучше делать после понятных сценариев, но до контрактов — чтобы типы и ключи были осмысленны.
В: Нужно ли рисовать все диаграммы?
О: Достаточно минимального набора, покрывающего критические сценарии и альтернативы. «Одна диаграмма — одна идея».
В: Как выбрать уровень детализации SRS?
О: Руководствуйтесь риском: чем выше риск недопонимания/стоимость ошибки, тем детальнее. Но избегайте копипасты контента из OpenAPI/ER — давайте ссылки.
В: Можно ли менять scope во время капстона?
О: Да, но только через CR/Change Log и с cut-line — иначе потеряете управляемость.
В: Как показать NFR без прод-метрик?
О: Запланируйте метод верификации: нагрузочный тест/смоки SLI в тестовом окружении, чек-листы безопасности, трассировки.
В: Что, если не успеваю?
О: Сохраните «критический путь» (order→payment→shipment), второстепенное — под фичефлаги. Главное — согласованность и качество ядра.
Шпаргалка
- Vision → C4 → BPMN/DMN → ER → OpenAPI → NFR → RTM → Tests → UAT — не перескакивайте этапы.
- Везде одна лексика (UL/Glossary) и сквозная трассировка.
- Контракты: идемпотентность, версии, ошибки, безопасность.
- NFR = метрика + окно + метод проверки.
- RTM — ваша «страховка» от дыр в логике.
- UAT — это решение бизнеса «Go/No-Go», готовьте вход/выход и критерии.
- Всегда держите Change Log и cut-line.
