Нефункциональные требования (НФТ) к ПО — это измеримые правила про производительность и безопасность: на какую нагрузку система тянет и как защищает данные; реально выйти на «внятное ТЗ» за 1–3 дня, но ключевой риск — писать лозунги (“быстро”, “надёжно”) вместо цифр и проверок.

Боитесь, что разработчики сделают «нормально», а бизнес потом обнаружит, что “нормально” — это 12 секунд загрузки и утечка токена в логах? Это классика. НФТ как раз нужны, чтобы одинаково понимать слово «быстро» и «безопасно», а не спорить об этом на проде.

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

Что такое нефункциональные требования и чем они отличаются от функциональных

Функциональные требования описывают, что система делает: “пользователь оформляет заказ”, “админ блокирует аккаунт”.

Нефункциональные — как система должна это делать: за какое время, под какой нагрузкой, с каким уровнем защиты, логирования, доступности, восстановлением после сбоев.

Мини-шпаргалка: критерий хорошего НФТ

• Измеримо: есть число/порог/единица измерения.
• Проверяемо: понятно, каким тестом/аудитом подтверждается.
• Контекстно: написано для конкретных сценариев и критичных операций.
• С приоритетом: что must-have, а что “было бы неплохо”.

Подводный камень: НФТ без сценариев. “1000 RPS” само по себе бессмысленно, если не сказано, какие ручки API, какой профиль запросов, какой размер данных и какая доля чтение/запись.

Как описывать производительность (performance): цифры, сценарии, тесты

1) Начинаем не с «система должна быть быстрой», а со SLO

SLO (Service Level Objective) — целевые метрики сервиса: задержки, пропускная способность, ошибки, доступность. Для требований это идеальная форма: бизнесу понятна, инженерам измерима.

2) Что обычно фиксируют в НФТ по производительности

• Latency: p95/p99 время ответа (в мс/сек) по конкретным операциям.
• Throughput: RPS/TPM, количество параллельных пользователей.
• Ошибка: допустимый процент 5xx/таймаутов.
• Ресурсы: ограничения CPU/RAM, время GC, размер очередей.
• Поведение при деградации: что отключаем первым (например, рекомендации), чтобы сохранить оформление заказа.

Практический вывод: выбирайте 3–5 критичных пользовательских сценариев и описывайте требования на них, а не «на систему в целом».

3) Примеры формулировок НФТ по производительности (готовые к проверке)

• Web/API latency: “Для метода POST /checkout при профиле нагрузки 70% чтение / 30% запись, p95 ≤ 800 мс, p99 ≤ 1500 мс, при 300 RPS в течение 30 минут; доля 5xx ≤ 0.2%.”
• UI: “Time to Interactive на странице каталога ≤ 3.0 сек на мобильных устройствах уровня Android 10 / 4GB RAM при сети 4G (медиана по Lighthouse)”.
• Batch: “Ежедневная выгрузка отчёта на 2 млн записей завершается за ≤ 25 минут; потребление RAM процесса ≤ 2 GB; при ошибках > 0.5% происходит автоповтор 3 раза с backoff.”
• Пики: “Система выдерживает пик x3 от среднего трафика (до 900 RPS) без нарушения SLO p95 ≤ 1.2 сек для чтений; возможна деградация некритичных функций (отключение блока ‘похожие товары’).”

Типичная ошибка: писать “система должна поддерживать 10 000 пользователей”. Пользователи — не нагрузка. Нагрузка — это запросы, их типы, частота и профиль поведения.

4) Таблица: шаблон требований к performance

Как описывать безопасность (security): не «по ГОСТу», а по угрозам

1) Сначала — активы и угрозы

Безопасность в требованиях начинается с вопроса: что защищаем (персональные данные, деньги, токены, коммерческие отчёты) и от кого (фишинг, утечка логов, инсайдер, подбор пароля, SQLi, XSS).

Практический вывод: на 1 странице зафиксируйте список активов + угроз. После этого требования пишутся в 2 раза быстрее.

2) Что обычно фиксируют в НФТ по безопасности

• Аутентификация: MFA, политики сессий, запрет слабых паролей.
• Авторизация: RBAC/ABAC, принцип наименьших привилегий.
• Шифрование: TLS, шифрование данных “at rest”.
• Секреты: хранение ключей/токенов, ротация.
• Журналы и аудит: что логируем, что нельзя логировать, сроки хранения.
• Уязвимости: SAST/DAST, управление зависимостями.
• Инциденты: требования к реагированию, RTO/RPO (если важно).

3) Примеры требований по безопасности (чёткие и проверяемые)

• TLS: “Весь внешний трафик — только HTTPS (TLS 1.2+). HTTP перенаправляется на HTTPS. HSTS включён.”
• Пароли: “Минимум 12 символов, проверка на утечки (HIBP/аналог), блокировка после 10 неуспешных попыток на 15 минут, rate limiting на /login.”
• Сессии: “Access token живёт ≤ 15 минут, refresh token ≤ 30 дней; при смене пароля все refresh токены инвалидируются.”
• Роли: “Админские операции доступны только роли Admin; доступ к данным клиента — только владельцу (user_id) и саппорту по заявке с аудит-логом.”
• Логи: “В логах запрещены: пароли, токены, полные номера карт, CVC. PII маскируется. Срок хранения логов 180 дней, доступ — по RBAC.”
• Зависимости: “Критические уязвимости (CVSS ≥ 9.0) в зависимостях — блокируют релиз; исправление ≤ 72 часов.”

Типичная ошибка: “Соответствовать лучшим практикам OWASP”. Это не требование, это настроение. Нужны конкретные контрмеры + критерии проверки.

4) Таблица: безопасность как набор контролей

Скрытая цена НФТ: что «забывают» и потом платят дважды

• Наблюдаемость (метрики/логи/трейсы). Без неё performance и security — гадание.
• Тестовые стенды, близкие к продакшену. Иначе нагрузочные тесты — театр.
• Процессы: кто реагирует на инцидент, кто владелец SLO, кто принимает риск.

Подводный камень: требования “p99 200 мс” на архитектуре без кэшей и очередей. Можно, но бюджет и сроки внезапно тоже становятся «нефункциональными».

Экспертный вердикт и инструмент: чек‑лист, чтобы НФТ не были фольклором

1. Назовите 3–5 критичных сценариев (деньги, доступ, ключевые user-journey).
2. Зафиксируйте метрики: p95/p99, RPS, error rate, RTO/RPO (если нужно).
3. Опишите условия: профиль нагрузки, объём данных, окружение, длительность теста.
4. Добавьте критерии приёмки: каким тестом подтверждаем, кто подписывает.
5. Опишите деградацию: что можно “уронить”, чтобы не уронить главное.

Частые вопросы