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

5.1 Требования к производительности системы^💬

Идентификатор	Требование	Описание
INSP-NFR-001	Количество одновременно работающих пользователей	Система должна поддерживать одновременную работу не менее 100 активных пользователей.
INSP-NFR-002	Частота запросов от пользователя в минуту	Система должна обрабатывать не менее 5 запросов в минуту на одного пользователя при пиковой нагрузке. При 100 одновременных пользователях это даёт ~8,3 запр/сек суммарно на систему в среднем режиме.
INSP-NFR-003	Пропускная способность транзакций	MVP-целевая нагрузка: не менее 15 значимых бизнес-транзакций в секунду в пике (запас ×1,8 от расчётных 8,3/сек на рост числа пользователей/пиковые всплески (целевая нагрузка после масштабирования (не MVP-требование, а ориентир для архитектуры): до 50 тр/сек — использовать как параметр для нагрузочного тестирования на горизонт 2-3 года, не как жёсткое приёмочное условие MVP.
INSP-NFR-004	Время отклика для типовых операций	Система должна исполнять 80% типовых запросов за время не более 2 секунды; Система должна исполнять 95% типовых запросов за время не более 4 секунд.
INSP-NFR-005	Время отклика для сложных операций	Время формирования сложных отчетов (генерация акта по результатам осмотра) не должно превышать 30 секунд.^💬
INSP-NFR-006	Время отклика API	95% запросов к API должно обрабатываться менее чем за 1 секунду.^💬
INSP-NFR-044	Условия нагрузочного тестирования	Нагрузочное тестирование проводится профилем «ramp-up 10 мин → устойчивая нагрузка 30 мин → пиковый всплеск ×2 на 5 мин»; типовые операции — просмотр списка заявок, создание/изменение заявки, смена статуса, получение уведомлений; сложные операции — генерация акта осмотра, формирование выгрузки/отчёта реестра.

5.2 Требования к масштабируемости системы

Идентификатор	Требование	Описание
INSP-NFR-007	Горизонтальное масштабирование^💬	Архитектура системы должна позволять увеличение производительности за счет добавления серверов в кластер без изменения кода приложения.
INSP-NFR-008	Масштабируемость хранилищ	Система хранения данных должна быть способна хранить и эффективно обрабатывать не менее 300 ТБ данных о заявках и трекинге за годовой период^💬.
INSP-NFR-009	Развитие модулей	Система должна позволять добавление новых функциональных модулей (например, модуль аналитики, публикация заявок на поиск исполнителей) при дальнейшей доработке.
INSP-NFR-010	Интеграционная масштабируемость^💬	Система должна позволять внедрение дополнительных интеграций со сторонними сервисами/системами через стандартизированные API.

5.3 Требования к надежности системы

Идентификатор	Требование	Описание
INSP-NFR-011	Время восстановления после сбоя^💬	Система должна восстанавливаться после катастрофического сбоя (потеря инфраструктуры) не более чем за 4 часа при переключении на резервную инфраструктуру. Система должна восстанавливаться после сбоя критической тяжести (потерян доступ к одному из элементов инфраструктуры) не более чем за 15 минут. Система должна восстанавливаться после сбоя средней (падение БД) и ниже средней (падение сервиса) тяжести не более чем за 2 минуты.
INSP-NFR-012	Целевая точка восстановления	При сбое катастрофического уровня максимальная потеря данных не должна превышать 60^💬 минут (что соответствует частоте репликации на резервную площадку). При критическом сбое максимальная потеря данных не должна превышать 5 минут (периодичность синхронизации/бэкапа транзакций). При с^💬бое среднего и ниже среднего уровня максимальная потеря данных не должна превышать 1 минуты.^💬
INSP-NFR-014	Сохранность данных	Система должна производить регулярное автоматическое резервное копирование критических данных не реже одного раза в 24 часа. Полные бэкапы должны храниться не менее 90 дней изолированно от основной БД. Также система должна каждые 5 минут выполнять сохранение транзакций (WAL)^💬 обязательное регулярное тестовое восстановление из бэкапа — не реже 1 раза в квартал, с фиксацией результата; ^💬 ответственный за ротацию и контроль бэкапов — администратор/DevOps по регламенту эксплуатации; ^💬 хранилище бэкапов размещается в отдельном сетевом сегменте, недоступном напрямую из DMZ.^💬
INSP-NFR-041	Срок хранения данных	Все данные в системе должны храниться не менее трех лет до момента архивации или удаления
INSP-NFR-013	Устойчивость к сбоям	Система должна корректно обрабатывать сбои в работе внешних интеграций (API-сервисов), не допуская полной остановки своей работы.
INSP-NFR-045	Схема отказоустойчивости БД	БД разворачивается в конфигурации с синхронной репликацией на «горячий резерв» (standby) в пределах одной площадки для покрытия RTO 15 минут по критическим сбоям; для катастрофического сценария — асинхронная репликация на резервную площадку/ЦОД с интервалом синхронизации, соответствующим RPO 1 час.^💬

5.4 Требования к безопасности системы

Идентификатор	Требование	Описание
INSP-NFR-015	Конфиденциальность данных	По требования 152-ФЗ^💬 все конфиденциальные данные (персональные данные, коммерческая тайна)^💬 должны храниться и передаваться в зашифрованном виде с использованием современных алгоритмов шифрования (не слабее AES-256^💬). Класс информационной системы персональных данных — ИСПДн УЗ-3 (типовая ИС для оператора, не гос.орган, данные не специальной категории); меры защиты — по Приказу ФСТЭК №21 (для ИСПДн) и, при обработке гостайны/критической инфраструктуры, дополнительно по требованиям ФСБ. Требование резидентности: персональные данные граждан РФ обрабатываются и хранятся на территории РФ (ст. 18 152-ФЗ) — при локальном размещении у Заказчика выполняется по умолчанию.
INSP-NFR-016	Аутентификация	Доступ к системе должен осуществляться по логину и надежному паролю (требования^💬: мин. 8 символов, заглавные/строчные буквы, цифры INSP-AT-USR-009). Должна быть реализована защита от перебора паролей (заморозка после 5 неудачных попыток^💬). Двухфакторная авторизация - за рамками MVP.
INSP-NFR-017	Авторизация и RBAC	Система должна обладать гибкими настройками разграничения прав доступа на основе ролей (Role-Based Access Control - RBAC).
INSP-NFR-018	Аудит и логирование	Все значимые действия пользователей (вход, изменение данных, удаление записей) должны протоколироваться в защищенном журнале аудита с возможностью просмотра отчета не менее 90 дней^💬. Журнал аудита должен быть защищён от изменения/удаления (WORM/append-only) — записи нельзя редактировать или удалять до истечения срока хранения, включая привилегированных пользователей (кроме выгрузки/архивации по регламенту).
INSP-NFR-019	Защита от веб-угроз	Система должна быть защищена от распространенных веб-угроз (OWASP Top 10), таких как SQL-инъекции, XSS, CSRF.
INSP-NFR-020	Резервное копирование и целостность	Резервные копии данных также должны быть зашифрованы.
INSP-NFR-046	TLS	Все внешние и межзонные соединения — TLS 1.2 как минимум, предпочтительно TLS 1.3; TLS 1.0/1.1 запрещены; сертификаты — не самоподписанные для внешнего периметра.

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

Идентификатор	Требование	Описание
INSP-NFR-021	Общая доступность	Уровень доступности системы для конечных пользователей должен составлять не менее 99.9% в расчете на месяц/год.
INSP-NFR-022	Допустимый простой	Для обеспечения доступности 99.9% допустимое время простая: - В месяц: не более 43.8 минут - В квартал: не более 2 часов 11 минут - В год: не более 8 часов 46 минут
INSP-NFR-023	Плановое техническое обслуживание	Работы по плановому техническому обслуживанию не должны превышать 4 часов в месяц, включенных в расчет простоя^💬 и должны проводиться в нерабочее время^💬 (например, в ночь с субботы на воскресенье).

Идентификатор

Требование

Описание

INSP-NFR-021

Общая доступность

Уровень доступности системы для конечных пользователей должен составлять не менее 99.9% в расчете на месяц/год.

INSP-NFR-022

Допустимый простой

Для обеспечения доступности 99.9% допустимое время простая:

- В месяц: не более 43.8 минут
- В квартал: не более 2 часов 11 минут
- В год: не более 8 часов 46 минут

INSP-NFR-023

Плановое техническое обслуживание

Работы по плановому техническому обслуживанию не должны превышать 4 часов в месяц, включенных в расчет простоя^💬 и должны проводиться в нерабочее время^💬 (например, в ночь с субботы на воскресенье).

5.6 Требования к атрибутам качества использования системы

Идентификатор	Требование	Описание
INSP-NFR-024	Результативность	Средняя доля успешных завершений сценариев необученным пользователем должна быть не менее 80%
INSP-NFR-025	Простота освоения	Для начала работы с системой пользователям не должны требоваться специализированные навыки работы с ПК, кроме умения пользоваться веб-браузером.
INSP-NFR-026	Скорость обучения	Средняя длительность обучения, необходимая для доведения результативности выполнения сценариев пользователем до 95% не должна превышать 1 часа.
INSP-NFR-027	Эффективность работы пользователя	Среднее время выполнения учетных сценариев (создание заявки) обученным пользователем не должно превышать 7 мин в 80% случаев. Среднее время выполнения сложных сценариев (завершение осмотра) обученным пользователем не должно превышать 15 мин в 80% случаев. Среднее время выполнения поисковых сценариев обученным пользователем не должно превышать 1 мин в 80% случаев.
INSP-NFR-028	Точность	Средняя доля ошибок, совершаемых обученным пользователем в течение первых 15 минут нового сеанса работы не должна превышать 5%;
INSP-NFR-029	Эргономичность	Среднее время непрерывной работы обученного пользователя, после которой число ошибок возрастает более, чем на 20%, не должно быть менее 45 мин.
INSP-NFR-030	Удовлетворенность	Средняя оценка пользователями удобства системы по 5-балльной шкале после месяца эксплуатации должна быть не менее 4.0, на основе обратной связи конечных пользователей.
INSP-NFR-031	Кросс-платформенность и кросc-браузерность	Веб-интерфейс должен корректно отображаться и функционировать в последних (последняя стабильная версия и две предыдущие версии) версиях^💬 популярных браузеров: Google Chrome, Mozilla Firefox, Microsoft Edge, Apple Safari, Яндекс.Браузер.
INSP-NFR-032	Адаптивный интерфейс	Интерфейс системы должен быть адаптивным для комфортного использования на устройствах с шириной экрана от ^💬380^💬px^💬 (мобильные телефоны) до 1920px и более (мониторы). Нативные мобильные приложения - за рамками MVP.
INSP-NFR-033	Язык интерфейса	Пользовательский интерфейс системы, включая все элементы меню, кнопки, сообщения, формы, справочную систему и документацию для пользователя, должен быть на русском языке и английском языках с возможностью изменения^💬. Формат даты и времени — dd.mm.yyyy hh:mm / дд.мм.гггг чч:мм (рус); формат чисел — разделитель разрядов пробел, числовая локализация не требуется, десятичный разделитель - точка.
INSP-NFR-034	Контекстная помощь и подсказки	Система должна предоставлять контекстные подсказки и инструкции непосредственно в интерфейсе на всех этапах выполнения сценариев (например, при создании заявки на осмотр). Должны быть реализованы: всплывающие подсказки (tooltips), примеры заполнения полей, валидация вводимых данных в реальном времени с понятными сообщениями об ошибках.
INSP-NFR-035	Самостоятельность работы	Интерфейс системы должен быть спроектирован таким образом, чтобы пользователь мог выполнять типовые операции без постоянного обращения к инструкции по эксплуатации. Для сложных операций должна быть предусмотрена контекстная справочная система, доступная непосредственно из интерфейса соответствующего модуля.
INSP-NFR-047	Доступность (accessibility)	Для MVP — базовые практики (клавиатурная навигация по формам, контрастность текста не ниже 4.5:1, читаемые alt-тексты для иконок); полное соответствие WCAG 2.1 уровня AA — После MVP, как отдельная работа.

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

Идентификатор	Требование	Описание
INSP-NFR-036	Поставляемые артефакты	Поставка программной системы должна включать: 1. Исходный код всей системы; 2. Исполняемые файлы/контейнеры; 3. Скрипты для развертывания и миграции БД; 4. Конфигурационные файлы; 5. Полный комплект документации.
INSP-NFR-037	Техническая документация	Комплект документации к программной системе должен включать: Руководство администратора по развёртыванию, обновлению и обслуживанию системы; Руководство пользователя по использованию системы; Документ архитектуры системы согласно ГОСТ Р 57100-2016 «Системная и программная инженерия. Описание архитектуры»;
INSP-NFR-038	Лицензирование и патентное чистота	Все права на вновь созданный исходный код принадлежат Заказчику; Разработчик не имеет права распространения кода в любых целях без согласования с Заказчиком; Допускается использование готовых компонентов, распространяемых по лицензии Apache License 2.0, MIT License, BSD License (v2, v3), ISC License, LGPL v2.1, v3.0, GPL; При разработке системы запрещено использование нелицензионных компонентов.

Идентификатор

Требование

Описание

INSP-NFR-036

Поставляемые артефакты

Поставка программной системы должна включать:
1. Исходный код всей системы;
2. Исполняемые файлы/контейнеры;
3. Скрипты для развертывания и миграции БД;
4. Конфигурационные файлы;
5. Полный комплект документации.

INSP-NFR-037

Техническая документация

Комплект документации к программной системе должен включать:

Руководство администратора по развёртыванию, обновлению и обслуживанию системы;
Руководство пользователя по использованию системы;
Документ архитектуры системы согласно ГОСТ Р 57100-2016 «Системная и программная инженерия. Описание архитектуры»;

INSP-NFR-038

Лицензирование и патентное чистота

Все права на вновь созданный исходный код принадлежат Заказчику;
Разработчик не имеет права распространения кода в любых целях без согласования с Заказчиком;
Допускается использование готовых компонентов, распространяемых по лицензии Apache License 2.0, MIT License, BSD License (v2, v3), ISC License, LGPL v2.1, v3.0, GPL;
При разработке системы запрещено использование нелицензионных компонентов.

5.8 Ограничения системы^💬

Идентификатор	Требование	Описание
INSP-NFR-039	Технологический стек	Фронтенд-часть системы должна быть реализована как веб-приложение, работающее в современных браузерах. Бэкенд-часть должна быть реализована с использованием технологий: JavaScript, Node.js, Python
INSP-NFR-040	Архитектурные ограничения	Система должна быть реализована по микросервисной, модульной монолитной или гибридной архитектуре^💬.
INSP-NFR-042	Ограничения инфраструктуры	Программный комплекс размещается локально у заказчика. Элементы системы размещаются в двух зонах сетевой доступности. Клиентское приложение и API сервисы размещаются в первой зоне - выделенном DMZ сегменте. База данных размещается во второй - внутренней зоне доступности. Коммуникация между зонами защищена межсетевым экраном.

Идентификатор

Требование

Описание

INSP-NFR-039

Технологический стек

Фронтенд-часть системы должна быть реализована как веб-приложение, работающее в современных браузерах.

Бэкенд-часть должна быть реализована с использованием технологий: JavaScript, Node.js, Python

INSP-NFR-040

Архитектурные ограничения

Система должна быть реализована по микросервисной, модульной монолитной или гибридной архитектуре^💬.

INSP-NFR-042

Ограничения инфраструктуры

Программный комплекс размещается локально у заказчика. Элементы системы размещаются в двух зонах сетевой доступности. Клиентское приложение и API сервисы размещаются в первой зоне - выделенном DMZ сегменте. База данных размещается во второй - внутренней зоне доступности. Коммуникация между зонами защищена межсетевым экраном.

5.9 Мониторинг и наблюдаемость (Monitoring & Observability)

Идентификатор	Требование	Описание
INSP-NFR-048	Мониторинг доступности	Система должна предоставлять метрики доступности и производительности (uptime, время отклика, коды ошибок) в реальном времени; интеграция с системой мониторинга (например, Zabbix/Prometheus+Grafana).
INSP-NFR-049	Алертинг	При деградации сервиса (рост времени отклика выше порога, недоступность компонентов) должны генерироваться автоматические оповещения ответственным инженерам.
INSP-NFR-050	Централизованное логирование	Логи приложения и инфраструктуры должны агрегироваться в едином хранилище с возможностью поиска и хранением не менее срока хранения аудит-лога (90 дней), для расследования инцидентов.

Комментарии (102) · по состоянию на 2026-09-18

К фрагментам текста

claude-code · 2026-09-15 09:15 МСК · фрагмент удалён · к фрагменту · 73074890

«не менее 50 значимых бизнес-транзакций в секунду»

[Ревью] Критично: 100 пользователей × 5 запросов/мин ≈ 8,3 rps, но требование гласит «не менее 50 бизнес-транзакций/сек» — это в ~6 раз больше суммарного расчётного трафика. Цифры противоречат друг другу, нужно пересчитать и согласовать.

claude-code · 2026-09-15 13:40 МСК · 73075439

[Ревью] Пока актуально: цифры всё ещё расходятся — «не менее 50 бизнес-транзакций/сек» против расчётных ~8,3 rps (100 польз. × 5 запросов/мин). Нужно пересчитать/согласовать.

claude-code · 2026-09-16 08:46 МСК · 73075687

[Ревью] Пока актуально: противоречие не устранено — «не менее 50 значимых бизнес-транзакций в секунду» всё ещё в ~6 раз превышает расчётные ~8,3 rps (100 польз. × 5 запросов/мин). Нужно пересчитать/согласовать цифры.

claude-code · 2026-09-16 10:18 МСК · 73075860

[Ревью] РЕШЕНО — можно удалить: NFR-003 переписан — MVP-цель явно 15 тр/сек (запас ×1,8 от расчётных 8,3/сек), а 50 тр/сек обозначено как ориентир после масштабирования, не приёмочный критерий MVP — противоречие снято.

claude-code · 2026-09-15 09:15 МСК · решён · к фрагменту · 73074893

«5.1 Требования к производительности системы»

[Ревью] Желательно: Не указаны условия нагрузочного тестирования (конфигурация окружения, сеть, размер БД) — без baseline нельзя объективно проверить SLA по времени отклика.

claude-code · 2026-09-15 13:40 МСК · 73075442

[Ревью] Пока актуально: условия нагрузочного тестирования (окружение, сеть, размер БД) в разделе 5.1 так и не описаны.

claude-code · 2026-09-16 08:46 МСК · 73075692

[Ревью] Пока актуально: условия нагрузочного тестирования (окружение, сеть, размер БД) в разделе 5.1 по-прежнему не описаны.

claude-code · 2026-09-16 10:18 МСК · 73075862

[Ревью] РЕШЕНО — можно удалить: добавлена строка NFR-044 «Условия нагрузочного тестирования» с профилем нагрузки (ramp-up/устойчивая/пик).

claude-code · 2026-09-15 09:15 МСК · решён · к фрагменту · 73074897

«Время формирования сложных отчетов и аналитических выборок не должно превышать 30 секунд.»

[Ревью] Критично: Нет перечня конкретных операций, попадающих в категории «типовые» (2–4 сек) и «сложные» (до 30 сек) — без этого агент/разработчик не поймёт, к каким эндпоинтам применять какой SLA.

claude-code · 2026-09-15 13:40 МСК · 73075444

[Ревью] Пока актуально: перечень конкретных «типовых» и «сложных» операций всё ещё не приведён.

claude-code · 2026-09-16 08:46 МСК · 73075693

[Ревью] Уточнение внесено частично: для «сложных операций» добавлен конкретный пример (генерация акта по результатам осмотра), но исчерпывающего перечня операций, попадающих в категории «типовые» и «сложные», всё ещё нет.

claude-code · 2026-09-16 10:19 МСК · 73075863

[Ревью] РЕШЕНО — можно удалить: NFR-044 теперь перечисляет конкретные типовые и сложные операции для нагрузочного тестирования.

claude-code · 2026-09-15 09:15 МСК · решён · к фрагменту · 73074901

«не менее 5 ТБ данных о заявках и трекинге за годовой период»

[Ревью] Критично: «5 ТБ данных за годовой период» указано без срока хранения в «горячем» доступе и без политики архивации — без этого нельзя спроектировать партиционирование БД.

claude-code · 2026-09-15 13:40 МСК · 73075445

[Ревью] Пока актуально: срок хранения в горячем доступе и политика архивации для 5 ТБ данных не указаны.

claude-code · 2026-09-16 08:46 МСК · 73075694

[Ревью] Пока актуально: объём данных изменён (теперь 300 ТБ/год), но срок хранения в «горячем» доступе и политика архивации по-прежнему не указаны.

claude-code · 2026-09-15 09:15 МСК · решён · к фрагменту · 73074907

«восстанавливаться после сбоя средней тяжести не более чем за 5 минут»

[Ревью] Критично: RTO=5 мин указан только для «сбоя средней тяжести»; нет классификации сбоев (лёгкий/средний/критический/катастрофический) с RTO/RPO для каждой категории.

claude-code · 2026-09-15 13:40 МСК · 73075446

[Ревью] Пока актуально: классификация сбоев (лёгкий/средний/критический/катастрофический) с RTO/RPO по категориям так и не добавлена.

claude-code · 2026-09-16 08:47 МСК · 73075695

[Ревью] Уточнение внесено частично: RTO теперь дифференцирован по трём категориям тяжести сбоя (критический/средний/ниже среднего). Однако RPO (NFR-012) остаётся единым значением (5 минут) без привязки к категориям сбоя, а категория «катастрофический сбой» отсутствует.

claude-code · 2026-09-16 10:19 МСК · 73075866

[Ревью] РЕШЕНО — можно удалить: NFR-011 дополнена категорией «катастрофический сбой» (RTO 4ч), NFR-012 теперь содержит RPO по каждой категории (60/5/15 мин) — классификация завершена.

claude-code · 2026-09-15 09:15 МСК · решён · к фрагменту · 73074927

«Полные бэкапы должны храниться не менее 90 дней.»

[Ревью] Желательно: Не указано место/способ хранения бэкапов, требования к тестированию восстановления, ответственный за ротацию.

claude-code · 2026-09-15 13:40 МСК · 73075447

[Ревью] Пока актуально: место/способ хранения бэкапов, требования к тестированию восстановления и ответственный за ротацию не указаны.

claude-code · 2026-09-16 08:47 МСК · 73075696

[Ревью] Уточнение внесено частично: добавлено «изолированно от основной БД» (место хранения частично уточнено), но требования к тестированию восстановления и ответственный за ротацию бэкапов всё ещё не указаны.

claude-code · 2026-09-16 10:19 МСК · 73075867

[Ревью] РЕШЕНО — можно удалить: NFR-014 дополнена требованиями к тестовому восстановлению (ежеквартально), ответственному за ротацию (админ/DevOps) и изоляции хранилища бэкапов от DMZ.

claude-code · 2026-09-15 09:15 МСК · решён · к фрагменту · 73074933

«конфиденциальные данные (персональные данные, коммерческая тайна)»

[Ревью] Критично: Упомянуты «персональные данные», но нет явной ссылки на 152-ФЗ, приказы ФСТЭК/ФСБ, класс ИСПДн, требование хранения ПДн на территории РФ.

claude-code · 2026-09-15 13:40 МСК · 73075450

[Ревью] Пока актуально: ссылка на 152-ФЗ/ФСТЭК, класс ИСПДн и требование хранения ПДн на территории РФ отсутствуют.

claude-code · 2026-09-16 08:47 МСК · 73075697

[Ревью] Уточнение внесено частично: ссылка на 152-ФЗ добавлена. Но класс ИСПДн, приказы ФСТЭК/ФСБ и требование хранения ПДн на территории РФ по-прежнему не упомянуты.

claude-code · 2026-09-16 10:19 МСК · 73075868

[Ревью] РЕШЕНО — можно удалить: NFR-015 дополнена классом ИСПДн УЗ-3, ссылкой на Приказ ФСТЭК №21/ФСБ и требованием резидентности ПДн на территории РФ (ст. 18 152-ФЗ).

claude-code · 2026-09-15 09:15 МСК · решён · к фрагменту · 73074939

«блокировка после 5 неудачных попыток»

[Ревью] Желательно: Не упомянута многофакторная аутентификация (MFA), хотя описаны требования к паролям/блокировке.

claude-code · 2026-09-15 13:40 МСК · 73075452

[Ревью] Пока актуально: требование по MFA не добавлено.

claude-code · 2026-09-16 08:47 МСК · 73075699

[Ревью] Решено, спасибо — добавлена явная формулировка «Двухфакторная авторизация - за рамками MVP», что снимает неопределённость (согласуется со страницей решений по MVP, где 2FA также вынесена «После MVP»).

claude-code · 2026-09-16 10:19 МСК · 73075869

[Ревью] РЕШЕНО — можно удалить: MFA явно выведена за рамки MVP (NFR-016), согласовано с решением по MVP.

claude-code · 2026-09-15 09:15 МСК · решён · к фрагменту · 73074943

«журнале аудита с возможностью просмотра отчета»

[Ревью] Желательно: Не указан срок хранения журнала аудита и требования к его неизменяемости (WORM).

claude-code · 2026-09-15 13:40 МСК · 73075453

[Ревью] Пока актуально: срок хранения журнала аудита и требование неизменяемости (WORM) не указаны.

claude-code · 2026-09-16 08:47 МСК · 73075700

[Ревью] Уточнение внесено частично: срок хранения журнала аудита (90 дней) теперь указан. Требование неизменяемости (WORM) по-прежнему отсутствует.

claude-code · 2026-09-16 10:19 МСК · 73075870

[Ревью] РЕШЕНО — можно удалить: NFR-018 дополнена требованием WORM/append-only для журнала аудита.

claude-code · 2026-09-15 09:15 МСК · решён · к фрагменту · 73074949

«не слабее AES-256»

[Ревью] Желательно: Указано шифрование AES-256, но не указана минимальная версия TLS и требования к сертификатам.

claude-code · 2026-09-15 13:40 МСК · 73075454

[Ревью] Пока актуально: минимальная версия TLS и требования к сертификатам не указаны.

claude-code · 2026-09-16 08:47 МСК · 73075701

[Ревью] Пока актуально: минимальная версия TLS и требования к сертификатам всё ещё не указаны.

claude-code · 2026-09-16 10:19 МСК · 73075871

[Ревью] РЕШЕНО — можно удалить: добавлена строка NFR-046 с минимальной версией TLS 1.2 (запрет 1.0/1.1) и требованиями к сертификатам.

claude-code · 2026-09-15 09:15 МСК · решён · к фрагменту · 73074968

«Работы по плановому техническому обслуживанию не должны превышать 4 часов в месяц»

[Ревью] Критично: Не указано явно, включается ли плановое ТО (до 4 ч/мес) в расчёт простоя 99.9% или является исключением из него.

claude-code · 2026-09-15 13:40 МСК · 73075456

[Ревью] Пока актуально: не уточнено, входит ли плановое ТО в расчёт простоя 99.9% или является исключением.

claude-code · 2026-09-16 08:47 МСК · 73075702

[Ревью] Решено, спасибо — явно добавлено «включенных в расчет простоя», т.е. плановое ТО учитывается в расчёте доступности 99.9%.

claude-code · 2026-09-16 10:19 МСК · 73075872

[Ревью] РЕШЕНО — можно удалить: явно указано «включенных в расчет простоя» — плановое ТО учитывается в SLA 99.9%.

claude-code · 2026-09-15 09:15 МСК · решён · к фрагменту · 73074976

«на русском языке и английском языках с возможностью изменения»

[Ревью] Желательно: «Русский и английский с возможностью изменения», но не указаны форматы дат/чисел/валют, язык уведомлений, язык по умолчанию.

claude-code · 2026-09-15 13:40 МСК · 73075459

[Ревью] Пока актуально: форматы дат/чисел/валют и язык по умолчанию всё ещё не описаны.

claude-code · 2026-09-16 08:47 МСК · 73075703

[Ревью] Уточнение внесено частично: на странице «Список допущений/решений принятых для реализации MVP» (id 73075569) зафиксировано решение по формату даты/времени (dd.mm.yyyy hh:mm) и двуязычности интерфейса. Однако в тексте самой страницы 5 НФР (раздел 5.6, NFR-033) это решение пока не отражено — форматы дат/чисел/валют и язык по умолчанию там всё ещё не описаны. Рекомендуем перенести/сослаться на решение в этом разделе.

claude-code · 2026-09-16 10:19 МСК · 73075873

[Ревью] Уточнение внесено частично: NFR-033 дополнена форматами даты/времени и чисел, но язык по умолчанию и язык уведомлений всё ещё не описаны.

claude-code · 2026-09-15 09:15 МСК · фрагмент удалён · к фрагменту · 73074981

«Внешние интеграции»

[Ревью] Критично: Строка «Внешние интеграции» в таблице ограничений (раздел 5.7 «Ограничения системы») — идентификатор и описание полностью пустые, требование по сути отсутствует.

claude-code · 2026-09-15 13:40 МСК · 73075433

[Ревью] Решено, спасибо — пустая строка «Внешние интеграции» удалена из таблицы ограничений.

claude-code · 2026-09-16 08:47 МСК · 73075704

[Ревью] Подтверждаем: пустая строка «Внешние интеграции» по-прежнему отсутствует в таблице — решено.

claude-code · 2026-09-16 10:19 МСК · 73075874

[Ревью] РЕШЕНО — можно удалить: пустая строка «Внешние интеграции» отсутствует в текущей версии таблицы ограничений.

claude-code · 2026-09-15 09:15 МСК · решён · к фрагменту · 73074986

«5.7 Ограничения системы»

[Ревью] Желательно: Дублирование номера раздела «5.7» — есть два разных раздела («5.7 Требования к составу поставки» и «5.7 Ограничения системы») с одним номером, нарушает сквозную нумерацию.

claude-code · 2026-09-15 13:40 МСК · 73075435

[Ревью] Решено, спасибо — разделы теперь имеют разные номера (5.7 «Требования к составу поставки» и 5.8 «Ограничения системы»).

claude-code · 2026-09-16 08:48 МСК · 73075706

[Ревью] Подтверждаем: нумерация разделов 5.7/5.8 корректна — решено.

claude-code · 2026-09-16 08:48 МСК · 73075719

[Ревью] Подтверждаем: нумерация разделов 5.7/5.8 корректна — решено.

claude-code · 2026-09-16 10:19 МСК · 73075875

[Ревью] РЕШЕНО — можно удалить: разделы имеют разные номера (5.7 и 5.8), дублирование устранено.

claude-code · 2026-09-15 09:15 МСК · решён · к фрагменту · 73074992

«Горизонтальное масштабирование»

[Ревью] Критично: Упомянуто горизонтальное масштабирование приложения, но не указана схема отказоустойчивости самой БД (репликация/кластер) — см. также раздел «Ограничения инфраструктуры», где БД размещена в единственной внутренней зоне без упоминания резервирования.

claude-code · 2026-09-15 13:40 МСК · 73075461

[Ревью] Пока актуально: схема отказоустойчивости БД (репликация/кластер) не добавлена, БД по-прежнему в единственной внутренней зоне.

claude-code · 2026-09-16 08:48 МСК · 73075708

[Ревью] Пока актуально: схема отказоустойчивости БД (репликация/кластер) не добавлена, БД по-прежнему в единственной внутренней зоне без резервирования.

claude-code · 2026-09-16 10:19 МСК · 73075876

[Ревью] РЕШЕНО — можно удалить: добавлена строка NFR-045 со схемой отказоустойчивости БД (синхронная репликация на standby + асинхронная на резервную площадку).

claude-code · 2026-09-15 09:15 МСК · решён · к фрагменту · 73074998

«с шириной экрана от 380px»

[Ревью] Желательно: Не сказано явно, что нативных мобильных приложений не будет (указано только «веб, адаптивно от 380px») — стоит зафиксировать явно, чтобы устранить риск разного понимания.

claude-code · 2026-09-15 13:40 МСК · 73075463

[Ревью] Пока актуально: явного указания на отсутствие нативных мобильных приложений так и не добавлено.

claude-code · 2026-09-16 08:48 МСК · 73075710

[Ревью] Решено, спасибо — добавлена явная формулировка «Нативные мобильные приложения - за рамками MVP».

claude-code · 2026-09-16 10:19 МСК · 73075877

[Ревью] РЕШЕНО — можно удалить: NFR-032 явно фиксирует «Нативные мобильные приложения - за рамками MVP».

Кирилл Левчук · 2026-09-16 11:31 МСК · открыт · к фрагменту · 73075895

«При сбое ниже среднего максимальная потеря данных не должна превышать 15 минут.»

Почему тут 15 минут, если мы делаем бэкап каждые 5 минут

Георгий Павленко · 2026-09-16 12:05 МСК · 73075901

Здесь получается около 0 потеря

Роман Износов · 2026-09-16 15:04 МСК · 73075914

В блоке ниже написано “не реже одного раза в 24 часа”. Просто если вдруг мы всё-таки будем делать бекапы раз в 24 часа по какой-ли причине (например проблемы с инфрой) - мы не сможем реализовать потерю данных < 15 минут

Софья Герасимова · 2026-09-17 11:46 МСК · 73075973

Полный бэкап - раз в сутки

В течении дня раз в 5 минут сохранение WAL

Роман Износов · 2026-09-16 14:58 МСК · открыт · к фрагменту · 73075910

«95% запросов к API должно обрабатываться менее чем за 1 секунду.»

А в чем принципиальное различие от “Частоты запросов от пользователя в минуту”?
Также мне непонятен алгоритм сбора метрик. 95% должны выполняться последовательно или параллельно? Если запросы выполняются в одном потоке и в нескольких, то время выполнения может сильно различаться.

Роман Износов · 2026-09-16 15:00 МСК · открыт · к фрагменту · 73075912

«Время восстановления после сбоя»

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

Софья Герасимова · 2026-09-17 11:42 МСК · 73075968

ниже среднего - упал сервис, потеря около 0
средний сбой - упала БД, потеря около 0
критический сбой - потеряли доступ к одному из сервисов или БД (любой элемент инфраструктуры), восстанавливается из бэкапа + WAL (Запись транзакций) каждый день делаем бэкап не более 5 минут потеря

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

Софья Герасимова · 2026-09-17 11:44 МСК · 73075969

средняя, нижнаяя - само поднимится
критическая - 15

катастрофа - не можем гарантировать, тк не знаем инфраструктуру РМП

Роман Износов · 2026-09-16 15:08 МСК · открыт · к фрагменту · 73075917

«152-ФЗ»

Я не очень в этом разбираюсь, могу ошибаться. Для бизнеса вроде нужно письменное или электронное согласие, оно где и как будет производиться?

Софья Герасимова · 2026-09-17 11:52 МСК · 73075976

При первом входе, пока не нажмешь, должна висеть - lдобавлять ли в MVP?

Спросить у юристов у Зеленина

Роман Износов · 2026-09-16 15:09 МСК · фрагмент удалён · к фрагменту · 73075919

«блокировка»

на время или перманентно?

Софья Герасимова · 2026-09-17 11:53 МСК · 73075978

Заморозка

Роман Износов · 2026-09-16 15:09 МСК · решён · к фрагменту · 73075921

«требования»

А спецсимволы?

Софья Герасимова · 2026-09-17 04:27 МСК · 73075932

В словаре данных там подробнее все требования к паролю описаны, тут по верхам

Софья Герасимова · 2026-09-17 11:52 МСК · 73075977

ссылка на атрибут

Роман Износов · 2026-09-16 15:12 МСК · фрагмент удалён · к фрагменту · 73075923

«неактивности»

Мне не хватает более подробного описания, что является “Неактивностью”. Например кейсы являются неактивностью?
1) Пользователь сидит в системе и просматривает список заявок без отправки со своей стороны новых реквестов (Просто двигет мышкой на вкладке)
2) Пользователь переходит по разделам, смотрит заявки, но не создаёт/не вносит ничего нового

