Документ бизнес-требований (BRD) — это связующее звено между бизнес-заказчиками и техническими командами: он фиксирует то, что нужно бизнесу, и переводит это в требования, которые разработчики могут реализовать. С Trupeer вы можете сэкономить часы на написании BRD, начав с бесплатного шаблона документа бизнес-требований, настроив его с помощью ваших бренд-гайдлайнов и превращая длинные BRD в видеообходы, которые действительно может смотреть каждый.

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

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

Скачать шаблон документа бизнес-требований

Бесплатно, редактируемо, без водяного знака. Большинство команд используют Word для самого документа и Excel — для таблицы требований, когда количество требований превышает примерно тридцать.

Что такое документ бизнес-требований?

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

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

Как настроить этот шаблон в Trupeer

Шаг 1: Откройте раздел «Templates»

Перейдите в раздел «Templates» в главном меню.

Шаг 2: Выберите и откройте шаблон

Нажмите на любой шаблон, с которым хотите работать, чтобы открыть его.

Шаг 3: Разверните просмотр шаблона

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

Шаг 4: Отредактируйте шаблон

Нажмите «Edit», чтобы начать изменять выбранный шаблон.

В редакторе вы можете:

• Добавлять новые разделы

• Определять или обновлять правила форматирования

• Добавить логотип и настроить его положение и связанные параметры

Шаг 5: Сохраните настроенный шаблон

После того как вы внесете все необходимые изменения, нажмите «Save», чтобы сохранить обновленный шаблон как свой.

Шаг 6: Предпросмотр и точная настройка шаблона

Когда вы захотите увидеть, как выглядит ваш настроенный шаблон, откройте «Preview».

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

С шаблоном документа бизнес-требований вы можете:

• Экономить часы на написании: пропускайте пустую страницу со структурой, которую используют опытные BA и PM.

• Согласовывать бизнес и технологии: встроенные разделы связывают бизнес-цели с функциональными требованиями.

• Оставаться в фирменном стиле: применяйте логотип, шрифты и цвета с помощью бренд-набора Trupeer.

• Ясно коммуницировать: превращайте плотные BRD в видеообходы для обзоров заинтересованными сторонами.

• Стандартизировать по проектам: используйте один и тот же шаблон BRD для каждого инициативного проекта.

• Достигать глобальных команд: переводите BRD на 65+ языков одним кликом.

Почему вам нужен документ бизнес-требований

• Рамки становятся тем, на что можно ссылаться, а не тем, что нужно помнить. Большинство споров о рамке — это сбои в документации, а не недобросовестность.

• Требования получают приоритеты, поэтому когда времени не хватает, вы сокращаете осознанно, а не вычеркиваете все подряд.

• Допущения фиксируются на бумаге — именно тогда кто-то замечает, что одно из них неверное.

• Критерии приемки существуют до начала разработки, поэтому «готово» не решается тем, кто громче всех в конце.

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

• Поставщики могут оценивать стоимость по реальным данным. Расплывчатый BRD приводит к широкой оценке и проекту, перегруженному запросами на изменения.

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

• Контроль документа: версия, автор, дата, распространение и статус утверждения.

• Краткое резюме: что это за проект и почему — одним абзацем.

• Бизнес-цели, выраженные как измеримые результаты, а не как действия.

• Контекст и формулировка проблемы: что происходит сейчас и сколько это стоит.

• Рамки: что входит и что явно не входит.

• Заинтересованные стороны: кого это затрагивает, кто принимает решения, кто подписывает.

• Текущее состояние — таким, какое оно есть на самом деле.

• Бизнес-требования, пронумерованные, приоритизированные, каждое с критериями приемки.

• Допущения, ограничения и зависимости.

• Риски с ответственными.

• Сводка по затратам и выгодам, а также ожидаемая отдача.

• График и ключевые вехи.

• Критерии успеха для проекта в целом.

• Глоссарий, потому что половина споров по требованиям — это споры о терминах.

• Блок согласования.

• Приложения: схемы процессов, данные, экраны, поддерживающий анализ.

Структура шаблона

Для проекта среднего размера нормально иметь от десяти до двадцати страниц. После тридцати таблица требований обычно уже «впитала» дизайнерские решения, которые должны быть в функциональной спецификации.

Как сформулировать требование, которое выдержит проверку

Это и есть весь навык. Требование написано хорошо, когда два человека, которые не согласны, после прочтения понимают, что они не согласны.

Слабо: Система должна быть удобной для пользователя.
Лучше: Новый пользователь должен иметь возможность отправить заявку без обучения, измеряется тем, что 8 из 10 тестовых пользователей завершают отправку заявки с мобильного устройства без посторонней помощи менее чем за 3 минуты.

Слабо: Отчеты должны загружаться быстро.
Лучше: Ежемесячный отчет должен отображаться в течение 4 секунд для набора данных до 50 000 строк.

Слабо: Менеджерам нужна видимость утверждений.
Лучше: Менеджер должен иметь возможность видеть все заявки, ожидающие его одобрения, отсортированные по дате отправки, на одном экране без фильтрации.

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

