ТЗ на модуль Диспетчера

Техническое задание на разработку модуля диспетчера системы «MobileCharge»

1.1. Термины и определения (Глоссарий)
1.2. Цель и назначение модуля диспетчера
1.3. Описание автоматизируемых процессов диспетчера
1.4. Модель предметной области (ссылка на общую модель)
1.5. Ролевая модель диспетчера

2. Требования к набору функциональных блоков модуля диспетчера

2.1. Блок «Дашбоард диспетчера»

UC001: Просмотр оперативной сводки по заказам
UC002: Просмотр статистики по техникам и автопарку
UC003: Просмотр аналитики выполнения заказов
UC004: Просмотр критичных уведомлений и алертов

2.2. Блок «Управление заказами»

UC005: Просмотр списка заказов с фильтрацией
UC006: Просмотр детальной информации заказа
UC007: Редактирование параметров заказа
UC008: Изменение статуса заказа
UC009: Создание нового заказа (от имени клиента)
UC010: Отмена заказа с указанием причины
UC011: Массовые операции с заказами

2.3. Блок «Управление маршрутами»

UC012: Просмотр списка маршрутов
UC013: Создание нового маршрута
UC014: Автоматическое формирование оптимального маршрута
UC015: Редактирование маршрута (добавление/удаление заказов)
UC016: Назначение ресурсов на маршрут (техник + комплект ТС и станции)
UC017: Просмотр детальной информации маршрута
UC018: Отслеживание выполнения маршрута в реальном времени
UC019: Завершение и архивирование маршрута

2.4. Блок «Управление автопарком»

UC020: Просмотр списка сервисных ТС
UC021: Добавление нового сервисного ТС
UC022: Редактирование информации о сервисном ТС
UC023: Управление статусом ТС (доступен/в работе/на ТО/недоступен)
UC024: Просмотр истории использования ТС
UC025: Планирование и учет технического обслуживания ТС
UC026: Деактивация/архивирование ТС

2.5. Блок «Управление зарядными станциями»

UC027: Просмотр списка зарядных станций
UC028: Добавление новой зарядной станции
UC029: Редактирование информации о станции
UC030: Управление статусом станции
UC031: Назначение станции на сервисное ТС (формирование комплекта)
UC032: Отвязка станции от ТС
UC033: Просмотр истории использования станции
UC034: Планирование и учет технического обслуживания станций
UC035: Деактивация/архивирование станции

2.6. Блок «Управление техниками»

UC036: Просмотр списка техников
UC037: Добавление нового техника
UC038: Редактирование профиля техника
UC039: Управление статусом техника (активен/неактивен)
UC040: Просмотр рабочих смен техников
UC041: Создание и редактирование рабочих смен
UC042: Просмотр истории работы техника
UC043: Просмотр операций техника в реальном времени
UC044: Деактивация/архивирование учетной записи техника

2.7. Блок «Обработка обращений клиентов»

UC045: Просмотр списка открытых обращений
UC046: Просмотр детальной информации обращения
UC047: Ответ на обращение клиента
UC048: Изменение статуса обращения
UC049: Закрытие обращения
UC050: Просмотр истории переписки по обращению

2.8. Блок «Управление справочниками»

UC051: Управление справочником "Производители станций"
UC052: Управление справочником "Модели зарядных станций"
UC053: Управление справочником "Бренды автомобилей"
UC054: Управление справочником "Модели автомобилей"
UC055: Управление справочником "Тарифы"
UC056: Управление справочником "Зоны обслуживания"
UC057: Управление справочником "Типы коннекторов"
UC058: Управление справочником "Причины отмены заказов"
UC059: Управление справочником "Типы операций техников"

3. Требования к интерфейсу модуля диспетчера

3.1. Общие требования к интерфейсу
3.2. Требования к навигации
3.3. Требования к отображению данных
3.4. Требования к формам ввода
3.5. Требования к уведомлениям

4. Требования к безопасности и разграничению доступа

4.1. Аутентификация диспетчеров
4.2. Авторизация и права доступа
4.3. Аудит действий диспетчера

5. Интеграционные требования

5.1. Интеграция с внешними сервисами (карты, уведомления)

Список основных функций модуля диспетчера

Основные функциональные области:

Дашбоард и аналитика - оперативная сводка, статистика, уведомления
Управление заказами - просмотр, создание, редактирование, изменение статусов
Управление маршрутами - создание, оптимизация, назначение ресурсов, отслеживание
Управление автопарком - учет ТС, статусы, ТО, история использования
Управление станциями - учет станций, комплектация с ТС, статусы, ТО
Управление техниками - профили, смены, статусы, мониторинг работы
Обработка обращений - просмотр, ответы, управление статусами
Управление справочниками - CRUD операции для всех справочных данных

Ключевые возможности:

Создание и оптимизация маршрутов с учетом всех ограничений
Мониторинг выполнения заказов в реальном времени
Управление ресурсами (техники, ТС, станции) и их распределение
Обработка обращений клиентов
Ведение справочной информации системы
Аналитика и отчетность по работе службы

Блок «Дашбоард диспетчера»

UC001: Просмотр оперативной сводки по заказам

Описание: Диспетчер просматривает список нераспределенных заказов, анализирует их приоритеты и принимает решения о назначении на маршруты.

Activity-диаграмма (Диаграмма деятельности)

В данном параграфе описан алгоритм работы функции

