ТЗ на модуль Техника

СТРУКТУРА ТЕХНИЧЕСКОГО ЗАДАНИЯ МОДУЛЯ ТЕХНИКА

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

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

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

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

2.3. Блок «Выполнение заказов»

2.4. Блок «Взаимодействие с клиентами»

2.5. Блок «Мониторинг оборудования»

2.6. Блок «Навигация и геолокация»

2.7. Блок «Отчетность и история»

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

4. Требования к геолокации и автоматизации

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

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

СПИСОК ФУНКЦИЙ МОДУЛЯ ТЕХНИКА

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

UC001: Просмотр расписания рабочих смен
UC002: Начало рабочей смены
UC003: Завершение рабочей смены
UC004: Просмотр информации о текущей смене
UC005: Просмотр истории рабочих смен

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

UC006: Получение и просмотр назначенного маршрута
UC007: Принятие назначенного маршрута
UC008: Отклонение маршрута с указанием причины
UC009: Просмотр детальной информации маршрута
UC010: Отслеживание прогресса выполнения маршрута

2.3. Блок «Выполнение заказов»

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

2.4. Блок «Взаимодействие с клиентами»

UC020: Просмотр контактной информации клиента (без номера телефона)
UC021: Отправка сообщений в чат с клиентом
UC022: Получение сообщений от клиента
UC023: Просмотр истории переписки с клиентом по заказу

2.5. Блок «Мониторинг оборудования»

UC024: Просмотр статуса сервисного ТС
UC025: Просмотр статуса зарядной станции
UC026: Создание заявки на неисправность ТС
UC027: Создание заявки на неисправность зарядной станции
UC028: Просмотр истории заявок на неисправности
UC029: Просмотр технических характеристик оборудования

2.6. Блок «Навигация и геолокация»

UC030: Автоматическая передача GPS-координат в систему
UC031: Построение маршрута к адресу заказа
UC032: Пошаговая навигация к клиенту
UC033: Автоматическое определение прибытия в геозону заказа
UC034: Отображение текущего местоположения на карте

2.7. Блок «Отчетность и история»

UC035: Просмотр статистики выполненных заказов
UC036: Просмотр статистики рабочего времени
UC037: Формирование отчета о рабочем дне
UC038: Просмотр рейтинга и оценок от клиентов

Ключевые особенности модуля:

Автоматизация на основе GPS:

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

Фотодокументирование:

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

Коммуникация:

Защищенный чат с клиентами без раскрытия телефонов
Автоматические уведомления клиентам о статусе заказа
Интеграция с системой уведомлений диспетчера

Мониторинг оборудования:

Получение данных о состоянии МЗС от серверной части
Система заявок на неисправности с фотофиксацией
Автоматический журнал операций с оборудованием

Предлагаемые действия техника по статусам

Рабочая смена:

PLANNED → ACTIVE: "Начать смену" (техник отмечается на работу)
ACTIVE → COMPLETED: "Завершить смену" (техник завершает рабочий день)

Маршрут:

ASSIGNED: Техник получает уведомление и может "Принять маршрут" или "Отклонить с причиной"
ASSIGNED → IN_PROGRESS: "Принять маршрут"
IN_PROGRESS → COMPLETED: автоматически при завершении всех заказов в маршруте

Заказ:

ASSIGNED → EN_ROUTE: "Выехал к клиенту" (или автоматически при начале движения)
EN_ROUTE → ARRIVED: автоматически по GPS при входе в геозону адреса (радиус ~100м)
ARRIVED → CHARGING: "Начать зарядку" + обязательное фото подключения
CHARGING → COMPLETED: "Завершить зарядку" + фото отключения и показаний счетчика
Любой статус → FAILED: "Сообщить о проблеме" + причина + фото

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

Общее описание блока

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

Основные возможности блока:

Просмотр расписания запланированных смен
Начало рабочей смены с геолокационным контролем
Мониторинг текущей активной смены
Завершение смены с указанием причин досрочного завершения
Отмена смены с выбором причины
Просмотр истории выполненных смен
Получение push-уведомлений о предстоящих сменах

UC001: Просмотр расписания рабочих смен

Актор: Техник

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

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

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

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

classDiagram
    class ЭкранРасписанияСмен {
        <<Screen>>
        +ВыборПериода : DateRangePicker
        +КалендарьСмен : CalendarView
        +СписокСмен : ListView
        +КнопкаОбновить : Button
    }
    
    class КарточкаСмены {
        <<Area>>
        +ДатаСмены : Label
        +ВремяНачалаОкончания : Label
        +БазаНачала : Label
        +БазаОкончания : Label
        +СтатусСмены : StatusBadge
        +КнопкаОтменить : Button
    }
    
    class ФормаОтменыСмены {
        <<Screen>>
        +ИнформацияОСмене : Area
        +ПричинаОтмены : DropDown*
        +Комментарий : TextArea[300]
        +КнопкаПодтвердить : Button
        +КнопкаОтмена : Button
    }
    
    ЭкранРасписанияСмен *-- КарточкаСмены

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

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

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

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

Дату и время смены
База начала и окончания смены
Статус смены (Запланирована/Активна/Завершена/Отменена)
Количество заказов в смене (если есть назначенные маршруты)

RQ004. Требование к возможности отмены. Техник может отменить смену только со статусом PLANNED не позднее чем за 2 часа до ее начала.

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

Болезнь
Семейные обстоятельства
Технические проблемы с ТС
Форс-мажор
Другое (с обязательным комментарием)

RQ006. Требование к уведомлению диспетчера. При отмене смены техником система должна автоматически уведомить ответственного диспетчера с указанием причины и времени отмены.

UC002: Начало рабочей смены

Актор: Техник

Описание: Техник начинает запланированную рабочую смену с проверкой геолокации и временного интервала.

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

graph TD
    Start([Начало]) --> A1[Техник: Нажимает 'Начать смену']
    A1 --> S1[Система: Проверяет наличие запланированной смены]
    S1 --> D1{Есть запланированная смена?}
    D1 -->|Нет| S2[Система: Отображает сообщение об отсутствии смены]
    D1 -->|Да| S3[Система: Проверяет время начала смены]
    S3 --> D2{Время начала смены подошло?}
    D2 -->|Нет| S4[Система: Отображает время до начала смены]
    D2 -->|Да| S5[Система: Запрашивает текущую геолокацию]
    S5 --> S6[Система: Проверяет расстояние до базы начала смены]
    S6 --> D3{Техник находится рядом с базой?}
    D3 -->|Нет| S7[Система: Отображает сообщение о необходимости<br/>приблизиться к базе]
    D3 -->|Да| S8[Система: Отображает подтверждение начала смены<br/>ссылка: ЭкранПодтвержденияНачалаСмены]
    S8 --> A2[Техник: Подтверждает начало смены]
    A2 --> S9[Система: Изменяет статус смены на ACTIVE]
    S9 --> S10[Система: Устанавливает actualStartTime = текущее время]
    S10 --> S11[Система: Записывает GPS-координаты начала смены]
    S11 --> S12[Система: Отображает экран активной смены]
    S12 --> End([Конец])
    S2 --> End
    S4 --> End
    S7 --> End

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

classDiagram
    class ЭкранПодтвержденияНачалаСмены {
        <<Screen>>
        +ИнформацияОСмене : Area
        +ТекущееВремя : Label
        +БазаНачала : Label
        +ТекущееМестоположение : Label
        +КнопкаНачатьСмену : Button
        +КнопкаОтмена : Button
    }
    
    class ЭкранАктивнойСмены {
        <<Screen>>
        +СтатусСмены : StatusIndicator
        +ВремяНачала : Label
        +ПрошедшееВремя : Timer
        +ОставшеесяВремя : Label
        +КнопкаЗавершитьСмену : Button
        +КнопкаПросмотретьМаршруты : Button
    }

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

RQ007. Требование к временному окну начала смены. Техник может начать смену не ранее чем за 15 минут до запланированного времени начала и не позднее чем через 30 минут после запланированного времени.

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

RQ009. Требование к проверке предыдущей смены. Система должна проверить, что предыдущая смена техника завершена (статус COMPLETED или CANCELLED).

RQ010. Требование к автоматическим полям. При начале смены система должна автоматически:

Установить WorkShifts.status = ACTIVE
Установить WorkShifts.actualStartTime = текущее время
Записать GPS-координаты места начала смены
Создать запись в журнале операций техника

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

UC003: Завершение рабочей смены

Актор: Техник

Описание: Техник завершает активную рабочую смену с возможностью досрочного завершения и указания причин.

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

graph TD
    Start([Начало]) --> A1[Техник: Нажимает 'Завершить смену']
    A1 --> S1[Система: Проверяет статус текущей смены]
    S1 --> D1{Есть активная смена?}
    D1 -->|Нет| S2[Система: Отображает сообщение об отсутствии активной смены]
    D1 -->|Да| S3[Система: Проверяет завершенность текущих маршрутов]
    S3 --> D2{Есть незавершенные маршруты?}
    D2 -->|Да| S4[Система: Отображает предупреждение о незавершенных маршрутах]
    D2 -->|Нет| S5[Система: Проверяет время завершения]
    S5 --> D3{Досрочное завершение?}
    D3 -->|Да| S6[Система: Отображает форму досрочного завершения<br/>ссылка: ФормаДосрочногоЗавершения]
    D3 -->|Нет| S7[Система: Отображает стандартную форму завершения<br/>ссылка: ФормаЗавершенияСмены]
    S6 --> A2[Техник: Выбирает причину досрочного завершения]
    S7 --> A3[Техник: Подтверждает завершение смены]
    A2 --> A4[Техник: Опционально добавляет комментарий]
    A4 --> A5[Техник: Подтверждает завершение]
    A3 --> S8[Система: Запрашивает геолокацию для завершения]
    A5 --> S8
    S8 --> S9[Система: Проверяет местоположение базы окончания]
    S9 --> D4{Техник рядом с базой окончания?}
    D4 -->|Нет| S10[Система: Отображает предупреждение о расстоянии]
    D4 -->|Да| S11[Система: Изменяет статус смены на COMPLETED]
    S11 --> S12[Система: Устанавливает actualEndTime = текущее время]
    S12 --> S13[Система: Записывает GPS-координаты завершения]
    S13 --> S14[Система: Рассчитывает общее время работы]
    S14 --> S15[Система: Отображает итоги смены]
    S15 --> End([Конец])
    S2 --> End
    S4 --> End
    S10 --> A6[Техник: Принимает решение]
    A6 --> D5{Завершить принудительно?}
    D5 -->|Да| S11
    D5 -->|Нет| End

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

classDiagram
    class ФормаЗавершенияСмены {
        <<Screen>>
        +ИтогиСмены : Area
        +ОтработанноеВремя : Label
        +КоличествоВыполненныхЗаказов : Label
        +ТекущееМестоположение : Label
        +БазаОкончания : Label
        +КнопкаЗавершить : Button
        +КнопкаОтмена : Button
    }
    
    class ФормаДосрочногоЗавершения {
        <<Screen>>
        +ИнформацияОСмене : Area
        +ПричинаДосрочногоЗавершения : DropDown*
        +Комментарий : TextArea[300]
        +КнопкаЗавершить : Button
        +КнопкаОтмена : Button
    }
    
    class ЭкранИтоговСмены {
        <<Screen>>
        +ОбщееВремяРаботы : Label
        +ВыполненоЗаказов : Label
        +СтатистикаДня : Area
        +КнопкаПродолжить : Button
    }

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

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

RQ013. Требование к досрочному завершению. Если смена завершается более чем за 30 минут до запланированного времени, система должна запросить причину досрочного завершения:

Выполнены все задачи
Технические проблемы с оборудованием
Проблемы со здоровьем
Семейные обстоятельства
Форс-мажор
Другое (с обязательным комментарием)

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

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

Установить WorkShifts.status = COMPLETED
Установить WorkShifts.actualEndTime = текущее время
Рассчитать WorkShifts.totalWorkedMinutes
Записать GPS-координаты завершения смены
Обновить статистику техника

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

UC004: Просмотр информации о текущей смене

Актор: Техник

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

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

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

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

classDiagram
    class ЭкранТекущейСмены {
        <<Screen>>
        +СтатусСмены : StatusIndicator
        +ВременныеМетрики : ОбластьВременныхМетрик
        +ИнформацияОСмене : ОбластьИнформацииОСмене
        +ТекущиеМаршруты : ОбластьМаршрутов
        +КнопкаЗавершитьСмену : Button
        +КнопкаПросмотретьМаршруты : Button
    }
    
    class ОбластьВременныхМетрик {
        <<Area>>
        +ВремяНачала : Label
        +ТекущееВремя : LiveTimer
        +ОтработанноеВремя : Timer
        +ОставшеесяВремя : Label
        +ПрогрессБар : ProgressBar
    }
    
    class ОбластьИнформацииОСмене {
        <<Area>>
        +БазаНачала : Label
        +БазаОкончания : Label
        +ЗапланированноеВремя : Label
        +ТекущееМестоположение : LocationView
    }
    
    class ОбластьМаршрутов {
        <<Area>>
        +КоличествоМаршрутов : Label
        +ВыполненныеМаршруты : Label
        +ТекущийМаршрут : RouteCard
    }
    
    ЭкранТекущейСмены *-- ОбластьВременныхМетрик
    ЭкранТекущейСмены *-- ОбластьИнформацииОСмене
    ЭкранТекущейСмены *-- ОбластьМаршрутов

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

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

Время начала смены
Текущее отработанное время
Оставшееся время до конца смены
Прогресс выполнения смены в процентах

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

База начала и окончания смены
Запланированное время начала и окончания
Текущее местоположение техника
Статус смены

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

Количество назначенных маршрутов на смену
Количество выполненных маршрутов
Информацию о текущем активном маршруте
Прогресс выполнения заказов в маршрутах

RQ020. Требование к обновлению данных. Информация о текущей смене должна обновляться:

Автоматически каждые 30 секунд
При выполнении pull-to-refresh пользователем
При изменении статуса связанных маршрутов или заказов

RQ021. Требование к навигации. С экрана текущей смены должны быть доступны переходы:

К списку маршрутов смены
К завершению смены
К просмотру истории смен

UC005: Просмотр истории рабочих смен

Актор: Техник

Описание: Техник просматривает историю всех своих выполненных рабочих смен с детальной статистикой.

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

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

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