Софья Герасимова · 2026-09-17 04:28 МСК · 73075933

Тут будто бы все-таки про то, что вообще нет никакой активности, ни переходов, ни просмотров. Открыто во вкладке фоновой

Роман Износов · 2026-09-16 15:16 МСК · открыт · к фрагменту · 73075925

«и должны проводиться в нерабочее время»

Нет требования для предварительного уведомления о работах? Насколько я знаю порты работают 24/7 без выходных. Как будто бы адекватно будет предупредить юзеров заранее, что система не будет работать в определённое время.

Софья Герасимова · 2026-09-17 11:56 МСК · 73075981

пока нет

Роман Износов · 2026-09-16 15:21 МСК · решён · к фрагменту · 73075927

«последних версиях»

Как будто бы слишком жёсткое ограничение. Может быть сделаем что-то вроде
последняя стабильная версия и две предыдущие

Софья Герасимова · 2026-09-17 11:37 МСК · фрагмент удалён · к фрагменту · 73075964

«базы данных»

хранилища

Софья Герасимова · 2026-09-17 11:38 МСК · открыт · к фрагменту · 73075966

«масштабируемость»

добавить про планы на будущее

Софья Герасимова · 2026-09-17 11:45 МСК · открыт · к фрагменту · 73075970

«60»

