Функциональные и бизнес-требований для интернет-магазина

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

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

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

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

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

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

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

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

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

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

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

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

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

Дарья

Sales Manager

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

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

Итак, бизнес-требования – это общие задачи, решаемые сайтом. После сбора бизнес-требований идет этап определения функциональных требований.

Что такое функциональные требования?

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

Гульназ

Head of Account Management

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

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

Нефункциональные требования. Важные особенности

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

Нефункциональных требований очень много. Вот некоторые примеры:

Дизайн, UX/UI. Добавить дополнительную кнопку на чекауте. При переходе на страницу продукта пользователь видит все вариации продукта.

Требования к коду: cделать модификацию на JS, работа в репозитории клиента, использовать указанные заказчиком библиотеки при реализации модификации.

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

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

Контент. На продуктовые страницы добавить ссылки на юридические документы. Такое требование часто озвучивают владельцы немецких маркетплейсов.

Производительность сайта. Магазин должен выдерживать нагрузку в 1000 посетителей онлайн одновременно.

Кто собирает требования?

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

✔ Стороннее агентство, нанятое заказчиком

✔ Штатный аналитик заказчика

✔ Наша команда в рамках услуги “Проектирование”

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

Валерия

System Analyst

Как происходит сбор требований?

Обычно сбор требований происходит через интервью, переписку или в специальных системах типа Notion, Trello и т.д. Приведем алгоритм сбора требований:

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

Кто участвует в сборе требований?

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

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

Вспомогательные материалы, предоставляемые заказчиком

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

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

Какие ошибки допускают заказчики в ходе сбора информации?

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

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

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

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

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

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

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

Выводы

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

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

Поделиться статьей:

Как оформить функциональные и бизнес-требования к сайту электронной коммерции?