classDiagram
    class ЭкранИсторииСмен {
        <<Screen>>
        +ПанельФильтров : ОбластьФильтров
        +СписокСмен : ListView
        +СтатистикаОбщая : ОбластьОбщейСтатистики
        +КнопкаЭкспорт : Button
    }
    
    class ОбластьФильтров {
        <<Area>>
        +ПериодДат : DateRangePicker
        +СтатусСмены : MultiSelectDropDown
        +СортировкаПо : DropDown
        +КнопкаПрименить : Button
        +КнопкаСброс : Button
    }
    
    class КарточкаИсторииСмены {
        <<Area>>
        +ДатаСмены : Label
        +ВремяСмены : Label
        +ДлительностьСмены : Label
        +КоличествоЗаказов : Label
        +СтатусСмены : StatusBadge
        +БазыНачалаОкончания : Label
    }
    
    class ЭкранДеталейСмены {
        <<Screen>>
        +ОсновнаяИнформация : Area
        +ВременныеМетрики : Area
        +СписокМаршрутов : ListView
        +СписокЗаказов : ListView
        +СтатистикаСмены : Area
    }
    
    ЭкранИсторииСмен *-- ОбластьФильтров
    ЭкранИсторииСмен *-- КарточкаИсторииСмены

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

RQ022. Требование к отображению истории. Система должна отображать все смены техника со статусами COMPLETED и CANCELLED, отсортированные по дате по убыванию.

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

По периоду (дата начала и окончания)
По статусу смены (Завершена/Отменена)
По длительности смены
По количеству выполненных заказов

RQ024. Требование к пагинации. Система должна загружать историю смен порциями по 20 записей с возможностью подгрузки следующих порций.

RQ025. Требование к детальной информации о смене. При просмотре деталей смены система должна отображать:

Основную информацию (даты, времена, базы, статус)
Фактическое время работы и отклонения от плана
Список выполненных маршрутов
Список выполненных заказов
Статистику эффективности

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

RQ027. Требование к общей статистике. На экране истории должна отображаться сводная статистика:

Общее количество отработанных смен
Общее время работы
Среднее время смены
Количество выполненных заказов
Процент вовремя начатых/завершенных смен

Системные требования и интеграции

Требования к push-уведомлениям

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

За 24 часа до начала смены: "Напоминание: завтра у вас запланирована смена с [время] до [время] на базе [название]"
За 1 час до начала смены: "Напоминание: через час начинается ваша рабочая смена"
В момент времени начала смены: "Пора начинать рабочую смену! Перейдите в приложение для активации"

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

Включение/отключение уведомлений о сменах
Время предварительных уведомлений
Звуковые сигналы для уведомлений

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

RQ030. Требование к точности геолокации. Система должна использовать GPS с точностью не менее 10 метров для определения местоположения техника.

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

500 метров для начала смены
1000 метров для завершения смены

RQ032. Требование к работе в офлайн режиме. При отсутствии интернет-соединения система должна:

Сохранять GPS-координаты локально
Позволять начало/завершение смены с последующей синхронизацией
Уведомлять о работе в офлайн режиме

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

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

RQ034. Требование к ограничению доступа. Техник может управлять только своими сменами и не имеет доступа к сменам других техников.

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

Времени операции
GPS-координат
Типа операции
Результата операции

Требования к интеграции с другими блоками

RQ036. Требование к связи с блоком маршрутов. Система должна интегрироваться с блоком "Управление маршрутами" для:

Отображения маршрутов, назначенных на смену
Контроля завершенности маршрутов при завершении смены
Автоматического начала маршрутов при активации смены

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

Отправки push-уведомлений о сменах
Уведомления диспетчеров об отменах и опозданиях
Системных уведомлений о статусе смен

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

Модель предметной области (Domain Model)

Основные сущности блока

classDiagram
    class РабочиеСмены {
        +Id : String
        +ТехникId : String
        +ДатаСмены : Date
        +ЗапланированноеВремяНачала : DateTime
        +ЗапланированноеВремяОкончания : DateTime
        +ФактическоеВремяНачала : DateTime
        +ФактическоеВремяОкончания : DateTime
        +Статус : СтатусыСмен
        +БазаНачала : String
        +БазаОкончания : String
        +GPS_Начала : Координаты
        +GPS_Окончания : Координаты
        +ПричинаОтмены : String
        +ПричинаДосрочногоЗавершения : String
        +Комментарий : String
        +ВсегоОтработаноМинут : Number
    }
    
    class СтатусыСмен {
        <<enumeration>>
        PLANNED
        ACTIVE  
        COMPLETED
        CANCELLED
    }
    
    class ПричиныОтменыСмен {
        <<enumeration>>
        Болезнь
        СемейныеОбстоятельства
        ТехническиеПроблемыСТС
        ФорсМажор
        Другое
    }
    
    class ПричиныДосрочногоЗавершения {
        <<enumeration>>
        ВыполненыВсеЗадачи
        ТехническиеПроблемыСОборудованием
        ПроблемыСоЗдоровьем
        СемейныеОбстоятельства
        ФорсМажор
        Другое
    }
    
    class Техники {
        +Id : String
        +Фамилия : String
        +Имя : String
        +Email : String
        +Статус : СтатусыТехников
        +ТекущаяСмена : РабочиеСмены
    }
    
    class УведомленияОСменах {
        +Id : String
        +ТехникId : String
        +СменаId : String
        +ТипУведомления : ТипыУведомленийОСменах
        +ВремяОтправки : DateTime
        +Статус : СтатусыУведомлений
        +ТекстСообщения : String
    }
    
    class ТипыУведомленийОСменах {
        <<enumeration>>
        За24Часа
        За1Час
        ВМоментНачала
        ОбОтмене
        ОбОпоздании
    }
    
    РабочиеСмены --> СтатусыСмен
    РабочиеСмены --> ПричиныОтменыСмен
    РабочиеСмены --> ПричиныДосрочногоЗавершения
    Техники --> РабочиеСмены
    УведомленияОСменах --> РабочиеСмены
    УведомленияОСменах --> ТипыУведомленийОСменах

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

Общее описание блока

Блок «Управление маршрутами» предоставляет технику возможности для работы с назначенными маршрутами в рамках его рабочей смены. Техник может просматривать назначенные маршруты, принимать или отклонять их, отслеживать прогресс выполнения и получать детальную информацию о каждом маршруте.

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

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

UC006: Получение и просмотр назначенного маршрута

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

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

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

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

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

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

RQ040. Требование к получению уведомлений. Система должна отправлять технику push-уведомление при назначении нового маршрута со статусом ASSIGNED.

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

Номер маршрута из Routes.routeNumber
Дата маршрута из Routes.routeDate
Плановое время начала и окончания
Количество заказов в маршруте
База начала и окончания смены

RQ042. Требование к доступности маршрута. Техник может просматривать только маршруты, назначенные конкретно ему (Routes.idTechnician = ID текущего техника).

RQ043. Требование к временным ограничениям. Уведомление о маршруте должно отображаться до тех пор, пока техник не примет решение (принять/отклонить) или пока диспетчер не отменит назначение.

UC007: Принятие назначенного маршрута

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

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

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

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

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

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

RQ044. Требование к проверке доступности маршрута. Система должна проверять, что маршрут имеет статус ASSIGNED и назначен текущему технику.

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

Изменить Routes.status на IN_PROGRESS
Установить Routes.actualStartTime = текущее время
Обновить Routes.updatedBy = идентификатор техника

RQ046. Требование к активации рабочей смены. Система должна изменить статус связанной рабочей смены (WorkShifts.status) на ACTIVE.

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

RQ048. Требование к блокировке повторного принятия. После принятия маршрута кнопка "Принять" должна стать недоступной для всех других уведомлений этого маршрута.

UC008: Отклонение маршрута с указанием причины

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

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

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

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

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

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

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

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

Болезнь
Семейные обстоятельства
Технические проблемы с оборудованием
Превышение рабочего времени
Конфликт с другими обязательствами
Недостаточно времени на подготовку
Другое (с обязательным комментарием)

RQ051. Требование к обязательному комментарию. При выборе причины "Другое" поле комментария становится обязательным для заполнения (максимум 500 символов).

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

Изменить Routes.status на CANCELLED
Сохранить причину отклонения в Routes.cancellationReason
Сохранить комментарий техника в Routes.notes
Установить Routes.updatedBy = идентификатор техника

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

Изменить WorkShifts.status обратно на PLANNED
Изменить статус всех заказов в маршруте обратно на CONFIRMED
Освободить назначенное оборудование (ТС и станция)

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

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

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

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

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

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

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

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

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

Полную информацию о маршруте из таблицы Routes
Текущий статус маршрута с цветовой индикацией
Плановые и фактические времена начала/окончания
Прогресс выполнения в процентах

RQ056. Требование к отображению заказов. Во вкладке "Заказы" должна отображаться информация:

Список всех заказов из RoutePoints с порядком выполнения
Статус каждого заказа
Адрес и время прибытия к клиенту
Информация о клиенте (ФИО, тип заказа)
Требуемый уровень зарядки

RQ057. Требование к временной схеме. Временная линия должна отображать:

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

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

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

RQ059. Требование к отображению карты. Интерактивная карта должна показывать:

Все точки маршрута с номерами порядка выполнения
Оптимальные пути между точками
Текущее местоположение техника (для активных маршрутов)
Базу начала и окончания маршрута

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

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

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

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

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

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

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

RQ060. Требование к расчету общего прогресса. Система должна рассчитывать общий прогресс маршрута по формуле:

Прогресс = (Количество завершенных заказов / Общее количество заказов) × 100%

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

Плановое время начала и окончания маршрута
Фактическое время начала
Текущее время
Расчетное время завершения на основе текущего прогресса
Отклонение от планового графика (с цветовой индикацией)

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

Текущий статус из Orders.status
Плановое время прибытия из RoutePoints.plannedArrivalTime
Фактическое время прибытия из Orders.actualArrivalTime (если есть)
Время выполнения заказа (если завершен)

RQ063. Требование к автоматическому обновлению. Система должна автоматически обновлять информацию о прогрессе каждые 30 секунд при активном маршруте.

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

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

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

Автоматически изменить статус маршрута на COMPLETED
Отобразить уведомление технику о завершении маршрута
Предложить перейти к завершению рабочей смены

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

Требования к интеграции с другими блоками

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

Автоматической активации смены при принятии маршрута
Проверки соответствия времени маршрута времени смены
Завершения смены при завершении маршрута

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

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

RQ068. Требование к связи с блоком навигации. Система должна интегрироваться с блоком "Навигация и геолокация" для:

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

Требования к уведомлениям

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

Назначении нового маршрута
Изменении маршрута диспетчером
Критических задержках в выполнении маршрута
Сообщениях от диспетчера по маршруту

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

Принятии маршрута техником
Отклонении маршрута техником с причиной
Критических задержках в выполнении маршрута
Завершении маршрута

Требования к офлайн работе

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

Сохранять информацию о текущем маршруте локально
Позволять просмотр маршрута и заказов в офлайн режиме
Сохранять изменения статусов локально с последующей синхронизацией
Уведомлять техника о работе в офлайн режиме

RQ072. Требование к синхронизации данных. При восстановлении интернет-соединения система должна:

Автоматически синхронизировать все изменения статусов
Получить актуальную информацию о маршруте с сервера
Разрешить конфликты данных в пользу серверной версии
Уведомить техника об успешной синхронизации

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

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

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

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

Времени операции
GPS-координат (если доступны)
Типа операции (принятие, отклонение, просмотр)
Результата операции

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

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

RQ077. Требование к обновлению данных. Автоматическое обновление статусов и прогресса должно выполняться не более чем за 1 секунду.

RQ078. Требование к размеру кеша. Система должна кешировать информацию о текущем маршруте локально, занимая не более 50 МБ памяти устройства.

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

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

RQ079. Требование к API маршрутов. Мобильное приложение должно использовать следующие API endpoints:

GET /api/technician/routes - получение списка маршрутов техника
POST /api/technician/routes/{id}/accept - принятие маршрута
POST /api/technician/routes/{id}/reject - отклонение маршрута
GET /api/technician/routes/{id}/details - детальная информация о маршруте
GET /api/technician/routes/{id}/progress - прогресс выполнения маршрута

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

route_assigned - назначение нового маршрута
route_updated - изменение маршрута
order_status_changed - изменение статуса заказа в маршруте
route_cancelled - отмена маршрута диспетчером

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

RQ081. Требование к обработке сетевых ошибок. При сетевых ошибках система должна:

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

RQ082. Требование к обработке ошибок сервера. При ошибках сервера система должна:

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

Требования к интерфейсу мобильного приложения

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

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

RQ084. Требование к размеру элементов управления. Все кнопки и элементы управления должны иметь размер не менее 44x44 пикселей для удобного использования на мобильных устройствах.

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

Зеленый - завершено/активно
Желтый - в процессе/ожидание
Красный - отменено/ошибка
Серый - неактивно/недоступно

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

RQ086. Требование к поддержке ориентации. Интерфейс должен корректно отображаться как в портретной, так и в ландшафтной ориентации экрана.

RQ087. Требование к поддержке различных размеров экранов. Интерфейс должен адаптироваться под различные размеры экранов мобильных устройств (от 5 до 7 дюймов).

RQ088. Требование к доступности. Интерфейс должен соответствовать стандартам доступности для пользователей с ограниченными возможностями, включая поддержку screen readers.

Блок «Выполнение заказов» - Модуль Техника

Общие положения блока

Блок «Выполнение заказов» является ключевым функциональным блоком модуля техника, обеспечивающим полный жизненный цикл выполнения заказа от выезда к клиенту до завершения процедуры зарядки. Блок интегрируется с системами геолокации, фотофиксации, мониторинга оборудования и уведомлений для обеспечения автоматизированного контроля качества услуг.

Ключевые особенности блока:

Автоматизация переходов статусов на основе GPS-событий
Обязательная фотофиксация ключевых этапов выполнения заказа
Мониторинг процесса зарядки в реальном времени
Система отчетности о проблемах с эскалацией диспетчеру
Автоматические уведомления клиентам о статусе заказа

UC011: Просмотр списка заказов в маршруте

Актор: Техник

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

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

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

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

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

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

