Чтобы составить Техническое Задание на разработку ПО, вам необходимо определить, какие задачи стоят перед вашим интернет-магазином или маркетплейсом и как вы будете продавать. Для этого нужно учесть интересы и целевой аудитории, и тех, кто будет работать над сайтом. Другими словами, потребуется оформить требования к разработке. Требования могут быть разными: к функционалу разрабатываемой платформы, ее надежности и безопасности, а также к ожидаемому эффекту для бизнеса. В этой статье рассмотрим, что представляют собой функциональные требования, как правильно их оформлять и передавать исполнителю работ.
Наши специалисты сами соберут требования.
Вы получите точное описание всех разделов интернет-магазина и карту реализации проекта
с указанием этапов и сроков выполнения работ.
Что такое функциональные требования?
Функциональные требования — это описание всех функций, выполняемых системой в рамках определенного задания.
Примеры функциональных требований к проекту:
- Вендор регистрируется в системе: система регистрирует данные вендора на входе и на выходе отображает их на странице всех вендоров.
- Присвоение уникального номера заказу: система обрабатывает заявки на заказы. Приходит заказ, система присваивает ему номер и на выходе выдает список заказов.
- Расчет доставки: система по API запрашивает данные у сервиса доставки и выдает рассчитанную стоимость доставки на странице заказа.
- Поддержка мобильных кошельков: в странах Среднего Востока и Северной Африки система принимает оплату с мобильного телефона.
Какие функциональные требования могут быть включены в разработку сайта?
- Регистрация и аутентификация пользователей:
-
-
- Создание учетной записи пользователя.
- Вход в систему с использованием учетных данных.
- Восстановление пароля.
-
- Управление контентом:
-
-
- Добавление, редактирование и удаление контента на сайте.
- Загрузка и отображение изображений, видео и других медиафайлов.
- Управление списками и категориями контента.
-
- Поиск и фильтрация:
-
-
- Поиск по сайту с использованием ключевых слов или фраз.
- Фильтрация контента по различным критериям, таким как дата, категория или автор.
-
- Взаимодействие с пользователями:
-
-
- Комментирование контента.
- Оценка или рейтинг контента.
- Обратная связь с пользователями через форму на сайте или электронную почту.
- Прикрепление файлов (фото, видео)
-
- Интеграция с социальными сетями:
-
-
- Авторизация через аккаунты в социальных сетях.
- Публикация контента на страницах в социальных сетях.
-
- Оптимизация для поисковых систем (SEO):
-
-
- Настройка мета-тегов для каждой страницы.
- Настройка ЧПУ (человекопонятных URL) для улучшения видимости сайта в поисковых системах.
-
- Аналитика и отчетность:
-
- Отслеживание статистики посещаемости сайта.
- Создание отчетов о поведении пользователей на сайте.
Зачем нужны функциональные требования?
Почему функциональные требования так важны
Рассмотрим несколько причин:
- Определение функциональности: Функциональные требования помогают определить, какие функции должна выполнять система. Например, покупатель оформляет заказ. Какие функции сайта ему доступны на данном этапе? Что система отображает пользователю при определенных действиях? Что происходит с сайтом в ответ на действия покупателя? Без четкого определения функциональности разработчики могут не корректно понять, что должна делать система.
- Уточнение ожиданий: Они помогают уточнить ожидания заказчика и пользователей. Они позволяют разработчикам и заказчикам обсудить и согласовать, как должна работать система. Это помогает избежать недоразумений и несоответствий между ожиданиями и фактическим результатом.
- Определение границ системы: Функциональные требования помогают определить границы системы. Они указывают, какие функции должны быть включены в систему, а какие — нет. Это помогает разработчикам сосредоточиться на разработке необходимых функций и избежать перегрузки системы ненужными функциями.
- Оценка и планирование: Они позволяют оценить сложность и объем работы для разработки системы. Они помогают разработчикам и менеджерам проекта определить ресурсы, необходимые для реализации функциональностей, и спланировать время и бюджет проекта.
- Тестирование и верификация: Функциональные требования являются основой для тестирования и верификации системы. Они помогают разработчикам и тестировщикам проверить, что система работает правильно и соответствует требованиям.
Типы и классы функциональных требований
Ниже приведем 10 основных типов и классов функциональных требований:
- Функциональности: связаны с основным функционалом системы или продукта. Функционал — это, например, возможность поиска, добавления, редактирования и удаления данных.
- Производительность: связаны с производительностью системы или продукта. Например, требования к времени отклика, скорости обработки данных или количеству одновременных пользователей.
- Надежность: имеют отношение к надежности системы или продукта. Например, требования к доступности, отказоустойчивости или восстановлению после сбоев.
- Безопасность: требования, связанные с защитой системы или продукта от несанкционированного доступа или злоумышленников. Например, требования к аутентификации, авторизации или шифрованию данных.
- Требования к интерфейсу пользователя: относятся к пользовательским интерфейсом системы или продукта. Например, требования к удобству использования, доступности или совместимости с различными устройствами.
- Масштабируемость: связаны с возможностью системы или продукта масштабироваться для обработки больших объемов данных или увеличения числа пользователей.
- Поддержка: речь идет о поддержке системы или продукта после его внедрения. Например, требования к документации, обучению пользователей или технической поддержке.
- Интеграция: имеется в виду интеграция системы или продукта с другими системами или компонентами. Например, требования к форматам данных, протоколам обмена или совместимости с другими программными продуктами.
- Адаптивность: требования, связанные с возможностью системы или продукта адаптироваться к изменяющимся условиям или требованиям. Например, требования к поддержке различных языков, валют или региональных настроек.
- Доступность: доступность системы или продукта для пользователей с ограниченными возможностями. Например, требования к поддержке альтернативных способов ввода или вывода данных, блокировке содержания или увеличению размера шрифта.
Что необходимо учитывать в функциональных требованиях?
Функциональные требования описывают, что система должна делать, какие функции она должна выполнять или какие задачи она должна решать. При их разработке необходимо учитывать следующие аспекты:
- Цель и контекст системы: Функциональные требования выстраиваются вокруг целей и контекста использования системы. Необходимо понять, какие задачи и функции будут полезны для пользователей в данной ситуации.
- Четкость и однозначность: Требования должны быть ясными и понятными для всех заинтересованных сторон. Их нужно сформулировать таким образом, чтобы не оставлять места для различных интерпретаций.
- Полнота: Все функции и задачи, которые система должна выполнять. Необходимо предусмотреть все возможные сценарии использования системы и описать соответствующие функции.
- Применимость: Функциональные требования должны быть применимыми и выполнимыми. Необходимо учитывать ограничения технической реализации и возможности системы.
- Измеримость: Функциональные требования должны быть измеримыми и проверяемыми. Необходимо определить критерии для проверки выполнения каждой функции и задачи.
- Приоритеты: Требования нужно упорядочить по приоритетам. Необходимо определить, какие функции и задачи являются наиболее важными для пользователей и бизнеса.
- Изменяемость: Функциональные требования должны быть гибкими и способными к изменениям. Необходимо предусмотреть возможность добавления, изменения или удаления функций в будущем.
Как выявлять функциональные требования
Выявление функциональных требований является важным этапом в разработке программного обеспечения. Оно заключается в определении функций и возможностей, которые необходимо реализовать в системе.
Для выявления функциональных требований можно использовать следующие методы:
- Интервьюирование заинтересованных сторон: Провести интервью с потенциальными пользователями, заказчиками и другими заинтересованными сторонами для выяснения их требований и ожиданий от системы.
- Анализ документации: Изучить существующие документы (бизнес-планы, спецификации, макеты и прототипы) для выявления функций, которые уже были определены.
- Наблюдение и анализ рабочих процессов: Изучить текущие рабочие процессы и задачи, чтобы выявить потребности в автоматизации и функции, которые могут быть реализованы в системе.
- Прототипирование и тестирование: Создать прототип системы и протестировать его с пользователями для определения функциональных требований и получения обратной связи.
- Мозговой штурм: Организовать мозговой штурм с командой разработчиков и заинтересованными сторонами для генерации идей и выявления функций.
Как оформлять функциональные требования
Оформление функциональных требований может варьироваться в зависимости от используемой методологии разработки и предпочтений команды. Однако, в целом, следует придерживаться следующих рекомендаций:
- Заголовок: Функциональные требования должны иметь ясный и информативный заголовок, который отражает суть требования.
- Описание: Под заголовком следует предоставить подробное описание функционального требования. Опишите, что именно должна делать система или функция, какие данные она должна обрабатывать и какие результаты она должна предоставлять.
- Приоритет: Обозначьте приоритет требования, чтобы команда разработки могла определить, какие функции следует реализовать в первую очередь.
- Примеры использования: Предоставьте примеры использования системы или функции, чтобы помочь команде разработки лучше понять требования и контекст их использования.
- Ограничения: Напишите любые ограничения или ограничения, которые могут повлиять на реализацию требования, такие как бюджетные ограничения, ограничения по времени или требования к совместимости с другими системами.
- Взаимодействие с другими функциями: Если требование взаимодействует с другими функциями или системами, укажите это и опишите, как они должны взаимодействовать.
- Тестирование: Укажите, как будет проводиться тестирование функционального требования, чтобы проверить его правильность и соответствие.
Важно помнить, что оформление функциональных требований должно быть понятным и доступным для всех членов команды разработки.
Чем функциональные требования отличаются от нефункциональных требований?
Функциональные требования определяют, как система должна вести себя, какие функции и возможности она должна предоставлять пользователю. Например, функциональные требования для интернет-магазина могут включать возможность создания аккаунта, добавления товаров в корзину, оформления заказа и т.д.
Нефункциональные требования определяют характеристики системы, такие как производительность, надежность, безопасность, удобство использования и т.д. Они не описывают конкретные функции системы, а скорее задают ограничения и ожидания по ее работе. Например, нефункциональные требования могут включать требования к времени отклика системы, к ее масштабируемости, к безопасности пользовательских данных и т.д.
Чем функциональные требования отличаются от бизнес-требований?
Функциональные требования определяют, что должна делать система или продукт, какие функции и возможности они должны предоставлять. Они описывают, как система должна взаимодействовать с пользователем или другими системами, какие операции она должна выполнять и какие данные она должна обрабатывать.
Бизнес-требования определяют, что ожидает клиент или заказчик от системы или продукта, какие бизнес-процессы они должны поддерживать или улучшать. Они описывают цели и задачи бизнеса, которые должны быть достигнуты с помощью системы или продукта, а также ограничения и требования к производительности, безопасности, надежности и т. д.
Таким образом, функциональные требования определяют, что система должна делать, а бизнес-требования определяют, почему система должна делать это и как это поможет достичь бизнес-целей.
Кто собирает требования?
Сбором первичных требований к интернет-магазину занимается менеджер отдела продаж. К этому процессу, могут также подключаться:
✔ Стороннее агентство, нанятое заказчиком
✔ Штатный аналитик заказчика
✔ Наша команда в рамках услуги “Проектирование”
Если заказчик пришел с уже готовыми требованиями, то, как правило, потребуется их адаптация под наши решения с учетом особенностей платформы CS-Cart. То есть мы накладываем пожелания клиента на возможности платформы CS-Cart и подбираем наилучший способ реализации.
Как происходит формирование функциональных требований?
Обычно сбор требований происходит через интервью, переписку или в специальных системах типа Notion, Trello и т.д. Приведем алгоритм сбора требований:
- Предоставление общих требований к продукту или брифование для составления MVP.
- Если запрос описан четко и конкретно, менеджер обсуждает требования с техническим экспертом.
- Дается грубая оценка реализации.
- Если нужны уточнения, используются уточняющие вопросы, проводится дооценка сроков и стоимости работ.
Кто участвует в сборе требований?
В зависимости от потребностей проекта, можно и нужно привлекать следующих заинтересованных лиц:
- Продавцы и отдел привлечения персонала (для маркетплейсов);
- Бухгалтерия (чтобы понимать, какие отчеты нужны, как проводить платежи);
- Юридический отдел (если есть юридические ограничения, которые нужно учесть при создании интернет-магазина);
- Маркетинг (для реализации механики промо акций);
- IT-отдел (при наличии, поскольку может понадобиться интеграция с внутренними системами, которыми сейчас занимается отдел);
- Специалисты по безопасности;
- Сторонние эксперты.
Вспомогательные материалы, предоставляемые заказчиком
Дополнительные материалы помогают исполнителю лучше понимать процесс принятия решений в компании и организовать работу наиболее эффективным образом. К таким материалам можно отнести:
- Примеры конкурентов и реализации желаемого функционала;
- Блок-схема с описанием бизнес-процессов, функциональности;
- CJM-карта;
- Архитектурная диаграмма;
- Документ с описанием проекта (общее описание того, что будет представлено на панелях администратора, вендора и пользователя);
- Дизайн-макеты;
- План развития проекта, например, нагрузка на сайт, способы монетизации проекта, планы по ROI и т.п.;
- Список ролей участников проекта и схема принятия решения;
- User-cases (описание сценариев работы при определенной ситуации, например, что происходит при регистрации пользователя).
Какие ошибки допускают заказчики в ходе сбора информации?
- Выбор изначально неподходящего стороннего сервиса. Так происходит, когда заказчик не оговаривает цель, а просит подключить сервис на свой выбор. После интеграции сервиса, оказывается, что отсутствует дополнительный функционал, необходимый магазину. Опыт разработчика может помочь при выборе оптимального решения для интеграции, отвечающего процессам и целям магазина.
- Выбор неподходящей платформы. Клиент сам выбирает вариант платформы без понимания ее особенностей. Например, бизнес ведется по модели маркетплейса (Multi-Vendor), но клиент покупает лицензию однопользовательского интернет-магазина (CS-Cart). До покупки лицензии лучше обратиться к исполнителю и дать описание бизнес-модели и бизнес-процессов компании. Так, исполнитель сможет подсказать, какой вариант платформы подходит лучше всего.
- Неверно сформированный запрос. Например, заказчик просит исправить код для улучшения показателей SEO, но на самом деле проблема не в коде, а в сервере, который плохо выдерживает нагрузку. Здесь помогло бы четкое описание проблемы и желаемого результата. Исполнитель сможет подобрать комплексное решение, помогающее оптимально достичь цели.
Насколько детализированными должны быть требования?
Важно соблюдать баланс между подробностью и избыточностью. Если требования слишком детализированные, лучше сообщить исполнителю бизнес-цель и примерное видение. Так разработчик сможет подобрать подходящий вариант реализации.
Пример 1. Форма для регистрации интуитивно понятна.
Как нужно: Форма для регистрации имеет два поля: ФИО и телефон. Также, необходимо обеспечить посетителю возможность входа через социальные сети.
Пример 2. Магазин не должен тормозить.
Как нужно: Скорость загрузки страницы составляет 2 секунды. Магазин остается производительным при нагрузке в 150 тысяч посетителей в день.
Рекомендации заказчику, пишущему требования для интернет-магазина или маркетплейса
Желательно, чтобы заказчик, формирующий требования, писал максимально просто с четким наименование объектов (покупатель, вендор, администратор сайта) и результата. Лучше всего, в формате пользовательских сценариев. При этом, функциональные требования будут выглядеть как совокупность функций, объединенных по смыслу. Например, кейс «Зарегистрировать визит пациента в зубной кабинет» будет состоять из совокупности функций:
- Просмотр истории визитов;
- Добавление еще одного визита;
- Выбор посещения зубного кабинета;
- Просмотр деталей визита (число, время, кабинет, лечащий врач);
- Редактирование информации о визите;
- Удаление визита.
Выводы
- Завершите сбор требований до формирования спецификации на разработку интернет-магазина. Так вы вложите меньше усилий и средств и уменьшите время создания разработки.
- Ставьте задачи конкретно. Так вероятность создания магазина, выполняющего все возложенные на него задачи, выше. Всегда дополняйте конкретные функциональные обобщенными бизнес-требованиями. Так, совместно с разработчиком, вы сможете выработать оптимальный путь решения задачи
- Участвуйте в сборе требований. Только заказчик имеет глубокое представление о специфике своего бизнеса. Имеет смысл нанять сторонних специалистов или обратиться к команде разработчика. Какой бы путь ни был выбран, принимайте активное и непосредственное участие на всех этапах. Так вы гарантируете, что все особенности бизнеса будут учтены.
Если вы запускаете интернет-магазин с нуля или существенно меняете его функционал, мы рекомендуем воспользоваться услугой “Проектирование архитектуры интернет-магазина”. Наши специалисты сами соберут требования, адаптируют их под выбранную платформу, предоставят вам все необходимые материалы для понимания работы проекта.
ЧаВо
Какие функции должен иметь сайт?
- Регистрация пользователей: позволяет пользователям создавать учетные записи на сайте.
- Вход в систему: позволяет зарегистрированным пользователям входить в свои учетные записи.
- Профиль пользователя: позволяет пользователям управлять своими персональными данными и настройками.
- Поиск: позволяет пользователям искать информацию на сайте по ключевым словам или категориям.
- Каталог товаров/услуг: позволяет пользователям просматривать список доступных товаров или услуг, а также получать дополнительную информацию о каждом из них.
- Корзина: позволяет пользователям добавлять выбранные товары или услуги в корзину для последующего оформления заказа.
- Оформление заказа: позволяет пользователям заполнять необходимую информацию для оформления заказа, такую как адрес доставки или способ оплаты.
- Отзывы и рейтинги: позволяет пользователям оставлять отзывы о товарах или услугах, а также ставить рейтинг.
- Контактная информация: предоставляет пользователям контактную информацию для связи с администрацией сайта или службой поддержки.
- Новости и блог: позволяет администраторам сайта публиковать новости, статьи или блоги для информирования пользователей о последних событиях или акциях.
Какие возможности есть для администраторов сайта?
- Управление пользователями: позволяет администраторам просматривать и управлять учетными записями пользователей, включая редактирование данных или блокировку аккаунтов.
- Управление контентом: позволяет администраторам добавлять, редактировать или удалять информацию на сайте, включая товары, услуги, новости и блоги.
- Управление заказами: позволяет администраторам просматривать и управлять оформленными заказами, включая изменение статуса заказа или отмену заказа.
- Управление отзывами и рейтингами: позволяет администраторам просматривать и управлять оставленными пользователями отзывами и рейтингами, включая модерацию или удаление некорректного контента.
- Управление настройками сайта: позволяет администраторам настраивать различные параметры сайта, такие как цветовая схема, язык интерфейса или способы оплаты.
Какие требования к безопасности должны быть учтены при разработке сайта?
- Защита от несанкционированного доступа: сайт должен обеспечивать безопасность пользовательских данных, таких как пароли или персональная информация, путем использования шифрования и механизмов аутентификации.
- Защита от взлома: сайт должен иметь механизмы защиты от взлома, такие как защита от SQL-инъекций, кросс-сайтового скриптинга или подделки запросов межсайтовой подделки.
- Резервное копирование данных: сайт должен регулярно создавать резервные копии данных, чтобы в случае сбоя или атаки можно было восстановить информацию.
- Обновление программного обеспечения: сайт должен регулярно обновляться до последних версий программного обеспечения, чтобы устранить известные уязвимости и обеспечить безопасность.
- Мониторинг активности: сайт должен иметь механизмы мониторинга активности пользователей и системы, чтобы быстро обнаруживать и реагировать на подозрительную или вредоносную активность.
Какие требования к масштабируемости должны быть учтены при разработке сайта?
- Горизонтальное масштабирование: сайт должен быть способен масштабироваться горизонтально путем добавления дополнительных серверов или ресурсов для обработки увеличивающейся нагрузки.
- Оптимизация производительности: сайт должен быть оптимизирован для быстрой загрузки и обработки запросов пользователей, чтобы обеспечить плавное и отзывчивое взаимодействие.
- Кэширование данных: сайт должен использовать механизмы кэширования данных для уменьшения нагрузки на сервер и ускорения работы сайта.
- Гибкость инфраструктуры: сайт должен быть разработан таким образом, чтобы его инфраструктура могла легко адаптироваться и масштабироваться в соответствии с изменяющимися потребностями и требованиями бизнеса.
- Тестирование производительности: сайт должен быть подвергнут тестированию производительности, чтобы обнаружить и устранить узкие места или проблемы, связанные с масштабируемостью.