graph TD
    Start([Начало]) --> A1[Пользователь: Открывает дашбоард диспетчера]
    A1 --> S1[Система: Загружает нераспределенные заказы<br/>link: СписокНераспределенныхЗаказов]
    S1 --> S2[Система: Отображает заказы со статусами NEW, CONFIRMED<br/>сортированные по времени прибытия]
    S2 --> A2[Пользователь: Выбирает заказ для назначения]
    A2 --> S3[Система: Отображает варианты назначения<br/>link: ФормаНазначенияЗаказа]
    S3 --> D1{Выбор варианта назначения}
    D1 -->|Добавить в существующий маршрут| S4[Система: Отображает список подходящих маршрутов]
    D1 -->|Создать новый маршрут| S5[Система: Переходит к UC013 Создание маршрута]
    D1 -->|Изменить предложенный маршрут| S6[Система: Переходит к UC015 Редактирование маршрута]
    S4 --> A3[Пользователь: Выбирает маршрут]
    A3 --> S7[Система: Назначает заказ на выбранный маршрут]
    S5 --> End([Конец])
    S6 --> End
    S7 --> S8[Система: Обновляет статус заказа на ASSIGNED]
    S8 --> S9[Система: Обновляет список через WebSocket]
    S9 --> End

Модель интерфейсов

В данном параграфе описана модель интерфейсов

classDiagram
    class СписокНераспределенныхЗаказов {
        <<Screen>>
        +ОбластьФильтровЗаказов : ОбластьФильтров
        +ОбластьСпискаЗаказов : ОбластьСписка
        +КнопкаСоздатьМаршрут : Кнопка
        +КнопкаОбновить : Кнопка
    }
    
    class ОбластьФильтров {
        <<Area>>
        +ФильтрПоТипу : СелекторТипаЗаказа
        +ФильтрПоВремени : ВременнойИнтервал
        +ПолеПоиска : ТекстовоеПоле
    }
    
    class ОбластьСписка {
        <<Area>>
        +КарточкаЗаказа : КарточкаЗаказаВСписке[]
    }
    
    class КарточкаЗаказаВСписке {
        <<Area>>
        +НомерЗаказа : Текст
        +ТипЗаказа : ИконкаТипа
        +ВремяПрибытия : Время
        +АдресЗаказа : Текст
        +КлиентИнформация : Текст
        +КнопкаНазначить : Кнопка
        +КнопкаДетали : Кнопка
    }
    
    class ФормаНазначенияЗаказа {
        <<Screen>>
        +ВариантыНазначения : ОбластьВариантов
        +ИнформацияОЗаказе : ОбластьИнформации
        +КнопкаПодтвердить : Кнопка
        +КнопкаОтмена : Кнопка
    }
    
    СписокНераспределенныхЗаказов *-- ОбластьФильтров
    СписокНераспределенныхЗаказов *-- ОбластьСписка
    ОбластьСписка *-- КарточкаЗаказаВСписке

Функциональные требования

RQ001. Требование к отображению нераспределенных заказов. Система должна отображать только заказы со статусами NEW и CONFIRMED, сортированные по полю Orders.scheduledDate в порядке возрастания (ближайшие по времени первыми).

RQ002. Требование к обновлению списка в реальном времени. При получении WebSocket-сообщения о новом заказе или изменении статуса, Система должна автоматически обновить отображение списка без перезагрузки страницы.

RQ003. Требование к визуальному выделению экстренных заказов. Заказы с типом "экстренный" должны отображаться с красной иконкой молнии и выделенным фоном.

RQ004. Требование к отображению информации о заказе. Карточка заказа должна содержать: номер заказа, тип (экстренный/плановый), время прибытия, адрес, информацию о клиенте (имя, телефон), кнопки "Назначить" и "Детали".

RQ005. Требование к функции назначения заказа. При нажатии кнопки "Назначить" Система должна отобразить модальное окно с вариантами: "Добавить в существующий маршрут", "Создать новый маршрут", "Изменить предложенный маршрут".

RQ006. Требование к фильтрации заказов. Система должна предоставлять фильтры по типу заказа (все/экстренные/плановые) и поиск по номеру заказа или адресу.

RQ007. Требование к счетчику нераспределенных заказов. В заголовке секции должен отображаться счетчик количества нераспределенных заказов в формате "Нераспределенные заказы (X)".

UC002: Просмотр активных маршрутов и карты

Описание: Диспетчер мониторит текущее состояние всех активных маршрутов, отслеживает местоположение техников на карте и анализирует выполнение заказов.

Activity-диаграмма (Диаграмма деятельности)

В данном параграфе описан алгоритм работы функции

graph TD
    Start([Начало]) --> A1[Пользователь: Просматривает карту и список маршрутов]
    A1 --> S1[Система: Загружает активные маршруты<br/>link: КартаИСписокМаршрутов]
    S1 --> S2[Система: Отображает маршруты кроме статуса DRAFT]
    S2 --> S3[Система: Обновляет позиции техников через WebSocket]
    S3 --> A2[Пользователь: Выбирает маршрут для детального просмотра]
    A2 --> S4[Система: Отображает маршрут на карте<br/>link: КартаМаршрута]
    S4 --> S5[Система: Показывает текущую позицию техника и прогресс]
    S5 --> D1{Техник отстает от графика?}
    D1 -->|Да, более 15 минут| S6[Система: Отображает индикатор задержки]
    D1 -->|Нет| S7[Система: Отображает нормальный статус]
    S6 --> A3[Пользователь: Может связаться с техником]
    S7 --> A3
    A3 --> End([Конец])

graph TD
  <!-- spacer -->

Модель интерфейсов

В данном параграфе описана модель интерфейсов

