Полное руководство по продвижению интернет-магазина и привлечению покупателей
Получить руководство

Сбор и формирование бизнес-требований для сайта интернет-магазина

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

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

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

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

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

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

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

Рассмотрим, что могут включать бизнес-потребности:

  1. Предоставление возможности создания и управления онлайн-магазином: сайт должен предоставлять функционал для добавления и управления товарами, категориями товаров, ценами и акциями.
  2. Поддержка процесса покупки: сайт должен предоставлять возможность пользователям оформить заказ, выбрать способ доставки и оплаты, а также предоставлять информацию о статусе заказа.
  3. Интеграция с платежными системами: сайт должен поддерживать интеграцию с различными платежными системами, чтобы пользователи могли безопасно и удобно оплачивать свои покупки.
  4. Управление клиентскими данными: сайт должен предоставлять возможность управления клиентскими данными, такими как личная информация, история заказов и контактная информация.
  5. Аналитика и отчетность: сайт должен предоставлять возможность сбора и анализа данных о посетителях и покупках, а также генерировать отчеты для принятия решений и оптимизации бизнес-процессов.
  6. Маркетинговые возможности: сайт должен предоставлять инструменты для проведения маркетинговых акций, таких как скидки, промо-коды и программы лояльности.
  7. Мобильная адаптация: сайт должен быть адаптирован для просмотра и покупок с мобильных устройств, так как все больше пользователей предпочитают использовать смартфоны и планшеты для онлайн-покупок.

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

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

Вот несколько причин, почему бизнес-требования являются важными:

  1. Ясное определение целей: Бизнес требования помогают четко определить, что ожидается от проекта, и что должно быть достигнуто. Они помогают установить приоритеты и избежать недоразумений между командой разработки и бизнесом.
  2. Улучшение коммуникации: Бизнес требования служат основой для коммуникации между бизнесом и командой разработки. Они помогают установить общий язык и понимание между сторонами, что в свою очередь способствует более эффективному взаимодействию.
  3. Управление ожиданиями: Бизнес требования позволяют управлять ожиданиями стейкхолдеров и заинтересованных сторон. Они помогают определить, что будет включено в проект, а что — нет, что может быть достигнуто, а что — нет.
  4. Оценка проекта: Бизнес требования помогают определить объем работы, ресурсы и время, необходимые для выполнения проекта. Они помогают оценить, насколько реалистичны цели бизнеса и требования проекта.
  5. Оценка успеха: Бизнес требования служат основой для оценки успеха проекта. Они помогают определить, в какой степени проект соответствует бизнес-целям и требованиям.

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

Существует несколько видов БТ, включая:

  1. Функциональные требования: описывают функции и возможности, которые должна иметь система или продукт. Например, требование наличия определенной функции в программном обеспечении или возможности оплаты различными способами в интернет-магазине.
  2. Нефункциональные требования: определяют качественные характеристики системы или продукта, такие как производительность, безопасность, надежность, удобство использования и т. д. Например, требование наличия защиты данных в системе или требование кратких временных откликов веб-сайта.
  3. Бизнес-правила: определяют правила и процессы, которые должны быть реализованы в системе или продукте. Например, требование автоматического расчета налогов при оформлении заказа в онлайн-магазине или требование проверки наличия товара перед его добавлением в корзину.
  4. Требования к данным: определяют структуру, формат и характеристики данных, которые должны быть использованы в системе или продукте. Например, требование хранения данных о клиентах в базе данных или требование использования определенного формата файла для импорта данных.
  5. Требования к интерфейсу: определяют внешний вид и поведение пользовательского интерфейса системы или продукта. Например, требование использования определенного цветового оформления или требование наличия кнопки «назад» на каждой странице веб-сайта.
  6. Требования пользователей: определяют потребности и ожидания конечных пользователей системы или продукта. Например, требования по удобству использования, доступности или персонализации.
  7. Технические требования: определяют технические характеристики и ограничения, которые должны быть учтены при разработке системы или продукта. Например, требования по совместимости, масштабируемости или интеграции с другими системами.
  8. Процессуальные требования: определяют процессы и процедуры, которые должны быть реализованы в системе или продукте. Например, требования по автоматизации бизнес-процессов или управлению рабочими потоками.

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

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

Документ бизнес-требований (Business Requirements Document, BRD) – это формальный документ, который описывает цели, ожидания и требования к проекту или системе, разрабатываемым для удовлетворения бизнес-потребностей организации. BRD является основным инструментом коммуникации между бизнес-аналитиками, заказчиками и разработчиками.

