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

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

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: Просмотр рейтинга и оценок от клиентов
UC039: Экспорт данных о выполненной работе

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

Автоматизация на основе 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-модулями сервисных ТС для отслеживания местоположения
Системой управления автопарком для статусов оборудования
Биллинговой системой для расчета стоимости услуг

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

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

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

Оглавление

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-диаграмма (Диаграмма деятельности)

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

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

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

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

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

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