Expand technical specification content

docs/tz/functional-requirements.md

@@ -1,116 +1,130 @@
-# Функциональные требования
+# 4. Функциональные требования
 
-## 1. Авторизация и подключение
+## 4.1 Авторизация и регистрация
 
-Система должна поддерживать два способа входа клиента в продукт:
+Система должна поддерживать два сценария подключения клиента:
 
 - регистрация по персональному приглашению
-- самостоятельная регистрация с последующим согласованием менеджером
+- самостоятельная регистрация через форму
 
-### Обязательные сценарии
+### Требования
 
-- создание приглашения менеджером
-- отправка приглашения по email
-- самостоятельная подача заявки на подключение
-- approve/reject заявки менеджером
-- завершение регистрации и установка учетных данных
-- привязка пользователя к контрагенту
-- подключение Telegram и Max как каналов уведомлений
+1. Менеджер должен иметь возможность отправить клиенту приглашение на email.
+2. Клиент должен иметь возможность завершить регистрацию по полученной ссылке.
+3. Клиент должен иметь возможность подать самостоятельную заявку на подключение.
+4. После самостоятельной регистрации система должна сформировать заявку на рассмотрение менеджером.
+5. Менеджер должен иметь возможность approve/reject заявки.
+6. При approve система должна отправить клиенту приглашение для завершения регистрации.
+7. После завершения регистрации клиент должен получить доступ к кабинету.
+8. Клиент должен иметь возможность подключить Telegram и Max как каналы уведомлений.
 
-## 2. Каталог готовой продукции
+## 4.2 Каталог готовой продукции
 
-Система должна предоставлять клиенту витрину готовой продукции.
+Система должна отображать клиенту каталог готовой продукции без отображения цены.
 
-### Обязательные сценарии
+### Требования
 
-- просмотр списка типов товаров
-- переход в карточку конкретного типа товара
-- выбор параметров продукции
-- просмотр доступных вариантов
-- сравнение остатков по складам
-- добавление позиции в корзину без отображения цены
+1. Система должна отображать список типов продукции.
+2. Система должна позволять перейти в карточку конкретного типа товара.
+3. Система должна отображать параметры выбора товара.
+4. Система должна отображать доступные варианты товара.
+5. Система должна отображать остатки по складам по каждой позиции.
+6. Система должна позволять добавить позицию в корзину.
+7. Система не должна отображать стоимость на этапе выбора товара.
+8. Система должна отображать текстовые описания параметров и сценариев применения.
 
-### Обязательные особенности
-
-- по каждой позиции должны отображаться характеристики товара
-- по каждой позиции должны отображаться остатки по складам
-- клиент не должен видеть цену на этапе выбора
-- каталог должен поддерживать как стандартные параметры, так и информационные описания по применению
-
-## 3. Корзина и заявка на заказ
+## 4.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С
-- отображение изменений по заказу
-- отправка трекинг-уведомлений
+1. Система должна отображать список заказов клиента.
+2. Система должна поддерживать фильтрацию истории заказов по периоду.
+3. Система должна отображать карточку заказа.
+4. Система должна отображать актуальный статус заказа.
+5. Система должна отображать историю изменений по заказу.
+6. Система должна отображать стоимость и параметры доставки, если они доступны.
+7. Система должна отображать дату актуальности данных.
 
-## 7. Уведомления
+## 4.8 Уведомления
 
-Система должна поддерживать многоканальные уведомления.
+Система должна поддерживать уведомления по нескольким каналам.
 
 ### Каналы
 
@@ -118,23 +132,35 @@
 - Telegram
 - Max
 
-### События
+### События уведомлений
 
 - приглашение к регистрации
 - approve/reject подключения
 - публикация условий по заявке
 - изменение статуса заказа
-- изменения по бонусному балансу
+- изменения бонусного баланса
+- обработка заявки на вывод
 
-## 8. Бонусная программа
+## 4.9 Бонусная программа
 
-Бонусный контур должен быть описан в ТЗ как отдельная функциональная область.
+Система должна поддерживать бонусный контур как полноценную функциональную область продукта.
 
-Минимально должны быть зафиксированы:
+### Требования
 
-- реферальная привязка клиентов
-- начисления и списания
-- журнал бонусных операций
-- магазин вознаграждений
-- заявка на вывод
-- менеджерская обработка заявок на вывод
+1. Менеджер должен иметь возможность создавать реферальные связи.
+2. Система должна хранить бонусные начисления и списания.
+3. Клиент должен видеть текущий бонусный баланс.
+4. Клиент должен видеть историю бонусных операций.
+5. Клиент должен иметь возможность использовать бонусы в рамках правил программы.
+6. Клиент должен иметь возможность подать заявку на вывод при достижении минимального порога.
+7. Менеджер должен иметь возможность обрабатывать заявку на вывод.
+8. Система должна уведомлять клиента об изменениях бонусного состояния.
+
+## 4.10 Административные настройки
+
+Система должна предоставлять административные разделы для управления:
+
+- параметрами каталога
+- шаблонами уведомлений
+- параметрами синхронизации
+- бонусным контуром в разрешенной части