Сквозная фича (end-to-end feature) — бизнес-результат, достигаемый цепочкой действий через границы подсистем: FE, BFF, сервисы, шина, batch. Этот шаблон описывает сквозной сценарий в нотации BPMN 2.0 (Business Process Model and Notation): участники, шаги, ветвления, события, интеграции и точки взаимодействия с UI/API/очередями. Он не заменяет User Story, Use Case, REST/SOAP/Kafka-спеки и описание экранов — связывает их в один процесс и задаёт трассировку к BRD/SRS (02.03.03 Спецификация требований (SRS, Use Case, User Story), 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)). Место BPMN в SA-контуре — 03.04.01 BPMN 2.0 - введение и основы; элементы нотации и паттерны — раздел 06.02 (здесь не учим нотацию).

1. Назначение

Документ пишет системный аналитик; его читают Product Owner, разработка, QA, архитектор и интеграционные команды на этапах проектирования, оценки и приёмки сквозного сценария.

Два режима модели — зафиксируйте в паспорте §3.1 и не смешивайте требования к ним:

РежимНазначениеДостаточноДополнительно для runtime
ДокументационнаяСогласование, E2E-трассировка, walkthrough QACollaboration L0 + таблица шагов + матрица; Confluence / draw.io—
Исполняемая (движок)Деплой в Camunda и аналогиВсё из документационнойService Task, job retry, incident, external task — см. 06.02.04 Работа с Camunda

В документационном режиме «исполнимость» означает однозначность шагов для dev/QA, а не семантику BPMN Engine. Команда не должна требовать retry/incident там, где достаточно collaboration + таблицы; в исполняемом режиме — наоборот, недокладывать runtime-элементы нельзя.

Шаблон закрывает четыре задачи:

  • Оркестрация передач между системами (handoffs) — кто что делает, в каком порядке и через какие границы; BPMN фиксирует центральную оркестрацию (orchestration), а не внутреннюю логику сервиса (03.05.06 Event-Driven Architecture — для сравнения с choreography).
  • Скелет фичи — единая точка, куда ссылаются детализирующие артефакты раздела 10.01: stories, API, producer/consumer, экраны, ADR.
  • Покрытие сценариев — happy path, бизнес-альтернативы (alt) и исключения (exception): таймауты, ошибки интеграции, компенсации при saga.
  • Трассировка требований (requirements traceability) — каждый шаг процесса связан с SRS req ID и downstream-спецификациями; проверка полноты — по FR с меткой «сценарий» или «интеграция» в SRS (см. §3.7).

BPMN-шаблон — уровень фичи/эпика (05.02 Scrum и Kanban (аналитик в Agile)), а не единица бэклога. Детали мотивации, контрактов и полей — в соседних артефактах по ссылке.

2. Когда использовать

Подходит, если:

  • фича проходит через несколько систем или bounded context (портал → BFF → сервисы → очередь → внешний провайдер);
  • нужно согласовать сквозной сценарий до детализации API и экранов — «как это едет end-to-end»;
  • в SRS есть раздел «сценарии/потоки», и вы операционализируете его в модель процесса;
  • команда проектирует event-driven или saga-поток с центральной моделью оркестрации — нужны явные async-шаги, correlation id, compensation;
  • QA и dev готовят walkthrough по task ID; процесс — основа интеграционных и E2E-тестов.

Не подходит или требует дополнения, если:

Входные условия: цель и границы зафиксированы в BRD (04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD), 02.01.04 Определение границ решения (Scope Modelling)), роли согласованы (10.01.11 Шаблон ролевой модели), список участников (pools) и внешних систем известен (03.01.02 Моделирование контекста системы (Context Diagram)), термины — в 10.01.14 Шаблон глоссария и словаря данных.

Уровни диаграмм: L0 — collaboration «фича целиком»; L1 — subprocess по домену/системе (обязателен, если на L0 > 15–20 элементов, embedded subprocess с alt/exception/compensation или отдельная команда-владелец pool); L2+ — только при обоснованной необходимости (compliance, сложная компенсация).

3. Структура документа

Скопируйте блок в Camunda Modeler, draw.io, EA или Confluence с BPMN-плагином. Поля с пометкой обяз. нужны для согласования; остальные — по контексту. Минимум: L0-диаграмма + таблица touchpoints + матрица трассировки.

