diff --git a/docs/.vitepress/config.ts b/docs/.vitepress/config.ts index c3ce504..9a6f55e 100644 --- a/docs/.vitepress/config.ts +++ b/docs/.vitepress/config.ts @@ -14,19 +14,20 @@ export default defineConfig({ text: 'Техническое задание', items: [ { text: '0. Общие положения', link: '/' }, - { text: '1. Основания и нормативная база', link: '/tz/normative-base' }, - { text: '2. Назначение и границы продукта', link: '/tz/product-scope' }, - { text: '3. Роли и права доступа', link: '/tz/roles-access' }, + { text: '1. Основания для разработки и нормативные материалы', link: '/tz/normative-base' }, + { text: '2. Назначение и границы программного продукта', link: '/tz/product-scope' }, + { text: '3. Роли пользователей и права доступа', link: '/tz/roles-access' }, { text: '4. Функциональные требования', link: '/tz/functional-requirements' }, - { text: '5. Данные и интеграции', link: '/tz/data-integrations' }, - { text: '6. Экранные формы и текстовые прототипы', link: '/tz/stage-1/' }, - { text: '7. Приемка и состав артефактов', link: '/tz/acceptance' }, + { text: '5. Требования к данным и интеграциям', link: '/tz/data-integrations' }, + { text: '6. Нефункциональные требования', link: '/tz/non-functional-requirements' }, + { text: '7. Экранные формы и прототипы интерфейсов', link: '/tz/stage-1/' }, + { text: '8. Порядок приемки и состав передаваемых материалов', link: '/tz/acceptance' }, ], }, { text: 'Приложения', items: [ - { text: 'А. Текущее состояние продукта', link: '/appendix/current-state' }, + { text: 'А. Текущее состояние программного продукта', link: '/appendix/current-state' }, ], }, ], @@ -35,7 +36,7 @@ export default defineConfig({ provider: 'local', }, footer: { - message: 'Черновик ТЗ для согласования с заказчиком', + message: 'Техническое задание на разработку программного продукта', copyright: 'Фрегат Групп / ИП Бакиев', }, }, diff --git a/docs/appendix/current-state.md b/docs/appendix/current-state.md index e4d1be9..98e6ff8 100644 --- a/docs/appendix/current-state.md +++ b/docs/appendix/current-state.md @@ -1,25 +1,27 @@ -# Приложение: текущее состояние продукта +# Приложение А. Текущее состояние программного продукта -## Назначение приложения +## А.1 Назначение приложения -Этот раздел нужен, чтобы ТЗ не отрывалось от реальной реализации. +Настоящее приложение фиксирует текущее состояние реализованных разделов программного продукта и используется как справочный материал при согласовании требований основного технического задания. -Ниже перечислены основные разделы, уже присутствующие в кодовой базе `web-frontend`, которые можно использовать как фактическую основу для дальнейшей детализации ТЗ. +## А.2 Реализованные клиентские разделы -## Клиентские разделы +В текущей реализации программного продукта присутствуют следующие клиентские разделы: - главная страница - каталог товаров -- карточка типа товара +- карточка товара - корзина -- список клиентских заказов -- карточка клиентского заказа +- список заказов +- карточка заказа - профиль пользователя - адреса - уведомления -- бонусная программа +- бонусный раздел -## Менеджерские разделы +## А.3 Реализованные менеджерские разделы + +В текущей реализации программного продукта присутствуют следующие менеджерские разделы: - список клиентов - карточка клиента @@ -30,22 +32,8 @@ - настройки каталога - настройки сообщений - настройки синхронизации -- бонусный блок +- бонусный раздел -## Что это означает для ТЗ +## А.4 Значение приложения для настоящего ТЗ -ТЗ можно писать не с нуля, а на основании уже сложившейся структуры продукта. - -Это позволяет: - -- быстро привязать бизнес-требования к реальным экранам -- не терять уже реализованные сущности -- сократить расхождение между договорной документацией и кодом - -## Что еще нужно будет дозаполнить - -- окончательная экранная карта -- перечень состояний каждого ключевого экрана -- точные статусы заявок и заказов -- детальное описание бонусного контура -- детальная спецификация интеграции с 1С +Сведения настоящего приложения используются для сопоставления требований технического задания с уже существующей структурой программного продукта и позволяют минимизировать расхождения между документацией и фактической реализацией. diff --git a/docs/index.md b/docs/index.md index 34f46b4..f4e801d 100644 --- a/docs/index.md +++ b/docs/index.md @@ -6,98 +6,62 @@ Заказчик: ООО `Фрегат Групп`. -Основания для разработки: +Основанием для разработки являются: - договор на разработку программного продукта №28/04-26ПО от 28 апреля 2026 года - приложение №1 к договору: спецификация основных требований к программному обеспечению `Личный кабинет Фрегат` -- текущая реализованная кодовая база клиентской и серверной части +- согласованный состав действующей клиентской и серверной реализации -Настоящее техническое задание определяет: +Настоящее техническое задание устанавливает требования к составу, функциям, данным, интеграциям, интерфейсным формам, условиям приемки и составу материалов, подлежащих передаче заказчику по результатам выполнения работ. -- назначение программного продукта -- состав и границы системы -- состав ролей и прав доступа -- функциональные и информационные требования -- требования к интеграциям -- требования к интерфейсным формам -- порядок приемки и состав передаваемых материалов +## 0.1 Назначение программного продукта -## Содержание +Программный продукт предназначен для автоматизации взаимодействия между ООО `Фрегат Групп` и B2B-клиентами компании в части: -1. [Основания и нормативная база](/tz/normative-base) -2. [Назначение и границы продукта](/tz/product-scope) -3. [Роли и права доступа](/tz/roles-access) -4. [Функциональные требования](/tz/functional-requirements) -5. [Данные и интеграции](/tz/data-integrations) -6. [Экранные формы и текстовые прототипы](/tz/stage-1/) -7. [Приемка и состав артефактов](/tz/acceptance) -8. [Приложение. Текущее состояние продукта](/appendix/current-state) - -## Назначение продукта - -Программный продукт предназначен для автоматизации взаимодействия между клиентами ООО `Фрегат Групп` и сотрудниками компании в части: - -- регистрации и подключения клиентов -- выбора готовой продукции -- оформления заявок на заказ -- оформления заявок на расчет индивидуальной продукции -- согласования стоимости и условий доставки +- подключения и регистрации клиентов +- выбора готовой продукции из каталога +- подачи заявок на заказ готовой продукции +- подачи заявок на расчет индивидуальной продукции +- согласования стоимости и условий поставки - сопровождения заказов по статусам -- уведомления клиентов по изменениям -- отображения бонусного и реферального контура +- направления клиентских уведомлений +- ведения бонусной и реферальной программы -## Ожидаемый результат разработки +## 0.2 Объект автоматизации -Результатом выполнения работ должен являться развернутый на инфраструктуре заказчика B2B веб-продукт, который: +Объектом автоматизации являются процессы клиентского обслуживания и внутренней обработки заявок, выполняемые менеджерами ООО `Фрегат Групп` при работе с готовой и индивидуальной продукцией. -- предоставляет отдельный клиентский и менеджерский интерфейс -- работает на desktop и mobile -- обеспечивает управление заказным контуром без отображения цены до ручной обработки менеджером -- обеспечивает хранение и отображение данных по клиентам, товарам, заявкам и заказам -- получает и отображает данные из 1С в согласованном объеме -- обеспечивает уведомления по email и подключенным мессенджерам -- позволяет сопровождать бонусную и реферальную программу +## 0.3 Состав системы -## Объект автоматизации - -Объектом автоматизации являются процессы взаимодействия с B2B клиентами ООО `Фрегат Групп`, включая: - -- подключение новых клиентов -- работу с каталогом готовой продукции -- оформление и согласование заявок -- сопровождение заказов -- информирование клиентов -- бонусные и реферальные механики - -## Состав системы - -В состав системы входят: +В состав программного продукта входят: - клиентский веб-интерфейс - менеджерский веб-интерфейс - серверная бизнес-логика -- хранилище данных -- интеграционный слой обмена с 1С +- база данных +- модуль синхронизации с внешними системами - модуль уведомлений - модуль бонусной программы - модуль административных настроек -## Общие требования к реализации +## 0.4 Общие принципы работы системы -Система должна быть реализована как единый программный продукт, в котором: +Система должна обеспечивать следующие базовые принципы: -- клиент не видит стоимость товара до обработки заявки менеджером -- менеджер управляет ценой, доставкой и согласованием -- данные по заказам и статусам могут обновляться от внешней системы 1С -- доступ к функциям определяется ролью пользователя -- действия пользователей журналируются +- доступ к функциям и данным определяется ролью пользователя +- клиент работает только в пределах собственных данных и данных своего контрагента +- стоимость товара и условия поставки публикуются только после обработки менеджером +- история изменений по заявкам, заказам и бонусным операциям фиксируется в системе +- сведения о товарах, остатках, заказах и статусах могут обновляться из внешней учетной системы -## Принцип детализации настоящего ТЗ +## 0.5 Содержание технического задания -Настоящий документ описывает не абстрактную концепцию, а конкретный состав продукта. Поэтому дальнейшие разделы фиксируют: - -- реальные модули системы -- реальные действия клиента и менеджера -- реальные данные, подлежащие хранению и отображению -- реальные экранные формы и их состав -- реальные интеграционные требования +1. [Основания для разработки и нормативные материалы](/tz/normative-base) +2. [Назначение и границы программного продукта](/tz/product-scope) +3. [Роли пользователей и права доступа](/tz/roles-access) +4. [Функциональные требования](/tz/functional-requirements) +5. [Требования к данным и интеграциям](/tz/data-integrations) +6. [Нефункциональные требования](/tz/non-functional-requirements) +7. [Экранные формы и прототипы интерфейсов](/tz/stage-1/) +8. [Порядок приемки и состав передаваемых материалов](/tz/acceptance) +9. [Приложение. Текущее состояние программного продукта](/appendix/current-state) diff --git a/docs/tz/acceptance.md b/docs/tz/acceptance.md index 423c16e..70c0a07 100644 --- a/docs/tz/acceptance.md +++ b/docs/tz/acceptance.md @@ -1,72 +1,61 @@ -# 7. Приемка и состав артефактов +# 8. Порядок приемки и состав передаваемых материалов -## 7.1 Общие положения приемки +## 8.1 Общие положения приемки -Приемка должна подтверждать, что разработанный программный продукт соответствует настоящему техническому заданию, договору и спецификации. +Приемка результата работ должна подтверждать соответствие программного продукта требованиям настоящего технического задания, условиям договора и согласованным требованиям заказчика. -При приемке должны проверяться: +При приемке подлежат проверке: -- функциональность клиентского контура -- функциональность менеджерского контура -- работа с каталогом -- работа с заявками на заказ -- работа с заявками на расчет -- работа с заказами -- работа уведомлений -- работа бонусного контура -- работа интеграционного обмена в согласованном объеме +- клиентский контур +- менеджерский контур +- каталог готовой продукции +- сценарии заявок на заказ +- сценарии заявок на расчет +- сопровождение заказов +- уведомления +- бонусный и реферальный контур +- интеграционный обмен в согласованном объеме -## 7.2 Критерии приемки +## 8.2 Критерии приемки -Продукт считается соответствующим требованиям, если: +Программный продукт считается соответствующим требованиям, если: -- все обязательные сценарии выполняются -- роли и права разграничены корректно -- статусы и история изменений отображаются корректно +- обязательные пользовательские сценарии выполняются корректно +- разграничение ролей и прав доступа реализовано корректно +- заявкам, заказам и бонусным операциям присваиваются и отображаются корректные статусы - каталог и остатки отображаются корректно -- клиент не видит цену до публикации условий менеджером -- менеджер может обрабатывать заявки и публиковать условия -- система сохраняет и отображает историю значимых действий +- цена не отображается клиенту до публикации условий менеджером +- менеджер имеет возможность обработать заявку и опубликовать условия +- история изменений сохраняется и доступна в предусмотренных сценариях -## 7.3 Передаваемые артефакты +## 8.3 Состав передаваемых материалов -В состав передаваемых материалов должны входить: +В состав передаваемых заказчику материалов должны входить: -- исходный код всех разработанных компонентов -- перечень используемых сторонних модулей и их версий -- сведения об используемых внешних API -- схемы взаимодействия модулей -- схемы движения данных -- схемы баз данных и связей -- распределение ролей пользователей -- сетевые требования, порты и протоколы -- обучающие материалы -- исходные графические и интерфейсные материалы +- исходный код программного продукта +- техническое задание в согласованной редакции +- сведения об используемых сторонних компонентах и их версиях +- описание реализованных интеграций и используемых внешних интерфейсов +- схемы взаимодействия модулей и движения данных +- описание состава пользовательских ролей и прав доступа +- материалы, необходимые для сопровождения и эксплуатации продукта -## 7.4 Требования к документации +## 8.4 Требования к документации -Документация должна позволять: +Передаваемая документация должна позволять: -- развернуть продукт -- сопровождать продукт -- понимать архитектуру модулей -- понимать состав данных -- понимать состав пользовательских ролей -- понимать сценарии интеграционного обмена +- идентифицировать состав реализованных функций +- понять структуру данных и интеграций +- сопровождать клиентский и менеджерский контуры +- использовать систему в рамках согласованных ролей и сценариев -## 7.5 Требования к фиксации замечаний +## 8.5 Порядок фиксации замечаний -При приемке каждая выявленная проблема должна быть классифицирована по влиянию: +Каждое замечание, выявленное при приемке, должно содержать: -- блокирующий дефект -- критичный дефект -- некритичное замечание -- пожелание к развитию - -Каждое замечание должно иметь: - -- описание -- шаги воспроизведения +- описание проблемы +- сценарий воспроизведения - ожидаемый результат - фактический результат +- уровень критичности - статус устранения diff --git a/docs/tz/data-integrations.md b/docs/tz/data-integrations.md index df3ac5f..ae74a78 100644 --- a/docs/tz/data-integrations.md +++ b/docs/tz/data-integrations.md @@ -1,4 +1,4 @@ -# 5. Данные и интеграции +# 5. Требования к данным и интеграциям ## 5.1 Основные сущности данных @@ -17,27 +17,27 @@ - событие изменения статуса - уведомление - бонусная связь -- бонусная транзакция -- заявка на вывод вознаграждения +- бонусная операция +- заявка на использование либо вывод бонусов ## 5.2 Обязательные данные по сущностям -### Пользователь +### 5.2.1 Пользователь -Обязательные поля: +Обязательные данные: - идентификатор - имя -- email +- адрес электронной почты - телефон - роль - статус учетной записи - связанный контрагент - подключенные каналы уведомлений -### Контрагент +### 5.2.2 Контрагент -Обязательные поля: +Обязательные данные: - идентификатор - наименование компании @@ -47,93 +47,99 @@ - контактные лица - закрепленный менеджер -### Товар +### 5.2.3 Товар -Обязательные поля: +Обязательные данные: - идентификатор - SKU - наименование - тип продукции - набор параметров +- доступные варианты - остатки по складам -- признаки доступности +- признаки доступности и кастомизации -### Заявка на заказ +### 5.2.4 Заявка на заказ -Обязательные поля: +Обязательные данные: - идентификатор - инициатор -- дата создания +- дата и время создания - состав позиций +- параметры позиций - количество - комментарий клиента - статус - закрепленный менеджер - стоимость после обработки -- параметры доставки после обработки +- условия поставки после обработки -### Заявка на расчет +### 5.2.5 Заявка на расчет -Обязательные поля: +Обязательные данные: - идентификатор - инициатор -- дата создания +- дата и время создания - параметры изделия - комментарий клиента - статус - закрепленный менеджер - стоимость после обработки -- параметры доставки после обработки +- условия поставки после обработки -### Заказ +### 5.2.6 Заказ -Обязательные поля: +Обязательные данные: - внутренний идентификатор -- внешний идентификатор 1С +- внешний идентификатор учетной системы - статус -- даты изменений +- даты изменения - состав заказа - стоимость -- доставка -- связанная клиентская заявка +- условия поставки +- ссылка на исходную клиентскую заявку + +### 5.2.7 Бонусная операция + +Обязательные данные: + +- идентификатор операции +- связанный клиент +- тип операции +- сумма или объем операции +- основание операции +- дата и время операции +- текущий статус операции ## 5.3 Требования к данным каталога -Для каждой позиции в каталоге система должна хранить и отображать: +Для каждой позиции и для каждого товарного направления система должна хранить и отображать: -- тип товара -- параметры выбора -- описание параметров +- тип продукции +- доступные параметры выбора +- стандартные значения параметров +- описания параметров +- признаки доступности индивидуальной длины, втулки с логотипом и нанесения надписи +- доступные варианты товара - остатки по складам -- доступные варианты -- признаки кастомизации, если они применимы +- сведения об актуальности данных -## 5.4 Интеграция с 1С +## 5.4 Требования к интеграции с 1С -Интеграция с 1С должна обеспечивать обмен данными о заказах и каталоге. +Интеграция с 1С должна обеспечивать обмен данными, необходимыми для сопровождения каталога и заказов. -### Входящие события +Система должна обеспечивать получение из 1С следующих данных: -Система должна принимать: - -- событие создания заказа -- событие изменения заказа -- событие изменения статуса -- событие изменения доставки -- событие изменения состава или иных параметров - -### Методы получения данных - -Система должна получать: - -- список заказов клиентов - каталог товаров - характеристики товаров -- остатки по складам +- складские остатки +- сведения о заказах +- статусы заказов +- изменения состава, стоимости, доставки и иных существенных параметров заказа ## 5.5 Требования к интеграционному обмену @@ -141,27 +147,29 @@ - сопоставление внутренних идентификаторов и идентификаторов 1С - защиту от дублирования событий -- журналирование входящих событий -- повторную обработку неуспешных событий -- сохранение истории обновлений +- регистрацию входящих и исходящих операций обмена +- повторную обработку неуспешных сообщений +- хранение истории обновлений по интеграционным операциям -## 5.6 Требования к журналированию +## 5.6 Требования к журналированию данных -Для ключевых операций система должна хранить: +Для ключевых действий и изменений система должна сохранять: -- кто инициировал действие -- когда произошло действие -- какой объект был изменен -- какое состояние было до изменения -- какое состояние стало после изменения +- тип объекта +- идентификатор объекта +- предыдущее состояние объекта +- новое состояние объекта +- дату и время изменения +- пользователя либо источник, выполнивший изменение -## 5.7 Бонусные данные +## 5.7 Требования к данным бонусного контура -Для бонусного контура система должна хранить: +Для бонусной и реферальной программы система должна хранить: -- текущий баланс +- текущий бонусный баланс клиента - историю начислений - историю списаний +- историю использования бонусов - реферальные связи -- заявки на вывод -- статус обработки заявок на вывод +- заявки на использование либо вывод бонусов +- статусы обработки таких заявок diff --git a/docs/tz/functional-requirements.md b/docs/tz/functional-requirements.md index 1acab48..2d4c461 100644 --- a/docs/tz/functional-requirements.md +++ b/docs/tz/functional-requirements.md @@ -1,166 +1,181 @@ # 4. Функциональные требования -## 4.1 Авторизация и регистрация +## 4.1 Требования к регистрации и подключению клиентов -Система должна поддерживать два сценария подключения клиента: +Система должна поддерживать два базовых сценария подключения клиента: - регистрация по персональному приглашению -- самостоятельная регистрация через форму +- самостоятельная заявка на подключение -### Требования +Функциональные требования: -1. Менеджер должен иметь возможность отправить клиенту приглашение на email. -2. Клиент должен иметь возможность завершить регистрацию по полученной ссылке. -3. Клиент должен иметь возможность подать самостоятельную заявку на подключение. -4. После самостоятельной регистрации система должна сформировать заявку на рассмотрение менеджером. -5. Менеджер должен иметь возможность approve/reject заявки. -6. При approve система должна отправить клиенту приглашение для завершения регистрации. -7. После завершения регистрации клиент должен получить доступ к кабинету. -8. Клиент должен иметь возможность подключить Telegram и Max как каналы уведомлений. +1. Менеджер должен иметь возможность направить клиенту приглашение на регистрацию по электронной почте. +2. Клиент должен иметь возможность завершить регистрацию по персональной ссылке. +3. Клиент должен иметь возможность подать заявку на подключение через публичную форму. +4. Самостоятельная заявка должна поступать в менеджерский контур на рассмотрение. +5. Менеджер должен иметь возможность подтвердить либо отклонить заявку на подключение. +6. При подтверждении заявки система должна предоставить клиенту возможность завершить регистрацию. +7. После завершения регистрации клиент должен получить доступ к личному кабинету. +8. Система должна поддерживать подключение доступных каналов уведомлений для клиентской учетной записи. -## 4.2 Каталог готовой продукции +## 4.2 Требования к каталогу готовой продукции -Система должна отображать клиенту каталог готовой продукции без отображения цены. +Система должна предоставлять клиенту каталог готовой продукции без отображения цены до обработки менеджером. -### Требования +Функциональные требования: -1. Система должна отображать список типов продукции. -2. Система должна позволять перейти в карточку конкретного типа товара. -3. Система должна отображать параметры выбора товара. -4. Система должна отображать доступные варианты товара. -5. Система должна отображать остатки по складам по каждой позиции. -6. Система должна позволять добавить позицию в корзину. -7. Система не должна отображать стоимость на этапе выбора товара. -8. Система должна отображать текстовые описания параметров и сценариев применения. +1. Система должна отображать список товарных направлений. +2. Для каждого товарного направления система должна предоставлять отдельную карточку товара. +3. В карточке товара система должна отображать параметры выбора, применимые к данному типу продукции. +4. В карточке товара система должна отображать доступные стандартные варианты. +5. Для каждой доступной позиции система должна отображать складские остатки. +6. Система должна позволять клиенту выбрать параметры и добавить позицию в корзину. +7. Система должна исключать отображение стоимости до момента публикации условий менеджером. +8. Для параметров товара система должна отображать пояснения, помогающие клиенту понять назначение параметра и ограничения выбора. -## 4.3 Корзина и заявка на заказ +## 4.3 Требования к параметрам каталога и кастомизации -Система должна позволять клиенту собрать корзину и отправить заявку менеджеру. +Система должна поддерживать настройку параметров по каждому товарному направлению. -### Требования +Функциональные требования: -1. Клиент должен видеть список выбранных позиций. -2. Клиент должен иметь возможность изменить количество. -3. Клиент должен иметь возможность удалить позицию. -4. Клиент должен иметь возможность отправить заявку на заказ. -5. После отправки заявки система должна зафиксировать состав позиций без стоимости. -6. Система должна назначить заявку закрепленному менеджеру. -7. Система должна сохранить время создания заявки и инициатора. +1. Для каждого типа продукции должен задаваться перечень стандартных параметров выбора. +2. Для параметров длины должна поддерживаться настройка доступных стандартных значений. +3. Для параметров длины должна поддерживаться возможность индивидуального значения при наличии соответствующего разрешения. +4. Для параметров втулки должна поддерживаться возможность заказа втулки с логотипом при наличии соответствующего разрешения. +5. Для параметров надписи должна поддерживаться возможность заказа индивидуального нанесения при наличии соответствующего разрешения. +6. Наборы стандартных параметров должны редактироваться в административном контуре. +7. Изменение набора стандартных параметров не должно приводить к потере уже сохраненных заказных данных. -## 4.4 Менеджерская обработка заявки +## 4.4 Требования к корзине и заявке на заказ -Менеджер должен иметь возможность обработать заявку вручную. +Система должна позволять клиенту собрать корзину и направить заявку на заказ. -### Требования +Функциональные требования: -1. Менеджер должен видеть состав заявки. -2. Менеджер должен видеть данные клиента и контрагента. +1. Клиент должен видеть перечень выбранных позиций. +2. Для каждой позиции клиент должен иметь возможность изменить количество. +3. Клиент должен иметь возможность удалить позицию из корзины. +4. Клиент должен иметь возможность направить заявку менеджеру. +5. После отправки заявки система должна зафиксировать состав, параметры и количество позиций. +6. Для заявки должны сохраняться дата создания, инициатор и закрепленный менеджер. +7. До обработки менеджером стоимость в заявке не должна отображаться клиенту. + +## 4.5 Требования к обработке заявки менеджером + +Менеджер должен иметь возможность обработать клиентскую заявку вручную. + +Функциональные требования: + +1. Менеджер должен видеть состав заявки и параметры заказанных позиций. +2. Менеджер должен видеть карточку клиента и сведения о контрагенте. 3. Менеджер должен иметь возможность указать стоимость. -4. Менеджер должен иметь возможность указать параметры доставки. -5. Менеджер должен иметь возможность оставить комментарий. -6. Менеджер должен иметь возможность опубликовать условия клиенту. -7. Менеджер должен иметь возможность повторно изменить условия до перевода заявки в работу. +4. Менеджер должен иметь возможность указать условия поставки и доставки. +5. Менеджер должен иметь возможность оставить комментарий к заявке. +6. Менеджер должен иметь возможность опубликовать согласованные условия клиенту. +7. До перевода заявки в работу менеджер должен иметь возможность скорректировать опубликованные условия. 8. Менеджер должен иметь возможность перевести заявку в работу. -9. Менеджер должен иметь возможность отменить заявку. +9. Менеджер должен иметь возможность отменить заявку с фиксацией основания отмены. -## 4.5 Заявка на расчет +## 4.6 Требования к заявке на расчет индивидуальной продукции -Система должна поддерживать сценарий заявки на расчет индивидуальной продукции. +Система должна поддерживать отдельный сценарий расчета продукции с индивидуальными параметрами. -### Требования +Функциональные требования: -1. Клиент должен иметь возможность перейти в расчетный сценарий, если готовая продукция не подходит. -2. Клиент должен иметь возможность заполнить параметры изделия. -3. Клиент должен иметь возможность отправить заявку на расчет. -4. Менеджер должен иметь возможность обработать заявку на расчет так же, как и заказную заявку. -5. Система должна публиковать стоимость клиенту только после ручной обработки менеджером. +1. Клиент должен иметь возможность перейти из каталога в сценарий расчета индивидуальной продукции. +2. Клиент должен иметь возможность указать параметры изделия. +3. Клиент должен иметь возможность приложить комментарий к заявке. +4. Клиент должен иметь возможность направить заявку менеджеру. +5. Менеджер должен иметь возможность обработать такую заявку по правилам, аналогичным заявке на заказ. +6. Стоимость и условия поставки должны публиковаться клиенту только после ручной обработки менеджером. -### Параметры расчетной заявки - -Минимально система должна поддерживать передачу следующих параметров: +Минимальный состав параметров расчетной заявки должен поддерживать: - тип продукции -- ширина -- длина -- толщина +- ширину +- длину +- толщину - цвет -- микронность или эквивалентный параметр толщины -- специальные параметры в зависимости от типа продукции -- комментарий клиента +- надпись или маркировку +- иные параметры в зависимости от вида продукции +- текстовый комментарий клиента -## 4.6 Статусы заявок +## 4.7 Требования к статусам заявок -Для заявок на заказ и заявок на расчет система должна поддерживать статусы, достаточные для управления процессом. +Система должна обеспечивать сквозное сопровождение заявок по статусам. -Минимально должны быть предусмотрены следующие состояния: +Для заявок на заказ и заявок на расчет должны поддерживаться следующие базовые статусы: - создана -- отправлена менеджеру +- направлена менеджеру - обработана менеджером - условия опубликованы - в работе - отменена -Для каждого изменения статуса система должна фиксировать: +Для каждого изменения статуса система должна сохранять: -- инициатора -- дату и время - предыдущее состояние - новое состояние +- дату и время изменения +- пользователя или источник, выполнивший изменение +- комментарий, если он предусмотрен сценарием -## 4.7 Заказы и сопровождение +## 4.8 Требования к заказам и их сопровождению -Система должна отображать клиенту список заказов и карточку каждого заказа. +Система должна предоставлять клиенту и менеджеру доступ к списку заказов и карточке каждого заказа. -### Требования +Функциональные требования: -1. Система должна отображать список заказов клиента. -2. Система должна поддерживать фильтрацию истории заказов по периоду. -3. Система должна отображать карточку заказа. -4. Система должна отображать актуальный статус заказа. -5. Система должна отображать историю изменений по заказу. -6. Система должна отображать стоимость и параметры доставки, если они доступны. -7. Система должна отображать дату актуальности данных. +1. Система должна отображать перечень заказов клиента. +2. Система должна поддерживать фильтрацию заказов по периоду и статусу. +3. Для каждого заказа система должна предоставлять отдельную карточку. +4. В карточке заказа должны отображаться состав, статус, стоимость, условия поставки и история изменений. +5. В карточке заказа должна отображаться дата актуальности данных. +6. При наличии обновлений из внешней системы сведения по заказу должны синхронизироваться и отображаться пользователю. -## 4.8 Уведомления +## 4.9 Требования к уведомлениям -Система должна поддерживать уведомления по нескольким каналам. +Система должна поддерживать уведомления по нескольким каналам связи. -### Каналы +Поддерживаемые каналы: -- email +- электронная почта - Telegram - Max -### События уведомлений +Система должна поддерживать уведомления по следующим событиям: - приглашение к регистрации -- approve/reject подключения +- подтверждение либо отклонение заявки на подключение - публикация условий по заявке - изменение статуса заказа -- изменения бонусного баланса -- обработка заявки на вывод +- изменение бонусного баланса +- обработка заявки на использование либо вывод бонусов -## 4.9 Бонусная программа +## 4.10 Требования к бонусной и реферальной программе -Система должна поддерживать бонусный контур как полноценную функциональную область продукта. +Система должна включать бонусный контур как самостоятельную функциональную область. -### Требования +Функциональные требования: -1. Менеджер должен иметь возможность создавать реферальные связи. -2. Система должна хранить бонусные начисления и списания. -3. Клиент должен видеть текущий бонусный баланс. -4. Клиент должен видеть историю бонусных операций. -5. Клиент должен иметь возможность использовать бонусы в рамках правил программы. -6. Клиент должен иметь возможность подать заявку на вывод при достижении минимального порога. -7. Менеджер должен иметь возможность обрабатывать заявку на вывод. -8. Система должна уведомлять клиента об изменениях бонусного состояния. +1. Система должна хранить правила участия клиента в бонусной программе. +2. Система должна поддерживать фиксацию реферальных связей. +3. Система должна хранить начисления, списания и текущий остаток бонусов. +4. Клиент должен видеть текущий бонусный баланс. +5. Клиент должен видеть историю бонусных операций. +6. Клиент должен иметь возможность использовать бонусы в пределах установленных правил. +7. Клиент должен иметь возможность подать заявку на вывод либо иную операцию, если это предусмотрено правилами программы. +8. Менеджер должен иметь возможность обрабатывать операции бонусного контура. +9. Система должна уведомлять клиента об изменениях бонусного состояния. -## 4.10 Административные настройки +## 4.11 Требования к административным настройкам -Система должна предоставлять административные разделы для управления: +Система должна содержать административные разделы для управления следующими объектами: - параметрами каталога +- пользовательскими описаниями параметров - шаблонами уведомлений - параметрами синхронизации -- бонусным контуром в разрешенной части +- отдельными настройками бонусного контура diff --git a/docs/tz/index.md b/docs/tz/index.md index d9d4c77..24dc131 100644 --- a/docs/tz/index.md +++ b/docs/tz/index.md @@ -1,62 +1,18 @@ -# Техническое задание +# Разделы технического задания -## Статус документа +Настоящий раздел содержит полный состав технического задания на разработку программного продукта `Личный кабинет Фрегат`. -Документ является рабочим черновиком ТЗ на программный продукт `Личный кабинет Фрегат` по договору на разработку программного продукта №28/04-26ПО от 28 апреля 2026 года. +## Содержание -Текущая редакция предназначена для: +1. [Основания для разработки и нормативные материалы](/tz/normative-base) +2. [Назначение и границы программного продукта](/tz/product-scope) +3. [Роли пользователей и права доступа](/tz/roles-access) +4. [Функциональные требования](/tz/functional-requirements) +5. [Требования к данным и интеграциям](/tz/data-integrations) +6. [Нефункциональные требования](/tz/non-functional-requirements) +7. [Экранные формы и прототипы интерфейсов](/tz/stage-1/) +8. [Порядок приемки и состав передаваемых материалов](/tz/acceptance) -- фиксации объема продукта -- декомпозиции работ по этапам -- согласования первого этапа UX/UI -- подготовки формального комплекта материалов для заказчика +## Назначение раздела -## Основания для разработки - -Разработка ведется на основании следующих документов: - -- договор на разработку программного продукта №28/04-26ПО от 28 апреля 2026 года -- приложение №1 к договору: спецификация `Основные требования к программному обеспечению "Личный кабинет Фрегат"` -- текущая кодовая база `apollo-backend` и `web-frontend` - -## Цель продукта - -Создать единый B2B личный кабинет для клиентов и сотрудников ООО `Фрегат Групп`, который обеспечивает: - -- регистрацию и подключение клиентов -- выбор готовой продукции -- оформление заявок на заказ и на расчет -- обработку заявок менеджером -- сопровождение заказа по статусам -- уведомления по email и в мессенджеры -- отображение истории заказов, задолженности и бонусной информации - -## Границы текущего ТЗ - -В рамках этого документа описываются: - -- клиентский веб-интерфейс -- менеджерский веб-интерфейс -- основные сущности и данные -- обмен данными с 1С -- приемка по этапам -- состав документации, подлежащей передаче заказчику - -Не входят в предмет этой редакции: - -- точные payload-схемы webhooks от 1С -- детальная сетевая схема production-контура -- финансовая модель бонусной программы в части бухгалтерских расчетов - -## Структура этапов - -- Этап 1: согласование UX/UI на ограниченном наборе ключевых страниц -- Этап 2: реализация полного функционала без интеграции с 1С -- Этап 3: подключение, настройка и отладка интеграции с 1С - -## Что должно получиться после согласования этой версии - -- утвержденный каркас полного ТЗ -- подтвержденный состав экранов и сценариев -- согласованный объем первого этапа -- перечень открытых вопросов, которые нужно добрать до финальной редакции +Материалы раздела используются для согласования требований к программному продукту, его функциям, данным, интерфейсам, интеграциям и условиям приемки. diff --git a/docs/tz/non-functional-requirements.md b/docs/tz/non-functional-requirements.md new file mode 100644 index 0000000..ef27dea --- /dev/null +++ b/docs/tz/non-functional-requirements.md @@ -0,0 +1,69 @@ +# 6. Нефункциональные требования + +## 6.1 Общие требования к архитектуре + +Программный продукт должен быть реализован как веб-система с разделением клиентского и менеджерского контуров, серверной бизнес-логикой, постоянным хранением данных и возможностью интеграционного обмена с внешними системами. + +## 6.2 Требования к доступности интерфейсов + +Система должна обеспечивать корректную работу: + +- в десктопных браузерах +- в мобильных браузерах +- на основных пользовательских разрешениях экрана + +Интерфейсы должны сохранять работоспособность и читаемость при адаптивном отображении. + +## 6.3 Требования к производительности + +При штатной эксплуатации система должна обеспечивать: + +- приемлемое время открытия основных экранов +- приемлемое время отправки заявок и выполнения пользовательских действий +- отображение каталогов, карточек и заказов без заметных задержек при типовом объеме данных + +Точные количественные показатели производительности подлежат фиксации в рабочей документации по инфраструктуре и тестированию. + +## 6.4 Требования к безопасности + +Система должна обеспечивать: + +- аутентификацию пользователей +- авторизацию по ролям +- ограничение доступа клиента только к данным своего контрагента +- хранение и передачу чувствительных данных с использованием защищенных механизмов +- исключение несанкционированного доступа к административным функциям + +## 6.5 Требования к надежности и журналированию + +Система должна обеспечивать: + +- сохранность пользовательских данных +- сохранность истории изменений по заявкам, заказам и бонусным операциям +- фиксацию ошибок интеграционного обмена +- фиксацию значимых системных и пользовательских событий + +## 6.6 Требования к сопровождаемости + +Реализация должна обеспечивать возможность: + +- сопровождения и развития клиентского контура +- сопровождения и развития менеджерского контура +- изменения параметров каталога и уведомлений без переработки базовой структуры системы +- расширения интеграционного обмена с 1С и иными внешними системами + +## 6.7 Требования к данным и актуальности сведений + +Система должна обеспечивать: + +- хранение актуального состояния пользовательских данных +- отображение даты актуальности сведений, полученных из внешних систем, когда это применимо +- защиту от потери данных при обновлении параметров каталога и заказных сущностей + +## 6.8 Требования к документации + +По результатам выполнения работ должна быть сформирована документация, достаточная для: + +- приемки результата работ +- дальнейшего сопровождения программного продукта +- понимания состава функций, данных, ролей и интеграций diff --git a/docs/tz/normative-base.md b/docs/tz/normative-base.md index 3bc3396..944d955 100644 --- a/docs/tz/normative-base.md +++ b/docs/tz/normative-base.md @@ -1,58 +1,39 @@ -# Нормативная база и формат ТЗ +# 1. Основания для разработки и нормативные материалы -## Базовый стандарт +## 1.1 Основания для разработки -Структура настоящего ТЗ ориентирована на `ГОСТ 19.201-78` как на базовый стандарт для технического задания на программный продукт. +Разработка программного продукта выполняется на основании следующих документов: -В практической части документ адаптирован под современную веб-разработку, потому что продукт: +- договор на разработку программного продукта №28/04-26ПО от 28 апреля 2026 года +- приложение №1 к договору: спецификация основных требований к программному обеспечению `Личный кабинет Фрегат` +- согласованные требования заказчика к клиентскому, менеджерскому, бонусному и интеграционному контурам +- действующее состояние клиентской и серверной кодовой базы, используемое как фактическая основа для детализации требований -- является B2B веб-системой -- включает несколько ролей и интерфейсов -- зависит от внешних интеграций -- разрабатывается поэтапно +## 1.2 Нормативные и методические материалы -## Принцип адаптации ГОСТ +При подготовке настоящего технического задания используется структура технической документации, соответствующая общепринятой практике составления ТЗ на программные продукты, включая подходы, применяемые в `ГОСТ 19.201-78`. -Мы не копируем ГОСТ механически, а используем его как каркас. Поэтому в ТЗ оставляем обязательную инженерную логику: +Настоящий документ устанавливает требования к программному продукту применительно к современному веб-решению с разграничением ролей, интеграцией с учетной системой, журналированием событий и поддержкой клиентских и менеджерских сценариев. -- основания для разработки -- назначение продукта -- требования к продукту -- требования к данным и документации -- этапы разработки -- порядок приемки +## 1.3 Исходные материалы для детализации требований -И дополняем это современными разделами: +При разработке технического задания использованы следующие исходные материалы: -- user flow -- экранная карта -- роли и права -- интеграции и события -- статусы бизнес-процессов -- UX/UI-этап как отдельный приемочный блок +- договорная документация заказчика +- согласованные бизнес-сценарии работы клиента и менеджера +- перечень разделов личного кабинета +- перечень основных товарных направлений и параметров каталога +- реализованные интерфейсные формы и сущности текущей версии продукта +- требования к обмену данными с учетной системой 1С +- требования к уведомлениям, бонусной программе и административным настройкам -## Разделы, которые должны быть в финальном ТЗ +## 1.4 Назначение настоящего документа -Финальная редакция ТЗ должна включать: +Настоящий документ предназначен для: -1. Основания для разработки -2. Назначение и цели продукта -3. Объект автоматизации и границы системы -4. Состав ролей и прав доступа -5. Функциональные требования -6. Нефункциональные требования -7. Требования к данным и интеграциям -8. Требования к документации и передаваемым материалам -9. Этапы выполнения работ -10. Критерии приемки -11. Приложения - -## Что еще нужно будет приложить к финальной версии - -- карта экранов -- перечень статусов и переходов -- перечень сущностей и их полей -- описание уведомлений -- список интеграционных точек с 1С -- перечень страниц Этапа 1 -- список артефактов, передаваемых заказчику по результату +- фиксации полного объема требований к программному продукту +- определения состава реализуемых функций +- определения состава данных и интеграционных точек +- определения требований к пользовательским и административным интерфейсам +- определения критериев приемки результата работ +- определения состава артефактов, передаваемых заказчику diff --git a/docs/tz/product-scope.md b/docs/tz/product-scope.md index 76d98aa..6eeab48 100644 --- a/docs/tz/product-scope.md +++ b/docs/tz/product-scope.md @@ -1,108 +1,97 @@ -# 2. Назначение и границы продукта +# 2. Назначение и границы программного продукта ## 2.1 Назначение системы -`Личный кабинет Фрегат` предназначен для переноса клиентского B2B взаимодействия из разрозненной переписки и ручного обмена файлами в единый веб-интерфейс. +Программный продукт `Личный кабинет Фрегат` предназначен для организации единого цифрового канала взаимодействия между ООО `Фрегат Групп` и клиентами компании. -Система должна обеспечить: +Система должна обеспечивать: -- единый вход клиента в процессы компании -- цифровой выбор готовой продукции -- цифровую отправку заявок на заказ и расчет -- ручное согласование коммерческих условий менеджером -- прозрачное сопровождение заказа по статусам -- уведомление клиента о значимых изменениях +- подключение новых клиентов и ведение клиентских учетных записей +- предоставление клиенту каталога готовой продукции без публичного отображения цены +- прием заявок на заказ готовой продукции +- прием заявок на расчет продукции с индивидуальными параметрами +- обработку заявок менеджером с публикацией стоимости и условий поставки +- сопровождение заказов по статусам +- информирование клиентов о значимых изменениях +- ведение бонусной и реферальной программы -## 2.2 Границы продукта +## 2.2 Границы программного продукта -Продукт охватывает следующие функциональные области: +В состав программного продукта входят следующие функциональные области: - регистрация и подключение клиента +- профиль клиента и данные компании - каталог готовой продукции - карточка товара и выбор параметров -- корзина и отправка заявки на заказ -- заявка на расчет кастомной продукции -- менеджерская обработка заявок -- карточка заказа и история заказов -- уведомления -- бонусная и реферальная программа -- административные настройки - -Продукт не предназначен для: - -- самостоятельного расчета цены клиентом -- бухгалтерского учета -- публичной B2C торговли -- самостоятельного изменения клиентом бизнес-правил компании - -## 2.3 Пользовательские контуры - -### Клиентский контур - -Клиентский контур должен включать: - -- вход и завершение регистрации -- профиль компании -- каталог продукции -- карточку товара -- корзину -- список заявок и заказов -- карточку заказа +- корзина и заявка на заказ +- заявка на расчет индивидуальной продукции +- обработка заявок менеджером +- список заказов и карточка заказа - уведомления - бонусный кабинет - -### Менеджерский контур - -Менеджерский контур должен включать: - -- обработку заявок на подключение -- обработку заказных заявок -- обработку расчетных заявок -- работу с клиентами -- работу с заказами -- бонусные операции - административные настройки -## 2.4 Основные бизнес-сценарии +## 2.3 Функции, не входящие в состав программного продукта -### Сценарий А. Подключение нового клиента +Программный продукт не предназначен для выполнения следующих функций: -1. Клиент получает приглашение от менеджера или самостоятельно подает заявку на подключение. -2. Менеджер проверяет данные клиента. -3. Менеджер принимает решение approve/reject. -4. При approve система отправляет клиенту ссылку для завершения регистрации. -5. Клиент завершает регистрацию и получает доступ в кабинет. +- самостоятельного ценообразования клиентом +- ведения бухгалтерского учета +- выполнения функций публичного B2C-магазина +- прямого редактирования клиентом внутренних бизнес-правил компании +- замены учетной системы 1С как первичного источника учетных данных -### Сценарий Б. Заказ готовой продукции +## 2.4 Пользовательские контуры + +В системе должны быть предусмотрены следующие пользовательские контуры: + +- клиентский контур +- менеджерский контур +- административный контур суперменеджера + +Клиентский контур предназначен для работы клиента с каталогом, заявками, заказами, уведомлениями и бонусным кабинетом. + +Менеджерский контур предназначен для обработки клиентских заявок, публикации коммерческих условий, сопровождения заказов, работы с клиентскими карточками и бонусными операциями. + +Административный контур предназначен для управления настройками каталога, уведомлений, интеграционных параметров и отдельных сервисных настроек системы. + +## 2.5 Основные бизнес-сценарии + +### 2.5.1 Подключение клиента + +1. Потенциальный клиент получает приглашение на регистрацию либо подает заявку на подключение самостоятельно. +2. Менеджер проверяет сведения о клиенте и принимает решение о подтверждении либо отклонении заявки. +3. При положительном решении клиенту предоставляется доступ к завершению регистрации. +4. После завершения регистрации клиент получает доступ к личному кабинету. + +### 2.5.2 Заказ готовой продукции 1. Клиент открывает каталог готовой продукции. -2. Клиент выбирает тип товара. +2. Клиент выбирает товарное направление. 3. Клиент выбирает параметры товара. -4. Клиент видит доступные варианты и остатки по складам. -5. Клиент добавляет позиции в корзину. -6. Клиент отправляет заявку без цены. -7. Менеджер указывает стоимость и условия доставки. -8. Клиент получает обновленные условия и принимает решение. +4. Клиент просматривает доступные варианты и остатки. +5. Клиент добавляет выбранные позиции в корзину. +6. Клиент отправляет заявку на заказ. +7. Менеджер указывает стоимость, условия поставки и комментарий. +8. Система публикует обновленные условия клиенту. -### Сценарий В. Заявка на расчет +### 2.5.3 Заявка на расчет индивидуальной продукции -1. Клиент понимает, что готовый товар не подходит под задачу. -2. Клиент переходит в режим расчета. -3. Клиент заполняет параметры изделия. -4. Клиент отправляет заявку на расчет. -5. Менеджер указывает стоимость и условия доставки. -6. Клиент получает расчет и может продолжить работу по заявке. +1. Клиент переходит в режим расчета индивидуальной продукции. +2. Клиент указывает параметры требуемого изделия. +3. Клиент направляет заявку менеджеру. +4. Менеджер подготавливает коммерческие условия и публикует их клиенту. -### Сценарий Г. Сопровождение заказа +### 2.5.4 Сопровождение заказа -1. Заказ создается и получает статус. -2. Изменения по заказу поступают в систему. -3. Клиент видит актуальный статус и обновленные данные. -4. Система отправляет уведомления клиенту. +1. Заказ получает уникальный идентификатор и статус. +2. Данные по заказу обновляются в системе по мере обработки. +3. Клиент отслеживает состав, статус, сроки и иные существенные сведения. +4. При изменении статуса либо условий система направляет уведомления. -### Сценарий Д. Бонусная программа +### 2.5.5 Бонусная и реферальная программа -1. Менеджер создает или поддерживает реферальную связь. -2. Система отражает бонусные начисления и изменения баланса. -3. Клиент видит бонусный баланс и историю операций. -4. Клиент может использовать бонусы или подать заявку на вывод в рамках правил программы. +1. Для клиента фиксируются правила участия в бонусной программе и, при наличии, реферальные связи. +2. Система ведет учет начислений, списаний и остатка бонусов. +3. Клиент получает доступ к истории бонусных операций. +4. Менеджер обрабатывает заявки, связанные с использованием либо выводом бонусов, в пределах установленных правил. diff --git a/docs/tz/roles-access.md b/docs/tz/roles-access.md index d68582a..bd0fdf7 100644 --- a/docs/tz/roles-access.md +++ b/docs/tz/roles-access.md @@ -1,64 +1,64 @@ -# 3. Роли и права доступа +# 3. Роли пользователей и права доступа ## 3.1 Состав ролей -В системе должны быть предусмотрены следующие базовые роли: +В системе должны быть предусмотрены следующие роли пользователей: - клиент - менеджер - суперменеджер -## 3.2 Роль `Клиент` +## 3.2 Роль клиента -Клиент представляет организацию-контрагента и работает только в рамках данных своей компании. +Пользователь с ролью `Клиент` представляет организацию-контрагента и работает только с данными своей компании. -Клиент должен иметь возможность: +Клиенту должны быть доступны следующие действия: -- завершить регистрацию по приглашению -- подать заявку на подключение -- просматривать и редактировать собственные профильные данные в разрешенной части -- подключать каналы уведомлений -- работать с каталогом готовой продукции -- добавлять товары в корзину -- отправлять заявку на заказ -- отправлять заявку на расчет -- просматривать список своих заказов -- просматривать карточку заказа -- просматривать уведомления -- просматривать бонусный баланс и историю операций -- подавать заявку на вывод, если это разрешено правилами программы +- завершение регистрации по персональному приглашению +- подача заявки на подключение +- просмотр и изменение разрешенных профильных данных +- подключение доступных каналов уведомлений +- просмотр каталога готовой продукции +- выбор параметров товара +- добавление позиций в корзину +- отправка заявки на заказ +- отправка заявки на расчет +- просмотр списка заявок и заказов +- просмотр карточки заявки и карточки заказа +- просмотр истории уведомлений +- просмотр бонусного баланса и истории бонусных операций +- подача заявки на использование либо вывод бонусов при наличии соответствующих правил -## 3.3 Роль `Менеджер` +## 3.3 Роль менеджера -Менеджер представляет сотрудника компании, закрепленного за клиентами. +Пользователь с ролью `Менеджер` представляет сотрудника компании, закрепленного за клиентами. -Менеджер должен иметь возможность: +Менеджеру должны быть доступны следующие действия: -- рассматривать заявки на подключение -- approve/reject регистрацию клиента -- привязывать клиента к контрагенту -- получать заявки на заказ -- получать заявки на расчет -- указывать стоимость -- указывать параметры доставки -- публиковать условия клиенту -- переводить заявку в работу -- отменять заявку -- просматривать карточки клиентов -- просматривать карточки заказов -- работать с бонусными связями и заявками на вывод +- рассмотрение заявок на подключение клиентов +- подтверждение либо отклонение заявок на подключение +- привязка клиента к контрагенту и назначение ответственного сопровождения +- просмотр и обработка заявок на заказ +- просмотр и обработка заявок на расчет +- указание стоимости, условий поставки и сопроводительного комментария +- публикация условий клиенту +- перевод заявки в работу +- отмена заявки при наличии оснований +- просмотр карточек клиентов, заявок и заказов +- выполнение операций в бонусном контуре в пределах полномочий -## 3.4 Роль `Суперменеджер` +## 3.4 Роль суперменеджера -Суперменеджер является расширенной административной ролью. +Пользователь с ролью `Суперменеджер` обладает всеми правами менеджера и дополнительными административными полномочиями. -Суперменеджер должен иметь все права менеджера, а также дополнительно: +Суперменеджеру должны быть доступны следующие действия: -- доступ ко всем клиентам и всем заказам -- управление настройками каталога +- доступ ко всем клиентам, заявкам и заказам +- управление параметрами каталога +- управление описаниями и наборами параметров товаров - управление настройками уведомлений -- управление настройками синхронизации -- расширенный доступ к бонусному контуру +- управление параметрами интеграции и синхронизации +- расширенное управление бонусным и реферальным контуром ## 3.5 Матрица доступа @@ -67,23 +67,24 @@ | Завершение регистрации | Да | Нет | Нет | | Подача заявки на подключение | Да | Нет | Нет | | Просмотр каталога | Да | Да | Да | -| Добавление товара в корзину | Да | Нет | Нет | +| Выбор параметров и добавление в корзину | Да | Нет | Нет | | Отправка заявки на заказ | Да | Нет | Нет | | Отправка заявки на расчет | Да | Нет | Нет | -| Указание стоимости и доставки | Нет | Да | Да | +| Назначение стоимости и условий поставки | Нет | Да | Да | | Публикация условий клиенту | Нет | Да | Да | -| Перевод заявки в работу | Да | Да | Да | -| Отмена заявки | Да | Да | Да | -| Управление настройками каталога | Нет | Нет | Да | -| Управление настройками уведомлений | Нет | Нет | Да | -| Управление синхронизацией | Нет | Нет | Да | +| Перевод заявки в работу | Нет | Да | Да | +| Отмена заявки | Нет | Да | Да | +| Управление параметрами каталога | Нет | Нет | Да | +| Управление уведомлениями | Нет | Нет | Да | +| Управление параметрами синхронизации | Нет | Нет | Да | +| Управление бонусными правилами | Нет | Да | Да | -## 3.6 Ограничения и безопасность доступа +## 3.6 Ограничения доступа и требования к безопасности Система должна обеспечивать: -- раздельные интерфейсы клиента и менеджера -- доступ клиента только к собственному контрагенту и его объектам -- ограничение административных функций по ролям -- журналирование действий пользователя -- возможность аудита изменения статусов и условий заявок +- раздельные интерфейсы для клиентского и менеджерского контуров +- доступ клиента только к данным собственного контрагента +- ограничение административных функций в соответствии с ролью +- журналирование значимых пользовательских действий +- хранение истории изменения статусов, условий заявок и бонусных операций diff --git a/docs/tz/stage-1/index.md b/docs/tz/stage-1/index.md index 308d05c..646ae8e 100644 --- a/docs/tz/stage-1/index.md +++ b/docs/tz/stage-1/index.md @@ -1,204 +1,236 @@ -# 6. Экранные формы и текстовые прототипы +# 7. Экранные формы и прототипы интерфейсов -## 6.1 Общие требования к экранным формам +## 7.1 Общие требования к экранным формам -Экранные формы должны обеспечивать понятную навигацию, читаемое отображение статусов, явное разделение клиентского и менеджерского контура и однозначную привязку действий к текущему объекту. +Экранные формы должны обеспечивать: -Для всех ключевых форм должны выполняться требования: +- однозначное понимание текущего объекта работы +- явное отображение статуса объекта +- соответствие доступных действий роли пользователя +- единый визуальный подход для клиентского и менеджерского контуров +- понятное отображение параметров товара, условий заказа и бонусных операций -- на экране должен быть понятен текущий объект работы -- должен быть виден текущий статус объекта -- действия пользователя должны соответствовать роли и статусу объекта -- клиент не должен видеть стоимость до публикации условий менеджером -- остатки по складам должны отображаться в наглядном виде +Для экранов, связанных с товарами, заявками и заказами, должны выполняться дополнительные требования: -## 6.2 Клиентские формы +- цена не отображается клиенту до публикации условий менеджером +- остатки и доступные варианты отображаются в наглядном виде +- пользователь понимает ограничения выбора и возможность кастомизации -### 6.2.1 Главная страница клиента +## 7.2 Клиентские экранные формы -Назначение: +### 7.2.1 Главная страница клиента -- входная точка в систему -- доступ к основным разделам -- отображение важных текущих событий +Назначение страницы: -Состав: +- вход в основные разделы личного кабинета +- отображение актуальных действий и событий -- шапка с навигацией -- блок быстрых переходов -- блок актуальных заказов +Состав страницы: + +- верхняя навигация +- быстрые переходы по основным разделам +- блок актуальных заказов и заявок - блок последних уведомлений +- блок бонусной информации при наличии подключенного бонусного контура Прототип: ```text -+-------------------------------------------------------------+ -| Header: каталог | заказы | уведомления | бонусы | профиль | -+-------------------------------------------------------------+ -| Быстрые действия | -| [Каталог] [Мои заказы] [Бонусы] [Профиль] | -+-------------------------------------------------------------+ -| Актуальные заказы | -| № | статус | дата | действие | -+-------------------------------------------------------------+ -| Последние уведомления | -+-------------------------------------------------------------+ ++------------------------------------------------------------------+ +| Header: Каталог | Заказы | Уведомления | Бонусы | Профиль | ++------------------------------------------------------------------+ +| Быстрые действия | +| [Каталог] [Мои заказы] [Заявка на расчет] [Бонусы] [Профиль] | ++------------------------------------------------------------------+ +| Актуальные заказы и заявки | +| № | Тип | Статус | Дата | Действие | ++------------------------------------------------------------------+ +| Последние уведомления | ++------------------------------------------------------------------+ ``` -### 6.2.2 Каталог продукции +### 7.2.2 Каталог продукции -Назначение: +Назначение страницы: -- показать доступные товарные направления -- дать переход в карточку типа товара +- отображение товарных направлений +- переход к карточке выбранного типа товара -Состав: +Состав страницы: -- поиск -- сетка карточек типов продукции +- заголовок раздела +- поиск при необходимости +- сетка карточек товарных направлений -### 6.2.3 Карточка типа товара +### 7.2.3 Карточка товара -Назначение: +Назначение страницы: - выбор параметров товара -- просмотр остатков и доступных вариантов -- добавление в корзину +- просмотр стандартных вариантов +- просмотр складских остатков +- добавление выбранной позиции в корзину -Состав: +Состав страницы: -- заголовок -- изображение -- блок параметров -- блок описания параметров -- SKU выбранной позиции -- действие `В корзину` +- заголовок товара +- изображение товара +- блок выбора параметров +- блок пояснений по параметрам +- блок индивидуальных возможностей, если они разрешены +- блок добавления в корзину - таблица доступных вариантов Прототип: ```text -+-------------------------------------------------------------+ -| Назад | Тип товара | -+-------------------------------------------------------------+ -| Изображение | Параметры выбора | SKU / В корзину | -| | ширина | | -| | длина | | -| | толщина | | -| | цвет / надпись | | -+-------------------------------------------------------------+ -| Таблица доступных вариантов | -| SKU | ширина | длина | толщина | остатки | действие | -+-------------------------------------------------------------+ ++------------------------------------------------------------------+ +| Назад | +| Алюминиевый скотч | ++------------------------------------------------------------------+ +| Изображение товара | Выбор параметров | +| | ширина / длина / толщина | +| | цвет / надпись / доп. условия | +| | [В корзину] | ++------------------------------------------------------------------+ +| Пояснения по параметрам | +| Длина указывается в метрах. При наличии разрешения допускается | +| заказ индивидуального значения в согласованных пределах. | ++------------------------------------------------------------------+ +| Доступные варианты | +| SKU | Параметры | Остаток | Доступность | Действие | ++------------------------------------------------------------------+ ``` -### 6.2.4 Корзина +### 7.2.4 Корзина -Назначение: +Назначение страницы: -- проверка состава заказа -- корректировка количества -- отправка заявки +- просмотр выбранных позиций +- изменение количества +- удаление позиции +- отправка заявки на заказ -### 6.2.5 Карточка заявки / заказа +Состав страницы: -Назначение: +- список позиций +- параметры и количество +- комментарий клиента +- действие отправки заявки -- отображение состава, статуса, стоимости, доставки и истории +### 7.2.5 Карточка заявки или заказа + +Назначение страницы: + +- просмотр состава +- просмотр статуса +- просмотр стоимости и условий поставки после публикации +- просмотр истории изменений Прототип: ```text -+-------------------------------------------------------------+ -| № заявки / заказа | Статус | -+-------------------------------------------------------------+ -| Состав | -+-------------------------------------------------------------+ -| Стоимость и доставка | -+-------------------------------------------------------------+ -| История изменений | -+-------------------------------------------------------------+ -| [Отправить в работу] [Отменить] | -+-------------------------------------------------------------+ ++------------------------------------------------------------------+ +| Номер заявки или заказа | Статус | ++------------------------------------------------------------------+ +| Состав позиции | ++------------------------------------------------------------------+ +| Стоимость и условия поставки | ++------------------------------------------------------------------+ +| История изменений | ++------------------------------------------------------------------+ ``` -### 6.2.6 Список заказов +### 7.2.6 Список заказов -Назначение: +Назначение страницы: - просмотр текущих и архивных заказов -- фильтрация по периоду +- фильтрация по периоду и статусу -### 6.2.7 Уведомления +### 7.2.7 Уведомления -Назначение: +Назначение страницы: -- просмотр истории уведомлений по всем объектам +- просмотр истории уведомлений по заказам, заявкам и бонусным операциям -### 6.2.8 Бонусный кабинет +### 7.2.8 Бонусный кабинет -Назначение: +Назначение страницы: -- просмотр бонусного баланса +- просмотр текущего бонусного баланса - просмотр истории операций -- выполнение действий в рамках бонусной программы +- инициирование действий, допускаемых правилами бонусной программы -## 6.3 Менеджерские формы +Состав страницы: -### 6.3.1 Список клиентов +- текущий баланс +- история начислений и списаний +- связанные реферальные сведения +- форма подачи заявки на использование либо вывод бонусов -Назначение: +## 7.3 Менеджерские экранные формы -- просмотр клиентов -- переход в карточку клиента +### 7.3.1 Список клиентов -### 6.3.2 Карточка клиента +Назначение страницы: -Назначение: +- просмотр клиентской базы +- переход в карточку конкретного клиента -- просмотр компании, заявок, заказов и бонусных связей +### 7.3.2 Карточка клиента -### 6.3.3 Карточка обработки заявки +Назначение страницы: -Назначение: +- просмотр сведений о компании +- просмотр истории заявок и заказов +- просмотр бонусных и реферальных данных -- ввод стоимости и доставки +### 7.3.3 Карточка обработки заявки + +Назначение страницы: + +- просмотр состава заявки +- ввод коммерческих условий - публикация условий клиенту -- управление статусом +- перевод заявки в работу либо отмена Прототип: ```text -+-------------------------------------------------------------+ -| Клиент | Контрагент | Менеджер | -+-------------------------------------------------------------+ -| Состав заявки / параметры изделия | -+-------------------------------------------------------------+ -| Стоимость | -| Доставка | -| Комментарий менеджера | -+-------------------------------------------------------------+ -| [Опубликовать условия] [В работу] [Отменить] | -+-------------------------------------------------------------+ ++------------------------------------------------------------------+ +| Клиент | Контрагент | Ответственный менеджер | ++------------------------------------------------------------------+ +| Состав заявки или параметры индивидуального изделия | ++------------------------------------------------------------------+ +| Стоимость | +| Условия поставки и доставки | +| Комментарий менеджера | ++------------------------------------------------------------------+ +| [Опубликовать условия] [Перевести в работу] [Отменить] | ++------------------------------------------------------------------+ ``` -### 6.3.4 Список заказов менеджера +### 7.3.4 Список заказов менеджера -Назначение: +Назначение страницы: - просмотр заказов по клиентам -- контроль текущих статусов +- контроль статусов +- переход в карточку заказа -### 6.3.5 Настройки каталога +### 7.3.5 Настройки каталога -Назначение: +Назначение страницы: -- управление параметрами типов продукции -- управление описаниями и вариантами +- управление параметрами товарных направлений +- управление стандартными значениями параметров +- управление возможностями кастомизации +- управление описаниями параметров -### 6.3.6 Настройки уведомлений и синхронизации +### 7.3.6 Настройки уведомлений и синхронизации -Назначение: +Назначение страницы: -- управление шаблонами сообщений -- управление параметрами обмена +- управление шаблонами уведомлений +- управление параметрами интеграционного обмена