Шаблон документа бизнес-требований (BRD)
Этот бесплатный шаблон документа бизнес-требований даёт вам структурированный BRD из двух частей: обзор BRD для целей, объёма, заинтересованных сторон и утверждения и журнал требований , где у каждого требования есть ID, тип, обоснование, приоритет по MoSCoW, источник, критерии приёмки и статус. Скачайте его для Google Sheets, Excel или PDF в базовой, продвинутой или экспертной версии.
Главное
- Документ бизнес-требований (BRD) фиксирует, что нужно бизнесу от проекта и зачем, а также как вы узнаете, что каждая потребность удовлетворена. Он описывает потребность, а не решение.
- В шаблоне две вкладки: обзор BRD из десяти разделов и журнал требований с восемью столбцами и выпадающими списками для типа, приоритета и статуса.
- Хорошие требования не предписывают решения, проверяемы, записаны по одному в строке и связаны с бизнес-целью и источником.
- Приоритизируйте по MoSCoW и будьте строги: если всё — Must, то ничего не Must.
- Получите утверждение до начала проектирования или закупок, а затем управляйте изменениями через процесс запросов на изменения.
Бесплатно · без регистрации
Получить шаблон документа бизнес-требований
Выберите уровень и формат: Google Sheets, Excel или готовый к печати PDF. Таблицы содержат выпадающие списки, формулы и примеры строк, которые можно заменить своими.
Полный шаблон со всеми вкладками, выпадающими списками и формулами.
Что такое документ бизнес-требований?
A документ бизнес-требований (BRD) — это документ, излагающий, что нужно бизнесу от проекта или решения, зачем это нужно и как будет измеряться успех. Он охватывает цели, объём, заинтересованные стороны, ограничения и список приоритизированных требований с критериями приёмки. Он описывает, что нужно, а не как это будет создано.
BRD обычно пишут на раннем этапе проекта, после того как идея одобрена в бизнес-обоснование или устав проекта , и до начала проектирования, разработки или закупок. Он даёт тем, кто будет создавать или покупать решение, чёткую согласованную цель, а спонсору — основу для приёмки результата в конце.
BRD обычно пишут бизнес-аналитики, но в небольших проектах это часто делает руководитель проекта или владелец продукта. Кто бы его ни писал, содержание исходит от заинтересованных сторон: BRD — это запись их потребностей, проверенная и согласованная.
Более широкую картину высокоуровневых и детальных требований см. в нашем руководстве по требованиям проекта.
Предварительный просмотр шаблона BRD
Первая вкладка — обзор BRD. У каждого раздела есть краткая подсказка в столбце «Пояснения»; ваши ответы вносятся в столбец «Ваше содержание».
| Раздел | Подсказка | Ваше содержание |
|---|---|---|
| Название проекта и владелец | ||
| Резюме для руководства | Потребность и предлагаемый результат вкратце. | |
| Бизнес-цели | Измеримые цели, которые поддерживает проект. | |
| Предыстория / текущее состояние | Как всё работает сейчас и какие есть проблемы. | |
| Содержание | Что входит и не входит в объём. | |
| Заинтересованные стороны | Кого это затрагивает и кто утверждает. |
Строки-примеры приведены для иллюстрации: замените их своими.
Что входит в шаблон BRD
Шаблон — это электронная таблица с двумя взаимосвязанными вкладками. обзор BRD задаёт контекст в десяти коротких разделах; вкладка Требования перечисляет все требования в структурированном журнале с возможностью фильтрации.
- обзор BRD: раздел, подсказка, ваше содержание
- Требования: ID, Требование, Тип, Обоснование, Приоритет (MoSCoW), Источник, Критерии приёмки, Статус
Вкладка обзора BRD
Три столбца (Раздел, Подсказка, Ваше содержание) и десять разделов: название проекта и владелец, резюме, бизнес-цели, предыстория / текущее состояние, объём, заинтересованные стороны, допущения и ограничения, требования (со ссылкой на вкладку «Требования»), показатели успеха и утверждение.
Вкладка «Требования»
Восемь столбцов: ID, Требование, Тип, Обоснование, Приоритет (MoSCoW), Источник, Критерии приёмки и Статус. В продвинутой и экспертной версиях у трёх столбцов есть выпадающие списки:
- Тип: Функциональное, Нефункциональное, Ограничение, Данные, Отчётность.
- Приоритет (MoSCoW): Must, Should, Could, Won't.
- Статус: Черновик, На проверке, Утверждено, Отклонено, Отложено.
Четыре примера требований для проекта клиентского портала показывают, как заполнять каждый столбец; замените их своими.
Какую версию скачать?
| Версия | Что входит | Лучше всего для |
|---|---|---|
| Начальный уровень | Только вкладка обзора BRD: десять разделов с пояснениями плюс пустые строки | Небольшие проекты, требования которых умещаются в несколько абзацев |
| Продвинутый уровень | Обе вкладки: обзор BRD и полный журнал требований из восьми столбцов с выпадающими списками типа, приоритета (MoSCoW) и статуса | Большинство проектов с бизнес-аналитиком или несколькими группами заинтересованных сторон |
| Экспертный | Всё, что есть в продвинутой версии, плюс вкладка инструкций, дашборд, автоматически подсчитывающий требования по типу, приоритету MoSCoW и статусу, цветовая индикация статусов (утверждено, на проверке, отклонено) и вкладка истории изменений | Крупные проекты, закупки и PMO, отчитывающиеся о ходе работы с требованиями |
Что включить в документ бизнес-требований
Десять разделов обзора дают читателям контекст, необходимый до того, как они дойдут до самих требований. Вот что писать в каждом.
| Раздел | Что писать | Пример |
|---|---|---|
| Название проекта и владелец | Проект и бизнес-владелец, отвечающий за требования | Клиентский портал; руководитель службы клиентской поддержки |
| Резюме для руководства | Потребность и предлагаемый результат в нескольких предложениях. Пишите этот раздел последним | Клиенты не могут сами просматривать счета или сбрасывать пароли, поэтому звонят в поддержку. Портал самообслуживания сократит число звонков. |
| Бизнес-цели | Измеримые цели, которые поддерживает проект | Сократить число звонков по вопросам учётных записей на 30% в течение 6 месяцев после запуска |
| Предыстория / текущее состояние | Как всё работает сейчас и какие есть проблемы | Все изменения учётных записей проходят через службу поддержки по телефону или email |
| Содержание | Что входит и не входит в объём | Входит: просмотр учётной записи, счета, сброс пароля. Не входит: мобильное приложение, платежи |
| Заинтересованные стороны | Кого это затрагивает и кто утверждает | Служба клиентской поддержки, ИТ, финансы, юристы, клиенты |
| Допущения и ограничения | Что вы предполагаете и в каких рамках должны работать | API биллинга доступен к февралю; данные должны оставаться в ЕС |
| Требования | Ссылка на вкладку «Требования» | См. вкладку «Требования» (BR-01 – BR-04) |
| Показатели успеха | Как вы будете оценивать успех после реализации | Объём звонков, использование портала, удовлетворённость клиентов |
| Утверждение | Имена, роли и даты утверждающих | Спонсор, руководитель ИТ, ответственный за защиту данных |
Многие опубликованные форматы BRD также включают анализом затрат и выгод. Если у проекта уже есть бизнес-обоснование, дайте на него ссылку, а не повторяйте цифры; BRD должен оставаться сосредоточенным на потребностях. Наше руководство по анализом затрат и выгод объясняет метод, если он вам нужен.
Как формулировать хорошие бизнес-требования
Журнал требований — сердце BRD. Хорошее требование:
- Необходимо: оно поддерживает бизнес-цель. Если вы не можете сказать, какую, поставьте его под сомнение.
- Не предписывает решение: оно говорит, что нужно, а не как это создать. «Клиенты должны иметь возможность сбросить пароль, не обращаясь в поддержку» оставляет проектирование открытым.
- Понятно: допускает только одно разумное толкование. Избегайте слов вроде «удобный», «быстрый» или «гибкий» без меры.
- Проверяемо: кто-то может проверить, что оно выполнено. Для этого и нужен столбец критериев приёмки.
- Атомарно: одно требование в строке. Разделяйте всё, что соединено союзом «и».
- Прослеживаемо: у него есть ID, источник (человек, документ, нормативный акт или данные) и обоснование.
| Слабое требование | Лучшее требование | Почему оно лучше |
|---|---|---|
| Портал должен быть быстрым | Страницы должны загружаться менее чем за 2 секунды (95-й процентиль) | Измеримо и проверяемо |
| Использовать ссылку для сброса пароля, отправляемую по email через CRM | Клиенты должны иметь возможность сбросить пароль, не обращаясь в поддержку | Описывает потребность, а не решение |
| Клиенты могут видеть счета и обновлять свой адрес | Две строки: одна для просмотра счетов, другая для обновления адреса | Одно требование в строке, чтобы каждое можно было приоритизировать и протестировать |
| Соблюдать правила работы с данными | Данные клиентов должны храниться в ЕС | Конкретно, с понятным источником (юристы / политика GDPR) |
Типы требований
Выпадающий список «Тип» в шаблоне упрощает фильтрацию журнала: Функциональные (что должно делать решение), Нефункциональные (насколько хорошо оно должно это делать, например производительность, доступность, безопасность или удобство использования), Ограничение (ограничения, такие как регулирование, технологии или бюджет), Данные и Отчётность.
Если ваша организация следует BABOK Guide от IIBA, вы встретите более широкую классификацию: бизнес-требования (цели и результаты), требования заинтересованных сторон (потребности отдельных групп), требования к решению (функциональные и нефункциональные) и переходные требования (что нужно для перехода из текущего состояния в будущее, например миграция данных или обучение). Их можно добавить как дополнительные варианты в список «Тип».
Приоритизация по MoSCoW
MoSCoW делит требования на четыре группы, которые используются в столбце «Приоритет» шаблона:
| Приоритет | Значение | Тестирование |
|---|---|---|
| Must | Без этого решение не работает либо не соответствует закону или требованиям безопасности | Отменили бы вы запуск, если бы этого не было? |
| Should | Важно, но есть обходной путь | Неприятно исключать, но решение всё равно работает |
| Could | Желательно, если позволяют время и бюджет | Хорошо бы иметь; исключается первым при нехватке ресурсов |
| Won't (в этот раз) | Согласовано как не входящее в объём на данный момент | Фиксируется, чтобы решение было видно |
Типичная ошибка — помечать почти всё как Must. Задавайте вопрос «отменили бы вы запуск?» по каждому требованию. Фиксировать пункты Won't не менее полезно: это не даёт одному и тому же запросу возвращаться каждый месяц.
Формулирование критериев приёмки
Критерии приёмки описывают, как вы подтвердите выполнение требования. Делайте их конкретными и наблюдаемыми: «сброс выполняется менее чем за 2 минуты», «видны все счета с 2024 года», «регион хостинга подтверждён как ЕС». Они становятся основой для тестирования и для приёмки спонсором в конце проекта и естественно связаны с вашим подходом к управление качеством .
Как пошагово заполнить шаблон BRD
- Начните с устава или бизнес-обоснования. Скопируйте цели и объём, чтобы BRD соответствовал утверждённому.
- Определите заинтересованные стороны. Перечислите всех, кто использует, эксплуатирует, оплачивает или регулирует решение. Наше руководство по управление заинтересованными сторонами показывает, как их анализировать.
- Опишите текущее состояние. Зафиксируйте, как всё работает сейчас и что идёт не так. Помогают данные, например статистика звонков или результаты опросов.
- Соберите требования. Используйте интервью, воркшопы, наблюдение, анализ документов и данные. Записывайте источник каждого требования по ходу работы; протоколы совещаний с воркшопов служат полезной записью.
- Записывайте каждое требование в отдельную строку. Присвойте ему ID, чёткую формулировку, тип и обоснование, связанное с целью.
- Приоритизируйте и добавьте критерии приёмки. Согласуйте приоритеты MoSCoW с бизнес-владельцем и сформулируйте тест для каждого требования.
- Проведите обзор с заинтересованными сторонами. Пройдитесь по журналу, разрешите противоречия и обновите статусы с «Черновик» на «На проверке» и «Утверждено».
- Получите утверждение и зафиксируйте базовую версию. Попросите названных утверждающих подписать обзор. С этого момента изменения проходят через управление изменениями с помощью запрос на изменение.
Пример документа бизнес-требований
Строки-примеры в шаблоне описывают проект клиентского портала. Вот журнал требований в исходном виде с пояснением, почему каждая строка написана именно так.
| ID | Требование | Тип | Приоритет | Критерии приёмки | Статус |
|---|---|---|---|---|---|
| BR-01 | Клиенты должны иметь возможность сбросить пароль, не обращаясь в поддержку | Функциональные | Must | Сброс выполняется менее чем за 2 минуты | Утверждено |
| BR-02 | Портал должен показывать счета за последние 24 месяца | Функциональные | Must | Видны все счета с 2024 года | Утверждено |
| BR-03 | Страницы должны загружаться менее чем за 2 секунды | Нефункциональные | Should | 95-й процентиль менее 2 с | Черновик |
| BR-04 | Данные должны храниться в ЕС | Ограничение | Must | Регион хостинга подтверждён | Утверждено |
- BR-01 основано на данных поддержки и напрямую служит цели сокращения звонков, поэтому это Must.
- BR-02 основано на опросе клиентов и имеет чёткую границу (24 месяца), что исключает бесконечную миграцию данных.
- BR-03 — нефункциональное требование из UX-исследования. Оно всё ещё в статусе «Черновик», потому что целевое значение 2 секунды ещё не согласовано с ИТ.
- BR-04 — ограничение от юристов на основе политики GDPR. Это Must, потому что без него решение не может быть запущено.
Каждая строка прослеживается до цели (меньше звонков), источника и обоснования. Именно эта прослеживаемость позволяет через полгода ответить на вопрос «зачем мы это делаем?» и в первую очередь исключать нужные требования, если не хватает времени.
BRD, FRD, SRS, PRD и пользовательские истории
Документы с требованиями пересекаются, а их названия различаются в разных организациях. В таблице показаны обычные различия.
| Документ | Фокус | Типичный автор | Основные читатели |
|---|---|---|---|
| Документ бизнес-требований (BRD) | Что нужно бизнесу и зачем; цели, объём, высокоуровневые требования | Бизнес-аналитик | Спонсор, бизнес-заинтересованные стороны, команда реализации |
| Документ функциональных требований (FRD) / функциональная спецификация | Как будет вести себя решение, чтобы удовлетворить бизнес-требования | Бизнес-аналитик или системный аналитик | Дизайнеры, разработчики, тестировщики |
| Спецификация требований к ПО (SRS) | Детальные функциональные и нефункциональные требования к программной системе | Системный аналитик или архитектор | Разработчики, тестировщики, поставщики |
| Документ требований к продукту (PRD) | Что продукт или релиз должен делать для пользователей, часто по функциям | Менеджер продукта | Продуктовые, дизайнерские и инженерные команды |
| Пользовательские истории | Небольшие, ориентированные на пользователя части функциональности с критериями приёмки | Владелец продукта вместе с командой | Scrum- или Agile-команда |
| Техническое задание (SOW) | Что поставщик выполнит и на каких условиях | Покупатель, часто вместе с отделом закупок | Поставщики |
BRD часто служит основой для RFQ или техническое задание , когда решение будет покупаться, а не создаваться, и служит основой для описания объёма проекта в каждом проекте.
Использование BRD в Agile-проектах
Agile-команды редко пишут длинный BRD заранее, но стоящий за ним подход по-прежнему полезен. Короткий BRD, фиксирующий цели, границы объёма, ограничения и основные бизнес-требования, даёт Владелец продукта и команде общую цель.
Затем детали переходят в Бэклог продукта в виде пользовательских историй, каждая из которых прослеживается до ID бизнес-требования. Нефункциональные требования и ограничения часто становятся частью критериям готовности (Definition of Done)команды. Для этого обычно достаточно базовой версии шаблона — одной вкладки обзора; используйте её вместе с нашим шаблона пользовательской истории или шаблоне бэклога продукта.
Типичные ошибки в BRD
- Проектирование решения. Макеты экранов и выбор технологий относятся к проектированию, а не к BRD.
- Расплывчатые слова. «Просто», «быстро» и «безопасно» требуют меры, иначе их невозможно проверить.
- Всё — Must. Без реальных приоритетов команда не может идти на компромиссы при нехватке времени.
- Упущенные заинтересованные стороны. Требования юристов, финансов, безопасности или эксплуатации часто всплывают поздно и вызывают переделки.
- Нет источника или обоснования. Требования, которые никто не может объяснить, трудно защищать и легко «позолотить».
- Пропуск утверждения. Без утверждения BRD остаётся черновиком, а объём — открытым. См. расползание содержания.
- Восприятие документа как неизменного навсегда. Требования меняются. Фиксируйте утверждённый BRD как базовую версию и управляйте изменениями открыто, а не правьте его втихую.
Связанные шаблоны и руководства
BRD — звено в цепочке документов. Перед ним идут шаблон бизнес-обоснования и шаблон устава проекта; наряду с ним шаблон описания проблемы и Шаблон анализа разрывов формулируют потребность; после него шаблон содержания проекта, шаблона пользовательской истории и шаблон запроса на изменение переносят требования в реализацию. шаблон матрицы RACI помогает договориться, кто их пишет, проверяет и утверждает.
Шаблон описания содержания проектаБесплатный шаблон содержания проекта: цели, результаты, что входит и что не входит в содержание, приёмка…Начальный · Продвинутый · Экспертный
Шаблон пользовательской историиБесплатный шаблон пользовательской истории: «Как… я хочу… чтобы…», критерии приёмки, эпик, оценка…Начальный · Продвинутый · Экспертный
Шаблон анализа разрывовБесплатный шаблон анализа разрывов для сравнения текущего и целевого состояния, оценки каждого разрыва и…Начальный · Продвинутый · Экспертный
Шаблон формулировки проблемыБесплатный шаблон формулировки проблемы: кого затрагивает, что, где и когда, влияние, доказательства,…Начальный · Продвинутый · Экспертный
Шаблон анализа первопричин («5 почему»)Бесплатный шаблон анализа первопричин по методу «5 почему»: формулировка проблемы, цепочка «почему», первопричина…Начальный · Продвинутый · Экспертный- Требования к проекту: высокоуровневые и технические требования
- Управление заинтересованными сторонами: выявление, анализ, вовлечение
- Содержание проекта: определение, описание содержания и примеры
- Пользовательские истории: как писать, с примерами
Чтобы узнать, как сочетаются высокоуровневые и детальные требования, прочитайте наше руководстве по требованиям проекта.
Частые вопросы
Что такое шаблон документа бизнес-требований?
Шаблон документа бизнес-требований — это готовая структура для фиксации бизнес-целей проекта, объёма, заинтересованных сторон, ограничений и требований, у каждого из которых есть приоритет и критерии приёмки. Этот шаблон содержит вкладку обзора BRD и журнал требований.
Этот шаблон BRD бесплатный?
Да. Шаблон документа бизнес-требований можно бесплатно скачать в Google Sheets, Excel и PDF без регистрации.
Что должен включать документ бизнес-требований?
Резюме, бизнес-цели, предысторию и текущее состояние, объём, заинтересованные стороны, допущения и ограничения, сами требования с приоритетом и критериями приёмки, показатели успеха и утверждение.
Кто пишет документ бизнес-требований?
Обычно бизнес-аналитик вместе с заинтересованными сторонами, спонсором и руководителем проекта. В небольших проектах его часто пишет руководитель проекта или владелец продукта.
Кто утверждает BRD?
Его утверждает спонсор или бизнес-владелец, обычно вместе с руководителями основных групп заинтересованных сторон и профильными специалистами, например юристами или службой безопасности, чьи требования он содержит.
Чем BRD отличается от FRD?
BRD излагает, что нужно бизнесу и зачем. Документ функциональных требований (FRD) описывает, как будет вести себя решение, чтобы удовлетворить эти потребности, с детализацией, достаточной для дизайнеров, разработчиков и тестировщиков.
Какие бывают типы бизнес-требований?
В этом шаблоне используются функциональные, нефункциональные требования, ограничения, данные и отчётность. BABOK Guide от IIBA классифицирует требования как бизнес-требования, требования заинтересованных сторон, требования к решению (функциональные и нефункциональные) и переходные требования.
Какой длины должен быть BRD?
Настолько коротким, насколько возможно при сохранении ясности. Небольшому проекту может хватить нескольких страниц; крупной системе или закупке может понадобиться гораздо больше. Держите контекст в обзоре, а каждое требование — в отдельной строке журнала.
Когда писать BRD?
После того как проект одобрен в принципе через бизнес-обоснование или устав и до начала проектирования, разработки или закупок.
Как приоритизировать бизнес-требования?
Используйте MoSCoW: Must, Should, Could и Won't have this time. Согласуйте приоритеты с бизнес-владельцем и проверяйте каждое Must вопросом, отменили бы вы запуск без него.
Могут ли Agile-команды использовать документ бизнес-требований?
Да, на высоком уровне. Используйте короткий BRD для целей, объёма, ограничений и ключевых бизнес-требований, а детали фиксируйте как пользовательские истории в бэклоге продукта.
Что делать, если требования меняются после утверждения?
Оформите запрос на изменение, оцените влияние на объём, график и стоимость и получите одобрение, прежде чем обновлять BRD. Зафиксируйте изменение и решение по нему, чтобы базовая версия оставалась понятной.
Можно ли использовать шаблон BRD в Word?
Для скачивания доступны электронная таблица и PDF. Если ваша организация предпочитает Word, можно скопировать разделы обзора в документ Word, а журнал требований оставить в электронной таблице, где его проще фильтровать и сортировать.