Формат поставки: зафиксируйте в паспорте §3.1 — одна страница Confluence с embed, отдельный .bpmn в репозитории + ссылка в wiki, или оба. Версия в паспорте — текущая; журнал изменений — §3.10. Диаграмму и таблицу шагов версионируйте синхронно (один tag/commit или одна revision страницы). При breaking change контракта или feature flag — bump версии процесса и ссылка на версию API/event в Contract Ref (см. 03.05.07 Управление версионированием API и жизненным циклом).

Правило потоков между pools: sequence flow не пересекает границу pool; между pools — только message flow (или message throw/catch на task). Нарушение — типичная ошибка на L0.

Правило Contract Ref (нормативное): в BPMN и таблице шагов — только ID артефакта (API-xxx, PROD-xxx, US-xxx); поля запроса/ответа, payload и AC — в соответствующих спецификациях (03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)). В BPMN — ID и краткая подпись шага.

3.1. Паспорт фичи (метаданные)

ПолеОбяз.Что писать
Process IDдаУникальный идентификатор, напр. PROC-BPMN-LEAVE-01. Согласован с реестром ID проекта и схемой из 10.01.15 Шаблон матрицы трассировки (PROC-BPMN-xxx).
Название процессадаБизнес-результат: «Согласование заявки на отпуск end-to-end».
Режим моделидаДокументационная / Исполняемая (движок) — см. §1.
Версия, статус, датадаТекущая версия документа: Draft → Review → Approved; автор последнего изменения. Журнал — §3.10.
Владелец (SA)даОтветственный системный аналитик.
Epic / Feature / релиздаРодительская инициатива в backlog или roadmap.
Upstream: BRD / SRSдаBRD-GOAL-xxx, SRS-REQ-xxx — ссылки, не пересказ.
Scope (in)даОдин абзац: что входит в процесс от триггера до завершения.
Out of scopeдаЯвный список: смежные процессы, системы «чёрным ящиком», batch без участия в journey.
Формат поставкидаConfluence / .bpmn в Git / оба; инструмент моделирования.
Alt flows statusда*Есть / N/A. *При N/A — одна строка обоснования («линейный сценарий без бизнес-развилок»).
Версия AS-IS / TO-BEнетЕсли миграция — метка диаграммы и ссылка на legacy-описание.

3.2. Цель и критерии приёмки на уровне процесса

ПолеОбяз.Что писать
Process goalдаИзмеримый end-to-end outcome («заявка согласована, сотрудник и HR получили уведомление»).
Process-level DoDдаКритерии «процесс выполнен успешно» на уровне всего сценария — не дублировать AC из stories (02.04.02 Критерии приёмки (Acceptance Criteria)). Контрпример — не писать: «кнопка „Подать" зелёная», «поле „Комментарий" обязательное» — это AC story, не DoD процесса.
KPI / SLA процессанетСквозное время, процент успешных завершений; детали — 10.01.12 Шаблон нефункциональных требований (NFR).

3.3. Контекст

ПолеОбяз.Что писать
Заинтересованные сторонынетКто заинтересован в результате процесса; не путать с lanes.
Pools (участники)даОтдельный pool = система, bounded context или внешняя организация с собственной границей ответственности и message flow наружу.
Lanes (роли/компоненты)даВнутри одного pool: роли из 10.01.11 Шаблон ролевой модели или технические компоненты (FE, BFF, Worker).
AssumptionsнетДопущения («SSO уже внедрён», «справочник отделов актуален»).
ConstraintsнетРегуляторика, legacy, запрет прямого доступа к БД смежного сервиса.

Правило pool vs lane: FE и BFF одного продукта — lanes в одном pool, если общая граница деплоя/команды и нет message flow между ними (только sequence flow). Отдельный pool — когда у компонента свой контракт с внешним потребителем, отдельная команда-владелец или bounded context по DDD. Не смешивайте «систему целиком» и «отдельный микросервис» без явного правила — зафиксируйте в decision log §3.10.

3.4. Диаграмма collaboration (L0)

