Как написать бизнес-требования к проекту: полное руководство с примерами и шаблоном BRD

Что такое бизнес-требования проекта

Определение простыми словами

Бизнес-требования проекта — это зафиксированное описание того, зачем нужен проект, каких бизнес-целей он должен достичь и какие условия должны быть выполнены, чтобы считаться результатом. Они не говорят «как сделать» — только «что должно получиться и почему это важно».

Более точное определение из практики: бизнес-требования описывают измеримую потребность организации, которую проект или продукт должен удовлетворить. Именно из них потом вырастают пользовательские истории, функциональные требования и в итоге — техническое задание.

Зачем нужны бизнес-требования: 5 весомых причин

В каждом втором комплексном ИТ-проекте в российских компаниях требуется доработка после внедрения. При этом 35% неудач прямо связаны с тем, что внедренное решение не соответствовало фактическим бизнес-требованиям компании. Затраты на исправление ошибок составляют от 10 до 30% бюджета — а в самых запущенных случаях перезапуск проекта обходится в двойную стоимость.

Вот что конкретно дает команде наличие документа бизнес-требований:

• Общий язык. Заказчик, аналитик, разработчик и тестировщик видят одну и ту же картину. Никто не додумывает детали самостоятельно.
• Управление ожиданиями. Заказчик подписывается под конкретными формулировками — и потом сложнее сказать «я имел в виду другое».
• Точка отсчета при конфликтах. Когда на третьем спринте появляется новая «хотелка», документ помогает оценить: это расширение скоупа или изначально запланированная функция?
• Основа для тестирования. Хорошо написанное бизнес-требование тестируемо: из него прямо вытекают критерии приемки.
• Защита бюджета. Без зафиксированных требований легко согласиться на scope creep — постепенное «раздувание» проекта, которое не укладывается ни в сроки, ни в деньги.

Кто использует бизнес-требования и когда

Документ бизнес-требований появляется на самом раннем этапе — на стадии инициации проекта, еще до первого спринта или написания ТЗ. В нем заинтересованы сразу несколько ролей.

В небольших командах — например, в стартапах или в продуктовых командах, — роль бизнес-аналитика часто берет на себя продакт или владелец продукта. В крупных корпоративных проектах (внедрение ERP, CRM, замена банковского ядра) это отдельный специалист с полной занятостью на проекте.

Бизнес-требования «живут» на протяжении всего жизненного цикла проекта: их создают до старта, корректируют в процессе и архивируют после внедрения — как артефакт, к которому можно вернуться при масштабировании продукта.

Аббревиатуры и синонимы: BRD, БТ, бизнес-требования

В профессиональной среде одно и то же понятие называют по-разному — в зависимости от контекста, компании и стандарта, с которым работает команда.

BRD (Business Requirements Document) — это английское название документа бизнес-требований. Аббревиатура пришла из практики системной инженерии и стандарта Six Sigma, который закрепил понятие Business Requirement Definition как официальный артефакт. Сегодня BRD используется как устойчивый термин в ИТ-проектах вне зависимости от применяемой методологии.

БТ — сокращение, принятое в русскоязычных командах. Неофициальное, но повсеместно распространенное: встречается во внутренних регламентах большинства российских ИТ-компаний.

Международный стандарт BABOK Guide v3 (свод знаний по бизнес-анализу от IIBA) дает наиболее точное определение: бизнес-требования — это «представление целей, задач и результатов, объясняющих, зачем было инициировано изменение и как будет оцениваться успех». Иными словами, бизнес-требование отвечает на вопрос «почему» — в отличие от функциональных требований, которые отвечают на вопрос «что», и технических решений, которые отвечают на вопрос «как».

Есть еще одна важная деталь, которую BABOK подчеркивает, но о которой часто забывают: бизнес-требования не зависят от конкретных стейкхолдеров*. Если завтра на месте заказчика появится другой человек, а суть бизнеса останется той же — требование не изменится. Это принципиальное отличие от пользовательских требований, которые всегда привязаны к конкретным ролям и процессам.

Простой тест на «бизнес-требовательность»: задайте себе два вопроса.

• Изменится ли требование, если его сформулирует другой человек на той же должности?
• Изменится ли требование, если поменяется бизнес-процесс, но не изменится цель бизнеса?

Если ответ на оба вопроса — «нет», перед вами настоящее бизнес-требование.

Кроме BABOK, с бизнес-требованиями работают в рамках стандартов PMI (там используется термин business requirements в контексте управления проектами) и ISO/IEC/IEEE 29148:2018, который начиная с версии 2018 года явно разграничивает Business Requirements и Stakeholder Requirements как два отдельных уровня. В России наряду с международными стандартами формально действует ГОСТ 34 серии, который оперирует понятием «требования пользователя», однако на практике в коммерческих ИТ-проектах ГОСТ применяется редко — его используют преимущественно при госзаказе и в ОПК.

Виды бизнес-требований — какие они бывают

Верхнеуровневые (высокоуровневые) требования

Верхнеуровневые требования — это самый абстрактный слой документации. Они не описывают ни функции системы, ни поведение пользователя. Они отвечают на один вопрос: зачем вообще нужен этот проект?

Типичный пример верхнеуровневого бизнес-требования: «Увеличить долю повторных заказов на маркетплейсе на 20% за 12 месяцев за счет запуска программы лояльности». Здесь нет ни слова о технической реализации — только цель, метрика и срок. Именно из таких формулировок потом вырастают конкретные задачи для продукта, дизайна и разработки.

Верхнеуровневые бизнес-требования фиксируют почему инициирован проект и как будет оцениваться успех — это прямая цитата из определения BABOK Guide v3. Такие требования нередко появляются как результат стратегической сессии или OKR-цикла и становятся отправной точкой для формирования продуктового бэклога.

Четыре уровня требований: иерархия от «зачем» к «как»

Профессиональная среда использует несколько классификаций. Наиболее распространенные в российских командах — модель Карла Вигерса и классификация BABOK v3. Они немного расходятся в терминологии, но логика у них одна: требования выстраиваются в иерархию от бизнес-целей до технических деталей.

Бизнес-требования стоят на вершине этой пирамиды. Все, что ниже, должно быть с ними трассируемо — то есть каждую функцию системы можно соотнести с конкретной бизнес-целью. Если функция не связана ни с одним бизнес-требованием, это красный флаг: либо требование не задокументировано, либо функция лишняя.

