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

Конспект статьи. Автор оригинала: Ольга Пономарева (System_Analyst)

Практический туториал о том, как выявлять, формулировать и проверять НФТ. Автор начинает с кейса: продакшен упал при росте числа запросов в секунду, хотя все функции работали. Вывод — требования, которые кажутся второстепенными, часто оказываются критичными.

Категории по ISO/IEC 25010

• Производительность — только с цифрами: время загрузки при заданной нагрузке.
• Безопасность — аутентификация, шифрование, соответствие нормам, а не только HTTPS.
• Масштабируемость — запас на рост, например +50% пользователей.
• Надёжность — через процент доступности: 99,9% — это около 8 ч 46 мин простоя в год, 99,99% — около 52 минут.
• Удобство — время нового пользователя на ключевую задачу, число действий, соответствие WCAG.
• Совместимость — браузеры, ОС, legacy-системы.

Реже вспоминают переносимость (переезд на другую инфраструктуру) и обслуживаемость (документация, логирование, простота выкладки исправлений).

Как выявлять

Заменять общие вопросы конкретными: не «какая нагрузка», а «сколько пользователей одновременно в час пик»; не «нужна ли отказоустойчивость», а «какой максимальный простой допустим». Анализировать похожие системы и конкурентов. Регуляторные требования выяснять заранее — переделка после запуска обходится гораздо дороже.

Как проверять

• Нагрузочное тестирование (например, Gatling) — моделировать пиковый час, смотреть восстановление после пика, утечки памяти, поведение кеша.
• Безопасность — OWASP Top 10 как база.
• Юзабилити — наблюдение за пользователями, A/B-тесты, кликабельные прототипы.
• Метрики — RPS, TPS, MTBF, MTTR, SLA, SLO, Error Rate, TTFB, LCP и другие.

Главный принцип: если требование нельзя проверить, это пожелание. Для каждого НФТ заранее договариваются, как его будут тестировать. Формулировка по SMART: «95% вызовов укладываются в 1 секунду при 500 RPS».