частота сохранения и отсылки бэкапов на внешний ЦОД

Софья Герасимова · 2026-09-17 11:48 МСК · открыт · к фрагменту · 73075974

«для катастрофического сценария — асинхронная репликация на резервную площадку/ЦОД с интервалом синхронизации, соответствующим RPO 1 час.»

все зависит от инфраструктуры РМП. Если оставим для нас - то делать точно не будем для себя

Софья Герасимова · 2026-09-17 11:54 МСК · фрагмент удалён · к фрагменту · 73075979

«Таймаут сессии»

Убрать

Софья Герасимова · 2026-09-17 11:58 МСК · решён · к фрагменту · 73075982

«(например, Java/Spring или Python/Django).»

JavaScript, Node.js, python

Софья Герасимова · 2026-09-17 11:59 МСК · решён · к фрагменту · 73075984

«архитектуре»

гибрид

К странице

claude-code · 2026-09-15 09:15 МСК · открыт · 73075017

[Ревью] Критично (относится ко всем таблицам разделов 5.1–5.7): Во всех таблицах разделов 5.1–5.7 колонка «Идентификатор» (согласно схеме INSP-NFR-XXX из раздела 1.2) пустая — без ID невозможна трассировка требований между документами, тест-кейсами и кодом.

Софья Герасимова · 2026-09-15 13:31 МСК · 73075401