Функциональные vs. нефункциональные требования: в чем разница

Это разграничение — источник бесконечной путаницы. Особенно у тех, кто пришел в роль бизнес-аналитика из разработки или менеджмента.

Функциональные требования описывают, что система делает: какие операции выполняет, как реагирует на действия пользователя, какую логику реализует. Например: «Система отправляет пуш-уведомление при изменении статуса заказа».

Нефункциональные требования описывают, как хорошо система это делает: насколько быстро, надежно, безопасно и удобно. Пример из практики: «Время отклика API оформления заказа — не более 500 мс при нагрузке до 1000 RPS». Это требование к качеству, а не к функции.

Граница между ними иногда размывается. Если заказчик говорит: «Хочу, чтобы приложение работало быстро» — это еще не требование. Это пожелание, которое нужно превратить в измеримый критерий. Слова «быстро», «надежно», «удобно» в бизнес-документации без цифр и контекста — не требования, а источник конфликтов на этапе приемки.

Пользовательские требования

Пользовательские требования (в BABOK — stakeholder requirements) — это мост между бизнес-целями и функциями системы. Они описывают, что именно пользователь хочет делать с продуктом в своей повседневной работе.

Классическая форма записи — User Story*: «Как покупатель, я хочу отслеживать статус доставки в приложении, чтобы знать, когда ожидать курьера». В отличие от бизнес-требования, пользовательское требование* всегда привязано к конкретной роли и сценарию.

Важно! Пользовательские требования зависят от людей и процессов. Если бизнес перейдет с доставки курьером на постаматы — пользовательское требование изменится. Бизнес-требование «снизить стоимость последней мили на 15%» при этом останется прежним.

Требования к качеству, безопасности и производительности

Нефункциональные требования часто незаслуженно откладывают «на потом» — и последствия наступают на нагрузочном тестировании или после утечки данных. В российских реалиях это особенно актуально: требования регулятора к обработке персональных данных (152-ФЗ), к информационной безопасности в финтехе (требования ЦБ РФ) и к хранению данных внутри страны — это тоже нефункциональные требования, и их нужно фиксировать на этапе BRD.

Основные группы нефункциональных требований выглядят так:

• Производительность — время отклика, пропускная способность, количество одновременных пользователей. Пример: «Сервис должен обрабатывать не менее 500 транзакций в секунду».
• Безопасность — аутентификация, авторизация, шифрование, аудит действий. Для банков и маркетплейсов это первоочередные требования, часто закрепленные регулятором.
• Доступность (SLA) — процент времени работоспособности системы. Пример: «Доступность сервиса — не менее 99,9% в месяц, плановые окна обслуживания — не более 4 часов в квартал».
• Масштабируемость — способность системы выдерживать рост нагрузки без деградации. Актуально для продуктов с сезонными пиками — например, сервисов доставки в период распродаж.
• Совместимость — поддерживаемые платформы, браузеры, версии API, интеграции с внешними системами.

Классификация по BABOK v3

BABOK Guide v3 делит все требования на пять типов. Это самая распространенная классификация в международной практике, и ее стоит знать хотя бы на уровне понятий.

Последний тип — transition requirements — это требования к миграции данных, обучению персонала, параллельной работе старой и новой систем. Без них переход на новое ПО превращается в нервный марафон. Именно такие требования нередко обнаруживаются в последний момент на крупных корпоративных внедрениях.

Чем бизнес-требования отличаются от ТЗ, функциональных и системных требований

Бизнес-требования vs. Техническое задание: принципиальная разница

Путаница между этими двумя документами — пожалуй, самое распространенное заблуждение в российской практике. Заказчики нередко говорят «нам нужно ТЗ», имея в виду документ с бизнес-целями. Разработчики просят «прислать требования» — и ждут конкретных экранов и API. В итоге обе стороны говорят на разных языках.

Главное отличие — в уровне абстракции и адресате документа.

Бизнес-требования пишутся для заказчика, руководителей, продакт-менеджера и аналитика. Они отвечают на вопрос «зачем?» и оперируют бизнес-метриками: выручка, конверсия, доля рынка, скорость процесса. Технических деталей в них нет и быть не должно.

Техническое задание — это следующий шаг. Оно пишется для команды разработки и отвечает на вопрос «что и как?». ТЗ содержит конкретные функции, алгоритмы, интерфейсы, протоколы интеграций, требования к инфраструктуре и юридически закрепляет обязательства сторон. В российском контексте ТЗ на государственные системы составляют по ГОСТ 34 серии — со структурой и обязательными разделами.

Простая аналогия: бизнес-требования — это бриф архитектору («нам нужен офис на 200 человек с переговорными, паркингом и зеленой зоной»). ТЗ — это проектная документация с чертежами, расчетами нагрузок и спецификацией материалов.

Иерархия требований: от «зачем» к «как»

Все типы требований выстраиваются в логическую цепочку. Каждый уровень вытекает из предыдущего и не может существовать сам по себе — иначе команда рискует построить технически безупречный продукт, который никому не нужен.

Бизнес-требования → Пользовательские требования → Функциональные требования → Техническое решение

Разберем на конкретном примере из российского рынка. Предположим, команда банка запускает новый раздел в мобильном приложении.

• Бизнес-требование:«Увеличить долю клиентов, пользующихся инвестиционными продуктами, с 12% до 20% за 9 месяцев».
• Пользовательское требование:«Клиент может открыть брокерский счет и купить первую акцию за 3 минуты, не выходя из приложения».
• Функциональное требование*:«Система предоставляет упрощенный онбординг для новых инвесторов: анкета из 5 вопросов, автоматическая проверка данных по СМЭВ, открытие счета без визита в отделение».
• Нефункциональное требование*:«Время ответа API проверки документов — не более 3 секунд, доступность сервиса — 99,95%».
• Техническое решение: конкретная архитектура, стек, интеграции с АБС и брокерской системой.

Если пропустить верхний уровень и сразу перейти к функциям — команда строит продукт вслепую. Если зафиксировать только бизнес-требования и не декомпозировать до функциональных — разработчики не поймут, что именно кодировать.

Когда бизнес-требования заменяют ТЗ — и наоборот

На практике строгой границы нет, и подход к документации зависит от типа проекта и зрелости команды.

