Шаблон документа с бизнес-требованиями: 7 ключевых компонентов с примерами

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

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

Что такое документ с бизнес-требованиями (BRD)?

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

Документ бизнес-требований состоит из семи компонентов:

1. Краткое изложение

2. Цели проекта

3. Область проекта

4. Business-требования

5. Ключевые заинтересованные стороны

6. Ограничения проекта 

7. Анализ затрат и выгод

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

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

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

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

1. Основные факты и выводы

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

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

2. Цели проекта

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

Перечислите цели своего проекта в виде SMART-целей, чтобы убедиться, что они:

• Specific — конкретными

• Измеримыми

• Achievable — достижимая

• Актуальными

• Ограниченными по времени

Измерение целей проекта поможет определить, нужно ли вам скорректировать свою рабочую нагрузку, чтобы лучше соответствовать своим целям. Например, если одной из ваших целей было увеличение клиентской базы на 10% к концу квартала, вы можете посмотреть на свои показатели по окончании квартала и четко увидеть, достигли ли вы своей цели или нет. Затем можно проанализировать действия, предпринятые на этом пути, и определить причины, по которым вы, возможно, не достигли цели.

3. Область проекта

Область проекта определяет границы проекта в документе Business Requirements Document. Определив область проекта, вы обеспечите единое понимание и предотвратите расползание границ, которое происходит, когда проект выходит за установленные рамки и становится трудно контролируемым. 

В области проекта необходимо указать следующее:

• Хронология

• Бюджет

• конечный продукт;

• Требования к проекту

• Команда проекта

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

4. Бизнес-требования

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

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

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

5. Ключевые заинтересованные лица

К заинтересованным сторонам проекта относятся все лица, имеющие к нему отношение. Скорее всего, это люди, которые будут читать ваш шаблон BRD, чтобы понять, о чём проект. Ключевыми заинтересованными лицами могут быть:

• Участники команды, работающие над проектом

• менеджеры проекта, руководящие его реализацией;

• Руководители, утверждающие проект

• Клиенты, на которых повлияет завершённый проект

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

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

6. Ограничения проекта

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

К ограничениям проекта могут относиться:

• Риски проекта

• Доступность команды

• Ресурсы

• зависимости проекта;

• Дедлайны

• Бюджет проекта

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

7. Анализ затрат и выгод

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

Как создать анализ затрат и выгод:

• Опишите все расходы, связанные с проектом.

• Объясните связанные с этим преимущества

• Укажите общую ожидаемую стоимость проекта.

• Оцените ожидаемую рентабельность инвестиций, вычитая предполагаемые затраты из предполагаемого дохода

Шаблон документа с бизнес-требованиями (с примером)

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

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

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

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

При обсуждении бизнес-требований часто упоминаются функциональные требования, но важно понимать разницу между ними. В документе Business Requirements Document рассматриваются требования к проекту. Этот документ содержит общий обзор и предлагает заинтересованным сторонам всестороннее представление о проекте в целом. 

Документ с функциональными требованиями (FRD) содержит подробное описание того, как выполнять конкретные задания в рамках проекта. Представьте себе эти документы как настольную игру: BRD — это коробка, объясняющая правила игры и убеждающая вас её купить. А FRD — это инструкции, которые учат вас играть в эту игру. 

Помимо функциональных требований, существуют:

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

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

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

Делитесь требованиями с помощью инструментов управления проектами

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

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