В документе бизнес-требований, как правило, содержатся следующие элементы:

  1. Введение: описание целей и задач проекта, а также описание текущей ситуации и проблем, которые требуется решить.
  2. Обзор бизнес-потребностей: описание основных потребностей и требований бизнеса, которые должны быть учтены в проекте.
  3. Функциональные требования: описание функций и возможностей, которые должны быть реализованы в проекте.
  4. Нефункциональные требования: описание требований к производительности, надежности, безопасности, доступности и другим нефункциональным характеристикам системы.
  5. Процессы и бизнес-правила: описание бизнес-процессов, правил и процедур, которые должны быть автоматизированы или улучшены в рамках проекта.
  6. Интерфейсы и интеграции: описание требований к взаимодействию системы с другими системами или компонентами.
  7. Требования к данным: описание процесса сбора, хранения, обработки и отображения данных.
  8. Ограничения и зависимости: описание ограничений, связанных с проектом, таких как бюджетные, временные или технические ограничения.
  9. Тестирование и проверка: инструкции по проверке системы на соответствие бизнес-требованиям.
  10. План реализации: описание плана поэтапной реализации проекта, включая сроки, ресурсы и ответственных лиц.

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

  1. Данные компании. Область бизнеса, продукт, портрет покупателя, конкурентные преимущества.
  2. Целевая аудитория. Местоположение, пол, возраст, хобби потенциальных посетителей магазина. Важно осознавать, зачем люди посещают магазин. К примеру, приобрести продукт, узнать стоимость услуги или ознакомиться с новостями.
  3. Анализ конкурентов
  4. Цель запуска проекта. Выйти на новый рынок. Стать монополистом в нише. Перевести бизнес в онлайн.
  5. Конкретизированная цель. Например, система должна обеспечить доставку в Израиль. Увеличить товарооборот (в цифрах). Ускорить обработку заказов через автоматизацию работы менеджеров.
  6. Планируемые метрики. Увеличить трафик вдвое за первый год запуска проекта. Увеличить коэффициент конверсии трафика с 0,8% до 1,1%. Втрое увеличить количество вендоров. Поднять прямые онлайн-продажи без похода в магазин на 30% за полгода.
  7. Пользовательские требования, то есть какую задачу должен решить пользователь на сайте. Купить шампунь, если речь идет о покупателе на сайте. Организовать доставку в другую страну, если пользователь — другая компания. Увеличить заработок для вендора. Иметь доступ только к заказам для менеджера по продажам и так далее.

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

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

Для большей наглядности, приведем такой пример бизнес-требований:

Название проекта: Разработка онлайн-платформы для доставки еды

Цель проекта: Создание удобной и эффективной онлайн-платформы, которая позволит пользователям заказывать еду из различных ресторанов и кафе с доставкой на дом или в офис.

Описание проекта:

  1. Платформа должна быть доступна как на веб-сайте, так и в виде мобильного приложения для iOS и Android.
  2. Пользователи должны иметь возможность просматривать меню различных ресторанов и кафе, выбирать блюда и оформлять заказы.
  3. Платформа должна предоставлять информацию о времени доставки, стоимости доставки и возможных скидках и акциях.
  4. Пользователи должны иметь возможность оплачивать заказы онлайн с помощью различных платежных систем.
  5. Платформа должна иметь функцию отслеживания заказа, чтобы пользователи могли видеть, где находится их заказ и когда он будет доставлен.
  6. Рестораны и кафе должны иметь возможность зарегистрироваться на платформе и добавлять свое меню, управлять заказами и обрабатывать платежи.
  7. Платформа должна иметь систему обратной связи, чтобы пользователи могли оставлять отзывы о ресторанах и кафе, а также оценивать качество доставки.

Требования к разработке:

  1. Платформа должна быть разработана с использованием современных технологий и фреймворков.
  2. Платформа должна быть масштабируемой и способной обрабатывать большое количество одновременных заказов.
  3. Платформа должна быть интуитивно понятной и легкой в использовании для пользователей всех возрастов.
  4. Платформа должна быть безопасной и защищенной от несанкционированного доступа к данным пользователей и ресторанов.
  5. Платформа должна быть адаптивной и корректно отображаться на различных устройствах и разрешениях экранов.

Ожидаемые результаты:

  1. Разработка и запуск полнофункциональной онлайн-платформы для доставки еды.
  2. Увеличение количества заказов и клиентов для ресторанов и кафе, зарегистрированных на платформе.
  3. Удовлетворение потребностей и ожиданий пользователей в удобном и быстром заказе еды с доставкой.

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