В аутсорсной разработке BRD и ТЗ — обычно два отдельных документа. Заказчик передает BRD подрядчику, тот разрабатывает ТЗ и согласовывает его до старта работ. Это классическая схема для проектов с фиксированным бюджетом и водопадной моделью разработки.

В продуктовых инхаус-командах — отдельный BRD-документ нередко заменяют набором эпиков и user stories, где верхнеуровневый эпик* фактически и выполняет роль бизнес-требования. Product Owner держит контекст в голове или в кратком PRD (Product Requirements Document).

В стартапах на ранней стадии бизнес-требования часто существуют в виде одностраничного документа или даже слайда в питч-деке. Это нормально для MVP: главное, чтобы команда понимала, какую метрику они двигают и почему.

В государственных и корпоративных проектах документация регламентирована строже. Здесь BRD нередко является обязательным входным артефактом перед разработкой ТЗ по ГОСТ, и оба документа проходят официальное согласование с подписями.

Универсальное правило одно: чем выше неопределенность и чем больше стейкхолдеров — тем важнее зафиксировать бизнес-требования письменно и отдельно от технической документации. Устные договоренности не работают, когда в проекте участвуют три отдела, подрядчик и спонсор из совета директоров.

Отличный материал. Пишу пятый раздел.

Как формировать и разрабатывать бизнес-требования — пошаговый процесс

Шаг 1 — Определение стейкхолдеров и заинтересованных сторон

Прежде чем идти на первое интервью, нужно понять — с кем вообще разговаривать. Пропустить этого шага нельзя: если упустить ключевого стейкхолдера на старте, его требования всплывут позже — и переделка обойдется дороже, чем если бы его нашли сразу.

Стейкхолдеры делятся на несколько групп. Первая — спонсор и заказчик: тот, кто финансирует проект и несет за него ответственность. Вторая — конечные пользователи: те, кто будет работать с системой каждый день. Третья — смежные команды: маркетинг, юристы, финансы, IT-инфраструктура — все, на чью работу повлияют изменения. Четвертая — внешние стороны: регуляторы, партнеры, поставщики, если их интересы касаются проекта.

Удобный инструмент для этого — матрица влияние/интерес. По оси X — насколько стейкхолдер заинтересован в результате, по оси Y — насколько он влияет на проект. Те, кто попал в квадрант «высокое влияние + высокий интерес», должны участвовать в сборе требований лично. Остальных достаточно информировать или опросить письменно.

Шаг 2 — Методы сбора бизнес-требований

Не существует одного универсального метода, поэтому предпочтительно комбинировать подходы в зависимости от этапа и масштаба проекта. Вот основные инструменты с их плюсами и минусами:

Совет: начинайте с анализа существующих документов и первичных интервью с заказчиком. Так вы придете на воркшоп уже подготовленными — с гипотезами, а не с пустым листом.

Шаг 3 — Анализ и структурирование требований

После сбора информации начинается самое сложное — перевести записи интервью и заметки воркшопа в четкие, измеримые формулировки. Именно здесь большинство аналитиков теряют качество.

Первый инструмент — техника «5 почему». Заказчик говорит: «Хочу дашборд с отчетами». Спрашиваете: «Зачем?» — «Чтобы видеть продажи». «Зачем?» — «Чтобы принимать решения по акциям». «Зачем?» — «Чтобы не терять товар». На третьем-четвертом «почему» обычно появляется настоящее бизнес-требование: «Снизить уровень неликвидных остатков на складе на 15%». Дашборд — это уже инструмент, а не требование.

Второй важный момент — выявление скрытых и противоречивых требований. Разные стейкхолдеры видят проект по-разному: финансовый директор хочет сократить расходы, операционный — добавить функций, юрист — ограничить доступ к данным. Задача аналитика — не выбрать правого, а найти формулировку, которая учитывает все легитимные интересы или явно фиксирует компромисс.

Шаг 4 — Приоритизация требований: метод MoSCoW

Когда требований набирается много — а это неизбежно — нужно решить, что войдет в первый релиз, а что подождет. Самый распространенный в российских командах метод — MoSCoW, разработанный Даем Клеггом из Oracle еще в 1994 году.

Аббревиатура расшифровывается так:

• M — Must have (обязательно): без этого продукт не работает и нет смысла выпускать его вообще. Например, для интернет-магазина — оформление заказа и оплата.
• S — Should have (желательно): важно, но можно запустить без этого. Например, история заказов в личном кабинете.
• C — Could have (было бы хорошо): улучшает опыт, но не критично. Например, персонализированные рекомендации.
• W — Won’t have (не в этот раз): явно выводится за рамки текущего скоупа. Это не «никогда», а «не сейчас» — важная психологическая разница для заказчика.

Практический пример для e-commerce проекта — допустим, команда разрабатывает новый личный кабинет для маркетплейса:

Шаг 5 — Согласование и валидация требований с заказчиком

Написать BRD недостаточно. Важнее — убедиться, что все ключевые стейкхолдеры прочитали, осмыслили и подтвердили согласие. Иначе документ превращается в пустую декларацию.

Вот минимальный чек-лист перед финальным согласованием:

• Каждое требование имеет уникальный идентификатор (ID).
• Указан источник требования — кто его сформулировал и на каком основании.
• Требование измеримо: есть цифра, критерий или конкретный сценарий, по которому его можно проверить.
• Нет формулировок с «быстро», «удобно», «современно» без расшифровки.
• Требования не противоречат друг другу в пределах документа.
• Все стейкхолдеры из матрицы влияния ознакомлены с документом.
• Дата версии и история изменений зафиксированы.

Формат review зависит от аудитории. Заказчику удобнее смотреть на прототипы и схемы процессов. Разработчику — читать текстовые формулировки и таблицы. Юристу — видеть раздел с ограничениями и регуляторными требованиями. Хорошая практика — не отправлять документ «на прочтение», а проводить короткую встречу с разбором ключевых разделов. Люди подписывают то, что обсудили вслух, — и реже приходят с «а я имел в виду другое».

Критерии качества бизнес-требований

SMART-критерии для бизнес-требований

Методология SMART изначально создавалась для постановки целей, но в работе с бизнес-требованиями она работает не хуже. Каждый из пяти критериев — это фильтр, через который нужно пропустить любую формулировку перед тем, как зафиксировать ее в документе.