classDiagram
    class КартаИСписокМаршрутов {
        <<Screen>>
        +ОбластьКарты : ОбластьИнтерактивнойКарты
        +ОбластьСпискаМаршрутов : ОбластьСписка
        +ПанельФильтров : ОбластьФильтров
    }
    
    class ОбластьИнтерактивнойКарты {
        <<Area>>
        +МаркерыТехников : МаркерТехника[]
        +МаршрутНаКарте : ЛинияМаршрута
        +МаркерыЗаказов : МаркерЗаказа[]
    }
    
    class КарточкаМаршрута {
        <<Area>>
        +НомерМаршрута : Текст
        +ИмяТехника : Текст
        +СтатусМаршрута : СтатусИндикатор
        +КоличествоЗаказов : Число
        +ТекущаяТочка : Текст
        +ОтставаниеОтГрафика : ИндикаторЗадержки
        +КнопкаПодробнее : Кнопка
    }
    
    class МаркерТехника {
        <<Area>>
        +ПозицияНаКарте : GeoPoint
        +ИконкаТехника : Иконка
        +СтатусИндикатор : СтатусЦвет
        +ВсплывающаяИнформация : Подсказка
    }
    
    КартаИСписокМаршрутов *-- ОбластьИнтерактивнойКарты
    КартаИСписокМаршрутов *-- КарточкаМаршрута
    ОбластьИнтерактивнойКарты *-- МаркерТехника

Функциональные требования

RQ008. Требование к отображению активных маршрутов. Система должна отображать маршруты со всеми статусами, кроме DRAFT, с актуальной информацией о текущем выполнении.

RQ009. Требование к обновлению позиций техников. Позиции техников на карте должны обновляться через WebSocket-сообщения technician_location_updated не реже чем каждые 30 секунд.

RQ010. Требование к индикации отставания от графика. Если техник отстает от запланированного времени более чем на 15 минут, карточка маршрута должна отображаться с красным индикатором и иконкой предупреждения.

RQ011. Требование к отображению маршрута на карте. При выборе маршрута из списка, Система должна отобразить на карте: траекторию маршрута, текущую позицию техника, точки заказов с их статусами.

RQ012. Требование к фильтрации маршрутов. Система должна предоставлять фильтры по статусу маршрута (все/запланированные/в работе) и по технику.

RQ013. Требование к компоновке карты и списка. Карта должна занимать верхнюю правую четверть дашбоарда (50% × 50%), список маршрутов — нижнюю правую четверть (50% × 50%).

UC003: Анализ выполнения маршрутов

Описание: Диспетчер анализирует информацию о выполнении маршрутов на основе данных, отображаемых в карточках маршрутов (план, факт, расчетные показатели).

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Просматривает карточки маршрутов]
    A1 --> S1[Система: Отображает информацию о выполнении<br/>link: КарточкиМаршрутовСАналитикой]
    S1 --> S2[Система: Показывает плановые и фактические показатели]
    S2 --> A2[Пользователь: Анализирует отклонения от плана]
    A2 --> D1{Требуется детализация?}
    D1 -->|Да| S3[Система: Отображает детальную информацию по маршруту]
    D1 -->|Нет| End([Конец])
    S3 --> End

Модель интерфейсов

classDiagram
    class КарточкиМаршрутовСАналитикой {
        <<Screen>>
        +СписокМаршрутов : КарточкаАналитикиМаршрута[]
        +ФильтрыАналитики : ОбластьФильтров
    }
    
    class КарточкаАналитикиМаршрута {
        <<Area>>
        +НомерМаршрута : Текст
        +ПлановоеВремя : Время
        +ФактическоеВремя : Время
        +ОтклонениеОтПлана : ИндикаторОтклонения
        +КоличествоЗаказовПлан : Число
        +КоличествоЗаказовФакт : Число
        +ЭффективностьВыполнения : Процент
    }
    
    КарточкиМаршрутовСАналитикой *-- КарточкаАналитикиМаршрута

Функциональные требования

RQ014. Требование к отображению плановых показателей. Каждая карточка маршрута должна отображать плановое время выполнения, количество заказов, расчетное время прибытия.

RQ015. Требование к отображению фактических показателей. Карточка должна показывать фактическое время выполнения, текущий прогресс, отклонения от плана.

RQ016. Требование к расчету эффективности. Система должна автоматически рассчитывать процент выполнения плана и отображать его цветовым индикатором (зеленый >90%, желтый 70-90%, красный <70%).

UC004: Обработка обращений клиентов

Описание: Диспетчер просматривает открытые обращения клиентов и отвечает на них.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Просматривает список обращений]
    A1 --> S1[Система: Загружает открытые обращения<br/>link: СписокОбращений]
    S1 --> S2[Система: Отображает обращения со статусом не CLOSED, не DELETED]
    S2 --> A2[Пользователь: Выбирает обращение]
    A2 --> S3[Система: Отображает детали обращения<br/>link: ДеталиОбращения]
    S3 --> A3[Пользователь: Читает обращение]
    A3 --> D1{Требуется ответ?}
    D1 -->|Да| A4[Пользователь: Вводит ответ]
    D1 -->|Нет| End([Конец])
    A4 --> S4[Система: Отправляет ответ клиенту]
    S4 --> S5[Система: Обновляет статус обращения]
    S5 --> End

Модель интерфейсов