RQ101. Требование к загрузке заказов. Система должна загружать заказы из RoutePoints для текущего активного маршрута техника, отсортированные по orderIndex в порядке возрастания.

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

ASSIGNED - серый (ожидает выполнения)
EN_ROUTE - синий (техник в пути)
ARRIVED - желтый (техник прибыл)
CHARGING - зеленый (процесс зарядки)
COMPLETED - темно-зеленый (завершен)
FAILED - красный (проблема)

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

Номер порядка выполнения в маршруте
Номер заказа с префиксом типа (PZ- для плановых, EZ- для экстренных)
Текущий статус заказа
Адрес выполнения заказа
Плановое время прибытия
Требуемый уровень зарядки из Orders.chargeLevel и Orders.chargeValue
ФИО клиента и модель автомобиля
Доступные действия в зависимости от статуса

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

ASSIGNED: "Выехать к клиенту", "Просмотр деталей"
EN_ROUTE: "Прибыл", "Просмотр деталей", "Сообщить о проблеме"
ARRIVED: "Начать зарядку", "Просмотр деталей", "Сообщить о проблеме"
CHARGING: "Мониторинг зарядки", "Завершить зарядку", "Сообщить о проблеме"
COMPLETED/FAILED: "Просмотр деталей"

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

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

Актор: Техник

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

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

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

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

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

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

RQ106. Требование к загрузке данных заказа. Система должна загружать и отображать:

Полную информацию из Orders
Данные клиента из Clients (ФИО, замаскированный телефон, рейтинг)
Параметры автомобиля из ClientVehicles
Историю изменений статусов из OrderStatusHistories
Применяемый тариф из Tariffs

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

Показывать полный номер телефона клиента в формате +7 (XXX) XXX-XX-XX
НЕ отображать email клиента и другие персональные данные
Отображать только ФИО клиента и рейтинг

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

Расчетное время зарядки на основе текущего и требуемого уровня заряда
Стоимость услуги согласно применяемому тарифу
Расстояние до клиента от текущего местоположения техника

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

Времени изменения статуса
Предыдущего и нового статуса
Инициатора изменения (техник, система, диспетчер)
GPS-координат изменения (если доступны)
Причины изменения (если указана)

UC013: Подтверждение выезда к клиенту ("Выехал")

Актор: Техник

Описание: Техник подтверждает начало движения к клиенту, что переводит заказ в статус EN_ROUTE и активирует отслеживание местоположения.

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

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

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

RQ110. Требование к проверке статуса. Действие "Выехать к клиенту" доступно только для заказов со статусом ASSIGNED. При попытке применить к заказу с другим статусом система должна отобразить соответствующее сообщение об ошибке.

RQ111. Требование к геолокации. При подтверждении выезда система должна:

Запросить текущие GPS-координаты техника
Сохранить координаты в OrderStatusHistories.latitude и OrderStatusHistories.longitude
Проверить, что техник находится в пределах 5 км от базы начала смены
При превышении расстояния запросить подтверждение у техника

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

Изменить Orders.status на EN_ROUTE
Создать запись в OrderStatusHistories с указанием времени, GPS-координат и техника
Установить Orders.actualStartTime = текущее время
Обновить Orders.updatedAt и Orders.idUpdatedBy

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

"Техник выехал к вам"
Имя техника
Ориентировочное время прибытия (ETA)
Ссылка на отслеживание местоположения техника

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

Активировать непрерывную передачу GPS-координат техника
Начать расчет ETA до адреса клиента
Активировать автоматическое определение прибытия в геозону заказа

UC014: Автоматическая отметка прибытия (по GPS)

Актор: Система (автоматический процесс)

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

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

graph TD
    Start([Начало: GPS-данные от техника]) --> S1[Система: Получает GPS-координаты техника]
    S1 --> S2[Система: Проверяет наличие заказов со статусом EN_ROUTE]
    S2 --> D1{Есть активные заказы EN_ROUTE?}
    D1 -->|Нет| End([Конец])
    D1 -->|Да| S3[Система: Рассчитывает расстояние до адреса заказа]
    S3 --> D2{Расстояние ≤ 100 метров?}
    D2 -->|Нет| S4[Система: Обновляет ETA клиенту]
    D2 -->|Да| S5[Система: Проверяет время нахождения в геозоне]
    S4 --> End
    S5 --> D3{В геозоне > 30 секунд?}
    D3 -->|Нет| S6[Система: Ожидает дополнительные GPS-данные]
    D3 -->|Да| S7[Система: Изменяет Orders.status на ARRIVED]
    S6 --> End
    S7 --> S8[Система: Создает запись в OrderStatusHistories]
    S8 --> S9[Система: Отправляет push-уведомление технику]
    S9 --> S10[Система: Отправляет уведомление клиенту]
    S10 --> S11[Система: Деактивирует отслеживание маршрута]
    S11 --> End

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

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

Расстояние от GPS-координат техника до координат заказа (Orders.latitude, Orders.longitude) ≤ 100 метров
Техник находится в данной геозоне непрерывно более 30 секунд
Заказ имеет статус EN_ROUTE

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

Учитывать погрешность GPS (использовать буферную зону 100±20 метров)
Игнорировать кратковременные "скачки" GPS-сигнала
Требовать минимум 3 последовательных измерения в геозоне для подтверждения прибытия

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

Изменить Orders.status на ARRIVED
Создать запись в OrderStatusHistories с указанием previousStatus = EN_ROUTE, newStatus = ARRIVED
Установить OrderStatusHistories.idUser = техник заказа
Указать OrderStatusHistories.reason = "Автоматическое определение прибытия по GPS"
Сохранить точные GPS-координаты момента прибытия

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

Отправить push-уведомление технику: "Вы прибыли к клиенту. Можете начинать зарядку."
Отправить уведомление клиенту: "Техник прибыл. Ожидайте начала зарядки."
Уведомить диспетчера об автоматическом изменении статуса

RQ119. Требование к обработке ошибок GPS. При проблемах с GPS система должна:

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

UC015: Начало процесса зарядки с фотофиксацией

Актор: Техник

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

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

graph TD
    Start([Начало]) --> A1[Техник: Нажимает 'Начать зарядку']
    A1 --> S1[Система: Проверяет статус заказа]
    S1 --> D1{Статус = ARRIVED?}
    D1 -->|Нет| S2[Система: Отображает ошибку о невозможности действия]
    D1 -->|Да| S3[Система: Отображает форму фотофиксации<br/>ссылка: ФормаФотофиксацииНачала]
    S3 --> A2[Техник: Делает фото области зарядного лючка автомобиля]
    A2 --> S4[Система: Проверяет качество фото]
    S4 --> D2{Фото соответствует требованиям?}
    D2 -->|Нет| S5[Система: Показывает рекомендации по улучшению фото]
    D2 -->|Да| S6[Система: Обрабатывает фото (сжатие до 1920px, JPEG, 72%)]
    S5 --> A2
    S6 --> A3[Техник: Подтверждает начало зарядки]
    A3 --> S7[Система: Изменяет Orders.status на CHARGING]
    S7 --> S8[Система: Сохраняет фото в таблицу Photos]
    S8 --> S9[Система: Создает запись в OrderStatusHistories]
    S9 --> S10[Система: Активирует мониторинг процесса зарядки]
    S10 --> S11[Система: Отправляет уведомление клиенту]
    S11 --> S12[Система: Уведомляет диспетчера о начале зарядки]
    S12 --> End([Конец])
    S2 --> End

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

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

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

RQ120. Требование к фотофиксации начала зарядки. При начале зарядки техник должен сделать фотографии:

Общий вид области зарядного лючка автомобиля до подключения
Состояние лакокрасочного покрытия вокруг зарядного лючка
Видимые элементы автомобиля в радиусе 50 см от лючка зарядки
Показания одометра автомобиля (если видны через лобовое стекло)

RQ121. Требование к качеству фотографий. Система должна контролировать:

Минимальное разрешение исходного фото: 1280x720 пикселей
Отсутствие сильного размытия (автоматическая проверка резкости)
Достаточную освещенность (автоматическая проверка яркости)
Видимость зарядного лючка в кадре (предупреждение при его отсутствии)

RQ122. Требование к обработке фотографий. Перед сохранением система должна:

Сжать фото до размера 1920 пикселей по большей стороне
Конвертировать в формат JPEG с качеством 72%
Добавить метаданные: время съемки, GPS-координаты, ID заказа
Сохранить исходное фото локально до подтверждения отправки

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

Изменить Orders.status на CHARGING
Установить Orders.actualStartTime = текущее время
Создать запись в OrderStatusHistories
Сохранить фотографии в таблицу Photos с типом "charging_start"
Связать фото с заказом через Photos.idOrder

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

Клиенту: "Зарядка началась. Ожидайте завершения процесса."
Диспетчеру: системное уведомление о начале зарядки с указанием времени и техника
Технику: подтверждение успешного начала процесса зарядки

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

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

UC016: Мониторинг процесса зарядки в реальном времени

Актор: Техник

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

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

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

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

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

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

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

Текущий уровень заряда автомобиля (в процентах)
Целевой уровень заряда из заказа
Оставшееся время до завершения зарядки (расчетное)
Потребленную энергию с начала зарядки (кВт·ч)
Мгновенную мощность зарядки (кВт)
Среднюю мощность за сессию
Общее время зарядки

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

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

RQ128. Требование к графическому отображению. Система должна отображать:

Линейный график изменения уровня заряда автомобиля во времени
График мощности зарядки за последние 30 минут
Прогнозную кривую зарядки до целевого уровня
Цветовую индикацию: зеленый (норма), желтый (предупреждение), красный (ошибка)

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

Достижении целевого уровня заряда
Критических ошибках зарядной станции
Перегреве оборудования (>70°C)
Значительном снижении мощности зарядки
Потере связи с зарядной станцией

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

Приостановить процесс зарядки
Возобновить приостановленный процесс
Выполнить аварийную остановку зарядки
Завершить зарядку досрочно (с подтверждением)
Изменить целевой уровень заряда (в пределах ±10% от заказанного)

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

Обновлять параметры зарядки каждые 5 секунд
Обновлять графики каждые 30 секунд
Сохранять историю параметров для построения графиков
Кешировать данные для работы при кратковременных обрывах связи

UC017: Завершение зарядки с фотоотчетом

Актор: Техник

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

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

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

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

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

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

RQ132. Требование к фотофиксации завершения зарядки. При завершении зарядки техник должен сделать фотографии:

Общий вид области зарядного лючка после отключения
Финальное состояние лакокрасочного покрытия вокруг лючка
Показания одометра автомобиля (если доступны)
Общий вид автомобиля (для фиксации отсутствия повреждений)
Зарядная станция в отключенном состоянии

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

Orders.actualEndTime = время завершения
Orders.totalKwh = общее количество потребленной энергии
Orders.totalPrice = итоговая стоимость услуги
Финальный уровень заряда автомобиля
Общее время выполнения заказа
Среднюю мощность зарядки за сессию

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

Стоимость потребленной энергии: totalKwh × Tariffs.pricePerKwh
Разовую плату за обслуживание: Tariffs.oneTimeServiceFee (если применимо)
Доплату за экстренность: Tariffs.emergencyServiceFee (для экстренных заказов)
Итоговую сумму с учетом всех составляющих
НДС и детализацию по позициям

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

Общую информацию о заказе (номер, дата, техник)
Детализацию процесса зарядки (время, энергия, мощность)
Стоимость услуг с разбивкой
Фотографии до и после зарядки
Комментарии техника (если есть)
QR-код для быстрого доступа клиента к отчету

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

Клиенту: "Зарядка завершена" с итоговым отчетом и ссылкой на оплату
Диспетчеру: уведомление о завершении заказа с основными метриками
Системе биллинга: данные для создания счета к оплате
Технику: подтверждение успешного завершения заказа

RQ137. Требование к возможности корректировки. До финального подтверждения техник должен иметь возможность:

Изменить комментарии к заказу
Переснять фотографии
Скорректировать финальные показания (в пределах ±5%)
Отменить завершение и вернуться к процессу зарядки

UC018: Сообщение о проблемах при выполнении заказа

Актор: Техник

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

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

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

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

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

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

RQ138. Требование к классификации проблем. Система должна предоставлять следующие категории проблем:

Технические проблемы оборудования:

Неисправность зарядной станции
Проблемы с сервисным ТС
Неисправность зарядного кабеля
Проблемы с электропитанием

Проблемы с клиентом/автомобилем:

Клиент недоступен по указанному адресу
Неисправность зарядного порта автомобиля
Несовместимость типа коннектора
Клиент отказался от услуги

Проблемы доступа:

Невозможность подъезда к автомобилю
Заблокированный доступ к зарядному лючку
Проблемы с парковкой
Ограничения безопасности

Форс-мажорные обстоятельства:

Неблагоприятные погодные условия
Дорожно-транспортное происшествие
Чрезвычайные ситуации
Проблемы с безопасностью

RQ139. Требование к обязательности фотофиксации. Фотографии обязательны для следующих типов проблем:

Все проблемы категории "Проблемы с клиентом/автомобилем"
Неисправности оборудования
Проблемы доступа к автомобилю
Видимые повреждения или нестандартные ситуации

RQ140. Требование к действиям с заказом. Техник должен выбрать одно из действий:

Завершить заказ как неуспешный (FAILED) - при невозможности выполнения
Продолжить выполнение - при устранимых проблемах
Запросить помощь диспетчера - при сложных ситуациях
Перенести заказ - при временных препятствиях

RQ141. Требование к эскалации диспетчеру. При выборе "Запросить помощь диспетчера" система должна:

Отправить push-уведомление диспетчеру с высоким приоритетом
Включить в уведомление тип проблемы, описание и фото
Указать местоположение техника и клиента
Предоставить диспетчеру возможность связаться с техником
Установить статус заказа в "ожидает помощи диспетчера"

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

Тип и описание проблемы
Время возникновения проблемы
GPS-координаты техника
Фотографии проблемы (если есть)
Выбранное действие с заказом
Связь с OrderStatusHistories для отслеживания

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

Диспетчера: о всех проблемах с указанием уровня критичности
Клиента: при проблемах, влияющих на выполнение заказа
Техническую поддержку: при технических неисправностях оборудования
Службу безопасности: при проблемах безопасности

UC019: Просмотр истории выполненных заказов

Актор: Техник

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

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

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

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

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

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

