Вчера с коллегой на должности «Системный архитектор» обсуждали НФТ и их влияние на архитектуру, а также почему вообще этот пласт арх работы важен.

Напомню, что я считаю термин «нефункциональные требования» абсолютно отвратительным по нескольким причинам.

Во-первых, само название «нефункциональные требования» как бы противопоставляется термину «функциональные требования». В голове как стейкхолдеров, так и команды имплементаторов (аналитиков, разработчиков, менеджеров) это противопоставление работает не в пользу первых - «мы же разрабатываем ФУНКЦИОАЛЬНОСТЬ, зачем нам какие-то НЕФУНКЦИОНАЛЬНЫЕ требования?». Как следствие, ценность всех процессов, связанных с «НФТ» - выявления, анализа, проектирования и БЮДЖЕТИРОВАНИЯ - стремится к нулю. При построении плана работ и бюджетировании все уходит исключительно в фича-деливеринг, а «НФТ» остается хотелками всяких там технарей, служб эксплуатации и прочих непонятных людей, которые не про результаты, а про техническое совершенство (что - будем честны - иногда не то чтобы прям совсем неправда). Стоит ли говорить, что практика эта порочна, а выполнение всяких *-ilities обычно стоит денег и времени, в лучшем случае сопоставимых с фичами, а чаще и намного больше?

Во-вторых, создается впечатление, что «нефункциональные требования» существуют в принципе в отрыве от функциональных, что конечно неправда. Сами по себе требования «к системе в целом» - за редким исключением - не интересны, потому что «система в целом» - это непонятная сущность. А понятными и обладающими ценностью для заинтересованных сторон являются именно характеристики, связанные с функциями системы. То есть условно, мало кому интересна «надежность системы в 99,9», потому что непонятно, как проявляется надежность целой системы, а если и понятно - непонятно, какую ценность это принесет. Тогда как «надежность функции регистрации пользователей в системе - 99,9» - вполне понятная характеристика, которую и ясно, как мерять, и ясно, как использовать. В итоге «нефункциональные требования» в имеющем ценность смысле - это по сути требования к характеристикам качества функциональных требований и сценариев (повторюсь, за редким исключением, типа «архитектурных» требований, где говорится о том, как система должна быть устроена, но и они, при желании, докручиваются до характеристик качества вида «функция А должна быть отделена от функции Б»)

Именно поэтому я в своей практике стараюсь использовать вместо термина «нефункциональные требования» две категории требований:
- ограничения
- требования к качеству,

которые в составе понятия «НФТ» обычно распределяются как 20/80.

О том, почему это важный пласт архитектурной работы, на каких этапах мы работаем с какими требованиями - в следующем потоке сознания!

З.Ы. Вот тут лежит один из моих первых докладов на аналитической конференции, где я рассказывал про архитектурно-значимые требования. Вроде как рассказывал «по-простому», для аналитиков от уровня джуна. Это доклад 18го года, с тех пор я немного докрутил эту концепцию, но общие принципы, включая подход к классификации, категории и подходы к фиксации и анализу требований остались те же. Этот же доклад лег в основу воркшопа по нефункциональным требованиям, который я проводил на нескольких конференциях, а также относительно регулярно провожу в родной организации (и как раз сейчас докручиваю его до воркшопа по архитектурно-значимым требованиям, расширяя требования качества функциональными).