classDiagram
    class СписокОбращений {
        <<Screen>>
        +ОбластьФильтровОбращений : ОбластьФильтров
        +ОбластьСпискаОбращений : ОбластьСписка
        +СчетчикОткрытыхОбращений : СчетчикУведомлений
    }
    
    class КарточкаОбращения {
        <<Area>>
        +НомерОбращения : Текст
        +ТемаОбращения : Текст
        +ИмяКлиента : Текст
        +ВремяСоздания : Время
        +ПриоритетОбращения : ИндикаторПриоритета
        +КнопкаОтветить : Кнопка
    }
    
    class ДеталиОбращения {
        <<Screen>>
        +ИсторияПереписки : ОбластьСообщений
        +ФормаОтвета : ОбластьВвода
        +ИнформацияОЗаказе : ОбластьИнформации
        +КнопкаОтправить : Кнопка
    }
    
    СписокОбращений *-- КарточкаОбращения

Функциональные требования

RQ017. Требование к отображению открытых обращений. Система должна отображать обращения клиентов со всеми статусами, кроме CLOSED и DELETED.

RQ018. Требование к счетчику обращений. В заголовке секции должен отображаться счетчик открытых обращений в формате "Открытые обращения (X)".

RQ019. Требование к приоритизации обращений. Обращения должны сортироваться по приоритету: сначала связанные с активными заказами, затем по времени создания.

RQ020. Требование к ответу на обращение. При отправке ответа Система должна сохранить сообщение в истории переписки и уведомить клиента.

RQ021. Требование к автоматическому закрытию. Обращения должны автоматически закрываться через 24 часа после последнего ответа диспетчера, если от клиента не поступило новых сообщений.

Модель интерфейсов дашбоарда

Общая компоновка дашбоарда

classDiagram
    class ДашбоардДиспетчера {
        <<Screen>>
        +ЗаголовокДашбоарда : Заголовок
        +СекцияНераспределенныхЗаказов : ОбластьЗаказов
        +СекцияКарты : ОбластьКарты
        +СекцияОбращений : ОбластьОбращений
        +СекцияМаршрутов : ОбластьМаршрутов
    }
    
    class ОбластьЗаказов {
        <<Area>>
        +СписокНераспределенныхЗаказов : СписокЗаказов
        +Позиция : ВерхнийЛевыйКвадрант
        +Размер : 50процентовШиринына50процентовВысоты
    }
    
    class ОбластьКарты {
        <<Area>>
        +ИнтерактивнаяКарта : Карта
        +МаркерыТехников : МаркерТехника[]
        +Позиция : ВерхнийПравыйКвадрант
        +Размер : 50процентовШиринына50процентовВысоты
    }
    
    class ОбластьОбращений {
        <<Area>>
        +СписокОткрытыхОбращений : СписокОбращений
        +Позиция : НижнийЛевыйКвадрант
        +Размер : 50процентовШиринына50процентовВысоты
    }
    
    class ОбластьМаршрутов {
        <<Area>>
        +СписокАктивныхМаршрутов : СписокМаршрутов
        +Позиция : НижнийПравыйКвадрант
        +Размер : 50процентовШиринына50процентовВысоты
    }
    
    ДашбоардДиспетчера *-- ОбластьЗаказов
    ДашбоардДиспетчера *-- ОбластьКарты
    ДашбоардДиспетчера *-- ОбластьОбращений
    ДашбоардДиспетчера *-- ОбластьМаршрутов

Технические требования к дашбоарду

Требования к компоновке

RQ022. Требование к структуре дашбоарда. Дашбоард должен состоять из четырех равных секций размером 50% × 50% каждая:

Верхний левый квадрант: Нераспределенные заказы
Верхний правый квадрант: Интерактивная карта
Нижний левый квадрант: Открытые обращения
Нижний правый квадрант: Список активных маршрутов

RQ023. Требование к фиксированному заголовку. Дашбоард должен иметь фиксированный заголовок высотой 60px с навигационными элементами и индикаторами статуса системы.

Требования к взаимодействию в реальном времени

RQ024. Требование к WebSocket-подключению. При загрузке дашбоарда Система должна автоматически установить WebSocket-соединение с сервером на эндпоинт /ws/dispatcher/{dispatcher_id}.

RQ025. Требование к обработке сообщений. Система должна обрабатывать следующие типы WebSocket-сообщений:

{
  "type": "order_created",
  "data": {
    "order": { /* объект заказа */ },
    "priority": "normal|high|urgent"
  }
}

{
  "type": "technician_location_updated", 
  "data": {
    "technician_id": "string",
    "location": {"lat": 0.0, "lng": 0.0},
    "timestamp": "datetime"
  }
}

{
  "type": "support_ticket_created",
  "data": {
    "ticket_id": "string",
    "client_id": "string",
    "subject": "string",
    "priority": "low|normal|high|urgent"
  }
}

RQ026. Требование к восстановлению соединения. При разрыве WebSocket-соединения Система должна автоматически переподключаться с экспоненциальной задержкой (1с, 2с, 4с, 8с, максимум 30с).

RQ027. Требование к ручному обновлению. Кнопка "Обновить" в заголовке дашбоарда должна выполнять полную перезагрузку всех данных, эквивалентную обновлению страницы.

Требования к производительности

RQ028. Требование к времени отклика. Обновление интерфейса при получении WebSocket-сообщения должно происходить не более чем за 200 миллисекунд.

RQ029. Требование к оптимизации рендеринга. Система должна использовать виртуализацию для списков с более чем 50 элементами.

RQ030. Требование к адаптивности. Дашбоард должен корректно отображаться на экранах с разрешением от 1366x768 до 2560x1440 пикселей с сохранением пропорций секций.

Блок «Управление заказами» - Модуль диспетчера

