BPMN и требования на собеседовании системного аналитика
Зачем SA знать BPMN и требования
Требования — это «что строить». SA переводит бизнес-задачу («хочу автоматизировать выдачу кредита») в техническое описание для команды: какие шаги, какие участники, какие интеграции, какие edge cases. Это половина работы аналитика.
На собесе системного аналитика BPMN и требования — отдельный раунд 45-60 минут. Уровень: junior — формализует простые процессы; middle — рисует BPMN с gateways, exceptions; senior — управляет цепочкой требований от business case до acceptance criteria.
Виды требований
Бизнес-требования. Зачем делать, какой outcome. «Снизить time-to-approve кредита с 24h до 1h».
Пользовательские требования. Что хочет конкретный actor. «Менеджер хочет видеть список pending заявок».
Функциональные требования. Что система должна делать. «Система отправляет SMS клиенту при изменении статуса заявки».
Нефункциональные требования. Качество. «Время отклика < 200ms». «Доступность 99.9%».
Иерархия: business → user → functional + non-functional → technical.
Use cases
Use case — сценарий взаимодействия actor-а с системой.
Use case: Оформить заказ
Actor: Покупатель
Precondition: Авторизован, корзина не пуста
Main flow:
1. Покупатель открывает корзину
2. Выбирает способ доставки
3. Выбирает способ оплаты
4. Подтверждает заказ
5. Система создаёт заказ и отправляет email
Alternative flows:
2a. Адрес доставки невозможен → показать ошибку, вернуться к шагу 1
3a. Оплата отклонена → показать причину, вернуться к шагу 3
Postcondition: Заказ создан, статус "pending"Use cases описывают «что» делает система с точки зрения пользователя, без «как».
BPMN — основы
BPMN (Business Process Model and Notation) — стандарт нотации бизнес-процессов.
Базовые элементы:
Events (события):
- Start event — начало процесса (тонкая окружность)
- End event — конец (жирная окружность)
- Intermediate event — внутри процесса (двойная окружность)
- Timer event — задержка/расписание
- Message event — отправка/приём сообщения
Activities (задачи):
- Task — атомарное действие (прямоугольник)
- Subprocess — вложенный процесс (прямоугольник с «+»)
- Service task — выполнение системой
- User task — действие пользователя
- Manual task — вне системы
Gateways (развилки):
- Exclusive (XOR, ромб с «X») — один из путей
- Parallel (AND, ромб с «+») — все пути параллельно
- Inclusive (OR, ромб с «O») — любая комбинация
- Event-based — выбор по событию
Flows:
- Sequence flow — последовательность шагов
- Message flow — между процессами / pools
- Association — связь с артефактами
Pools и lanes — кто выполняет (отдел, система, человек).
Подробнее — BPMN gateways.
Acceptance criteria
AC — конкретные критерии, по которым проверяется готовность фичи.
Формат Given-When-Then
Given <предусловие>
When <действие>
Then <результат>Пример:
Given юзер с подтверждённой почтой
When он отправляет запрос на сброс пароля
Then email с одноразовой ссылкой приходит в течение 30 секунд
And ссылка действительна 24 часаПреимущества:
- Тестируемые (можно автоматизировать)
- Понятные бизнесу и QA
- Гарантия что не упустили edge case
Подробнее — Acceptance criteria (Given-When-Then).
As-is / To-be
Описание текущего состояния процесса (as-is) и желаемого (to-be).
Зачем:
- Видим, что меняется
- Можем посчитать ROI
- Бизнес понимает, чего ждать
Подход: As-is BPMN → проблемы и узкие места → To-be BPMN → план миграции.
Подробнее — As-is / To-be.
ER-diagram
Диаграмма сущностей и связей. Основа моделирования данных.
Сущности (Entity): объекты предметной области. Customer, Order, Product.
Атрибуты: свойства сущности. У Customer — name, email, phone.
Связи (Relationship): 1-to-1, 1-to-many, many-to-many.
Кардинальность: «у каждого Customer 0 или больше Order».
Нотация Chen (классическая, ромбы для связей) или Crow's foot (популярнее в современных инструментах).
C4-model
Уровни диаграмм архитектуры:
Level 1 — System Context. Что за система, какие external actors и systems.
Level 2 — Container. Apps, БД, очереди. Как они общаются.
Level 3 — Component. Внутри одного container — модули.
Level 4 — Code. Классы (редко используется).
Хорошо для коммуникации архитектуры с разными аудиториями: бизнес видит L1, инженеры — L2-L3.
Подробнее — C4-model на собесе SA.
Типичные вопросы
«Спроектируй процесс оформления кредита через BPMN»
Шаги: заявка → KYC → скоринг → решение → если approved → выдача / если rejected → уведомление.
Gateways: после скоринга — exclusive (approved / rejected). Параллельно — KYC и проверка credit history.
«Опиши acceptance criteria для "отменить заказ"»
AC1: Given заказ в статусе "pending"
When юзер нажимает "отменить"
Then статус меняется на "cancelled"
And возврат денег инициируется через X
And email с подтверждением приходит в течение 10 минут
AC2: Given заказ в статусе "shipped"
When юзер пытается отменить
Then возвращается ошибка "невозможно отменить отправленный заказ"
And предлагается опция возврата«Чем functional req отличается от non-functional?»
Functional — «что делает». Non-functional — «как делает». Например, «отправить SMS» — functional. «За 5 секунд, доступность 99.9%» — non-functional.
«Что такое POC vs MVP?»
POC (Proof of Concept) — техническая проверка идеи на feasibility. MVP (Minimum Viable Product) — минимальный продукт для проверки гипотезы на рынке.
«Как обработать exception в BPMN?»
Через error boundary event на activity. Если activity бросает error, выходим через альтернативный path. Также через timer boundary event для timeout-ов.
Частые ошибки
- Use case без alternative flow. Реальные процессы имеют ошибки, exceptions, edge cases. Описать только happy path — половина работы.
- AC без измеримости. «Быстро работает» — не AC. «<200ms p95» — AC.
- BPMN как PowerPoint. BPMN — нотация. Стрелочки и квадратики — это не BPMN.
- Игнорировать non-functional. «Сделать функцию» без latency / availability / security — недо-требования.
- Технические детали в требованиях. «Использовать Redis для кеша» — это решение, не требование. Требование: «время отклика < 100ms».
FAQ
Какой инструмент для BPMN?
Camunda Modeler (бесплатный), Bizagi, draw.io, Lucidchart. На собесе обычно достаточно нарисовать на доске.
Нужно ли уметь рисовать BPMN наизусть?
Не наизусть. Знать основные элементы (start/end events, gateways, tasks, pools) — да. Сложные паттерны (compensation, event-based gateway) — на senior.
Как практиковаться?
Возьми реальный процесс из жизни (заказ Wildberries, перевод денег) и нарисуй BPMN. Обсуди с другом или ChatGPT.
Спрашивают ли UML?
Реже, чем BPMN. UML — для технических диаграмм (sequence, class). SA чаще использует BPMN для бизнес-процессов и ER для данных.
Сколько готовиться?
Junior — 1-2 месяца. Middle — 2-3 недели.