184 lines
15 KiB
Markdown
184 lines
15 KiB
Markdown
# 4. Функциональные требования
|
||
|
||
## 4.1 Требования к регистрации и подключению клиентов
|
||
|
||
Система должна поддерживать два базовых сценария подключения клиента:
|
||
|
||
- регистрация по персональному приглашению
|
||
- самостоятельная заявка на подключение
|
||
|
||
Функциональные требования:
|
||
|
||
1. Менеджер должен иметь возможность направить клиенту приглашение на регистрацию по электронной почте.
|
||
2. Клиент должен иметь возможность завершить регистрацию по персональной ссылке.
|
||
3. Клиент должен иметь возможность подать заявку на подключение через публичную форму.
|
||
4. Самостоятельная заявка должна поступать в менеджерский контур на рассмотрение.
|
||
5. Менеджер должен иметь возможность подтвердить либо отклонить заявку на подключение.
|
||
6. При подтверждении заявки система должна предоставить клиенту возможность завершить регистрацию.
|
||
7. После завершения регистрации клиент должен получить доступ к личному кабинету.
|
||
8. Система должна поддерживать подключение доступных каналов уведомлений для клиентской учетной записи.
|
||
|
||
## 4.2 Требования к каталогу готовой продукции
|
||
|
||
Система должна предоставлять клиенту каталог готовой продукции без отображения цены до обработки менеджером.
|
||
|
||
Функциональные требования:
|
||
|
||
1. Система должна отображать список товарных направлений.
|
||
2. Для каждого товарного направления система должна предоставлять отдельную карточку товара.
|
||
3. В карточке товара система должна отображать параметры выбора, применимые к данному типу продукции.
|
||
4. В карточке товара система должна отображать доступные стандартные варианты.
|
||
5. Для каждой доступной позиции система должна отображать складские остатки.
|
||
6. Система должна позволять клиенту выбрать параметры и добавить позицию в корзину.
|
||
7. Система должна исключать отображение стоимости до момента публикации условий менеджером.
|
||
8. Для параметров товара система должна отображать пояснения, помогающие клиенту понять назначение параметра и ограничения выбора.
|
||
|
||
## 4.3 Требования к параметрам каталога и кастомизации
|
||
|
||
Система должна поддерживать настройку параметров по каждому товарному направлению.
|
||
|
||
Функциональные требования:
|
||
|
||
1. Для каждого типа продукции должен задаваться перечень стандартных параметров выбора.
|
||
2. Для параметров длины должна поддерживаться настройка доступных стандартных значений.
|
||
3. Для параметров длины должна поддерживаться возможность индивидуального значения при наличии соответствующего разрешения.
|
||
4. Для параметров втулки должна поддерживаться возможность заказа втулки с логотипом при наличии соответствующего разрешения.
|
||
5. Для параметров надписи должна поддерживаться возможность заказа индивидуального нанесения при наличии соответствующего разрешения.
|
||
6. Наборы стандартных параметров должны редактироваться в административном контуре.
|
||
7. Изменение набора стандартных параметров не должно приводить к потере уже сохраненных заказных данных.
|
||
|
||
## 4.4 Требования к корзине и заявке на заказ
|
||
|
||
Система должна позволять клиенту собрать корзину и направить заявку на заказ.
|
||
|
||
Функциональные требования:
|
||
|
||
1. Клиент должен видеть перечень выбранных позиций.
|
||
2. Для каждой позиции клиент должен иметь возможность изменить количество.
|
||
3. Клиент должен иметь возможность удалить позицию из корзины.
|
||
4. Клиент должен иметь возможность направить заявку менеджеру.
|
||
5. После отправки заявки система должна зафиксировать состав, параметры и количество позиций.
|
||
6. Для заявки должны сохраняться дата создания, инициатор и закрепленный менеджер.
|
||
7. До обработки менеджером стоимость в заявке не должна отображаться клиенту.
|
||
|
||
## 4.5 Требования к обработке заявки менеджером
|
||
|
||
Менеджер должен иметь возможность обработать клиентскую заявку вручную.
|
||
|
||
Функциональные требования:
|
||
|
||
1. Менеджер должен видеть состав заявки и параметры заказанных позиций.
|
||
2. Менеджер должен видеть карточку клиента и сведения о контрагенте.
|
||
3. Менеджер должен иметь возможность указать стоимость.
|
||
4. Менеджер должен иметь возможность указать условия поставки и доставки.
|
||
5. Менеджер должен иметь возможность оставить комментарий к заявке.
|
||
6. Менеджер должен иметь возможность опубликовать согласованные условия клиенту.
|
||
7. До перевода заявки в работу менеджер должен иметь возможность скорректировать опубликованные условия.
|
||
8. Менеджер должен иметь возможность перевести заявку в работу.
|
||
9. Менеджер должен иметь возможность отменить заявку с фиксацией основания отмены.
|
||
|
||
## 4.6 Требования к заявке на расчет индивидуальной продукции
|
||
|
||
Система должна поддерживать отдельный сценарий расчета продукции с индивидуальными параметрами.
|
||
|
||
Функциональные требования:
|
||
|
||
1. Клиент должен иметь возможность перейти из каталога в сценарий расчета индивидуальной продукции.
|
||
2. Клиент должен иметь возможность указать параметры изделия.
|
||
3. Клиент должен иметь возможность приложить комментарий к заявке.
|
||
4. Клиент должен иметь возможность направить заявку менеджеру.
|
||
5. Менеджер должен иметь возможность обработать такую заявку по правилам, аналогичным заявке на заказ.
|
||
6. Стоимость и условия поставки должны публиковаться клиенту только после ручной обработки менеджером.
|
||
|
||
Минимальный состав параметров расчетной заявки должен поддерживать:
|
||
|
||
- тип продукции
|
||
- ширину
|
||
- длину
|
||
- толщину
|
||
- цвет
|
||
- надпись или маркировку
|
||
- иные параметры в зависимости от вида продукции
|
||
- текстовый комментарий клиента
|
||
|
||
## 4.7 Требования к статусам заявок
|
||
|
||
Система должна обеспечивать сквозное сопровождение заявок по статусам.
|
||
|
||
Для заявок на заказ и заявок на расчет должны поддерживаться следующие базовые статусы:
|
||
|
||
- создана
|
||
- направлена менеджеру
|
||
- обработана менеджером
|
||
- условия опубликованы
|
||
- в работе
|
||
- отменена
|
||
|
||
Для каждого изменения статуса система должна сохранять:
|
||
|
||
- предыдущее состояние
|
||
- новое состояние
|
||
- дату и время изменения
|
||
- пользователя или источник, выполнивший изменение
|
||
- комментарий, если он предусмотрен сценарием
|
||
|
||
## 4.8 Требования к заказам и их сопровождению
|
||
|
||
Система должна предоставлять клиенту и менеджеру доступ к списку заказов, карточке каждого заказа и актуальным учетным сведениям, полученным из 1С.
|
||
|
||
Функциональные требования:
|
||
|
||
1. Система должна отображать перечень заказов клиента.
|
||
2. Система должна поддерживать фильтрацию заказов по периоду и статусу.
|
||
3. Для каждого заказа система должна предоставлять отдельную карточку.
|
||
4. В карточке заказа должны отображаться состав, статус, стоимость, условия поставки и история изменений.
|
||
5. В карточке заказа должна отображаться дата актуальности данных.
|
||
6. При наличии обновлений из внешней системы сведения по заказу должны синхронизироваться и отображаться пользователю.
|
||
7. Система должна отображать текущую задолженность клиента, если такие сведения получены из 1С.
|
||
8. Для задолженности должна отображаться дата актуальности данных.
|
||
|
||
## 4.9 Требования к уведомлениям
|
||
|
||
Система должна поддерживать уведомления по нескольким каналам связи.
|
||
|
||
Поддерживаемые каналы:
|
||
|
||
- электронная почта
|
||
- Telegram
|
||
- Max
|
||
|
||
Система должна поддерживать уведомления по следующим событиям:
|
||
|
||
- приглашение к регистрации
|
||
- подтверждение либо отклонение заявки на подключение
|
||
- публикация условий по заявке
|
||
- изменение статуса заказа
|
||
- изменение бонусного баланса
|
||
- обработка заявки на использование либо вывод бонусов
|
||
|
||
## 4.10 Требования к бонусной и реферальной программе
|
||
|
||
Система должна включать бонусный контур как самостоятельную функциональную область с отдельным пользовательским интерфейсом.
|
||
|
||
Функциональные требования:
|
||
|
||
1. Система должна хранить правила участия клиента в бонусной программе.
|
||
2. Система должна поддерживать фиксацию реферальных связей.
|
||
3. Система должна хранить начисления, списания и текущий остаток бонусов.
|
||
4. Клиент должен видеть текущий бонусный баланс.
|
||
5. Клиент должен видеть историю бонусных операций.
|
||
6. Клиент должен иметь возможность использовать бонусы в пределах установленных правил.
|
||
7. Клиент должен иметь возможность подать заявку на вывод либо иную операцию, если это предусмотрено правилами программы.
|
||
8. Менеджер должен иметь возможность обрабатывать операции бонусного контура.
|
||
9. Система должна уведомлять клиента об изменениях бонусного состояния.
|
||
|
||
## 4.11 Требования к административным настройкам
|
||
|
||
Система должна содержать административные разделы для управления следующими объектами:
|
||
|
||
- параметрами каталога
|
||
- пользовательскими описаниями параметров
|
||
- шаблонами уведомлений
|
||
- параметрами синхронизации
|
||
- отдельными настройками бонусного контура
|