Модуль 1.2. Сбор требований системного аналитика

Интервью, воркшопы, протоколы; виды требований; трассируемость (RTM). Практика: mini-SRS + RTM.

Сильный SA не «слушает и записывает», а структурирует неопределённость: извлекает требования, проверяет их на реализуемость/измеримость и связывает с тестами и метриками. В этом модуле — от подготовки интервью и воркшопов до формализации в mini-SRS и построения RTM (Requirements Traceability Matrix).

Каркас процесса сбора требований (как сотруднику — к исполнению)

Подготовка: карта стейкхолдеров → гипотезы/вопросы → артефакты для ревью (как минимум глоссарий v0).
Elicitation (сбор): интервью/воркшопы/наблюдение/анализ документов/прототипы.
Анализ/структурирование: классификация (виды требований), нормализация терминов, разрешение конфликтов, приоритизация.
Фиксация: mini-SRS (структура ниже), критерии приёмки (AC/BDD), модели (BPMN/DMN/UML/ER), NFR.
Трассируемость: RTM «цель → требование → задача → тест → метрика/алерт».
Валидация: walkthrough с Dev/QA/PO/архитектором (3-Amigos + бизнес).
Управление изменениями: версии, CR, журнал изменений.

Подготовка к интервью и воркшопам

Карта стейкхолдеров (минимум)

Владельцы процесса (PO/операции), исполнители (операторы/поддержка), соседние команды (интеграции), контролёры (безопасность/комплаенс/финконтроль), тех.лиды.

Бриф и цели сессий

Одна сессия — одна цель (напр., «подтвердить правила возвратов»).
Подготовьте артефакт на вход: схема as-is (BPMN черновик) и список терминов; это снижает расхождения.

Сценарий интервью (шаблон)

1) Вступление: цель, тайминг, запись (согласие), «как будем фиксировать решения».

2) Контекст: «кто пользователь? когда сценарий стартует? что считается успехом/неуспехом?»

3) Сценарий: happy path → альтернативы → ошибки.

4) Правила/ограничения: суммы/сроки/лимиты/роли/данные/регуляторика.

5) Метрики: как поймём, что хорошо? (конверсия/время/ошибки).

6) Интеграции/данные: источники, кто владелец правды, возможные коллизии.

7) Риски и предположения: что может пойти не так? какие допущения делаем?

8) Подтверждение: «что пропустили? кто ещё должен это увидеть?»

Вопросы (инструменты)

Открытые: «Расскажите, как сейчас оформляется возврат?»
Закрытые для закрепления: «Срок возврата — 30 календарных?»
Ладдеринг/пять почему: «Почему нужно именно 30?»
Контроль исключений: «Что делаем, если PSP не отвечает?»
Чек-блок NFR: «Сколько секунд допустимо ждать? что логируем? кто сможет читать логи?»

Протокол (минимальный формат)

Дата/время, Участники, Цель, Основные тезисы (маркированно),

Решения (D), Вопросы/риски (Q/R), Действия (A) с владельцами и сроками.

Воркшопы: когда и как

Когда: много стейкхолдеров, есть конфликты, нужно быстрое согласование.
Форматы:
- Event Storming (light): выносим события домена («Заказ создан», «Оплата проведена») и связи; быстро выявляет «дыры».
- Story Mapping: скелет пользовательского пути → группируем релизы/минимальные срезы.
- Правила (DMN): превращаем «устные договорённости» в таблицы решений.

Роли на воркшопе: фасилитатор (SA), скрайбер (SA/BA), эксперты домена, Dev/QA/архитектор как «техническая совесть».
Выход: фото/экспорт доски + протокол решений → в mini-SRS.

Виды требований и как их не путать

Бизнес-требования (BR): цели/ограничения бизнеса (из Vision/BRD).
Требования стейкхолдеров: то, что «болит» у ролей.
Пользовательские (UR): поведение с точки зрения пользователя/актора.
Системные (SR): что должна делать система/интеграции/данные.
Функциональные (FR): конкретное поведение, сценарии, правила.
Нефункциональные (NFR): производительность, надёжность, безопасность, наблюдаемость, совместимость, локализация и пр.
Ограничения (Constraints): регуляторика, лицензии, уже принятые решения (ADR), технологические рамки.

Атрибуты требования (минимум): REQ-ID, Title, Type (FR/NFR/UR/BR), Source, Priority, Status, Version, AC link, Test link, DataImpact, Risk.
Критерии качества (проверяйте каждое): однозначность, полнота, проверяемость, реализуемость, трассируемость.

Трассируемость (RTM): зачем и как

Цель RTM: связать цель и реализацию: «зачем» → «что» → «как» → «как проверим» → «как наблюдаем».