UC005: Просмотр списка заказов с фильтрацией

Описание: Диспетчер просматривает список всех заказов в системе, применяет фильтры для поиска нужных заказов и переходит к детальному просмотру или редактированию.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Открывает страницу заказов]
    A1 --> S1[Система: Загружает список заказов<br/>сортированный по scheduledDate]
    S1 --> S2[Система: Отображает заказы с пагинацией<br/>20 записей на странице]
    S2 --> A2[Пользователь: Применяет фильтры или поиск]
    A2 --> S3[Система: Фильтрует заказы по критериям]
    S3 --> S4[Система: Обновляет список заказов]
    S4 --> D1{Выбор действия}
    D1 -->|Просмотр деталей| A3[Пользователь: Нажимает на заказ]
    D1 -->|Редактирование| A4[Пользователь: Нажимает Редактировать]
    D1 -->|Изменение статуса| A5[Пользователь: Нажимает Изменить статус]
    A3 --> S5[Система: Переход к UC006 Просмотр деталей]
    A4 --> S6[Система: Переход к UC007 Редактирование заказа]
    A5 --> S7[Система: Переход к UC008 Изменение статуса]
    S5 --> End([Конец])
    S6 --> End
    S7 --> End

Модель интерфейсов

classDiagram
    class СписокЗаказов {
        <<Screen>>
        +ЗаголовокСтраницы : Заголовок
        +ОбластьФильтров : ОбластьФильтрации
        +ОбластьПоиска : ПолеПоиска
        +СписокКарточекЗаказов : ОбластьСписка
        +Пагинация : КомпонентПагинации
        +КнопкаСоздатьЗаказ : Кнопка
    }
    
    class ОбластьФильтрации {
        <<Area>>
        +ФильтрСтатус : Селектор
        +ФильтрКлиент : ПолеВыбораКлиента
        +ФильтрДатаСоздания : ДатаИнтервал
        +ФильтрПлановаяДата : ДатаИнтервал
        +КнопкаПрименить : Кнопка
        +КнопкаСброс : Кнопка
    }
    
    class КарточкаЗаказа {
        <<Area>>
        +НомерЗаказа : Текст
        +СтатусЗаказа : СтатусИндикатор
        +ТипЗаказа : ИконкаТипа
        +КлиентИнформация : Текст
        +АдресЗаказа : Текст
        +ПлановоеВремя : ДатаВремя
        +НазначенныйТехник : Текст
        +КнопкиДействий : ГруппаКнопок
    }
    
    class ПолеПоиска {
        <<Area>>
        +ТекстовоеПоле : Ввод[255]
        +КнопкаПоиска : Кнопка
        +ПодсказкаПоиска : Текст
    }
    
    СписокЗаказов *-- ОбластьФильтрации
    СписокЗаказов *-- КарточкаЗаказа
    СписокЗаказов *-- ПолеПоиска

Функциональные требования

RQ101. Требование к загрузке списка заказов. Система должна загружать заказы со всеми статусами, сортированные по Orders.scheduledDate в порядке возрастания (ближайшие по времени первыми).

RQ102. Требование к пагинации. Система должна отображать 20 заказов на странице с возможностью навигации по страницам.

RQ103. Требование к фильтрации по статусу. Система должна предоставлять мультиселект фильтр по Orders.status со всеми возможными значениями статусов.

RQ104. Требование к фильтрации по клиенту. Система должна предоставлять поле автодополнения для поиска клиента по Clients.firstName, Clients.lastName, Clients.email.

RQ105. Требование к фильтрации по датам. Система должна предоставлять интервальные фильтры:

По дате создания (Orders.createdAt)
По плановой дате исполнения (Orders.scheduledDate)

RQ106. Требование к функции поиска. При вводе текста в поле поиска и нажатии кнопки "Поиск", Система должна искать по вхождению подстроки в:

Orders.orderNumber
Orders.address
Clients.firstName + Clients.lastName
Clients.email

RQ107. Требование к отображению информации в карточке заказа. Каждая карточка должна содержать:

Номер заказа с префиксом типа
Цветовой индикатор статуса
Иконку типа заказа (экстренный/плановый)
ФИО клиента и телефон
Адрес заказа
Плановые дату и время
ФИО назначенного техника (если есть)

RQ108. Требование к действиям с заказом. Для каждого заказа должны быть доступны кнопки:

"Просмотр" - всегда доступна
"Редактировать" - доступна для статусов NEW, CONFIRMED, ASSIGNED
"Изменить статус" - доступна для активных заказов

UC006: Просмотр детальной информации заказа

Описание: Диспетчер просматривает полную информацию о заказе, включая историю изменений статусов, детали клиента и автомобиля, назначенные ресурсы.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает на заказ в списке]
    A1 --> S1[Система: Загружает детальную информацию]
    S1 --> S2[Система: Отображает информацию о заказе]
    S2 --> S3[Система: Загружает историю статусов<br/>из OrderStatusHistories]
    S3 --> S4[Система: Отображает информацию о клиенте<br/>и автомобиле]
    S4 --> S5[Система: Отображает назначенные ресурсы<br/>техник и маршрут]
    S5 --> D1{Выбор действия}
    D1 -->|Редактировать| A2[Пользователь: Нажимает Редактировать]
    D1 -->|Изменить статус| A3[Пользователь: Нажимает Изменить статус] 
    D1 -->|Назначить в маршрут| A4[Пользователь: Нажимает Назначить в маршрут]
    D1 -->|Вернуться| A5[Пользователь: Нажимает Назад]
    A2 --> S6[Система: Переход к UC007 Редактирование заказа]
    A3 --> S7[Система: Переход к UC008 Изменение статуса]
    A4 --> S8[Система: Переход к UC012 Назначение в маршрут]
    A5 --> End([Конец])
    S6 --> End
    S7 --> End  
    S8 --> End