RQ144. Требование к загрузке истории заказов. Система должна загружать заказы техника из Orders со статусами COMPLETED и FAILED, отсортированные по updatedAt в порядке убывания (новые первыми).

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

По периоду времени: последние 7 дней, 30 дней, 3 месяца, произвольный период
По статусу завершения: успешные (COMPLETED), неуспешные (FAILED), все
По типу заказа: плановые, экстренные, все типы
По диапазону стоимости: от минимальной до максимальной суммы
По клиентам: поиск по имени клиента с автодополнением

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

Номеру заказа (Orders.orderNumber)
Имени клиента (Clients.firstName + Clients.lastName)
Адресу выполнения заказа (Orders.address)
Комментариям к заказу
Модели автомобиля клиента

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

Номер заказа и дату выполнения
ФИО клиента и модель автомобиля
Адрес выполнения заказа
Параметры зарядки (начальный/финальный уровень, потребленная энергия)
Длительность выполнения заказа
Итоговую стоимость услуги
Оценку клиента (если есть)
Статус завершения с иконкой

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

Полную информацию о заказе и клиенте
Хронологию выполнения заказа с временными метками
Фотографии до и после зарядки
Детализацию стоимости услуги
Отзыв клиента и оценку работы техника
Использованное оборудование (ТС и зарядная станция)

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

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

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

Списка заказов за выбранный период в формате Excel или CSV
Детального отчета по каждому заказу с фотографиями (PDF)
Сводного отчета по статистике работы техника
Фильтрация экспортируемых данных согласно примененным фильтрам

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

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

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

Требования к интеграции с другими блоками

RQ152. Требование к интеграции с блоком геолокации. Блок должен интегрироваться с UC030-UC034 для:

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

RQ153. Требование к интеграции с блоком взаимодействия с клиентами. Блок должен интегрироваться с UC020-UC023 для:

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

RQ154. Требование к интеграции с блоком мониторинга оборудования. Блок должен интегрироваться с UC024-UC029 для:

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

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

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

EN_ROUTE: "Техник {имя} выехал к вам. Ожидаемое время прибытия: {ETA}"
ARRIVED: "Техник прибыл к месту зарядки. Ожидайте начала процесса."
CHARGING: "Зарядка началась. Текущий уровень: {%}. Ожидаемое время завершения: {время}"
COMPLETED: "Зарядка завершена! Финальный уровень: {%}. Итоговая стоимость: {сумма}"
FAILED: "К сожалению, возникла проблема: {описание}. Свяжитесь с поддержкой."

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

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

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

RQ157. Требование к обработке фотографий. Все фотографии должны:

Сжиматься до размера 1920 пикселей по большей стороне
Сохраняться в формате JPEG с качеством 72%
Содержать метаданные: время съемки, GPS-координаты, ID заказа
Проходить автоматическую проверку качества (резкость, освещенность)

RQ158. Требование к хранению фотографий. Система должна:

Сохранять фотографии в таблице Photos с привязкой к заказу
Указывать тип фото (charging_start, charging_end, problem_report)
Обеспечивать возможность удаления/пересъемки до подтверждения действия
Создавать резервные копии фотографий для критических заказов

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

RQ159. Требование к real-time обновлениям. Система должна использовать WebSocket для:

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

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

Уведомить техника о потере связи
Кешировать критические действия локально
Автоматически восстанавливать соединение при появлении связи
Синхронизировать накопленные данные после восстановления

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

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

Загрузку списка заказов не более чем за 3 секунды
Отображение деталей заказа не более чем за 2 секунды
Обновление статуса заказа не более чем за 1 секунду
Отправку фотографий не более чем за 10 секунд при стабильном соединении

RQ162. Требование к обработке фотографий. Система должна:

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

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

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

Время выполнения действия
GPS-координаты техника (если доступны)
Тип выполненного действия
Результат действия (успех/ошибка)
Связанные данные (ID заказа, фотографии, комментарии)

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

Показывать технику только необходимую информацию о клиенте
Маскировать номер телефона клиента в интерфейсе
Не передавать персональные данные клиента третьим лицам
Обеспечивать шифрование передаваемых данных

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

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

Диаграмма переходов статусов заказа

stateDiagram-v2
    [*] --> ASSIGNED : Заказ назначен техникy
    ASSIGNED --> EN_ROUTE : UC013: Техник подтвердил выезд
    EN_ROUTE --> ARRIVED : UC014: Автоматически по GPS
    ARRIVED --> CHARGING : UC015: Техник начал зарядку + фото
    CHARGING --> COMPLETED : UC017: Техник завершил зарядку + фото
    
    ASSIGNED --> FAILED : UC018: Сообщение о проблеме
    EN_ROUTE --> FAILED : UC018: Сообщение о проблеме  
    ARRIVED --> FAILED : UC018: Сообщение о проблеме
    CHARGING --> FAILED : UC018: Сообщение о проблеме
    
    COMPLETED --> [*]
    FAILED --> [*]
    
    note right of CHARGING : UC016: Мониторинг зарядки
    note right of FAILED : Требует ручного вмешательства диспетчера

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

RQ166. Требование к API интеграции. Мобильное приложение должно использовать следующие API endpoints:

GET /api/technician/orders - получение списка заказов техника
POST /api/technician/orders/{id}/status - изменение статуса заказа
POST /api/technician/orders/{id}/photos - загрузка фотографий
GET /api/technician/orders/{id}/monitoring - получение данных мониторинга зарядки
POST /api/technician/orders/{id}/problems - сообщение о проблеме

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

Зарядными станциями для получения данных мониторинга
GPS-модулями сервисных ТС для отслеживания местоположения
Системой управления автопарком для статусов оборудования
Биллинговой системой для расчета стоимости услуг

Данный блок является основой операционной деятельности техников и напрямую влияет на качество клиентского сервиса и эффективность бизнес-процессов компании.

Блок «Взаимодействие с клиентами» - Модуль Техника

Общие положения блока

Блок «Взаимодействие с клиентами» обеспечивает защищенную коммуникацию между техником и клиентом в рамках выполнения конкретного заказа. Блок предоставляет возможность обмена текстовыми сообщениями и фотографиями без раскрытия персональных контактных данных сторон.

Ключевые особенности блока:

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

Интеграционные связи:

UC011-UC019 (Выполнение заказов) - контекст активного заказа
UC006-UC010 (Управление маршрутами) - проверка статуса маршрута
Система уведомлений - отправка push-уведомлений о новых сообщениях

UC020: Просмотр контактной информации клиента

Актор: Техник

Описание: Техник просматривает доступную контактную информацию клиента по текущему заказу для идентификации и подготовки к взаимодействию.

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

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

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

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

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

RQ201. Требование к загрузке информации клиента. Система должна загружать информацию клиента только для заказов, назначенных текущему технику (проверка Orders.idAssignedTechnician).

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

Полное имя клиента из Clients.firstName
Замаскированный номер телефона в формате "+7 (XXX) XXX-XX-67" (показать только последние 2 цифры)
Общий статус клиента (активен/заблокирован)

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

Бренд и модель из связанной записи ClientVehicles
Год выпуска, номер автомобиля, цвет
Тип коннектора для зарядки

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

Маршрут техника имеет статус IN_PROGRESS
Заказ имеет статус ASSIGNED, EN_ROUTE, ARRIVED или CHARGING
Рабочая смена техника активна (status = ACTIVE)

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

Полный номер телефона клиента
Адрес проживания клиента (кроме адреса заказа)
Историю других заказов клиента
Финансовую информацию клиента

UC021: Отправка сообщений в чат с клиентом

Актор: Техник

Описание: Техник отправляет текстовое сообщение или фотографию клиенту в рамках выполнения конкретного заказа.

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

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

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

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

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

RQ206. Требование к доступности чата. Чат должен быть доступен только если:

Маршрут техника имеет статус IN_PROGRESS
Заказ находится в статусе ASSIGNED, EN_ROUTE, ARRIVED или CHARGING
Техник является исполнителем заказа (Orders.idAssignedTechnician)

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

Длина сообщения не более 1000 символов
Сообщение не содержит только пробельные символы
Отсутствие запрещенного контента (спам, оскорбления)

RQ208. Требование к обработке фотографий. Система должна:

Принимать файлы форматов JPEG, PNG размером до 10 МБ
Автоматически сжимать изображения до 1920px по большей стороне
Добавлять watermark с ID заказа
Сохранять EXIF-данные о времени и местоположении съемки

RQ209. Требование к сохранению сообщений. При отправке система должна создавать запись в Messages:

idOrder - ID текущего заказа
idSender - ID техника (пользователь с ролью TECHNICIAN)
idRecipient - ID клиента заказа
messageType - TEXT или PHOTO
content - текст сообщения или путь к файлу фото
sentAt - текущее время сервера

RQ210. Требование к уведомлениям. После отправки сообщения система должна:

Отправить push-уведомление клиенту с превью сообщения
Отправить SMS-уведомление, если push недоступен
Логировать факт отправки уведомления

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

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

UC022: Получение сообщений от клиента

Актор: Техник

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

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

graph TD
    Start([Начало]) --> Event1[Событие: Клиент отправил сообщение]
    Event1 --> S1[Система: Получает сообщение через WebSocket]
    S1 --> S2[Система: Валидирует принадлежность сообщения к заказу техника]
    S2 --> D1{Сообщение для этого техника?}
    D1 -->|Нет| End1([Игнорировать])
    D1 -->|Да| S3[Система: Обновляет интерфейс чата в реальном времени]
    S3 --> D2{Приложение активно?}
    D2 -->|Да| S4[Система: Отображает сообщение в чате]
    D2 -->|Нет| S5[Система: Отправляет push-уведомление технику]
    S4 --> S6[Система: Воспроизводит звук нового сообщения]
    S5 --> D3{Техник открыл уведомление?}
    S6 --> A1[Техник: Просматривает новое сообщение]
    D3 -->|Да| S7[Система: Открывает чат с конкретным заказом]
    D3 -->|Нет| End2([Конец])
    S7 --> S4
    A1 --> S8[Система: Отмечает сообщение как прочитанное]
    S8 --> D4{Требуется ответ?}
    D4 -->|Да| A2[Техник: Переходит к UC021 Отправка сообщения]
    D4 -->|Нет| A3[Техник: Продолжает работу с заказом]
    A2 --> End3([Конец])
    A3 --> End3

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

classDiagram
    class СообщениеКлиента {
        <<Area>>
        +ТекстСообщения : Текст
        +ВремяПолучения : ВремяИДата
        +СтатусПрочтения : ИндикаторПрочтения
        +Фотография : Изображение
        +КнопкаОтветить : Кнопка
        +КнопкаСохранитьФото : Кнопка
    }
    
    class PushУведомление {
        <<Notification>>
        +ЗаголовокУведомления : Текст
        +ТекстПревью : Текст[100]
        +ИконкаЗаказа : Изображение
        +ВремяПолучения : Время
        +КнопкаОтветить : Кнопка
        +КнопкаПросмотреть : Кнопка
    }
    
    class ИндикаторНовыхСообщений {
        <<Area>>
        +КоличествоНепрочитанных : Число
        +ИконкаУведомления : Значок
        +АнимацияВнимания : Анимация
    }

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

RQ212. Требование к real-time получению. Система должна:

Использовать WebSocket для мгновенного получения сообщений
Обновлять интерфейс чата без перезагрузки страницы
Поддерживать работу в фоновом режиме

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

Сообщение относится к заказу, назначенному текущему технику
Отправитель является клиентом данного заказа
Сообщение не является дубликатом

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

Выравнивать сообщения клиента по левой стороне
Отображать время получения в локальном часовом поясе
Показывать статус прочтения (прочитано/не прочитано)
Поддерживать отображение фотографий в полном размере

RQ215. Требование к push-уведомлениям. При получении сообщения в фоновом режиме:

Отображать краткое превью сообщения (до 100 символов)
Показывать имя клиента и номер заказа
Предоставлять быстрые действия (ответить, просмотреть)
Группировать уведомления по заказам

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

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

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

Отображать количество непрочитанных сообщений на иконке чата
Обновлять счетчик в реальном времени
Сбрасывать счетчик при открытии чата

UC023: Просмотр истории переписки с клиентом по заказу

Актор: Техник

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

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

graph TD
    Start([Начало]) --> A1[Техник: Открывает историю чата с клиентом]
    A1 --> S1[Система: Проверяет права доступа к заказу]
    S1 --> D1{Доступ разрешен?}
    D1 -->|Нет| S2[Система: Отображает ошибку доступа]
    D1 -->|Да| S3[Система: Загружает все сообщения из Messages<br/>где idOrder = текущий заказ]
    S3 --> S4[Система: Сортирует сообщения по sentAt по возрастанию]
    S4 --> S5[Система: Группирует сообщения по дате]
    S5 --> S6[Система: Отображает историю переписки<br/>ссылка: ИсторияПереписки]
    S6 --> L1[Цикл: Навигация по истории]
    L1 --> D2{Выбор действия}
    D2 -->|Поиск в истории| A2[Техник: Вводит текст для поиска]
    D2 -->|Просмотр фото| A3[Техник: Нажимает на фотографию]
    D2 -->|Экспорт истории| A4[Техник: Нажимает 'Экспортировать']
    D2 -->|Новое сообщение| A5[Техник: Нажимает 'Написать']
    D2 -->|Назад| A6[Техник: Возвращается к деталям заказа]
    A2 --> S7[Система: Фильтрует сообщения по тексту]
    A3 --> S8[Система: Открывает фото в полноэкранном режиме]
    A4 --> S9[Система: Формирует PDF отчет переписки]
    A5 --> S10[Система: Переход к UC021 Отправка сообщения]
    A6 --> End([Конец])
    S7 --> S11[Система: Подсвечивает найденные результаты]
    S8 --> L1
    S9 --> S12[Система: Предлагает сохранить/отправить отчет]
    S10 --> End
    S11 --> L1
    S12 --> L1
    S2 --> End

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

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

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

RQ218. Требование к загрузке истории сообщений. Система должна:

Загружать все сообщения для заказа: SELECT * FROM Messages WHERE idOrder = ? ORDER BY sentAt ASC
Группировать сообщения по датам для удобной навигации
Использовать пагинацию при большом количестве сообщений (по 50 сообщений на страницу)

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