• S — Specific (конкретность). Требование описывает одну четкую ситуацию, а не размытое пожелание. «Система должна быть удобной» — не требование. «Пользователь должен завершить оформление заказа за не более чем 4 шага» — требование.
• M — Measurable (измеримость). Должен быть количественный критерий, по которому можно проверить выполнение. Если нельзя написать тест-кейс — требование нуждается в доработке.
• A — Achievable (достижимость). Требование реализуемо в рамках существующих технологий, бюджета и сроков. Требования-фантазии создают конфликты на приемке.
• R — Relevant (релевантность). Требование связано с бизнес-целью проекта. Если функция не трассируется ни к одному бизнес-требованию — это либо незадокументированная потребность, либо лишний scope.
• T — Time-bound (временны́е рамки). Там, где важен срок — он должен быть зафиксирован. «Уведомление должно отправляться не позднее 5 секунд после события» — пример временно́го критерия в требовании.

Признаки хорошего бизнес-требования: чек-лист

Международный стандарт IEEE и практика BABOK выделяют несколько основных характеристик качественного требования.

• Атомарность. Требование описывает одну и только одну ситуацию или функцию. Если в одном предложении два глагола — скорее всего, это два разных требования.
• Однозначность. Все читатели документа понимают формулировку одинаково. Слова «быстро», «достаточно», «корректно», «интуитивно» — сигнал тревоги: их нужно заменить на цифры или конкретные условия.
• Тестируемость. Из требования должен вытекать четкий критерий приемки: можно написать тест-кейс и однозначно ответить — выполнено или нет.
• Полнота. Все существенные условия указаны: что происходит в штатном сценарии, что — при ошибке, какие исключения возможны.
• Непротиворечивость. Требование не конфликтует с другими требованиями в том же документе.
• Трассируемость. Каждое требование имеет идентификатор и связано с бизнес-целью, источником и, в идеале, с тест-кейсом.
• Выполнимость. Требование реализуемо с учетом реальных ограничений: стека технологий, бюджета, сроков, регуляторных норм.

Типичные ошибки при написании бизнес-требований

Двусмысленные формулировки — ошибка №3 в топе проблем бизнес-аналитиков. Вот десять ошибок, которые чаще всего встречаются в реальных документах.

1. Требование-решение вместо требования-цели. Заказчик пишет: «Добавить кнопку “Позвонить нам” на главную страницу». Это решение, а не требование. Настоящее требование: «Обеспечить пользователю возможность связаться с поддержкой в один клик с любой страницы сайта». Решение — кнопка, чат, форма обратной связи или что-то еще — аналитик и команда выбирают после.
2. Двусмысленные формулировки.«Система должна быстро обрабатывать запросы» — что значит «быстро»? Для разработчика — 200 мс, для заказчика — 3 секунды, для пользователя — «до конца загрузки страницы». Всегда указывайте конкретные цифры.
3. Неполные условия. Требование описывает только «счастливый путь» и не учитывает ошибки, граничные случаи или исключения. Например: «Система рассчитывает сумму налога» — непонятно ни когда, ни для кого, ни по каким правилам.
4. Игнорирование нефункциональных требований. Команда сосредотачивается на функциях и забывает про производительность, безопасность и доступность. Потом обнаруживается, что сервис падает под нагрузкой 200 пользователей — хотя планировалось 20 000.
5. Конфликт требований разных стейкхолдеров. Отдел безопасности требует двухфакторную аутентификацию при каждом входе. UX-команда требует минимальное число шагов при авторизации. Оба требования попадают в документ без явного указания на противоречие — и разработчик делает так, как понял.
6. Требования без источника. Никто не знает, откуда взялось конкретное требование. Когда его пытаются изменить — непонятно, кого спрашивать и насколько оно обязательно.
7. Отсутствие критериев приемки. Требование есть, а проверить его выполнение нечем. На этапе тестирования или сдачи проекта неизбежно возникают споры.
8. Слишком детальные технические описания в BRD. Аналитик начинает описывать цвет кнопок, размер шрифта и поведение скроллбара. Это не бизнес-требования — это прообраз ТЗ или дизайн-спецификации. BRD должен отвечать на «зачем» и «что», но не «как именно».
9. Фокус на получении подписи, а не на понимании. Заказчик подписал документ — но не читал. Команда приступает к работе с разными ожиданиями. Подпись без реального согласования — юридическая страховка без практической ценности.
10. Требования не обновляются при изменениях. Продукт развивается, а документ остается в версии 1.0. Через три месяца команда работает по устаревшим требованиям — и никто об этом не знает.

Хорошее требование — это то, которое можно проверить без обращения к автору.

Структура документа бизнес‑требований (BRD): разделы, шаблон и инструменты

BRD — это структурированный артефактдокумент, который фиксирует зачем создается продукт, что он должен делать и при каких ограничениях. Именно BRD становится точкой отсчета для всей команды: от бизнес‑аналитика до QA‑инженера.

Из чего состоит BRD: стандартная структура

Ниже — классическая структура документа бизнес‑требований, которую используют большинство команд в российских продуктовых и аутсорс‑компаниях. Ее можно адаптировать под конкретный проект: стартап обойдется пятью разделами, крупный корпоративный заказчик потребует все двенадцать.

Как выглядит каждый раздел на практике

Раздел 1. Резюме. Пишется в последнюю очередь, читается в первую. Задача — убедить спонсора за две минуты. Типичная формула: «Текущая ситуация → Проблема → Предлагаемое решение → Ожидаемый эффект → Срок». Например: «Конверсия из корзины в оплату на мобильном приложении составляет 34 %, что на 18 п.п. ниже, чем в среднем по рынку. Цель проекта — поднять показатель до 48 % за 6 месяцев за счет редизайна checkout‑флоу и интеграции Системы быстрых платежей (СБП)».

Раздел 3. Бизнес‑цели. Формулируются строго по SMART. Плохой пример: «Улучшить пользовательский опыт». Хороший: «Снизить время оформления заказа с 4 минут до 90 секунд к 1 октября #CURRENT_YEAR# года». Каждой цели присваивается идентификатор (BG‑01, BG‑02 и т.д.) — это основа матрицы трассируемости.

Раздел 4. Границы проекта. Один из самых недооцененных разделов. Явное указание on scope / out of scope спасает от scope creep — неконтролируемого расширения объема работ в середине проекта. Пример: «В рамках проекта: редизайн страницы оплаты для iOS и Android. За рамками проекта: интеграция с новыми платежными системами, кроме СБП и ЮКassa».