Функциональные требования

RQ109. Требование к отображению основной информации. Система должна отображать:

Номер заказа и текущий статус
Тип заказа (экстренный/плановый)
Дату и время создания, плановую дату исполнения
Полный адрес и координаты
Комментарий к заказу

RQ110. Требование к отображению информации о клиенте. Система должна отображать:

ФИО клиента
Контактные данные (телефон, email)
Дату регистрации
Статус клиента (активен/неактивен)

RQ111. Требование к отображению информации об автомобиле. Система должна отображать данные из связанного Vehicles:

Марка и модель автомобиля
Государственный номер
Год выпуска
Цвет

RQ112. Требование к отображению истории статусов. Система должна отображать хронологический список изменений статуса из OrderStatusHistories с указанием:

Предыдущий и новый статус
Дата и время изменения
Инициатор изменения (пользователь или система)
Причина изменения (если указана)

RQ113. Требование к отображению назначенных ресурсов. При наличии назначений Система должна отображать:

ФИО и контакты назначенного техника
Информацию о сервисном ТС
Номер маршрута и ссылку на детали маршрута

UC007: Редактирование параметров заказа

Описание: Диспетчер изменяет параметры заказа в зависимости от его текущего статуса.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Редактировать заказ]
    A1 --> S1[Система: Проверяет статус заказа]
    S1 --> D1{Статус позволяет редактирование?}
    D1 -->|Нет| S2[Система: Отображает сообщение об ошибке]
    D1 -->|Да| S3[Система: Определяет доступные поля<br/>на основе статуса]
    S3 --> S4[Система: Отображает форму редактирования]
    S4 --> A2[Пользователь: Изменяет параметры заказа]
    A2 --> A3[Пользователь: Нажимает Сохранить]
    A3 --> S5[Система: Валидирует введенные данные]
    S5 --> D2{Данные корректны?}
    D2 -->|Нет| S6[Система: Отображает ошибки валидации]
    D2 -->|Да| S7[Система: Сохраняет изменения в Orders]
    S7 --> S8[Система: Создает запись в аудит-лог]
    S8 --> S9[Система: Отображает подтверждение]
    S9 --> End([Конец])
    S6 --> A2
    S2 --> End

Модель интерфейсов

classDiagram
    class ФормаРедактированияЗаказа {
        <<Screen>>
        +ЗаголовокФормы : Заголовок
        +ОбластьОсновныхПараметров : ОбластьПолей
        +ОбластьВремениИМеста : ОбластьПолей
        +ОбластьТарифаИАвто : ОбластьПолей
        +ПолеКомментария : ТекстовоеПоле
        +КнопкаСохранить : Кнопка
        +КнопкаОтмена : Кнопка
    }
    
    class ОбластьПолей {
        <<Area>>
        +НаборПолейВвода : ПолеВвода[]
        +ПодписиПолей : Текст[]
        +ИндикаторыОбязательности : Индикатор[]
    }

Функциональные требования

RQ114. Требование к проверке возможности редактирования. Система должна разрешать редактирование только для заказов со статусами NEW, CONFIRMED, ASSIGNED.

RQ115. Требование к набору редактируемых полей по статусам:

NEW, CONFIRMED: address, scheduledDate, scheduledTime, idTariff, chargeLevel, chargeValue, комментарий, выбор автомобиля клиента
ASSIGNED: scheduledTime, комментарий (ограниченное редактирование)
Остальные статусы: редактирование недоступно

RQ116. Требование к валидации данных. Система должна проверять:

Плановая дата не может быть в прошлом
Адрес должен быть валидным и геокодируемым
Выбранный автомобиль должен принадлежать клиенту заказа
Выбранный тариф должен быть активным

RQ117. Требование к сохранению изменений. При успешной валидации Система должна:

Обновить соответствующие поля в таблице Orders
Создать запись в аудит-лог с указанием изменившихся полей
Установить Orders.updatedBy = текущий диспетчер
Установить Orders.updatedAt = текущее время

RQ118. Требование к ограничениям редактирования. Система не должна позволять изменять:

Клиента заказа (Orders.idClient)
Номер заказа (Orders.orderNumber)
Статус заказа (только через UC008)
Техническую информацию (totalKwh, totalPrice до завершения)

UC008: Изменение статуса заказа

Описание: Диспетчер изменяет статус заказа с обязательным логированием действия в истории.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Изменить статус]
    A1 --> S1[Система: Загружает текущий статус заказа]
    S1 --> S2[Система: Определяет доступные статусы<br/>для перехода]
    S2 --> S3[Система: Отображает форму изменения статуса]
    S3 --> A2[Пользователь: Выбирает новый статус]
    A2 --> A3[Пользователь: Опционально вводит причину]
    A3 --> A4[Пользователь: Нажимает Подтвердить]
    A4 --> S4[Система: Валидирует возможность перехода]
    S4 --> D1{Переход разрешен?}
    D1 -->|Нет| S5[Система: Отображает ошибку]
    D1 -->|Да| S6[Система: Обновляет Orders.status]
    S6 --> S7[Система: Создает запись в OrderStatusHistories]
    S7 --> S8[Система: Уведомляет заинтересованные стороны]
    S8 --> S9[Система: Отображает подтверждение]
    S9 --> End([Конец])
    S5 --> A2

