(В оригинале Quantify)

Требование «Быстро» фактически требованием не является. Как и не является требованием «Расширяемо» или «Надежно». Самая главная причина этого – это то, что у вас нет объективного способа измерить полученный результат, чтобы сказать, выполнено требование или нет. Однако пользователи часто такие требования ставят. И задача архитектора – сделать так, чтобы проектируемая система обладала этими качествами. Найти баланс между конфликтами и несоответствиями между ними. И без объективных критериев архитектору придется полагаться на добрую волю капризных пользователей («Нет, система все еще работает недостаточно быстро!») и слишком требовательных разработчиков («Мы не можем выпустить релиз, система все еще работает недостаточно быстро!»).

Слишком часто при определении требований к системе записываются такие неопределенные прилагательные как «гибкий», «легко поддерживаемый» и им подобные. И в большинстве таких случаев можно задать некий исчисляемый критерий и определить границы. И если этого не сделать, то у вас не будет основы для критерия сдачи работы заказчику, у разработчиков не будет мотивации для работы, а у архитекторов – четкого видения.

Несколько простых вопросов могут это прояснить. Сколько? За какой период? Как часто? К какому сроку? С какой частотой? Если на эти вопросы не будет ответов, то значит, что потребность клиента не сформулирована. Ответы должны быть на языке бизнеса, использующего систему, в противном случае надо очень хорошо подумать. Если вы проектируете систему и ваш заказчик не хочет или не может назвать вам эти цифры, задайте себе вопрос «Почему?». А потом все же получите эти ответы. И если в следующий раз вам скажут, что система должна быть «масштабируемой», спросите, откуда появятся новые пользователи, сколько их будет и как часто это будет происходить. И не принимайте ответы «Много» и «Часто».

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

«Система должна давать ответ пользователю не позднее чем через 1500 миллисекунд после ввода. Во время нормальной загрузки (определяемой как...) среднее время ответа должно быть в диапазоне от 750 до 1250 миллисекунд. Для времен менее 500 миллисекунд пользователь уже не заметит особой разницы, поэтому тратить ресурс на снижение времени ниже этой границы мы не будем» - вот теперь это требование!

Автор оригинала: Keith Braithwaite