Раздел 10. Матрица трассируемости (RTM). Связывает каждое бизнес‑требование с функциональным требованием и тест‑кейсом. Это страховка: если требование изменилось, RTM сразу показывает, какие тесты нужно пересмотреть.

Типы BRD в зависимости от проекта

Структура документа гибко адаптируется под тип задачи. В аутсорс‑разработке BRD становится частью договора и защищает обе стороны от разночтений. В продуктовой команде его часто заменяет облегченный PRD (Product Requirements Document) или набор эпиков в Яндекс Трекере. В стартапе на ранней стадии достаточно одностраничного Lean BRD.

• Полный BRD — для корпоративных и государственных проектов: все 12 разделов, формальные подписи стейкхолдеров, нумерация требований.
• PRD (Product Requirements Document) — продуктовые in‑house команды: акцент на пользовательских сценариях, метриках и дизайн‑решениях.
• Lean BRD — стартапы и MVP: 1–2 страницы, только цели, ключевые функции и ограничения.
• FRD (Functional Requirements Document) — отдельный документ для разработчиков, детализирует функциональный блок из BRD.

Инструменты для работы с BRD

Выбор инструмента зависит от размера команды, наличия санкционных ограничений и принятых в компании стандартов. Большинство российских команд столкнулись с необходимостью замены Confluence и Notion — оба сервиса ограничили работу с рядом организаций. Мы написали подробный гайд об альтернативах Miro, Jira, Confluence и другом софте, что ушел из РФ.

Для большинства российских продуктовых команд в #CURRENT_YEAR# году оптимальная связка выглядит так: Яндекс Wiki или Yonote для хранения BRD → Яндекс Трекер или Kaiten для привязки требований к задачам.

Минимально жизнеспособный шаблон BRD: что писать в каждом блоке

Если документ создается с нуля, начните с этой структуры и заполните только то, что известно сейчас. Пустые разделы — сигнал, что нужно провести дополнительные интервью со стейкхолдерами.

Примеры бизнес‑требований для разных типов проектов

Самый частый запрос на практике — «покажи, как это выглядит в реальности». Ниже — три сценария: мобильное приложение, интернет‑магазин и внутренний корпоративный сервис. Все примеры адаптированы под российские реалии.

Пример 1. Мобильное приложение для розничной сети (аналог программы лояльности)

Допустим, сеть косметических магазинов хочет перевести бонусную программу в мобильное приложение, заменить физическую карту и нарастить средний чек. Ниже показано, как описание бизнес‑требований выглядит на разных уровнях — от бизнес‑цели до конкретного функционального требования.

Бизнес‑цели (верхний уровень):

• BG‑01: Увеличить долю повторных покупок с 28 % до 38 % за 9 месяцев после запуска приложения.
• BG‑02: Снизить себестоимость обслуживания программы лояльности на 15 % за счет отказа от пластиковых карт к концу #CURRENT_YEAR# года.
• BG‑03: Поднять средний чек держателя карты лояльности с 2 100 ₽ до 2 600 ₽ в течение года.

Бизнес‑требования (BRD):

Пользовательская история (User Story) к BR‑01:

Как постоянный покупатель, я хочу показать QR‑код в приложении вместо пластиковой карты, чтобы получить скидку и не носить с собой карточку.

Критерий приемки (Acceptance Criteria):

• Кассовая система сканирует QR‑код за ≤ 3 секунды.
• Бонусы отображаются в приложении не позднее чем через 5 минут после оплаты.
• При отсутствии связи QR‑код доступен в офлайн‑режиме.

Пример 2. Интернет‑магазин: редизайн страницы оформления заказа

Задача — повысить конверсию checkout‑флоу, которая у интернет‑магазина бытовой техники упала с 41 % до 33 % после редизайна главной страницы. Именно такая ситуация часто встречается в e‑commerce‑командах на российском рынке.

Бизнес‑цель: Вернуть конверсию checkout‑страницы на уровень ≥ 40 % в течение двух месяцев с момента запуска обновленного флоу.

Ключевые бизнес‑требования:

• BR‑01: Пользователь завершает оформление заказа не более чем за 4 шага (выбор адреса → способ доставки → оплата → подтверждение).
• BR‑02: На странице оплаты отображаются все доступные способы: СБП, карта Visa/Mastercard/МИР, оплата частями через BNPL‑партнера.
• BR‑03: При вводе некорректных данных в поле «Адрес» система подсвечивает ошибку и предлагает корректный вариант через DaData API — без перезагрузки страницы.
• BR‑04: Страница оформления загружается на мобильном устройстве за ≤ 2 секунды при 4G‑соединении.
• BR‑05: Незарегистрированный пользователь может оформить заказ как гость без обязательной регистрации.

Что явно выходит за рамки (out of scope): редизайн каталога, изменение логики корзины, интеграция новых служб доставки, кроме уже подключенных (СДЭК, Почта России, Яндекс Доставка).

Пример 3. Внутренний корпоративный сервис: дашборд финансовой отчетности

Этот тип задач особенно актуален для холдингов с несколькими юридическими лицами, где данные из 1С, ERP и CRM нужно консолидировать в одном месте. Именно нехватка детализации по интеграциям чаще всего становится причиной пересогласования документа на середине проекта.

Бизнес‑цели:

• BG‑01: Сократить время подготовки ежеквартального финансового отчета с 5 рабочих дней до 4 часов.
• BG‑02: Обеспечить руководителям 5 дочерних компаний доступ к актуальным финансовым показателям в режиме реального времени без участия бухгалтерии.

Примеры бизнес‑требований:

• BR‑01: Система консолидирует данные из 1С (бухгалтерия), Битрикс24 (CRM) и Excel‑файлов через API или ручную загрузку и обновляет дашборд не реже одного раза в час.
• BR‑02: Каждый руководитель дочерней компании видит только показатели своего юридического лица — без доступа к данным других структур холдинга.
• BR‑03: Дашборд поддерживает выгрузку отчета в PDF и Excel одним кликом.
• BR‑04: При недоступности источника данных система отображает время последнего успешного обновления и не показывает устаревшие данные без предупреждения.

Пример ошибки, которую важно избежать: заказчик формулирует требование как «улучшить отчетность». Это не бизнес‑требование — это намерение. Правильно: зафиксировать конкретный показатель («время подготовки отчета → с 5 дней до 4 часов»), источник проблемы и критерий, по которому задача считается выполненной.

