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

ID	Название	Категория	Описание требования	Приоритет (MoSCoW)	Обоснование
NFR-01	Время отклика при поиске	Производительность	Время загрузки страницы с результатами поиска (UC-002) при применении фильтров не должно превышать 2 секунд	Must Have	Для нашего продукта быстрый поиск — критическое конкурентное преимущество.
NFR-02	Скорость подтверждения брони	Производительность	Операция бронирования должна выполняться не более чем за 1,5 секунды. В случае недоступности внешней системы таймаут должен наступать через 3 секунды.	Must Have	Пользователь ожидает мгновенного подтверждения, как при покупке билетов в кино. Долгая обработка может привести к повторным попыткам и задвоению броней.
NFR-03	Доступность сервиса	Надёжность	Уровень доступности (uptime) веб-приложения должен составлять не менее 99,5% в месяц (допустимо не более 3,5 часов простоя).	Must Have	Пользователь ожидает доступности приложения в любое для него удобное время.
NFR-04	Согласованность данных при бронировании	Надёжность	Система должна гарантировать отсутствие двойного бронирования одного столика на одно время. Вероятность конфликта должна быть менее 0,01%.	Must Have	Двойное бронирование — фатальная ошибка для репутации. Требует реализации транзакционности.
NFR-05	Защита персональных данных	Безопасность	Все персональные данные пользователей (email, телефон, история броней) должны храниться в зашифрованном виде. Передача данных между клиентом и сервером — только по HTTPS.	Must Have	Требование 152-ФЗ о персональных данных. Утечка данных приведёт к штрафам и потере доверия.
NFR-06	Масштабируемость	Масштабируемость	Система должна выдерживать пиковую нагрузку 50 RPS (запросов в секунду) на операции поиска и просмотра без деградации производительности.	Should Have	Оценка: на старте 10 000 пользователей, 20% активны в пике, 10 запросов за сессию → ~55 RPS.
NFR-07	Интуитивность интерфейса	Удобство использования	Пользователь должен выполнять бронирование (от выбора ресторана до подтверждения) не более чем за 3 минуты для нового пользователя.	Could Have	Можно провести юзабилити-тестирование и улучшить интерфейс в следующих версиях.
NFR-08	Доступность информации о ресторанах	Юридические и нормативные требования	Пользователи приложения должны видеть фирменное наименование ресторана, место нахождения, режим работы, государственный регистрационный номер. Поскольку мы являемся агрегатором (посредником), обязаны обеспечить наличие информации в карточке ресторана. Закон о «Защите прав потребителей», статья 9 «Информация об изготовителе (исполнителе, продавце, владельце агрегатора)» требует от агрегатора (посредника) обеспечить наличие информации о ресторане в карточках ресторана.	Should Have	Закон о «Защите прав потребителей»; для агрегатора обязательна корректная карточка ресторана.
NFR-09	Идентификация ресторанов-партнёров	Юридические и нормативные требования	Перед активацией профиля ресторана система должна проводить проверку юридического лица или ИП (по ИНН, ОГРН). При обнаружении недействительных или недостоверных данных регистрация должна отклоняться.	Must Have	Защита от мошенничества и повышение доверия пользователей. Предотвращаем репутационные риски.
NFR-10	Ограничение размера загружаемых файлов	Емкость	Система должна ограничивать размер загружаемых изображений (фото ресторанов, схемы залов) до 10 МБ для одного файла. Поддерживаемые форматы: JPEG, PNG.	Must Have	Без ограничений рестораны могут загружать файлы огромного размера, что приведёт к замедлению загрузки страниц у пользователей.
NFR-11	Горизонтальное масштабирование	Масштабируемость	Архитектура системы должна поддерживать горизонтальное масштабирование через добавление новых серверов. Должны выполняться следующие условия: • Возможность увеличить количество серверов с 2 до 10 (и более) по мере роста нагрузки. • Балансировка: использовать балансировщик нагрузки для равномерного распределения запросов к серверам. • Отказоустойчивость: при выходе одного из серверов из строя оставшиеся должны продолжать обслуживать запросы без потери данных.	Should Have	Горизонтальное масштабирование — стандартный подход для веб-сервисов с растущей нагрузкой. Оно позволяет наращивать мощность и обеспечивает отказоустойчивость.

Почему не покрыты остальные категории?

Категория	Объяснение
Совместимость	Для MVP мы ориентируемся на современные версии браузеров. Поддержка устаревших браузеров не требуется. Это сознательное ограничение, чтобы не усложнять разработку. Риск: небольшой процент пользователей со старыми браузерами не сможет воспользоваться сервисом, но для MVP это приемлемо. В будущих версиях можно добавить адаптацию под более широкий спектр.
Поддерживаемость	Для MVP мы считаем, что команда разработки обеспечит необходимый уровень поддерживаемости без явного требования.
Юридические и нормативные требования	Основное требование — 152-ФЗ о персональных данных — уже покрыто в NFR-05.