Показывать сообщения в хронологическом порядке (старые сверху)
Выделять разными цветами сообщения техника и клиента
Отображать точное время отправки каждого сообщения
Группировать сообщения, отправленные в течение 5 минут

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

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

RQ221. Требование к работе с фотографиями. При отображении фото в истории:

Показывать миниатюры фотографий размером 150x150px
Открывать полноразмерное изображение при клике
Отображать метаданные фото (время, размер, геолокация если есть)
Предоставлять возможность сохранения фото на устройство

RQ222. Требование к экспорту истории. Функция экспорта должна:

Формировать PDF-отчет со всей перепиской
Включать метаданные заказа (номер, дата, участники)
Вставлять фотографии в отчет с подписями
Добавлять электронную подпись и timestamp экспорта

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

Общее количество сообщений в переписке
Соотношение сообщений техника и клиента
Общее время активной переписки
Среднее время ответа техника на сообщения клиента

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

Загружать историю не более чем за 3 секунды
Поддерживать плавную прокрутку при больших объемах переписки
Кешировать загруженные сообщения для быстрого доступа
Оптимизировать загрузку изображений (lazy loading)

Интеграционные требования блока

Интеграция с блоком "Выполнение заказов"

RQ225. Требование к интеграции со статусами заказов. Блок должен:

Автоматически активировать чат при переходе заказа в статус ASSIGNED
Ограничивать доступ к чату при статусах COMPLETED, CANCELLED, FAILED
Отображать текущий статус заказа в интерфейсе чата
Синхронизироваться с изменениями статуса в реальном времени

Интеграция с блоком "Управление маршрутами"

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

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

Интеграция с системой уведомлений

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

Push-уведомлениями мобильного приложения
SMS-шлюзом для резервных уведомлений
Email-системой для служебных уведомлений диспетчеру
WebSocket для real-time обновлений

Интеграция с системой аудита

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

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

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

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

Проверять права техника на доступ к каждому сообщению
Запрещать доступ к чатам других техников
Автоматически завершать сессии при смене статуса заказа
Логировать все попытки несанкционированного доступа

RQ230. Требование к шифрованию данных. Система должна:

Шифровать сообщения при передаче по сети (TLS 1.3)
Хранить сообщения в зашифрованном виде в базе данных
Использовать end-to-end шифрование для конфиденциальных данных
Регулярно ротировать ключи шифрования

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

Хранить сообщения не более 1 года после завершения заказа
Автоматически удалять персональные данные по запросу
Вести журнал удаления данных для аудита
Создавать резервные копии в зашифрованном виде

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

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

Доставку сообщений не более чем за 2 секунды
Загрузку истории чата не более чем за 3 секунды
Отправку push-уведомлений не более чем за 1 секунду
Поиск по истории не более чем за 5 секунд

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

До 100 одновременных техников в чатах
До 1000 сообщений в минуту
Загрузку фотографий до 10 МБ каждая
Хранение до 1 млн сообщений в активной базе

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

Доступность 99.9% времени в рабочие часы
Автоматическое восстановление соединений
Дублирование критических сообщений
Откат к резервным каналам связи при сбоях

Диаграмма состояний доступности чата

stateDiagram-v2
    [*] --> Недоступен : Маршрут не назначен
    Недоступен --> Ожидание : Маршрут назначен (ASSIGNED)
    Ожидание --> Активен : Маршрут принят (IN_PROGRESS)
    Активен --> Заблокирован : Заказ завершен/отменен
    Активен --> Приостановлен : Техническая проблема
    Приостановлен --> Активен : Проблема устранена
    Заблокирован --> Архивный : Маршрут завершен (COMPLETED)
    Архивный --> [*] : Истечение срока хранения
    
    note right of Активен : Доступны UC021, UC022, UC023
    note right of Архивный : Доступен только UC023 (только чтение)
    note right of Заблокирован : Доступен только UC023 (только чтение)

Блок «Мониторинг оборудования» - Модуль Техника

Общие положения блока

Блок «Мониторинг оборудования» обеспечивает технику возможность отслеживания технического состояния назначенного ему оборудования (сервисного ТС и зарядной станции), создания заявок на неисправности и просмотра технических характеристик. Блок интегрируется с серверными системами мониторинга оборудования для получения данных в реальном времени и обеспечивает оперативное реагирование на технические проблемы.

Ключевые особенности блока:

Мониторинг в реальном времени данных о состоянии оборудования от серверной части
Система приоритетных заявок на неисправности с фотофиксацией
Отслеживание статуса заявок техником после создания
Автоматические уведомления диспетчеру и технику о критичных проблемах
Интеграция с GPS для привязки проблем к местоположению

UC024: Просмотр статуса сервисного ТС

Актор: Техник

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

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

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

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

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

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

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

Уровень заряда основной батареи ТС (%)
Текущий пробег и расход энергии (кВт⋅ч/100км)
Текущую скорость движения (км/ч)
GPS-координаты с точностью до метра
Время последнего обновления данных

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

Температуру в салоне и отсеках с оборудованием (°C)
Статус систем: двигатель, тормоза, освещение, кондиционирование
Давление в шинах (при наличии датчиков)
Уровень охлаждающей жидкости/температуру систем охлаждения
Напряжение бортовой сети

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

Выделять красным цветом критичные показатели (заряд <15%, перегрев >80°C)
Отображать желтым предупреждающие значения (заряд <30%, высокая температура >60°C)
Показывать зеленым нормальные параметры
Воспроизводить звуковой сигнал при критичных проблемах

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

Обновлять данные автоматически каждые 30 секунд при активном экране
Сохранять данные локально при потере соединения
Отображать индикатор "офлайн" при отсутствии связи с сервером
Синхронизировать накопленные данные при восстановлении связи

UC025: Просмотр статуса зарядной станции

Актор: Техник

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

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

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

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

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

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

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

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

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

Температуру оборудования станции (°C)
Общее время работы с момента начала смены
Счетчик циклов зарядки до планового ТО
Статус подключения к сервисному ТС
Время последней автоматической диагностики

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

Номер текущего заказа и время начала зарядки
Текущий уровень заряда автомобиля клиента (%)
Объем уже переданной энергии (кВт⋅ч)
Примерное время завершения зарядки
Накопленную стоимость текущей сессии

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

Выделять красным критичные проблемы (заряд станции <10%, перегрев >70°C, ошибки коннекторов)
Показывать желтым предупреждения (заряд станции <25%, температура >50°C)
Отображать зеленым нормальное состояние
Отправлять push-уведомление при критичных ошибках

UC026: Создание заявки на неисправность ТС

Актор: Техник

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

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

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

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

classDiagram
    class ФормаЗаявкиТС {
        <<Screen>>
        +ЗаголовокФормы : Заголовок
        +ИнформацияОТС : ОбластьИнформации
        +ОписаниеПроблемы : TextArea*[500]
        +ВыборПриоритета : RadioGroup*
        +ВлияниеНаРаботу : CheckboxGroup
        +ОбластьФотографий : ОбластьФото
        +ДополнительныеКомментарии : TextArea[200]
        +КнопкаОтправить : Button
        +КнопкаОтмена : Button
    }
    
    class ОбластьИнформации {
        <<Area>>
        +МодельТС : TextField[readonly]
        +НомерТС : TextField[readonly]
        +ТекущееМестоположение : КоординатыПоле
        +ВремяОбнаружения : DateTimeField
    }
    
    class ОбластьФото {
        <<Area>>
        +КнопкаСделатьФото : Button
        +СписокФотографий : ListBox
        +КнопкаУдалитьФото : Button
        +ПросмотрФото : ImageViewer
    }
    
    class ВыборПриоритета {
        <<RadioGroup>>
        +НизкийПриоритет : RadioButton
        +СреднийПриоритет : RadioButton  
        +ВысокийПриоритет : RadioButton
        +КритическийПриоритет : RadioButton
    }
    
    ФормаЗаявкиТС *-- ОбластьИнформации
    ФормаЗаявкиТС *-- ОбластьФото
    ФормаЗаявкиТС *-- ВыборПриоритета

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

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

Описание проблемы (минимум 10 символов, максимум 500)
Приоритет проблемы (низкий/средний/высокий/критический)
Минимум 1 фотография проблемы
Влияние на возможность работы (может работать/ограниченная работа/не может работать)

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

Критический: Полная невозможность работы, угроза безопасности
Высокий: Серьезное влияние на качество работы
Средний: Заметные проблемы, не критичные для работы
Низкий: Минорные проблемы, косметические дефекты

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

Модель и номер ТС из назначения техника
Текущие GPS-координаты техника
Дату и время создания заявки
ID техника и информацию о текущей смене

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

Требовать минимум 1 фотографию для создания заявки
Позволять прикреплять до 5 фотографий к одной заявке
Сжимать фотографии до 1920px по большей стороне
Добавлять GPS-координаты в метаданные фотографий

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

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

UC027: Создание заявки на неисправность зарядной станции

Актор: Техник

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

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

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

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

classDiagram
    class ФормаЗаявкиСтанции {
        <<Screen>>
        +ЗаголовокФормы : Заголовок
        +ИнформацияОСтанции : ОбластьИнформацииСтанции
        +ТипПроблемы : DropDown*
        +ОписаниеПроблемы : TextArea*[500]
        +ВыборПриоритета : RadioGroup*
        +ВлияниеНаЗаказы : CheckboxGroup
        +ТекущиеПараметры : ОбластьПараметров
        +ОбластьФотографий : ОбластьФото
        +КнопкаОтправить : Button
        +КнопкаОтмена : Button
    }
    
    class ОбластьИнформацииСтанции {
        <<Area>>
        +МодельСтанции : TextField[readonly]
        +СерийныйНомер : TextField[readonly]
        +ТекущийСтатус : StatusField[readonly]
        +ВремяОбнаружения : DateTimeField
        +АктивныйЗаказ : TextField[readonly]
    }
    
    class ОбластьПараметров {
        <<Area>>
        +ЗарядБатареи : PercentField[readonly]
        +ТемператураОборудования : NumberField[readonly]
        +ВыходноеНапряжение : NumberField[readonly]
        +ВыходнойТок : NumberField[readonly]
        +СтатусКоннекторов : StatusList[readonly]
    }
    
    class ТипПроблемы {
        <<DropDown>>
        +НеисправностьБатареи : Option
        +ПроблемыЗарядки : Option
        +НеисправностьКоннектора : Option
        +Перегрев : Option
        +ОшибкиПО : Option
        +МеханическиеПовреждения : Option
        +ПроблемыПитания : Option
        +Другое : Option
    }
    
    ФормаЗаявкиСтанции *-- ОбластьИнформацииСтанции
    ФормаЗаявкиСтанции *-- ОбластьПараметров
    ФормаЗаявкиСтанции *-- ТипПроблемы

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

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

Неисправность батареи: Проблемы с накоплением/отдачей энергии
Проблемы зарядки: Невозможность зарядить автомобиль клиента
Неисправность коннектора: Физические проблемы с разъемами
Перегрев: Критическая температура оборудования
Ошибки ПО: Программные сбои в управлении станцией
Механические повреждения: Физические повреждения корпуса/компонентов
Проблемы питания: Проблемы с подключением к ТС или внешним источникам
Другое: С обязательным детальным описанием

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

Все текущие технические параметры станции
Время последней успешной зарядки
Количество ошибок в логах за последние 24 часа
Информацию о текущем заказе (если есть)
Историю последних 10 операций станции

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

Отправить немедленное push-уведомление диспетчеру
Отправить SMS-уведомление при отсутствии подтверждения в течение 5 минут
Создать запись в журнале критических событий
Предложить технику связаться с диспетчером напрямую

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

Блокирует текущий заказ: Невозможно продолжить зарядку
Снижает эффективность: Пониженная мощность зарядки
Угрожает безопасности: Риск для техника или клиента
Может повлиять на следующие заказы: Потенциальные проблемы
Не влияет на работу: Косметические/информационные проблемы

UC028: Просмотр истории заявок на неисправности

Актор: Техник

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

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

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

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

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

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

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

Уникальный номер заявки (например, "EQ-2024-001234")
Тип оборудования (ТС/Зарядная станция) с соответствующей иконкой
Текущий статус (Новая/В работе/Ожидает техника/Решена/Закрыта)
Приоритет с цветовой индикацией
Дату создания и краткое описание проблемы
Индикатор непрочитанных комментариев от диспетчера

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

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

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

Полную информацию о проблеме и оборудовании
Все прикрепленные фотографии с возможностью увеличения
Хронологию всех комментариев и изменений статуса
Информацию о диспетчере, обрабатывающем заявку
Ожидаемые сроки решения (если указаны диспетчером)

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

При изменении статуса заявки
При добавлении комментария диспетчером
При запросе дополнительной информации
При решении/закрытии заявки
За 1 час до истечения срока ответа на запрос диспетчера

UC029: Просмотр технических характеристик оборудования

Актор: Техник

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

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

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

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

classDiagram
    class СправочникОборудования {
        <<Screen>>
        +ЗаголовокСправочника : Заголовок
        +ВкладкиОборудования : TabControl
        +ОбластьХарактеристик : ОбластьКонтента
        +КнопкиДействий : ОбластьДействий
    }
    
    class ХарактеристикиТС {
        <<Area>>
        +МодельТС : TextField[readonly]
        +ПроизводительТС : TextField[readonly]
        +ГодВыпуска : NumberField[readonly]
        +ЕмкостьБатареи : NumberField[readonly]
        +ЗапасХода : NumberField[readonly]
        +МаксимальнаяСкорость : NumberField[readonly]
        +Грузоподъемность : NumberField[readonly]
        +РазмерыТС : TextField[readonly]
        +ТипЗарядкиТС : TextField[readonly]
    }
    
    class ХарактеристикиСтанции {
        <<Area>>
        +МодельСтанции : TextField[readonly]
        +ПроизводительСтанции : TextField[readonly]
        +МаксимальнаяМощность : NumberField[readonly]
        +ЕмкостьБатареи : NumberField[readonly]
        +ТипыКоннекторов : ListField[readonly]
        +ВыходноеНапряжение : TextField[readonly]
        +МаксимальныйТок : NumberField[readonly]
        +ВремяЗарядкиСобственной : NumberField[readonly]
        +РабочаяТемпература : TextField[readonly]
        +ВесСтанции : NumberField[readonly]
    }
    
    class ИнструкцииЭксплуатации {
        <<Area>>
        +ИнструкцияПоТС : DocumentLink
        +ИнструкцияПоСтанции : DocumentLink
        +РуководствоПоБезопасности : DocumentLink
        +АварийныеПроцедуры : DocumentLink
        +ПроцедурыТО : DocumentLink
        +ВидеоИнструкции : VideoLink
    }
    
    class КонтактыТехподдержки {
        <<Area>>
        +ГорячаяЛиния : PhoneLink
        +EmailТехподдержки : EmailLink
        +ЧатТехподдержки : ChatLink
        +СервисныйЦентр : ContactInfo
        +АварийнаяСлужба : PhoneLink
        +РежимРаботы : TextField[readonly]
    }
    
    СправочникОборудования *-- ХарактеристикиТС
    СправочникОборудования *-- ХарактеристикиСтанции
    СправочникОборудования *-- ИнструкцииЭксплуатации
    СправочникОборудования *-- КонтактыТехподдержки

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

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