добавила

claude-code · 2026-09-15 13:40 МСК · 73075438

[Ревью] Уточнение внесено, но остался вопрос: идентификаторы добавлены во все таблицы — это решает проблему трассировки. Но в экспорте страницы они отображаются с лишним префиксом «DEFINITIONINSP-NFR-XXX» вместо «INSP-NFR-XXX» — похоже на не до конца отработавший макрос/переменную. Пожалуйста, проверьте, что на самой странице (не в экспорте) ID отображаются корректно.

claude-code · 2026-09-15 09:15 МСК · открыт · 73075019

[Ревью] Критично (раздел 5.4 «Требования к безопасности системы», строка «Аутентификация»): Не указано время неактивности, после которого сессия пользователя должна завершаться (session timeout). Нужно явно зафиксировать таймаут неактивной сессии.

claude-code · 2026-09-15 13:40 МСК · 73075464

[Ревью] Пока актуально: таймаут неактивной сессии не зафиксирован.

claude-code · 2026-09-15 09:15 МСК · открыт · 73075021

[Ревью] Критично (общее, отсутствует как отдельный раздел): Полностью отсутствует раздел требований к мониторингу/observability (APM, метрики, алерты) — в документе описан только аудит действий пользователей. Это критично при заявленном SLA доступности 99.9% (раздел 5.5), поскольку без мониторинга невозможно отследить и оперативно среагировать на деградацию сервиса.

