| Идентификатор требования | Описание первоначальных требований | Комментарий |
|---|---|---|
| Общие требования | ||
INSP-BR-001 | Управление заявками на осмотр судов. | |
INSP-BR-002 | Интерфейс личного кабинета должен быть интуитивно понятным и доступным для пользователей с базовыми навыками работы на компьютере. | |
INSP-BR-003 | Программа должна работать на всех современных браузерах и быть адаптирована для мобильных устройств. | |
| Регистрация и аутентификация пользователей | ||
INSP-BR-004 | Создание учётных записей с правами доступа. | |
INSP-BR-005 | Вход в систему с использованием логина и пароля. | |
INSP-BR-006 | Восстановление пароля через систему уведомлений. | За рамками MVP |
INSP-BR-007 | Система ролей и прав доступа. | За рамками MVP |
| Модуль подачи заявок: | ||
INSP-BR-008 | Форма для ввода данных о заявке, в которой хранится основная информация необходимая для проведения осмотра: данные Агента, данные Заказчика, данные судна, данные Исполнителя, планирование осмотра.💬 | |
INSP-BR-009 | Выбор судна из списка существующих. | Справочник судов с характеристиками |
INSP-BR-010 | Указание портов отправления и назначения. | |
INSP-BR-011 | Выбор планируемой даты осмотра. | |
INSP-BR-012 | Сохранение статуса заявки (создана, в обработке, выполнена). | |
INSP-BR-013 | История изменения заявки | |
INSP-BR-014 | Подсказки по заполнению форм ввода | |
INSP-BR-015 | Прикрепление и предварительный просмотр документов | |
| Модуль документооборота | ||
INSP-BR-016 | Экспорт данных заявки по шаблону в формат Word/PDF | |
INSP-BR-017 | Генерация Акта осмотра по шаблонус результатами проведенного осмотра | |
INSP-BR-018 | Прикрепление к заявкам различных форматов файлов | |
| Уведомления и оповещения | ||
INSP-BR-019 | Уведомления об изменении статуса заявки | |
| Нефункциональные требования | ||
INSP-BR-020 | Защита данных пользователей с использованием шифрования. | |
INSP-BR-021 | Регулярное резервное копирование данных. | |
INSP-BR-022 | Быстрая обработка данных и генерация документов.💬 | |
INSP-BR-023 | Оптимизация интерфейса для работы с большими объёмами данных. | |
INSP-BR-024 | Поддержка русского и английского языков.💬 | |
Комментарии (21) · по состоянию на 2026-09-18
К фрагментам текста
[Ревью] Критично: раздел «Модуль грузовых отчётов» — 2 из 3 строк требований пустые, заполнена только «Экспорт данных в Excel формат». Само название модуля опять отсылает к терминологии грузоперевозок (копипаста из другого проекта) и требование фактически без содержания. Нужно либо наполнить модуль реальными требованиями по отчётности осмотров, либо удалить раздел.
[Ревью] Решено, спасибо — раздел «Модуль грузовых отчётов» удалён из таблицы бизнес-требований.
[Ревью] РЕШЕНО — можно удалить. Раздел «Модуль грузовых отчётов» удалён из таблицы бизнес-требований.
[Ревью] Критично (MVP): требование «Автоматическое создание ….» обрублено многоточием — не указано, что именно генерируется (предположительно Акт осмотра), в каком формате и по какому шаблону. Нужна точная формулировка, т.к. это влияет на модуль документооборота.
[Ревью] Решено, спасибо — обрубленная формулировка заменена на конкретное требование DEFINITIONINSP-BR-017 «Генерация Акта осмотра по шаблону с результатами проведенного осмотра».
[Ревью] РЕШЕНО — можно удалить. Обрубленная формулировка заменена на конкретное требование BR-017 «Генерация Акта осмотра по шаблону с результатами проведенного осмотра».
[Ревью] Критично (MVP): «Форма для ввода данных о заявке ()» — пустые скобки, перечень полей формы заявки отсутствует. Форма заявки — центральный UI/API объект системы, без списка полей невозможно проектировать модель данных и экраны.
добавила
[Ревью] Решено, спасибо — состав формы заявки теперь описан (данные Агента, Заказчика, судна, Исполнителя, планирование осмотра).
[Ревью] РЕШЕНО — можно удалить. Состав формы заявки описан (данные Агента, Заказчика, судна, Исполнителя, планирование осмотра).
[Ревью] Критично: нефункциональные требования сформулированы без измеримых метрик — «быстрая обработка», «регулярное резервное копирование», «оптимизация для больших объёмов данных», «шифрование данных пользователей». Нужны конкретные цифры и стандарты (например, время отклика в мс, RPO/RTO для бэкапов, объём данных для тестов производительности, алгоритм/стандарт шифрования), иначе требования непроверяемы.
Метрик в рамках MVP не будет
[Ревью] Не решено (принято как риск): подтверждаем, что измеримые метрики по НФТ (время отклика, RPO/RTO для бэкапов, объёмы данных, стандарт шифрования) сознательно не вводятся в рамках MVP. Фиксируем как осознанный риск для MVP — актуально для последующих релизов.
[Ревью] Пока актуально: измеримые метрики НФТ (время отклика, RPO/RTO, объёмы данных, стандарт шифрования) по-прежнему не заданы. Страница решений (id 73075569) этот пункт не затрагивает. Оставляем как принятый риск для MVP.
[Ревью] Критично (MVP): «Роли и выдача некоторых особых прав» — конкретные роли и права не перечислены. Нужна полная матрица доступа (роль × операция/сущность), иначе нельзя реализовать разграничение прав.
[Ревью] Уточнение внесено: детальная матрица доступа (роль × операция/сущность) по-прежнему не описана, но требование «Система ролей и прав доступа» теперь явно помечено «За рамками MVP» — для MVP вопрос закрываем, актуально для follow-up релиза.
[Ревью] РЕШЕНО — можно удалить. Требование «Система ролей и прав доступа» явно помечено «За рамками MVP», детальная матрица доступа переносится на follow-up релиз.
[Ревью] Желательно: требование двуязычности (RU/EN) не привязано явно к MVP или последующим релизам — нужно подтвердить объём у заказчика, т.к. полноценная i18n трудоёмка и может существенно повлиять на оценку.
необходима двуязычность в рамках MVP
[Ревью] Решено, спасибо — подтверждено, что двуязычность (RU/EN) необходима в рамках MVP.
[Ревью] РЕШЕНО — можно удалить. Подтверждено: двуязычность RU/EN необходима в рамках MVP.