Мини-модель RTM

Business Goal → BR → FR/NFR → Model/Contract (BPMN/DMN/ER/OpenAPI/AsyncAPI) → Jira Story/Task → Test (BDD/регресс) → Monitor (метрика/алерт) → Release

Пример RTM (фрагмент)

Goal	REQ-ID	Тип	Кратко	Модель/Контракт	Jira	Тесты	Метрика/Алерт
G1: ↑конверсия оплаты на 2п.п.	FR-PAY-001	FR	Создать платёж (идемпотентно)	OpenAPI /payments v2.4, BPMN PAY-001	PAY-123	payments.feature:Create	payments_latency_p95<3s
	NFR-SEC-003	NFR	Маскирование PAN в логах	SRS §Security	SEC-021	security.feature:masking	Audit: log_masking_violation=0
	FR-EVT-007	FR	Событие PaymentCaptured	AsyncAPI 1.3, Avro payment-captured.avsc	EVT-044	event.feature:captured	missing_captured_events=0

Где хранить RTM: таблица в Confluence (Page Properties Report) или CSV/Excel в Git; главное — живое обновление на каждом изменении.

Практические примеры (конструктив)

Финтех. «Возврат платежа»

FR-REF-001: «Система должна инициировать возврат по платёжной транзакции…»
- AC:
  1. Given payment.status=CAPTURED and amount ≤ capturedAmount → When POST /refunds → Then 201 и refund.status=PENDING.
  2. Given повтор Idempotency-Key → Then 200 с тем же refundId.
  3. Given PSP timeout → Then 202 и событие RefundPending отправлено.
- Модели: BPMN «Refund», DMN «Правила возвратов» (сроки, лимиты), OpenAPI /refunds, событие RefundCompleted.
- NFR: p95<2s, retry 3× (экспонента), audit-лог на каждое состояние.
- Observability: метрики refund_error_rate, трейсы с correlation-id.

E-commerce. «Смена адреса доставки»

UR-ADR-002: «Покупатель может изменить адрес до статуса Shipped.»
FR-ADR-003: Если status in {Created, Paid, Packed}, то разрешить PATCH /orders/{id}/delivery-address.
NFR: ответ < 500 мс; аудирование всех изменений адреса (PII маскирована).
ER: сущности Order, ShipmentAddress (версионирование адреса).
Тест: BDD на позитив/негатив (после Shipped → 409 Conflict).

Приоритизация и конфликты

MoSCoW для грубой сортировки (Must/Should/Could/Won’t).
WSJF (если SA вовлечён в продуктовые приоритеты): (Business Value + Time Criticality + Risk Reduction) / Job Size.
Конфликты требований:
- Сначала фиксируем факты и контексты (кто пользователь, когда сценарий, какие ограничения).
- Согласовываем правило выбора (DMN) и исключения.
- Все спорные решения — в ADR (решение/альтернативы/последствия).

Типичные риски и способы гашения

«Вода» вместо требований.
Признак: «должно быть быстро и удобно». → Переводим в измеримые NFR (p95, RPS, error-rate), AC/BDD.
Нет единых терминов.
Признак: «заказ/покупка» используются вперемешку. → Глоссарий, ссылка в каждом документе, термин-в-скобках при первом употреблении.
Забытые исключения.
Признак: баги «на границе» (таймауты, повторы, нестандартные статусы). → На интервью всегда спрашивать «что идёт не так?», моделировать ошибки в BPMN, DMN для спорных правил.
Отсутствие RTM.
Признак: непонятно, что реализовано/протестировано. → Ввести RTM как «вход в релиз»; без связей — «не готово».
Неучтённые данные.
Признак: «поле всплыло в проде». → ER/глоссарий обязательны, домены/справочники, миграции.
Версии и совместимость.
Признак: ломающее изменение API без MAJOR. → SemVer, openapi-diff, матрица совместимости.

Мини-SRS: структура и пример (фрагменты)

Шаблон mini-SRS (до 6–8 страниц)

1. Область и цели (Vision link, бизнес-метрики)
2. Термины и глоссарий (ссылки)
3. Сценарии (Use Cases) + BPMN/последовательности
4. Правила (DMN) и ограничения
5. Данные (ER, домены, справочники)
6. Интеграции (OpenAPI/AsyncAPI, ошибки, лимиты, идемпотентность, безопасность)
7. NFR (производительность/надёжность/безопасность/наблюдаемость)
8. Критерии приёмки (AC/BDD)
9. Трассируемость (RTM ссылка) и версии/изменения

Пример записей

FR-PAY-001 (Создать платёж)

