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

1) Безопасность (Security)

ID	Название	Описание требования	Приоритет	Обоснование	Как проверяется
NFR-SEC-001	Шифрование трафика	Все запросы клиента к backend выполняются по HTTPS (TLS 1.2+). HTTP-запросы перенаправляются на HTTPS.	MUST	В системе обрабатываются персональные данные (аккаунт, переписка, фото, геометки). Без шифрования возможен перехват данных и юридические/репутационные риски.	Открыть сервис и проверить протокол HTTPS, попытаться открыть HTTP, но должно переключаться на HTTPS.
NFR-SEC-002	Доступ к операциям с объявлениями	Доступ к операциям создания/редактирования/закрытия объявления имеет только автор.	MUST	Защита от доступа к чужим данным и подмены действий (мошенничество, утечки).	Другой пользователь пытается редактировать/закрыть чужое объявление, получает отказ.
NFR-SEC-003	Доступ к диалогу	Доступ к диалогу имеют только участники диалога.	MUST	Защита от доступа к чужим данным и подмены действий (мошенничество, утечки).	Пользователь, не являющийся участником, пытается открыть диалог, получает отказ.
NFR-SEC-004	Доступ к жалобам и модерации	Просмотр жалоб и действия модерации доступны только модератору.	MUST	Защита от доступа к чужим данным и подмены действий (мошенничество, утечки).	Негативный тест: обычный пользователь пытается открыть раздел жалоб/модерации, получает отказ.
NFR-SEC-005	Защита от подбора паролей	После 5 неудачных попыток входа следует блокировка попыток для аккаунта на 15 минут.	SHOULD	Порог 5 попыток отсекает подбор пароля, но не мешает пользователю при единичных ошибках. 15 минут, достаточное время, чтобы снизить частоту попыток подбора без полной блокировки аккаунта. Это снижает риск подбора пароля, повышает безопасность входа.	Смоделировать 5 неверных входов и убедиться, что вход блокируется на 15 минут.
NFR-SEC-006	Логирование блокировки входа	Событие блокировки входа фиксируется в журнале событий.	SHOULD	Снижает риск подбора пароля и повышает безопасность входа.	После срабатывания NFR-SEC-005 проверить наличие записи в логах.
NFR-SEC-007	Хранение паролей	Пароли хранятся в базе данных только в зашифрованном виде/в виде хэша, восстановить исходный пароль из базы невозможно.	MUST	Даже при утечке БД пароли не должны раскрываться в открытом виде.	Проверить, что в БД нет хранения пароля в открытом виде.

2) Производительность (Performance)

ID	Название	Описание требования	Приоритет	Обоснование	Как проверяется
NFR-PERF-001	Скорость загрузки ленты	Лента объявлений загружается ≤ 2 сек при выдаче до 50 объявлений.	MUST	50 – ограничение первой выдачи, чтобы не перегружать экран и сеть. 2 секунды – целевое время, при котором пользователь не бросает сценарий. Быстрая лента повышает шанс, что пользователь не уйдёт на альтернативы (чаты/группы).	Замер времени загрузки ленты при выдаче 50 объявлений.
NFR-PERF-002	Время ответа поиска/фильтров	API поиска/фильтров возвращает результаты ≤ 500 мс при нагрузке до 100 RPS.	MUST	100 запросов/сек – оценка пикового чтения для MVP при 200 одновременных пользователях. Цель 500 мс выбрана как почти мгновенный отклик фильтров, иначе ухудшается сценарий поиска совпадений. Поиск и фильтры – ключевая ценность, задержки снижают эффективность нахождения совпадений.	Нагрузочный тест API поиска/фильтров (100 запросов/сек) и замер времени ответа.
NFR-PERF-003	Карта и маркеры	Первичная загрузка карты и отображение маркеров в выбранном радиусе ≤ 2 сек при отображении до 300 маркеров (с кластеризацией).	MUST	Карта – ключевая функция MVP, без приемлемой скорости падает полезность сервиса. 300 маркеров – предел, после которого карта становится визуально перегруженной, 2 секунды – целевое время первого появления карты/точек, иначе пользователю проще уйти в ленту.	Тест: сформировать 300 объявлений в радиусе и провести замер времени загрузки карты и маркеров.

3) Надёжность (Reliability)

