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

Техническое задание на разработку модуля диспетчера системы «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([Конец])

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

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

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. Требование к уведомлениям. При изменении важных параметров заказа должны отправляться уведомления:

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

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

UC012: Просмотр списка маршрутов

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

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

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

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

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

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

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

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

RQ203. Требование к фильтрации по статусу. Система должна предоставлять мультиселект фильтр по Routes.status со всеми возможными значениями: PLANNED, IN_PROGRESS, COMPLETED, CANCELLED.

RQ204. Требование к фильтрации по технику. Система должна предоставлять поле автодополнения для поиска техника по Users.firstName, Users.lastName с ролью TECHNICIAN.

RQ205. Требование к функции поиска. При вводе текста в поле поиска Система должна искать по вхождению подстроки в номер маршрута и имя техника.

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

Идентификатор маршрута
Цветовой индикатор статуса
ФИО назначенного техника
Дату маршрута
Количество заказов в маршруте
Плановое время начала и окончания
Прогресс выполнения (процент выполненных заказов)

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

"Просмотр" - всегда доступна
"Редактировать" - доступна для статусов PLANNED
"Отслеживать" - доступна для статуса IN_PROGRESS

UC013: Создание нового маршрута

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

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

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Создать маршрут]
    A1 --> S1[Система: Отображает форму создания маршрута<br/>link: ФормаСозданияМаршрута]
    S1 --> S2[Система: Автоматически устанавливает базу<br/>как начальную и конечную точки]
    S2 --> A2[Пользователь: Заполняет дату маршрута]
    A2 --> A3[Пользователь: Выбирает заказы для маршрута]
    A3 --> S3[Система: Рассчитывает плановые времена<br/>для каждой точки маршрута]
    S3 --> S4[Система: Рассчитывает энергозатраты<br/>по алгоритму]
    S4 --> D1{Энергии достаточно?}
    D1 -->|Нет| S5[Система: Отображает предупреждение<br/>и предлагает альтернативы]
    D1 -->|Да| A4[Пользователь: Нажимает Создать]
    A4 --> S6[Система: Валидирует введенные данные]
    S6 --> D2{Данные корректны?}
    D2 -->|Нет| S7[Система: Отображает ошибки валидации]
    D2 -->|Да| S8[Система: Создает маршрут со статусом PLANNED]
    S8 --> S9[Система: Создает записи в RoutePoints для заказов]
    S9 --> S10[Система: Отображает подтверждение создания]
    S10 --> End([Конец])
    S5 --> A3
    S7 --> A2

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

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

Дата маршрута (Routes.routeDate)
Начальный адрес должен быть координатами базы (Routes.startAddress, startLatitude, startLongitude)
Конечный адрес должен быть координатами базы (Routes.endAddress, endLatitude, endLongitude)

RQ209. Требование к выбору заказов. Система должна отображать только заказы со статусами NEW и CONFIRMED, не назначенные на другие маршруты.

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

status = PLANNED
createdBy = текущий диспетчер
createdAt = текущее время

RQ211. Требование к обязательности базы. Маршрут должен обязательно начинаться и заканчиваться на базе. Система должна автоматически устанавливать координаты базы как начальную и конечную точки маршрута.

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

Плановое время выезда с предыдущей точки (RoutePoints.plannedDepartureTime)
Плановое время прибытия на точку заказа (RoutePoints.plannedArrivalTime)
Ожидаемое время в пути между точками (RoutePoints.expectedTravelTimeMinutes)

RQ213. Требование к расчету энергозатрат. При добавлении заказов в маршрут Система должна рассчитывать достаточность заряда по следующему алгоритму:

Алгоритм расчета энергозатрат:

Шаг 1. Расчет энергозатрат автомобиля техника:

Общее_расстояние_маршрута = Расстояние_от_базы_до_первого_заказа + 
                             Сумма_расстояний_между_заказами + 
                             Расстояние_от_последнего_заказа_до_базы

Энергозатраты_на_поездку = Общее_расстояние_маршрута × Расход_автомобиля_кВтч_на_км

Минимальный_заряд_автомобиля = Энергозатраты_на_поездку × 1.2  // 20% запас

Шаг 2. Расчет энергозатрат зарядной станции:

Суммарная_энергия_для_зарядки = Сумма_всех_chargeValue_в_заказах_маршрута

Энергия_для_подзарядки_автомобиля = ЕСЛИ (Текущий_заряд_автомобиля < Минимальный_заряд_автомобиля)
                                   ТО (Минимальный_заряд_автомобиля - Текущий_заряд_автомобиля)
                                   ИНАЧЕ 0