Часто бизнес-требования влияют на способ реализации продукта. Рассмотрим несколько примеров.

  • Требование А. Чтобы привлечь вендоров, владелец маркетплейса может предложить продавцам продолжать работать в собственных системах,  интегрировав эти системы в маркетплейс. Вендорам не придется изучать интерфейс новой для себя системы, а владелец будет иметь все необходимые данные на своей платформе. Таким образом, способом реализации продукта станет интеграция с сервисами вендора по API. 
  • Требование Б. По условию франшизы за определённой территорией может быть закреплен только один продавец / территориальный представитель, который будет работать с заказами покупателей из данного региона. Продажа товаров на данной территории другими представителями бренда запрещена по условиям договора. Способ реализации: определение геолокации покупателя, сортировка товаров и отображение актуальных остатков для конкретной локации, привязка покупателя к продавцу для дальнейших заказов.
  • Требование В. Владелец сайта-каталога (где можно просматривать товары, но нельзя покупать их) хочет создать интернет-магазин без перехода на новую платформу. В связи с этим, требуется внедрить функционал оформления заказа из платформы CS-Cart таким образом, чтобы для покупателя это выглядело «бесшовно», как будто он и не покидал существующий сайт. Способ реализации: интеграция технологии единого входа — SSO — при которой пользователь переходит из одной системы в другую без повторной аутентификации. 

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

Составление документа бизнес-требований включает в себя несколько этапов:

  1. Определение цели и предметной области документа: определите, что именно вы хотите достичь с помощью этого документа и какие аспекты бизнеса он будет охватывать.
  2. Идентификация заинтересованных сторон: определите круг заинтересованных лиц и какие типы требований они могут иметь.
  3. Сбор информации: проведите исследование и соберите всю необходимую информацию о бизнес-процессах, системах, требованиях клиентов и других факторах, которые могут повлиять на содержание документа.
  4. Определение требований: на основе собранной информации определите требования, которые должны быть учтены в документе. Разделите требования на функциональные (что система должна делать) и нефункциональные (как система должна работать).
  5. Описание требований: описывайте требования в ясной и понятной форме, используя структурированный формат. Включайте в документ информацию о функциональности, производительности, безопасности, надежности и других аспектах системы.
  6. Проверка и утверждение: проконсультируйтесь с заинтересованными сторонами, чтобы убедиться, что документ отражает их требования и ожидания. После этого документ должен быть утвержден и подписан соответствующими лицами.
  7. Обновление и поддержание: регулярно обновляйте документ, чтобы отражать изменения в бизнес-процессах и требованиях. Поддерживайте его актуальность и доступность для всех заинтересованных сторон.

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

Кто выявляет бизнес-требования?

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

  • Менеджер проекта
  • Вендоры и отдел привлечения вендоров (для маркетплейсов)
  • Бухгалтерия (чтобы понимать, какие отчеты нужны, как проводить платежи)
  • Юридический отдел (если есть юридические ограничения, которые нужно учесть при создании онлайн-магазина).
  • Маркетинг (для реализации механики промо акций)
  • IT-отдел 
  • Специалисты по безопасности
  • Сторонние эксперты

Как выявлять бизнес-требования

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

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

  1. Интервьюирование заинтересованных сторон: Беседа с заинтересованными сторонами, такими как клиенты, пользователи или владельцы бизнеса помогает понять их потребности и требования.
  2. Анализ документации: Изучение существующих документов, таких как бизнес-планы, отчеты, спецификации и другие материалы, может помочь выявить требования.
  3. Наблюдение за рабочим процессом: Изучение текущих рабочих процессов и наблюдение за работой пользователей может помочь идентифицировать потребности и проблемы.
  4. Фокус-группы и опросы: Проведение фокус-групп или опросов с пользователями или клиентами помогает получить обратную связь и понять их требования.
  5. Прототипирование: Создание прототипов или макетов решения позволяет пользователям визуализировать и предложить изменения или улучшения.
  6. Взаимодействие с заинтересованными сторонами: Регулярное общение и обратная связь с заинтересованными сторонами помогает уточнить требования и адаптировать решение.

Почему нужно конкретно и четко оформить бизнес-требования?

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

  1. Позволяет управлять ожиданиями. Исполнитель узнает об ожиданиях клиента и может предложить лучшее решение  
  2. Помогает точнее выполнить оценку объема работ 
  3. Экономит время исполнителя и заказчика на процесс сбора требований

Например, заказчик пришел с запросом “создать eCommerce платформу “все включено”. Клиент планировал подключение к платформе банковских систем, юридических и образовательных организаций в качестве вендоров и выделил шесть направлений работ с клиентами. Однако, в процессе выявления требований к платформе, выяснилось, что заказчик недостаточно четко сам для себя определил конечный продукт. Поэтому в брифе для клиента мы уточнили, каким он представляет продукт и CJM (путь клиента).

