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

«Быстро» превращается в проверку времени ответа для конкретного сценария и нагрузки. «Надёжно» — в допустимую долю повторных ошибок, восстановление и отсутствие потери данных. «Безопасно» — в список разрешений, запретов и проверяемых событий. Формулировка должна указывать субъект, границу и свидетельство.

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

AI-агент может собрать измерения, сопоставить их с порогами и показать пропуски. Он не должен подменять отсутствие данных зелёным статусом. Нельзя принять NFR, если измерение не охватывает заявленную область.

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

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

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