Шаблон улучшений везде одинаков. Назовите, кому это нужно, что именно, и условие, при котором вы согласитесь, что это достигнуто. Слова, которым не стоит доверять в собственных черновиках: удобный для пользователя, надежный, бесшовный, интуитивный, быстрый, гибкий, масштабируемый, простой. Каждое из них скрывает решение, которое кто-то примет позже — без вашего участия.

Приоритизация требований с MoSCoW

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

Дисциплина, которая делает MoSCoW рабочим: не более чем около 60% требований должны быть Must have. Если все — Must, у вас получается список желаний с колонкой приоритета. А список Won't-have — самый ценный, потому что это письменная фиксация того, что сознательно отложили, а не забыли.

Таблица требований

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

Матрица трассируемости

Проверка того, что ничего не было тихо выкинуто, и что ничего не разрабатывается без причины.

Сразу проявляются две проблемы. Требование без тест-кейса не будет проверено, а пункт функциональной спецификации, который не связан ни с одним требованием, означает, что разрабатывается то, о чем никто не просил. Обе проблемы встречаются часто, и обе легко обнаружить таким способом.

Пример документа бизнес-требований

Сокращенный пример с пояснениями, чтобы вы могли увидеть уровень конкретики.

Проект: Замена системы заявок на расходы. Версия: 1.2. Автор: Бизнес-аналитик. Утверждающие: Финансовый директор, директор по ИТ, директор по персоналу.

Бизнес-цели. Сократить среднее время возмещения расходов с 24 рабочих дней до 10. Снизить время команды финансов, затрачиваемое на обработку заявок, на 50%: сейчас это 14 часов в неделю. Достичь 95% соответствия политике по поданным заявкам, сейчас — 71%.

Формулировка проблемы. Заявки подаются в таблице и отправляются по электронной почте. Маршрутизация утверждений выполняется вручную, чеки приходят отдельно, и 29% заявок нарушают политику, не будучи выявленными до оплаты. Финансы тратят примерно 14 часов в неделю на преследование, а среднее возмещение занимает 24 рабочих дня при обязательстве 10 дней, указанном в справочнике для сотрудников.

В рамках. Отправка заявки, фиксация чеков, проверка соответствия политике, маршрутизация утверждений, передача в бухгалтерскую систему, уведомление сотрудника.
Вне рамок. Сверка корпоративных карт, настройка ставок пробега, интеграция с зарплатой, перенос исторических заявок за пределами 12 месяцев.

Требования.

Допущения. Текущая оргструктура в системе HR точна и поддерживается в актуальном состоянии. Бухгалтерская система предоставляет поддерживаемый API. Лимиты политики не изменятся в ходе внедрения.

Ограничения. Бюджет £85 000. Запуск до начала нового финансового года. Без дополнительного штата в финансах.

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

Критерии успеха. Среднее возмещение — не более 10 рабочих дней в течение одного квартала после запуска. Время обработки в финансах — не более 7 часов в неделю. Соответствие политике — 95% или выше.

Документ бизнес-требований vs функциональные требования vs технические требования

Самый частый источник путаницы в этой теме — и причина, почему многие BRD на самом деле являются спецификациями, но с неправильным названием.

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

Кто готовит документ бизнес-требований и кто его подписывает

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

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

Самая важная подпись — от человека, к которому в четвертом месяце обратятся с вопросом, было ли это согласовано.

Как написать документ бизнес-требований

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

2. Определите заинтересованные стороны и полномочия на принятие решений до того, как собирать что-либо. Понимание того, кто может сказать «да», предотвращает большинство поздних разворотов.

3. Честно задокументируйте текущее состояние, включая обходные решения. Именно здесь прячутся реальные требования.

4. Собирайте требования через интервью и наблюдение, а не только через воркшоп. Воркшопы выявляют то, что люди говорят, что им нужно. Наблюдение — то, что они делают.

5. Пишите каждое требование с прикрепленными критериями приемки — в тот же момент. Добавление критериев позже означает, что вы пишете их по памяти.

6. Приоритизируйте с MoSCoW и держите линию на долю Must-have.

7. Явно фиксируйте допущения, ограничения и зависимости. Незаписанные допущения превращаются в споры.

8. Стройте матрицу трассируемости по мере продвижения, а не в конце.

9. Рассылайте на обзор с дедлайном и назначенным рецензентом для каждого раздела. «Любые комментарии?» в рассылку приводит к тишине.

10. Пройдите с заинтересованными сторонами по документу на сессии перед тем, как просить подписи, затем зафиксируйте базовую версию и формально управляйте изменениями с этого момента.

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

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

Лучшие практики

• Пишите требования, с которыми кто-то мог бы не согласиться. Расплывчатость воспринимается как согласие и приводит к спорам позже.

• По одному требованию в строке. Все, что содержит «и», — вероятно, это два требования.

• Сразу прикрепляйте критерии приемки, никогда не позже.

• Пронумеруйте все и никогда не перенумеровывайте. Вместо этого выводите ID из использования.

• Фиксируйте источник каждого требования.