Сравнительная таблица: как одна бизнес‑цель «расписывается» по уровням

Чтобы окончательно закрепить связь между уровнями требований, посмотрим, как одна верхнеуровневая цель трансформируется в конкретные артефакты.

Готовый мини‑шаблон для быстрого описания одного требования

Если документ создается впервые или нет времени на полный BRD, используйте эту карточку для каждого требования. Она покрывает минимально необходимый контекст.

Бизнес‑требования в Agile: как работать без «толстого» BRD

Scrum и Kanban не ставят под сомнение ценность требований — они переопределяют их жизненный цикл: от статичного документа к динамично пополняемому бэклогу. В классическом Waterfall BRD подписывается до старта разработки и становится «законом». В Agile требования — живой артефакт, который уточняется в процессе или после каждого спринта. Это не значит, что документация исчезает — она просто меняет форму.

Waterfall vs. Agile: как меняется роль бизнес‑требований

В Waterfall‑проекте полный BRD подписывается всеми стейкхолдерами до начала разработки, изменения фиксируются через формальный change request, а отклонение от документа грозит штрафными санкциями. Такой подход оправдан в государственных контрактах, банковских проектах с жесткой регуляторикой (ФЗ‑152, ГОСТ 34), системах класса ERP с длинным циклом внедрения.

В Agile‑командах тот же объем информации распределяется иначе. Верхнеуровневые бизнес‑цели фиксируются один раз — в Product Vision или Lean BRD. Дальше они декомпозируются в эпики, фичи и User Stories, которые живут в product backlog и приоритизируются перед каждым спринтом.

Иерархия артефактов в Scrum: от бизнес‑цели до задачи

В Scrum‑команде бизнес‑требования не исчезают — они распределяются по уровням иерархии бэклога. Важно понимать эту цепочку, чтобы не потерять связь между стратегической целью и конкретной задачей разработчика.

Бизнес-цель (Business Goal)

  └── Эпик (Epic) — крупная функциональная область

        └── Фича (Feature) — набор связанных возможностей

              └── User Story — конкретная потребность пользователя

                    └── Задача (Task) — технический шаг реализации

Разберем на примере. Допустим, команда банка работает над увеличением доли инвесторов-новичков.

• Бизнес‑цель (BG‑01): Увеличить долю клиентов с брокерским счетом с 12 % до 20 % за 9 месяцев.
• Эпик: Онбординг нового инвестора — весь путь от «хочу попробовать» до первой сделки.
• Фича: Упрощенное открытие брокерского счета внутри мобильного приложения.
• User Story:«Как новый клиент, я хочу открыть брокерский счет за 5 минут, не выходя из приложения, чтобы не разбираться в бумажных документах».
• Acceptance Criteria: Форма содержит не более 7 полей; документы подписываются через СМС‑код; статус «Счет открыт» появляется в приложении в течение 2 минут после отправки заявки.
• Задача разработчика: Реализовать API‑интеграцию с сервисом верификации личности (СМЭВ).

Именно такая трассируемость — от BG до Task — позволяет команде в любой момент ответить на вопрос «а зачем мы это делаем?» без обращения к 50‑страничному BRD.

Как писать User Stories, которые выражают бизнес‑требование

User Story — это не техническое задание. Это формат фиксации потребности пользователя с точки зрения ценности для бизнеса. Классический шаблон:

Как [роль], я хочу [действие], чтобы [бизнес-ценность]

Хорошая User Story соответствует критериям INVEST:

• Independent — не зависит от других историй.
• Negotiable — детали обсуждаются до начала спринта.
• Valuable — приносит ценность пользователю или бизнесу.
• Estimable — команда может оценить трудозатраты.
• Small — выполняется за один спринт.
• Testable — из нее следуют четкие критерии приемки.

Плохой пример:«Как пользователь, я хочу хорошее приложение» — нет конкретики, нет измеримой ценности, нельзя проверить.

Хороший пример:«Как покупатель интернет‑магазина, я хочу оплатить заказ через СБП, чтобы не вводить данные карты вручную» — понятна роль, действие и ценность.

Критерии приемки (Acceptance Criteria): мост между требованием и тестом

Acceptance Criteria (AC) — это набор условий, при выполнении которых User Story считается реализованной. По сути, это бизнес‑требование, переведенное на язык, по которому QA‑инженер пишет тест‑кейс.

Есть два популярных формата записи AC:

Формат «Список условий» (Rule-oriented):

• Кнопка «Оплатить через СБП» отображается на странице оплаты для всех пользователей.
• При нажатии открывается QR‑код или диплинк в банковское приложение.
• Если оплата прошла успешно — пользователь видит экран подтверждения в течение 5 секунд.
• Если оплата не прошла — отображается сообщение об ошибке с кнопкой «Попробовать снова».

Формат Given / When / Then (сценарно‑ориентированный, BDD):

Given: Пользователь на странице оплаты

When: Нажимает кнопку «Оплатить через СБП»

Then: Открывается QR-код для сканирования банковским приложением

And: Статус заказа меняется на «Оплачен» после подтверждения транзакции

Второй формат удобнее для автоматизации тестирования и непосредственно связывает бизнес‑требование с автотестом.

Управление изменениями требований в Agile: как не допустить scope creep

Scope creep («расползание объема») — один из главных рисков в Agile‑проектах. Он возникает, когда новые требования появляются без оценки их влияния на сроки и бюджет. Признаки: команда постоянно переключается между задачами, спринты срываются, Product Owner добавляет задачи в середине итерации.

Практики, которые помогают держать требования под контролем:

• Definition of Ready (DoR) — четкие критерии того, что User Story готова к работе (есть AC, оценка, нет неразрешенных вопросов). Задача без DoR не попадает в спринт.
• Backlog Refinement — регулярная сессия (обычно раз в неделю, 1–2 часа), на которой команда уточняет и оценивает предстоящие истории. Именно здесь бизнес‑требования «дозревают» до уровня, пригодного для разработки.
• Change Control — даже в Agile изменения, влияющие на скоуп спринта, проходят через оценку: Product Owner обосновывает приоритет, команда оценивает трудозатраты, принимается решение — включать сейчас или в следующий спринт.
• Версионирование эпиков — если крупное требование изменилось, старая версия сохраняется в системе (Jira, Яндекс Трекер). Это позволяет отследить, кто, когда и почему изменил скоуп.