ПолеОбяз.Что писать
Диаграмма L0даPools = системы/bounded context; lanes = роли; message flows между pools; sequence flows только внутри pool. Data Object Reference — для ключевых сущностей, согласованных с 10.01.14 Шаблон глоссария и словаря данных.
Триггер стартадаStart event: «сотрудник нажал Подать», «получено сообщение topic X», timer.
Условия завершениядаEnd events: успех, отмена пользователем, терминальная ошибка; не один «End» без семантики.
Embedded subprocess L1нет*Вложенная диаграмма этой же фичи; в L0 — collapsed subprocess с Process Ref на L1. *Обязателен при критериях из §2 (перегруз L0, alt/exception внутри pool).
Call ActivityнетВызов переиспользуемого процесса другой фичи: Call Activity → PROC-BPMN-xxx (напр. общий блок «Идентификация клиента»). Не путать с embedded subprocess.
Multi-instanceнет*Parallel/sequential multi-instance для «все N согласующих» / «любой из группы»; loop characteristics + completion condition. *При параллельном согласовании несколькими ролями.
Sync vs asyncдаНа каждом message flow между pools — annotation: sync (REST/SOAP, request-response) или async (событие, очередь). Для async дополнительно: correlation id, topic/queue ref — §3.5 и §3.7.

Элементы нотации — 06.02.01 Потоки, шлюзы, события, 06.02.02 Пулы, дорожки и артефакты, паттерны — 06.02.03 Типовые паттерны BPMN. Для исполняемого режима: типы task, delegate, external task, retry — 06.02.04 Работа с Camunda.

3.5. Описание потоков (таблица шагов)

Для каждого Task / SubProcess / User Task / Call Activity на L0 (и при необходимости L1):

ПолеОбяз.Что писать
Task IDдаИдентификатор на диаграмме: T-01, T-02 — стабильный для трассировки.
Название / типдаUser Task, Service Task, Send/Receive Task, SubProcess, Call Activity; краткая подпись. В исполняемом режиме для Service Task — implementation ref по 06.02.04 Работа с Camunda.
Pool / LaneдаГде выполняется шаг.
Назначениеда1–2 предложения: что делает шаг в бизнес-смысле.
Preconditions / Postconditionsнет*Факты до/после шага; для интеграций — ожидаемое состояние данных и доменного объекта. *Обязательно для async и exception/retry-веток.
Вход / выход (данные)да*Ключевые data objects: requestId, leaveRequest, correlation id; имена — из глоссария. *Обязательно для async.
Touchpoint / Contract Refда*Ссылка на артефакт: US-0247, API-LEAVE-003, PROD-LEAVE-001, FE-LEAVE-FORM-01; для контрактов — 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf). *На каждый task, затрагивающий систему.
Security / authнет*AuthN/AuthZ, step-up, маскирование PII на шаге — ID из 10.01.11 Шаблон ролевой модели или 08.07 Основы кибербезопасности для системного аналитика. *При доступе к данным или внешним системам.
Gateway / условиенетБизнес-формулировка на шлюзе: «баланс достаточен»; коды ошибок — в API spec.
Rollout / feature flagнетAnnotation «активно с релиза X», версия контракта (API-LEAVE-003 v2) или ссылка на ADR при поэтапном включении и breaking change.

AC stories остаются в 10.01.01 Шаблон User Story; см. нормативное правило Contract Ref в начале §3.

3.6. Happy path, альтернативы и исключения

ПолеОбяз.Что писать
Happy pathдаНумерованный список Task ID от start до success end или таблица «шаг → следующий шаг».
Alternative flows (alt)да*Бизнес-ветки по решению участника или правилу: «руководитель отклонил», «требуется доработка» — exclusive gateway + task ID ветки. *Если в паспорте Alt flows status = N/A — не заполнять; обоснование в §3.1.
Exception flowsдаТехнические сбои: ошибка интеграции, timeout, недоступность внешней системы; error boundary events, ручные task эскалации; postcondition после retry — явно. Бизнес-отказ («отклонить заявку») — alt, не exception.
Compensation / rollbackнет*При saga — шаги отмены и порядок; ссылка на 10.01.13 Шаблон архитектурного решения (ADR). *Обязательно при распределённых транзакциях.
События и таймерынетIntermediate timer («ожидание ответа 24 ч»), message catch; SLA и эскалации — связь с NFR.

3.7. Матрица трассировки (touchpoint matrix)

