BRD - По слоям и компонентам функционала
BRD - Телеграм бот для уведомления партнеров
-
Back: Методология
Методология описания Back BRD {#metodologiya-opisaniya-back-brd}
Обновлено: 16.06.2026 Назначение: единый стандарт написания BRD для Back-раздела.
1. Что такое Back BRD? {#1-chto-takoe-back-brd}
Back BRD описывает бизнес- и системные требования к данным, правилам и ограничениям системы.
Документ пишется в первую очередь для backend-разработчиков, но должен быть понятен всей команде.
Back BRD отвечает на вопросы:
– какие сущности и данные хранит система; – какие операции с ними доступны; – какие ограничения, валидации, статусы и связи обязательны; – какие правила являются источником истины на стороне системы; – что вынесено в другие разделы.
Back BRD не описывает:
– frontend-сценарии: экраны, тексты интерфейса, визуальные состояния, макеты и поведение элементов интерфейса;
2. Источники для написания {#2-istochniki-dlya-napisaniya}
Перед написанием BRD автор изучает гайдбук текущего раздела и связанные разделы, чтобы не дублировать требования.
Главный принцип: если правило уже описано в связанном разделе, в текущем документе оно не повторяется. В текущем документе ставится ссылка на нужный раздел в блоке «Не входит» или в комментарии к требованию, если это важно для понимания.
После получения файла о фактической реализации от команды разработки автор сверяет изначальные требования с реализацией и проставляет статусы требований.
3. Язык и стиль {#3-yazyk-i-stil}
Пишем на языке системы, но без лишних англицизмов.
Используем «Карточка клиента», а не «Client».
Формулировки должны быть короткими:
– одно требование = одно проверяемое правило без длинных бизнес-процессов; – без дублирования связанных разделов.
4. Структура документа {#4-struktura-dokumenta}
Верхний блок {#verhnij-blok}
Направление работ: Back Код раздела: код из полного перечня работ Раздел: название раздела Статус: черновик / на валидации / готов Ответственный: автор статьи Версия: 0.1 Обновлено: дата последнего обновления
Статус «готов» ставится после сверки со стороны СЕО и сверки с фактической реализацией.
1. Назначение {#1-naznachenie}
Назначение описывает, зачем существует раздел и что обеспечивает система.
Объем: 3-5 предложений.
Организация аккаунтов задает общую модель Аккаунтов в системе: связь с Карточкой клиента, состояния аккаунта, учетные данные, тариф и права доступа.
Система хранит аккаунты и общие ограничения, которые используют процессы регистрации, входа, восстановления доступа и дополнительных способов входа.
2. Ключевые понятия {#2-klyuchevye-ponyatiya}
Первым указывается ключевое понятие раздела: сущность или процесс, которому посвящен документ. В его название вставляется ссылка на соответствующую статью гайдбука.
Далее включаются только термины, нужные для понимания требований данного раздела.
Если термин уже описан в другом разделе, даем короткое определение и ссылкуна соответствующую BRD Back статью.
Определения пишем простыми понятными словами.
Карточка клиента — сущность для хранения персональной информации об аккаунте, истории заказов и отношений с партнерами.
3. Scope {#3-scope}
Scope — это граница документа. Он содержит 2 блока: Входит и Не входит.
В блоке «Входит» должно быть 5-10 составляющих. Каждый пункт — 1 строка
Каждому пункту «Входит» присваивается номер:
S1 S2 S3
…
Требования должны идти в том же порядке, что и Scope.
Рекомендуемая структура Scope для Back BRD:
Ключевые сущности и их параметры:
– сущность; – параметры и данные; – состояния и статусы; – связанные сущности.
Реализуемые процессы и их правила:
– создание; – изменение; – архивация; – восстановление; – удаление.
Ограничения:
– валидация; – лимиты; – безопасность; – производительность.
Пограничные случаи и прочее
Не нужно искусственно включать все группы. Scope должен быть коротким и соответствовать конкретному разделу. В scope включаются только те пункты, которые есть в гайдбуке или подтверждены согласованной backend-реализацией.
В блоке «Не входит» перечисляются связанные задачи, которые не описываются в этом BRD. По возможности указывается ссылка на раздел, где они должны быть описаны.
4. Требования {#4-trebovaniya}
В этом разделе описываются правила заполнения таблицы требований.
Таблица требований содержит колонки:
ID Требование Комментарий Тип требования Вес Статус
Правила заполнения таблицы:
ID {#id}
Заполняется в Markdown-режиме в формате: (тут надо либо скрин с маркдаун режима вставить, либо чет придумать, тк он не дает показать без маркдаун режима как это под капотом выглядит)
номер Scope : BR + ID задачи-номер требования
S1: BR1.1-1
Этот идентификатор должен стать кликабельным, чтобы его можно было связать с frontend BRD и ссылаться на конкретное требование.
Требование {#trebovanie}
Формулируется как короткое проверяемое правило к системе.
На один Scope обычно пишется 1-5 требований. Максимум — 10 требований на один Scope, если раздел действительно сложный.
Система поддерживает несколько активных сессий и позволяет избегать повторной авторизации в течение длительного периода
Комментарий {#kommentarij}
Заполняется, если нужно раскрыть или уточнить требование.
Он не должен становиться вторым требованием. Если в комментарии появилось самостоятельное правило, его нужно вынести отдельным требованием.
Тип требования {#tip-trebovaniya}
Используются только три типа:
– Бизнес — описывает бизнес-смысл, продуктовую логику или ограничение предметной области.
– Системное — описывает поведение системы, связи сущностей, проверки, статусы или доступность операций.
– Техническое — описывает формат, например: хранение, технический ключ, автоматическое заполнение, файл, токен, срок действия или другой технический параметр.
Вес {#ves}
Вес показывает критичность требования и определяет приоритизацию реализации.
1 — без этого система не может работать.
Пример: «Связь Аккаунта и Карточки клиента является 1:1».
2 — пограничный случай: система может работать, но несет риски.
Пример: «Система ограничивает количество попыток ввода учетных данных».
3 — система будет работать нормально без этого, это не влияет на релиз.
Статус {#status}
Статус заполняется на второй итерации, когда BRD сверяется с фактической реализацией.
До сверки с фактической реализацией статус остается пустым.
Допустимые значения:
– Реализовано — работает в соответствии с BRD; – Нереализовано — полностью не соответствует BRD или не реализовано; – ссылка на ID открытого вопроса — работает, но не полностью соответствует требованию.
5. Открытые вопросы {#5-otkrytye-voprosy}
Открытый вопрос фиксирует неопределенность, которую нельзя решить на уровне автора BRD.
Открытый вопрос возникает в двух случаях:
– на этапе написания BRD по гайдбуку, если в гайдбуке не хватает данных или есть противоречие; – на этапе сверки с фактической реализацией, если требование реализовано и работает, но не полностью соответствует изначальному требованию.
ID открытого вопроса заполняется в Markdown-режиме, чтобы его можно было сделать кликабельным.
Формат ID:
OQ + код раздела + номер вопроса
Пример: OQ1.1-1
Статусы: Open / Closed.
Все открытые вопросы обсуждаются на еженедельной встрече с командой.
Порядок работы над BRD {#poryadok-raboty-nad-brd}
- Изучить гайдбук раздела и связанные разделы, чтобы не дублировать требования.
- Выделить сущность или процесс, который является центром документа.
- Сформировать короткий Scope с номерами S1-Sn и уточнить разделы, которые не входят в текущую документацию, со ссылками на них.
- Написать требования в порядке Scope.
- Проставить тип требования и вес.
- Вынести спорные места в открытые вопросы.
- После получения файла о фактической реализации сверить BRD с реализацией и заполнить статусы требований.
-
Back: Шаблон
Шаблон Back BRD
Направление работ: Back Код раздела: Статус: Ответственный: Версия: Обновлено:
1. Назначение
Коротко описать зачем существует раздел и что обеспечивает система. (2-5 предложений)
2. Ключевые понятия
Термин 1 — определение.
Термин 2 — определение.
Термин 3 — определение.
3. Scope
Входит
S1:
S2:
S3:
Не входит
–
–
–
Указать связанные разделы, которые не описываются в текущем Back BRD.
4. Требования
Правила и ограничения бизнеса на уровне данных, источник истины в системе
| ID | Требования | Комментарий | Тип требования | Вес | Статус |
|---|---|---|---|---|---|
| S1: #BR1.1-1 |
5. Открытые вопросы
| ID | Источник | Вопрос | Кому | Статус |
|---|---|---|---|---|
| #OQ1.1-1 | Open |
-
Front: Методология
Обновлено: 17.06.2026 Назначение: единый стандарт написания BRD для Front-разделов: WebLk, Widget, Mobile и других пользовательских интерфейсов
1. Что такое Front BRD?
Front BRD описывает пользовательские сценарии, интерфейсное поведение и функциональные требования к frontend-разделу.
Документ пишется в первую очередь для frontend-разработчиков, дизайнеров и аналитиков, но должен быть понятен всей команде.
Front BRD отвечает на вопросы:
– какие экраны, разделы и интерфейсные области входят в задачу; – какие действия выполняет пользователь; – что интерфейс показывает пользователю; – какие состояния интерфейса должны быть предусмотрены; – какие frontend-проверки, ограничения и ошибки должны отображаться; – какие backend-правила используются как источник истины; – что вынесено в другие разделы.
Front BRD не описывает:
– структуру БД; – API-контракты; – backend-реализацию проверок; – внутреннюю бизнес-логику системы, если она уже описана в Back BRD; – расчеты, хранение данных и системные ограничения, которые не проявляются в интерфейсе.
Если правило относится к данным и их валидности, оно описывается в Back BRD. Если правило описывает, как пользователь видит это правило, не может его нарушить или получает ошибку, оно описывается в Front BRD.
2. Источники для написания
Перед написанием Front BRD автор изучает:
– макеты и комментарии дизайнера; – связанные frontend-разделы; – связанные Back BRD, т.к. интерфейс зависит от backend-правил; – фактическую реализацию, если имеется
Основной источник истины для Front BRD — согласованный пользовательский flow и макеты.
Back BRD используется как источник бизнес-правил и ограничений. Front BRD не должен заново формулировать backend-логику как самостоятельные BR. Вместо этого frontend-требование ссылается на соответствующие BR.
Если в макетах и факт реализацией есть расхождения, это фиксируется как открытый вопрос.
3. Язык и стиль
Пишем языком интерфейса и пользовательского сценария.
Формулировка должна отвечать на вопрос: что пользователь делает и что интерфейс должен показать или позволить сделать.
Одно функциональное требование = один проверяемый сценарий или действие.
Хорошая формулировка:
Интерфейс позволяет выбрать одну или несколько ячеек матрицы стоимостей и задать для них общее значение стоимости.
Плохая формулировка:
Система должна корректно работать с ценами.
В Front BRD допускаются термины интерфейса:
– экран; – список; – карточка; – вкладка; – фильтр; – кнопка; – модальное окно; – индикатор ошибки; – состояние загрузки; – пустое состояние.
Но не нужно описывать pixel-perfect реализацию, если она уже есть в макете. BRD фиксирует поведение и требования, а не заменяет дизайн.
4. Структура документа
Верхний блок
Направление работ: WebLk / Widget / Mobile / другой Front-раздел Код раздела: код из полного перечня работ Раздел: название раздела Статус: черновик / на валидации / готов Ответственный: автор статьи Версия: 0.1 Обновлено: дата последнего обновления
Статус «готов» ставится только после согласования scope, требований, сверки с фактической реализацией, и выставленных связей с BR
1. Назначение
Назначение описывает, зачем существует интерфйсный раздел и какую пользовательскую задачу он решает.
Объем: 3–5 предложений.
В назначении нужно указать:
– кто пользователь раздела; – какую задачу он решает; – какие основные действия выполняет; – от каких Back BRD или системных компонентов зависит раздел.
Пример:
Данный раздел обеспечивает партнеру интерфейс для управления ценами в рамках партнерской зоны. Партнер создает, редактирует, архивирует, восстанавливает и удаляет цены, а также настраивает условия их применения. Раздел зависит от Back: 2.6, операции с ценами выполняются через API Back-end.
2. Ключевые понятия
В ключевые понятия включаются только термины, необходимые для понимания frontend-сценариев.
Для Front BRD важно раскрывать:
– интерфейсные сущности: экран, список, карточка, вкладка, форма, контейнер; – пользовательские представления backend-сущностей; – визуальные группировки; – статусы и состояния, если они отображаются пользователю; – специфичные элементы сценария.
Если термин уже описан в Back BRD, во Front BRD дается короткое определение с учетом интерфейсного смысла.
Например:
Экран настройки цен — экран/контейнер, в котором партнер настраивает набор цен для выбранной площадки: стандартную цену и дополнительные цены во вкладках.
Не нужно раскрывать внутреннюю структуру backend-сущностей, если она не нужна для интерфейса.
3. Scope
Scope — это граница frontend-документа. Он содержит 2 блока: «Входит» и «Не входит».
В блоке «Входит» перечисляются пользовательские сценарии, экраны или интерфейсные области, которые описываются в статье.
Каждому пункту «Входит» присваивается номер:
S1 S2 S3 …
Требования должны идти в том же порядке, что и Scope.
Рекомендуемая структура Scope для Front BRD:
– вход в раздел / открытие экрана; – создание сущности или настройка с нуля; – заполнение основных данных; – настройка условий или дополнительных параметров; – список, карточки, фильтрация, поиск, сортировка; – просмотр существующей сущности; – редактирование; – архивация, восстановление, удаление, если действие доступно в интерфейсе; – массовые действия; – состояния интерфейса: загрузка, пусто, ошибка, блокирующая ошибка, успешное действие; – пограничные интерфейсные случаи.
Не нужно искусственно включать все группы. Scope составляется под конкретный раздел и конкретный пользовательский flow.
В блоке «Не входит» перечисляются связанные задачи, которые не описываются в текущем Front BRD. По возможности указывается раздел, где они должны быть описаны.
4. BR
В этом разделе указываются backend business requirements, на которые ссылается Front BRD.
Если для frontend-раздела есть связанный Back BRD, в разделе пишется:
Указаны в пункте 4 раздела Back: X.X Название раздела.
Front BRD не дублирует таблицу BR, если BR уже описаны в Back BRD.
Если backend-правило отсутствует, но необходимо для frontend-сценария, это фиксируется как открытый вопрос или как зависимость от Back BRD.
5. Функциональные требования
Функциональные требования описываются в формате UC + FR:
– UC / сценарий — что делает пользователь; – FR — что должен сделать интерфейс в этом сценарии.
Таблица требований содержит колонки:
ID Сценарий Функциональное требование BR Вес Статус
ID
ID заполняется в формате:
номер Scope : FR + код раздела - номер требования
Пример:
S1: FR4.4-1
Этот идентификатор должен стать кликабельным.
Сценарий
Сценарий формулируется от лица пользователя:
– Партнер открывает список цен; – Партнер добавляет цену; – Партнер изменяет матрицу стоимостей; – Партнер применяет массовое действие.
Сценарий не должен быть техническим.
Функциональное требование
Функциональное требование описывает поведение интерфейса.
Оно должно отвечать на вопросы:
– что интерфейс показывает; – что интерфейс позволяет сделать; – что происходит после действия; – какие ограничения видит пользователь; – какую ошибку или состояние нужно показать.
Если требование зависит от Back BR, в тексте FR описывается интерфейсная реакция, а не backend-логика.
Пример:
Интерфейс отображает результат проверки системой бизнес-правил: сохраняет изменения при успехе или показывает причину отказа при ошибке.
BR
В колонке BR указываются связанные backend-правила.
Если frontend-требование не зависит от Back BR, ставится «–».
Пример:
– переключение вкладки; – раскрытие блока; – состояние загрузки; – локальное отображение фильтра.
Если frontend-требование показывает результат backend-проверки, нужно указать соответствующий BR.
Тип требования
В Front BRD отдельная колонка «Тип требования» обычно не используется, потому что все требования в таблице являются функциональными frontend-требованиями.
Если тип нужен в конкретном проекте, допускаются значения:
– Функциональное; – Интерфейсное; – Состояние интерфейса; – Валидация интерфейса.
Вес
Вес показывает критичность frontend-требования.
1 — без этого пользователь не может выполнить основной сценарий.
Пример: «Интерфейс позволяет создать цену и сохранить ее при корректном заполнении».
2 — сценарий работает, но без требования есть риск ошибки, потери данных или непонятного поведения.
Пример: «Интерфейс показывает индикатор ошибки на скрытой вкладке».
3 — улучшение удобства, не блокирующее основной сценарий.
Пример: «Интерфейс запоминает выбранный фильтр в рамках текущей сессии».
Статус
Статус заполняется после сверки с макетами и фактической реализацией.
До сверки статус остается пустым.
Допустимые значения:
– Реализовано — работает в соответствии с FR; – Нереализовано — отсутствует или полностью не соответствует FR; – ссылка на ID открытого вопроса — реализовано частично или есть расхождение между макетом, BRD и реализацией.
6. Открытые вопросы
Открытый вопрос фиксирует неопределенность, которую нельзя решить на уровне автора BRD.
Открытый вопрос возникает, если:
– макет и фактическая реализация расходятся; – в макете нет сценария, который нужен по flow; – непонятно, должен ли сценарий быть на Front или на Back; – backend-правило отсутствует, но интерфейс должен на него опираться; – фактическая реализация расходится с утвержденным требованием.
ID открытого вопроса заполняется в формате:
OQ + код раздела + номер вопроса
Пример:
OQ4.4-1
Статусы: Open / Closed.
Все открытые вопросы обсуждаются на встрече с ответственными за продукт, дизайн и разработку.
Порядок работы над Front BRD
-
Изучить макеты и комментарии дизайнера.
-
Определить основной пользовательский flow.
-
Выделить экраны, состояния и действия пользователя.
-
Сформировать Scope с номерами S1–Sn.
-
Указать, что не входит в текущий Front BRD.
-
Проверить связанные Back BRD и определить, какие BR нужны для ссылок.
-
Написать FR в порядке Scope.
-
Проставить связи с BR.
-
Проставить вес.
-
Вынести спорные места в открытые вопросы.
-
После сверки с макетами и реализацией заполнить статусы требований.
-
-
Front: Шаблон
Шаблон Front BRD
Направление работ: WebLk / Widget / Mobile / AdmLk Код раздела: Статус: черновик Ответственный: Версия: 0.1 Обновлено:
1. Назначение
Коротко описать, зачем существует раздел, кто им пользуется и какую пользовательскую задачу он решает.
Указать основные действия пользователя и зависимость от Back BRD, если она есть.
2. Ключевые понятия
Термин 1 — определение.
Термин 2 — определение.
Термин 3 — определение.
Включать только понятия, которые нужны для понимания интерфейсных сценариев, экранов, состояний и требований.
3. Scope
Входит
S1:
S2:
S3:
Не входит
–
–
–
Указать связанные разделы, которые не описываются в текущем Front BRD.
4. BR
Указаны в пункте 4 раздела Back: X.X Название раздела.
Если связанного Back BRD нет или он еще не готов, указать:
Связанные BR требуют уточнения в Back: X.X Название раздела.
5. Функциональные требования (UC + FR)
FR — functional requirement: что интерфейс должен уметь делать в рамках конкретного пользовательского сценария.
| ID | Сценарий | Функциональное требование | BR | Вес | Статус |
|---|
6. Открытые вопросы
| ID | Источник | Вопрос | Кому | Статус |
|---|