PRD vs BRD vs FRD: полное сравнение трёх документов
В продуктовой разработке три документа описывают требования на разных уровнях: BRD — на уровне бизнеса, PRD — на уровне продукта, FRD — на уровне системы. Каждый отвечает на свой вопрос и адресован своей аудитории.
Три документа за 30 секунд
| BRD | PRD | FRD | |
|---|---|---|---|
| Вопрос | «Зачем бизнесу это строить?» | «Что мы строим и почему?» | «Как система должна работать?» |
| Фокус | Бизнес-ценность, ROI | Продукт, функции, UX | Техническое поведение системы |
| Кто пишет | Business Analyst / PM | Product Manager | Business Analyst / Systems Analyst |
| Кто читает | Executives, инвесторы | Дизайнеры, разработчики, QA | Разработчики, QA, архитекторы |
| Уровень | Стратегический | Тактический | Технический |
| Объём | 15-30+ стр. | 1-15 стр. | 10-30+ стр. |
BRD: зачем бизнесу это нужно
BRD (Business Requirements Document) обращён к тем, кто принимает решения об инвестициях. Его задача — доказать, что проект стоит ресурсов: какую бизнес-проблему он решает, какой ROI ожидается, как вписывается в стратегию компании.
Обязательные секции: Executive Summary, бизнес-цели по SMART, описание текущего процесса (AS-IS / TO-BE), cost-benefit analysis, приоритизированные бизнес-требования, риски, глоссарий.
BRD не описывает, как будет выглядеть продукт или как будет работать система. Он отвечает на вопрос уровнем выше: стоит ли вообще браться за этот проект.
PRD: что мы строим
PRD (Product Requirements Document) переводит бизнес-обоснование в конкретные продуктовые требования. Это рабочий документ продуктовой команды: дизайнеры ищут в нём персоны и сценарии, разработчики — функциональные требования и приоритеты, QA — критерии приёмки.
Обязательные секции: Problem Statement, Target Users, Proposed Solution, Scope (IN/OUT), Success Metrics. Расширенный набор включает ещё восемь секций — до 13 в сумме.
PRD существует в девяти вариациях: от одностраничного One-Pager до AI-Optimized PRD для AI-агентов.
Подробнее: PRD — полное руководство.
FRD: как система должна работать
FRD (Functional Requirements Document) — технический чертёж системы. Он переводит продуктовые требования из PRD в детальные спецификации для разработки: как система реагирует на действия пользователя, какие бизнес-правила применяются, какие роли и разрешения существуют.
Обязательные секции: Introduction, Business Requirements (контекст из PRD), Functional Features, User Roles & Permissions, Use Cases, System Behavior, Process Diagrams, Non-Functional Requirements, Assumptions & Constraints.
FRD — самый детальный из трёх документов. Если PRD говорит «пользователь может отфильтровать товары по цене», FRD описывает: какой UI-элемент, какой диапазон значений, как система обрабатывает граничные случаи, какое время отклика допустимо.
Детальное сравнение
| Параметр | BRD | PRD | FRD |
|---|---|---|---|
| Ключевой вопрос | «Зачем?» | «Что?» | «Как?» |
| Аудитория | Executives, спонсоры | Продуктовая команда | Инженеры, архитекторы |
| Создаётся | Первым (до PRD) | После BRD, до FRD | После PRD |
| Методология | Waterfall, enterprise | Все | Waterfall, enterprise |
| Содержит метрики | ROI, бизнес-KPI | Продуктовые KPI | SLA, время отклика |
| User Stories | Нет | Да | Развёрнуты в Use Cases |
| Диаграммы | Нет (или высокоуровневые) | Wireframes, mockups | Process Diagrams, Data Flow |
| Приоритизация | Critical / High / Medium / Low | P0 / P1 / P2 | По функциям |
| Обновляется | Фиксируется после одобрения | Регулярно (живой) | Перед каждым спринтом |
Когда нужны все три
Полная цепочка BRD → PRD → FRD используется в двух ситуациях:
Enterprise-проекты с бюджетом от $100K и несколькими департаментами. BRD обосновывает инвестицию для руководства, PRD определяет продукт для команды, FRD специфицирует систему для разработчиков.
Регулируемые отрасли (fintech, healthcare, defense), где формальная документация — обязательное требование аудита или сертификации. Каждый документ в цепочке — юридически значимый артефакт.
Когда достаточно одного или двух
| Ситуация | Документы | Почему |
|---|---|---|
| Стартап (3-10 человек) | Только PRD | Нет формальных процессов, команда маленькая |
| Agile-команда | PRD + User Stories | PRD заменяет BRD, acceptance criteria заменяют FRD |
| AI-assisted coding | AI-Optimized PRD | AI-агент генерирует реализацию из PRD напрямую |
| Аутсорсинг без PM | BRD + FRD | Владелец пишет BRD, подрядчик работает по FRD |
| Enterprise waterfall | BRD + PRD + FRD | Полная цепочка, каждый документ обязателен |
Аналогия: строительство дома
- BRD: «Зачем нам дом?» — семья растёт, нужно больше места, бюджет позволяет, район подходит. Обоснование решения строить.
- PRD: «Какой дом мы хотим?» — современный дизайн, три спальни, два этажа, много света, бюджет в пределах X. Техзадание для архитектора.
- FRD: «Как именно построить?» — фундамент ленточный, стены из газобетона, перекрытия монолитные, электропроводка по схеме Y. Чертежи для строителей.
Key insight
Без BRD можно начать строить дом, который не по карману. Без PRD архитектор не знает, что проектировать. Без FRD строители не знают, как реализовать проект архитектора.
Частые путаницы
BRD и PRD. Чаще всего путают именно эти два документа. Ключевое отличие: BRD описывает бизнес-потребность (почему проект нужен компании), PRD описывает продукт (что будет построено для пользователя). Подробнее: PRD vs BRD.
PRD и FRD. PRD описывает «что» на уровне функций (пользователь может фильтровать товары), FRD описывает «как» на уровне системы (фильтр реализован через dropdown, запрос к API /products?price_min=X&price_max=Y, кеширование на 5 минут). PRD — для продуктовой команды, FRD — для инженеров.
BRD и FRD. В некоторых организациях BRD переходит напрямую в FRD, минуя PRD. Это происходит, когда нет роли Product Manager, а Business Analyst работает одновременно с бизнесом и разработкой.
Что дальше
- PRD — полное руководство — как написать PRD, 9 вариаций
- PRD vs BRD — детальное сравнение двух документов
- Шаблоны PRD — готовые шаблоны
- Промпт-навигатор — определите нужный тип документа