Описание: Идемпотентный POST /payments с заголовком Idempotency-Key.
Ошибки: 409 — дубль/конфликт статуса; 422 — валидация; 504 — таймаут PSP.
AC: Given idempotent key repeated → Then same paymentId.
NFR: p95<3s; error-rate<0.5%; журнал аудита payment.audit.
Observability: логируем X-Correlation-Id, метрики payments_latency_p95.

NFR-SEC-004 (Безопасность логов)

Требование: маскировать PAN/PII; доступ к логам — роли ops.read/sec.read.
Тест: security.feature: log masking.

Вопрос–Ответ

Q1: Чем BRD отличается от SRS?
A: BRD фиксирует зачем и какую ценность даём; SRS — как именно будет работать система: модели, контракты, NFR, AC.

Q2: Когда достаточно интервью, а когда нужен воркшоп?
A: Если 1–2 эксперта и простая тема — интервью. Несколько команд/конфликты/правила — воркшоп (Event Storming/DMN).

Q3: Нужно ли всегда писать BDD?
A: На ключевые сценарии — да. Это снижает риск двусмысленности и ускоряет приёмку.

Q4: Кто владеет RTM?
A: SA. QA и Dev обновляют ссылки на тесты/реализацию, но структура и полнота — ваша ответственность.

Q5: Можно ли обойтись без ER-модели?
A: Нельзя для интеграций и любой фичи, где есть данные. Мини-ER обязателен.

Q6: Как фиксировать «не уверены»?
A: Через Assumptions + срок проверки + владелец; открытые вопросы — в раздел Open Issues mini-SRS.

Практика: mini-SRS + RTM (2–4 часа)

Задача: описать одну фичу (на выбор: «Возврат платежа» или «Смена адреса доставки») и собрать RTM.

Что сделать

Провести интервью (30–45 мин) с «экспертом» (можно проиграть сценарий) → протокол.
Провести мини-воркшоп DMN (30 мин) — правила/исключения.
Собрать mini-SRS (до 8 стр.) по шаблону (§9.1).
Добавить 3 модели: BPMN основного потока, Sequence критичного взаимодействия, ER с 4–6 сущностями.
Описать OpenAPI фрагмент (1–2 endpoint), ошибки/лимиты/идемпотентность, X-Correlation-Id.
Сформулировать NFR (измеримо) и 3–5 BDD сценариев.
Заполнить RTM (10–15 строк): цели → FR/NFR → модели/контракты → Jira → тесты → метрики/алерты.
Версионировать: SRS v0.1.0, OpenAPI 0.1.0, добавить CHANGELOG.

Критерии зачёта

Полнота: есть все разделы mini-SRS, 3 модели, NFR, BDD.
Качество: требования однозначны и проверяемы; есть исключения/ошибки/лимиты.
Трассируемость: RTM закрывает ≥90% требований (ссылки осмысленные).
Измеримость: NFR с цифрами, есть соответствующие SLI/алерты.
Версионирование: семантические версии, CHANGELOG.

Результаты (что сдаём)

PDF mini-SRS (или страница Confluence) + исходники моделей (PlantUML/Mermaid/drawio).
CSV/таблица RTM.
Фрагмент openapi.yml.
Протокол интервью + фото/экспорт воркшопа.

Шпаргалки и шаблоны

Шаблон протокола интервью

Тема / Цель:
Дата/Время / Участники:

1) Ключевые тезисы:
- ...

2) Решения (Decision):
- ...

3) Риски/Вопросы (Risk/Question):
- ...

4) Действия (Action / Owner / Due):
- ...

Шаблон строки требования

REQ-ID: FR-<домен>-NNN | Title: <краткое> | Type: FR/NFR | Source: <интервью/док> |
Priority: MoSCoW/WSJF | Status: Draft/Review/Approved | AC: <ссылка> | DataImpact: <сущности> |
Risk: <низ/ср/высок> | Notes: <...>

Шаблон RTM (CSV)

Goal, REQ-ID, Type, Short, Model/Contract, Jira, Test, Monitor
G1, FR-PAY-001, FR, Create payment, OpenAPI /payments v0.1, PAY-12, payments.feature:Create, p95<3s
...

Правильно собранные требования — это mini-SRS с измеримыми NFR и RTM, где каждое «хотелось бы» превращено в проверяемый сценарий. С этого момента команда может планировать, реализовывать и принимать работу без «серых зон». Хотите — подготовлю для вас пакет шаблонов (Confluence-страницы, CSV RTM, заготовки OpenAPI/BDD и формы протокола) под ваш домен.

← Предыдущая статья

Модуль 1.1. Системная аналитика с нуля: инструменты и программы

Следующая статья →

Модуль 1.3. Документация системного аналитика и артефакты