Функциональные требования

RQ119. Требование к доступным переходам статусов. Диспетчер может инициировать переходы согласно диаграмме состояний, последовательно по жизненному циклу заказа.

RQ120. Требование к форме изменения статуса. Система должна отображать:

Текущий статус заказа
Селектор доступных статусов для перехода
Необязательное поле для комментария/причины
Информацию о последствиях изменения статуса

RQ121. Требование к созданию записи в истории. При изменении статуса Система должна создать запись в OrderStatusHistories:

previousStatus = текущий статус
newStatus = выбранный статус
idUser = текущий диспетчер
reason = введенный комментарий
createdAt = текущее время

RQ122. Требование к уведомлениям. После изменения статуса Система должна:

Отправить push-уведомление клиенту (если применимо)
Уведомить назначенного техника (если применимо)
Обновить связанные маршруты и смены

UC009: Создание нового заказа (от имени клиента)

Описание: Диспетчер создает заказ для существующего клиента с привязанной картой оплаты.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Изменить статус]
    A1 --> S1[Система: Загружает текущий статус заказа]
    S1 --> S2[Система: Определяет доступные статусы<br/>для перехода]
    S2 --> S3[Система: Отображает форму изменения статуса]
    S3 --> A2[Пользователь: Выбирает новый статус]
    A2 --> A3[Пользователь: Опционально вводит причину]
    A3 --> A4[Пользователь: Нажимает Подтвердить]
    A4 --> S4[Система: Валидирует возможность перехода]
    S4 --> D1{Переход разрешен?}
    D1 -->|Нет| S5[Система: Отображает ошибку]
    D1 -->|Да| S6[Система: Обновляет Orders.status]
    S6 --> S7[Система: Создает запись в OrderStatusHistories]
    S7 --> S8[Система: Уведомляет заинтересованные стороны]
    S8 --> S9[Система: Отображает подтверждение]
    S9 --> End([Конец])
    S5 --> A2

Функциональные требования

RQ123. Требование к выбору клиента. Система должна предоставить поиск по клиентам с автодополнением по ФИО, email, телефону.

RQ124. Требование к проверке карты оплаты. Система должна проверить наличие активной привязанной карты у клиента и не позволять создание заказа без неё.

RQ125. Требование к доступным типам заказов. Диспетчер может создать:

Экстренный заказ (с префиксом "EO-")
Плановый заказ (с префиксом "PO-")

RQ126. Требование к обязательным полям. При создании заказа обязательны:

Клиент
Автомобиль клиента
Адрес
Тип заказа
Для планового: дата и время
Тариф
Параметры зарядки

RQ127. Требование к автоматическим полям. Система должна автоматически установить:

status = NEW
orderNumber = автогенерируемый номер
createdBy = текущий диспетчер
createdAt = текущее время

UC010: Отмена заказа с указанием причины

Описание: Диспетчер отменяет заказ с обязательным указанием причины и расчетом компенсации.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Отменить заказ]
    A1 --> S1[Система: Проверяет возможность отмены]
    S1 --> D1{Отмена разрешена?}
    D1 -->|Нет| S2[Система: Отображает сообщение о невозможности]
    D1 -->|Да| S3[Система: Отображает форму отмены]
    S3 --> A2[Пользователь: Выбирает причину отмены]
    A2 --> A3[Пользователь: Вводит комментарий]
    A3 --> A4[Пользователь: Нажимает Подтвердить отмену]
    A4 --> S4[Система: Рассчитывает сумму к возврату]
    S4 --> S5[Система: Изменяет статус на CANCELLED]
    S5 --> S6[Система: Создает запись в OrderStatusHistories]
    S6 --> S7[Система: Создает транзакцию возврата]
    S7 --> S8[Система: Освобождает назначенные ресурсы]
    S8 --> S9[Система: Уведомляет клиента и техника]
    S9 --> End([Конец])
    S2 --> End

Функциональные требования

RQ128. Требование к проверке возможности отмены. Отмена разрешена для заказов со статусами: NEW, CONFIRMED, ASSIGNED, EN_ROUTE. Запрещена для: CHARGING, COMPLETED, CANCELLED, FAILED.

RQ129. Требование к обязательной причине. Диспетчер обязан выбрать причину отмены из предопределенного справочника и может добавить текстовый комментарий.

RQ130. Требование к расчету возврата. Система должна рассчитать сумму возврата на основе:

Стадии выполнения заказа
Фактически потребленных ресурсов
Действующих тарифов на штрафы

RQ131. Требование к освобождению ресурсов. При отмене Система должна:

Убрать заказ из маршрута техника
Обновить рабочую смену
Освободить зарезервированное время техника

UC011: Массовые операции с заказами

Описание: Диспетчер выполняет операции над группой выбранных заказов.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Выбирает заказы в списке<br/>с помощью чекбоксов]
    A1 --> A2[Пользователь: Нажимает Массовые операции]
    A2 --> S1[Система: Отображает меню операций]
    S1 --> D1{Выбор операции}
    D1 -->|Назначить в маршрут| A3[Пользователь: Выбирает маршрут]
    D1 -->|Изменить статус| A4[Пользователь: Выбирает новый статус]
    D1 -->|Отменить заказы| A5[Пользователь: Выбирает причину]
    D1 -->|Экспорт| A6[Пользователь: Выбирает формат экспорта]
    A3 --> S2[Система: Назначает заказы в маршрут]
    A4 --> S3[Система: Изменяет статус у всех заказов]
    A5 --> S4[Система: Отменяет выбранные заказы]
    A6 --> S5[Система: Экспортирует данные заказов]
    S2 --> S6[Система: Отображает результат операции]
    S3 --> S6
    S4 --> S6  
    S5 --> S7[Система: Предлагает скачать файл]
    S6 --> End([Конец])
    S7 --> End