Минимальная_энергия_станции = Суммарная_энергия_для_зарядки + 
                              Энергия_для_подзарядки_автомобиля × 1.1  // 10% запас

Шаг 3. Проверка достаточности:

ЕСЛИ (Текущий_заряд_автомобиля >= Минимальный_заряд_автомобиля И 
      Текущий_заряд_станции >= Минимальная_энергия_станции)
ТО Маршрут_возможен = ИСТИНА
ИНАЧЕ Маршрут_возможен = ЛОЖЬ

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

Время окончания маршрута (plannedEndTime)
Время начала следующего запланированного маршрута для этого комплекта
Между ними должно быть минимум 4 часа для зарядки автомобиля и станции на базе

RQ215. Требование к валидации энергозатрат. Если расчет показывает недостаточность энергии, Система должна:

Отобразить предупреждение с детализацией проблемы
Предложить альтернативы: уменьшить количество заказов, выбрать другой комплект оборудования
Не позволить создать маршрут до устранения проблемы

RQ216. Требование к отображению энергетической информации. В форме создания маршрута Система должна отображать:

Текущий уровень заряда выбранного автомобиля и станции
Расчетные энергозатраты маршрута
Остаток энергии после выполнения маршрута
Цветовую индикацию (зеленый - достаточно, желтый - критично, красный - недостаточно)

UC015: Редактирование маршрута (добавление/удаление заказов)

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

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

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

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

RQ223. Требование к проверке возможности редактирования. Система должна разрешать редактирование только для маршрутов со статусом PLANNED.

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

Показывать только заказы со статусами NEW, CONFIRMED
Исключать заказы, уже назначенные на другие маршруты
Проверять совместимость по времени и географии
Автоматически пересчитывать энергозатраты по алгоритму из RQ213

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

Изменить статус заказа обратно на CONFIRMED
Удалить соответствующую запись из RoutePoints
Пересчитать плановые времена для оставшихся заказов
Пересчитать энергозатраты маршрута

RQ226. Требование к изменению порядка. Система должна позволять изменять orderIndex в RoutePoints с автоматическим пересчетом всех плановых времен и энергозатрат.

UC016: Назначение ресурсов на маршрут (техник + комплект ТС и станции)

Описание: Диспетчер назначает на маршрут техника и комплект оборудования (сервисное ТС + зарядная станция).

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

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

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

RQ217. Требование к доступности техников. Система должна отображать только техников (Users с ролью TECHNICIAN), которые:

Имеют статус isActive = true
Не назначены на другие активные маршруты в ту же дату

RQ218. Требование к доступности оборудования. Система должна отображать только комплекты, где:

ServiceVehicles.status = AVAILABLE
ChargingStations.status = AVAILABLE
Существует связь в StationVehicleAssignments

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

Время окончания данного маршрута (Routes.plannedEndTime)
Время начала следующего запланированного маршрута для этого комплекта
Между окончанием текущего и началом следующего маршрута должно быть минимум 4 часа
Если интервал меньше 4 часов, комплект должен быть исключен из списка доступных

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

Установить Routes.idTechnician = выбранный техник
Установить Routes.idServiceVehicle = выбранное ТС
Установить Routes.idChargingStation = выбранная станция
Изменить статусы оборудования на IN_USE

RQ221. Требование к созданию рабочей смены. Система должна автоматически создать запись в WorkShifts с:

idTechnician = назначенный техник
shiftDate = дата маршрута
plannedStartTime и plannedEndTime = времена маршрута
status = PLANNED

RQ222. Требование к валидации временных интервалов. Если выбранный комплект не удовлетворяет требованию 4-часового интервала, Система должна:

Отобразить предупреждение с указанием конфликтующих маршрутов
Показать точное время окончания предыдущего и начала следующего маршрута
Предложить альтернативные комплекты или изменение времени маршрута

UC017: Просмотр детальной информации маршрута

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

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

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

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

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

Идентификатор и статус маршрута
Дату маршрута
Начальный и конечный адреса
Плановые времена начала и окончания
Фактические времена (если доступны)

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

Номер заказа и его статус
Адрес выполнения
Плановое время прибытия
Фактическое время прибытия (если есть)
Статус выполнения

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

ФИО и контакты техника
Информацию о сервисном ТС (номер, модель)
Информацию о зарядной станции (модель, серийный номер)

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

Плановыми точками маршрута
Фактическим прогрессом выполнения
Отклонениями от графика

UC018: Отслеживание выполнения маршрута в реальном времени

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

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

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

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

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

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

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

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