ID	Название	Описание требования	Приоритет	Обоснование	Как проверяется
NFR-REL-001	Доступность сервиса	Доступность backend и основных функций (лента/поиск/создание/диалоги) ≥ 99.5% в месяц.	MUST	Для MVP допускается компромисс, но частые простои убивают доверие и новые публикации/отклики. 99.5% выбрано как реалистичная цель для MVP при небольшой команде и внешних зависимостях.	Мониторинг доступности за месяц / отчёт по инцидентам.
NFR-REL-002	Ежедневное резервное копирование БД	Резервное копирование БД выполняется ежедневно.	MUST	Потеря объявлений/диалогов критична: ломает доверие и метрики «закрыто».	Проверить расписание и наличие ежедневных бэкапов.
NFR-REL-003	Хранение бэкапов	Хранение бэкапов БД составляет ≥ 30 дней.	SHOULD	Срок хранения 30 дней выбран как минимально достаточный для обнаружения ошибок (например, некорректного удаления объявлений, скрытых багов, жалоб пользователей спустя 1–2 недели). Такой период позволяет восстановиться даже если проблема выявлена не сразу.Потеря объявлений/диалогов критична: ломает доверие и метрики «закрыто».	Проверить политику хранения/наличие бэкапов за прошлые периоды.
NFR-REL-004	Допустимая потеря данных	При аварии допустимая потеря данных составляет ≤ 24 часа.	SHOULD	Допустимая потеря данных ≤ 24 часа логически следует из ежедневного резервного копирования, в худшем случае теряются изменения, внесённые после последнего бэкапа. Для MVP это приемлемый уровень риска.	Восстановление из последнего бэкапа, сравнение с временем последней копии.
NFR-REL-005	Срок восстановления	После сбоя восстановление сервиса выполняется не более чем за 4 часа.	SHOULD	Время восстановления ≤ 4 часов выбрано как реалистичная цель для MVP при небольшой команде и отсутствии круглосуточной поддержки. Данный срок включает восстановление БД из бэкапа и перезапуск сервиса.	Поднять сервис из бэкапа и зафиксировать время восстановления.
NFR-REL-006	Работа при недоступности карты	При недоступности API карты сервис остаётся работоспособным: лента/поиск доступны, место можно указать/фильтровать текстом (район/адрес/ориентир).	MUST	Внешний провайдер карты может упасть, нужна альтернатива, чтобы сервис не останавливался.	Имитация недоступности карты, проверка публикации/поиска с текстовым местом.

4) Ёмкость (Capacity)

ID	Название	Описание требования	Приоритет	Обоснование	Как проверяется
NFR-CAP-001	Пиковая нагрузка MVP	Система устойчиво обслуживает: до 200 одновременных пользователей, до 100 RPS на чтение (лента/поиск), до 20 RPS на запись (создание/маркетинга.	MUST	Оценка для пилота: чтение доминирует (просмотр ленты/поиска чаще, чем публикации), поэтому лимит чтения выше записи. 200 одновременных пользователей соответствует пилотному запуску без массового маркетинга.	Нагрузочный тест на чтение и записи, проверка отсутствия критичных ошибок/таймаутов.
NFR-CAP-002	Объём активных объявлений (в месяц)	Система поддерживает до 1 000 новых объявлений в месяц.	SHOULD	Нужны прогнозируемые лимиты для MVP и базы сопоставлений. 1 000 объявлений в месяц — ожидаемая величина для пилота в Москве (в среднем 30–40 объявлений в день), достаточная для появления совпадений.	Заполнить тестовыми данными до 1 000 объявлений за расчётный период; проверить работоспособность ленты и поиска (скорость, отсутствие ошибок).
NFR-CAP-003	Объём архива объявлений	Система поддерживает хранение до 100 000 объявлений в архиве.	SHOULD	Архив 100 000 объявлений обеспечивает накопление истории без заметного ухудшения работы поиска при корректной индексации. Это запас для роста в рамках одного региона.	Заполнить архив тестовыми данными до 100 000 записей, проверить корректность выборок и стабильность работы поиска.
NFR-CAP-004	Лимиты медиафайлов	Для объявления: до 5 фото, размер одного фото ≤ 10 МБ (общий лимит на объявление ≤ 50 МБ).	MUST	5 фото достаточно, чтобы показать предмет/животное с разных ракурсов. 10 МБ – верхняя граница размера одного фото с телефона. 50 МБ на объявление ограничивает злоупотребления и расходы на хранение/трафик в MVP.	Попытка загрузить 6-е фото/файл >10 МБ/суммарно >50 МБ, тогда система должна отказать.

5) Удобство использования (Usability)

