Требования к ПО

Документирование требований: SRS, BRD, FRD

📚 26 вопросовПройти тест →
Лекция

Документирование требований: SRS, BRD, FRD

Требования к ПО

Документирование требований: SRS, BRD, FRD

Введение: три уровня одной идеи 🗺️

Одна и та же инициатива выглядит по-разному для бизнеса, продукта и разработки. Бизнесу важна цель, аналитике — функции, команде разработки — точная спецификация.
Поэтому используются разные документы: BRD (зачем), FRD (что), SRS (как).
✅ Вывод: правильный тип документа снижает недопонимание между ролями.

Проблема → решение

Проблема: когда всё складывают в один «универсальный» файл, документ становится перегруженным и плохо читаемым для каждой роли.
Решение: разделять документацию по уровням:
  • BRD для бизнес-целей;
  • FRD для функционального поведения;
  • SRS для технической спецификации.
✅ Вывод: структура документации напрямую влияет на скорость и качество реализации.

Чем помогает и как работает

Разделение на BRD/FRD/SRS помогает:
  • дать каждому участнику ровно нужный уровень детализации;
  • сократить количество пересогласований;
  • повысить проверяемость требований и трассируемость.
Как это работает:
  1. На старте формируется BRD (цели, KPI, scope).
  2. На основе BRD готовится FRD (сценарии, функции, правила).
  3. Затем детализируется SRS (интерфейсы, метрики, ограничения).
  4. Между документами поддерживаются явные связи.
✅ Вывод: документы работают как последовательная цепочка от стратегии к реализации.

Ключевые термины (простыми словами)

  • BRD (Business Requirements Document) — документ бизнес-целей и ценности.
  • FRD (Functional Requirements Document) — документ функций и бизнес-правил.
  • SRS (Software Requirements Specification) — детальная техническая спецификация.
  • Scope — границы релиза (что входит/не входит).
  • Baseline — зафиксированная версия требований.
  • Change Request (CR) — формальный запрос на изменение.
  • Traceability Matrix — связи «требование -> задача -> тест».
✅ Вывод: единая терминология делает документацию управляемой.

1. BRD: бизнес-цели и ценность

Назначение: описать, зачем инициатива нужна бизнесу.
Пример:
Цель: увеличить конверсию оплаты на 10% за кварталKPI: ARPU +8%, отказ от оплаты -15%Scope: только веб-версия
🔎 Как это происходит на практике:
  1. Бизнес и продукт фиксируют цель и ожидаемый эффект.
  2. Определяются KPI и ограничения.
  3. Утверждается high-level scope.
Когда использовать: на старте инициативы и при защите приоритетов.
✅ Вывод: BRD отвечает на вопрос «почему делаем именно это».

2. FRD: функции, сценарии и правила

Назначение: описать, что система должна делать для пользователя и бизнеса.
Пример:
Функции: регистрация, оплата, подтверждение записиПравило: скидка применяется только новым пользователям
🔎 Как это происходит на практике:
  1. Аналитик раскладывает цели BRD в функциональные блоки.
  2. Формулируются сценарии и бизнес-правила.
  3. Добавляются acceptance criteria.
Когда использовать: перед декомпозицией в backlog и sprint planning.
✅ Вывод: FRD переводит бизнес-цели в функциональный язык команды.

3. SRS: техническая спецификация

Назначение: задать точные параметры реализации и проверки.
Пример:
POST /api/paymentsLatency p95 <= 300 msError format: { code, message }
🔎 Как это происходит на практике:
  1. Технические требования детализируются по интерфейсам и данным.
  2. Добавляются NFR, ограничения и форматы ошибок.
  3. QA строит тесты на основе SRS.
Когда использовать: для сложных интеграций, высоких рисков и строгого QA-контроля.
✅ Вывод: SRS делает техническую реализацию проверяемой и предсказуемой.

4. Как выбрать нужный уровень документации

Назначение: не уходить в лишнюю бюрократию и не терять критичные детали.
Подход:
  • MVP: BRD + компактный FRD;
  • средний продукт: BRD + FRD + частичный SRS;
  • enterprise/регулируемые системы: полный BRD + FRD + SRS.
🔎 Как это происходит на практике:
  1. Оценивается риск и стоимость ошибки.
  2. Определяется аудитория документов.
  3. Выбирается глубина детализации по каждому уровню.
Когда использовать: при запуске нового проекта или крупного релиза.
✅ Вывод: глубина документации должна соответствовать риску, а не привычке команды.

5. Аудитория и роль каждого документа

ДокументКлючевая аудиторияГлавный вопрос
BRDбизнес, стейкхолдерызачем
FRDпродукт, аналитик, QAчто
SRSразработка, QA, архитекторыкак
🔎 Как это происходит на практике:
  1. Для каждого документа назначается владелец.
  2. Определяется круг обязательного согласования.
  3. Документ пишется языком целевой аудитории.
Когда использовать: при построении процесса требований внутри команды.
✅ Вывод: «документ для всех» обычно не подходит никому.

6. Версионирование, baseline и изменения

Назначение: контролировать эволюцию требований.
Пример:
Baseline v1.0 утверждёнИзменения через CR-форму с impact analysis
🔎 Как это происходит на практике:
  1. Фиксируется baseline перед реализацией.
  2. Любое изменение проходит через change request.
  3. Оценивается влияние на сроки, бюджет и тесты.
Когда использовать: всегда, если требования меняются в процессе разработки.
✅ Вывод: baseline защищает команду от хаотичных и неуправляемых изменений.

7. Traceability matrix

Назначение: обеспечить связь между требованиями, задачами и тестами.
Пример:
BRD-1 -> FRD-3 -> SRS-7 -> TC-21
🔎 Как это происходит на практике:
  1. Каждому требованию присваивается ID.
  2. Создаются связи с задачами и тест-кейсами.
  3. Перед релизом проверяется покрытие.
Когда использовать: на критичных фичах и в релизах с высоким риском регрессии.
✅ Вывод: трассируемость показывает, что бизнес-цель действительно дошла до работающего кода.

Часто спрашивают на собеседованиях

  • В чём разница BRD, FRD и SRS на практике?
  • Когда достаточно BRD + FRD без полного SRS?
  • Что такое baseline и зачем он нужен?
  • Как связать требования и тесты через traceability?
  • Кто владелец каждого типа документа?
✅ Вывод: на интервью важно уметь объяснить не теорию, а практику применения.

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

Ошибка 1: полный SRS для маленького MVP

❌ много детализации без бизнес-необходимости ✅ достаточный уровень документации под текущий риск

Ошибка 2: смешение уровней

❌ KPI, UI и API в одном абзаце ✅ BRD/FRD/SRS разделены по назначению

Ошибка 3: нет baseline

❌ «плавающая» версия требований ✅ фиксированная версия и прозрачный change process

Ошибка 4: нет связей с тестами

❌ непонятно, что покрыто проверками ✅ traceability matrix с актуальными ссылками

Best Practices

  • Подбирайте формат документации под масштаб и риск проекта.
  • Разделяйте бизнес-цели, функции и техспецификацию.
  • Фиксируйте baseline перед стартом реализации.
  • Управляйте изменениями через CR.
  • Ведите traceability для критичных требований.

Заключение

🎯 BRD фиксирует бизнес-смысл.
🎯 FRD описывает функциональное поведение.
🎯 SRS задаёт техническую точность реализации.
Теперь вы можете выбирать и строить документацию требований так, чтобы она реально помогала проекту, а не мешала ему.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «Документирование требований: SRS, BRD, FRD»

Пройти тест →