BRD vs SRS vs User Stories: какой документ нужен вашему проекту

Бизнес-аналитик создаёт десятки документов за проект. Но три формата встречаются чаще всего: BRD (Business Requirements Document), SRS (Software Requirements Specification) и User Stories. Новички путают их, опытные аналитики — комбинируют. Разберём, чем они отличаются и когда какой использовать.

Три документа — три уровня детализации

Главное различие — уровень абстракции:

Документ	Отвечает на вопрос	Аудитория	Уровень
BRD	Зачем? Что хочет бизнес?	Заказчик, спонсор, руководство	Бизнес-уровень
SRS	Что должна делать система?	Разработчики, тестировщики, архитектор	Системный уровень
User Stories	Что нужно пользователю?	Agile-команда (PO, разработчики, QA)	Пользовательский уровень

Это не взаимозаменяемые форматы, а звенья одной цепочки: BRD → SRS → User Stories (от общего к частному).

BRD — Business Requirements Document

Что это

BRD фиксирует бизнес-потребность и обоснование проекта. Это документ для руководства, а не для разработчиков. BRD отвечает на вопросы:

Какая бизнес-проблема решается?
Какие цели и KPI?
Кто стейкхолдеры?
Каковы границы проекта (scope)?
Какие ограничения и риски?

Структура BRD

1. Введение
   1.1. Цель документа
   1.2. Scope и границы
   1.3. Стейкхолдеры

2. Бизнес-контекст
   2.1. Текущее состояние (проблема)
   2.2. Целевое состояние (vision)
   2.3. Бизнес-цели и KPI

3. Бизнес-требования
   3.1. Высокоуровневые требования
   3.2. Бизнес-правила
   3.3. Ограничения

4. Scope
   4.1. В scope
   4.2. Вне scope

5. Допущения и риски

6. Зависимости

7. Критерии успеха

Пример бизнес-требования из BRD

BR-001: Компания должна иметь возможность обрабатывать входящие заявки клиентов не более чем за 1 час с момента получения, обеспечивая 100% фиксацию обращений и автоматическое уведомление клиента о статусе.

Обоснование: Текущее среднее время обработки — 12 часов. 15% заявок теряются. Клиентская удовлетворённость — 3.2/5.

KPI: Cycle time ≤ 1 час, потери = 0%, CSAT ≥ 4.5/5.

Обратите внимание: BRD не говорит, как это реализовать — CRM, бот, новый процесс. Только что нужно бизнесу и зачем.

Когда нужен BRD

Новый проект, требующий инвестиционного решения
Проект с несколькими стейкхолдерами и конфликтующими интересами
Формальная среда: госсектор, банки, страхование
Проект с внешним подрядчиком (BRD — часть тендерной документации)

SRS — Software Requirements Specification

Что это

SRS — детальная спецификация того, что должна делать система. Это документ для разработчиков и тестировщиков. SRS переводит бизнес-требования из BRD в системные требования.

Структура SRS

1. Введение
   1.1. Назначение системы
   1.2. Аббревиатуры и определения
   1.3. Ссылки на BRD и другие документы

2. Общее описание
   2.1. Контекст системы (Context Diagram)
   2.2. Пользователи и роли
   2.3. Допущения и зависимости

3. Функциональные требования
   3.1. Модуль «Заявки»
      FR-001: Система должна...
      FR-002: При наступлении...
   3.2. Модуль «Уведомления»
   3.3. ...

4. Нефункциональные требования
   4.1. Производительность
   4.2. Безопасность
   4.3. Доступность

5. Интерфейсы
   5.1. Пользовательский интерфейс (wireframes)
   5.2. API (контракты)
   5.3. Интеграции с внешними системами

6. Модель данных
   6.1. ER-диаграмма
   6.2. Описание сущностей и атрибутов

7. Ограничения и предположения

Пример функционального требования из SRS

FR-001: Система должна автоматически создавать запись «Заявка» при получении входящего письма на адрес support@company.ru.

Входные данные: тема письма, тело письма, вложения, email отправителя, дата/время.

Обработка:

Система парсит email и извлекает: тему, тело, вложения

Система создаёт запись «Заявка» со статусом «Новая»

Система присваивает уникальный номер формата ZAY-YYYYMMDD-NNN

Система привязывает заявку к существующему контакту по email, или создаёт новый контакт

Выходные данные: созданная запись «Заявка» с заполненными полями.

Исключения:

Если email пустой → заявка создаётся с пометкой «Требует ручной обработки»

Если размер вложений > 25 МБ → вложения не сохраняются, в заявке — предупреждение

Связанное бизнес-требование: BR-001

Когда нужен SRS

Waterfall или V-модель разработки
Проект с фиксированным scope и бюджетом
Разработка на заказ с внешним подрядчиком
Критичные системы (медицина, финансы, безопасность)
Интеграционные проекты с детальными API-контрактами

User Stories

Что это

User Story — лёгкий формат описания требования с точки зрения пользователя. Не спецификация, а «приглашение к разговору» (Рон Джеффрис).

Формат

Как [роль],
я хочу [действие],
чтобы [польза].

Пример User Story с Acceptance Criteria