Когда Agile — не панацея: когда нужен полный BRD

Не каждый проект выигрывает от «легкой» документации. Если у проекта есть хотя бы один из следующих признаков, полный BRD обязателен даже при использовании Agile‑практик внутри спринтов:

• Проект ведется по государственному или корпоративному контракту с фиксированной ценой.
• Есть жесткие регуляторные требования: ФЗ‑152 (персональные данные), 161‑ФЗ (национальная платежная система), требования ЦБ РФ для финтех‑проектов.
• В проекте задействованы несколько подрядчиков, и BRD служит юридически значимым документом.
• Высокая стоимость переделки: медицинские системы, авиация, промышленная автоматизация.

В остальных случаях оптимальная стратегия — гибридный подход: одностраничный Lean BRD с бизнес‑целями и границами проекта плюс живой бэклог с эпиками и User Stories.

Роль бизнес‑аналитика: кто пишет бизнес‑требования и что для этого нужно

Бизнес‑требования не пишутся сами. За ними всегда стоит конкретный человек, который умеет одновременно слышать заказчика, понимать разработчиков и держать в голове бизнес‑цели проекта. В большинстве российских IT‑команд это бизнес‑аналитик (BA) — специалист на стыке бизнеса и технологий.

Что делает бизнес‑аналитик в контексте требований

В контексте бизнес‑требований BA решает несколько последовательных задач. Сначала он выявляет реальную потребность заказчика: задает уточняющие вопросы, проводит интервью, наблюдает за пользователями, изучает документацию и данные. Затем структурирует полученную информацию, отделяет симптом от причины («заказчик просит кнопку — а зачем ему кнопка?»). После этого формулирует требования в формате, понятном как бизнесу, так и разработчикам, согласует их со стейкхолдерами и сопровождает на протяжении всей разработки, отвечая на вопросы команды и фиксируя изменения.

В крупных продуктовых компаниях роли часто разделены: бизнес‑аналитик отвечает за «что и зачем», системный аналитик — за «как именно реализовать». В командах поменьше один специалист закрывает оба направления.

Три типа бизнес‑аналитиков

По характеру задач выделяют три специализации, и важно понимать, к какой из них вы обращаетесь или в какую хотите вырасти.

Аналитик бизнес‑процессов работает с операционной стороной: описывает текущие процессы (AS‑IS), находит узкие места, проектирует оптимизированный сценарий (TO‑BE). Типичный работодатель — крупный ритейл, логистика, производство.

Аналитик в продуктовой разработке встраивается в Agile‑команду и работает в тесной связке с Product Owner. Описывает пользовательские сценарии, пишет User Stories, участвует в Backlog Refinement, создает прототипы. Типичный работодатель — IT‑продуктовая компания.

Проектный бизнес‑аналитик — «переводчик» между заказчиком и разработчиком в аутсорс‑проекте. Собирает требования на старте проекта, создает полный BRD, сопровождает команду. Типичный работодатель — системный интегратор или веб‑студия.

Главные навыки БА: что нужно уметь

Компетенции бизнес‑аналитика делятся на профессиональные (hard skills) и коммуникационные (soft skills). Причем последние для этой роли — не бонус, а профессиональная необходимость.

Hard skills — профессиональные компетенции:

• Описание бизнес‑процессов: BPMN 2.0 (самый востребованный стандарт), UML (Use Case, Activity, Sequence диаграммы), IDEF0 — чаще в государственных проектах.
• SQL: на уровне SELECT, JOIN, оконных функций — для проверки данных и выявления несоответствий в бизнес‑логике.
• Работа с инструментами: Jira / Яндекс Трекер для управления требованиями, Confluence / Яндекс Wiki для документации, Figma / FigJam для прототипов и Use Case-схем, Camunda / ELMA для моделирования процессов, Miro / Mural для воркшопов.
• BI‑системы: Yandex DataLens, Power BI, Tableau — для визуализации метрик и проверки гипотез.
• Понимание API и интеграций: базовый REST, JSON, Swagger — чтобы корректно ставить задачи и проверять реализацию.

Soft skills — коммуникационные компетенции:

• Интервьюирование: умение задавать правильные вопросы, докапываться до реальной потребности, а не принимать первый ответ за истину.
• Критическое мышление: способность сомневаться в очевидном и находить неявные зависимости между требованиями.
• Системность: структурирование большого объема разрозненной информации в связную модель.
• Фасилитация: ведение воркшопов и рабочих встреч со стейкхолдерами с разными интересами и уровнями технической грамотности.
• Управление конфликтами: умение находить решение, когда требования двух стейкхолдеров противоречат друг другу.

Зарплата бизнес‑аналитика в России: актуальные данные 2025–2026

Медиана зарплаты бизнес‑аналитика в России составляет около 170 000 ₽ в месяц на руки. Разброс по грейдам значителен: от стажерских 50 000–90 000 ₽ до 500 000–800 000 ₽ у главного аналитика в крупной IT‑компании.

Карьерный путь и как начать

Войти в профессию с нуля реально за 6–12 месяцев. Стандартная траектория: самостоятельное изучение основ (BABOK, книга Карла Вигерса «Разработка требований к программному обеспечению») → онлайн‑курс с практическими проектами → стажировка или помощь действующему BA в команде.

Международные сертификации для тех, кто хочет подтвердить квалификацию:

• ECBA (Entry Certificate in Business Analysis, IIBA) — для начинающих, опыт не требуется.
• CCBA (Certification of Competency in Business Analysis, IIBA) — для специалистов с 2–3 годами опыта.
• CBAP (Certified Business Analysis Professional, IIBA) — топовая сертификация, требует 5+ лет опыта; добавляет 10–15 % к рыночной стоимости и открывает приоритет в найме в крупных компаниях.
• PMI‑PBA (PMI Professional in Business Analysis) — альтернатива от PMI, хорошо котируется в проектно‑ориентированных компаниях.

В российских реалиях международные сертификации не являются обязательным требованием большинства вакансий, но ускоряют рост до Senior и дают преимущество при переходе в крупные корпорации и финтех.

Разница между бизнес‑аналитиком и смежными ролями

Частая точка путаницы — чем BA отличается от системного аналитика, Product Owner и продакт‑менеджера. Коротко:

