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

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

Нефункциональные требования (Non-Functional Requirements, NFR) — это критерии качества, которые описывают не ЧТО должна делать система (это удел функциональных требований), а КАК она это должна делать. Они определяют характеристики системы, её поведение в различных условиях и ограничения, накладываемые на реализацию. Если функциональные требования отвечают на вопрос «Что система делает?», то нефункциональные — «Как хорошо она это делает?».

Эти требования не менее критичны для успеха проекта, чем функциональные. Их несоблюдение может привести к системе, которая технически выполняет заявленные функции, но на практике непригодна для использования: слишком медленная, ненадёжная, неудобная или небезопасная.

Ключевые категории нефункциональных требований (на примере интернет-магазина)

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

Определяет скорость и эффективность работы системы.

• Время отклика: «95% всех запросов страниц каталога должны загружаться менее чем за 2 секунды».
• Пропускная способность: «Система должна обрабатывать не менее 1000 успешных заказов в час».
• Использование ресурсов: «Под пиковой нагрузкой использование CPU не должно превышать 70%».

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

Характеризует способность системы выполнять требуемые функции в заданных условиях в течение определённого времени.

• Доступность (Availability): «Система должна быть доступна для пользователей 99.9% времени в рабочее время (с 8:00 до 20:00 по МСК)».
• Отказоустойчивость (Fault Tolerance): «При сбое основного сервера баз данных автоматическое переключение на резервный должно произойти в течение 30 секунд».
• Восстанавливаемость (Recoverability): «Полное восстановление системы после критического сбоя должно занимать не более 4 часов».

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

Касается простоты освоения и эффективности работы пользователя с системой.

• Обучаемость: «Новый пользователь без подготовки должен суметь оформить заказ за 5 минут».
• Соблюдение стандартов: «Интерфейс административной панели должен соответствовать рекомендациям Material Design».
• Доступность (Accessibility): «Веб-интерфейс должен соответствовать уровню AA стандарта WCAG 2.1 для поддержки пользователей с ограниченными возможностями».

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

Определяет меры по защите системы и данных от несанкционированного доступа.

• Аутентификация: «Доступ к платежным данным возможен только после двухфакторной аутентификации».
• Шифрование: «Все передаваемые личные данные пользователей должны шифроваться с использованием TLS 1.3».
• Аудит: «Система должна вести логи всех попыток доступа к API управления заказами с сохранением IP-адреса и времени».

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

Описывает способность системы работать в различных окружениях.

• Браузеры: «Ключевой функционал сайта должен корректно работать в последних версиях Chrome, Firefox, Safari и Edge».
• Мобильные устройства: «Интерфейс должен быть адаптивным и корректно отображаться на экранах от 320px до 1920px».
• Интеграция: «Система должна предоставлять REST API, совместимое с версией 1.2 нашей внутренней ERP-системы».

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

Способность системы увеличивать производительность при добавлении ресурсов.

• «Архитектура системы должна позволять горизонтальное масштабирование веб-серверов для обработки увеличения трафика в 10 раз в период распродажи».

Роль QA-инженера в работе с нефункциональными требованиями

1. Участие в спецификации: Помогать формулировать NFR измеримо и проверяемо. Вместо «система должна быть быстрой» — «время отклика API поиска товаров при нагрузке 100 RPS не более 200 мс».
2. Планирование тестирования: Разрабатывать стратегии нефункционального тестирования: нагрузочное (Load Testing), стрессовое (Stress Testing), тестирование удобства использования (Usability Testing), тестирование безопасности (Security Testing).
3. Автоматизация проверок: Многие NFR можно и нужно проверять автоматически в CI/CD.

   // Пример упрощённого JUnit-теста на производительность
   @Test
   @Timeout(value = 2000, unit = TimeUnit.MILLISECONDS) // Требование: ответ < 2 сек.
   public void productSearchApiResponseTimeTest() {
       long startTime = System.currentTimeMillis();
       Response response = apiClient.searchProducts("laptop");
       long duration = System.currentTimeMillis() - startTime;
   
       assertTrue(response.statusCode() == 200);
       assertTrue("Response time exceeds requirement", duration < 2000);
   }
   

4. Использование специализированных инструментов:

    *   **Производительность:** JMeter, Gatling, k6.
    *   **Безопасность:** OWASP ZAP, Burp Suite.
    *   **Доступность:** axe DevTools, Lighthouse.

1. Мониторинг в продакшене: Участвовать в настройке мониторинга (например, через Prometheus+Grafana) для контроля соблюдения NFR в реальной эксплуатации.

Важный вывод: Нефункциональные требования — это фундамент пользовательского опыта и технического здоровья продукта. Их игнорирование ведёт к рискам для бизнеса: потере клиентов, репутационным издержкам и высоким затратам на последующую переделку системы. Грамотный QA-инженер должен рассматривать NFR не как второстепенные, а как обязательные и проверяемые критерии качества, требующие такого же тщательного тестового покрытия, как и бизнес-логика.