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

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

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

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

Что нам дает такой подход?

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

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

О том, как мы работаем с брифом и функциональными требованиями к проекту, писали в прошлой статье. А в этой статье мы разберем список требований бизнеса к проекту.

BRD, Business Requirements Document — документ, в котором описаны требования бизнеса к проекту или продукту разработки.

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

BRD дает возможность определить:

В итоге:

Далее рассмотрим, как правильно определить ваши требования к проекту и как разработать BRD документ.

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

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

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

Вытекают из требований вашего бизнеса и пользователя и подробно описывают, как система должна работать, чтобы соответствовать этим требованиям. Они задокументированы в форме документов о требованиях к продукту — PRD, Product Requirement Document, который включает в себя функциональные и нефункциональные требования.

Функциональные требования — описывают, как продукт решает проблему пользователя с точки зрения функциональности, они документируются в Functional Requirements Document, FRD.

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

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

BRD описывает, чего организация надеется достичь с помощью партнерства с подрядчиком, а FRD описывает, как они ожидают этого достичь.

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

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

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

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

KISLOROD специализируется на проектах электронной коммерции для B2C и B2B-клиентов, поэтому далее рассмотрим примеры реализации BRD для различных типов интернет-площадок.

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

Например, выйти на новый рынок, стать монополистом в нише, перенести свой бизнес в онлайн.

Например, обеспечить доставку в Европу. Увеличить оборот в N раз или на N%. Ускорить обработку заказов за счет автоматизации рутинной работы менеджеров.

Например, удвоить трафик в первый год запуска проекта, увеличить коэффициент конверсии трафика до N%, утроить количество поставщиков, увеличить прямые онлайн-продажи на 30% за 6 месяцев.

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

Укажите сервисы, системы и платформы, которые должны быть интегрированы с площадкой.

Вкратце опишите общую схему взаимодействия интеграционного слоя и сайта.

Также вкратце можно указывать функциональные и нефункциональные требования.

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

Пример функциональных требований к интернет-магазину:

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

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

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

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

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

Этапы составления BDR-документа:

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

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

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

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

Если у вас есть вопросы о том, как написать BRD документ или вы хотите начать обсуждение вашего проекта — обращайтесь в KISLOROD.