Модуль 3. Документирование требований: BRD, SRS, User Story, Use Case
Картина целиком: кто что читает и зачем
- BRD (Business Requirements Document) — «почему и что» на бизнес-языке: контекст, цели, ценность, ограничения, границы, высокоуровневые сценарии и метрики успеха. Читают спонсоры, владельцы процессов, PO, архитекторы.
- SRS (Software/System Requirements Specification) — «что именно должно быть реализовано»: функциональные и нефункциональные требования, модели данных/интерфейсов, правила расчёта метрик, права доступа, отчетность для аудита. Читают разработчики, системные аналитики, QA, безопасность.
- User Stories — «срезы работы» для инкрементов: кратко про роль, действие, ценность + чёткие критерии приемки. Читают все, кто делает поставку.
- Use Cases — «сквозные сценарии взаимодействия» с шагами/альтернативами и пред-/постусловиями. Удобно для сложных цепочек (например, сверка маржи, drill-down с исключениями).
Принцип: BRD даёт смысл и границы → SRS уточняет специфику → backlog (stories/use cases) режет на поставляемые куски → трассируемость связывает всё с целями и тестами.
Уровни требований и «не перепутать что с чем»
- Бизнес-требования: цели, ценность (value case), KPI, ограничения бизнеса.
- Пользовательские/функциональные: поведение системы, сценарии, правила вычислений, отчётные формы.
- Нефункциональные (NFR): производительность, доступность, безопасность, аудит, качество данных, SLA обновления, хранение историчности, масштабируемость, наблюдаемость.
- Ограничения/допущения: «данные логистики — D+2», «PII хранится только в источнике», «региональная сегрегация доступа».
Проверка уровня: если формулировка отвечает «зачем» — это бизнес-уровень; если «что система должна делать» — функциональный; если «как хорошо/быстро/безопасно» — нефункциональный.
Как писать требование, чтобы его реально сделали
Ориентиры качества:
- Однозначность (избегать «удобно», «быстро», «красиво»; писать порог/единицу измерения).
- Проверяемость (как протестируем? привести метрику/эталон/набор данных).
- Не смешивать what/how (что нужно бизнесу vs как разработчик реализует).
- Цепочка смыслов (цель → требование → критерии → тест → метрика эффекта).
Полезные акронимы:
- INVEST (для User Stories): Independent, Negotiable, Valuable, Estimable, Small, Testable.
- SMART (для целей в BRD): Specific, Measurable, Achievable, Relevant, Time-bound.
Шаблон BRD (примерная структура под BI/DWH)
- Введение и контекст — что болит и для кого.
- Цели и метрики успеха — SMART + lead/lag показатели.
- Scope (включено/исключено) — где остановимся в MVP.
- Стейкхолдеры и RACI — кто решает, кто консультирует, кто в курсе.
- Высокоуровневые сценарии/Use Cases уровня бизнеса — что пользователи делают и какие решения принимают.
- Value Case — гипотезы эффекта (сокращение цикла закрытия, рост точности, экономия FTE).
- Ограничения и допущения — данные, регуляторика, доступы.
- Риски Discovery — что может сорвать ценность и как это отслеживаем.
- Глоссарий — определения показателей и терминов.
Фрагмент BRD (маржинальность):
Цель: «Сократить цикл закрытия GM% с 3 до 1 дня к 31.12; точность ±1 п.п.; доступ к 10:00 мск D-1».
Scope IN: «Витрина GM, дашборд GM% по каналам/категориям, флаг промо, возвраты». Scope OUT: «Прогноз ассортимента, оптимизация цен».
Шаблон SRS (структура и «куда положить смысл»)
- Общее описание — ссылка на BRD, контекст проекта, артефакты.
-
Функциональные требования
2.1. Метрики и правила расчёта: формула, гранулярность, фильтры/исключения, источники, примеры расчётов на эталонной выборке.
2.2. Сценарии (Use Cases): основная и альтернативные ветви; бизнес-правила.
2.3. Интерфейсы/отчёты: макеты страниц/дашбордов, поля, сортировки, фильтры, экспорт.
2.4. Интеграции/источники: таблицы, поля, ключи, лаги, события инкремента/CDC. -
Нефункциональные требования
3.1. Производительность: «время отклика ≤ 5 сек при 12 мес истории на фильтрах канал/категория/регион».
3.2. Обновление/латентность: «обновление витрины 4 раза/сутки; данные доступны к 10:00 D-1».
3.3. Безопасность и доступы: роли, области видимости (row-level security), аудит запросов.
3.4. Надёжность: RTO/RPO, ретеншн, версионирование расчётов.
3.5. Качество данных (DQ): полнота, уникальность, допустимые значения, правила валидации и действия при нарушениях.
3.6. Наблюдаемость: логирование загрузок, lineage, алерты по SLA/DQ. -
Данные и модели
4.1. Словарь данных: атрибут → тип → описание → источник → правила трансформации → владелец.
4.2. Source-to-Target (STT): поле источника → преобразование → поле витрины (с примерами). - Ограничения/допущения — наследуем из BRD, уточняем технически.
- Критерии приемки и UAT — Given/When/Then + референсные выборки.
- Трассируемость — таблица связей «цель → требование → история → тест».
- Приложения — макеты, SQL-эталоны, шаблоны выгрузок, маскирование примеров.
Фрагмент SRS (правило метрики GM%):
Формула: GM% = (Revenue – COGS – Logistics)/Revenue.
Гранулярность: SKU×Канал×Период (день/неделя/месяц).
Исключения: возвраты, проведенные вне периода — отражаем корректировкой текущего.
Эталон: файл GM_reference_Q2.xlsx, лист SKU_123, допустимое расхождение ≤ 0.2 п.п.
User Stories: как превращать SRS в инкременты
Шаблон: «Как [роль], я хочу [действие], чтобы [ценность]».
Критерии (INVEST) + Приемка (Gherkin).
Пример истории:
Как финконтролер, хочу видеть GM% по каналам с обновлением к 10:00 D-1 и флагом «промо», чтобы закрывать месяц за 1 день.
Acceptance Criteria:
- Given загружены данные D-1, When открываю дашборд до 10:00, Then GM% рассчитан по согласованной формуле, страница открывается ≤ 5 сек.
- Given включён фильтр «промо», When сравниваю GM% promo vs non-promo, Then расхождение с эталонной таблицей ≤ 0.2 п.п.
- Given моя роль «Регион X», When открываю карточку SKU, Then вижу только данные региона X.
Антипаттерн и перепись:
«Хочу красивый отчёт» → «Как категорийный менеджер хочу топ-SKU по падению GM% за последнюю неделю с drill-down до чека, чтобы инициировать корректировку промо».
Use Cases: когда истории не хватает
Зачем: сложные многоходовые сценарии, ветвления, обработка ошибок, альтернативные пути (например, «Сверка маржи и работа с неполнотой данных»).
Шаблон Use Case:
- Название, Акторы, Предусловия, Основной поток шагов, Альтернативы/исключения, Постусловия, Триггеры ошибок, Ссылки на NFR и тест-кейсы.
Фрагмент:
UC-03 «Сверка GM% с неполнотой логистики»
Предусловие: загрузка D-1 завершена; DQ-порог полноты логистики = 98%.
Основной поток: 1) Пользователь открывает дашборд → 2) Система проверяет полноту → 3) Если ≥ 98%, снимается предупреждение → 4) Разрешён экспорт.
Альтернатива: при < 98% — показывается баннер, GM% помечается «черновик», экспорт блокируется, доступна кнопка «Показать отсутствующие партии».
Приоритизация и планирование: MoSCoW + слоями
MoSCoW: Must, Should, Could, Won’t (в этом релизе). Привязываем к ценности/рискам/зависимостям.
Слои поставки:
- MVP: минимальный путь ценности (витрина GM + базовый дашборд + DQ-виджет).
- R2: промо/возвраты/роли доступа.
- R3: рекомендации/алерты/пояснительные карточки.
Практика: в Jira/YouTrack метим Must/Should и связываем с релизами. Каждую историю — с link на SRS-параграф и BRD-цель.
Трассируемость (traceability): связать точками
Мини-матрица (фрагмент):
|
BRD Цель |
SRS Требование |
Story/Use Case |
Тест |
Примечание |
|---|---|---|---|---|
|
Сократить цикл GM% до 1 дня |
NFR-P1 Отклик ≤ 5 сек |
US-12 Открытие страницы GM |
TC-45 Замер отклика |
Масштаб выборки 12 мес |
|
SLA 10:00 D-1 |
NFR-U2 Обновление 4 раза/сутки |
US-08 Обновление витрины |
TC-37 Проверка расписания |
Алерт при срыве SLA |
|
Точность ±1 п.п. |
FR-M3 Формула GM% |
UC-03 Сверка GM |
TC-22 Сличение с эталоном |
Допуск 0.2 п.п. |
Где хранить: Confluence (страницы BRD/SRS), Jira (Epic/Story/Test), связи ссылками. Любое изменение — обновление матрицы.
Практика модуля (что сдать)
- Мини-SRS (3–5 страниц) для фичи «GM% дашборд» с: 1) правилом расчёта, 2) макетом страницы, 3) NFR (отклик/обновление/доступы), 4) STT на 1–2 поля, 5) UAT-критериями.
- Backlog (10–15 историй) в Jira/YouTrack с INVEST и приёмкой; пометить MoSCoW.
- Матрица трассируемости (минимум 5 связок) между BRD целями, SRS пунктами, историями и тестами.
Риски оформления и как их предотвращать
|
Риск |
Симптом |
Профилактика |
|---|---|---|
|
Размытые формулировки |
«Быстро», «удобно» |
NFR с числами и условиями; Gherkin-критерии |
|
Смешение уровней |
В SRS — бизнес-цели без конкретики |
Разнести: BRD — «почему», SRS — «что», Stories — «инкремент» |
|
Неполный словарь метрик |
Споры финансы/коммерция |
Словарь с владельцами и версионированием; протокол решения |
|
Нет DQ-правил |
«Отчёт неверный» из-за мусора |
DQ раздел в SRS + действия при нарушениях (баннер/блок экспорт/алерт) |
|
Потеря traceability |
«Зачем мы это делали?» |
Матрица связей + шаблон ссылок в Jira/Confluence |
|
Scope creep |
Постоянные «быстрые» добавки |
MoSCoW + change-log с оценкой влияния и решением PO |
|
Неучтённая безопасность |
Блок на релизе |
Ранний Security Review, RLS/маскирование, аудит доступов |
|
Непроверяемые допуски |
Нечем принять работу |
Эталонные выгрузки/SQL-снапшоты, тестовые наборы данных |
Теория и стандарты — «достаточно, чтобы не ошибаться»
- IEEE 29148: качества требований — корректность, недвусмысленность, полнота, проверяемость, реализуемость, трассируемость, изменяемость.
- Верификация vs Валидизация: «правильно ли написали» vs «правильную ли вещь сделали».
- Data Contracts: явные соглашения по полям/типам/частоте/качества источников.
- Версионирование артефактов: BRD v1.0 → SRS v1.2; change-log с датой, автором, обоснованием.
Вопрос–ответ (FAQ)
Q: Чем BRD отличается от SRS в одном предложении?
A: BRD — зачем и какая ценность; SRS — что система обязана делать и как это проверим.
Q: Когда писать Use Case, если уже есть User Stories?
A: Когда сценарий многошаговый с альтернативами/ошибками (сверка, исправления данных, эскалации) — Use Case экономит ошибки и переписки.
Q: Как описывать метрики, чтобы не спорить на UAT?
A: Формула + гранулярность + фильтры/исключения + источник + эталонные расчёты на реальной выборке + допустимое расхождение.
Q: Где фиксировать NFR?
A: В SRS отдельным разделом, а для критичных — дублировать в историях (чтобы они попали в DoD и тест-кейсы).
Q: Как избежать «документа ради документа»?
A: Делайте «минимально достаточный» BRD и SRS, но каждый пункт проверяемый. Всё, что нельзя протестировать или измерить, не приносит пользы.
Q: Что делать, если в середине спринта бизнес меняет формулу GM?
A: Change-request: оценка влияния (dev/test/обучение/ретро-пересчёт), решение PO/SteerCo, версия словаря ↑, миграционный план, пометка в отчёте об изменении методологии.
Мини-шаблоны (скопируйте в Confluence)
BRD — «Цели и метрики»
Цель: … (S)
Метрика успеха (lag): … (M, единицы)
Ранняя метрика (lead): …
Срок (T): …
Владелец: …
SRS — «Правило метрики»
Название/код: …
Формула: …
Гранулярность: …
Фильтры/исключения: …
Источник: …
Эталонная выборка/файл: …
Допустимое расхождение: …
Владелец/версия: …
Story (INVEST) + Приемка (Gherkin)
Как [роль], хочу [действие], чтобы [ценность].
Given … When … Then … (минимум 3 сценария, включая негативный).
Traceability (таблица)
BRD Цель → SRS Пункт → Story → Тест → Комментарии.
Чек-листы готовности
BRD готов:
- Есть SMART-цели и метрики эффекта.
- Scope IN/OUT утверждён.
- Глоссарий ключевых терминов.
- Value case с гипотезами выгоды.
- Риски и допущения зафиксированы.
SRS готов:
- Описаны все метрики и правила, есть эталоны.
- STT покрывает поля для витрины.
- NFR числовые и проверяемые.
- Use Cases для сложных сценариев.
- UAT-критерии и тестовые наборы.
- Трассируемость заведена.
Backlog готов:
- Истории INVEST, с приёмкой.
- MoSCoW разнесён по релизам.
- Ссылки на SRS/BRD в каждой истории.
- DoR/DoD согласованы.
Вы оформляете смысл (BRD), специфику (SRS) и инкременты (Stories/Use Cases), связываете их трассируемостью и делаете проверяемыми через UAT и NFR. Такой пакет снимает 80% типовых споров на разработке и при приемке, ускоряет поставку и делает эффект прозрачным для бизнеса.