Текущую позицию техника с актуальными координатами
Траекторию маршрута с запланированными точками
Маркеры заказов с цветовой индикацией статусов

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

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

RQ235. Требование к критическим уведомлениям. При отклонении от графика более чем на 30 минут Система должна отображать предупреждение с предложением связаться с техником.

UC019: Завершение и архивирование маршрута

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

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

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

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

RQ236. Требование к проверке готовности к завершению. Система должна разрешать завершение маршрута только если все заказы в нем имеют статусы COMPLETED, CANCELLED или FAILED.

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

Изменить Routes.status на COMPLETED
Установить Routes.actualEndTime = текущее время
Обновить Routes.updatedBy = текущий диспетчер

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

Изменить WorkShifts.status на COMPLETED
Установить ServiceVehicles.status = AVAILABLE
Установить ChargingStations.status = AVAILABLE

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

Общее время выполнения маршрута
Отклонения от планового времени
Количество успешно выполненных заказов
Эффективность выполнения маршрута

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

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

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

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

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

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

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

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

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

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

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

RQ246. Требование к синхронизации с заказами. При изменении состава заказов в маршруте должны автоматически обновляться статусы соответствующих заказов (ASSIGNED при добавлении, CONFIRMED при удалении).

RQ247. Требование к консистентности данных. Все операции с маршрутами должны выполняться в рамках транзакций для обеспечения целостности данных между связанными таблицами Routes, RoutePoints, WorkShifts и статусами ресурсов.

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

UC020: Просмотр списка сервисных ТС

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

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

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

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

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

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

RQ301. Требование к загрузке списка ТС. Система должна загружать сервисные ТС со всеми статусами, сортированные по ServiceVehicles.licensePlate в алфавитном порядке.

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

RQ303. Требование к фильтрации по статусу. Система должна предоставлять мультиселект фильтр по ServiceVehicles.status со значениями: AVAILABLE, IN_USE, MAINTENANCE, UNAVAILABLE.

RQ304. Требование к фильтру по необходимости ТО. Фильтр "Требуется ТО" должен показывать ТС, у которых:

currentMileageKm - lastServiceMileageKm >= serviceIntervalKm ИЛИ
Дата последнего ТО + serviceIntervalMonths <= текущая дата

RQ305. Требование к функции поиска. При вводе текста Система должна искать по вхождению подстроки в ServiceVehicles.licensePlate, ServiceVehicles.brand, ServiceVehicles.model.

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

Государственный номер
Бренд и модель ТС
Цветовой индикатор статуса
Текущий пробег
Назначенную зарядную станцию (если есть)
Индикатор необходимости ТО

RQ307. Требование к индикатору ТО. Индикатор должен показывать:

Зеленый: ТО не требуется
Желтый: ТО потребуется в ближайший месяц (на основе статистики использования)
Красный: ТО просрочено

UC021: Добавление нового сервисного ТС

Описание: Диспетчер добавляет новое сервисное транспортное средство в систему.

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

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

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

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

Государственный номер (licensePlate)
Бренд (brand)
Модель (model)
Интервал ТО в км (serviceIntervalKm)
Интервал ТО в месяцах (serviceIntervalMonths)
Текущий пробег (currentMileageKm)

RQ309. Требование к валидации госномера. Система должна проверять уникальность licensePlate среди всех ServiceVehicles.

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

status = AVAILABLE
createdBy = текущий диспетчер
createdAt = текущее время

UC022: Редактирование информации о сервисном ТС

Описание: Диспетчер изменяет информацию о сервисном ТС, включая параметры технического обслуживания.

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

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

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

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

Бренд и модель ТС
Параметры технического обслуживания
Текущий пробег
Примечания

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

Государственный номер (только при создании)
Статус ТС (только через UC023)
Даты создания и технической информации

UC023: Управление статусом ТС

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

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

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

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

RQ313. Требование к переходам статусов. Разрешенные переходы статусов:

AVAILABLE → IN_USE, MAINTENANCE, UNAVAILABLE
IN_USE → AVAILABLE, MAINTENANCE, UNAVAILABLE
MAINTENANCE → AVAILABLE, UNAVAILABLE
UNAVAILABLE → AVAILABLE (после устранения проблем)

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

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

UC024: Просмотр истории использования ТС

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

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

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

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

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

Полную информацию о ТС
Текущий статус и назначенную зарядную станцию
Статистику использования (общий пробег, количество маршрутов)

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

Список выполненных маршрутов с датами
Общее количество километров по маршрутам
Расход энергии по маршрутам

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