ПолеОбяз.Что писать
Матрица Step ↔ артефактыдаСтроки: Task ID. Уникальные для BPMN-колонки: Process ID, sync/async, correlation id. Общие с 10.01.15 Шаблон матрицы трассировки: SRS req ID, US, UC, API, Producer, Consumer, FE, ADR, test case — заполняйте по правилам 10.01.15, не изобретайте свои названия колонок.
Correlation / idempotencyда*Сквозные идентификаторы для async: processInstanceId, messageId, orderId. *При очередях и event-driven.
Правило покрытия SRSдаFR сквозного сценария помечены типом «сценарий» или «интеграция» (02.03.01 Классификация требований (БТ, ФТ, НФТ)). Кто заводит метку: аналитик при создании/обновлении SRS (поле «тип FR» в шаблоне SRS или тег в ALM — зафиксируйте в реестре проекта). На review: каждый такой FR имеет ≥1 Step ID; каждый task с touchpoint ссылается на FR или явный gap TBD.

Концепция трассировки — 02.03.04 Трассировка требований (концепция).

3.8. Состояния доменного объекта (optional)

ПолеОбяз.Что писать
State machine / таблица переходовнетСтатусы сущности (напр. заявка) с привязкой к Task ID; согласовано с 03.02.04 Диаграмма состояний (State Machine Diagram).

3.9. NFR-срез процесса

ПолеОбяз.Что писать
End-to-end latencyнетСквозное время happy path; пошаговые p95 — в NFR-документе.
Доступность / аудит / PIIнетID из 10.01.12 Шаблон нефункциональных требований (NFR) с привязкой к шагам.
IdempotencyнетКакие шаги идемпотентны; ссылка на ADR или API spec.

3.10. Риски, открытые вопросы, decision log

ПолеОбяз.Что писать
Open questionsнетЧто блокирует детализацию API/контрактов.
Risksнет«Нет compensation при отказе платёжного шлюза» — с mitigations; методика — 08.05 Управление рисками на этапе анализа.
Decision logнетРазвилки sync vs async, orchestration vs choreography, pool/lane, выбор saga — 10.01.13 Шаблон архитектурного решения (ADR).
История измененийдаЖурнал: версия, дата, автор, что изменилось; impact на матрицу, Contract Ref и версии контрактов. Текущая версия — в паспорте §3.1.

3.11. Чеклист качества перед Review

4. Пример заполнения

Сокращённый фрагмент для HR Portal — процесс «Оформление и согласование заявки на отпуск» (данные условны). Базовый сценарий — v1.0 (один согласующий — руководитель); вариант v1.1 — в конце.

Паспорт. PROC-BPMN-LEAVE-01 · Оформление и согласование заявки на отпуск · Режим: Документационная · v1.0 · Review · SA: И. Петров · Epic EP-015 · BRD BRD-GOAL-011, BRD-GOAL-012 · SRS SRS-REQ-038–045 · Поставка: Confluence + .bpmn в Git · Alt flows: Есть.

Scope. Сотрудник подаёт заявку в портале → сервис отпусков валидирует и сохраняет → руководитель согласует → уведомления сотруднику и HR. Out of scope: интеграция с 1С:ЗУП; отмена заявки (PROC-BPMN-LEAVE-02); batch-пересчёт баланса (10.01.10 Шаблон описания Airflow-триггеров и автоматических процессов).

Process goal. Заявка прошла путь от «Черновик/Новая» до «Согласована» или «Отклонена»; все участники получили уведомления; audit trail полный.

Process-level DoD. Happy path завершается за ≤ 2 рабочих дня при нормальной нагрузке; при ошибке интеграции заявка не остаётся в «зависшем» статусе без эскалации. (Не сюда: валидация полей формы — AC US-0238.)

Pools и lanes. Pool «Leave Service». Pool «HR Portal» — lanes: Сотрудник, Руководитель, BFF. Pool «Notification Hub». Pool «Email» — чёрный ящик без процесса.