• Не включайте в документ решения. Как только вы называете экран или поле, вы начинаете проектировать.

• Определяйте каждый неоднозначный термин в глоссарии. Слова вроде «заявка», «пользователь» и «утверждено» означают разные вещи для разных отделов.

• Зафиксируйте базовую версию на этапе согласования и формально управляйте изменениями после этого.

• Держите список вне рамок видимым. Он предотвращает расширение рамок лучше, чем любой другой раздел.

Частые ошибки

• Требования, которые нельзя проверить. «Интуитивный» и «надежный» нельзя протестировать, поэтому их трактуют во время разработки те, кто находится ближе всего.

• Нет приоритетов, поэтому все обязательно до дедлайна, который заставляет делать произвольные сокращения.

• Решения, замаскированные под требования. Они ограничивают дизайн до того, как кто-либо оценил варианты.

• Нет критериев приемки, поэтому «готово» превращается в предмет переговоров.

• Отсутствует раздел вне рамок. Это самое дешевое средство предотвращения расширения рамок.

• Написано для заинтересованных сторон, а не вместе с ними. Подписывают, не читая.

• Допущения оставлены незаписанными. Они есть у каждого проекта, и именно незадокументированные ломают его.

• Никогда не обновляется после согласования. Требования меняются, и не поддерживаемая базовая версия перестает быть эталоном, которому доверяют.

• Нет трассируемости, поэтому тихие «выпадения» обнаруживаются на приемочном тестировании пользователями.

Зафиксируйте текущее состояние, записав его

Откройте шаблон в Trupeer AI, примените ваш бренд-набор, чтобы BRD соответствовал другим документам вашего проекта, и отредактируйте любой раздел напрямую. Настройка описана в руководстве по шаблону.

Раздел «текущее состояние» — самое слабое место BRD, потому что описание того, как что-то работает сегодня, занимает больше времени, чем кто-либо закладывает в бюджет, и почти всегда пропускает обходные решения. Зафиксируйте существующий процесс один раз — и Trupeer AI создаст письменную документацию текущего состояния со скриншотами, которые будут захвачены автоматически, а также с озвученным видеообходом, который вы сможете прикрепить как приложение. Поставщики, которые оценивают стоимость по вашему BRD, понимают двухминутную запись быстрее, чем четыре страницы текста.

Зафиксируйте это. Документируйте это. Переведите это на 65+ языков для команд, работающих удаленно. Сохраните в вашем хранилище знаний. Trupeer it.

Часто задаваемые вопросы

Есть ли бесплатный шаблон документа бизнес-требований в Word?

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

Могу ли я бесплатно скачать шаблон документа бизнес-требований в Word?

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

Есть ли шаблон документа бизнес-требований в формате Word doc?

Да: версия .doc включена для более старых систем документов и библиотек, которые не корректно обрабатывают .docx.

Есть ли бесплатный шаблон документа бизнес-требований в PDF?

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

Есть ли пример документа бизнес-требований в PDF?

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

Где я могу скачать шаблон документа требований в Word?

На этой странице — в Word, .doc, Google Docs, Excel и PDF. Все бесплатно. Если вам нужна функциональная спецификация вместо бизнес-требований, это отдельный документ, а различие объясняется выше.

Что такое BRD?

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

Что должен включать документ бизнес-требований?

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

В чем разница между бизнес-требованиями и функциональными требованиями?

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

Какой должна быть длина документа бизнес-требований?

От десяти до двадцати страниц для проекта среднего размера. Небольшие проекты можно сделать за пять. После тридцати раздел требований обычно уже «впитал» функциональный дизайн, который должен быть в другом месте.

Кто пишет документ бизнес-требований?

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

Кто утверждает BRD?

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

Сколько требований должно быть в BRD?

Столько, сколько рамки действительно требуют, но если вы уже за пределами примерно восьмидесяти, проверьте, не просочилась ли функциональная детализация. Полезный индикатор — доля Must-have: выше примерно 60% приоритизация выполнена неправильно.

Что такое матрица трассируемости?

Таблица, которая связывает каждое требование с бизнес-целью, которую оно обслуживает, с функциональной спецификацией, которая его закрывает, и с тест-кейсом, который это подтверждает. Она выявляет требования, которые никогда не будут тестироваться, и работу, которая создается без привязки к требованиям.

Могу ли я настроить этот шаблон документа бизнес-требований?

Да, каждая версия полностью редактируемая. Удаляйте разделы, которые не применимы, вместо того чтобы оставлять пустые заголовки, и адаптируйте таблицу требований под вашу собственную схему приоритетов, если вы не используете MoSCoW. В Trupeer AI вы также можете применить ваш бренд-набор, чтобы BRD соответствовал другим документам вашего проекта.

Связанные шаблоны

• Шаблон плана проекта

• Шаблон плана управления проектом

• Шаблон документации проекта

• Шаблон технической документации

• Шаблон документации по ПО

• Шаблоны тестовой документации

• Шаблон бизнес-процесса

• Шаблон плана управления изменениями

• Шаблон бизнес-плана