claude-code · 2026-09-15 13:40 МСК · 73075466

[Ревью] Пока актуально: раздел требований к мониторингу/observability по-прежнему отсутствует, хотя заявлен SLA 99.9%.

claude-code · 2026-09-15 09:15 МСК · открыт · 73075022

[Ревью] Желательно (общее, отсутствует как отдельный раздел): Полностью отсутствуют требования доступности для людей с ограниченными возможностями (WCAG 2.1 AA), хотя пользователи системы включают представителей госорганов (порты) — это может быть законодательным требованием и стоит уточнить у заказчика.

claude-code · 2026-09-15 13:40 МСК · 73075469

[Ревью] Пока актуально: требования доступности WCAG 2.1 AA не добавлены.

claude-code · 2026-09-15 09:15 МСК · открыт · 73075024

[Ревью] Желательно (раздел 5.7 «Ограничения системы», строка «Ограничения инфраструктуры»): БД размещена во «внутренней зоне», но не описано, как физически передаются/хранятся резервные копии с учётом сегментации сети (DMZ/внутренняя зона, межсетевой экран) — нужно уточнить процесс и место хранения бэкапов относительно этих зон.

claude-code · 2026-09-15 13:40 МСК · 73075471

[Ревью] Пока актуально: процесс и место хранения бэкапов с учётом сетевой сегментации (DMZ/внутренняя зона) не описаны.

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

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

5.2 Требования к масштабируемости системы

5.3 Требования к надежности системы

5.4 Требования к безопасности системы

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

5.6 Требования к атрибутам качества использования системы

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

5.8 Ограничения системы💬

5.9 Мониторинг и наблюдаемость (Monitoring & Observability)

Комментарии (102) · по состоянию на 2026-09-18

К фрагментам текста

К странице

5.1 Требования к производительности системы^💬

5.8 Ограничения системы^💬