1.1 Назначение документа
Настоящий документ определяет полный набор требований к Автоматизированной Системе Управления заявками на осмотр судов в портах (далее - Портал "Осмотры судов" или "Портал", "Система") для использования в качестве основы для проектирования, разработки, тестирования и приемки системы.
1.2 Идентификация и наименование требований
В документе у каждого требования имеется свой уникальный код, состоящий из префикса, аббревиатуры функциональной возможности и трехзначного номера.
Префиксы:
- INSP-BR- - для идентификации бизнес-требований (исходные требования предоставленные Заказчиком),
- INSP-UC- - для идентификации сценариев использования,
- INSP-AT- - для идентификации атрибутов данных,
- INSP-NFR- - для идентификации нефункциональных требований.
Аббревиатуры функциональных возможностей системы:
- PRT - управление портами, причалами и стоянками
- VSS - управление суднами,
- APP - управление заявками,
- RPT - отчеты,
- AUTH - регистрация/авторизация,
- USR - управление пользователями,
- NTF - управление уведомлениями,
- FILE - управление файлами,
- COM - управление комментариями,
- CNTR - управление реестром Исполнителей,
- MAIN - главная
- AGNT - управление реестром Агентов,
- RSR - управление ресурсами Исполнителя.
1.3. Границы Системы
Настоящий раздел определяет функциональные и нефункциональные границы Портала, разделяя задачи, которые решает система, и те, которые остаются за ее пределами.
Входит в область действия (Scope) системы:
Функциональные модули:
• Управление справочниками системы (порты, флот).
• Управление заявками на осмотр.
• Управление пользователями, ролями и правами доступа.
• Формирование отчетности, актов (результаты осмотров).
• Система уведомлений и комментариев (для MVP только in-app уведомления без интеграций).
Роли пользователей:
• Агент
• Исполнитель
• Администрация порта
• Служба контроля (за рамками MVP)
• Системный администратор (за рамками MVP, в MVP справочники, данные пользователей будут внесены в БД без использования интерфейса)
Ключевые интеграции:
• С системой PortCall - для получения заявок на вход судна, передачи результатов осмотра (за рамками MVP, в MVP заявки будут создаваться вручную Агентом)
• Со внешними сервисами коммуникаций: Рассылка уведомлений по электронной почте, SMS, а также в мессенджеры (MAX). (вне MVP)
Назначение: Автоматизация и оптимизация ключевых процессов управления осмотрами судов, включая обработку заявок, формирование документов и планирование осмотров судов.
Не входит в область действия (Out of Scope) системы:
• Регистрация конечных клиентов: Самостоятельная регистрация в системе Физических и Юридических лиц (Судовладельцев).
• Прием платежей: Интеграция с онлайн-платежными системами для приема оплаты.
• Функциональность CRM: Поиск клиентов, управление продажами и маркетинговые активности остаются за пределами системы и осуществляются Агентами внешними средствами
Комментарии (25) · по состоянию на 2026-09-18
К фрагментам текста
[Ревью] Критично. Название системы обрывается многоточием и не совпадает ни с названием пространства («Осмотры судов»), ни с термином, используемым на остальных страницах («осмотр судов»). Нужно зафиксировать единое официальное название системы — риск закрепить неверное имя в коде/БД/UI/API.
Исправила
[Ревью] Уточнение внесено, но остался вопрос: в разделе 1.1 название теперь единообразно («Портал «Осмотры судов»»), это хорошо. Но в разделе 1.3 всё ещё осталась фраза «…(АСУ …)» с незаполненным многоточием — то же незавершённое сокращение, что и было. Предлагаю либо убрать «(АСУ …)» совсем, либо заменить на полное официальное название.
[Ревью] Решено, спасибо — в текущей редакции раздела 1.3 фрагмент «(АСУ …)» отсутствует, название системы используется единообразно («Портал «Осмотры судов»» / «Портал» / «Система»), что также подтверждается терминологией на других страницах (включая новый Глоссарий).
[Ревью] РЕШЕНО — можно удалить: название системы в текущей редакции единообразно во всех разделах («Портал «Осмотры судов»» / «Портал» / «Система»), фрагмент «(АСУ …)» отсутствует.
[Ревью] Критично, конфликт MVP-разметки. Модуль «Управление заявками» заявлен в скоупе без оговорок, но ключевая интеграция получения заявок из PortCall — «вне MVP». Нужно явно зафиксировать, как заявки будут создаваться в MVP при отсутствии этой интеграции (ручной ввод?).
В портале заявки на осмотр будут создаваться Агентами, интеграция с заявками из PortCall за рамками MVP
[Ревью] Уточнение внесено, но остался вопрос: спасибо за пояснение (заявки в MVP создают Агенты вручную, интеграция с PortCall — вне MVP), но в самом тексте раздела 1.3 это по-прежнему не зафиксировано — там всё так же просто «Управление заявками на осмотр» без оговорки про ручной ввод в MVP. Стоит добавить эту оговорку прямо в текст, чтобы не полагаться на комментарий.
[Ревью] Решено, спасибо — в текст раздела 1.3 добавлена явная оговорка «(за рамками MVP, в MVP заявки будут создаваться вручную Агентом)» рядом с описанием интеграции PortCall. Это согласуется с новой страницей решений (id 73075569), закрываем.
[Ревью] РЕШЕНО — можно удалить: в раздел 1.3 добавлена явная оговорка «(за рамками MVP, в MVP заявки будут создаваться вручную Агентом)» рядом с интеграцией PortCall, что снимает конфликт MVP-разметки для модуля «Управление заявками».
[Ревью] Критично, конфликт MVP-разметки. Роль «Системный администратор» вне MVP, но именно на неё завязано ведение справочников и пользователей (см. другие разделы). Кто выполняет эти функции в MVP?
Часть данных будет заведена вручную прямо в БД в рамках MVP, часть будет заводить Агент в MVP
[Ревью] Уточнение внесено, но остался вопрос: спасибо за пояснение (часть справочников заводится вручную в БД, часть — Агентом), но текст раздела 1.3 не изменился — «Системный администратор (вне MVP)» по-прежнему указан без пояснения, кто и как ведёт справочники/пользователей в MVP. Рекомендую отразить это пояснение прямо в документе.
[Ревью] Уточнение внесено частично: в текст добавлена фраза «в MVP справочники, данные пользователей будут внесены в БД без использования интерфейса» — но по новой странице решений (id 73075569) это не совсем точно: для справочников «Порты/Причалы/Стоянки» и «Суда» Агенты/Исполнители в MVP МОГУТ вносить новые данные через интерфейс (риск принят), вручную в БД заводятся только записи Агентов/Исполнителей, часть полей и справочник «Типы ресурсов». Формулировка в разделе 1.3 сейчас звучит так, будто вообще нет UI-ввода для справочников, что противоречит принятому решению. Предлагаю уточнить формулировку в 1.3 или дать ссылку на страницу решений.
[Ревью] Пока актуально: текст раздела 1.3 не изменился («…в MVP справочники, данные пользователей будут внесены в БД без использования интерфейса»). Это по-прежнему противоречит странице решений (id 73075569), где для справочников «Порты/Причалы/Стоянки» и «Суда» Агентам/Исполнителям в MVP разрешён ввод новых данных через интерфейс. Нужно скорректировать формулировку в 1.3 (например, уточнить, что без UI заводятся только записи Агентов/Исполнителей, часть полей и справочник «Типы ресурсов»), либо дать ссылку на страницу решений.
[Ревью] Желательно. Модуль заявлен в скоупе, но нет перечня конкретных отчётов, их полей и форматов экспорта — невозможно оценить объём работ.
Добавила Акты, но перечень данных здесь отображать не буду, в данном разделе это избыточно
[Ревью] Решено, спасибо — в перечень модуля явно добавлены «акты», это снимает основную неопределённость по составу отчётности для раздела 1. Решение не детализировать поля/форматы экспорта здесь обоснованно (эта информация уместнее в профильном разделе).
[Ревью] Критично, конфликт MVP-разметки. Модуль в скоупе без оговорок, но каналы уведомлений (email/SMS/MAX) ниже помечены «вне MVP» — нужно явно зафиксировать, что в MVP работает только in-app уведомление.
Добавила
[Ревью] Решено, спасибо — добавлена явная оговорка «(для MVP только in-app уведомления без интеграций)», конфликт с блоком «вне MVP» ниже снят.
К странице
Тестовая проверка возможности комментирования (будет удалено)
[Ревью] Прочие уточнения по разделу 1 «Введение»: 1) Нет перечня/ссылок на связанные документы (ТЗ, договор, архитектура) — агенту не с чем сверить источник требований. 2) Нет истории версий документа и статуса согласования (черновик/утверждено) — неясно, можно ли уже разрабатывать по текущей редакции. 3) Не указан владелец требований (контакт для эскалации неоднозначностей). 4) Нет глоссария терминов (осмотр, заявка, Агент, Исполнитель, Администрация порта и т.д.) — риск неверной интерпретации доменной модели. 5) Не определено само понятие MVP для проекта (сроки, критерии готовности, состав итераций).
[Ревью] Решено по всем пяти пунктам, спасибо: 1) Связанные документы — принято пояснение, что для этой инициативы отдельных ТЗ/договора нет. 2) История версий/статус — принято пояснение про конвенцию по умолчанию (нет пометки «в работе» → документ считается готовым/утверждённым). 3) Владелец требований — принято пояснение, что для инициативы формального владельца нет. 4) Глоссарий — добавлена страница «Глоссарий» (id 73075176), дочерняя к разделу 1. 5) Понятие MVP — добавлена страница «Список функций Портала «Осмотры судов»» (id 73075171) с разметкой MVP/После MVP по каждой функции, это рабочий ориентир.