Дату последнего ТО и пробег
Дату следующего планового ТО
Список всех проведенных ТО

RQ319. Требование к переназначению станции. Диспетчер должен иметь возможность:

Просмотреть текущую назначенную станцию
Выбрать новую станцию из доступных
Отвязать станцию от ТС

UC025: Планирование и учет технического обслуживания ТС

Описание: Диспетчер планирует и регистрирует проведенное техническое обслуживание сервисного ТС.

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

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Запланировать ТО]
    A1 --> S1[Система: Отображает форму планирования ТО]
    S1 --> A2[Пользователь: Выбирает тип действия]
    A2 --> D1{Тип действия}
    D1 -->|Запланировать| A3[Пользователь: Указывает дату планового ТО]
    D1 -->|Зарегистрировать выполненное| A4[Пользователь: Заполняет данные о проведенном ТО]
    A3 --> S2[Система: Сохраняет плановую дату ТО]
    A4 --> S3[Система: Создает запись в ServiceVehicleMaintenances]
    A4 --> S4[Система: Обновляет lastServiceDate и lastServiceMileageKm]
    S4 --> S5[Система: Рассчитывает nextMaintenanceDate]
    S5 --> S6[Система: Переводит ТС в статус AVAILABLE если было MAINTENANCE]
    S2 --> End([Конец])
    S6 --> End

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

RQ320. Требование к планированию ТО. Диспетчер должен иметь возможность:

Запланировать дату следующего ТО
Указать тип планового ТО (плановое/внеплановое)
Добавить комментарии к плановому ТО

RQ321. Требование к регистрации выполненного ТО. При регистрации ТО обязательны:

Дата проведения ТО (maintenanceDate)
Пробег на момент ТО (mileageKm)
Описание выполненных работ (description)
Стоимость ТО (опционально)

RQ322. Требование к автоматическому расчету. При регистрации ТО Система должна:

Обновить lastServiceDate и lastServiceMileageKm в ServiceVehicles
Рассчитать nextMaintenanceDate = maintenanceDate + serviceIntervalMonths
Рассчитать nextMaintenanceMileageKm = mileageKm + serviceIntervalKm

UC026: Деактивация/архивирование ТС

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

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

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Деактивировать ТС]
    A1 --> S1[Система: Проверяет использование ТС]
    S1 --> S2[Система: Загружает связанные маршруты]
    S2 --> S3[Система: Загружает назначенные станции]
    S3 --> D1{Есть активные связи?}
    D1 -->|Да| S4[Система: Отображает предупреждение со списком связей]
    D1 -->|Нет| S5[Система: Отображает форму деактивации]
    S4 --> A2[Пользователь: Просматривает список маршрутов и комплектов]
    A2 --> A3[Пользователь: Принимает решение о продолжении]
    A3 --> D2{Продолжить деактивацию?}
    D2 -->|Нет| End([Конец])
    D2 -->|Да| S5
    S5 --> A4[Пользователь: Указывает причину деактивации]
    A4 --> A5[Пользователь: Нажимает Подтвердить]
    A5 --> S6[Система: Устанавливает isDeleted = true]
    S6 --> S7[Система: Отвязывает назначенные станции]
    S7 --> S8[Система: Логирует деактивацию]
    S8 --> End

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

RQ323. Требование к проверке перед деактивацией. Система должна проверить и отобразить:

Список активных маршрутов (Routes со статусами PLANNED, IN_PROGRESS)
Список назначенных зарядных станций через StationVehicleAssignments

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

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

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

Установить ServiceVehicles.isDeleted = true
Удалить активные записи из StationVehicleAssignments
Сохранить причину деактивации в аудит-лог

RQ326. Требование к мягкому удалению. Деактивированные ТС должны:

Исключаться из основных рабочих списков
Оставаться доступными в отчетах и истории
Иметь возможность восстановления администратором

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

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

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

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

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

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

RQ329. Требование к времени отклика. Загрузка списка ТС должна выполняться не более чем за 2 секунды при нагрузке до 500 ТС.

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

ServiceVehicles.licensePlate
ServiceVehicles.status
ServiceVehicles.brand, ServiceVehicles.model

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

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

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

О приближающемся сроке ТО (за 7 дней)
О просроченном ТО
При критических изменениях статуса ТС

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

Техническое задание на разработку модуля диспетчера системы «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-диаграмма (Диаграмма деятельности)

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

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

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

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

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

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

UC012: Просмотр списка маршрутов

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

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

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

UC013: Создание нового маршрута

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

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

Алгоритм расчета энергозатрат:

UC015: Редактирование маршрута (добавление/удаление заказов)