На практике в небольших командах один человек совмещает BA и SA («фулстек‑аналитик»), а в стартапах продакт‑менеджер нередко пишет требования сам. Но по мере роста компании роли разделяются — и понимание границ каждой из них становится критически важным.

FAQ: часто задаваемые вопросы о бизнес-требованиях

Кто должен писать бизнес-требования — бизнес или аналитик?

Правильный ответ: совместно. Бизнес (заказчик, спонсор, владелец продукта) формулирует проблему и желаемый результат на языке бизнеса. Бизнес-аналитик структурирует, верифицирует, дополняет деталями, проверяет измеримость и согласовывает с техническими ограничениями. На практике встречаются две крайности, обе опасны: когда бизнес пишет требования сам без аналитика — получается хаос без структуры; когда аналитик пишет в одиночку без участия бизнеса — получается технически аккуратный документ, не отражающий реальных потребностей.

Золотое правило: бизнес владеет требованиями, аналитик управляет процессом их выявления и документирования.

Можно ли обойтись без BRD в небольшом проекте?

Можно, но с условиями. Для проектов длительностью до 4 недель и командой до 5 человек полноценный BRD избыточен. В таких случаях достаточно одностраничного Lean BRD: цель проекта, измеримый результат, 3–7 ключевых требований в формате BR-карточек, список стейкхолдеров и критерии приемки. Отсутствие любой документации — даже минимальной — увеличивает риск недопонимания и переделок, согласно данным PMI, более чем вдвое.

Как часто нужно обновлять BRD?

В Waterfall BRD обновляется через формальный процесс Change Request (CR): изменение фиксируется, оценивается влияние на сроки, стоимость и риски, затем утверждается спонсором. В Agile BRD — живой документ: высокоуровневая часть пересматривается раз в квартал или при смене стратегических приоритетов, а детальные требования уточняются на каждом Backlog Refinement перед спринтом.

Нужна ли матрица трассировки (Traceability Matrix) в каждом проекте?

Матрица трассировки обязательна в трех случаях: регуляторные проекты (ФЗ-152, 44-ФЗ, медицина, банкинг), проекты с несколькими подрядчиками и проекты с высокой стоимостью ошибки. В остальных ситуациях достаточно связки «ID требования → User Story → тест-кейс» в Jira или Яндекс Трекере без отдельной таблицы. Главный принцип трассировки: каждое бизнес-требование должно быть реализовано и проверено — если требование существует, но не покрыто тестом, риск молча принять непроверенную функциональность очень высок.

Как приоритизировать требования, если все «срочно и важно»?

Самый распространенный метод — MoSCoW: Must Have (без этого продукт не работает), Should Have (важно, но можно отложить на следующую итерацию), Could Have (улучшает опыт, но не критично), Won't Have (явно вне скоупа текущего релиза). Альтернативы: RICE (Reach × Impact × Confidence ÷ Effort) для продуктовых команд и Kano Model для оценки влияния фич на удовлетворенность пользователей. Ключевое правило: если у вас более 30 % требований в статусе Must Have — приоритизация не работает, возвращайтесь к бизнес-целям.

Мнение эксперта

— Александр Апраксин, совладелец и генеральный директор digital-агентства MWI (входит в ТОП-10 Рейтинга Рунета). Автор книги «50 способов увеличения продаж интернет-магазина». Ведущий подкаста «Маркетологи», автор Telegram-канала Апраксин Pro Бизнес. Практик с 15+ годами опыта в digital и eCommerce. Сайт компании: mwi.me.

«Самая дорогостоящая ошибка, которую я наблюдаю снова и снова — команды начинают писать функциональные требования раньше, чем сформулированы бизнес-требования. Разработчики получают задачу "сделать личный кабинет", строят его идеально с технической точки зрения, а потом оказывается, что бизнес хотел не личный кабинет, а снижение нагрузки на колл-центр на 30 %. Это две разные задачи с разными решениями.

Второй момент, который меня всегда поражает: люди боятся писать "не знаю" в BRD. Незаполненное поле воспринимается как некомпетентность. На самом деле явно зафиксированная неопределенность — это зрелость. Лучше написать "источник данных не определен, требует уточнения до 15 мая" и поставить задачу, чем закрыть поле фиктивным ответом, который потом вылезет багом на проде.

И последнее: BRD — это живая гипотеза о том, что создаст ценность. Если реальность изменилась — меняйте документ без сожаления. Самый плохой BRD — тот, который лежит в папке и не отражает текущего понимания проекта».

Заключение

Бизнес-требования — это не бюрократический артефакт и не формальность перед стартом разработки. Это инструмент, который переводит размытое «хочу, чтобы стало лучше» в конкретное «что именно строим, зачем, для кого и как поймем, что получилось». Хорошо написанные требования экономят месяцы переделок, снижают стоимость ошибки и дают команде общий язык — от спонсора до тестировщика.

Мы разобрали все: от определения и типологии до реальных примеров, Agile-подхода, роли аналитика и инструментов. Теперь ваша очередь применить это на практике.

А чтобы закрепить материал — ответьте себе на один вопрос: возьмите любой текущий проект или задачу, над которой работаете прямо сейчас, и попробуйте сформулировать для нее одно бизнес-требование по схеме «Бизнес-цель → Измеримый результат → Критерий приемки». Если формулировка не получается за 10 минут — скорее всего, цель проекта еще не определена достаточно четко, и именно с этого стоит начать.

Термины и сноски

* Пользовательское требование (Stakeholder Requirement / User Requirement) — описание потребностей конкретного стейкхолдера или группы пользователей, которые должны быть удовлетворены для достижения бизнес-цели.

* Функциональное требование (Functional Requirement / FR) — описание конкретного поведения или функции системы. Пример: «Система должна отправлять SMS-подтверждение при регистрации».

* Нефункциональное требование (Non-Functional Requirement / NFR) — требование к качественным характеристикам системы: производительность, безопасность, надежность, масштабируемость, удобство использования.

* Стейкхолдер (Stakeholder) — любое лицо или группа, которая влияет на проект или испытывает его влияние: спонсор, конечный пользователь, регулятор, команда разработки.

* Эпик (Epic) — крупная функциональная область или бизнес-ценность, которая слишком велика для реализации в одном спринте и декомпозируется на User Stories.

* User Story — короткое описание требования с позиции пользователя по шаблону: «Как [роль], я хочу [действие], чтобы [ценность]».

Категория вопроса

Что мы можем предложить?