INSP-UC-MAIN-001 | Главная для Агента |
Статус сценария: Ожидает согласования | |
Релиз: MVP | |
Бизнес-требование: Для каждой роли должна быть реализована отдельная Главная страница, где должна храниться максимально-необходимая информация и функционал | |
Точки входа:
| |
Предусловия
| |
Приоритет: Высокий (1) | |
Роли: Агент - далее Пользователь | |
Основной поток:
| |
Расширение: 2a. Отображение реестра Заявок
В каждой вкладке отображается счетчик кол-ва заявок во вкладке
2b. Перейти в Заявку 2c. Фильтры, сортировка, поиск в реестре Заявок
2d. Не данных 2e. Ошибка загрузки | |
Примечание: Цель Агента - видеть все свои заявки и их статус |
INSP-UC-MAIN-002 | Главная для Исполнителя |
Статус сценария: Ожидает согласования | |
Релиз: MVP | |
Бизнес-требование: Для каждой роли должна быть реализована отдельная Главная страница, где должна храниться максимально-необходимая информация и функционал | |
Точки входа:
| |
Предусловия
| |
Приоритет: Высокий (1) | |
Роли: Исполнитель - далее Пользователь | |
Основной поток:
| |
Расширение: 2a. Отображение реестра Заявок
В каждой вкладке отображается счетчик кол-ва заявок во вкладке 2b. Перейти в Заявку 2c. Фильтры, сортировка, поиск в реестре Заявок
2d. Не данных 2e. Ошибка загрузки | |
Примечание: Цель Исполнителя - получить и выполнить заявку |
INSP-UC-MAIN-004 | Главная для Администрации порта |
Статус сценария: Ожидает согласования | |
Релиз: MVP | |
Бизнес-требование: Для каждой роли должна быть реализована отдельная Главная страница, где должна храниться максимально-необходимая информация и функционал | |
Точки входа:
| |
Предусловия
| |
Приоритет: Высокий (1) | |
Роли: Администрация порта - далее Пользователь | |
Основной поток:
| |
Расширение: 2a. Отображение реестра Заявок
В каждой вкладке отображается счетчик кол-ва заявок во вкладке 2b. Перейти в Заявку 2c. Фильтры, сортировка, поиск в реестре Заявок
2d. Не данных 2e. Ошибка загрузки | |
Примечание: Цель Администрации порта - видеть и контролировать все заявки на осмотр, получать статистику по осмотрам |
INSP-UC-MAIN-003 | Главная для Службы контроля |
Статус сценария: Ожидает согласования | |
Релиз: ПОСЛЕ MVP | |
Бизнес-требование: | |
Точки входа:
| |
Предусловия
| |
Приоритет: Высокий (1) | |
Роли: Служба контроля - далее Пользователь💬 | |
Основной поток:
| |
Расширение: 2a. Перейти в Заявку 2c. Настроить отображаемые данные статистики 2d. Фильтры, сортировка, поиск в реестре Заявок
| |
Примечание: Дашборды и уведомления могут добавляться в будущих доработках системы |
Комментарии (34) · по состоянию на 2026-09-18
К фрагментам текста
в MVP не будет
За прошлый месяц - должен быть слепок
Добавить минимальную статистику по МОИМ заявкам
кроме черновика
Только о завершении осмотров по заявке
[Ревью] Критично, После MVP. В сценарии «Главная для Службы контроля» (INSP-UC-MAIN-003) в поле «Роли» указано «Исполнитель», хотя по названию и контексту сценария (Заявки на регистрацию Исполнителя, статистика, контроль) должна быть роль «Служба контроля». Похоже на опечатку/копипаст из сценария Исполнителя — риск неверной реализации прав доступа при разработке.
[Ревью] Решено, спасибо — роль в сценарии «Главная для Службы контроля» исправлена на «Служба контроля».
[Ревью] РЕШЕНО — можно удалить. Роль в сценарии «Главная для Службы контроля» исправлена на «Служба контроля».
[Ревью] Критично, MVP. В реестре заявок для Службы контроля (UC-MAIN-003) упомянут статус «Поиск исполнителя», которого нет в списках статусов на вкладках у Агента/Исполнителя/Администрации порта на этой же странице. Набор статусов заявки расходится между разными ролевыми представлениями — нужен единый эталонный список статусов заявки (см. также раздел 3.3 Управление заявками), сверенный со всеми виджетами.
[Ревью] Решено, спасибо — упоминание статуса «Поиск исполнителя» убрано из раздела Службы контроля, расхождение снято.
[Ревью] РЕШЕНО — можно удалить. Упоминание статуса «Поиск исполнителя» убрано, расхождение статусов снято.
[Ревью] Желательно, MVP. Во вкладке «Ожидает назначение» для Агента объединены статусы «Черновик» (заявка ещё не отправлена, редактируется автором) и «Возвращено» (заявка была отклонена/возвращена после рассмотрения) — это концептуально разные состояния жизненного цикла заявки. Нужно подтвердить, что объединение в одну вкладку — осознанное UX-решение, а не недосмотр, и что пользователю будет понятно, почему заявки с разным смыслом статуса показаны вместе.
осознанное решение
[Ревью] Решено, спасибо за подтверждение — объединение «Черновик»+«Возвращено» во вкладке «Ожидает назначение» осознанное решение, вопросов нет.
[Ревью] РЕШЕНО — можно удалить. Подтверждено, что объединение статусов «Черновик»+«Возвращено» во вкладке — осознанное UX-решение.
[Ревью] Желательно, После MVP. Пункт «Статистика → 1. ???» — незаполненный плейсхолдер вместо содержимого. Нужно раскрыть, какие именно метрики/дашборды должна видеть Служба контроля.
[Ревью] Решено, спасибо — плейсхолдер «???» убран из пункта «Статистика».
[Ревью] РЕШЕНО — можно удалить. Плейсхолдер «???» в пункте «Статистика» убран.
[Ревью] Желательно, MVP. Для виджета «Мои заявки» не указан лимит отображаемых записей на странице/во вкладке, наличие пагинации (или бесконечная подгрузка) и сортировка по умолчанию (например, по дате создания/обновления). Это нужно для проектирования UI и производительности запроса.
добавила
[Ревью] Решено, спасибо — добавлено «по умолчанию сортировка от новых к старым, пагинация по 10» для виджета «Мои заявки».
[Ревью] РЕШЕНО — можно удалить. Пагинация (по 10) и сортировка по умолчанию для виджета «Мои заявки» добавлены.
[Ревью] Критично, MVP. Для виджета «Уведомления» (колокольчик) не описано: как визуально/логически различаются прочитанные и непрочитанные уведомления, как считается счётчик непрочитанных, и обновляются ли уведомления в реальном времени (push/WebSocket) или только при обновлении страницы/по интервалу опроса (polling). Это существенно влияет на архитектуру (нужен ли WebSocket-канал) и должно быть решено до разработки MVP.
Визуально - если пользователь нажал на кнопку “прочитано” - то данное уведомление больше не отображается в колокольчике. Это описано в сценарии INSP-UC-NTF-006
[Ревью] Уточнение внесено, но остался вопрос: спасибо за пояснение визуального поведения (уведомление пропадает из колокольчика после «прочитано», см. INSP-UC-NTF-006). Однако механизм обновления в реальном времени (push/WebSocket) vs. опрос/обновление страницы по-прежнему не указан — важно для архитектурного решения перед разработкой MVP.
[Ревью] Раунд 3. Пока актуально — механизм обновления уведомлений в реальном времени (push/WebSocket) vs. опрос/обновление страницы (polling) по-прежнему не указан. Новое решение (стр. 73075569) этот вопрос не затрагивает — требуется отдельное архитектурное решение перед разработкой MVP.
[Ревью] Пока актуально: механизм обновления уведомлений в реальном времени (push/WebSocket) vs. опрос/обновление страницы (polling) по-прежнему не указан на странице. Требуется отдельное архитектурное решение перед разработкой MVP.
[Ревью] Желательно, После MVP. Для статистического среза «по конкретному Агенту/Исполнителю» не указано, как именно пользователь выбирает конкретного Агента/Исполнителя (поиск по строке, выпадающий список, автокомплит), и обновляются ли цифры статистики в реальном времени при изменении данных или пересчитываются по расписанию/при обновлении страницы.
Статистика должна отображаться в виде таблицы, данные пусть обновляются один раз в 10 минут
[Ревью] Уточнение внесено, но остался вопрос: спасибо, периодичность обновления статистики (раз в 10 минут) и формат (таблица) зафиксированы. Способ выбора конкретного Агента/Исполнителя (поиск/выпадающий список/автокомплит) пока не описан.
[Ревью] Уточнение внесено частично: периодичность обновления статистики (раз в 10 минут) и формат (таблица) зафиксированы — спасибо. Способ выбора конкретного Агента/Исполнителя в срезе статистики (поиск/выпадающий список/автокомплит) пока не описан.
К странице
[Ревью] Критично, MVP. По всем виджетам главной страницы (Мои заявки, Уведомления, Статистика) не описано поведение при пустом состоянии («нет данных для отображения») и при ошибке загрузки данных виджета (таймаут, ошибка сервера). Нужно явно определить UX для этих случаев — иначе они останутся не проработаны при разработке.
добавила
[Ревью] Решено, спасибо — во всех сценариях Главной (Агент/Исполнитель/Администрация порта) добавлены расширения «Нет данных» и «Ошибка загрузки» для виджетов.