L0:

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" id="Definitions_leave" targetNamespace="http://bpmn.io/schema/bpmn" exporter="Camunda Modeler" exporterVersion="5.0.0">
  <bpmn:collaboration id="Collaboration_leave"><bpmn:participant id="leave" name="Leave Service" processRef="process_leave" /><bpmn:participant id="hrp" name="HR Portal" processRef="process_hr" /><bpmn:participant id="hub" name="Notification Hub" processRef="process_hub" /><bpmn:participant id="mail" name="Email" /><bpmn:messageFlow id="Message_0" name="Заявка" sourceRef="lv_form" targetRef="lv_in" /><bpmn:messageFlow id="Message_1" name="На согласование" sourceRef="lv_pub" targetRef="lv_rev" /><bpmn:messageFlow id="Message_2" name="Согласована" sourceRef="lv_save" targetRef="lv_note" /><bpmn:messageFlow id="Message_3" name="Отклонена" sourceRef="lv_rej" targetRef="lv_note" /><bpmn:messageFlow id="Message_4" name="Письмо" sourceRef="lv_mail" targetRef="mail" /></bpmn:collaboration>
  <bpmn:process id="process_leave" name="Leave Service" isExecutable="false"><bpmn:laneSet id="LaneSet_leave"><bpmn:lane id="ls" name="1. Сервис отпусков"><bpmn:flowNodeRef>lv_in</bpmn:flowNodeRef><bpmn:flowNodeRef>lv_val</bpmn:flowNodeRef><bpmn:flowNodeRef>lv_pub</bpmn:flowNodeRef></bpmn:lane></bpmn:laneSet><bpmn:startEvent id="lv_in" name="1.1"><bpmn:outgoing>Flow_1</bpmn:outgoing><bpmn:messageEventDefinition id="lv_in_def" /></bpmn:startEvent><bpmn:serviceTask id="lv_val" name="1.2 Проверить&#10;заявку"><bpmn:incoming>Flow_1</bpmn:incoming><bpmn:outgoing>Flow_2</bpmn:outgoing></bpmn:serviceTask><bpmn:sendTask id="lv_pub" name="1.3 Передать&#10;на согласование"><bpmn:incoming>Flow_2</bpmn:incoming></bpmn:sendTask><bpmn:sequenceFlow id="Flow_1" sourceRef="lv_in" targetRef="lv_val" /><bpmn:sequenceFlow id="Flow_2" sourceRef="lv_val" targetRef="lv_pub" /></bpmn:process><bpmn:process id="process_hr" name="HR Portal" isExecutable="false"><bpmn:laneSet id="LaneSet_hrp"><bpmn:lane id="fe" name="1. Сотрудник"><bpmn:flowNodeRef>lv_s</bpmn:flowNodeRef><bpmn:flowNodeRef>lv_form</bpmn:flowNodeRef></bpmn:lane><bpmn:lane id="mgr" name="2. Руководитель"><bpmn:flowNodeRef>lv_rev</bpmn:flowNodeRef><bpmn:flowNodeRef>lv_g</bpmn:flowNodeRef></bpmn:lane><bpmn:lane id="bff" name="3. BFF"><bpmn:flowNodeRef>lv_save</bpmn:flowNodeRef><bpmn:flowNodeRef>lv_rej</bpmn:flowNodeRef></bpmn:lane></bpmn:laneSet><bpmn:startEvent id="lv_s" name="1.1"><bpmn:outgoing>Flow_0</bpmn:outgoing></bpmn:startEvent><bpmn:userTask id="lv_form" name="1.2 Заполнить&#10;заявку"><bpmn:incoming>Flow_0</bpmn:incoming></bpmn:userTask><bpmn:userTask id="lv_rev" name="2.1 Рассмотреть&#10;заявку"><bpmn:outgoing>Flow_3</bpmn:outgoing></bpmn:userTask><bpmn:exclusiveGateway id="lv_g" name="2.2 Согласовано?"><bpmn:incoming>Flow_3</bpmn:incoming><bpmn:outgoing>Flow_4</bpmn:outgoing><bpmn:outgoing>Flow_5</bpmn:outgoing></bpmn:exclusiveGateway><bpmn:serviceTask id="lv_save" name="3.1 Обновить&#10;статус"><bpmn:incoming>Flow_4</bpmn:incoming></bpmn:serviceTask><bpmn:serviceTask id="lv_rej" name="3.2 Сохранить&#10;отказ"><bpmn:incoming>Flow_5</bpmn:incoming></bpmn:serviceTask><bpmn:sequenceFlow id="Flow_0" sourceRef="lv_s" targetRef="lv_form" /><bpmn:sequenceFlow id="Flow_3" sourceRef="lv_rev" targetRef="lv_g" /><bpmn:sequenceFlow id="Flow_4" name="да" sourceRef="lv_g" targetRef="lv_save" /><bpmn:sequenceFlow id="Flow_5" name="нет" sourceRef="lv_g" targetRef="lv_rej" /></bpmn:process><bpmn:process id="process_hub" name="Notification Hub" isExecutable="false"><bpmn:laneSet id="LaneSet_hub"><bpmn:lane id="nh" name="1. Уведомления"><bpmn:flowNodeRef>lv_note</bpmn:flowNodeRef><bpmn:flowNodeRef>lv_mail</bpmn:flowNodeRef></bpmn:lane></bpmn:laneSet><bpmn:receiveTask id="lv_note" name="1.1 Принять&#10;статус"><bpmn:outgoing>Flow_6</bpmn:outgoing></bpmn:receiveTask><bpmn:sendTask id="lv_mail" name="1.2 Отправить&#10;письмо"><bpmn:incoming>Flow_6</bpmn:incoming></bpmn:sendTask><bpmn:sequenceFlow id="Flow_6" sourceRef="lv_note" targetRef="lv_mail" /></bpmn:process>
  <bpmndi:BPMNDiagram id="BPMNDiagram_leave">
    <bpmndi:BPMNPlane id="BPMNPlane_leave" bpmnElement="Collaboration_leave">
      <bpmndi:BPMNShape id="leave_di" bpmnElement="leave" isHorizontal="true"><dc:Bounds x="80" y="40" width="1618" height="166" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="ls_di" bpmnElement="ls" isHorizontal="true"><dc:Bounds x="110" y="40" width="1588" height="166" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="hrp_di" bpmnElement="hrp" isHorizontal="true"><dc:Bounds x="80" y="296" width="1618" height="656" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="fe_di" bpmnElement="fe" isHorizontal="true"><dc:Bounds x="110" y="296" width="1588" height="166" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="mgr_di" bpmnElement="mgr" isHorizontal="true"><dc:Bounds x="110" y="462" width="1588" height="166" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="bff_di" bpmnElement="bff" isHorizontal="true"><dc:Bounds x="110" y="628" width="1588" height="324" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="hub_di" bpmnElement="hub" isHorizontal="true"><dc:Bounds x="80" y="1042" width="1618" height="166" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="nh_di" bpmnElement="nh" isHorizontal="true"><dc:Bounds x="110" y="1042" width="1588" height="166" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="mail_di" bpmnElement="mail" isHorizontal="true"><dc:Bounds x="80" y="1298" width="1618" height="120" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lv_in_di" bpmnElement="lv_in"><dc:Bounds x="352" y="108" width="36" height="36" /><bpmndi:BPMNLabel><dc:Bounds x="357" y="152" width="27" height="14" /></bpmndi:BPMNLabel></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lv_val_di" bpmnElement="lv_val"><dc:Bounds x="544" y="86" width="180" height="80" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lv_pub_di" bpmnElement="lv_pub"><dc:Bounds x="808" y="86" width="180" height="80" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lv_s_di" bpmnElement="lv_s"><dc:Bounds x="153" y="364" width="36" height="36" /><bpmndi:BPMNLabel><dc:Bounds x="158" y="408" width="27" height="14" /></bpmndi:BPMNLabel></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lv_form_di" bpmnElement="lv_form"><dc:Bounds x="280" y="342" width="180" height="80" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lv_rev_di" bpmnElement="lv_rev"><dc:Bounds x="808" y="508" width="180" height="80" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lv_g_di" bpmnElement="lv_g" isMarkerVisible="true"><dc:Bounds x="1072" y="523" width="50" height="50" /><bpmndi:BPMNLabel><dc:Bounds x="1042" y="491" width="110" height="14" /></bpmndi:BPMNLabel></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lv_save_di" bpmnElement="lv_save"><dc:Bounds x="1206" y="674" width="180" height="80" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lv_rej_di" bpmnElement="lv_rej"><dc:Bounds x="1206" y="832" width="180" height="80" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lv_note_di" bpmnElement="lv_note"><dc:Bounds x="1206" y="1088" width="180" height="80" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lv_mail_di" bpmnElement="lv_mail"><dc:Bounds x="1470" y="1088" width="180" height="80" /></bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="Flow_0_di" bpmnElement="Flow_0"><di:waypoint x="189" y="382" /><di:waypoint x="280" y="382" /></bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_1_di" bpmnElement="Flow_1"><di:waypoint x="388" y="126" /><di:waypoint x="544" y="126" /></bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_2_di" bpmnElement="Flow_2"><di:waypoint x="724" y="126" /><di:waypoint x="808" y="126" /></bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_3_di" bpmnElement="Flow_3"><di:waypoint x="988" y="548" /><di:waypoint x="1072" y="548" /></bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_4_di" bpmnElement="Flow_4"><di:waypoint x="1122" y="548" /><di:waypoint x="1296" y="548" /><di:waypoint x="1296" y="674" /><bpmndi:BPMNLabel><dc:Bounds x="1130" y="530" width="24" height="14" /></bpmndi:BPMNLabel></bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_5_di" bpmnElement="Flow_5"><di:waypoint x="1097" y="573" /><di:waypoint x="1097" y="872" /><di:waypoint x="1206" y="872" /><bpmndi:BPMNLabel><dc:Bounds x="1105" y="579" width="27" height="14" /></bpmndi:BPMNLabel></bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_6_di" bpmnElement="Flow_6"><di:waypoint x="1386" y="1128" /><di:waypoint x="1470" y="1128" /></bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Message_0_di" bpmnElement="Message_0"><di:waypoint x="370" y="342" /><di:waypoint x="370" y="180" /><di:waypoint x="370" y="144" /><bpmndi:BPMNLabel><dc:Bounds x="378" y="254" width="46" height="14" /></bpmndi:BPMNLabel></bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Message_1_di" bpmnElement="Message_1"><di:waypoint x="898" y="166" /><di:waypoint x="898" y="202" /><di:waypoint x="898" y="508" /><bpmndi:BPMNLabel><dc:Bounds x="906" y="177" width="104" height="14" /></bpmndi:BPMNLabel></bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Message_2_di" bpmnElement="Message_2"><di:waypoint x="1386" y="714" /><di:waypoint x="1414" y="714" /><di:waypoint x="1414" y="1088" /><di:waypoint x="1296" y="1088" /><bpmndi:BPMNLabel><dc:Bounds x="1361" y="696" width="78" height="14" /></bpmndi:BPMNLabel></bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Message_3_di" bpmnElement="Message_3"><di:waypoint x="1296" y="912" /><di:waypoint x="1296" y="948" /><di:waypoint x="1296" y="1088" /><bpmndi:BPMNLabel><dc:Bounds x="1304" y="923" width="66" height="14" /></bpmndi:BPMNLabel></bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Message_4_di" bpmnElement="Message_4"><di:waypoint x="1560" y="1168" /><di:waypoint x="1560" y="1204" /><di:waypoint x="1560" y="1298" /><bpmndi:BPMNLabel><dc:Bounds x="1568" y="1179" width="46" height="14" /></bpmndi:BPMNLabel></bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</bpmn:definitions>

