Почему же «нефункциональные» требования так важны для архитектурного проектирования, и почему анализ НФТ сложнее, чем кажется?
Первое, что приходит в голову - достаточно старый стереотип, что "аналитик работает с функциональными требованиями, а архитектор - с нефункциональными". Конечно, это сильное упрощение, исходная суть которого в том, что аналитик часто отвечает за поставку функциональных возможностей продукта/ системы, а архитектор - за внешнее и внутреннее качество. И это качество определяется в том числе потребностями разных категорий заинтересованных лиц:
- "имплементаторов", то есть команд разработки, внедрения и поддержки/ эксплуатации. Здесь в полный рост встают такие требования, как наблюдаемость (observability), ремонтопригодность (maintainabilty), модифицируемость (modifiability), а также запланированные решения по доступности/ надежности (reliability), масштабированию для производительности (scalability/ performance) и пр.
- "лиц, принимающих решение", то есть людей/ организаций, которых в первую очередь интересуют бизнес-перспектива использования продукта или системы - возможность развития функциональности (те же modifiability), непрерывность бизнеса (за счет reliability и scalability)
- "остальных заинтересованных лиц", в том числе разных архитектурных комитетов со своими "техрадарами", специалистов ИБ со своими сертифицированными во ФСТЭК версиями и пр
Примечание:
Классификация заинтересованных лиц честно подрезана из Practioner's Approach to Development Enterpise Architecture Following the TOGAF ADM, который Open Group постоянно перемещает и то выставляет в открытый паблик по ссылке, то дает скачать только с отжиманиями через учетную запись.
Поэтому требования ко всем этим характеристикам качества надо честно собирать и анализировать - и в идеале с пониманием, как эти характеристики можно (или нельзя) обеспечить. Частая схема "копипастим требования из шаблона или другого ТЗ" не канает, так как вообще не отражает реальные потребности (за редким исключением ситуаций, когда эти требования заранее проработаны, хорошо классифицированы и действительно отражают необходимое и достаточное качество. Более того, те самые "заинтересованные стороны" чаще всего сами не очень представляют, что им надо, и формулировать требования им надо помогать. А для этого нужны и хорошие коммуникативные навыки, и хард скилы в этой области.
Ну и второй момент не такой очевидный. Так как "нефункциональные требования", строго говоря, не существуют в отрыве от "функциональных" и не несут ценности сами по себе, то и выявлять функциональные требования без связанных "нефункциональных" не сильно правильно. Конечно это не значит, что для каждого сценария и каждого ожидаемого поведения надо определять его доступность, производительность, возможность внесения изменений и прочее (хотя это было бы неплохо), но для многих ключевых поведенческих сценариев, особенно тех, которые определяют саму суть продукта (собственно это и есть архитектурно-значимые функциональные требования) - точно стоит. Кроме того есть пласт требований, которые исторически не подлежат "нормальной" классификации, например, требования к интеграции и требования к ИБ. С одной стороны это требования к функциям, с другой - к определенным качествам продукта.
Так что ношусь я с этими "нефункциональными требованиями" и пытаюсь внушить коллегам, командам и заказчикам, что "не всё так просто"
Вроде пока получается