Функциональные требования

RQ132. Требование к выбору заказов. Пользователь должен иметь возможность:

Выбирать заказы индивидуально через чекбоксы
Выбирать все заказы на странице
Выбирать все заказы по текущему фильтру

RQ133. Требование к доступным массовым операциям:

Назначение в маршрут: для заказов со статусами NEW, CONFIRMED
Изменение статуса: только разрешенные переходы
Массовая отмена: для активных заказов с обязательной причиной
Экспорт: в форматах Excel, CSV с выбираемым набором полей

RQ134. Требование к валидации массовых операций. Система должна:

Проверить применимость операции к каждому заказу
Показать предупреждение о заказах, к которым операция неприменима
Дать возможность продолжить операцию только для подходящих заказов

RQ135. Требование к отчету о результатах. После выполнения массовой операции Система должна показать:

Количество успешно обработанных заказов
Количество заказов с ошибками
Детали ошибок для заказов, которые не удалось обработать

RQ136. Требование к экспорту данных. Функция экспорта должна включать:

Настраиваемый набор полей для экспорта
Форматы: Excel (.xlsx), CSV (.csv)
Экспорт с учетом текущих фильтров и сортировки
Лимит: не более 1000 заказов за один экспорт

Общие требования к блоку «Управление заказами»

Требования к безопасности

RQ137. Требование к авторизации. Все функции блока доступны только пользователям с ролью ДИСПЕТЧЕР или АДМИНИСТРАТОР.

RQ138. Требование к аудиту. Все действия диспетчера должны логироваться с указанием:

Типа операции
Идентификатора заказа
Пользователя-инициатора
Времени операции
Измененных данных (до/после)

Требования к производительности

RQ139. Требование к времени отклика. Загрузка списка заказов должна выполняться не более чем за 3 секунды при нагрузке до 10 000 заказов.

RQ140. Требование к оптимизации запросов. Система должна использовать индексы для ускорения поиска и фильтрации по полям:

Orders.status
Orders.createdAt
Orders.scheduledDate
Orders.orderNumber
Clients.firstName, Clients.lastName

Требования к интеграции

RQ141. Требование к real-time обновлениям. Изменения статусов заказов должны отображаться в интерфейсе диспетчера в реальном времени через WebSocket-соединение.

RQ142. Требование к уведомлениям. При изменении важных параметров заказа должны отправляться уведомления:

Клиенту - при изменении времени, отмене, назначении техника
Технику - при назначении заказа, изменении адреса или времени
Другим диспетчерам - при критических изменениях

ТЗ на модуль Диспетчера

Техническое задание на разработку модуля диспетчера системы «MobileCharge»

Оглавление

1. Общие положения

2. Требования к набору функциональных блоков модуля диспетчера

2.1. Блок «Дашбоард диспетчера»

2.2. Блок «Управление заказами»

2.3. Блок «Управление маршрутами»

2.4. Блок «Управление автопарком»

2.5. Блок «Управление зарядными станциями»

2.6. Блок «Управление техниками»

2.7. Блок «Обработка обращений клиентов»

2.8. Блок «Управление справочниками»

3. Требования к интерфейсу модуля диспетчера

4. Требования к безопасности и разграничению доступа

5. Интеграционные требования

Список основных функций модуля диспетчера

Основные функциональные области:

Ключевые возможности:

Блок «Дашбоард диспетчера»

UC001: Просмотр оперативной сводки по заказам

Activity-диаграмма (Диаграмма деятельности)

Модель интерфейсов

Функциональные требования

UC002: Просмотр активных маршрутов и карты

Activity-диаграмма (Диаграмма деятельности)

Модель интерфейсов

Функциональные требования

UC003: Анализ выполнения маршрутов

Activity-диаграмма (Диаграмма деятельности)

Модель интерфейсов

Функциональные требования

UC004: Обработка обращений клиентов

Activity-диаграмма (Диаграмма деятельности)

Модель интерфейсов

Функциональные требования

Модель интерфейсов дашбоарда

Общая компоновка дашбоарда

Технические требования к дашбоарду

Требования к компоновке

Требования к взаимодействию в реальном времени

Требования к производительности

Блок «Управление заказами» - Модуль диспетчера

UC005: Просмотр списка заказов с фильтрацией

Activity-диаграмма (Диаграмма деятельности)

Модель интерфейсов

Функциональные требования

UC006: Просмотр детальной информации заказа

Activity-диаграмма (Диаграмма деятельности)

Функциональные требования

UC007: Редактирование параметров заказа

Activity-диаграмма (Диаграмма деятельности)

Модель интерфейсов

Функциональные требования

UC008: Изменение статуса заказа

Activity-диаграмма (Диаграмма деятельности)

Функциональные требования

UC009: Создание нового заказа (от имени клиента)

Activity-диаграмма (Диаграмма деятельности)

Функциональные требования

UC010: Отмена заказа с указанием причины

Activity-диаграмма (Диаграмма деятельности)

Функциональные требования

UC011: Массовые операции с заказами

Activity-диаграмма (Диаграмма деятельности)

Функциональные требования

Общие требования к блоку «Управление заказами»

Требования к безопасности

Требования к производительности

Требования к интеграции