Приведите примеры нефункциональных требований

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

Отличаете ли вы «что система делает» от «какой она должна быть», и умеете ли формулировать требование так, чтобы его можно было проверить. Для аналитика это базовый навык: непроверяемое требование не требование.

Как отвечать

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

Дальше примеры по группам, обязательно с числами и условиями измерения:

• производительность: 95-й процентиль ответа на поиск не выше 300 мс при нагрузке 500 запросов в секунду;
• масштабируемость: рост нагрузки вдвое выдерживается добавлением узлов без изменения кода;
• доступность и надёжность: 99.9 процента в месяц, восстановление после сбоя не дольше 15 минут, потеря данных не более чем за 5 минут;
• безопасность: шифрование данных при передаче и хранении, двухфакторная аутентификация для административных ролей, журнал действий с хранением год;
• удобство и доступность: соответствие WCAG 2.1 уровня AA, оформление заказа не больше чем в три шага;
• совместимость: две последние версии Chrome, Safari и Firefox, Android от 10;
• эксплуатация: метрики и оповещения по ключевым сценариям, развёртывание без простоя.

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

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

Пишут «система должна быть быстрой и удобной». Проверить такое нечем, на приёмке начинается спор.

Забывают условия замера: 300 мс на пустой базе и на десяти миллионах записей это разные требования.

Смешивают с ограничениями проекта: «использовать PostgreSQL» это ограничение решения, а не свойство системы.