ID	Название	Описание требования	Приоритет	Обоснование	Как проверяется
NFR-UX-001	Быстрая публикация объявления	80% новых пользователей способны создать объявление (категория+место+время+приметы) за ≤ 3 минуты без обращений в поддержку (usability-тест на 10–20 пользователях).	SHOULD	3 минуты соответствует продуктовой цели MVP (быстро создать объявление). 80% – минимально приемлемая доля успешного прохождения ключевого сценария без помощи. 10–20 человек достаточно для пилотной проверки и выявления основных проблем.	Usability-тест: 10–20 человек, замер времени и доли успешно завершивших сценарий.
NFR-UX-002	Понятные ошибки и валидация	Ошибки формы показываются рядом с полем, текст ошибки объясняет, что исправить (без технических терминов).	MUST	Если пользователь не поймёт ошибку, то объявление не будет создано и падают совпадения и эффективность сервиса.	Проверка подсветки и текста ошибок.

6) Совместимость (Compatibility)

ID	Название	Описание требования	Приоритет	Обоснование	Как проверяется
NFR-COMP-001	Поддержка браузеров и адаптивность	Веб-интерфейс корректно работает в Chrome/Firefox/Safari, адаптивность для ширины 320–1440 px.	SHOULD	Пользователи приходят с разных устройств, нельзя терять аудиторию из‑за верстки.	Кроссбраузерный тест ключевых сценариев и проверка отображения на мобильном телефоне/десктопе.
NFR-COMP-002	Работа без карты как UI-сценарий	Если карта не загружается, интерфейс предоставляет альтернативу: лента/фильтры доступны, место можно вводить текстом.	MUST	Закрывает зависимость от внешнего API на уровне пользовательского интерфейса.	Имитировать сбой карты, убедиться, что лента/фильтры/ввод места текстом доступны.

7) Нормативно-правовые требования (Regulatory)

ID	Название	Описание требования	Приоритет	Обоснование	Как проверяется
NFR-REG-001	Согласия и документы	До использования функций, связанных с персональными данными (регистрация/диалоги/публикация фото), пользователь имеет доступ к политике конфиденциальности и пользовательскому соглашению, а система фиксирует факт принятия.	MUST	Сервис обрабатывает персональные данные, нужны прозрачные правила и фиксация согласий.	Проверить: без принятия документов регистрация/публикация недоступны; факт принятия фиксируется (дата/время/версия документа).
NFR-REG-002	Минимизация персональных данных в публикациях	Система не требует и не просит публиковать категории с персональными данными(серия/номер документа, номер карты, адрес проживания). Для таких типов действуют правила публикации и подсказки, что нельзя публиковать.	MUST	Снижает риск утечек и мошенничества, способствует безопасной передачи вещи.	Проверить формы: нет обязательных полей “номер/серия/адрес”; при выборе типа показываются подсказки “что нельзя публиковать”.
NFR-REG-003	Реактивная модерация и удаление контента	По жалобам модератор может скрыть объявление, запросить правку или ограничить аккаунт.	SHOULD	Платформа с пользовательским контентом без механизма реакции быстро превращается в спам/мошенничество.	Тест: отправить жалобу, увидеть её у модератора; применить действие “скрыть”, объявление пропадает из выдачи.

2.2 Обоснование непокрытых категорий

В НФТ MVP сознательно включены категории, которые прямо влияют на ценность сервиса и безопасность пользователей: Security, Performance, Reliability, Capacity, Usability, Compatibility, Regulatory.

Ниже описаны категории, которые не детализированы в MVP, и написана аргументация.

1) Масштабируемость (Scalability)

• Почему не критична: MVP ограничен Москвой и пилотной аудиторией. На старте важнее подтвердить, что сервисом пользуются (есть объявления, есть отклики, закрытия), чем закладывать требования под федеральную нагрузку.

• Риски игнорирования: если рост аудитории будет быстрее ожиданий, возможно ухудшение скорости поиска/карты/чат-диалогов.

• План: уточнить требования по масштабированию в V2/V3 на основе данных пилота (реальные пики, рост объявлений, нагрузка по модулям).

2) Наблюдаемость (Observability)

• Почему не критична: в MVP достаточно базового логирования ошибок и ключевых действий, чтобы реагировать на проблемы, полноценные метрики/алерты можно нарастить после запуска.

• Риски игнорирования: дольше находить причины ошибок, сложнее расследовать спорные кейсы (жалобы/мошенничество).

• План: в V2 добавить детальные метрики, дашборды и уведомления по порогам (после появления статистики и типовых инцидентов).

3) Поддерживаемость (Maintainability)

• Почему не критична: На этапе MVP важнее проверить работоспособность ключевых сценариев и собрать обратную связь. Детальные требования к процессам разработки и качеству кода целесообразно формализовать после пилота, на основе фактических рисков и темпа изменений.

• Риски игнорирования: при росте команды и частых изменениях может увеличиться число ошибок после обновлений.

• План: в V2 закрепить минимальные требования к тестированию критичных сценариев (публикация/поиск/owner-check) и к документации API.