Модель, производитель и год выпуска ТС
Емкость основной батареи (кВт⋅ч) и запас хода (км)
Максимальную скорость и грузоподъемность
Габаритные размеры и снаряженную массу
Тип зарядки ТС (AC/DC, мощность, тип разъема)
Рабочий диапазон температур

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

Модель, производитель и серийный номер станции
Максимальную мощность зарядки (кВт)
Емкость собственной батареи станции (кВт⋅ч)
Поддерживаемые типы коннекторов (CCS, CHAdeMO, Type 2)
Выходное напряжение (В) и максимальный ток (А)
Время зарядки собственной батареи станции
Рабочий диапазон температур и вес оборудования

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

Руководству по эксплуатации ТС в PDF формате
Инструкции по использованию зарядной станции
Руководству по технике безопасности
Процедурам в аварийных ситуациях
Инструкциям по базовому техническому обслуживанию
Видеоинструкциям по ключевым операциям

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

Номер горячей линии техподдержки с возможностью прямого звонка
Email техподдержки с автоматическим формированием письма
Доступ к чату техподдержки (если доступен)
Контакты ближайшего сервисного центра
Номер аварийной службы для критических ситуаций
Режим работы служб поддержки

Модель предметной области блока

Основные сущности блока

classDiagram
    class ЗаявкиНаНеисправности {
        +Id : String
        +ТехникId : String
        +ТипОборудования : ТипыОборудования
        +ОборудованиеId : String
        +НомерЗаявки : String
        +ТипПроблемы : String
        +ОписаниеПроблемы : String
        +Приоритет : ПриоритетыЗаявок
        +Статус : СтатусыЗаявок
        +GPS_Координаты : Координаты
        +ВлияниеНаРаботу : String
        +ТехническиеПараметры : JSON
        +ВремяСоздания : DateTime
        +ВремяРешения : DateTime
        +НазначенныйДиспетчер : String
        +КомментарииТехника : String
        +КомментарииДиспетчера : String
    }
    
    class ТипыОборудования {
        <<enumeration>>
        SERVICE_VEHICLE
        CHARGING_STATION
    }
    
    class ПриоритетыЗаявок {
        <<enumeration>>
        LOW
        MEDIUM
        HIGH
        CRITICAL
    }
    
    class СтатусыЗаявок {
        <<enumeration>>
        NEW
        IN_PROGRESS
        WAITING_TECHNICIAN
        RESOLVED
        CLOSED
    }
    
    class ПараметрыМониторинга {
        +ОборудованиеId : String
        +ТипОборудования : ТипыОборудования
        +ВремяОбновления : DateTime
        +СтатусПодключения : Boolean
        +ТехническиеПараметры : JSON
        +GPS_Координаты : Координаты
        +Предупреждения : String[]
        +Ошибки : String[]
    }
    
    class УведомленияОборудования {
        +Id : String
        +ЗаявкаId : String
        +ТипУведомления : ТипыУведомлений
        +ПолучательId : String
        +ТипПолучателя : ТипыПолучателей
        +ТекстУведомления : String
        +Приоритет : ПриоритетыУведомлений
        +ВремяОтправки : DateTime
        +СтатусДоставки : СтатусыДоставки
    }
    
    class ТипыУведомлений {
        <<enumeration>>
        ISSUE_CREATED
        STATUS_CHANGED
        COMMENT_ADDED
        CRITICAL_ALERT
        ISSUE_RESOLVED
    }
    
    ЗаявкиНаНеисправности --> ТипыОборудования
    ЗаявкиНаНеисправности --> ПриоритетыЗаявок
    ЗаявкиНаНеисправности --> СтатусыЗаявок
    ПараметрыМониторинга --> ТипыОборудования
    УведомленияОборудования --> ЗаявкиНаНеисправности
    УведомленияОборудования --> ТипыУведомлений

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

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

RQ192. Требование к получению данных мониторинга. Система должна:

Получать данные состояния оборудования от серверной части через WebSocket
Обновлять параметры ТС каждые 30 секунд при активном экране
Обновлять параметры зарядной станции каждые 15 секунд при активной зарядке
Кешировать последние полученные данные для работы в офлайн режиме

RQ193. Требование к синхронизации заявок. Система должна:

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

Требования к интеграции с другими блоками

RQ194. Требование к интеграции с блоком выполнения заказов. Блок должен:

Предоставлять данные о состоянии зарядной станции для UC016 (мониторинг зарядки)
Получать информацию о текущем заказе для контекста заявок
Блокировать создание заявок на оборудование при активной зарядке (кроме критических)

RQ195. Требование к интеграции с блоком уведомлений. Блок должен:

Отправлять push-уведомления при критических проблемах оборудования
Получать уведомления об изменениях статуса заявок
Интегрироваться с системой SMS для экстренных уведомлений

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

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

Отображать данные мониторинга не более чем за 2 секунды
Обрабатывать обновления параметров без блокировки интерфейса
Поддерживать одновременную работу мониторинга ТС и станции
Минимизировать расход батареи мобильного устройства

RQ197. Требование к надежности работы. Система должна:

Сохранять функциональность при потере связи с сервером до 30 минут
Автоматически восстанавливать соединение при появлении связи
Сохранять локально данные о заявках до успешной отправки
Предоставлять альтернативные способы связи при сбоях системы

Блок «Навигация и геолокация» - Модуль Техника

Описание блока

Блок «Навигация и геолокация» обеспечивает автоматическое определение местоположения техника, построение маршрутов к клиентам и пошаговую навигацию с использованием Яндекс.Карт. Блок интегрируется с блоками «Выполнение заказов» и «Управление маршрутами» для автоматического переключения статусов на основе геособытий.

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

Автоматическая передача GPS-координат для отслеживания перемещений техника
Построение оптимальных маршрутов к адресам заказов через Яндекс.Карты API
Пошаговая навигация с голосовыми подсказками и визуальными указателями
Автоматическое определение прибытия в геозону заказа (радиус 100м)
Интеграция с Яндекс.Навигатором для расширенных навигационных возможностей
Визуализация местоположения на карте в реальном времени

UC030: Автоматическая передача GPS-координат в систему

Актор: Система (автоматический процесс)

Описание: Система автоматически получает GPS-координаты от мобильного устройства техника и передает их на сервер для отслеживания местоположения и определения геособытий.

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

graph TD
    Start([Начало: Запуск приложения]) --> S1[Система: Запрашивает разрешение на геолокацию]
    S1 --> D1{Разрешение получено?}
    D1 -->|Нет| S2[Система: Отображает предупреждение о необходимости геолокации]
    D1 -->|Да| S3[Система: Инициализирует GPS-модуль]
    S3 --> S4[Система: Настраивает параметры отслеживания]
    S4 --> L1[Цикл: Непрерывное отслеживание]
    L1 --> S5[Система: Получает текущие GPS-координаты]
    S5 --> D2{GPS-сигнал доступен?}
    D2 -->|Нет| S6[Система: Использует последние известные координаты]
    D2 -->|Да| S7[Система: Валидирует точность координат]
    S6 --> S8[Система: Отмечает данные как неточные]
    S7 --> D3{Точность приемлема?}
    D3 -->|Нет| S8
    D3 -->|Да| S9[Система: Сохраняет координаты локально]
    S8 --> S10[Система: Передает данные на сервер с отметкой о точности]
    S9 --> S10
    S10 --> S11[Система: Проверяет активные геозоны]
    S11 --> D4{Техник в активной геозоне?}
    D4 -->|Да| S12[Система: Отмечает время нахождения в геозоне]
    D4 -->|Нет| S13[Система: Сбрасывает счетчики геозон]
    S12 --> D5{В геозоне > 30 сек?}
    D5 -->|Да| S14[Система: Инициирует автоматическое изменение статуса]
    D5 -->|Нет| S15[Система: Ожидает следующее измерение]
    S13 --> S15
    S14 --> S15
    S15 --> D6{Приложение активно?}
    D6 -->|Да| L1
    D6 -->|Нет| End([Конец])
    S2 --> End

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

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

5 секунд при активном маршруте (статус IN_PROGRESS)
30 секунд при ожидании заказов
60 секунд в режиме ожидания без активных задач

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

Принимать координаты с точностью не менее 50 метров
Игнорировать координаты с точностью хуже 200 метров
Использовать последние достоверные координаты при плохом сигнале
Уведомлять о проблемах с GPS при отсутствии сигнала более 2 минут

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

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

RQ303. Требование к энергопотреблению. Система должна:

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

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

Продолжать отслеживание при свернутом приложении
Отправлять push-уведомления о критических геособытиях
Поддерживать работу GPS в фоновом режиме до 8 часов
Автоматически возобновлять отслеживание при открытии приложения

UC031: Построение маршрута к адресу заказа

Актор: Техник

Описание: Техник запрашивает построение маршрута от текущего местоположения до адреса клиента с использованием Яндекс.Карт API.

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

graph TD
    Start([Начало]) --> A1[Техник: Нажимает 'Построить маршрут' в карточке заказа]
    A1 --> S1[Система: Проверяет доступность заказа]
    S1 --> D1{Заказ доступен для навигации?}
    D1 -->|Нет| S2[Система: Отображает сообщение о недоступности]
    D1 -->|Да| S3[Система: Получает текущие GPS-координаты техника]
    S3 --> D2{GPS-координаты доступны?}
    D2 -->|Нет| S4[Система: Предлагает ввести начальную точку вручную]
    D2 -->|Да| S5[Система: Отображает экран построения маршрута<br/>ссылка: ЭкранПостроенияМаршрута]
    S4 --> S5
    S5 --> S6[Система: Вызывает Яндекс.Карты API для построения маршрута]
    S6 --> D3{Маршрут построен успешно?}
    D3 -->|Нет| S7[Система: Отображает ошибку и предлагает альтернативы]
    D3 -->|Да| S8[Система: Анализирует варианты маршрутов]
    S8 --> S9[Система: Выбирает оптимальный маршрут по времени]
    S9 --> S10[Система: Отображает маршрут на карте<br/>ссылка: КартаМаршрута]
    S10 --> A2[Техник: Просматривает детали маршрута]
    A2 --> D4{Выбор действия}
    D4 -->|Начать навигацию| A3[Техник: Нажимает 'Начать навигацию']
    D4 -->|Яндекс.Навигатор| A4[Техник: Нажимает 'Открыть в Яндекс.Навигаторе']
    D4 -->|Отмена| A5[Техник: Нажимает 'Отмена']
    A3 --> S11[Система: Переход к UC032 Пошаговая навигация]
    A4 --> S12[Система: Открывает Яндекс.Навигатор с координатами]
    A5 --> End([Конец])
    S11 --> End
    S12 --> End
    S2 --> End
    S7 --> End

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

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

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

RQ305. Требование к интеграции с Яндекс.Карты API. Система должна:

Использовать Яндекс.Карты API для построения маршрутов
Передавать текущие координаты техника как начальную точку
Использовать координаты заказа (Orders.latitude, Orders.longitude) как конечную точку
Учитывать текущую дорожную ситуацию и пробки

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

Запрашивать несколько вариантов маршрута (до 3)
Выбирать маршрут с минимальным временем в пути
Отдавать предпочтение автомобильным дорогам
Избегать платных дорог при настройке в профиле техника

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

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

RQ308. Требование к интеграции с Яндекс.Навигатором. Система должна:

Проверять наличие Яндекс.Навигатора на устройстве
Открывать Яндекс.Навигатор с предустановленными координатами
Передавать адрес назначения в понятном формате
При отсутствии приложения предлагать его скачивание

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

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

UC032: Пошаговая навигация к клиенту

Актор: Техник

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

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

graph TD
    Start([Начало: Запуск навигации]) --> S1[Система: Инициализирует навигационный режим]
    S1 --> S2[Система: Включает экран постоянного отображения]
    S2 --> S3[Система: Активирует голосовые подсказки]
    S3 --> S4[Система: Отображает навигационный интерфейс<br/>ссылка: ЭкранНавигации]
    S4 --> L1[Цикл: Активная навигация]
    L1 --> S5[Система: Получает текущие GPS-координаты]
    S5 --> S6[Система: Рассчитывает отклонение от маршрута]
    S6 --> D1{Техник на маршруте?}
    D1 -->|Нет| S7[Система: Предлагает перестроение маршрута]
    D1 -->|Да| S8[Система: Определяет следующий маневр]
    S8 --> S9[Система: Рассчитывает расстояние до поворота]
    S9 --> D2{До маневра < 200м?}
    D2 -->|Да| S10[Система: Воспроизводит голосовую подсказку]
    D2 -->|Нет| S11[Система: Обновляет информацию на экране]
    S10 --> S11
    S11 --> S12[Система: Проверяет близость к цели]
    S12 --> D3{До цели < 100м?}
    D3 -->|Да| S13[Система: Объявляет приближение к цели]
    D3 -->|Нет| D4{В геозоне заказа?}
    D4 -->|Да| S14[Система: Автоматически завершает навигацию]
    D4 -->|Нет| D5{Навигация активна?}
    D5 -->|Да| L1
    D5 -->|Нет| End([Конец])
    S13 --> S14
    S14 --> S15[Система: Переход к UC033 Автоматическое определение прибытия]
    S15 --> End
    S7 --> A1[Техник: Выбирает перестроить или продолжить]
    A1 --> D6{Решение техника}
    D6 -->|Перестроить| S16[Система: Переход к UC031 Построение маршрута]
    D6 -->|Продолжить| L1
    S16 --> End

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