Триггер. Старт в дорожке «Сотрудник»: заявка ещё не отправлена. Сотрудник заполняет её и передаёт в Leave Service. Завершение на L0. Notification Hub отправляет письмо в чёрный ящик Email. Развилка «Согласовано?» ведёт либо к обновлению статуса, либо к сохранению отказа. Таблица ниже — те же шаги с идентификаторами; исключения из неё на этой диаграмме не развёрнуты.

Happy path v1.0 (Task ID): T-01 → T-02 → T-03 → T-04 → T-05 → T-06 → T-07 → E-OK.

Task IDШагTouchpoint
T-01Сотрудник заполняет формуFE-LEAVE-FORM-01, US-0238
T-02BFF вызывает создание заявкиAPI-LEAVE-001 (sync)
T-03Leave Service валидирует балансUC-LEAVE-012, SRS-REQ-038
T-04Публикация события «submitted»PROD-LEAVE-001 (async)
T-05Руководитель согласует в спискеFE-LEAVE-LIST-02, US-0247
T-06Обновление статуса + событиеAPI-LEAVE-003 (sync), PROD-LEAVE-002 (async)
T-07Отправка emailCONS-NOTIF-001 (async)

Alternative (v1.0): Gateway G-01 «Решение руководителя» → ветка «Отклонить» → T-08 (комментарий обязателен) → E-REJ. Бизнес-отказ — alt, не exception.

