Renumber technical specification sections
This commit is contained in:
Ruslan Bakiev
@@ -13,17 +13,17 @@ 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: '4. Функциональные требования', link: '/tz/functional-requirements' },
|
||||
{ text: '5. Требования к данным и интеграциям', link: '/tz/data-integrations' },
|
||||
{ text: '6. Техническая архитектура, стек и состав компонентов', link: '/tz/technical-architecture' },
|
||||
{ text: '7. Структура данных и модель базы данных', link: '/tz/database-model' },
|
||||
{ text: '8. Нефункциональные требования', link: '/tz/non-functional-requirements' },
|
||||
{ text: '9. Экранные формы и прототипы интерфейсов', link: '/tz/stage-1/' },
|
||||
{ text: '10. Порядок приемки и состав передаваемых материалов', link: '/tz/acceptance' },
|
||||
{ text: '1. Общие положения', link: '/' },
|
||||
{ text: '2. Основания для разработки и нормативные материалы', link: '/tz/normative-base' },
|
||||
{ text: '3. Назначение и границы программного продукта', link: '/tz/product-scope' },
|
||||
{ text: '4. Роли пользователей и права доступа', link: '/tz/roles-access' },
|
||||
{ text: '5. Функциональные требования', link: '/tz/functional-requirements' },
|
||||
{ text: '6. Требования к данным и интеграциям', link: '/tz/data-integrations' },
|
||||
{ text: '7. Техническая архитектура, стек и состав компонентов', link: '/tz/technical-architecture' },
|
||||
{ text: '8. Структура данных и модель базы данных', link: '/tz/database-model' },
|
||||
{ text: '9. Нефункциональные требования', link: '/tz/non-functional-requirements' },
|
||||
{ text: '10. Экранные формы и прототипы интерфейсов', link: '/tz/stage-1/' },
|
||||
{ text: '11. Порядок приемки и состав передаваемых материалов', link: '/tz/acceptance' },
|
||||
],
|
||||
},
|
||||
{
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Техническое задание на разработку программного продукта
|
||||
|
||||
## 0. Общие положения
|
||||
## 1. Общие положения
|
||||
|
||||
Наименование программного продукта: `Личный кабинет Фрегат`.
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
|
||||
Настоящее техническое задание устанавливает требования к составу, функциям, данным, интеграциям, интерфейсным формам, условиям приемки и составу материалов, подлежащих передаче заказчику по результатам выполнения работ.
|
||||
|
||||
## 0.1 Назначение программного продукта
|
||||
## 1.1 Назначение программного продукта
|
||||
|
||||
Программный продукт предназначен для автоматизации взаимодействия между ООО `Фрегат Групп` и B2B-клиентами компании в части:
|
||||
|
||||
@@ -27,11 +27,11 @@
|
||||
- направления клиентских уведомлений
|
||||
- ведения бонусной и реферальной программы
|
||||
|
||||
## 0.2 Объект автоматизации
|
||||
## 1.2 Объект автоматизации
|
||||
|
||||
Объектом автоматизации являются процессы клиентского обслуживания и внутренней обработки заявок, выполняемые менеджерами ООО `Фрегат Групп` при работе с готовой и индивидуальной продукцией.
|
||||
|
||||
## 0.3 Состав системы
|
||||
## 1.3 Состав системы
|
||||
|
||||
В состав программного продукта входят:
|
||||
|
||||
@@ -44,7 +44,7 @@
|
||||
- модуль бонусной программы
|
||||
- модуль административных настроек
|
||||
|
||||
## 0.4 Общие принципы работы системы
|
||||
## 1.4 Общие принципы работы системы
|
||||
|
||||
Система должна обеспечивать следующие базовые принципы:
|
||||
|
||||
@@ -54,16 +54,16 @@
|
||||
- история изменений по заявкам, заказам и бонусным операциям фиксируется в системе
|
||||
- сведения о товарах, остатках, заказах и статусах могут обновляться из внешней учетной системы
|
||||
|
||||
## 0.5 Содержание технического задания
|
||||
## 1.5 Содержание технического задания
|
||||
|
||||
1. [Основания для разработки и нормативные материалы](/tz/normative-base)
|
||||
2. [Назначение и границы программного продукта](/tz/product-scope)
|
||||
3. [Роли пользователей и права доступа](/tz/roles-access)
|
||||
4. [Функциональные требования](/tz/functional-requirements)
|
||||
5. [Требования к данным и интеграциям](/tz/data-integrations)
|
||||
6. [Техническая архитектура, стек и состав компонентов](/tz/technical-architecture)
|
||||
7. [Структура данных и модель базы данных](/tz/database-model)
|
||||
8. [Нефункциональные требования](/tz/non-functional-requirements)
|
||||
9. [Экранные формы и прототипы интерфейсов](/tz/stage-1/)
|
||||
10. [Порядок приемки и состав передаваемых материалов](/tz/acceptance)
|
||||
11. [Приложение. Текущее состояние программного продукта](/appendix/current-state)
|
||||
2. [Основания для разработки и нормативные материалы](/tz/normative-base)
|
||||
3. [Назначение и границы программного продукта](/tz/product-scope)
|
||||
4. [Роли пользователей и права доступа](/tz/roles-access)
|
||||
5. [Функциональные требования](/tz/functional-requirements)
|
||||
6. [Требования к данным и интеграциям](/tz/data-integrations)
|
||||
7. [Техническая архитектура, стек и состав компонентов](/tz/technical-architecture)
|
||||
8. [Структура данных и модель базы данных](/tz/database-model)
|
||||
9. [Нефункциональные требования](/tz/non-functional-requirements)
|
||||
10. [Экранные формы и прототипы интерфейсов](/tz/stage-1/)
|
||||
11. [Порядок приемки и состав передаваемых материалов](/tz/acceptance)
|
||||
12. [Приложение. Текущее состояние программного продукта](/appendix/current-state)
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 10. Порядок приемки и состав передаваемых материалов
|
||||
# 11. Порядок приемки и состав передаваемых материалов
|
||||
|
||||
## 10.1 Общие положения приемки
|
||||
## 11.1 Общие положения приемки
|
||||
|
||||
Приемка результата работ должна подтверждать соответствие программного продукта требованиям настоящего технического задания, условиям договора и согласованным требованиям заказчика.
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
- бонусный и реферальный контур
|
||||
- интеграционный обмен в согласованном объеме
|
||||
|
||||
## 10.2 Критерии приемки
|
||||
## 11.2 Критерии приемки
|
||||
|
||||
Программный продукт считается соответствующим требованиям, если:
|
||||
|
||||
@@ -28,7 +28,7 @@
|
||||
- менеджер имеет возможность обработать заявку и опубликовать условия
|
||||
- история изменений сохраняется и доступна в предусмотренных сценариях
|
||||
|
||||
## 10.3 Состав передаваемых материалов
|
||||
## 11.3 Состав передаваемых материалов
|
||||
|
||||
В состав передаваемых заказчику материалов должны входить:
|
||||
|
||||
@@ -40,7 +40,7 @@
|
||||
- описание состава пользовательских ролей и прав доступа
|
||||
- материалы, необходимые для сопровождения и эксплуатации продукта
|
||||
|
||||
## 10.4 Требования к документации
|
||||
## 11.4 Требования к документации
|
||||
|
||||
Передаваемая документация должна позволять:
|
||||
|
||||
@@ -49,7 +49,7 @@
|
||||
- сопровождать клиентский и менеджерский контуры
|
||||
- использовать систему в рамках согласованных ролей и сценариев
|
||||
|
||||
## 10.5 Порядок фиксации замечаний
|
||||
## 11.5 Порядок фиксации замечаний
|
||||
|
||||
Каждое замечание, выявленное при приемке, должно содержать:
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 5. Требования к данным и интеграциям
|
||||
# 6. Требования к данным и интеграциям
|
||||
|
||||
## 5.1 Основные сущности данных
|
||||
## 6.1 Основные сущности данных
|
||||
|
||||
Система должна оперировать следующими основными сущностями:
|
||||
|
||||
@@ -20,9 +20,9 @@
|
||||
- бонусная операция
|
||||
- заявка на использование либо вывод бонусов
|
||||
|
||||
## 5.2 Обязательные данные по сущностям
|
||||
## 6.2 Обязательные данные по сущностям
|
||||
|
||||
### 5.2.1 Пользователь
|
||||
### 6.2.1 Пользователь
|
||||
|
||||
Обязательные данные:
|
||||
|
||||
@@ -35,7 +35,7 @@
|
||||
- связанный контрагент
|
||||
- подключенные каналы уведомлений
|
||||
|
||||
### 5.2.2 Контрагент
|
||||
### 6.2.2 Контрагент
|
||||
|
||||
Обязательные данные:
|
||||
|
||||
@@ -47,7 +47,7 @@
|
||||
- контактные лица
|
||||
- закрепленный менеджер
|
||||
|
||||
### 5.2.3 Товар
|
||||
### 6.2.3 Товар
|
||||
|
||||
Обязательные данные:
|
||||
|
||||
@@ -60,7 +60,7 @@
|
||||
- остатки по складам
|
||||
- признаки доступности и кастомизации
|
||||
|
||||
### 5.2.4 Заявка на заказ
|
||||
### 6.2.4 Заявка на заказ
|
||||
|
||||
Обязательные данные:
|
||||
|
||||
@@ -76,7 +76,7 @@
|
||||
- стоимость после обработки
|
||||
- условия поставки после обработки
|
||||
|
||||
### 5.2.5 Заявка на расчет
|
||||
### 6.2.5 Заявка на расчет
|
||||
|
||||
Обязательные данные:
|
||||
|
||||
@@ -90,7 +90,7 @@
|
||||
- стоимость после обработки
|
||||
- условия поставки после обработки
|
||||
|
||||
### 5.2.6 Заказ
|
||||
### 6.2.6 Заказ
|
||||
|
||||
Обязательные данные:
|
||||
|
||||
@@ -103,7 +103,7 @@
|
||||
- условия поставки
|
||||
- ссылка на исходную клиентскую заявку
|
||||
|
||||
### 5.2.7 Бонусная операция
|
||||
### 6.2.7 Бонусная операция
|
||||
|
||||
Обязательные данные:
|
||||
|
||||
@@ -115,7 +115,7 @@
|
||||
- дата и время операции
|
||||
- текущий статус операции
|
||||
|
||||
## 5.3 Требования к данным каталога
|
||||
## 6.3 Требования к данным каталога
|
||||
|
||||
Для каждой позиции и для каждого товарного направления система должна хранить и отображать:
|
||||
|
||||
@@ -128,7 +128,7 @@
|
||||
- остатки по складам
|
||||
- сведения об актуальности данных
|
||||
|
||||
## 5.4 Требования к интеграции с 1С
|
||||
## 6.4 Требования к интеграции с 1С
|
||||
|
||||
Интеграция с 1С должна обеспечивать обмен данными, необходимыми для сопровождения каталога и заказов.
|
||||
|
||||
@@ -141,7 +141,7 @@
|
||||
- статусы заказов
|
||||
- изменения состава, стоимости, доставки и иных существенных параметров заказа
|
||||
|
||||
## 5.5 Требования к интеграционному обмену
|
||||
## 6.5 Требования к интеграционному обмену
|
||||
|
||||
Интеграционный слой должен обеспечивать:
|
||||
|
||||
@@ -151,7 +151,7 @@
|
||||
- повторную обработку неуспешных сообщений
|
||||
- хранение истории обновлений по интеграционным операциям
|
||||
|
||||
## 5.6 Требования к журналированию данных
|
||||
## 6.6 Требования к журналированию данных
|
||||
|
||||
Для ключевых действий и изменений система должна сохранять:
|
||||
|
||||
@@ -162,7 +162,7 @@
|
||||
- дату и время изменения
|
||||
- пользователя либо источник, выполнивший изменение
|
||||
|
||||
## 5.7 Требования к данным бонусного контура
|
||||
## 6.7 Требования к данным бонусного контура
|
||||
|
||||
Для бонусной и реферальной программы система должна хранить:
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 7. Структура данных и модель базы данных
|
||||
# 8. Структура данных и модель базы данных
|
||||
|
||||
## 7.1 Общие положения
|
||||
## 8.1 Общие положения
|
||||
|
||||
Основное хранилище данных программного продукта реализуется на `PostgreSQL`. Прикладной доступ к данным осуществляется через `Prisma ORM`.
|
||||
|
||||
@@ -18,7 +18,7 @@
|
||||
- уведомлений и мессенджерных подключений
|
||||
- бонусных и реферальных сущностей
|
||||
|
||||
## 7.2 Логические группы сущностей
|
||||
## 8.2 Логические группы сущностей
|
||||
|
||||
В модели базы данных выделяются следующие логические группы:
|
||||
|
||||
@@ -29,7 +29,7 @@
|
||||
- бонусный и реферальный контур
|
||||
- административные настройки каталога
|
||||
|
||||
## 7.3 Справочник пользователей и компаний
|
||||
## 8.3 Справочник пользователей и компаний
|
||||
|
||||
Базовые сущности группы:
|
||||
|
||||
@@ -57,7 +57,7 @@
|
||||
- один пользователь может иметь несколько адресов доставки
|
||||
- один пользователь может иметь несколько подключенных мессенджеров
|
||||
|
||||
## 7.4 Каталог и складской контур
|
||||
## 8.4 Каталог и складской контур
|
||||
|
||||
Базовые сущности группы:
|
||||
|
||||
@@ -97,7 +97,7 @@
|
||||
- разрешение на индивидуальную надпись
|
||||
- списки стандартных значений ширины, длины, толщины, втулки, цвета и надписи
|
||||
|
||||
## 7.5 Корзина и заказный контур
|
||||
## 8.5 Корзина и заказный контур
|
||||
|
||||
Базовые сущности группы:
|
||||
|
||||
@@ -121,7 +121,7 @@
|
||||
- заказ хранит состав позиций, статус, стоимость, условия поставки и историю изменений
|
||||
- события статуса обеспечивают аудит переходов между состояниями
|
||||
|
||||
## 7.6 Бонусный и реферальный контур
|
||||
## 8.6 Бонусный и реферальный контур
|
||||
|
||||
Базовые сущности группы:
|
||||
|
||||
@@ -135,7 +135,7 @@
|
||||
- хранение бонусных начислений и списаний
|
||||
- хранение заявок на использование либо вывод бонусов
|
||||
|
||||
## 7.7 Основные связи между сущностями
|
||||
## 8.7 Основные связи между сущностями
|
||||
|
||||
Укрупненная структура связей определяется следующими правилами:
|
||||
|
||||
@@ -147,7 +147,7 @@
|
||||
- настройки параметров по товарному направлению хранятся в `CatalogProductTypeSetting`
|
||||
- реферальные связи реализуются через `ReferralLink`, связывающий одного пользователя с другим пользователем
|
||||
|
||||
## 7.8 Требования к хранению прикладных данных
|
||||
## 8.8 Требования к хранению прикладных данных
|
||||
|
||||
Модель базы данных должна обеспечивать:
|
||||
|
||||
@@ -157,7 +157,7 @@
|
||||
- хранение истории статусов и действий
|
||||
- хранение интеграционных идентификаторов для связи с внешними системами
|
||||
|
||||
## 7.9 Требования к расширяемости модели
|
||||
## 8.9 Требования к расширяемости модели
|
||||
|
||||
Структура базы данных должна позволять:
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 4. Функциональные требования
|
||||
# 5. Функциональные требования
|
||||
|
||||
## 4.1 Требования к регистрации и подключению клиентов
|
||||
## 5.1 Требования к регистрации и подключению клиентов
|
||||
|
||||
Система должна поддерживать два базовых сценария подключения клиента:
|
||||
|
||||
@@ -18,7 +18,7 @@
|
||||
7. После завершения регистрации клиент должен получить доступ к личному кабинету.
|
||||
8. Система должна поддерживать подключение доступных каналов уведомлений для клиентской учетной записи.
|
||||
|
||||
## 4.2 Требования к каталогу готовой продукции
|
||||
## 5.2 Требования к каталогу готовой продукции
|
||||
|
||||
Система должна предоставлять клиенту каталог готовой продукции без отображения цены до обработки менеджером.
|
||||
|
||||
@@ -33,7 +33,7 @@
|
||||
7. Система должна исключать отображение стоимости до момента публикации условий менеджером.
|
||||
8. Для параметров товара система должна отображать пояснения, помогающие клиенту понять назначение параметра и ограничения выбора.
|
||||
|
||||
## 4.3 Требования к параметрам каталога и кастомизации
|
||||
## 5.3 Требования к параметрам каталога и кастомизации
|
||||
|
||||
Система должна поддерживать настройку параметров по каждому товарному направлению.
|
||||
|
||||
@@ -47,7 +47,7 @@
|
||||
6. Наборы стандартных параметров должны редактироваться в административном контуре.
|
||||
7. Изменение набора стандартных параметров не должно приводить к потере уже сохраненных заказных данных.
|
||||
|
||||
## 4.4 Требования к корзине и заявке на заказ
|
||||
## 5.4 Требования к корзине и заявке на заказ
|
||||
|
||||
Система должна позволять клиенту собрать корзину и направить заявку на заказ.
|
||||
|
||||
@@ -61,7 +61,7 @@
|
||||
6. Для заявки должны сохраняться дата создания, инициатор и закрепленный менеджер.
|
||||
7. До обработки менеджером стоимость в заявке не должна отображаться клиенту.
|
||||
|
||||
## 4.5 Требования к обработке заявки менеджером
|
||||
## 5.5 Требования к обработке заявки менеджером
|
||||
|
||||
Менеджер должен иметь возможность обработать клиентскую заявку вручную.
|
||||
|
||||
@@ -77,7 +77,7 @@
|
||||
8. Менеджер должен иметь возможность перевести заявку в работу.
|
||||
9. Менеджер должен иметь возможность отменить заявку с фиксацией основания отмены.
|
||||
|
||||
## 4.6 Требования к заявке на расчет индивидуальной продукции
|
||||
## 5.6 Требования к заявке на расчет индивидуальной продукции
|
||||
|
||||
Система должна поддерживать отдельный сценарий расчета продукции с индивидуальными параметрами.
|
||||
|
||||
@@ -101,7 +101,7 @@
|
||||
- иные параметры в зависимости от вида продукции
|
||||
- текстовый комментарий клиента
|
||||
|
||||
## 4.7 Требования к статусам заявок
|
||||
## 5.7 Требования к статусам заявок
|
||||
|
||||
Система должна обеспечивать сквозное сопровождение заявок по статусам.
|
||||
|
||||
@@ -122,7 +122,7 @@
|
||||
- пользователя или источник, выполнивший изменение
|
||||
- комментарий, если он предусмотрен сценарием
|
||||
|
||||
## 4.8 Требования к заказам и их сопровождению
|
||||
## 5.8 Требования к заказам и их сопровождению
|
||||
|
||||
Система должна предоставлять клиенту и менеджеру доступ к списку заказов и карточке каждого заказа.
|
||||
|
||||
@@ -135,7 +135,7 @@
|
||||
5. В карточке заказа должна отображаться дата актуальности данных.
|
||||
6. При наличии обновлений из внешней системы сведения по заказу должны синхронизироваться и отображаться пользователю.
|
||||
|
||||
## 4.9 Требования к уведомлениям
|
||||
## 5.9 Требования к уведомлениям
|
||||
|
||||
Система должна поддерживать уведомления по нескольким каналам связи.
|
||||
|
||||
@@ -154,7 +154,7 @@
|
||||
- изменение бонусного баланса
|
||||
- обработка заявки на использование либо вывод бонусов
|
||||
|
||||
## 4.10 Требования к бонусной и реферальной программе
|
||||
## 5.10 Требования к бонусной и реферальной программе
|
||||
|
||||
Система должна включать бонусный контур как самостоятельную функциональную область.
|
||||
|
||||
@@ -170,7 +170,7 @@
|
||||
8. Менеджер должен иметь возможность обрабатывать операции бонусного контура.
|
||||
9. Система должна уведомлять клиента об изменениях бонусного состояния.
|
||||
|
||||
## 4.11 Требования к административным настройкам
|
||||
## 5.11 Требования к административным настройкам
|
||||
|
||||
Система должна содержать административные разделы для управления следующими объектами:
|
||||
|
||||
|
||||
@@ -4,16 +4,16 @@
|
||||
|
||||
## Содержание
|
||||
|
||||
1. [Основания для разработки и нормативные материалы](/tz/normative-base)
|
||||
2. [Назначение и границы программного продукта](/tz/product-scope)
|
||||
3. [Роли пользователей и права доступа](/tz/roles-access)
|
||||
4. [Функциональные требования](/tz/functional-requirements)
|
||||
5. [Требования к данным и интеграциям](/tz/data-integrations)
|
||||
6. [Техническая архитектура, стек и состав компонентов](/tz/technical-architecture)
|
||||
7. [Структура данных и модель базы данных](/tz/database-model)
|
||||
8. [Нефункциональные требования](/tz/non-functional-requirements)
|
||||
9. [Экранные формы и прототипы интерфейсов](/tz/stage-1/)
|
||||
10. [Порядок приемки и состав передаваемых материалов](/tz/acceptance)
|
||||
2. [Основания для разработки и нормативные материалы](/tz/normative-base)
|
||||
3. [Назначение и границы программного продукта](/tz/product-scope)
|
||||
4. [Роли пользователей и права доступа](/tz/roles-access)
|
||||
5. [Функциональные требования](/tz/functional-requirements)
|
||||
6. [Требования к данным и интеграциям](/tz/data-integrations)
|
||||
7. [Техническая архитектура, стек и состав компонентов](/tz/technical-architecture)
|
||||
8. [Структура данных и модель базы данных](/tz/database-model)
|
||||
9. [Нефункциональные требования](/tz/non-functional-requirements)
|
||||
10. [Экранные формы и прототипы интерфейсов](/tz/stage-1/)
|
||||
11. [Порядок приемки и состав передаваемых материалов](/tz/acceptance)
|
||||
|
||||
## Назначение раздела
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# 8. Нефункциональные требования
|
||||
# 9. Нефункциональные требования
|
||||
|
||||
## 8.1 Общие требования к архитектуре
|
||||
## 9.1 Общие требования к архитектуре
|
||||
|
||||
Программный продукт должен быть реализован как веб-система с разделением клиентского и менеджерского контуров, серверной бизнес-логикой, постоянным хранением данных и возможностью интеграционного обмена с внешними системами.
|
||||
|
||||
## 8.2 Требования к доступности интерфейсов
|
||||
## 9.2 Требования к доступности интерфейсов
|
||||
|
||||
Система должна обеспечивать корректную работу:
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
|
||||
Интерфейсы должны сохранять работоспособность и читаемость при адаптивном отображении.
|
||||
|
||||
## 8.3 Требования к производительности
|
||||
## 9.3 Требования к производительности
|
||||
|
||||
При штатной эксплуатации система должна обеспечивать:
|
||||
|
||||
@@ -24,7 +24,7 @@
|
||||
|
||||
Точные количественные показатели производительности подлежат фиксации в рабочей документации по инфраструктуре и тестированию.
|
||||
|
||||
## 8.4 Требования к безопасности
|
||||
## 9.4 Требования к безопасности
|
||||
|
||||
Система должна обеспечивать:
|
||||
|
||||
@@ -34,7 +34,7 @@
|
||||
- хранение и передачу чувствительных данных с использованием защищенных механизмов
|
||||
- исключение несанкционированного доступа к административным функциям
|
||||
|
||||
## 8.5 Требования к надежности и журналированию
|
||||
## 9.5 Требования к надежности и журналированию
|
||||
|
||||
Система должна обеспечивать:
|
||||
|
||||
@@ -43,7 +43,7 @@
|
||||
- фиксацию ошибок интеграционного обмена
|
||||
- фиксацию значимых системных и пользовательских событий
|
||||
|
||||
## 8.6 Требования к сопровождаемости
|
||||
## 9.6 Требования к сопровождаемости
|
||||
|
||||
Реализация должна обеспечивать возможность:
|
||||
|
||||
@@ -52,7 +52,7 @@
|
||||
- изменения параметров каталога и уведомлений без переработки базовой структуры системы
|
||||
- расширения интеграционного обмена с 1С и иными внешними системами
|
||||
|
||||
## 8.7 Требования к данным и актуальности сведений
|
||||
## 9.7 Требования к данным и актуальности сведений
|
||||
|
||||
Система должна обеспечивать:
|
||||
|
||||
@@ -60,7 +60,7 @@
|
||||
- отображение даты актуальности сведений, полученных из внешних систем, когда это применимо
|
||||
- защиту от потери данных при обновлении параметров каталога и заказных сущностей
|
||||
|
||||
## 8.8 Требования к документации
|
||||
## 9.8 Требования к документации
|
||||
|
||||
По результатам выполнения работ должна быть сформирована документация, достаточная для:
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 1. Основания для разработки и нормативные материалы
|
||||
# 2. Основания для разработки и нормативные материалы
|
||||
|
||||
## 1.1 Основания для разработки
|
||||
## 2.1 Основания для разработки
|
||||
|
||||
Разработка программного продукта выполняется на основании следующих документов:
|
||||
|
||||
@@ -9,13 +9,13 @@
|
||||
- согласованные требования заказчика к клиентскому, менеджерскому, бонусному и интеграционному контурам
|
||||
- действующее состояние клиентской и серверной кодовой базы, используемое как фактическая основа для детализации требований
|
||||
|
||||
## 1.2 Нормативные и методические материалы
|
||||
## 2.2 Нормативные и методические материалы
|
||||
|
||||
При подготовке настоящего технического задания используется структура технической документации, соответствующая общепринятой практике составления ТЗ на программные продукты, включая подходы, применяемые в `ГОСТ 19.201-78`.
|
||||
|
||||
Настоящий документ устанавливает требования к программному продукту применительно к современному веб-решению с разграничением ролей, интеграцией с учетной системой, журналированием событий и поддержкой клиентских и менеджерских сценариев.
|
||||
|
||||
## 1.3 Исходные материалы для детализации требований
|
||||
## 2.3 Исходные материалы для детализации требований
|
||||
|
||||
При разработке технического задания использованы следующие исходные материалы:
|
||||
|
||||
@@ -27,7 +27,7 @@
|
||||
- требования к обмену данными с учетной системой 1С
|
||||
- требования к уведомлениям, бонусной программе и административным настройкам
|
||||
|
||||
## 1.4 Назначение настоящего документа
|
||||
## 2.4 Назначение настоящего документа
|
||||
|
||||
Настоящий документ предназначен для:
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 2. Назначение и границы программного продукта
|
||||
# 3. Назначение и границы программного продукта
|
||||
|
||||
## 2.1 Назначение системы
|
||||
## 3.1 Назначение системы
|
||||
|
||||
Программный продукт `Личный кабинет Фрегат` предназначен для организации единого цифрового канала взаимодействия между ООО `Фрегат Групп` и клиентами компании.
|
||||
|
||||
@@ -15,7 +15,7 @@
|
||||
- информирование клиентов о значимых изменениях
|
||||
- ведение бонусной и реферальной программы
|
||||
|
||||
## 2.2 Границы программного продукта
|
||||
## 3.2 Границы программного продукта
|
||||
|
||||
В состав программного продукта входят следующие функциональные области:
|
||||
|
||||
@@ -31,7 +31,7 @@
|
||||
- бонусный кабинет
|
||||
- административные настройки
|
||||
|
||||
## 2.3 Функции, не входящие в состав программного продукта
|
||||
## 3.3 Функции, не входящие в состав программного продукта
|
||||
|
||||
Программный продукт не предназначен для выполнения следующих функций:
|
||||
|
||||
@@ -41,7 +41,7 @@
|
||||
- прямого редактирования клиентом внутренних бизнес-правил компании
|
||||
- замены учетной системы 1С как первичного источника учетных данных
|
||||
|
||||
## 2.4 Пользовательские контуры
|
||||
## 3.4 Пользовательские контуры
|
||||
|
||||
В системе должны быть предусмотрены следующие пользовательские контуры:
|
||||
|
||||
@@ -55,16 +55,16 @@
|
||||
|
||||
Административный контур предназначен для управления настройками каталога, уведомлений, интеграционных параметров и отдельных сервисных настроек системы.
|
||||
|
||||
## 2.5 Основные бизнес-сценарии
|
||||
## 3.5 Основные бизнес-сценарии
|
||||
|
||||
### 2.5.1 Подключение клиента
|
||||
### 3.5.1 Подключение клиента
|
||||
|
||||
1. Потенциальный клиент получает приглашение на регистрацию либо подает заявку на подключение самостоятельно.
|
||||
2. Менеджер проверяет сведения о клиенте и принимает решение о подтверждении либо отклонении заявки.
|
||||
3. При положительном решении клиенту предоставляется доступ к завершению регистрации.
|
||||
4. После завершения регистрации клиент получает доступ к личному кабинету.
|
||||
|
||||
### 2.5.2 Заказ готовой продукции
|
||||
### 3.5.2 Заказ готовой продукции
|
||||
|
||||
1. Клиент открывает каталог готовой продукции.
|
||||
2. Клиент выбирает товарное направление.
|
||||
@@ -75,21 +75,21 @@
|
||||
7. Менеджер указывает стоимость, условия поставки и комментарий.
|
||||
8. Система публикует обновленные условия клиенту.
|
||||
|
||||
### 2.5.3 Заявка на расчет индивидуальной продукции
|
||||
### 3.5.3 Заявка на расчет индивидуальной продукции
|
||||
|
||||
1. Клиент переходит в режим расчета индивидуальной продукции.
|
||||
2. Клиент указывает параметры требуемого изделия.
|
||||
3. Клиент направляет заявку менеджеру.
|
||||
4. Менеджер подготавливает коммерческие условия и публикует их клиенту.
|
||||
|
||||
### 2.5.4 Сопровождение заказа
|
||||
### 3.5.4 Сопровождение заказа
|
||||
|
||||
1. Заказ получает уникальный идентификатор и статус.
|
||||
2. Данные по заказу обновляются в системе по мере обработки.
|
||||
3. Клиент отслеживает состав, статус, сроки и иные существенные сведения.
|
||||
4. При изменении статуса либо условий система направляет уведомления.
|
||||
|
||||
### 2.5.5 Бонусная и реферальная программа
|
||||
### 3.5.5 Бонусная и реферальная программа
|
||||
|
||||
1. Для клиента фиксируются правила участия в бонусной программе и, при наличии, реферальные связи.
|
||||
2. Система ведет учет начислений, списаний и остатка бонусов.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 3. Роли пользователей и права доступа
|
||||
# 4. Роли пользователей и права доступа
|
||||
|
||||
## 3.1 Состав ролей
|
||||
## 4.1 Состав ролей
|
||||
|
||||
В системе должны быть предусмотрены следующие роли пользователей:
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
- менеджер
|
||||
- суперменеджер
|
||||
|
||||
## 3.2 Роль клиента
|
||||
## 4.2 Роль клиента
|
||||
|
||||
Пользователь с ролью `Клиент` представляет организацию-контрагента и работает только с данными своей компании.
|
||||
|
||||
@@ -29,7 +29,7 @@
|
||||
- просмотр бонусного баланса и истории бонусных операций
|
||||
- подача заявки на использование либо вывод бонусов при наличии соответствующих правил
|
||||
|
||||
## 3.3 Роль менеджера
|
||||
## 4.3 Роль менеджера
|
||||
|
||||
Пользователь с ролью `Менеджер` представляет сотрудника компании, закрепленного за клиентами.
|
||||
|
||||
@@ -47,7 +47,7 @@
|
||||
- просмотр карточек клиентов, заявок и заказов
|
||||
- выполнение операций в бонусном контуре в пределах полномочий
|
||||
|
||||
## 3.4 Роль суперменеджера
|
||||
## 4.4 Роль суперменеджера
|
||||
|
||||
Пользователь с ролью `Суперменеджер` обладает всеми правами менеджера и дополнительными административными полномочиями.
|
||||
|
||||
@@ -60,7 +60,7 @@
|
||||
- управление параметрами интеграции и синхронизации
|
||||
- расширенное управление бонусным и реферальным контуром
|
||||
|
||||
## 3.5 Матрица доступа
|
||||
## 4.5 Матрица доступа
|
||||
|
||||
| Действие | Клиент | Менеджер | Суперменеджер |
|
||||
| --- | --- | --- | --- |
|
||||
@@ -79,7 +79,7 @@
|
||||
| Управление параметрами синхронизации | Нет | Нет | Да |
|
||||
| Управление бонусными правилами | Нет | Да | Да |
|
||||
|
||||
## 3.6 Ограничения доступа и требования к безопасности
|
||||
## 4.6 Ограничения доступа и требования к безопасности
|
||||
|
||||
Система должна обеспечивать:
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 9. Экранные формы и прототипы интерфейсов
|
||||
# 10. Экранные формы и прототипы интерфейсов
|
||||
|
||||
## 9.1 Карта экранов
|
||||
## 10.1 Карта экранов
|
||||
|
||||
Ниже приведен базовый состав экранов, подлежащих реализации и сопровождению в рамках программного продукта.
|
||||
|
||||
@@ -26,7 +26,7 @@
|
||||
| Настройки синхронизации | `/settings-sync` | суперменеджер | мониторинг и управление обменом |
|
||||
| Бонусная система | `/bonus-system/*` | менеджер/суперменеджер | рефералы, транзакции, выводы |
|
||||
|
||||
## 9.2 Общие требования к экранным формам
|
||||
## 10.2 Общие требования к экранным формам
|
||||
|
||||
Экранные формы должны обеспечивать:
|
||||
|
||||
@@ -42,9 +42,9 @@
|
||||
- остатки и доступные варианты отображаются в наглядном виде
|
||||
- пользователь понимает ограничения выбора и возможность кастомизации
|
||||
|
||||
## 9.3 Клиентские экранные формы
|
||||
## 10.3 Клиентские экранные формы
|
||||
|
||||
### 9.3.1 Главная страница клиента
|
||||
### 10.3.1 Главная страница клиента
|
||||
|
||||
Назначение страницы:
|
||||
|
||||
@@ -64,7 +64,7 @@
|
||||
|
||||
<NamedMermaidDiagram name="dashboard" />
|
||||
|
||||
### 9.3.2 Каталог продукции
|
||||
### 10.3.2 Каталог продукции
|
||||
|
||||
Назначение страницы:
|
||||
|
||||
@@ -83,7 +83,7 @@
|
||||
|
||||
<NamedMermaidDiagram name="catalog-grid" />
|
||||
|
||||
### 9.3.3 Карточка товара
|
||||
### 10.3.3 Карточка товара
|
||||
|
||||
Назначение страницы:
|
||||
|
||||
@@ -124,7 +124,7 @@
|
||||
- правила по втулке с логотипом
|
||||
- правила по нанесению индивидуальной надписи
|
||||
|
||||
### 9.3.4 Корзина
|
||||
### 10.3.4 Корзина
|
||||
|
||||
Назначение страницы:
|
||||
|
||||
@@ -146,7 +146,7 @@
|
||||
|
||||
<NamedMermaidDiagram name="cart" />
|
||||
|
||||
### 9.3.5 Карточка заявки или заказа
|
||||
### 10.3.5 Карточка заявки или заказа
|
||||
|
||||
Назначение страницы:
|
||||
|
||||
@@ -169,7 +169,7 @@
|
||||
- история статусов
|
||||
- системные комментарии
|
||||
|
||||
### 9.3.6 Страница логина и регистрации
|
||||
### 10.3.6 Страница логина и регистрации
|
||||
|
||||
Назначение страницы:
|
||||
|
||||
@@ -184,7 +184,7 @@
|
||||
- ссылка на самостоятельную заявку на подключение
|
||||
- блок пояснения по дальнейшему сценарию доступа
|
||||
|
||||
### 9.3.7 Список заказов
|
||||
### 10.3.7 Список заказов
|
||||
|
||||
Назначение страницы:
|
||||
|
||||
@@ -197,13 +197,13 @@
|
||||
- таблица заказов
|
||||
- переход в карточку конкретного заказа
|
||||
|
||||
### 9.3.8 Уведомления
|
||||
### 10.3.8 Уведомления
|
||||
|
||||
Назначение страницы:
|
||||
|
||||
- просмотр истории уведомлений по заказам, заявкам и бонусным операциям
|
||||
|
||||
### 9.3.9 Бонусный кабинет
|
||||
### 10.3.9 Бонусный кабинет
|
||||
|
||||
Назначение страницы:
|
||||
|
||||
@@ -223,9 +223,9 @@
|
||||
|
||||
<NamedMermaidDiagram name="bonus-cabinet" />
|
||||
|
||||
## 9.4 Менеджерские экранные формы
|
||||
## 10.4 Менеджерские экранные формы
|
||||
|
||||
### 9.4.1 Список клиентов
|
||||
### 10.4.1 Список клиентов
|
||||
|
||||
Назначение страницы:
|
||||
|
||||
@@ -239,7 +239,7 @@
|
||||
- индикаторы активности и количества заказов
|
||||
- действие приглашения нового клиента
|
||||
|
||||
### 9.4.2 Карточка клиента
|
||||
### 10.4.2 Карточка клиента
|
||||
|
||||
Назначение страницы:
|
||||
|
||||
@@ -255,7 +255,7 @@
|
||||
- список бонусных операций
|
||||
- связанные рефералы
|
||||
|
||||
### 9.4.3 Карточка обработки заявки
|
||||
### 10.4.3 Карточка обработки заявки
|
||||
|
||||
Назначение страницы:
|
||||
|
||||
@@ -278,7 +278,7 @@
|
||||
- история изменений
|
||||
- блок действий со статусом
|
||||
|
||||
### 9.4.4 Список заказов менеджера
|
||||
### 10.4.4 Список заказов менеджера
|
||||
|
||||
Назначение страницы:
|
||||
|
||||
@@ -290,7 +290,7 @@
|
||||
|
||||
<NamedMermaidDiagram name="manager-orders" />
|
||||
|
||||
### 9.4.5 Настройки каталога
|
||||
### 10.4.5 Настройки каталога
|
||||
|
||||
Назначение страницы:
|
||||
|
||||
@@ -307,7 +307,7 @@
|
||||
- списки стандартных параметров
|
||||
- единое действие сохранения настроек
|
||||
|
||||
### 9.4.6 Настройки синхронизации и уведомлений
|
||||
### 10.4.6 Настройки синхронизации и уведомлений
|
||||
|
||||
Назначение страницы:
|
||||
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# 6. Техническая архитектура, стек и состав компонентов
|
||||
# 7. Техническая архитектура, стек и состав компонентов
|
||||
|
||||
## 6.1 Общая архитектурная схема
|
||||
## 7.1 Общая архитектурная схема
|
||||
|
||||
Программный продукт реализуется по клиент-серверной модели и включает веб-клиент, сервер бизнес-логики, базу данных, модуль интеграции и вспомогательные сервисы уведомлений.
|
||||
|
||||
<NamedMermaidDiagram name="architecture-overview" />
|
||||
|
||||
## 6.2 Состав прикладных сервисов
|
||||
## 7.2 Состав прикладных сервисов
|
||||
|
||||
Согласно действующей карте деплоя в составе проекта используются следующие сервисы:
|
||||
|
||||
@@ -19,7 +19,7 @@
|
||||
|
||||
Основные прикладные сервисы `web-frontend` и `apollo-backend` разворачиваются через `dokploy_webhook` на сервере `main`.
|
||||
|
||||
## 6.3 Технологический стек фронтенда
|
||||
## 7.3 Технологический стек фронтенда
|
||||
|
||||
Клиентская часть программного продукта реализуется на следующих технологиях:
|
||||
|
||||
@@ -31,7 +31,7 @@
|
||||
- `Storybook` — контур изоляционного просмотра компонентов
|
||||
- `VitePress` — подготовка проектной документации
|
||||
|
||||
## 6.4 Технологический стек серверной части
|
||||
## 7.4 Технологический стек серверной части
|
||||
|
||||
Серверная часть программного продукта реализуется на следующих технологиях:
|
||||
|
||||
@@ -43,7 +43,7 @@
|
||||
- `Zod` — валидация структур данных в прикладных сценариях
|
||||
- `Nodemailer` — отправка уведомлений по электронной почте
|
||||
|
||||
## 6.5 Архитектура клиентской части
|
||||
## 7.5 Архитектура клиентской части
|
||||
|
||||
Клиентская часть организована по следующим слоям:
|
||||
|
||||
@@ -64,11 +64,11 @@
|
||||
- `/catalog-settings` — административные настройки каталога
|
||||
- `/bonus-program`, `/bonus-system/*` — бонусный контур
|
||||
|
||||
## 6.6 Карта слоев и компонентов
|
||||
## 7.6 Карта слоев и компонентов
|
||||
|
||||
<NamedMermaidDiagram name="component-map" />
|
||||
|
||||
## 6.7 Архитектура серверной части
|
||||
## 7.7 Архитектура серверной части
|
||||
|
||||
Серверная часть организована по следующим основным модулям:
|
||||
|
||||
@@ -81,7 +81,7 @@
|
||||
- `src/prisma-client.js` — точка подключения Prisma
|
||||
- `src/messenger*.js`, `src/telegram*.js`, `src/max-mini-app.js` — мессенджерный контур и мини-приложения
|
||||
|
||||
## 6.8 Взаимодействие фронтенда и backend
|
||||
## 7.8 Взаимодействие фронтенда и backend
|
||||
|
||||
Взаимодействие клиентской и серверной части строится через GraphQL API.
|
||||
|
||||
@@ -98,7 +98,7 @@
|
||||
- централизованно передавать авторизационные данные
|
||||
- поддерживать единый клиентский GraphQL endpoint
|
||||
|
||||
## 6.9 Интеграционные и вспомогательные HTTP-точки
|
||||
## 7.9 Интеграционные и вспомогательные HTTP-точки
|
||||
|
||||
Помимо GraphQL API, во фронтенд-контуре реализованы вспомогательные серверные маршруты:
|
||||
|
||||
@@ -109,7 +109,7 @@
|
||||
- `/api/dadata/party` — подсказки контрагентов
|
||||
- `/api/messenger-avatar/[connectionId]` — выдача изображений, связанных с мессенджерными подключениями
|
||||
|
||||
## 6.10 Компонентные требования к реализации
|
||||
## 7.10 Компонентные требования к реализации
|
||||
|
||||
Архитектура программного продукта должна сохранять следующие правила:
|
||||
|
||||
@@ -120,13 +120,13 @@
|
||||
- серверная логика доступа к данным должна проходить через Prisma
|
||||
- бизнес-правила доступа должны контролироваться серверной частью, а не только интерфейсом
|
||||
|
||||
## 6.11 Требования к конфигурации и секретам
|
||||
## 7.11 Требования к конфигурации и секретам
|
||||
|
||||
Сервисы программного продукта должны получать прикладные секреты из `Vault`.
|
||||
|
||||
В конфигурации сервисов допускается хранение только bootstrap-параметров для подключения к Vault. Бизнес-секреты, ключи интеграций и иные чувствительные данные должны загружаться из Vault при старте приложения.
|
||||
|
||||
## 6.12 Инфраструктура, деплой и эксплуатационный контур
|
||||
## 7.12 Инфраструктура, деплой и эксплуатационный контур
|
||||
|
||||
Текущая инфраструктурная схема проекта включает прикладные сервисы, сервис секретов, мессенджерные сервисы и вспомогательный worker-контур.
|
||||
|
||||
@@ -152,7 +152,7 @@
|
||||
|
||||
Эксплуатационные операции доступа и диагностики выполняются через Tailscale SSH.
|
||||
|
||||
## 6.13 Dokploy и цепочка развёртывания
|
||||
## 7.13 Dokploy и цепочка развёртывания
|
||||
|
||||
Для основных сервисов проекта используется режим `dokploy_webhook`.
|
||||
|
||||
@@ -171,7 +171,7 @@
|
||||
- `apollo-backend` стартует через загрузку Vault env, `prisma migrate deploy` и запуск `src/server.js`
|
||||
- bot-сервисы стартуют через общий паттерн загрузки Vault env и запуск `node src/server.js`
|
||||
|
||||
## 6.14 Vault и хранение секретов
|
||||
## 7.14 Vault и хранение секретов
|
||||
|
||||
Сервис `vault` развернут как отдельное приложение на базе образа `hashicorp/vault:1.21.3`.
|
||||
|
||||
@@ -190,7 +190,7 @@
|
||||
- загружает project secrets
|
||||
- экспортирует секреты в runtime environment процесса
|
||||
|
||||
## 6.15 Структура сервисных каталогов
|
||||
## 7.15 Структура сервисных каталогов
|
||||
|
||||
Текущая сервисная структура репозитория:
|
||||
|
||||
@@ -203,7 +203,7 @@
|
||||
- `vault` — Dockerfile, конфигурация и entrypoint Vault
|
||||
- `hatchet` — docker-compose инфраструктурного контура Hatchet
|
||||
|
||||
## 6.16 Контур фоновых процессов
|
||||
## 7.16 Контур фоновых процессов
|
||||
|
||||
В проекте присутствует отдельный контур фонового исполнения задач:
|
||||
|
||||
@@ -214,7 +214,7 @@
|
||||
|
||||
Конфигурация этого контура находится в `hatchet/docker-compose.yml`.
|
||||
|
||||
## 6.17 Зафиксированные runtime-версии и технологические зависимости
|
||||
## 7.17 Зафиксированные runtime-версии и технологические зависимости
|
||||
|
||||
### Базовые runtime и контейнерные образы
|
||||
|
||||
@@ -259,7 +259,7 @@
|
||||
| `nodemailer` | `8.0.4` | email notifications |
|
||||
| `dotenv` | `17.3.1` | env bootstrap in local/runtime layers |
|
||||
|
||||
## 6.18 Технические конфигурационные файлы
|
||||
## 7.18 Технические конфигурационные файлы
|
||||
|
||||
Ключевые технические файлы текущей реализации:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user