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

Нефункциональные требования (Non-Functional Requirements, NFR) – требования, описывающие как система должна работать (качество), а не что она должна делать (функции). NFR определяют архитектуру не меньше, чем бизнес-требования.

Основные категории NFR

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

• Время отклика (Response Time): “API-метод должен отвечать за < 200 мс (P95)”.
• Пропускная способность (Throughput): “Система должна обрабатывать 1000 платежей в секунду”.
• Задержка (Latency): “End-to-end задержка < 500 мс”.

2. Доступность (Availability)

• SLA: “99.95% uptime = не более 4.38 часов простоя в год”.
• RTO (Recovery Time Objective): максимальное время восстановления после сбоя.
• RPO (Recovery Point Objective): максимально допустимый объём потерянных данных (измеряется во времени).

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

• “Система должна выдерживать 10-кратный рост нагрузки за 6 месяцев”.
• Горизонтальное масштабирование без архитектурных изменений.

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

• Аутентификация и авторизация (OAuth2, JWT).
• Шифрование данных at rest и in transit (TLS).
• Соответствие стандартам (PCI DSS для карточных данных, GDPR для персональных данных).
• Журналирование всех критичных операций (audit log).

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

• Отказоустойчивость – работа при сбое отдельных компонентов.
• Консистентность данных – отсутствие потерь транзакций.

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

• Логирование (ELK stack).
• Метрики (Prometheus + Grafana).
• Трассировка (Jaeger, Zipkin).

7. Сопровождаемость (Maintainability)

• Читаемость кода, покрытие тестами.
• Документация API и архитектурных решений.

Как фиксировать NFR

Каждое нефункциональное требование должно быть измеримым. Расплывчатое “система должна быть быстрой” бесполезно. Вместо этого:

Требование: Время отклика API создания платежа
Метрика: P95 < 300 мс при нагрузке 500 RPS
Измерение: JMeter / Gatling нагрузочные тесты
Мониторинг: Prometheus histogram + Grafana dashboard

Итог

NFR определяют архитектурные решения. Требование “99.99% uptime” диктует резервирование, мультизональный деплой, автоматический failover. Требование “обработка 10 000 RPS” диктует горизонтальное масштабирование и асинхронную обработку. Без явно зафиксированных NFR архитектура строится на догадках.

На собеседовании: Интервьюер ожидает, что вы назовёте конкретные измеримые примеры NFR (P95 latency, SLA в процентах), а не абстрактные “быстро и надёжно”. Частая ошибка – забывать про наблюдаемость и сопровождаемость, сосредотачиваясь только на производительности.