Дарья
Sales Manager

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

  1. Опишите ваш продукт / услугу. Что будет являться товаром? Какие его характеристики? Как будет считаться его стоимость?
  2. Роли пользователей (администратор, продавец покупатель) и какие действия может выполнять каждый из них? Есть ли какие-либо зависимости / ограничения?
  3. CJM (путь покупателя по сайту): какими будут действия покупателя по приобретению вашего продукта? Какие соответствующие действия должен будет выполнять продавец / администратор?
  4. Регистрация пользователей: какие данные должны предоставить пользователи для регистрации?
  5. Как будет выглядеть личный кабинет (профиль) покупателя для пользования услугой? Какие действия он сможет выполнять?
  6. Понадобится ли интеграция со сторонними системами? Какими?

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

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

  1. Use Case-диаграммы: Это графическое представление, которое описывает взаимодействие между пользователями и системой. Они помогают идентифицировать основные функции системы и ее возможные сценарии использования.
  2. Бизнес-требования в формате текста: Это документ, который описывает требования к системе в текстовой форме. Он может включать в себя функциональные требования (что система должна делать) и нефункциональные требования (как система должна работать).
  3. Прототипы и технические спецификации: В некоторых случаях, особенно при разработке сложных систем, может быть полезно создать прототип или техническую спецификацию, которая подробно описывает требования и функциональность системы.
  4. User Stories: Это короткие и простые описания функциональности, написанные с точки зрения конечного пользователя. User Stories помогают команде разработчиков лучше понять потребности пользователей и создать функциональность, которая соответствует их ожиданиям.

Какие материалы нужно запрашивать у заказчика?

Дополнительные материалы помогают исполнителю лучше понимать процесс принятия решений в компании и организовать работу наиболее эффективным образом.

К таким материалам можно отнести:

  1. Примеры конкурентов и реализации желаемого функционала
  2. Блок-схема с описанием бизнес-процессов, функциональности
  3. CJM-карта
  4. Архитектурная диаграмма 
  5. Документ с описанием проекта (общее описание того, что будет представлено на панелях администратора, вендора и пользователя)
  6. Дизайн-макеты
  7. План развития проекта, например, нагрузка на сайт, способы монетизации проекта, планы по ROI и т.п.
  8. Список ролей участников проекта и схема принятия решения 
  9. User-cases (описание сценариев работы при определенной ситуации, например, что происходит при регистрации пользователя).

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

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

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

  • Пример 1. Форма для регистрации интуитивно понятна.

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

  • Пример 2. Магазин не должен тормозить.

Как нужно: Скорость загрузки страницы составляет 2 секунды. Магазин остается производительным при нагрузке в 150 тысяч посетителей в день.

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

  • Выбор изначально неподходящего стороннего сервиса. Так происходит, когда заказчик не оговаривает цель, а просит подключить сервис на свой выбор. После интеграции сервиса, оказывается, что отсутствует дополнительный функционал, необходимый магазину. Опыт разработчика может помочь при выборе оптимального решения для интеграции, отвечающего процессам и целям магазина.
  • Выбор неподходящей платформы. Клиент сам выбирает вариант платформы без понимания ее особенностей. Например, бизнес ведется по модели маркетплейса (Multi-Vendor), но клиент покупает лицензию однопользовательского интернет-магазина (CS-Cart). До покупки лицензии лучше обратиться к исполнителю и дать описание бизнес-модели и бизнес-процессов компании. Так, исполнитель сможет подсказать, какой вариант платформы подходит лучше всего.
  • Неверно сформированный запрос. Например, заказчик просит исправить код для улучшения показателей SEO, но на самом деле проблема не в коде, а в сервере, который не выдерживает нагрузку. Здесь помогло бы четкое описание проблемы и желаемого результата. Исполнитель сможет подобрать комплексное решение, помогающее оптимально достичь цели.

Выводы

  • Завершите сбор бизнес-требований до формирования спецификации на разработку интернет-магазина. Так вы вложите меньше усилий и средств и уменьшите время создания разработки.
  • Ставьте задачи конкретно. Суть в том, чтобы разрабатываемый сайт выполнял все возложенные на него задачи. Всегда дополняйте конкретные функциональные требования обобщенными бизнес-требованиями. Так, совместно с разработчиком, вы сможете выработать оптимальный путь решения задачи.
  • Участвуйте в сборе требований. Только заказчик имеет глубокое представление о специфике своего бизнеса. В случае с некрупной организацией, имеет смысл нанять сторонних специалистов или обратиться к команде разработчика. Какой бы путь ни был выбран, принимайте активное и непосредственное участие на всех этапах. Так вы гарантируете, что все особенности бизнеса будут учтены.

Если вы запускаете интернет-магазин с нуля или существенно меняете его функционал, мы рекомендуем воспользоваться услугой “Проектирование архитектуры интернет-магазина”. Наши специалисты сами соберут требования, адаптируют их под выбранную платформу, предоставят вам все необходимые материалы для понимания работы проекта.

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

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

Отправить заявку

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

Спасибо, мы получили ваш запрос и скоро ответим на него

Спасибо за обращение!
Мы свяжемся с вами в течение 1 часа в рабочее время