Exception (v1.0): T-04 — error boundary «Очередь недоступна» → T-04a outbox retry (ADR-042) → при успешной публикации переход к T-05. Postcondition после retry: статус заявки «На согласовании», событие submitted доставлено; T-05 не блокируется — руководитель видит заявку в списке. При исчерпании retry — эскалация, статус остаётся «Черновик/Ошибка публикации», T-05 недоступен. T-06 — timeout 30 с → T-06a ручная task «Поддержка: проверить статус» → E-ERR.

Correlation. leaveRequestId — сквозной ключ; messageId в PROD-LEAVE-001 = {leaveRequestId}-submitted-v1.

Security. T-01 — роль Employee, SSO; T-05 — роль Manager, step-up при сумме > 14 дней.

Состояния заявки: Draft → На согласовании (postcondition T-04) → Согласована (T-06) / Отклонена (T-08).

NFR-срез. NFR-PERF-020 — end-to-end happy path p95 < 5 с до статуса «На согласовании»; NFR-AUDIT-003 — все переходы статусов.

Матрица (фрагмент):

StepSRSUSAPI / EventFETest
T-02REQ-039US-0238API-LEAVE-001FE-LEAVE-FORM-01TC-E2E-LEAVE-003
T-05REQ-045US-0247API-LEAVE-003FE-LEAVE-LIST-02TC-E2E-LEAVE-012

