Как сформулировать нефункциональные требования для внешнего сервиса?

Как сформулировать нефункциональные требования для внешнего сервиса

Определение нефункциональных требований

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

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

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

• Время отклика (Response Time): API должно отвечать за 100ms при 95-м процентиле
• Пропускная способность (Throughput): система должна обрабатывать 10000 запросов в секунду
• Задержка (Latency): максимальная задержка при синхронном вызове не должна превышать 500ms

Когда формулируешь требования, используй конкретные числа и процентили, а не расплывчатые выражения типа быстрое.

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

• Доступность (Availability): сервис должен быть доступен 99.9% времени (SLA)
• Среднее время между отказами (MTBF): система должна работать без сбоев в течение 30 дней
• Среднее время восстановления (MTTR): после отказа система восстанавливается за 15 минут

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

• Горизонтальная масштабируемость: система должна линейно масштабироваться при добавлении новых серверов
• Вертикальная масштабируемость: система должна использовать до 256GB памяти
• Ёмкость: система должна поддерживать 1 миллион одновременных пользователей

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

• Шифрование: все данные в покое должны быть зашифрованы AES-256
• Аутентификация: доступ только с валидным OAuth 2.0 токеном
• Авторизация: пользователь может видеть только свои данные
• Логирование: все операции должны логироваться для аудита

Мониторируемость и поддерживаемость (Observability & Maintainability)

• Логирование: структурированные логи в JSON формате
• Мониторинг: метрики по CPU, памяти, времени отклика должны быть доступны
• Трейсинг: все запросы должны быть отследены через распределённый трейсинг
• Документация: API должна быть задокументирована в Swagger/OpenAPI

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

• API версионирование: поддержка нескольких версий API одновременно
• Обратная совместимость: изменения API не должны ломать старые клиенты
• Поддерживаемые протоколы: HTTP/2, gRPC, WebSocket

Как формулировать требования корректно

Измеримость — каждое требование должно быть проверяемо:

• Плохо: Сервис должен быть быстрым
• Хорошо: Медиана времени отклика должна быть менее 50ms, 99-й процентиль менее 200ms

Реалистичность — требования должны быть достижимыми с учётом затрат:

• Требование 99.99% доступности стоит в 10 раз дороже 99.9%
• Нужно согласовать требования с бизнесом и техническими ограничениями

Специфичность — указывай условия, при которых требование действует:

• При нормальной нагрузке (до 1000 RPS)
• В пиковые часы (18:00-22:00)
• При отказе одного из трёх серверов

Приоритизация — не все требования одинаково важны:

• MUST HAVE: 99.5% доступность (критично для бизнеса)
• SHOULD HAVE: время отклика менее 100ms (важно для UX)
• NICE TO HAVE: поддержка WebSocket (улучшает опыт)

Требования для конкретных сценариев

Платёжный сервис (Payment Service)

• Точность: 100% корректность расчётов, ноль погрешности
• Безопасность: PCI DSS соответствие, шифрование
• Надёжность: 99.99% доступность
• Аудит: логирование всех операций

Сервис аналитики (Analytics Service)

• Задержка: приемлемо задержка в несколько минут
• Объём: обработка миллиардов событий в день
• Консистентность: eventual consistency приемлема

Real-time сервис уведомлений (Notification Service)

• Latency: доставка в пределах 1 секунды
• Доставляемость: минимум попытки переделать
• Масштабируемость: миллионы сообщений в секунду

SLA и контракты

Когда работаешь с внешним сервисом, требования должны быть зафиксированы в Service Level Agreement (SLA):

• Время отклика: максимум 200ms для 95% запросов
• Доступность: 99.5% в течение месяца
• Поддержка: критичные инциденты решаются за 4 часа
• Деградация сервиса: сервис уведомляет об известных проблемах заранее

Лучшие практики

• Согласуй NFR с заинтересованными лицами перед разработкой
• Проводи load testing для проверки требований
• Мониторь метрики в production и сравнивай с требованиями
• Документируй допуски и исключения
• Регулярно пересматривай и обновляй требования
• Включи требования в Definition of Done

Правильно сформулированные нефункциональные требования — это основа стабильной, масштабируемой и надёжной системы.