В чем разница между нефункциональными и функциональными требованиями?

Что проверяют

Различаете ли вы «что делает» и «каким должно быть», и понимаете ли, что второе обязано быть измеримым.

Как отвечать

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

Нефункциональные требования описывают свойства системы: производительность, надёжность, доступность, безопасность, масштабируемость, удобство, совместимость, сопровождаемость. Набор атрибутов качества стандартизован в ISO 25010. Проверяются измерением, а не да или нет.

Ключевое правило: нефункциональное требование без числа это не требование. «Система должна работать быстро» непроверяемо. Требование выглядит так: «95-й перцентиль времени ответа поиска не выше 300 мс при 1000 запросов в секунду на рабочем окружении». Аналогично доступность это «99,9% в месяц», а не «должна быть надёжной».

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

Почему это важно именно аналитику: функциональные требования меняются относительно дёшево, а нефункциональные определяют архитектуру. Требование к времени ответа, к объёму данных или к доступности задаёт выбор хранилища и схемы развёртывания. Всплывшее после релиза, оно почти всегда означает переделку, а не доработку. Поэтому их собирают в самом начале и вместе с ответом на вопрос «как мы это проверим».

Где спотыкаются

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

Собирают их в конце, когда архитектура уже сделана.

Относят к нефункциональным всё, что не придумали, куда деть.

Путают ограничения с требованиями.