US-001: Как менеджер по продажам, я хочу видеть список новых заявок с автоматическим обновлением, чтобы быстро реагировать на обращения клиентов.

Acceptance Criteria:

Список обновляется автоматически каждые 30 секунд без перезагрузки страницы

Новые заявки выделяются визуально (иконка + цвет строки)

В списке отображаются: номер, дата, клиент, тема, статус, приоритет

Список можно фильтровать по статусу и приоритету

При клике на заявку открывается карточка с деталями

Время загрузки списка из 500 заявок — не более 2 секунд

INVEST-критерии качественной User Story

Критерий	Описание	Пример нарушения
I — Independent	Не зависит от других stories	«После выполнения US-003...»
N — Negotiable	Детали обсуждаемы	Жёсткое «кнопка должна быть зелёной»
V — Valuable	Несёт ценность для пользователя	«Рефакторинг модуля X»
E — Estimable	Команда может оценить объём	«Интеграция с чем-нибудь»
S — Small	Одна story = 1–3 дня работы	«Полный модуль отчётности»
T — Testable	Можно проверить	«Система должна быть удобной»

Когда использовать User Stories

Agile/Scrum команды
Продуктовая разработка с итерациями
Команда работает вместе (есть доступ к PO)
Требования уточняются в процессе

Сравнительная таблица

Параметр	BRD	SRS	User Stories
Уровень	Бизнес	Система	Пользователь
Объём	10–30 стр.	30–100 стр.	1–3 предложения
Автор	Бизнес-аналитик	Системный аналитик / BA	Product Owner / BA
Читатель	Руководство, спонсор	Разработчики, QA	Вся Agile-команда
Детализация	Высокоуровневая	Детальная	Минимальная (уточняется устно)
Методология	Любая	Waterfall, V-модель	Agile, Scrum, Kanban
Трассируемость	BR → цели бизнеса	FR → BR	US → Acceptance Criteria
Изменяемость	Низкая (версионируется)	Низкая	Высокая
Стоимость подготовки	Средняя	Высокая	Низкая

Комбинации на практике

Классический Waterfall

BRD → SRS → разработка → тестирование → приёмка

Полный цикл от бизнес-требований до системной спецификации. Подходит для проектов с фиксированным scope, формальных контрактов с подрядчиками.

Гибридный подход (самый частый)

BRD → User Stories с Acceptance Criteria

BRD фиксирует scope и бизнес-цели для руководства. User Stories описывают функциональность для команды. SRS не нужен — команда работает итеративно.

Это самый распространённый подход в моей практике: бизнес хочет понятный документ для согласования (BRD), команда хочет лёгкие артефакты (User Stories).

Чистый Agile

User Stories → Acceptance Criteria → DoD

Минимум документации. Работает только если:

Команда стабильная и опытная
Product Owner доступен ежедневно
Нет формальных требований к документации

Регулируемые отрасли

BRD → SRS → User Stories → Traceability Matrix

Все три документа + матрица трассируемости, связывающая бизнес-требования с системными и тестами. Обязательно для банков, страховых компаний, медицины.

Типичные ошибки

Ошибка 1: BRD с техническими деталями

❌ «Система должна использовать PostgreSQL 15 и REST API с JSON»

Это требование для SRS, не для BRD. В BRD — бизнес-потребность, технологический стек — ограничение, но не требование.

Ошибка 2: SRS без связи с BRD

Каждое функциональное требование в SRS должно быть привязано к бизнес-требованию из BRD. Если FR не связан ни с одним BR — зачем его реализовывать?

Ошибка 3: User Stories без Acceptance Criteria

User Story без AC — это пожелание, а не требование. Acceptance Criteria — единственное, что делает User Story тестируемой.

Ошибка 4: User Stories размером в эпик

❌ «Как руководитель, я хочу CRM-систему, чтобы управлять продажами»

Это не User Story, это эпик. Декомпозируйте до уровня, который команда может реализовать за 1–3 дня.

Ошибка 5: SRS вместо User Stories в Agile

Если команда работает спринтами, 80-страничная SRS будет устаревать быстрее, чем обновляться. Используйте бэклог с User Stories.

Матрица выбора формата

Ваша ситуация	Рекомендуемый формат
Нужно согласование бюджета с руководством	BRD
Проект с внешним подрядчиком (фикс. цена)	BRD + SRS
Agile-команда, Product Owner рядом	User Stories
Регулируемая отрасль (банк, страхование)	BRD + SRS + матрица трассируемости
Стартап, MVP	User Stories
Интеграция с внешней системой	SRS (раздел интеграций) + API-контракт
Доработка существующей системы	User Stories с AC
Крупный проект с множеством стейкхолдеров	BRD + User Stories (гибрид)

Итог

BRD, SRS и User Stories — не конкурирующие, а взаимодополняющие форматы. BRD — для бизнеса, SRS — для разработки, User Stories — для Agile-команды. Выбирайте формат под ситуацию: методологию, зрелость команды, формальность среды. И помните — документ ценен не объёмом, а тем, что он устраняет неопределённость.

Нужна помощь с документированием требований? Обсудим формат, который подойдёт именно вашему проекту.