classDiagram
    class ЭкранНавигации {
        <<Screen>>
        +КартаНавигации : КомпонентКарты
        +ПанельИнструкций : ОбластьИнструкций
        +ИнформационнаяПанель : ОбластьИнформации
        +КнопкиУправления : ГруппаКнопок
        +ИндикаторGPS : СтатусИндикатор
    }
    
    class ОбластьИнструкций {
        <<Area>>
        +ИконкаМаневра : Изображение
        +ТекстИнструкции : Текст
        +РасстояниеДоМаневра : Расстояние
        +НазваниеУлицы : Текст
    }
    
    class ОбластьИнформации {
        <<Area>>
        +ОставшеесяВремя : ВременноеПоле
        +ОставшеесяРасстояние : РасстояниеПоле
        +ВремяПрибытия : ВременноеПоле
        +ТекущаяСкорость : СкоростьПоле
    }
    
    class ГруппаКнопок {
        <<Area>>
        +КнопкаЗавершить : Кнопка
        +КнопкаПерестроить : Кнопка
        +КнопкаЗвук : КнопкаВклОткл
        +КнопкаЦентрировать : Кнопка
    }
    
    ЭкранНавигации *-- ОбластьИнструкций
    ЭкранНавигации *-- ОбластьИнформации
    ЭкранНавигации *-- ГруппаКнопок

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

RQ310. Требование к голосовым подсказкам. Система должна:

Воспроизводить голосовые инструкции за 200 метров до поворота
Повторять инструкцию за 50 метров до маневра
Использовать четкие и понятные формулировки
Позволять отключение/включение голоса техником

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

Стрелки направления движения
Иконки типов маневров (поворот, разворот, прямо)
Названия улиц и номера домов
Полосы движения при их наличии в данных карты

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

Проверять соответствие текущего положения маршруту каждые 5 секунд
Считать техника сбившимся с маршрута при отклонении более 100 метров
Автоматически предлагать перестроение маршрута при отклонении
Учитывать направление движения при определении отклонения

RQ313. Требование к обновлению информации. В реальном времени система должна показывать:

Оставшееся время до прибытия
Оставшееся расстояние в км
Текущую скорость движения
Ожидаемое время прибытия

RQ314. Требование к завершению навигации. Система должна:

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

UC033: Автоматическое определение прибытия в геозону заказа

Актор: Система (автоматический процесс)

Описание: Система автоматически определяет момент прибытия техника в геозону заказа (радиус 100 метров от адреса) и переводит заказ в статус ARRIVED.

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

graph TD
    Start([Начало: GPS-данные от техника]) --> S1[Система: Получает GPS-координаты техника]
    S1 --> S2[Система: Получает список активных заказов техника]
    S2 --> D1{Есть заказы со статусом EN_ROUTE?}
    D1 -->|Нет| End([Конец])
    D1 -->|Да| L1[Цикл: По каждому заказу EN_ROUTE]
    L1 --> S3[Система: Рассчитывает расстояние до адреса заказа]
    S3 --> D2{Расстояние ≤ 100 метров?}
    D2 -->|Нет| S4[Система: Обновляет ETA для клиента]
    D2 -->|Да| S5[Система: Проверяет время нахождения в геозоне]
    S5 --> D3{В геозоне непрерывно > 30 секунд?}
    D3 -->|Нет| S6[Система: Увеличивает счетчик времени в геозоне]
    D3 -->|Да| S7[Система: Проверяет точность GPS]
    S7 --> D4{Точность GPS приемлема?}
    D4 -->|Нет| S8[Система: Ожидает более точные данные]
    D4 -->|Да| S9[Система: Изменяет Orders.status на ARRIVED]
    S9 --> S10[Система: Создает запись в OrderStatusHistories]
    S10 --> S11[Система: Сохраняет GPS-координаты прибытия]
    S11 --> S12[Система: Останавливает отслеживание маршрута]
    S12 --> S13[Система: Отправляет push-уведомление технику]
    S13 --> S14[Система: Отправляет уведомление клиенту]
    S14 --> S15[Система: Уведомляет диспетчера об автоматическом изменении]
    S15 --> S16[Система: Активирует возможность начала зарядки]
    S16 --> End
    S4 --> D5{Есть еще заказы?}
    S6 --> D5
    S8 --> D5
    D5 -->|Да| L1
    D5 -->|Нет| End

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

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

Расстояние от GPS-координат техника до координат заказа (Orders.latitude, Orders.longitude) ≤ 100 метров
Техник находится в данной геозоне непрерывно более 30 секунд
Заказ имеет статус EN_ROUTE
Точность GPS составляет не более 50 метров

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

Использовать формулу гаверсинуса для расчета расстояния по координатам
Учитывать погрешность GPS (буферная зона 100±20 метров)
Игнорировать кратковременные "скачки" GPS-сигнала
Требовать минимум 3 последовательных измерения в геозоне

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

Изменить Orders.status на ARRIVED
Создать запись в OrderStatusHistories с указанием previousStatus = EN_ROUTE, newStatus = ARRIVED
Установить OrderStatusHistories.idUser = ID техника заказа
Указать OrderStatusHistories.reason = "Автоматическое определение прибытия по GPS"
Сохранить точные GPS-координаты момента прибытия

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

Отправить push-уведомление технику: "Вы прибыли к клиенту. Можете начинать зарядку."
Отправить уведомление клиенту: "Техник прибыл. Ожидайте начала зарядки."
Уведомить диспетчера об автоматическом изменении статуса с указанием времени и координат
Записать событие в системный журнал для аудита

RQ319. Требование к обработке ошибок GPS. При проблемах с GPS система должна:

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

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

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

UC034: Отображение текущего местоположения на карте

Актор: Техник

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

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

graph TD
    Start([Начало]) --> A1[Техник: Открывает раздел 'Карта']
    A1 --> S1[Система: Инициализирует компонент Яндекс.Карты]
    S1 --> S2[Система: Получает текущие GPS-координаты]
    S2 --> D1{GPS-координаты доступны?}
    D1 -->|Нет| S3[Система: Показывает последнее известное местоположение]
    D1 -->|Да| S4[Система: Центрирует карту на текущем местоположении]
    S3 --> S5[Система: Отображает предупреждение о недоступности GPS]
    S4 --> S6[Система: Отображает экран карты<br/>ссылка: ЭкранКарты]
    S5 --> S6
    S6 --> S7[Система: Загружает активные заказы техника]
    S7 --> S8[Система: Отмечает адреса заказов маркерами]
    S8 --> S9[Система: Отображает геозоны активных заказов]
    S9 --> S10[Система: Показывает пройденный путь за смену]
    S10 --> L1[Цикл: Обновление в реальном времени]
    L1 --> S11[Система: Обновляет текущее местоположение]
    S11 --> S12[Система: Обновляет маркеры и геозоны]
    S12 --> A2[Техник: Взаимодействует с картой]
    A2 --> D2{Тип взаимодействия}
    D2 -->|Нажатие на заказ| A3[Техник: Выбирает маркер заказа]
    D2 -->|Управление картой| A4[Техник: Масштабирует/перемещает карту]
    D2 -->|Центрирование| A5[Техник: Нажимает кнопку центрирования]
    A3 --> S13[Система: Отображает детали заказа]
    A4 --> S14[Система: Обновляет отображение карты]
    A5 --> S15[Система: Центрирует карту на текущем местоположении]
    S13 --> D3{Доступна навигация?}
    D3 -->|Да| S16[Система: Предлагает построить маршрут]
    D3 -->|Нет| L1
    S14 --> L1
    S15 --> L1
    S16 --> D4{Техник выбирает действие}
    D4 -->|Навигация| S17[Система: Переход к UC031 Построение маршрута]
    D4 -->|Закрыть| L1
    S17 --> End([Конец])

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

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

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

RQ321. Требование к инициализации карты. Система должна:

Использовать Яндекс.Карты API для отображения карты
Центрировать карту на текущем местоположении техника
Устанавливать масштаб карты для охвата рабочей области (зум 13-15)
Отображать спутниковый или гибридный слой по выбору техника

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

Текущее местоположение техника синим маркером с индикацией направления
Заказы со статусом ASSIGNED - зеленые маркеры
Заказы со статусом EN_ROUTE - желтые маркеры
Заказы со статусом ARRIVED - красные маркеры
Базу начала/окончания смены - специальный маркер дома

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

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

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

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

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

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

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

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

Общие требования к блоку «Навигация и геолокация»

Требования к интеграции с другими блоками

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

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

RQ328. Требование к связи с блоком управления маршрутами. Система должна интегрироваться с блоком "Управление маршрутами" для:

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

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

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

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

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

Инициализацию карты не более чем за 3 секунды
Построение маршрута не более чем за 5 секунд
Обновление GPS-координат не более чем за 2 секунды
Отклик на взаимодействие с картой не более чем за 1 секунду

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

Оптимизировать частоту GPS-запросов для экономии батареи
Кэшировать тайлы карты для снижения трафика
Использовать не более 50 МБ оперативной памяти для карты
Автоматически снижать качество при слабом интернет-соединении

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

Продолжать работу при временной потере GPS-сигнала
Использовать данные сотовых вышек при недоступности GPS
Предупреждать о проблемах с геолокацией
Сохранять последние известные координаты локально

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

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

Запрашивать разрешение на точную геолокацию
Запрашивать разрешение на фоновое использование GPS
Объяснять техникам необходимость предоставления разрешений
Корректно обрабатывать отказ в предоставлении разрешений

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

Передавать GPS-данные только на авторизованные серверы
Шифровать координаты при передаче по сети
Удалять старые GPS-данные согласно политике хранения
Предоставлять техникам контроль над своими геоданными

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

Все изменения статусов на основе геособытий
Временные метки входа/выхода из геозон
Ошибки определения местоположения
Действия техников в навигационном интерфейсе

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

RQ336. Требование к работе с Яндекс.Карты API. Система должна:

Использовать актуальную версию Яндекс.Карты API
Корректно обрабатывать ограничения API (лимиты запросов)
Кэшировать результаты запросов для оптимизации
Иметь план резервного картографического сервиса

RQ337. Требование к интеграции с Яндекс.Навигатором. Система должна:

Проверять наличие приложения Яндекс.Навигатор
Формировать корректные deep links для запуска навигации
Обрабатывать случаи отсутствия или устаревшей версии приложения
Предлагать альтернативную навигацию при недоступности

Требования к работе в неблагоприятных условиях

RQ338. Требование к работе при слабом сигнале. При проблемах с GPS система должна:

Переключаться на менее точные, но доступные методы позиционирования
Увеличивать интервал между запросами координат
Информировать техника о снижении точности
Сохранять функциональность навигации при возможности

RQ339. Требование к работе при слабом интернете. При проблемах с сетью система должна:

Использовать кэшированные данные карт
Снижать качество и детализацию карты
Сохранять GPS-данные локально для последующей синхронизации
Предоставлять базовую навигацию без подключения к интернету

RQ340. Требование к энергоэффективности. Система должна:

Адаптивно изменять частоту GPS-запросов в зависимости от движения
Использовать энергосберегающие режимы при низком заряде батареи
Автоматически отключать ненужные функции при критическом заряде
Предупреждать техника о высоком расходе энергии

Диаграмма состояний навигационной системы

stateDiagram-v2
    [*] --> Инициализация
    Инициализация --> ОжиданиеРазрешений : Запрос разрешений GPS
    ОжиданиеРазрешений --> НеактивнаяГеолокация : Разрешения отклонены
    ОжиданиеРазрешений --> АктивнаяГеолокация : Разрешения получены
    
    АктивнаяГеолокация --> Отслеживание : GPS сигнал доступен
    АктивнаяГеолокация --> РежимЭкономии : Низкий заряд батареи
    
    Отслеживание --> Навигация : Запуск навигации к заказу
    Отслеживание --> Мониторинг : Обычное отслеживание
    
    Навигация --> ВГеозоне : Вход в геозону заказа
    ВГеозоне --> АвтоПрибытие : > 30 секунд в геозоне
    АвтоПрибытие --> Отслеживание : Статус изменен на ARRIVED
    
    Мониторинг --> Отслеживание : Получение GPS данных
    РежимЭкономии --> Отслеживание : Восстановление заряда
    
    НеактивнаяГеолокация --> [*] : Завершение работы
    Отслеживание --> [*] : Завершение смены
    
    note right of ВГеозоне : Радиус 100м от адреса заказа
    note right of АвтоПрибытие : Автоматическое изменение статуса
    note left of РежимЭкономии : Снижение частоты GPS до 60 сек

Блок «Отчетность и история» - Модуль Техника

Блок включает 4 функции (UC035-UC038) для обеспечения техников инструментами анализа работы и планирования деятельности.

UC035: Просмотр статистики выполненных заказов

Актор: Техник

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

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

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

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

classDiagram
    class СтатистикаЗаказовТехника {
        <<Screen>>
        +ОбластьФильтровПериода : ФильтрПериода
        +ОбластьОсновныхМетрик : ОсновныеМетрики
        +ОбластьГрафиков : ОбластьГрафиков
        +ОбластьДетализации : ДетализацияМетрик
        +КнопкаОбновить : Button
    }
    
    class ФильтрПериода {
        <<Area>>
        +БыстрыеФильтры : SegmentedControl
        +ПроизвольныйПериод : DateRange
        +ФильтрПоСтатусу : CheckBoxGroup
        +ФильтрПоТипуЗаказа : CheckBoxGroup
    }
    
    class ОсновныеМетрики {
        <<Area>>
        +ВсегоЗаказов : КарточкаМетрики
        +УспешныхЗаказов : КарточкаМетрики
        +НеуспешныхЗаказов : КарточкаМетрики
        +СреднееВремяВыполнения : КарточкаМетрики
        +ОбщаяСтоимость : КарточкаМетрики
        +ОбщаяЭнергия : КарточкаМетрики
    }
    
    class ОбластьГрафиков {
        <<Area>>
        +ГрафикЗаказовПоДням : LineChart
        +ГрафикЭнергииПоДням : BarChart
        +РаспределениеПоТипам : PieChart
    }
    
    СтатистикаЗаказовТехника *-- ФильтрПериода
    СтатистикаЗаказовТехника *-- ОсновныеМетрики
    СтатистикаЗаказовТехника *-- ОбластьГрафиков

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

