Чем отличается BRD от SRS?

Чем отличается BRD от SRS?

BRD (Business Requirements Document) и SRS (Software Requirements Specification) — это два ключевых документа в разработке, но они отвечают на разные вопросы, предназначены для разных аудиторий и охватывают разные уровни детализации.

Определения

BRD (Бизнес-требования) — это документ, который описывает ЧТО нужно сделать и ПОЧЕМУ это нужно сделать с точки зрения бизнеса. Отвечает на вопрос о бизнес-проблеме и целях.

SRS (Технические требования) — это документ, который описывает КАК это нужно сделать в технического аспекте. Содержит детальные функциональные и нефункциональные требования для разработчиков.

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

BRD — детально

Содержит:

• Описание текущей проблемы (As-Is)
• Видение желаемого состояния (To-Be)
• Бизнес-цели и KPI
• Сценарии использования (Use Cases) в бизнес-терминах
• Приоритизацию требований (MoSCoW)
• Основные заинтересованные лица
• Бизнес-процессы (в BPMN)

Пример из BRD — запуск нового модуля рекомендаций:

ПРОБЛЕМА: Клиенты не видят релевантные товары, возвращаемость низкая
ЦЕЛЬ: Увеличить среднюю стоимость заказа на 15% за счёт 
       персонализированных рекомендаций
KPI: Средняя стоимость заказа, CTR на рекомендации, конверсия
РЕЗУЛЬТАТ: На главной странице система показывает 5 рекомендованных 
           товаров на основе истории покупок клиента

SRS — детально

Содержит:

• Функциональные требования (что должно работать)
• Нефункциональные требования (производительность, безопасность, масштабируемость)
• API спецификация (endpoints, параметры, ответы)
• UI макеты и спецификации (где ставить элементы, какие размеры)
• Алгоритмы и бизнес-логика в деталях
• Обработка ошибок и edge cases
• Требования к БД (схема, индексы)
• Интеграция с внешними системами

Пример из SRS — для того же модуля:

ФР 1.1: При загрузке главной страницы система должна 
        вызвать API /recommendations?user_id={id}&limit=5

ФР 1.2: Алгоритм: Top-5 товаров с максимальным Co-Purchase Score
        Score = (frequency × weight_category) + (avg_rating × 0.1)

НФР 1: Ответ API не более 200ms, кешировать на 1 час
НФР 2: Поддерживать 10 000 RPS
НФР 3: Данные товаров синхронизируются с 1С каждые 30 минут

Практический пример — покупка товара

В BRD:

Цель: Упростить процесс оформления заказа
Проблема: 40% пользователей отказываются на этапе ввода адреса
Решение: Позволить выбрать сохранённый адрес из профиля
Результат: Сокращение времени оформления на 30 секунд

В SRS:

ФР 1: При клике на поле "Адрес" должен открыться модальное окно 
      с лежащимися сохранёнными адресами

ФР 2: Адреса должны быть отсортированы по дате последнего использования

ФР 3: Пользователь может добавить новый адрес через кнопку "Добавить"

ФР 4: Если это первый заказ, поле заполняется пусто, модал не открывается

UI: Модал 600px шириной, список адресов в компоненте, каждый адрес 
    — карточка с иконкой и кнопкой удаления

Связь между BRD и SRS

BRD (Стейкхолдеры согласуют цели)
     ↓
Requirements Analysis (BA анализирует и разбирает)
     ↓
SRS (Разработчики получают детальный план)
     ↓
Development (Код пишется)

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

Смешивание BRD и SRS в один документ — становится неудобно и запутанно

• Стейкхолдеры тонут в технических деталях
• Разработчики не видят бизнес-контекста

BRD содержит технические решения — "Нужно добавить микросервис на Go"

• Это не задача бизнеса, это техническое решение

SRS слишком общий — "Должно работать быстро"

• Разработчикам нужны конкретные числа: "Время ответа < 200ms"

Для Business Analyst

BA должен:

1. Разрабатывать BRD совместно со стейкхолдерами
2. Уточнять требования через SRS-документ
3. Выступать переводчиком между бизнесом (BRD) и техническими специалистами (SRS)
4. Валидировать оба документа на полноту и консистентность

BRD отвечает на вопрос "Зачем?", SRS отвечает на вопрос "Что точно нужно сделать?". Оба документа критичны для успеха проекта.