Expand technical specification content
This commit is contained in:
Ruslan Bakiev
@@ -1,34 +1,32 @@
|
|||||||
import { defineConfig } from 'vitepress';
|
import { defineConfig } from 'vitepress';
|
||||||
|
|
||||||
export default defineConfig({
|
export default defineConfig({
|
||||||
title: 'Фрегат ЛК',
|
title: 'Техническое задание',
|
||||||
description: 'Техническое задание на разработку личного кабинета Фрегат',
|
description: 'Техническое задание на разработку личного кабинета Фрегат',
|
||||||
lang: 'ru-RU',
|
lang: 'ru-RU',
|
||||||
cleanUrls: true,
|
cleanUrls: true,
|
||||||
themeConfig: {
|
themeConfig: {
|
||||||
nav: [
|
nav: [
|
||||||
{ text: 'ТЗ', link: '/tz/' },
|
{ text: 'Техническое задание', link: '/' },
|
||||||
{ text: 'Этап 1', link: '/tz/stage-1/' },
|
|
||||||
{ text: 'Текущее состояние', link: '/appendix/current-state' },
|
|
||||||
],
|
],
|
||||||
sidebar: [
|
sidebar: [
|
||||||
{
|
{
|
||||||
text: 'Техническое задание',
|
text: 'Техническое задание',
|
||||||
items: [
|
items: [
|
||||||
{ text: 'Обзор', link: '/tz/' },
|
{ text: '0. Общие положения', link: '/' },
|
||||||
{ text: 'Нормативная база', link: '/tz/normative-base' },
|
{ text: '1. Основания и нормативная база', link: '/tz/normative-base' },
|
||||||
{ text: 'Контур продукта', link: '/tz/product-scope' },
|
{ text: '2. Назначение и границы продукта', link: '/tz/product-scope' },
|
||||||
{ text: 'Роли и доступ', link: '/tz/roles-access' },
|
{ text: '3. Роли и права доступа', link: '/tz/roles-access' },
|
||||||
{ text: 'Функциональные требования', link: '/tz/functional-requirements' },
|
{ text: '4. Функциональные требования', link: '/tz/functional-requirements' },
|
||||||
{ text: 'Данные и интеграции', link: '/tz/data-integrations' },
|
{ text: '5. Данные и интеграции', link: '/tz/data-integrations' },
|
||||||
{ text: 'Этап 1 (UX/UI)', link: '/tz/stage-1/' },
|
{ text: '6. Экранные формы и текстовые прототипы', link: '/tz/stage-1/' },
|
||||||
{ text: 'Приемка и артефакты', link: '/tz/acceptance' },
|
{ text: '7. Приемка и состав артефактов', link: '/tz/acceptance' },
|
||||||
],
|
],
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
text: 'Приложения',
|
text: 'Приложения',
|
||||||
items: [
|
items: [
|
||||||
{ text: 'Текущее состояние продукта', link: '/appendix/current-state' },
|
{ text: 'А. Текущее состояние продукта', link: '/appendix/current-state' },
|
||||||
],
|
],
|
||||||
},
|
},
|
||||||
],
|
],
|
||||||
|
|||||||
127
docs/index.md
127
docs/index.md
@@ -1,34 +1,103 @@
|
|||||||
---
|
# Техническое задание на разработку программного продукта
|
||||||
layout: home
|
|
||||||
|
|
||||||
hero:
|
## 0. Общие положения
|
||||||
name: "Личный кабинет Фрегат"
|
|
||||||
text: "Подробное техническое задание"
|
|
||||||
tagline: "Черновой пакет документов по договору №28/04-26ПО от 28 апреля 2026 года"
|
|
||||||
actions:
|
|
||||||
- theme: brand
|
|
||||||
text: Открыть ТЗ
|
|
||||||
link: /tz/
|
|
||||||
- theme: alt
|
|
||||||
text: Этап 1
|
|
||||||
link: /tz/stage-1/
|
|
||||||
|
|
||||||
features:
|
Наименование программного продукта: `Личный кабинет Фрегат`.
|
||||||
- title: По договору и спецификации
|
|
||||||
details: Структура документа собрана на основании договора, приложения со спецификацией и текущей реализации продукта.
|
|
||||||
- title: По ГОСТ-логике
|
|
||||||
details: Каркас построен по логике ГОСТ 19.201-78, но адаптирован под современный B2B веб-продукт.
|
|
||||||
- title: Из кода, а не из фантазий
|
|
||||||
details: В документ вынесены реальные роли, разделы, сценарии и сущности, которые уже заложены в продукте.
|
|
||||||
---
|
|
||||||
|
|
||||||
Этот пакет нужен как основа для согласования полного ТЗ и отдельного первого этапа. В текущей версии мы фиксируем:
|
Заказчик: ООО `Фрегат Групп`.
|
||||||
|
|
||||||
- рамки продукта
|
Основания для разработки:
|
||||||
- состав ролей и интерфейсов
|
|
||||||
- сценарии клиента и менеджера
|
|
||||||
- требования к данным и интеграциям
|
|
||||||
- границы этапа 1 по UX/UI
|
|
||||||
- состав итоговых артефактов и приемки
|
|
||||||
|
|
||||||
Рекомендуемый следующий шаг: пройти разделы `/tz/` сверху вниз, внести уточнения по спорным бизнес-правилам и после этого выпускать согласованную редакцию.
|
- договор на разработку программного продукта №28/04-26ПО от 28 апреля 2026 года
|
||||||
|
- приложение №1 к договору: спецификация основных требований к программному обеспечению `Личный кабинет Фрегат`
|
||||||
|
- текущая реализованная кодовая база клиентской и серверной части
|
||||||
|
|
||||||
|
Настоящее техническое задание определяет:
|
||||||
|
|
||||||
|
- назначение программного продукта
|
||||||
|
- состав и границы системы
|
||||||
|
- состав ролей и прав доступа
|
||||||
|
- функциональные и информационные требования
|
||||||
|
- требования к интеграциям
|
||||||
|
- требования к интерфейсным формам
|
||||||
|
- порядок приемки и состав передаваемых материалов
|
||||||
|
|
||||||
|
## Содержание
|
||||||
|
|
||||||
|
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)
|
||||||
|
|
||||||
|
## Назначение продукта
|
||||||
|
|
||||||
|
Программный продукт предназначен для автоматизации взаимодействия между клиентами ООО `Фрегат Групп` и сотрудниками компании в части:
|
||||||
|
|
||||||
|
- регистрации и подключения клиентов
|
||||||
|
- выбора готовой продукции
|
||||||
|
- оформления заявок на заказ
|
||||||
|
- оформления заявок на расчет индивидуальной продукции
|
||||||
|
- согласования стоимости и условий доставки
|
||||||
|
- сопровождения заказов по статусам
|
||||||
|
- уведомления клиентов по изменениям
|
||||||
|
- отображения бонусного и реферального контура
|
||||||
|
|
||||||
|
## Ожидаемый результат разработки
|
||||||
|
|
||||||
|
Результатом выполнения работ должен являться развернутый на инфраструктуре заказчика B2B веб-продукт, который:
|
||||||
|
|
||||||
|
- предоставляет отдельный клиентский и менеджерский интерфейс
|
||||||
|
- работает на desktop и mobile
|
||||||
|
- обеспечивает управление заказным контуром без отображения цены до ручной обработки менеджером
|
||||||
|
- обеспечивает хранение и отображение данных по клиентам, товарам, заявкам и заказам
|
||||||
|
- получает и отображает данные из 1С в согласованном объеме
|
||||||
|
- обеспечивает уведомления по email и подключенным мессенджерам
|
||||||
|
- позволяет сопровождать бонусную и реферальную программу
|
||||||
|
|
||||||
|
## Объект автоматизации
|
||||||
|
|
||||||
|
Объектом автоматизации являются процессы взаимодействия с B2B клиентами ООО `Фрегат Групп`, включая:
|
||||||
|
|
||||||
|
- подключение новых клиентов
|
||||||
|
- работу с каталогом готовой продукции
|
||||||
|
- оформление и согласование заявок
|
||||||
|
- сопровождение заказов
|
||||||
|
- информирование клиентов
|
||||||
|
- бонусные и реферальные механики
|
||||||
|
|
||||||
|
## Состав системы
|
||||||
|
|
||||||
|
В состав системы входят:
|
||||||
|
|
||||||
|
- клиентский веб-интерфейс
|
||||||
|
- менеджерский веб-интерфейс
|
||||||
|
- серверная бизнес-логика
|
||||||
|
- хранилище данных
|
||||||
|
- интеграционный слой обмена с 1С
|
||||||
|
- модуль уведомлений
|
||||||
|
- модуль бонусной программы
|
||||||
|
- модуль административных настроек
|
||||||
|
|
||||||
|
## Общие требования к реализации
|
||||||
|
|
||||||
|
Система должна быть реализована как единый программный продукт, в котором:
|
||||||
|
|
||||||
|
- клиент не видит стоимость товара до обработки заявки менеджером
|
||||||
|
- менеджер управляет ценой, доставкой и согласованием
|
||||||
|
- данные по заказам и статусам могут обновляться от внешней системы 1С
|
||||||
|
- доступ к функциям определяется ролью пользователя
|
||||||
|
- действия пользователей журналируются
|
||||||
|
|
||||||
|
## Принцип детализации настоящего ТЗ
|
||||||
|
|
||||||
|
Настоящий документ описывает не абстрактную концепцию, а конкретный состав продукта. Поэтому дальнейшие разделы фиксируют:
|
||||||
|
|
||||||
|
- реальные модули системы
|
||||||
|
- реальные действия клиента и менеджера
|
||||||
|
- реальные данные, подлежащие хранению и отображению
|
||||||
|
- реальные экранные формы и их состав
|
||||||
|
- реальные интеграционные требования
|
||||||
|
|||||||
@@ -1,62 +1,72 @@
|
|||||||
# Приемка и передаваемые артефакты
|
# 7. Приемка и состав артефактов
|
||||||
|
|
||||||
## Этапность приемки
|
## 7.1 Общие положения приемки
|
||||||
|
|
||||||
Разработка и приемка продукта выполняются последовательно.
|
Приемка должна подтверждать, что разработанный программный продукт соответствует настоящему техническому заданию, договору и спецификации.
|
||||||
|
|
||||||
### Этап 1
|
При приемке должны проверяться:
|
||||||
|
|
||||||
Критерий завершения:
|
- функциональность клиентского контура
|
||||||
|
- функциональность менеджерского контура
|
||||||
|
- работа с каталогом
|
||||||
|
- работа с заявками на заказ
|
||||||
|
- работа с заявками на расчет
|
||||||
|
- работа с заказами
|
||||||
|
- работа уведомлений
|
||||||
|
- работа бонусного контура
|
||||||
|
- работа интеграционного обмена в согласованном объеме
|
||||||
|
|
||||||
- заказчик согласовал 2-3 сверстанные страницы
|
## 7.2 Критерии приемки
|
||||||
- подтвержден визуальный подход
|
|
||||||
- подтверждена логика ключевых сценариев
|
|
||||||
|
|
||||||
### Этап 2
|
Продукт считается соответствующим требованиям, если:
|
||||||
|
|
||||||
Критерий завершения:
|
- все обязательные сценарии выполняются
|
||||||
|
- роли и права разграничены корректно
|
||||||
|
- статусы и история изменений отображаются корректно
|
||||||
|
- каталог и остатки отображаются корректно
|
||||||
|
- клиент не видит цену до публикации условий менеджером
|
||||||
|
- менеджер может обрабатывать заявки и публиковать условия
|
||||||
|
- система сохраняет и отображает историю значимых действий
|
||||||
|
|
||||||
- реализован весь функционал, описанный в ТЗ, без интеграции с 1С
|
## 7.3 Передаваемые артефакты
|
||||||
- стороны подтвердили работоспособность сценариев внутри системы
|
|
||||||
|
|
||||||
### Этап 3
|
В состав передаваемых материалов должны входить:
|
||||||
|
|
||||||
Критерий завершения:
|
|
||||||
|
|
||||||
- настроен обмен с 1С
|
|
||||||
- подтверждена работоспособность интеграционных сценариев
|
|
||||||
- устранены блокирующие дефекты по интеграции
|
|
||||||
|
|
||||||
## Итоговые артефакты, которые должны быть переданы
|
|
||||||
|
|
||||||
По договору и спецификации в финальном комплекте должны быть:
|
|
||||||
|
|
||||||
- исходный код всех разработанных компонентов
|
- исходный код всех разработанных компонентов
|
||||||
- перечень сторонних модулей и версий
|
- перечень используемых сторонних модулей и их версий
|
||||||
- дистрибутивные комплекты и зависимости
|
- сведения об используемых внешних API
|
||||||
- схема взаимодействия модулей
|
- схемы взаимодействия модулей
|
||||||
- схема движения данных
|
- схемы движения данных
|
||||||
- схемы баз данных и связей
|
- схемы баз данных и связей
|
||||||
- описание используемых сторонних API
|
|
||||||
- распределение ролей пользователей
|
- распределение ролей пользователей
|
||||||
- сетевые требования, порты и протоколы
|
- сетевые требования, порты и протоколы
|
||||||
- обучающие материалы
|
- обучающие материалы
|
||||||
- исходные графические материалы
|
- исходные графические и интерфейсные материалы
|
||||||
- схема графического интерфейса
|
|
||||||
|
|
||||||
## Что нужно зафиксировать в актах приемки по этапам
|
## 7.4 Требования к документации
|
||||||
|
|
||||||
В акте или приложении к акту по каждому этапу желательно отдельно перечислять:
|
Документация должна позволять:
|
||||||
|
|
||||||
- что именно показывалось заказчику
|
- развернуть продукт
|
||||||
- какие сценарии проверялись
|
- сопровождать продукт
|
||||||
- какие замечания были сняты
|
- понимать архитектуру модулей
|
||||||
- какие вопросы перенесены на следующий этап
|
- понимать состав данных
|
||||||
|
- понимать состав пользовательских ролей
|
||||||
|
- понимать сценарии интеграционного обмена
|
||||||
|
|
||||||
## Открытые вопросы перед выпуском финальной редакции ТЗ
|
## 7.5 Требования к фиксации замечаний
|
||||||
|
|
||||||
- окончательный перечень страниц первого этапа
|
При приемке каждая выявленная проблема должна быть классифицирована по влиянию:
|
||||||
- полный состав статусов заявок и заказов
|
|
||||||
- формат и объем бонусного контура на первом релизе
|
- блокирующий дефект
|
||||||
- обязательные поля клиента и контрагента
|
- критичный дефект
|
||||||
- формат данных и событий для интеграции с 1С
|
- некритичное замечание
|
||||||
|
- пожелание к развитию
|
||||||
|
|
||||||
|
Каждое замечание должно иметь:
|
||||||
|
|
||||||
|
- описание
|
||||||
|
- шаги воспроизведения
|
||||||
|
- ожидаемый результат
|
||||||
|
- фактический результат
|
||||||
|
- статус устранения
|
||||||
|
|||||||
@@ -1,105 +1,167 @@
|
|||||||
# Данные и интеграции
|
# 5. Данные и интеграции
|
||||||
|
|
||||||
## Основные сущности
|
## 5.1 Основные сущности данных
|
||||||
|
|
||||||
В текущем ТЗ должны быть формально закреплены следующие сущности:
|
Система должна оперировать следующими основными сущностями:
|
||||||
|
|
||||||
- пользователь
|
- пользователь
|
||||||
- роль
|
- роль
|
||||||
- контрагент
|
- контрагент
|
||||||
- клиентская заявка на подключение
|
- заявка на подключение
|
||||||
- товар
|
- товар
|
||||||
- остаток по складу
|
- складской остаток
|
||||||
- корзина
|
- корзина
|
||||||
- заявка на заказ
|
- заявка на заказ
|
||||||
- заявка на расчет
|
- заявка на расчет
|
||||||
- заказ
|
- заказ
|
||||||
- событие статуса заказа
|
- событие изменения статуса
|
||||||
- уведомление
|
- уведомление
|
||||||
- бонусная связь
|
- бонусная связь
|
||||||
- бонусная транзакция
|
- бонусная транзакция
|
||||||
- заявка на вывод
|
- заявка на вывод вознаграждения
|
||||||
|
|
||||||
## Минимальный состав данных по ключевым сущностям
|
## 5.2 Обязательные данные по сущностям
|
||||||
|
|
||||||
### Пользователь
|
### Пользователь
|
||||||
|
|
||||||
|
Обязательные поля:
|
||||||
|
|
||||||
- идентификатор
|
- идентификатор
|
||||||
- имя
|
- имя
|
||||||
- email
|
- email
|
||||||
- телефон
|
- телефон
|
||||||
- роль
|
- роль
|
||||||
- статус доступа
|
- статус учетной записи
|
||||||
- связанные мессенджеры
|
- связанный контрагент
|
||||||
- привязанный контрагент
|
- подключенные каналы уведомлений
|
||||||
|
|
||||||
|
### Контрагент
|
||||||
|
|
||||||
|
Обязательные поля:
|
||||||
|
|
||||||
|
- идентификатор
|
||||||
|
- наименование компании
|
||||||
|
- ИНН
|
||||||
|
- КПП
|
||||||
|
- юридический адрес
|
||||||
|
- контактные лица
|
||||||
|
- закрепленный менеджер
|
||||||
|
|
||||||
### Товар
|
### Товар
|
||||||
|
|
||||||
- SKU
|
Обязательные поля:
|
||||||
- наименование
|
|
||||||
- тип товара
|
- идентификатор
|
||||||
- параметры товара
|
- SKU
|
||||||
- флаги кастомизации
|
- наименование
|
||||||
- остатки по складам
|
- тип продукции
|
||||||
|
- набор параметров
|
||||||
### Заявка на заказ / расчет
|
- остатки по складам
|
||||||
|
- признаки доступности
|
||||||
|
|
||||||
|
### Заявка на заказ
|
||||||
|
|
||||||
|
Обязательные поля:
|
||||||
|
|
||||||
- идентификатор
|
- идентификатор
|
||||||
- тип заявки
|
|
||||||
- инициатор
|
- инициатор
|
||||||
- состав позиций или параметры изделия
|
- дата создания
|
||||||
|
- состав позиций
|
||||||
|
- количество
|
||||||
|
- комментарий клиента
|
||||||
- статус
|
- статус
|
||||||
- история изменений
|
|
||||||
- стоимость после обработки
|
|
||||||
- параметры доставки
|
|
||||||
- закрепленный менеджер
|
- закрепленный менеджер
|
||||||
|
- стоимость после обработки
|
||||||
|
- параметры доставки после обработки
|
||||||
|
|
||||||
|
### Заявка на расчет
|
||||||
|
|
||||||
|
Обязательные поля:
|
||||||
|
|
||||||
|
- идентификатор
|
||||||
|
- инициатор
|
||||||
|
- дата создания
|
||||||
|
- параметры изделия
|
||||||
|
- комментарий клиента
|
||||||
|
- статус
|
||||||
|
- закрепленный менеджер
|
||||||
|
- стоимость после обработки
|
||||||
|
- параметры доставки после обработки
|
||||||
|
|
||||||
### Заказ
|
### Заказ
|
||||||
|
|
||||||
- идентификатор во внутренней системе
|
Обязательные поля:
|
||||||
|
|
||||||
|
- внутренний идентификатор
|
||||||
- внешний идентификатор 1С
|
- внешний идентификатор 1С
|
||||||
- статус
|
- статус
|
||||||
- даты статусов
|
- даты изменений
|
||||||
- состав
|
- состав заказа
|
||||||
- стоимость
|
- стоимость
|
||||||
- доставка
|
- доставка
|
||||||
- связанная заявка
|
- связанная клиентская заявка
|
||||||
|
|
||||||
## Интеграции
|
## 5.3 Требования к данным каталога
|
||||||
|
|
||||||
### Интеграция с 1С
|
Для каждой позиции в каталоге система должна хранить и отображать:
|
||||||
|
|
||||||
На уровне ТЗ фиксируем две группы обменов.
|
- тип товара
|
||||||
|
- параметры выбора
|
||||||
|
- описание параметров
|
||||||
|
- остатки по складам
|
||||||
|
- доступные варианты
|
||||||
|
- признаки кастомизации, если они применимы
|
||||||
|
|
||||||
#### Входящие события
|
## 5.4 Интеграция с 1С
|
||||||
|
|
||||||
- создание нового заказа
|
Интеграция с 1С должна обеспечивать обмен данными о заказах и каталоге.
|
||||||
- изменение заказа
|
|
||||||
- обновление статуса
|
|
||||||
- обновление параметров доставки
|
|
||||||
- обновление состава и других полей заказа
|
|
||||||
|
|
||||||
#### Методы получения данных
|
### Входящие события
|
||||||
|
|
||||||
- получение заказов клиента
|
Система должна принимать:
|
||||||
- получение каталога
|
|
||||||
- получение характеристик товаров
|
|
||||||
- получение остатков по складам
|
|
||||||
|
|
||||||
## Что нужно зафиксировать отдельно до финальной версии
|
- событие создания заказа
|
||||||
|
- событие изменения заказа
|
||||||
|
- событие изменения статуса
|
||||||
|
- событие изменения доставки
|
||||||
|
- событие изменения состава или иных параметров
|
||||||
|
|
||||||
- контракт webhook-событий
|
### Методы получения данных
|
||||||
- идентификаторы и правила синхронизации сущностей
|
|
||||||
- правила дедупликации заказов
|
|
||||||
- политика ретраев и повторной обработки
|
|
||||||
- требования к логированию ошибок интеграции
|
|
||||||
|
|
||||||
## Требования к журналированию
|
Система должна получать:
|
||||||
|
|
||||||
Для спорных операций система должна хранить:
|
- список заказов клиентов
|
||||||
|
- каталог товаров
|
||||||
|
- характеристики товаров
|
||||||
|
- остатки по складам
|
||||||
|
|
||||||
|
## 5.5 Требования к интеграционному обмену
|
||||||
|
|
||||||
|
Интеграционный слой должен обеспечивать:
|
||||||
|
|
||||||
|
- сопоставление внутренних идентификаторов и идентификаторов 1С
|
||||||
|
- защиту от дублирования событий
|
||||||
|
- журналирование входящих событий
|
||||||
|
- повторную обработку неуспешных событий
|
||||||
|
- сохранение истории обновлений
|
||||||
|
|
||||||
|
## 5.6 Требования к журналированию
|
||||||
|
|
||||||
|
Для ключевых операций система должна хранить:
|
||||||
|
|
||||||
- кто инициировал действие
|
- кто инициировал действие
|
||||||
- когда оно произошло
|
- когда произошло действие
|
||||||
- какой объект был изменен
|
- какой объект был изменен
|
||||||
- какое было предыдущее значение статуса
|
- какое состояние было до изменения
|
||||||
- какое стало новое значение статуса
|
- какое состояние стало после изменения
|
||||||
|
|
||||||
|
## 5.7 Бонусные данные
|
||||||
|
|
||||||
|
Для бонусного контура система должна хранить:
|
||||||
|
|
||||||
|
- текущий баланс
|
||||||
|
- историю начислений
|
||||||
|
- историю списаний
|
||||||
|
- реферальные связи
|
||||||
|
- заявки на вывод
|
||||||
|
- статус обработки заявок на вывод
|
||||||
|
|||||||
@@ -1,116 +1,130 @@
|
|||||||
# Функциональные требования
|
# 4. Функциональные требования
|
||||||
|
|
||||||
## 1. Авторизация и подключение
|
## 4.1 Авторизация и регистрация
|
||||||
|
|
||||||
Система должна поддерживать два способа входа клиента в продукт:
|
Система должна поддерживать два сценария подключения клиента:
|
||||||
|
|
||||||
- регистрация по персональному приглашению
|
- регистрация по персональному приглашению
|
||||||
- самостоятельная регистрация с последующим согласованием менеджером
|
- самостоятельная регистрация через форму
|
||||||
|
|
||||||
### Обязательные сценарии
|
### Требования
|
||||||
|
|
||||||
- создание приглашения менеджером
|
1. Менеджер должен иметь возможность отправить клиенту приглашение на email.
|
||||||
- отправка приглашения по email
|
2. Клиент должен иметь возможность завершить регистрацию по полученной ссылке.
|
||||||
- самостоятельная подача заявки на подключение
|
3. Клиент должен иметь возможность подать самостоятельную заявку на подключение.
|
||||||
- approve/reject заявки менеджером
|
4. После самостоятельной регистрации система должна сформировать заявку на рассмотрение менеджером.
|
||||||
- завершение регистрации и установка учетных данных
|
5. Менеджер должен иметь возможность approve/reject заявки.
|
||||||
- привязка пользователя к контрагенту
|
6. При approve система должна отправить клиенту приглашение для завершения регистрации.
|
||||||
- подключение Telegram и Max как каналов уведомлений
|
7. После завершения регистрации клиент должен получить доступ к кабинету.
|
||||||
|
8. Клиент должен иметь возможность подключить Telegram и Max как каналы уведомлений.
|
||||||
|
|
||||||
## 2. Каталог готовой продукции
|
## 4.2 Каталог готовой продукции
|
||||||
|
|
||||||
Система должна предоставлять клиенту витрину готовой продукции.
|
Система должна отображать клиенту каталог готовой продукции без отображения цены.
|
||||||
|
|
||||||
### Обязательные сценарии
|
### Требования
|
||||||
|
|
||||||
- просмотр списка типов товаров
|
1. Система должна отображать список типов продукции.
|
||||||
- переход в карточку конкретного типа товара
|
2. Система должна позволять перейти в карточку конкретного типа товара.
|
||||||
- выбор параметров продукции
|
3. Система должна отображать параметры выбора товара.
|
||||||
- просмотр доступных вариантов
|
4. Система должна отображать доступные варианты товара.
|
||||||
- сравнение остатков по складам
|
5. Система должна отображать остатки по складам по каждой позиции.
|
||||||
- добавление позиции в корзину без отображения цены
|
6. Система должна позволять добавить позицию в корзину.
|
||||||
|
7. Система не должна отображать стоимость на этапе выбора товара.
|
||||||
|
8. Система должна отображать текстовые описания параметров и сценариев применения.
|
||||||
|
|
||||||
### Обязательные особенности
|
## 4.3 Корзина и заявка на заказ
|
||||||
|
|
||||||
- по каждой позиции должны отображаться характеристики товара
|
|
||||||
- по каждой позиции должны отображаться остатки по складам
|
|
||||||
- клиент не должен видеть цену на этапе выбора
|
|
||||||
- каталог должен поддерживать как стандартные параметры, так и информационные описания по применению
|
|
||||||
|
|
||||||
## 3. Корзина и заявка на заказ
|
|
||||||
|
|
||||||
Система должна позволять клиенту собрать корзину и отправить заявку менеджеру.
|
Система должна позволять клиенту собрать корзину и отправить заявку менеджеру.
|
||||||
|
|
||||||
### Обязательные сценарии
|
### Требования
|
||||||
|
|
||||||
- просмотр корзины
|
1. Клиент должен видеть список выбранных позиций.
|
||||||
- изменение количества позиций
|
2. Клиент должен иметь возможность изменить количество.
|
||||||
- удаление позиции
|
3. Клиент должен иметь возможность удалить позицию.
|
||||||
- отправка заявки на заказ
|
4. Клиент должен иметь возможность отправить заявку на заказ.
|
||||||
- фиксация состава заявки без цены
|
5. После отправки заявки система должна зафиксировать состав позиций без стоимости.
|
||||||
- передача заявки закрепленному менеджеру
|
6. Система должна назначить заявку закрепленному менеджеру.
|
||||||
|
7. Система должна сохранить время создания заявки и инициатора.
|
||||||
|
|
||||||
## 4. Обработка заявки менеджером
|
## 4.4 Менеджерская обработка заявки
|
||||||
|
|
||||||
Менеджер должен иметь возможность вручную обработать заявку.
|
Менеджер должен иметь возможность обработать заявку вручную.
|
||||||
|
|
||||||
### Обязательные сценарии
|
### Требования
|
||||||
|
|
||||||
- открытие заявки менеджером
|
1. Менеджер должен видеть состав заявки.
|
||||||
- заполнение стоимости по позициям или по заявке
|
2. Менеджер должен видеть данные клиента и контрагента.
|
||||||
- указание параметров доставки
|
3. Менеджер должен иметь возможность указать стоимость.
|
||||||
- публикация обновленных условий клиенту
|
4. Менеджер должен иметь возможность указать параметры доставки.
|
||||||
- повторная корректировка до перевода в работу
|
5. Менеджер должен иметь возможность оставить комментарий.
|
||||||
- перевод заявки в работу
|
6. Менеджер должен иметь возможность опубликовать условия клиенту.
|
||||||
- отмена заявки
|
7. Менеджер должен иметь возможность повторно изменить условия до перевода заявки в работу.
|
||||||
|
8. Менеджер должен иметь возможность перевести заявку в работу.
|
||||||
|
9. Менеджер должен иметь возможность отменить заявку.
|
||||||
|
|
||||||
Система должна фиксировать:
|
## 4.5 Заявка на расчет
|
||||||
|
|
||||||
- инициатора изменения
|
Система должна поддерживать сценарий заявки на расчет индивидуальной продукции.
|
||||||
- дату и время действия
|
|
||||||
- историю изменения статусов
|
|
||||||
|
|
||||||
## 5. Заявка на расчет
|
### Требования
|
||||||
|
|
||||||
Если готовая продукция не подходит, система должна переводить клиента в сценарий расчета.
|
1. Клиент должен иметь возможность перейти в расчетный сценарий, если готовая продукция не подходит.
|
||||||
|
2. Клиент должен иметь возможность заполнить параметры изделия.
|
||||||
|
3. Клиент должен иметь возможность отправить заявку на расчет.
|
||||||
|
4. Менеджер должен иметь возможность обработать заявку на расчет так же, как и заказную заявку.
|
||||||
|
5. Система должна публиковать стоимость клиенту только после ручной обработки менеджером.
|
||||||
|
|
||||||
### Обязательные сценарии
|
### Параметры расчетной заявки
|
||||||
|
|
||||||
- переход из каталога в заказ с расчетом
|
Минимально система должна поддерживать передачу следующих параметров:
|
||||||
- заполнение параметров изделия
|
|
||||||
- отправка заявки на расчет
|
|
||||||
- ручная обработка стоимости менеджером
|
|
||||||
- публикация расчета клиенту
|
|
||||||
- перевод расчета в работу или отмену
|
|
||||||
|
|
||||||
### Базовые параметры расчета
|
|
||||||
|
|
||||||
Минимально в ТЗ должны быть закреплены:
|
|
||||||
|
|
||||||
- тип продукции
|
- тип продукции
|
||||||
- ширина
|
- ширина
|
||||||
- длина
|
- длина
|
||||||
- толщина
|
- толщина
|
||||||
- цвет
|
- цвет
|
||||||
- дополнительные параметры по конкретному типу товара
|
- микронность или эквивалентный параметр толщины
|
||||||
|
- специальные параметры в зависимости от типа продукции
|
||||||
- комментарий клиента
|
- комментарий клиента
|
||||||
|
|
||||||
## 6. Заказы и сопровождение
|
## 4.6 Статусы заявок
|
||||||
|
|
||||||
|
Для заявок на заказ и заявок на расчет система должна поддерживать статусы, достаточные для управления процессом.
|
||||||
|
|
||||||
|
Минимально должны быть предусмотрены следующие состояния:
|
||||||
|
|
||||||
|
- создана
|
||||||
|
- отправлена менеджеру
|
||||||
|
- обработана менеджером
|
||||||
|
- условия опубликованы
|
||||||
|
- в работе
|
||||||
|
- отменена
|
||||||
|
|
||||||
|
Для каждого изменения статуса система должна фиксировать:
|
||||||
|
|
||||||
|
- инициатора
|
||||||
|
- дату и время
|
||||||
|
- предыдущее состояние
|
||||||
|
- новое состояние
|
||||||
|
|
||||||
|
## 4.7 Заказы и сопровождение
|
||||||
|
|
||||||
Система должна отображать клиенту список заказов и карточку каждого заказа.
|
Система должна отображать клиенту список заказов и карточку каждого заказа.
|
||||||
|
|
||||||
### Обязательные сценарии
|
### Требования
|
||||||
|
|
||||||
- просмотр списка заказов
|
1. Система должна отображать список заказов клиента.
|
||||||
- фильтрация по периоду
|
2. Система должна поддерживать фильтрацию истории заказов по периоду.
|
||||||
- просмотр карточки заказа
|
3. Система должна отображать карточку заказа.
|
||||||
- отображение статуса из 1С
|
4. Система должна отображать актуальный статус заказа.
|
||||||
- отображение изменений по заказу
|
5. Система должна отображать историю изменений по заказу.
|
||||||
- отправка трекинг-уведомлений
|
6. Система должна отображать стоимость и параметры доставки, если они доступны.
|
||||||
|
7. Система должна отображать дату актуальности данных.
|
||||||
|
|
||||||
## 7. Уведомления
|
## 4.8 Уведомления
|
||||||
|
|
||||||
Система должна поддерживать многоканальные уведомления.
|
Система должна поддерживать уведомления по нескольким каналам.
|
||||||
|
|
||||||
### Каналы
|
### Каналы
|
||||||
|
|
||||||
@@ -118,23 +132,35 @@
|
|||||||
- Telegram
|
- Telegram
|
||||||
- Max
|
- Max
|
||||||
|
|
||||||
### События
|
### События уведомлений
|
||||||
|
|
||||||
- приглашение к регистрации
|
- приглашение к регистрации
|
||||||
- approve/reject подключения
|
- approve/reject подключения
|
||||||
- публикация условий по заявке
|
- публикация условий по заявке
|
||||||
- изменение статуса заказа
|
- изменение статуса заказа
|
||||||
- изменения по бонусному балансу
|
- изменения бонусного баланса
|
||||||
|
- обработка заявки на вывод
|
||||||
|
|
||||||
## 8. Бонусная программа
|
## 4.9 Бонусная программа
|
||||||
|
|
||||||
Бонусный контур должен быть описан в ТЗ как отдельная функциональная область.
|
Система должна поддерживать бонусный контур как полноценную функциональную область продукта.
|
||||||
|
|
||||||
Минимально должны быть зафиксированы:
|
### Требования
|
||||||
|
|
||||||
- реферальная привязка клиентов
|
1. Менеджер должен иметь возможность создавать реферальные связи.
|
||||||
- начисления и списания
|
2. Система должна хранить бонусные начисления и списания.
|
||||||
- журнал бонусных операций
|
3. Клиент должен видеть текущий бонусный баланс.
|
||||||
- магазин вознаграждений
|
4. Клиент должен видеть историю бонусных операций.
|
||||||
- заявка на вывод
|
5. Клиент должен иметь возможность использовать бонусы в рамках правил программы.
|
||||||
- менеджерская обработка заявок на вывод
|
6. Клиент должен иметь возможность подать заявку на вывод при достижении минимального порога.
|
||||||
|
7. Менеджер должен иметь возможность обрабатывать заявку на вывод.
|
||||||
|
8. Система должна уведомлять клиента об изменениях бонусного состояния.
|
||||||
|
|
||||||
|
## 4.10 Административные настройки
|
||||||
|
|
||||||
|
Система должна предоставлять административные разделы для управления:
|
||||||
|
|
||||||
|
- параметрами каталога
|
||||||
|
- шаблонами уведомлений
|
||||||
|
- параметрами синхронизации
|
||||||
|
- бонусным контуром в разрешенной части
|
||||||
|
|||||||
@@ -1,79 +1,108 @@
|
|||||||
# Контур продукта
|
# 2. Назначение и границы продукта
|
||||||
|
|
||||||
## Назначение
|
## 2.1 Назначение системы
|
||||||
|
|
||||||
`Личный кабинет Фрегат` предназначен для того, чтобы клиент мог самостоятельно работать с заказами и взаимодействием с менеджером в единой системе без постоянной ручной переписки.
|
`Личный кабинет Фрегат` предназначен для переноса клиентского B2B взаимодействия из разрозненной переписки и ручного обмена файлами в единый веб-интерфейс.
|
||||||
|
|
||||||
## Основные пользовательские блоки
|
Система должна обеспечить:
|
||||||
|
|
||||||
### Для клиента
|
- единый вход клиента в процессы компании
|
||||||
|
- цифровой выбор готовой продукции
|
||||||
|
- цифровую отправку заявок на заказ и расчет
|
||||||
|
- ручное согласование коммерческих условий менеджером
|
||||||
|
- прозрачное сопровождение заказа по статусам
|
||||||
|
- уведомление клиента о значимых изменениях
|
||||||
|
|
||||||
|
## 2.2 Границы продукта
|
||||||
|
|
||||||
|
Продукт охватывает следующие функциональные области:
|
||||||
|
|
||||||
|
- регистрация и подключение клиента
|
||||||
|
- каталог готовой продукции
|
||||||
|
- карточка товара и выбор параметров
|
||||||
|
- корзина и отправка заявки на заказ
|
||||||
|
- заявка на расчет кастомной продукции
|
||||||
|
- менеджерская обработка заявок
|
||||||
|
- карточка заказа и история заказов
|
||||||
|
- уведомления
|
||||||
|
- бонусная и реферальная программа
|
||||||
|
- административные настройки
|
||||||
|
|
||||||
|
Продукт не предназначен для:
|
||||||
|
|
||||||
|
- самостоятельного расчета цены клиентом
|
||||||
|
- бухгалтерского учета
|
||||||
|
- публичной B2C торговли
|
||||||
|
- самостоятельного изменения клиентом бизнес-правил компании
|
||||||
|
|
||||||
|
## 2.3 Пользовательские контуры
|
||||||
|
|
||||||
|
### Клиентский контур
|
||||||
|
|
||||||
|
Клиентский контур должен включать:
|
||||||
|
|
||||||
- вход и завершение регистрации
|
- вход и завершение регистрации
|
||||||
- профиль компании и контактов
|
- профиль компании
|
||||||
- каталог готовой продукции
|
- каталог продукции
|
||||||
- карточка товара с параметрами и остатками
|
- карточку товара
|
||||||
- корзина
|
- корзину
|
||||||
- заявка на заказ
|
- список заявок и заказов
|
||||||
- заявка на расчет кастомной продукции
|
- карточку заказа
|
||||||
- список заказов
|
|
||||||
- карточка заказа
|
|
||||||
- уведомления
|
- уведомления
|
||||||
- бонусная программа
|
- бонусный кабинет
|
||||||
|
|
||||||
### Для менеджера
|
### Менеджерский контур
|
||||||
|
|
||||||
- обработка заявок на подключение
|
Менеджерский контур должен включать:
|
||||||
- обработка клиентских заказов и расчетов
|
|
||||||
- ручное заполнение стоимости и условий доставки
|
|
||||||
- публикация обновленных условий клиенту
|
|
||||||
- просмотр клиентов и контрагентов
|
|
||||||
- управление реферальными связями
|
|
||||||
- обработка бонусных операций и заявок на вывод
|
|
||||||
- настройка каталога, уведомлений и синхронизации
|
|
||||||
|
|
||||||
## Ключевые бизнес-сценарии
|
- обработку заявок на подключение
|
||||||
|
- обработку заказных заявок
|
||||||
|
- обработку расчетных заявок
|
||||||
|
- работу с клиентами
|
||||||
|
- работу с заказами
|
||||||
|
- бонусные операции
|
||||||
|
- административные настройки
|
||||||
|
|
||||||
### Сценарий 1. Подключение клиента
|
## 2.4 Основные бизнес-сценарии
|
||||||
|
|
||||||
1. Клиент получает приглашение или самостоятельно подает заявку.
|
### Сценарий А. Подключение нового клиента
|
||||||
2. Менеджер проверяет данные.
|
|
||||||
3. При approve клиент завершает регистрацию.
|
|
||||||
4. Клиент получает доступ в кабинет.
|
|
||||||
|
|
||||||
### Сценарий 2. Заказ готовой продукции
|
1. Клиент получает приглашение от менеджера или самостоятельно подает заявку на подключение.
|
||||||
|
2. Менеджер проверяет данные клиента.
|
||||||
|
3. Менеджер принимает решение approve/reject.
|
||||||
|
4. При approve система отправляет клиенту ссылку для завершения регистрации.
|
||||||
|
5. Клиент завершает регистрацию и получает доступ в кабинет.
|
||||||
|
|
||||||
1. Клиент открывает каталог.
|
### Сценарий Б. Заказ готовой продукции
|
||||||
2. Выбирает тип товара и параметры.
|
|
||||||
3. Видит доступные остатки по складам.
|
|
||||||
4. Добавляет позиции в корзину.
|
|
||||||
5. Отправляет заявку без цены.
|
|
||||||
6. Менеджер проставляет цену и условия доставки.
|
|
||||||
7. Клиент получает обновленные условия.
|
|
||||||
8. Одна из сторон переводит заявку в работу или отменяет ее.
|
|
||||||
|
|
||||||
### Сценарий 3. Заявка на расчет
|
1. Клиент открывает каталог готовой продукции.
|
||||||
|
2. Клиент выбирает тип товара.
|
||||||
|
3. Клиент выбирает параметры товара.
|
||||||
|
4. Клиент видит доступные варианты и остатки по складам.
|
||||||
|
5. Клиент добавляет позиции в корзину.
|
||||||
|
6. Клиент отправляет заявку без цены.
|
||||||
|
7. Менеджер указывает стоимость и условия доставки.
|
||||||
|
8. Клиент получает обновленные условия и принимает решение.
|
||||||
|
|
||||||
1. Клиент понимает, что готовая продукция не подходит.
|
### Сценарий В. Заявка на расчет
|
||||||
2. Переходит в режим расчета.
|
|
||||||
3. Заполняет параметры продукции.
|
|
||||||
4. Отправляет заявку менеджеру.
|
|
||||||
5. Менеджер указывает цену и условия доставки.
|
|
||||||
6. Клиент получает расчет и принимает решение.
|
|
||||||
|
|
||||||
### Сценарий 4. Сопровождение заказа
|
1. Клиент понимает, что готовый товар не подходит под задачу.
|
||||||
|
2. Клиент переходит в режим расчета.
|
||||||
|
3. Клиент заполняет параметры изделия.
|
||||||
|
4. Клиент отправляет заявку на расчет.
|
||||||
|
5. Менеджер указывает стоимость и условия доставки.
|
||||||
|
6. Клиент получает расчет и может продолжить работу по заявке.
|
||||||
|
|
||||||
1. После создания заказа статусы поступают из 1С.
|
### Сценарий Г. Сопровождение заказа
|
||||||
2. Клиент видит актуальный статус и изменения.
|
|
||||||
3. Система отправляет уведомления по подключенным каналам.
|
|
||||||
|
|
||||||
## Границы первой проектной фиксации
|
1. Заказ создается и получает статус.
|
||||||
|
2. Изменения по заказу поступают в систему.
|
||||||
|
3. Клиент видит актуальный статус и обновленные данные.
|
||||||
|
4. Система отправляет уведомления клиенту.
|
||||||
|
|
||||||
Для первой полноценной редакции ТЗ мы фиксируем все разделы продукта, но детализируем в первую очередь:
|
### Сценарий Д. Бонусная программа
|
||||||
|
|
||||||
- авторизацию и подключение клиента
|
1. Менеджер создает или поддерживает реферальную связь.
|
||||||
- каталог и заказ готовой продукции
|
2. Система отражает бонусные начисления и изменения баланса.
|
||||||
- расчет кастомной продукции
|
3. Клиент видит бонусный баланс и историю операций.
|
||||||
- менеджерскую обработку заявки
|
4. Клиент может использовать бонусы или подать заявку на вывод в рамках правил программы.
|
||||||
- карточку заказа и список заказов
|
|
||||||
|
|
||||||
Бонусная программа должна быть описана в ТЗ, но на раннем этапе может иметь меньшую глубину детализации интерфейсов, чем заказный контур.
|
|
||||||
|
|||||||
@@ -1,62 +1,89 @@
|
|||||||
# Роли и доступ
|
# 3. Роли и права доступа
|
||||||
|
|
||||||
## Основные роли
|
## 3.1 Состав ролей
|
||||||
|
|
||||||
### Клиент
|
В системе должны быть предусмотрены следующие базовые роли:
|
||||||
|
|
||||||
Клиент работает в личном кабинете своей организации и имеет доступ только к данным, относящимся к его компании.
|
- клиент
|
||||||
|
- менеджер
|
||||||
|
- суперменеджер
|
||||||
|
|
||||||
Клиент может:
|
## 3.2 Роль `Клиент`
|
||||||
|
|
||||||
- войти по приглашению или после approve заявки
|
Клиент представляет организацию-контрагента и работает только в рамках данных своей компании.
|
||||||
- редактировать профиль и контактные данные в разрешенных пределах
|
|
||||||
|
Клиент должен иметь возможность:
|
||||||
|
|
||||||
|
- завершить регистрацию по приглашению
|
||||||
|
- подать заявку на подключение
|
||||||
|
- просматривать и редактировать собственные профильные данные в разрешенной части
|
||||||
- подключать каналы уведомлений
|
- подключать каналы уведомлений
|
||||||
- выбирать готовую продукцию
|
- работать с каталогом готовой продукции
|
||||||
- создавать заявки на заказ
|
- добавлять товары в корзину
|
||||||
- создавать заявки на расчет
|
- отправлять заявку на заказ
|
||||||
- просматривать заказы, статусы, историю и уведомления
|
- отправлять заявку на расчет
|
||||||
- просматривать бонусную информацию и подавать заявки на вывод, если это предусмотрено правилами
|
- просматривать список своих заказов
|
||||||
|
- просматривать карточку заказа
|
||||||
|
- просматривать уведомления
|
||||||
|
- просматривать бонусный баланс и историю операций
|
||||||
|
- подавать заявку на вывод, если это разрешено правилами программы
|
||||||
|
|
||||||
### Менеджер
|
## 3.3 Роль `Менеджер`
|
||||||
|
|
||||||
Менеджер работает с закрепленными клиентами, их заявками, заказами и бонусными операциями.
|
Менеджер представляет сотрудника компании, закрепленного за клиентами.
|
||||||
|
|
||||||
Менеджер может:
|
Менеджер должен иметь возможность:
|
||||||
|
|
||||||
- рассматривать заявки на подключение
|
- рассматривать заявки на подключение
|
||||||
- approve/reject регистрацию
|
- approve/reject регистрацию клиента
|
||||||
- привязывать клиента к контрагенту
|
- привязывать клиента к контрагенту
|
||||||
- принимать клиентские заявки на заказ и расчет
|
- получать заявки на заказ
|
||||||
- вручную указывать стоимость и параметры доставки
|
- получать заявки на расчет
|
||||||
|
- указывать стоимость
|
||||||
|
- указывать параметры доставки
|
||||||
- публиковать условия клиенту
|
- публиковать условия клиенту
|
||||||
- переводить заявку в работу или отменять ее
|
- переводить заявку в работу
|
||||||
- просматривать связанные с клиентами данные
|
- отменять заявку
|
||||||
- управлять реферальными связями и бонусными операциями
|
- просматривать карточки клиентов
|
||||||
|
- просматривать карточки заказов
|
||||||
|
- работать с бонусными связями и заявками на вывод
|
||||||
|
|
||||||
### Суперменеджер
|
## 3.4 Роль `Суперменеджер`
|
||||||
|
|
||||||
Суперменеджер имеет все права менеджера плюс расширенные права на управление данными и настройками.
|
Суперменеджер является расширенной административной ролью.
|
||||||
|
|
||||||
Суперменеджер может:
|
Суперменеджер должен иметь все права менеджера, а также дополнительно:
|
||||||
|
|
||||||
- работать со всеми клиентами, а не только со своими
|
- доступ ко всем клиентам и всем заказам
|
||||||
- управлять настройками каталога
|
- управление настройками каталога
|
||||||
- управлять шаблонами уведомлений
|
- управление настройками уведомлений
|
||||||
- управлять параметрами синхронизации
|
- управление настройками синхронизации
|
||||||
- выполнять административные операции по бонусной системе
|
- расширенный доступ к бонусному контуру
|
||||||
|
|
||||||
## Ограничения доступа
|
## 3.5 Матрица доступа
|
||||||
|
|
||||||
|
| Действие | Клиент | Менеджер | Суперменеджер |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| Завершение регистрации | Да | Нет | Нет |
|
||||||
|
| Подача заявки на подключение | Да | Нет | Нет |
|
||||||
|
| Просмотр каталога | Да | Да | Да |
|
||||||
|
| Добавление товара в корзину | Да | Нет | Нет |
|
||||||
|
| Отправка заявки на заказ | Да | Нет | Нет |
|
||||||
|
| Отправка заявки на расчет | Да | Нет | Нет |
|
||||||
|
| Указание стоимости и доставки | Нет | Да | Да |
|
||||||
|
| Публикация условий клиенту | Нет | Да | Да |
|
||||||
|
| Перевод заявки в работу | Да | Да | Да |
|
||||||
|
| Отмена заявки | Да | Да | Да |
|
||||||
|
| Управление настройками каталога | Нет | Нет | Да |
|
||||||
|
| Управление настройками уведомлений | Нет | Нет | Да |
|
||||||
|
| Управление синхронизацией | Нет | Нет | Да |
|
||||||
|
|
||||||
|
## 3.6 Ограничения и безопасность доступа
|
||||||
|
|
||||||
Система должна обеспечивать:
|
Система должна обеспечивать:
|
||||||
|
|
||||||
- раздельные интерфейсы клиента и менеджера
|
- раздельные интерфейсы клиента и менеджера
|
||||||
- изоляцию клиентских данных по контрагенту
|
- доступ клиента только к собственному контрагенту и его объектам
|
||||||
- контроль административных настроек только для расширенных ролей
|
- ограничение административных функций по ролям
|
||||||
- журналирование ключевых действий по заявкам и заказам
|
- журналирование действий пользователя
|
||||||
|
- возможность аудита изменения статусов и условий заявок
|
||||||
## Открытые вопросы для финальной фиксации
|
|
||||||
|
|
||||||
- может ли один клиент иметь несколько пользователей внутри одной организации
|
|
||||||
- как разделяются полномочия между менеджером и суперменеджером в части справочников
|
|
||||||
- кто именно может изменять каталог, уведомления и бонусные настройки
|
|
||||||
- требуется ли дополнительная роль наблюдателя или оператора
|
|
||||||
|
|||||||
@@ -1,84 +1,204 @@
|
|||||||
# Этап 1: UX/UI
|
# 6. Экранные формы и текстовые прототипы
|
||||||
|
|
||||||
## Назначение этапа
|
## 6.1 Общие требования к экранным формам
|
||||||
|
|
||||||
Первый этап нужен не для полной разработки продукта, а для согласования визуального подхода, экранной структуры и базовой логики пользовательских сценариев.
|
Экранные формы должны обеспечивать понятную навигацию, читаемое отображение статусов, явное разделение клиентского и менеджерского контура и однозначную привязку действий к текущему объекту.
|
||||||
|
|
||||||
Согласно приложению к договору, на этапе должны быть представлены `2-3 сверстанные страницы` с основными элементами интерфейса.
|
Для всех ключевых форм должны выполняться требования:
|
||||||
|
|
||||||
## Рекомендуемый состав страниц этапа
|
- на экране должен быть понятен текущий объект работы
|
||||||
|
- должен быть виден текущий статус объекта
|
||||||
|
- действия пользователя должны соответствовать роли и статусу объекта
|
||||||
|
- клиент не должен видеть стоимость до публикации условий менеджером
|
||||||
|
- остатки по складам должны отображаться в наглядном виде
|
||||||
|
|
||||||
### Страница 1. Каталог / карточка товара
|
## 6.2 Клиентские формы
|
||||||
|
|
||||||
Цель страницы:
|
### 6.2.1 Главная страница клиента
|
||||||
|
|
||||||
- показать, как клиент выбирает готовую продукцию
|
Назначение:
|
||||||
- показать параметры, доступные варианты и остатки
|
|
||||||
- показать переход к заказу и к расчету
|
|
||||||
|
|
||||||
Что должно быть на странице:
|
- входная точка в систему
|
||||||
|
- доступ к основным разделам
|
||||||
|
- отображение важных текущих событий
|
||||||
|
|
||||||
- список или карточка типа товара
|
Состав:
|
||||||
- иллюстрация товара
|
|
||||||
- выбор параметров
|
- шапка с навигацией
|
||||||
- описания параметров и сценариев применения
|
- блок быстрых переходов
|
||||||
- доступные варианты
|
- блок актуальных заказов
|
||||||
- индикация остатков по складам
|
- блок последних уведомлений
|
||||||
|
|
||||||
|
Прототип:
|
||||||
|
|
||||||
|
```text
|
||||||
|
+-------------------------------------------------------------+
|
||||||
|
| Header: каталог | заказы | уведомления | бонусы | профиль |
|
||||||
|
+-------------------------------------------------------------+
|
||||||
|
| Быстрые действия |
|
||||||
|
| [Каталог] [Мои заказы] [Бонусы] [Профиль] |
|
||||||
|
+-------------------------------------------------------------+
|
||||||
|
| Актуальные заказы |
|
||||||
|
| № | статус | дата | действие |
|
||||||
|
+-------------------------------------------------------------+
|
||||||
|
| Последние уведомления |
|
||||||
|
+-------------------------------------------------------------+
|
||||||
|
```
|
||||||
|
|
||||||
|
### 6.2.2 Каталог продукции
|
||||||
|
|
||||||
|
Назначение:
|
||||||
|
|
||||||
|
- показать доступные товарные направления
|
||||||
|
- дать переход в карточку типа товара
|
||||||
|
|
||||||
|
Состав:
|
||||||
|
|
||||||
|
- поиск
|
||||||
|
- сетка карточек типов продукции
|
||||||
|
|
||||||
|
### 6.2.3 Карточка типа товара
|
||||||
|
|
||||||
|
Назначение:
|
||||||
|
|
||||||
|
- выбор параметров товара
|
||||||
|
- просмотр остатков и доступных вариантов
|
||||||
|
- добавление в корзину
|
||||||
|
|
||||||
|
Состав:
|
||||||
|
|
||||||
|
- заголовок
|
||||||
|
- изображение
|
||||||
|
- блок параметров
|
||||||
|
- блок описания параметров
|
||||||
|
- SKU выбранной позиции
|
||||||
- действие `В корзину`
|
- действие `В корзину`
|
||||||
- действие перехода в расчетный сценарий
|
- таблица доступных вариантов
|
||||||
|
|
||||||
### Страница 2. Карточка заявки / заказа клиента
|
Прототип:
|
||||||
|
|
||||||
Цель страницы:
|
```text
|
||||||
|
+-------------------------------------------------------------+
|
||||||
|
| Назад | Тип товара |
|
||||||
|
+-------------------------------------------------------------+
|
||||||
|
| Изображение | Параметры выбора | SKU / В корзину |
|
||||||
|
| | ширина | |
|
||||||
|
| | длина | |
|
||||||
|
| | толщина | |
|
||||||
|
| | цвет / надпись | |
|
||||||
|
+-------------------------------------------------------------+
|
||||||
|
| Таблица доступных вариантов |
|
||||||
|
| SKU | ширина | длина | толщина | остатки | действие |
|
||||||
|
+-------------------------------------------------------------+
|
||||||
|
```
|
||||||
|
|
||||||
- показать, как клиент видит созданную заявку или заказ
|
### 6.2.4 Корзина
|
||||||
- показать статусы, историю изменений и опубликованные менеджером условия
|
|
||||||
|
|
||||||
Что должно быть на странице:
|
Назначение:
|
||||||
|
|
||||||
- номер заявки или заказа
|
- проверка состава заказа
|
||||||
- текущий статус
|
- корректировка количества
|
||||||
- состав заказа
|
- отправка заявки
|
||||||
- стоимость после обработки менеджером
|
|
||||||
- параметры доставки
|
|
||||||
- история статусов
|
|
||||||
- действия `Отправить в работу` / `Отменить`, если стадия это допускает
|
|
||||||
|
|
||||||
### Страница 3. Менеджерская обработка заявки
|
### 6.2.5 Карточка заявки / заказа
|
||||||
|
|
||||||
Цель страницы:
|
Назначение:
|
||||||
|
|
||||||
- показать рабочее место менеджера
|
- отображение состава, статуса, стоимости, доставки и истории
|
||||||
- показать, как менеджер вносит стоимость и условия
|
|
||||||
|
|
||||||
Что должно быть на странице:
|
Прототип:
|
||||||
|
|
||||||
- данные клиента
|
```text
|
||||||
- состав заявки или параметры расчета
|
+-------------------------------------------------------------+
|
||||||
- поле стоимости
|
| № заявки / заказа | Статус |
|
||||||
- блок доставки
|
+-------------------------------------------------------------+
|
||||||
- комментарий менеджера
|
| Состав |
|
||||||
|
+-------------------------------------------------------------+
|
||||||
|
| Стоимость и доставка |
|
||||||
|
+-------------------------------------------------------------+
|
||||||
|
| История изменений |
|
||||||
|
+-------------------------------------------------------------+
|
||||||
|
| [Отправить в работу] [Отменить] |
|
||||||
|
+-------------------------------------------------------------+
|
||||||
|
```
|
||||||
|
|
||||||
|
### 6.2.6 Список заказов
|
||||||
|
|
||||||
|
Назначение:
|
||||||
|
|
||||||
|
- просмотр текущих и архивных заказов
|
||||||
|
- фильтрация по периоду
|
||||||
|
|
||||||
|
### 6.2.7 Уведомления
|
||||||
|
|
||||||
|
Назначение:
|
||||||
|
|
||||||
|
- просмотр истории уведомлений по всем объектам
|
||||||
|
|
||||||
|
### 6.2.8 Бонусный кабинет
|
||||||
|
|
||||||
|
Назначение:
|
||||||
|
|
||||||
|
- просмотр бонусного баланса
|
||||||
|
- просмотр истории операций
|
||||||
|
- выполнение действий в рамках бонусной программы
|
||||||
|
|
||||||
|
## 6.3 Менеджерские формы
|
||||||
|
|
||||||
|
### 6.3.1 Список клиентов
|
||||||
|
|
||||||
|
Назначение:
|
||||||
|
|
||||||
|
- просмотр клиентов
|
||||||
|
- переход в карточку клиента
|
||||||
|
|
||||||
|
### 6.3.2 Карточка клиента
|
||||||
|
|
||||||
|
Назначение:
|
||||||
|
|
||||||
|
- просмотр компании, заявок, заказов и бонусных связей
|
||||||
|
|
||||||
|
### 6.3.3 Карточка обработки заявки
|
||||||
|
|
||||||
|
Назначение:
|
||||||
|
|
||||||
|
- ввод стоимости и доставки
|
||||||
- публикация условий клиенту
|
- публикация условий клиенту
|
||||||
- действия по статусу заявки
|
- управление статусом
|
||||||
|
|
||||||
## Что должно быть согласовано по результату этапа
|
Прототип:
|
||||||
|
|
||||||
- визуальный стиль кабинета
|
```text
|
||||||
- логика компоновки клиентских и менеджерских экранов
|
+-------------------------------------------------------------+
|
||||||
- базовый набор UI-паттернов
|
| Клиент | Контрагент | Менеджер |
|
||||||
- структура основных карточек и таблиц
|
+-------------------------------------------------------------+
|
||||||
- подход к отображению статусов, уведомлений и складских остатков
|
| Состав заявки / параметры изделия |
|
||||||
|
+-------------------------------------------------------------+
|
||||||
|
| Стоимость |
|
||||||
|
| Доставка |
|
||||||
|
| Комментарий менеджера |
|
||||||
|
+-------------------------------------------------------------+
|
||||||
|
| [Опубликовать условия] [В работу] [Отменить] |
|
||||||
|
+-------------------------------------------------------------+
|
||||||
|
```
|
||||||
|
|
||||||
## Что не требуется завершать на этом этапе
|
### 6.3.4 Список заказов менеджера
|
||||||
|
|
||||||
- полную реализацию бизнес-логики
|
Назначение:
|
||||||
- реальные интеграции с 1С
|
|
||||||
- все вспомогательные разделы
|
|
||||||
- полную настройку бонусной программы
|
|
||||||
|
|
||||||
## Связанные материалы, которые желательно приложить к этапу
|
- просмотр заказов по клиентам
|
||||||
|
- контроль текущих статусов
|
||||||
|
|
||||||
- экранная карта
|
### 6.3.5 Настройки каталога
|
||||||
- список состояний каждой из 3 страниц
|
|
||||||
- перечень компонентов интерфейса
|
Назначение:
|
||||||
- список открытых вопросов, блокирующих следующий этап
|
|
||||||
|
- управление параметрами типов продукции
|
||||||
|
- управление описаниями и вариантами
|
||||||
|
|
||||||
|
### 6.3.6 Настройки уведомлений и синхронизации
|
||||||
|
|
||||||
|
Назначение:
|
||||||
|
|
||||||
|
- управление шаблонами сообщений
|
||||||
|
- управление параметрами обмена
|
||||||
|
|||||||
Reference in New Issue
Block a user