В разработке и реализации сайта электронной коммерции участвуют пожелания клиента и техническая реализация проекта. В идеале желания должны совпасть с технической реализацией, чтобы клиент получил то, что в итоге хотел. Для этого нужно выяснить все пожелания, собрать все требования с клиента и описать их в техническое задание (ТЗ) для разработчиков. А для того, чтобы создать ТЗ существуют такие вещи, как: бриф, описание бизнес требований, функциональных требований.
У вас есть идея? У нас есть решение!
Найдите идеальный вариант для вашего сайта
Выбрать решение
Что такое бизнес требования? Пример
Бизнес требования являются основой любого проекта. Они фокусируются на потребностях и целях бизнеса, определяя, какие задачи должен решить проект, чтобы добиться успеха. Эти требования включают цели и задачи, критические факторы успеха и ожидаемые выгоды.
Они включают в себя:
- Информацию и данные о компании. Сфера деятельности бизнеса, основные конкуренты, клиенты, основные преимущества, бизнес документы, регулирующие деятельность отрасли.
- Информация о целевой аудитории. Необходимо четко представлять, кто будет посетителями сайта. Сегментируйте аудиторию на группы, используя данные о поле, возрасте, регионах проживания, привычках и увлечениях. Это позволит понять вам, с какой целью посетители будут заходить на сайт.
- Информация о конкурентах. Какой функционал предлагает сайт конкурентов, какие у них преимущества, какое ценообразование и ассортимент.
- Уточнить цель создания сайта. Это может быть расширение географии продаж, увеличение охвата клиентов и, как следствие, увеличение конверсии и прибыли.
- Определить метрики эффективности сайта. По каким показателям вы поймете, что сайт помогает добиться вашей бизнес цели. Это могут быть: ROI, коэффициент конверсии, количество лидов и т.д.
Пример:
4. Функциональные требования, тикеты, JIRA (Курс бизнес-аналитик с нуля)
Для сайта по бронированию путешествий часть бизнес требований может заключаться в предоставлении возможностей:
Для посетителей — могут выбрать и забронировать отели, экскурсии в выбранной геолокации, найти машины для проката авто, найти и забронировать столик в кафе и ресторанах. При необходимости оплатить услуги через сайт.
Для вендоров — размещать свои услуги на этом канале продаж и продвигаться для большей эффективности.
Для владельца сайта — привлекать больше вендоров, партнеров, создавая уникальную площадку и увеличивая конверсию и прибыль с сайта.
Бизнес требования важно выяснить в самом начале жизненного цикла проекта, чтобы команда бизнеса и команда разработчиков находились на одной волне. Они служат основой для определения подходящей платформы, объема задач и разработки плана проекта.
Без четкого понимания бизнес требований бюджет проекта может выйти из-под контроля или привести к неправильным результатам.
Какие задачи помогают решить описанные бизнес требования
Четко сформулированные бизнес требования решают следующие задачи:
Как писать требования так, чтобы команда хотела их читать / Александр Войтехович / ISsoft
- Помогают команде бизнеса и разработчикам четко понять, что должно получится на выходе, какая основная цель сайта.
- Помогают определиться в дальнейшем с killer features, без которых цель сайта будет недостижима.
- Помогают приоритизировать последующие требования, чтобы грамотно расходовать бюджет.
- Помогают экономить время и бюджет на разработку, чтобы предупредить большое количество доработок.
Что такое функциональные требования? Пример
Функциональные требования собирают информацию о том, как должен работать сайт, интернет-магазин или маркетплейс. Что должно происходить при действиях разных участников сайта и как система должна реагировать. К примеру, как должен работать функционал бронирования отеля, регистрации на сайте, поиска подходящего тура и т.д.
Описание функциональных требований поможет разработчикам продумать архитектуру и составить дорожную карту разработки функционала.
Важные разделы сайта, для которых необходимо описать функциональность
Разберем кратко разделы на примере сайта по бронированию путешествий и отдыха:
1.Домашняя страница: это главная страница вашего сайта, визитная карточка. По ней пользователь должен сразу понять, о чем сайт, как попасть в каталог услуг, где находится строка поиска с необходимыми фильтрами, куда нажать, чтобы войти в личный кабинет или создать его. Также нужно продумать, будут ли на странице представлены рекламные блоки, акционные предложения, группы услуг.
2. Поиск: если сайт предполагает широкий спектр услуг, то необходимо предусмотреть фильтры для каждой из них. Но выбор необходимых дат, геолокации, количество путешествующих важно для всех категорий.
3. Страница результатов поиска: после того как пользователи введут информацию о своей поездке, они должны быть перенаправлены на страницу, где смогут просмотреть список всех доступных рейсов, гостиничных номеров, возможности проката авто, выбора кафе, ресторана, экскурсии и других вариантов для путешествий, соответствующих их критериям.
4. Каталог услуг: он предполагает разные разделы сайта, по которым пользователь будет перемещаться в зависимости от цели визита. Его ширина и глубина ограничивается вашими бизнес целями и требованиями.
5. Карточка товара/услуги: предполагает описание услуги с фотографиями, отзывы, доступные даты, стоимость, возможность связаться, оставить заявку, приобрести/забронировать услугу.
6. Страница бронирования отелей: Пользователи должны иметь возможность просматривать все доступные гостиничные номера, их удобства и цены. Они также должны иметь возможность выбрать предпочитаемый вариант размещения и ввести свою личную информацию, чтобы забронировать номер.
7. Страница бронирования рейсов: если ваш сайт предлагает услуги бронирования рейсов, вам следует создать для этого отдельную страницу. На ней должны отображаться все доступные пользователю рейсы, а также их цены, время вылета/прибытия, аэропорты и вокзалы вылета/прибытия, информация о перевозчике, возможные пересадки, время в пути. Пользователи должны иметь возможность выбрать предпочтительный рейс и ввести свою личную информацию, чтобы забронировать рейс.
8. Страница оплаты: после того как пользователи выбрали услугу, они должны быть перенаправлены на безопасную страницу оплаты, где они могут ввести свои платежные данные для завершения процесса бронирования.
9. Страница подтверждения: после того, как пользователи завершили процесс бронирования, они должны быть перенаправлены на страницу подтверждения, на которой отображаются все детали их бронирования вместе с номером подтверждения.
Как составить функциональные требования?
Один из подходов составления функциональных требований состоит в том, что вы описываете поведение пользователей в зависимости от его роли на сайте. Это так называемые пользовательские истории, или user story.
User story отвечают на три вопроса:
- Кто пользователь?
- Какое действие он хочет выполнить?
- Для чего это ему?
Роли на сайте могут быть:
Посетители сайта — могут искать нужные услуги или просматривать доступную информацию. Посетители и покупатели на сайте могут быть как физические лица, так и юридические b2b.
Продавцы или вендоры — физические или юридические лица, размещающие свои услуги на сайте.
Администраторы — управляют бесперебойной работой сайта, ведут арбитраж споров между продавцами и покупателями, производят расчеты с продавцами, уведомляют вендоров об оформлении заказа.
Модераторы — они могут проводить модерацию и проверку продавцов, а также отвечают за модерацию контента на сайте. Проверяют наличие спама, отслеживают поведение пользователей, предотвращают мошенничество.
Пример:
Посетитель на сайте хочет зарегистрироваться как юридическое лицо, чтобы оплатить услуги на сайте через выставленный счет.
Функционал должен предусматривать раздельную регистрацию для физических и юридических лиц, заполнение сведений для выставления счета в личном кабинете пользователя.
Что такое техническое задание?
Техническое задание (ТЗ) –- это документ, в котором описываются все требования и характеристики для создания сайта. Этот документ составляют разработчики на основании тех требований, которые собраны с заказчика. В нем описывается технический функционал для бэкэнда, фронтэнда, все интеграции, требования к системе и инфраструктуре, а также подходы к тестированию продукта.
В нашей практике встречается два варианта развития событий:
- У клиента есть бизнес и функциональные требования. Тогда эти требования компания-разработчик уточняет и трансформирует в ТЗ.
- У клиента нет сформированных требований. Тогда проводится бриф, описываются бизнес задачи, функциональные требования и составляется ТЗ.
Составленное ТЗ согласовывается с клиентом и является неотъемлемой частью договора.
Таким образом, если клиенту нужно быстрее начать разработку, то нужно продумать и составить не техническое задание, а бизнес требования, описать, как должен работать функционал сайта.
Почему описывать требования нужно?
Во-первых, это необходимо для того, чтобы получить именно тот продукт, который нужен заказчику.
Во-вторых, четко описанные требования экономят бюджет заказчика, так как позволяют сделать то, что нужно с первого раза.
В-третьих, после описания требований стоимость разработки сайта может измениться так же, как и сроки запуска.
Основные ошибки при составлении требований к проекту
1.Расплывчатое или чрезмерно подробное описание требований. Формулировки должны быть понятны и обозначать одно и тоже для всех участников, а результат можно оценить или измерить.
Например:
- “Понятный чекаут для покупателя” — расплывчато, а оценка может быть только субъективной.
- “Чекаут для покупателя должен содержать шкалу прогресса” — в этом случае ясно, что необходимо сделать разработчикам.
2. В требованиях не закладываются автоматизации и возможности для масштабирования. Часто это происходит по причине экономии средств, но по итогу могут привести к неверно выбранному решению.
Например:
Проект клиента на текущий момент небольшой, и администраторы вполне могут справиться вручную с обработкой заказов, которая предполагает сверку данных. Но по мере роста количества заказов, операционная нагрузка на администраторов увеличится или их потребуется больше в штате. Проблему можно было решить, заложив автоматическую проверку загружаемых данных.
3. Чрезмерное погружение в описания и многочисленные правки. Это не значит, что правок не должно быть совсем. Но доводя до идеала описание требований, вы должны помнить о цели. А конечная цель — запустить проект.
Четкие бизнес требования помогут не отклонится от курса.
4. Выбор не подходящего технического решения. Выбор и внедрение любых сервисов и интеграций должно быть обоснованным решением, а не пожеланием заказчика. Главная задача сервисов — соответствие всем требованиям заказчика и техническая совместимость с платформой, на которой создается сайт.
У вас есть идея? У нас есть решение!
Найдите идеальный вариант для вашего сайта
Выбрать решение
Выводы
1. Для того чтобы подготовиться к встрече с разработчиками, следует заранее продумать и составить бизнес требования к проекту. Сформулированные бизнес требования помогут определиться с основным функционалом для запуска сайта, бюджетом и сроками разработки.
2. Описывая функционал сайта по разделам, воспользуйтесь методом User Story. Он подразумевает описание поведения пользователя, в зависимости от его роли на сайте. Помните о том, каких целей должны достичь пользователи сайта.
3. Функциональные и бизнес требования помогут создать качественное ТЗ на разработку сайта электронной коммерции, а также помогут избежать исправлений, что сэкономит ваш бюджет.
4. В составлении функциональных и бизнес требований может помочь аналитик. Он сделает единое видение и понимание работы сайта для заказчика и разработчиков.
Хочу быть в курсе ecommerce событий!
Подписывайся, чтобы не пропустить новые статьи, советы, тематические исследования.
- Содержание
Хочу быть в курсе ecommerce событий!
Подписывайся, чтобы не пропустить новые статьи, советы, тематические исследования.
Команда Cart-Power
Другие статьи этой категории
Что такое Elasticsearch, зачем он нужен на сайте? Наш пример… Как известный сервис от Elastic Stack мы интегрировали на сайте нашего клиента. Что такое Elasticsearch, как он работает и как…
Как и зачем устанавливать GA4 на ваш интернет-магазин Как перейти на новую версию Google Analytics 4, как в ней работать и что в ней есть полезного для интернет-магазинов.
Зачем бизнесу свой интернет магазин в эпоху маркетплейсов? Рассказываем о том, зачем нужен свой интернет магазин, если можно продавать на маркетплейсах. Сколько стоит создать интернет магазин и почему…
Источник: cart-power.ru
Какие бывают требования?
Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования. Модель на рис. ниже иллюстрирует способ представления этих типов требований.
Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.
Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.
Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.
Системные требования (system requirements) — это высокоуровневые требования к продукту, которые содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.
Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные ВИ, или диктовать, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил.
Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта
Характеристика продукта (feature) — это набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели. В области коммерческого ПО характеристика представляет собой узнаваемую всеми заинтересованными лицами группу требований, которые важны при принятии решения о покупке — элемент маркированного списка в описании продукта.
Источник: www.uml2.ru
Виды требований к программным продуктам
Публикую больше для себя, чтобы всегда было под рукой… Ничего нового вы для себя здесь не найдёте, но всё удобно и в одном месте..
Итак, IEEE Standard Glossary of Software Engineering Terminology определяет требования как:
- Условия или возможности, необходимые пользователю для решения проблем или достижения целей;
- Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам
- Документированное представление условий или возможностей для п. 1 и 2
Какие требования бывают
Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования. Модель на рис. ниже иллюстрирует способ представления этих типов требований.
Бизнес-требования (business requirements)
Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.
Требования пользователей (user requirements)
Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.
Функциональные требования (functional requirements)
Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.
Системные требования (system requirements)
Системные требования (system requirements) – это высокоуровневые требования к продукту, которые содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.
Бизнес-правила (business rules)
Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные ВИ, или диктовать, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил.
Нефункциональные требования
Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта
Характеристика продукта (feature)
Характеристика продукта (feature) — это набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели. В области коммерческого ПО характеристика представляет собой узнаваемую всеми заинтересованными лицами группу требований, которые важны при принятии решения о покупке — элемент маркированного списка в описании продукта.
Какими характеристиками должны обладать хорошие требования?
Характеристики качества превосходных требований:
– Полнота. Каждое требование должно полно описывать функциональность, которую следует реализовать в продукте. То есть оно должно содержать всю информацию, необходимую для разработчиков, чтобы тем удалось создать этот фрагмент функциональности. Если вы понимаете, что данных определенного рода не хватает, используйте пометку «TBD» (to be determined — необходимо определить) на полях как стан-
дартный флаг для выделения такого места. Восполните все пробелы в каждом фрагменте требований, прежде чем приступать к конструированию этой функции.
– Корректность. Каждое требование должно точно описывать желаемую функциональность. Для соблюдения корректности необходима связь с источниками требований, например с пожеланиями пользователей или высокоуровневыми системными. Требования к ПО, которые конфликтуют с родительскими требованиями, нельзя считать корректными. Однако основная оценка здесь— за представителями пользователей, вот почему им или их непосредственным заместителям необходимо предоставлять требования для просмотра.
– Осуществимость. Необходима возможность реализовать каждое требование при известных условиях и ограничениях системы и операционной среды. Чтобы не придумывать недостижимые положения, обеспечьте взаимодействие разработчиков с маркетологами и аналитиками требований на период всего извлечения требований. Разработчики реально оценят, что можно выполнить технически, а что нет, или что сделать можно, но при дополнительном финансировании. Инкрементальная разработка и подтверждающие концепцию прототипы позволяют проверить осуществимость требования.
– Необходимость. Каждое требование должно отражать возможность, которая действительно необходима пользователям или которая нужна для соответствия внешним системным требованиям или стандартам. Кроме того, оно должно исходить от лица, которое имеет полномочия на запись положения. Отследите каждое требование вплоть до стадии сбора мнений пользователей, когда выявлялись варианты использования,
бизнес-правила или другие источники.
– Назначение приоритетов. Назначьте приоритеты каждому функциональному требованию, характеристике или варианту использования, чтобы определить, что необходимо для каждой версии продукта. Если все положения одинаково важны, менеджеру проекта будет трудно справиться с уменьшением бюджета, нарушением сроков, потерей персонала или добавлением новых требований в процессе разработки,
Дополнительная информация В главе 14 назначение приоритетов обсуждается в деталях.
– Однозначность. Все читатели требований должны интерпретировать их одинаково, но естественный язык зачастую грешит многозначностью. Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям. «Ясность»— цель качества требований, связанная с точностью: читатели должны четко понимать каждое положение. Занесите все специальные и запутанные термины в словарь.
– Проверяемость. Попробуйте разработать несколько тестов или примените другие приемы для проверки, например экспертизу или демонстрации, чтобы установить, действительно ли в продукте реализовано каждое требование. Если требование не проверяется, вопрос его корректной реализации становится предметом заключения, а не целью анализа. Неполные, несогласованные, невыполнимые или двусмысленные требования также не проверяются.
Какими характеристиками должны обладать спецификации требований?
Набор требований, составляющий спецификацию, должен отвечать характеристикам:
– Полнота. Никакие требования или необходимые данные не должны быть пропущены.
– Согласованность. Согласованные требования не конфликтуют с другими требованиями такого же типа или с высокоуровневыми пользовательскими, системными или бизнес-требованиями. Несогласованность документов следует устранить до начала процесса разработки. Вы не всегда знаете, какое именно положение некорректно (если какое-то некорректно), пока не выполните исследование. Рекомендуется записывать автора каждого требования, чтобы узнать, кто его высказал, если конфликт все-таки будет обнаружен.
– Трассируемость. Трассируемость, или возможность для анализа, можно реализовать как в направлении назад, к первоисточникам, так и вперед, к элементам дизайна и исходному коду, который его реализует, а также к вариантам использования, которые позволяют проверить корректность, реализации. Трассируемые требования помечены соответствующими идентификаторами. Они записаны в структурированной, детализированной форме, в противоположность параграфам в длинной повествовательной форме. Избегайте слипания множества требований в один ком, отдельные требования можно трассировать к различным элементам дизайна и кода.
Источник: akiselev87.wordpress.com