Вариант v1.1 (отдельная версия процесса, не смешивать с v1.0): параллельное согласование HR + руководитель — parallel multi-instance на T-05, completion condition: completed = 2; bump процесса до v1.1, обновление US-0247 и API-LEAVE-003 v2.

5. Связанные артефакты

На входе (upstream)

АртефактСвязь
Vision & Scope, BRDЦель процесса, границы ценности, бизнес-правила верхнего уровня — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)
SRSFR с типом «сценарий»/«интеграция» (метку заводит аналитик в SRS) получают Process Step ID
10.01.11 Шаблон ролевой моделиLanes и User Task
10.01.14 Шаблон глоссария и словаря данныхИмена сущностей, Data Object Reference на L0
03.01.02 Моделирование контекста системы (Context Diagram)Список pools и внешних систем
10.01.02 Шаблон Use CaseUC как subprocess или touchpoint внутри task
10.01.01 Шаблон User StoryStories как шаги или результаты task

На выходе (downstream)

АртефактКогда создавать
10.01.04 Шаблон спецификации REST API / 10.01.05 Шаблон спецификации SOAP APIКаждый sync message flow / service task с HTTP/SOAP
10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ) / 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ)Send/receive task, message flows между pools
10.01.09 Шаблон описания экранной формы и логики на FEUser Task с UI
10.01.03 Шаблон спецификации БД сервисаИзменения persistence по шагам с записью данных
10.01.12 Шаблон нефункциональных требований (NFR)SLA, latency, аудит, PII на уровне процесса
10.01.13 Шаблон архитектурного решения (ADR)Saga, sync vs async, outbox, compensation, choreography
10.01.10 Шаблон описания Airflow-триггеров и автоматических процессовBatch-ветки, не перегружающие customer journey
10.01.15 Шаблон матрицы трассировкиСводная RTM: goal → process step → spec → test

Типичный порядок работы аналитика

  1. Цель и scope из BRD → режим модели + черновик L0 (pools, happy path, start/end); правило pool/lane — в decision log.
  2. Согласование с архитектурой: sync/async, orchestration vs choreography, ADR на развилках.
  3. Метки «сценарий»/«интеграция» в SRS → заполнение touchpoint matrix → параллельная детализация API, events, FE по task ID.
  4. Добавление alt и exception paths с postconditions; привязка NFR, security и состояний доменного объекта.
  5. Review walkthrough с dev/QA; проверка по 10.04 Чеклист аналитика перед стартом разработки; обновление матрицы при изменении контрактов (02.05.02 Управление изменениями (Change Control Board) при формальном change control).

Как не дублировать соседние шаблоны

АртефактВ BPMNДетали — в
User Story / Use CaseID + краткая подпись task10.01.01 / 10.01.02
REST/SOAP/KafkaMessage throw/catch или «Вызвать X» + Contract Ref10.01.04–07
Экран FEUser Task + ссылка10.01.09
ADRAnnotation или decision log10.01.13
Версионирование API, feature flagsВерсия в Contract Ref + ADR10.01.13, 03.05.07 Управление версионированием API и жизненным циклом
Переиспользуемый subprocessCall Activity → PROC-BPMN-xxxДругая фича или общий процесс

6. Связи с другими разделами базы

Дополнительно к ссылкам в §2–§5 и таблицах §3:

7. Источники и дополнительные материалы

Спецификации

Статьи и практики

Книги и стандарты