BRD vs FRD vs SRS
Сравнение трёх ключевых документов требований: BRD (зачем, для бизнеса), FRD (что, для команды) и SRS (полная спецификация системы). Их цели, аудитория, содержание, объём и место в Waterfall и Agile.
Разные документы для разных людей
Представьте, что вы решили построить дом. Кто будет читать документы об этом доме?
- Инвестор (кто дает деньги) хочет знать, зачем вообще строить, сколько это будет стоить и когда окупится. Ему не нужны чертежи каждой стены.
- Архитектор хочет знать, как дом будет выглядеть, какие там комнаты, где окна.
- Прораб и строители хотят знать точные чертежи, материалы, технологии – как именно строить.
В разработке программного обеспечения те же роли и те же документы. Для разных целей и разных читателей нужны разные документы.
BRD (Business Requirements Document) – документ бизнес-требований. Для тех, кто принимает решения и дает деньги. FRD (Functional Requirements Document) – документ функциональных требований. Для аналитиков, дизайнеров, разработчиков. SRS (Software Requirements Specification) – спецификация требований к программному обеспечению. Самый полный документ, объединяющий всё.
BRD – Business Requirements Document
Что это такое
BRD – это документ, который описывает, ЗАЧЕМ нужен проект с точки зрения бизнеса. Это самый верхний уровень.
Для кого пишется
- Заказчики и спонсоры – люди, которые принимают решение о финансировании.
- Топ-менеджмент – те, кто утверждает стратегию.
- Руководители проекта – чтобы понимать цели и границы.
Что внутри
BRD отвечает на вопросы “зачем?” и “что получим в итоге?”. В нем почти нет технических деталей.
Типичное содержание BRD:
| Раздел | Описание |
|---|---|
| Цели и задачи проекта | Какие бизнес-цели достигаем (увеличить прибыль, снизить расходы). Обязательно с цифрами. |
| Текущая ситуация | Как сейчас, какие проблемы. |
| Предлагаемое решение | Что будем делать, общее описание. |
| Границы проекта | Что входит, что НЕ входит. |
| Заинтересованные лица | Кто влияет на проект, кого нужно опрашивать. |
| Ключевые метрики успеха | Как поймем, что проект удался. |
| Бюджет и сроки (оценка) | Очень примерно. |
| Риски | Что может пойти не так. |
Как выглядит
BRD – это обычно документ на 10-20 страниц, написанный понятным бизнес-языком. Много текста, мало схем, никакого кода.
Пример фрагмента BRD
1. ЦЕЛИ ПРОЕКТА
Увеличить повторные продажи интернет-магазина на 15% в течение 6 месяцев
после внедрения за счет внедрения программы лояльности для постоянных клиентов.
2. ТЕКУЩАЯ СИТУАЦИЯ
В настоящее время 70% клиентов совершают покупку один раз и больше не возвращаются.
Конкуренты активно используют накопительные скидки и персональные предложения.
3. ГРАНИЦЫ ПРОЕКТА
ВХОДИТ:
- Накопительная система скидок
- Личный кабинет с историей покупок
- Отправка персональных предложений по email
НЕ ВХОДИТ:
- Мобильное приложение (отдельный проект)
- Интеграция с CRM (уже есть)FRD – Functional Requirements Document
Что это такое
FRD – это документ, который описывает, ЧТО КОНКРЕТНО должна делать система. Какие функции, как они работают, как взаимодействуют с пользователем.
Для кого пишется
- Аналитики – чтобы зафиксировать детали.
- Дизайнеры – чтобы понимать логику экранов.
- Разработчики – чтобы знать, что программировать.
- Тестировщики – чтобы понимать, что проверять.
Что внутри
FRD детализирует требования до уровня конкретных функций. Здесь уже появляются сценарии, логика, правила.
Типичное содержание FRD:
| Раздел | Описание |
|---|---|
| Функциональные требования | Что система должна делать (по модулям или по пользовательским сценариям). |
| Пользовательские сценарии | Use Cases или User Stories с деталями. |
| Бизнес-правила | Ограничения и правила, которые система должна соблюдать. |
| Требования к интерфейсам | Общие принципы (не дизайн, а логика). |
| Требования к интеграции | Как система общается с внешним миром. |
| Критерии приемки | Как проверить, что функция работает правильно. |
Как выглядит
FRD – это более технический документ, чем BRD. Много схем, таблиц, детальных описаний. Может быть от 20 до 100+ страниц.
Пример фрагмента FRD
3.2. МОДУЛЬ "КОРЗИНА"
3.2.1. Добавление товара в корзину
- При нажатии на кнопку "В корзину" товар добавляется в корзину.
- Если товар уже есть в корзине, увеличивается количество на 1.
- После добавления иконка корзины показывает общее количество товаров.
3.2.2. Применение промокода
- В корзине есть поле для ввода промокода и кнопка "Применить".
- При вводе существующего активного промокода сумма пересчитывается.
- Показывается сообщение "Промокод применен".
- При неверном промокоде показывается сообщение об ошибке.
3.2.3. Оформление заказа
- При нажатии "Оформить заказ" проверяется, авторизован ли пользователь.
- Если не авторизован - перенаправление на страницу входа.
- Если авторизован - открывается страница с формой заказа.SRS – Software Requirements Specification
Что это такое
SRS – это самый полный документ, который объединяет всё: и бизнес-цели, и функциональные требования, и нефункциональные требования, и ограничения. Это “конституция” проекта.
Для кого пишется
- Вся команда – от заказчика до тестировщика.
- Подрядчики – если разработка отдается на аутсорс, SRS – основа договора.
- Архитекторы – для проектирования системы.
Что внутри
SRS содержит всё, что нужно знать о требованиях к системе. Это энциклопедия проекта.
Типичное содержание SRS (по стандарту IEEE 830):
| Раздел | Описание |
|---|---|
| Введение | Цели, область действия, определения, ссылки. |
| Общее описание | Контекст, пользователи, ограничения, предположения. |
| Функциональные требования | Детальное описание всех функций (как в FRD). |
| Нефункциональные требования | Производительность, безопасность, надежность и т.д. |
| Требования к интерфейсам | Пользовательские интерфейсы, API, интеграции. |
| Ограничения | Технологии, стандарты, законы. |
| Приложения | Схемы, прототипы, глоссарий. |
Как выглядит
SRS – это большой и серьезный документ. Может быть от 50 до нескольких сотен страниц. Обычно имеет титульный лист, историю изменений, утверждающие подписи.
Сравнение: BRD vs FRD vs SRS
| Характеристика | BRD | FRD | SRS |
|---|---|---|---|
| Основной вопрос | ЗАЧЕМ? | ЧТО? | ВСЕ О СИСТЕМЕ |
| Уровень | Бизнес-уровень | Функциональный уровень | Полная спецификация |
| Аудитория | Заказчики, топ-менеджмент | Аналитики, дизайнеры, разработчики | Вся команда |
| Детализация | Низкая | Средняя/Высокая | Очень высокая |
| Технические детали | Нет | Есть | Есть все |
| Нефункциональные требования | Нет | Обычно нет (или кратко) | Есть обязательно |
| Объем | 10-20 стр | 20-100+ стр | 50-500+ стр |
| Когда создается | В самом начале | После утверждения BRD | После сбора всех требований |
Как они связаны между собой
На практике эти документы не существуют изолированно. Они вытекают один из другого.
Типичный процесс:
Сначала пишется BRD. Встречи с заказчиком, выяснение целей, границ, бюджета. Получение одобрения.
На основе BRD пишется FRD. Берутся бизнес-цели и начинается детализация. Описываются функции, сценарии, правила. Согласовывается с заказчиком и командой.
Объединение в SRS. Добавление нефункциональных требований, ограничений, уточнение деталей. На выходе полный документ, по которому можно строить систему.
В реальной жизни границы могут размываться. В небольших проектах могут объединять FRD и SRS в один документ. В Agile вообще стараются не писать толстых документов, а хранить требования в виде User Stories в Jira и дополнительной документации в Confluence.
Место BRD, FRD и SRS в гибких методологиях (Agile)
В классическом “водопадном” подходе эти три документа идут строго друг за другом. В гибкой разработке (Agile) философия меняется: команда фокусируется на работающем продукте, а не на исчерпывающей документации. Поэтому жесткое разделение на BRD, FRD и SRS либо стирается, либо трансформируется в более легкие форматы.
BRD (Бизнес-требования) остаются отправной точкой, но часто существуют в виде “Vision Document” или “Product Roadmap”. Это может быть набор эпиков в Jira, которые описывают, какие бизнес-ценности и для каких пользователей мы создаем в ближайшие кварталы.
FRD и SRS в их классическом виде (многотомные фолианты с детальным описанием каждого экрана) в Agile практически не используются. Их роль выполняют User Stories (Пользовательские истории) в бэклоге продукта. Каждая история (например, “Как клиент, я хочу оплатить заказ картой”) содержит в себе и функциональное требование, и критерии приемки (которые по сути являются мини-SRS).
Дополнительная документация не исчезает полностью. Детали сложных алгоритмов, интеграций или протоколов взаимодействия выносятся в отдельные ADRs (Architecture Decision Records) или страницы в Confluence. Они служат справочной информацией, но не являются исчерпывающим описанием всего продукта.
Таким образом, если в “водопаде” BRD, FRD и SRS – это последовательные этапы заморозки требований, то в Agile это живой цикл: есть бизнес-видение (BRD), которое нарезается на итерации в виде функциональных историй (FRD), а технические уточнения по ним (SRS) возникают в момент разработки и фиксируются точечно.
Резюме для системного аналитика
BRD – для бизнеса, про “зачем”. Это фундамент. Даже в Agile вы должны понимать цели и границы проекта, просто вместо толстого документа это может быть дорожная карта продукта или видение (Бизнес-требования/BR) описанное в Confluence.
FRD – для команды, про “что”. В классике это отдельный документ. В гибких методологиях его роль выполняют User Stories с четкими критериями приемки, разложенные в бэклоге. Вы описываете не все сразу, а итеративно детализируете функциональность к спринту.
SRS – полная спецификация, “все о системе”. Здесь вы объединяете функциональные и нефункциональные требования, но в современном мире этот документ часто живет в распределенном виде: архитектурные решения – в ADR, логика – в описании задач, интерфейсы – в прототипах.
В реальной жизни границы размыты. Будьте гибкими: на одном проекте потребуется строгий трафарет SRS, на другом – достаточно хорошо структурированной доски в Jira и пары страниц в Confluence. Адаптируйтесь под методологию и реальные потребности команды.
Главное – чтобы требования были зафиксированы и поняты. Неважно, называете вы это BRD, FRD, SRS или просто “описанием задачи в бэклоге”. Важно, чтобы у бизнеса, аналитика и разработчиков не оставалось разногласий по поводу того, что нужно реализовать.