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

«Как собираются нефункциональные требования (NFR) в проекте?» — вопрос из категории Софт-скиллы, который задают на 10% собеседований Java Разработчик. Ниже — развёрнутый пример ответа, который можно адаптировать под свой опыт.

Ответ

Да, нефункциональные требования (NFR) собираются и документируются. Они описывают не что делает система, а как она это делает, и критичны для успеха проекта.

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

  • Производительность: Время отклика, пропускная способность (RPS), использование ресурсов.
  • Масштабируемость: Возможность системы справляться с ростом нагрузки.
  • Надежность и доступность: Время безотказной работы (uptime), устойчивость к сбоям.
  • Безопасность: Аутентификация, авторизация, соответствие стандартам (GDPR, PCI DSS).
  • Удобство использования (Usability): Интуитивность интерфейса, время обучения.
  • Сопровождаемость: Простота поддержки, тестирования и развертывания.

Как собираются:

  1. Интервью и воркшопы с заказчиком и стейкхолдерами.
  2. Анализ аналогичных систем и отраслевых стандартов.
  3. Фиксация в документации: Техническое задание (ТЗ), SLA (Service Level Agreement), нефункциональные спецификации.

Пример конкретного требования и реализации:

Требование: Время отклика 95-го перцентиля для API /api/order не должно превышать 200 мс при нагрузке 1000 запросов в секунду.

Почему это важно: Игнорирование NFR на ранних этапах ведет к дорогостоящим архитектурным переделкам на поздних стадиях проекта. Они определяют выбор технологий, архитектуру и подход к тестированию (нагрузочное, стресс-тестирование).