RQ347. Требование к загрузке данных статистики. Система должна загружать заказы техника из Orders со статусами COMPLETED и FAILED, связанные с техником через RoutePoints и Routes.

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

Последние 7 дней
Текущий месяц
Последние 3 месяца
Текущий год
Произвольный период (с ограничением не более 3 лет истории)

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

Всего заказов: общее количество назначенных заказов
Успешных заказов: количество заказов со статусом COMPLETED
Неуспешных заказов: количество заказов со статусом FAILED
Процент успешности: (успешные/всего) * 100%
Среднее время выполнения: среднее время от ARRIVED до COMPLETED
Общая стоимость услуг: сумма totalPrice для COMPLETED заказов
Общее потребление энергии: сумма totalKwh для всех заказов

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

Детальную разбивку по дням/неделям
Сравнение с предыдущим периодом
Тренд изменения (рост/снижение в %)
Дополнительные подметрики (мин/макс значения, медиана)

RQ351. Требование к графической визуализации. Система должна отображать графики:

График заказов по дням: количество выполненных заказов по дням периода
График энергии по дням: объем переданной энергии по дням
Распределение по типам заказов: плановые vs экстренные (в %)
Распределение по времени выполнения: группировка заказов по длительности

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

Автоматически при открытии экрана
По нажатию кнопки "Обновить"
При изменении периода фильтрации
Данные должны кэшироваться на 5 минут для оптимизации

UC036: Просмотр статистики рабочего времени

Актор: Техник

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

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

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

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

classDiagram
    class СтатистикаВремениТехника {
        <<Screen>>
        +ОбластьВременныхМетрик : ВременныеМетрики
        +КалендарьСмен : КалендарнаяСетка
        +ОбластьАнализаЭффективности : АнализЭффективности
        +ГрафикРабочегоВремени : TemporalChart
        +СписокСменПериода : ТаблицаСмен
    }
    
    class ВременныеМетрики {
        <<Area>>
        +ОбщееВремяСмен : КарточкаВремени
        +ФактическоеВремяРаботы : КарточкаВремени
        +ВремяВыполненияЗаказов : КарточкаВремени
        +ВремяПеремещений : КарточкаВремени
        +ВремяПростоя : КарточкаВремени
        +СреднееВремяСмены : КарточкаВремени
    }
    
    class АнализЭффективности {
        <<Area>>
        +ПроцентВыполненияПлана : ProgressBar
        +КоэффициентЗагрузки : Gauge
        +СреднееКоличествоЗаказовВСмену : NumberDisplay
        +ОтклонениеОтПлановогоВремени : DeltaDisplay
    }
    
    СтатистикаВремениТехника *-- ВременныеМетрики
    СтатистикаВремениТехника *-- АнализЭффективности

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

RQ353. Требование к загрузке данных смен. Система должна загружать все смены техника из WorkShifts со статусами COMPLETED и CANCELLED за выбранный период.

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

Общее время смен: сумма планового времени всех смен (plannedEndTime - plannedStartTime)
Фактическое время работы: сумма фактического времени (actualEndTime - actualStartTime)
Время выполнения заказов: время от первого ARRIVED до последнего COMPLETED по всем заказам
Время перемещений: время между завершением одного заказа и прибытием к следующему
Время простоя: разность между фактическим временем и временем выполнения заказов
Среднее время смены: общее время / количество смен

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

Процент выполнения плана: (фактическое время / плановое время) * 100%
Коэффициент загрузки: (время выполнения заказов / фактическое время) * 100%
Среднее количество заказов в смену: общее количество заказов / количество смен
Отклонение от планового времени: среднее отклонение начала/окончания смен

RQ356. Требование к календарной визуализации. Календарь смен должен отображать:

Все смены за выбранный период с цветовой индикацией статуса
Плановое и фактическое время для каждой смены
Количество выполненных заказов в смене
Индикатор эффективности смены (высокая/средняя/низкая)

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

Полную временную шкалу смены с событиями
Список всех выполненных заказов с временными метками
Маршруты и время перемещений между заказами
Время простоев и их причины (если указаны)

UC037: Формирование отчета о рабочей смене

Актор: Техник

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

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

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

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

classDiagram
    class ОтчетРабочейСмены {
        <<Screen>>
        +ВыборСмены : ShiftPicker
        +ЗаголовокОтчета : ОбластьЗаголовка
        +РезюмеСмены : РезюмеСмены
        +ДетализацияЗаказов : СписокЗаказовСмены
        +ВременнаяШкала : ВременнаяЛиния
        +СтатистикаСмены : СтатистическиеПоказатели
        +КнопкиДействий : ОбластьДействий
    }
    
    class ОбластьЗаголовка {
        <<Area>>
        +ДатаСмены : Label
        +ФИОТехника : Label
        +СтатусСмены : StatusBadge
        +ОбщаяДлительностьСмены : Label
    }
    
    class РезюмеСмены {
        <<Area>>
        +ВремяНачалаСмены : TimeField[readonly]
        +ВремяОкончанияСмены : TimeField[readonly]
        +БазаНачала : TextField[readonly]
        +БазаОкончания : TextField[readonly]
        +ПлановаяДлительность : TextField[readonly]
        +ФактическаяДлительность : TextField[readonly]
    }
    
    class СтатистическиеПоказатели {
        <<Area>>
        +КоличествоЗаказов : NumberDisplay
        +УспешноВыполненных : NumberDisplay
        +ОбщаяСтоимостьУслуг : MoneyDisplay
        +ПереданнаяЭнергия : EnergyDisplay
        +СреднееВремяЗаказа : TimeDisplay
        +КилометражПробега : DistanceDisplay
    }
    
    ОтчетРабочейСмены *-- ОбластьЗаголовка
    ОтчетРабочейСмены *-- РезюмеСмены
    ОтчетРабочейСмены *-- СтатистическиеПоказатели

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

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

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

RQ359. Требование к структуре отчета. Отчет должен содержать следующие разделы:

Заголовок: дата смены, ФИО техника, общая информация о смене
Резюме смены: плановые и фактические времена, базы начала/окончания
Статистика смены: ключевые числовые показатели
Детализация заказов: хронологический список всех заказов смены
Временная шкала: визуальное представление событий смены
Проблемы и замечания: зафиксированные проблемы с оборудованием или заказами

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

Общее количество назначенных заказов в смене
Количество успешно выполненных заказов (COMPLETED)
Общую стоимость оказанных услуг за смену
Общее количество переданной энергии (кВт⋅ч) за смену
Среднее время выполнения одного заказа
Общий километраж (по GPS-трекам между заказами)
Время простоев и их причины

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

Номер заказа и тип (плановый/экстренный)
Время прибытия и завершения
Адрес выполнения и данные клиента
Параметры зарядки (начальный/конечный уровень, потребленная энергия)
Стоимость услуги
Статус выполнения и возможные проблемы

RQ362. Требование к временной шкале. Временная шкала должна отображать:

Начало и окончание рабочей смены
Время выезда к каждому клиенту (EN_ROUTE)
Время прибытия к клиенту (ARRIVED)
Время начала и завершения зарядки (CHARGING → COMPLETED)
Время перемещений между заказами
Время простоев

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

Сохранения отчета в формате PDF для локального хранения
Отправки отчета диспетчеру через внутреннюю систему
Формирования отчета за произвольную смену (в пределах 3 лет истории)
Включения фотографий выполненных заказов в PDF-отчет

UC038: Просмотр рейтинга и оценок от клиентов

Актор: Техник

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

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

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

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

classDiagram
    class РейтингИОценкиТехника {
        <<Screen>>
        +ОбластьОбщегоРейтинга : ОбщийРейтинг
        +ОбластьСтатистикиОценок : СтатистикаОценок
        +ФильтрПериода : PeriodFilter
        +СписокОценок : СписокОценокБезТекста
        +ГрафикДинамики : RatingTrendChart
        +КнопкаСводкиОтзывов : Button
    }
    
    class ОбщийРейтинг {
        <<Area>>
        +СреднийРейтинг : StarRating[5.0]
        +КоличествоОценок : Counter
        +ПозицияВРейтинге : RankDisplay
        +ИзменениеЗаПериод : TrendIndicator
    }
    
    class СтатистикаОценок {
        <<Area>>
        +Распределение5Звезд : ProgressBar
        +Распределение4Звезды : ProgressBar
        +Распределение3Звезды : ProgressBar
        +Распределение2Звезды : ProgressBar
        +Распределение1Звезда : ProgressBar
    }
    
    class КарточкаОценки {
        <<Area>>
        +РейтингКлиента : StarRating
        +ДатаОценки : DateLabel
        +НомерЗаказа : OrderLink
        +ТипЗаказа : OrderTypeLabel
        +ИнициалыКлиента : ClientInitials
    }
    
    class СводкаОтзывов {
        <<Screen>>
        +ОбщиеТемы : ОбластьОбщихТем
        +ПозитивныеМоменты : ОбластьПозитива
        +ВозможностиУлучшения : ОбластьУлучшений
        +РекомендацииСистемы : ОбластьРекомендаций
    }
    
    РейтингИОценкиТехника *-- ОбщийРейтинг
    РейтингИОценкиТехника *-- СтатистикаОценок
    РейтингИОценкиТехника *-- КарточкаОценки

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

RQ364. Требование к загрузке данных рейтинга. Система должна:

Загружать все отзывы о технике из Reviews где idUserAuthor = ID техника
Фильтровать только отзывы с типом TECHNICIAN_REVIEW
Связывать отзывы с заказами через Reviews.idOrder
Ограничивать период загрузки последними 3 годами

RQ365. Требование к расчету общего рейтинга. Система должна рассчитывать:

Средний рейтинг: среднее арифметическое всех оценок (rating) с точностью до 0.1
Общее количество оценок: подсчет всех отзывов с рейтингом
Распределение по звездам: процентное соотношение оценок 1-5 звезд
Динамика изменения: сравнение с предыдущим периодом в %

RQ366. Требование к отображению оценок. Каждая оценка должна содержать:

Рейтинг клиента (1-5 звезд)
Дату создания оценки
Номер связанного заказа (кликабельная ссылка)
Инициалы клиента (без полного имени для конфиденциальности)
Тип заказа (плановый/экстренный)
Исключение: текст отзыва НЕ отображается

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

По периоду: последние 30 дней, 3 месяца, 6 месяцев, год, произвольный период (максимум 3 года)
По рейтингу: только высокие (4-5 звезд), средние (3 звезды), низкие (1-2 звезды)
По типу заказа: плановые, экстренные, все типы
Только с комментариями: фильтр для оценок, которые сопровождались текстовыми отзывами

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

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

RQ369. Требование к анализу динамики рейтинга. График динамики должен показывать:

Изменение среднего рейтинга по месяцам за последний год
Количество полученных оценок по периодам
Тренд изменения (улучшение/ухудшение)
Сравнение с общим рейтингом техников компании (если доступно)

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

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

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

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

Общие требования к блоку «Отчетность и история»

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

RQ372. Требование к времени загрузки данных. Система должна:

Загружать статистику за текущий месяц не более чем за 3 секунды
Формировать отчеты за период до 1 года не более чем за 10 секунд
Использовать кэширование для часто запрашиваемых данных
Отображать индикатор загрузки при длительных операциях

RQ373. Требование к объему данных. Система должна эффективно обрабатывать:

До 1000 заказов техника за месяц
До 50 рабочих смен в месяц
До 500 отзывов клиентов за год
Данные за период до 3 лет (период хранения в системе)

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

RQ374. Требование к интеграции с другими блоками. Блок должен интегрироваться с:

UC019 (просмотр истории заказов) для обеспечения единообразия данных
Блоком геолокации для получения данных о перемещениях
Системой уведомлений для информирования о готовности отчетов
Модулем диспетчера для передачи отчетов

RQ375. Требование к синхронизации данных. Статистические данные должны:

Обновляться в реальном времени при изменении статусов заказов
Учитывать корректировки данных, внесенные диспетчером
Сохранять историю изменений для обеспечения целостности отчетов

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

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

Собственным данным и статистике
Рейтингам оценок, оставленных о нем клиентами (без текстов отзывов)
Отчетам по своим рабочим сменам и заказам

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

Все операции просмотра статистики
Генерацию отчетов о рабочих сменах
Время и параметры каждого запроса
Попытки доступа к данным других техников

No comments to display

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

ТЗ на модуль Техника

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

OCPP Module Specification for EV Charging Stations

电动汽车充电站OCPP模块规范

New Page

ТЗ на модуль Техника

СТРУКТУРА ТЕХНИЧЕСКОГО ЗАДАНИЯ МОДУЛЯ ТЕХНИКА

Оглавление

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

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

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

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

2.3. Блок «Выполнение заказов»

2.4. Блок «Взаимодействие с клиентами»

2.5. Блок «Мониторинг оборудования»

2.6. Блок «Навигация и геолокация»

2.7. Блок «Отчетность и история»

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

4. Требования к геолокации и автоматизации

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

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

СПИСОК ФУНКЦИЙ МОДУЛЯ ТЕХНИКА

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

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

2.3. Блок «Выполнение заказов»

2.4. Блок «Взаимодействие с клиентами»

2.5. Блок «Мониторинг оборудования»

2.6. Блок «Навигация и геолокация»

2.7. Блок «Отчетность и история»

Ключевые особенности модуля:

Автоматизация на основе GPS:

Фотодокументирование:

Коммуникация:

Мониторинг оборудования:

Предлагаемые действия техника по статусам

Рабочая смена:

Маршрут:

Заказ:

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

Общее описание блока

UC001: Просмотр расписания рабочих смен

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

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

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

UC002: Начало рабочей смены

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

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

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

UC003: Завершение рабочей смены

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

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

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

UC004: Просмотр информации о текущей смене

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

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

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

UC005: Просмотр истории рабочих смен

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

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

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

Системные требования и интеграции

Требования к push-уведомлениям

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

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

Требования к интеграции с другими блоками

Модель предметной области (Domain Model)

Основные сущности блока

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

Общее описание блока

UC006: Получение и просмотр назначенного маршрута

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

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

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

UC007: Принятие назначенного маршрута

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

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

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

UC008: Отклонение маршрута с указанием причины

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