Модуль 0.1. Профиль компетенций системного аналитика (SA)
Ваша задача как системного аналитика — превратить разрозненные ожидания бизнеса и технические ограничения платформы в согласованные, тестируемые и внедряемые решения. В модуле вы зафиксируете собственную зону ответственности, отграни́чите её от ролей BA/PO/архитектора/разработчиков/QA, поймёте, какие артефакты вы обязаны выпускать и как встроены в SDLC/PDLC. На выходе — RACI-матрица проекта, которой можно руководствоваться в ежедневной работе.
Роль и зона ответственности SA — «как есть» и «как должно быть»
Ключевая миссия SA: обеспечить техническую реализуемость и согласованность решения — от требований и моделей до контрактов API, данных и нефункциональных требований (NFR).
Вы отвечаете за:
- Формализацию требований (функциональные и нефункциональные) до уровня инженерных спецификаций.
- Моделирование процессов (BPMN), правил (DMN), сценариев (Use Case), взаимодействий (UML sequence), компонентов (C4).
- Данные и интеграции: ER-модель, словарь и глоссарий, API-контракты (OpenAPI), события, очереди, схемы сообщений.
- Трассируемость: RTM (requirements traceability matrix) от цели → функционал/процесс → API/данные → тесты → мониторинг.
- Качество требований: однозначность, полнота, проверяемость, согласованность внутренних моделей.
- Участие в приёмке: критерии, BDD-сценарии, UAT-план, дефекты «требований».
Вы НЕ (в одиночку) отвечаете за:
- Приоритизацию портфеля и бизнес-value (это зона PO/BA), но вы даёте техоценку/риски.
- Архитектурные стандарты и целевую архитектуру предприятия (это зона архитектора), но вы формализуете требования к архитектуре и фиксируете решения в моделях/контрактах.
- Реализацию и покрытие юнит-тестами (Dev), системное тестирование (QA), но вы определяете, что должно быть протестировано и принято.
Границы со смежными ролями (BA, Архитектор, Dev, QA, PO)
- BA (бизнес-аналитик): формулирует бизнес-цели, ограничения домена, правила, KPI; вы превращаете это в инженерные артефакты (BPMN/DMN/ER/API/NFR).
- PO/PM: управляет бэклогом/приоритетами/дедлайнами; вы даёте техоценки, зависимости, риски, готовите DoR/DoD.
- Архитектор: определяет целевые принципы, паттерны и ограничения; вы адаптируете требования и контракты к этим рамкам, согласуете C4/интеграции.
- Разработчики: реализуют; вы даёте контракты и спецификации, участвуете в grooming/3-Amigos (Dev-QA-SA), уточняете вопросы.
- QA: тестирует; вы обеспечиваете тестируемость требований, выдаёте критерии приемки и BDD-сценарии, участвуете в UAT.
RACI: как закрепить ответственность прозрачно
RACI — Responsible (исполнитель), Accountable (владелец результата), Consulted (консультируемые), Informed (уведомляемые).
Шаги построения RACI
- Выпишите ключевые активности SDLC/PDLC (см. раздел ниже).
- Согласуйте роли проекта: PO, BA, SA, Архитектор, Dev Lead, QA Lead, DevOps/Data/UX.
- На каждую активность назначьте ровно одного A (владелец результата), распределите R, определите C и I.
- Проверьте коллизии: нет ли «двух A», нет ли активностей без A или без R, нет ли перегруза одной роли.
Пример RACI (фрагмент) — кейс «Онлайн-оплата в e-commerce»
|
Активность |
PO |
BA |
SA |
Архитектор |
Dev Lead |
QA Lead |
DevOps |
|---|---|---|---|---|---|---|---|
|
Бизнес-цели/метрики |
A |
R |
C |
I |
I |
I |
I |
|
Обследование «as-is» |
C |
A/R |
R |
C |
I |
I |
I |
|
BPMN/DMN «to-be» |
I |
C |
A/R |
C |
C |
C |
I |
|
NFR (производительность/безопасность) |
C |
C |
A/R |
C |
C |
C |
I |
|
ER/глоссарий/события |
I |
C |
A/R |
C |
C |
C |
I |
|
API (OpenAPI) |
I |
C |
A/R |
C |
R |
C |
I |
|
Архитектурное решение |
C |
I |
C |
A/R |
C |
I |
I |
|
План тестов/UAT критерии |
I |
C |
A/R |
I |
C |
R |
I |
|
План релиза/фича-флаги |
A |
I |
C |
C |
R |
C |
C/R |
В реальном проекте матрица будет шире (мониторинг, фрод-правила, отчётность, инциденты, обратная связь от пользователей).
SDLC/PDLC: что делает SA на каждом этапе
SDLC (Software Development Life Cycle) — жизненный цикл разработки; PDLC — жизненный цикл продукта (шире, включает стратегию, метрики, эксплуатацию).
|
Этап |
Цель |
Что делает SA |
Основные артефакты |
|---|---|---|---|
|
Discovery / Инициирование |
Понять проблему и ограничения |
Уточняет бизнес-цели, границы, риски интеграций |
Vision (1–2 стр.), high-level BPMN/C4 Level 1 |
|
Inception / Анализ |
Формализовать требования |
BPMN as-is/to-be, DMN, глоссарий, ER, NFR, риски |
SRS черновик, RTM v1, глоссарий, ER v1 |
|
Design / Проектирование |
Подготовить спецификации для Dev |
OpenAPI/события, модели последовательностей, C4 L2–L3, NFR измеримые |
SRS v2, OpenAPI v1, схемы событий, NFR-каталог |
|
Implementation / Реализация |
Уточнение и контроль соответствия |
Участвует в grooming, отвечает на вопросы, ведёт RTM |
Обновлённые спецификации, RTM v2 |
|
Testing / Приёмка |
Проверить тестируемость и критерии |
Пишет критерии приемки, BDD-сценарии, сопровождает UAT |
AC/BDD, UAT-план, отчёт о несоответствиях требований |
|
Release / Эксплуатация |
Гарантировать наблюдаемость и SLA |
Уточняет SLI/SLO/алерты, требования к логам/трассировкам |
Спецификация Observability, требования к аудит-логам |
|
Growth / Эволюция |
Улучшать по данным |
Анализирует инциденты/метрики, вносит изменения в SRS/контракты |
Change Requests, версия SRS/OpenAPI |
Артефакты SA: состав, «минимум жизнеспособности», типичные ошибки
SRS (System Requirements Specification).
Минимум: цели, границы, словарь, функциональные требования (сценарии/правила), NFR, интеграции, модели (BPMN/UML/ER), критерии приемки.
Ошибки: двусмысленность («быстро», «удобно»), отсутствие источников данных, нет связи с тестами.
BPMN/DMN.
Минимум: ветвления и ошибки, роли/пулы, события; в DMN — hit-policy, входы/выходы, примеры.
Ошибки: смешение бизнес-процесса и UI-потоков, «ручные» шаги без акторов/систем.
ER + Глоссарий.
Минимум: первичные/внешние ключи, кардинальности, дефиниции терминов.
Ошибки: атрибуты без типов и доменов, отсутствие версионирования справочников.
API (OpenAPI) / События.
Минимум: ресурсы/методы, схемы, коды ошибок, пагинация/фильтры, версии, безопасность (OAuth2/JWT), лимиты.
Ошибки: неуказанные поля «nullable», нет идемпотентности, отсутствие схем событий и ключей корреляции.
NFR (производительность/надёжность/безопасность/наблюдаемость).
Минимум: измеримые SLO (p95-latency, RPS, error-rate), RTO/RPO, требования к логам/метрикам/трейсам.
Ошибки: «быстро/надёжно» вместо метрик, нет деградационных режимов.
RTM (Traceability).
Минимум: связь «цель → требование → модель/контракт → тест → мониторинг».
Ошибки: RTM не обновляется при изменениях, отрывается от кода тестов и алертов.
Уровни зрелости: личные и процессные
Личная зрелость SA (самооценка):
- L1 (Junior): знает нотации и структуру SRS, умеет документировать простые сценарии, делает ER «одним доменом», нуждается в наставнике.
- L2 (Middle): ведёт несколько доменов, владеет OpenAPI/событиями, держит RTM, умеет договариваться о границах, формулирует измеримые NFR.
- L3 (Senior/Lead): проектирует сквозные решения, управляет рисками и изменениями, формирует стандарты артефактов, менторит команду.
Зрелость процесса требований (командная):
- M0: требований «нет», всё в чатах.
- M1: есть шаблоны, часть моделей, RTM эпизодический.
- M2: полная трассируемость, версии артефактов, интеграция с тестами/мониторингом.
- M3: метрики качества требований, автоматизированные проверки (lint для OpenAPI/JSON-Schema), практики 3-Amigos.
Практические примеры
Пример A: «Оплата картой и Apple/Google Pay»
- Цели: конверсия оплаты +2 п.п., отказов < 0,5 %, p95 платежа < 3 c.
- BPMN to-be: «Создать заказ → Выбрать способ оплаты → Редирект/SDK → 3DS/биометрия → Callback → Чек → Отразить статус».
- NFR: p95 < 3 c, timeout PSP 10 c, retry с экспоненциальной паузой до 3 раз, идемпотентность по ключу Payment-Idempotency-Key.
- API: POST /payments (идемпотентный), GET /payments/{id}, Webhook /payments/callback.
- События: PaymentAuthorized, PaymentCaptured, PaymentFailed (ключ корреляции — orderId).
- Observability: метрики payments_latency_p95, payments_error_rate, трассировка через trace-id на редиректах.
Пример B: DWH/BI интеграция для «Продажи/Возвраты»
- ER: Order, OrderItem, Payment, Refund, Customer.
- CDC: из OLTP → витрина «Fct_Sales»; SLA выгрузки 15 мин, дедупликация по orderId+itemId.
- API выгрузок: GET /export/sales?fromTs=...&toTs=... с пагинацией и лимитом, подписка на событие OrderChanged.
Риски и анти-паттерны
- Размытые NFR. Результат: «медленно/падает» в проде. → Делайте SLO/SLI, описывайте деградации (offloading, очереди, fallback).
- Без RTM. Потерялась связь «требование→тест/метрика». → Ведите RTM как живой артефакт.
- Смещение роли SA в «секретаря». Только протоколирует. → Берите ответственность за инженерную спецификацию.
- Артефакты без версий. Разрабы реализуют старое. → Версионируйте SRS/OpenAPI/ER, помечайте breaking changes.
- Перемоделирование. 20 диаграмм без ценности. → Отдавайте приоритет тем моделям, которые нужны Dev/QA прямо сейчас.
- Интеграции без идемпотентности/корреляции. Дубли операций. → Введите ключи идемпотентности и correlation-id.
- Безопасность «потом». → OAuth2/JWT, маскирование PII, аудит-логи, роли и минимальные привилегии — в SRS с первого дня.
Практикум: сделайте свою RACI (задание)
Кейс: «Возврат заказа онлайн».
Шаги:
- Опишите цели и метрики (конверсия возврата, сроки, fraud-контроль).
- Выпишите активности: анализ, BPMN, DMN, ER, API, NFR, тест-план, релиз, мониторинг.
- Заполните RACI на роли: PO, BA, SA, Архитектор, Dev Lead, QA Lead, DevOps, Фрод-офицер, Бухгалтер/Финконтролёр.
- Проверьте «ровно один A» и наличие R, укажите C/I.
Критерии оценки: полнота активностей, отсутствие коллизий RACI, измеримость NFR, связность RTM.
Чек-листы
Чек-лист качества требований (быстрый):
- Требования однозначны, без «быстро/удобно/надёжно».
- Есть измеримые NFR и SLO/SLI.
- Есть BPMN/DMN/ER там, где это снижает риск.
- Контракты API версионированы, ошибки/лимиты/пагинация описаны.
- RTM связывает цели → требования → тесты → метрики/алерты.
- Решены идентификаторы, идемпотентность, correlation-id, безопасность.
- Артефакты пронумерованы и версионированы.
Чек-лист RACI:
- На каждую активность — один A.
- Есть R (исполнитель).
- C/I назначены осознанно, команда согласна.
- RACI публикуется и обновляется при изменениях.
«Вопрос–Ответ» (частые ситуации)
Q1: Где граница BA и SA?
A: BA отвечает за бизнес-ценность и предметную область, SA — за инженерную спецификацию и согласованность решения. Часто BA и SA работают «в паре»: BA приносит «что и зачем», SA — «как именно и с какими ограничениями».
Q2: Кто пишет SRS — BA или SA?
A: SRS — зона ответственности SA. BA может давать разделы «бизнес-контекст/правила», но финальную инженерную спецификацию ведёт SA.
Q3: Должен ли SA рисовать UI-макеты?
A: Высокоуровневые user-flow и требования к состояниям/валидациям — да. Детальные мокапы — зона UX, но SA должен обеспечить непротиворечивость с процессами и правилами.
Q4: Кто владелец API-контракта?
A: SA как владелец спецификации. Разработчики реализуют, архитектор валидирует принципы, QA тестирует по контракту.
Q5: Как зафиксировать NFR, если бизнес говорит «быстро и безопасно»?
A: Переводите в метрики (p95 latency, throughput, error-rate), режимы деградации, RTO/RPO, требования к логам/алертам.
Q6: Мы «не успеваем» моделировать — можно без ER/BPMN?
A: Можно, если риск низкий и команда согласна. Но для интеграций и данных ER/BPMN часто экономят недели на исправлениях.
Q7: Кто готовит критерии приемки и BDD?
A: SA формулирует проверяемые критерии и согласует с QA и PO; QA детализирует тест-дизайн.
Q8: Как поступать с «плавающими» требованиями?
A: Версионирование артефактов, RTM, change-control (шаблон CR), определённые окна изменений и правила «feature freeze».
Q9: Кто отвечает за наблюдаемость?
A: SA — за требования (SLI/SLO, логи/метрики/трейсы), Dev/DevOps — за реализацию, архитектор — за принципы.
Q10: Как считать успешность SA?
A: Доля требований, прошедших приёмку без доработок; дефекты «требований»; соответствие SLO; своевременное обновление RTM/контрактов; довольство Dev/QA (опросы).
Итог артефакта модуля: RACI-матрица проекта
- Что сдаём: RACI по вашему реальному/учебному проекту (xlsx/Confluence-таблица) + короткий комментарий по спорным строкам.
- Критерии: «один A» на активность, ясно, кто R, логичная роль C/I, нет пробелов по интеграциям/данным/NFR/observability.
- Совет: начните с 20–25 активностей (смесь SDLC и предметных шагов), не пытайтесь охватить «всё на свете» — RACI должна быть используема на дейли-уровне.
