Все статьи
Нефункциональные требования в SAFe®
Дата: 26.01.2026
Когда мы говорим о требованиях к системе, чаще всего вспоминаем функциональные: что она должна делать, как реагировать на действия пользователя. Но есть другая категория – нефункциональные требования или НФТ (Non-Functional Requirements, NFR). Они формируют архитектуру и влияют на все уровни бэклогов – от командного до портфеля. Разберем рекомендации SAFe® (Scaled AgileFramework®) по работе с НФТ.
В отличие от функциональных требований, которые описывают, как система реагирует на конкретные входные данные, нефункциональные требования описывают атрибуты системы, такие как:
- Производительность: насколько быстро система должна реагировать на запросы.
- Масштабируемость: насколько хорошо система может справиться с ростом числа пользователей или нагрузки.
- Безопасность: насколько хорошо система защищает от несанкционированного доступа и утечки данных.
- Удобство использования: насколько просто и интуитивно понятно пользоваться системой.
- Удобство обслуживания: насколько легко обновлять и перенастраивать систему.
Эти характеристики остаются стабильными. Их соблюдение должно регулярно проверяться – как часть критериев готовности (Definition of Done, DoD) каждой итерации, интервала планирования (Planning Interval, PI) или релиза. НФТ влияют на бэклоги всех уровней: команды, поезда (Agile Release Train, ART), поезда решения (Solution Train) и портфеля.
Содержание
Разбираем по полочкам
НФТ нужны для того, чтобы описывать не функции, а свойства системы: насколько она надёжна, безопасна, масштабируема, удобна и т.д. НФТ описывают не что делает система, а насколько хорошо она это делает.
В отличие от функциональных требований, которые обычно упаковываются в виде возможностей, фич и пользовательских историй и описывают, что система делает в ответ на различные входные данные, НФТ могут показаться более изощренными, но они также важны для системы. Если НФТ не соблюдаются, система может не соответствовать ожиданиям бизнеса, пользователей, требованиям рынка, нормативным актам или стандартам. А это уже серьёзные последствия: дополнительные расходы, отзыв продукта, риски для конфиденциальности и безопасности, юридические последствия и многое другое.
Ошибки в определении НФТ обходятся дорого. Если они заданы слишком жёстко, решение может оказаться слишком дорогим или вообще нежизнеспособным. Если же они оказались недостаточными, система может просто не справиться с задачами, ради которых она создавалась. Независимо от масштаба системы, умение гибко и поэтапно выявлять, формулировать и реализовывать НФТ – это одна из ключевых компетенций для Agile-команд.
Как НФТ влияют на бэклоги
НФТ связаны с бэклогами на всех уровнях SAFe, как показано на рисунке 1, но сами по себе не являются элементами бэклога. Элементы бэклога создаются и закрываются по мере их реализации, а НФТ – это постоянные ограничения, влияющие на архитектуру и разработку. Например, если задано требование: «Все продукты в составе решения должны поддерживать технологию единого входа (Single Sign-On,SSO) на основе SAML» — то сам функционал единого входа – это функциональное требование, а выбор технологии SAML (Security Assertion Markup Language) – это ограничение. Соответственно, любой новый элемент бэклога, связанный с аутентификацией, должен включать SAML в свои критерии приёмки.
Поскольку НФТ – это важные атрибуты решения, которое создаётся поездом и потоками создания ценности, они напрямую влияют на бэклоги команд, поезда и поезда решения. Иногда НФТ также требуются на уровне портфеля – особенно когда речь идёт о сквозных характеристиках, применяемых ко всем решениям, таких как соответствие нормативным требованиям. Agile-команды используют практики встроенного качества (Built-In Quality), чтобы ускорить тестирование НФТ и сделать его непрерывным. Команды включают соответствующие НФТ в свои критерии готовности, рассматривают их как ограничения при принятии архитектурных и технических решений, и берут на себя ответственность за их тестирование.
Как показано на рисунке 2, НФТ моделируются как ограничения для бэклога.
Два типа НФТ
Качественные характеристики
Ограничения проектирования
Помимо качественных характеристик системы, существует другой тип НФТ – ограничения проектирования, которые существенно влияют на архитектуру и реализацию. Они ограничивают свободу выбора при принятии технических решений.
Примеры таких ограничений:
- Дизайн системы должен использовать аппаратные компоненты только от утверждённых поставщиков (для киберфизических систем).
- Механизм единого входа должен использовать протокол SAML.
- Использование компонентов с открытым исходным кодом должно быть предварительно согласовано с юридическим отделом.
- Все пользовательские данные должны быть зашифрованы и храниться в корпоративной базе данных.
- Для разработки разрешены языки программирования Java, Python и JavaScript. Использование других языков требует предварительного одобрения.
Чем меньше таких ограничений, тем больше пространства для инноваций. Но иногда они критичны для безопасности, масштабируемости или других критически важных аспектов создаваемых решений.
Функциональные требования, нефункциональные требования и ограничения проектирования – вместе определяют объём и качество системы. Понимание как НФТ, так и проектных ограничений помогает командам принимать более взвешенные архитектурные решения, чтобы система соответствовала ожиданиям заинтересованных сторон и при этом укладывалась в заданные рамки.
Если вы дочитали до этого места, значит, вам интересен полезный контент о современных методах управления. Чтобы узнавать про новые статьи, видео и бесплатные мероприятия, вступайте в сообщество SAFe® Russia.
Формулировка нефункциональных требований
В SAFe НФТ обычно включаются в артефакт под названием Solution Intent, которой содержит как функциональные, так и нефункциональные требования и помогает определить, какие части решения уже четко зафиксированы, а где возможна гибкость с точки зрения экономической целесообразности.
Кроме того, Solution Intent может обеспечивать трассировку между НФТ, элементами бэклога, на которые они влияют, и тестами, подтверждающими их соблюдение. Это важно для понимания, какие части решения должны быть фиксированными, а где допустима гибкость (см. рисунок 4).
Как и другие требования, некоторые НФТ являются фиксированными и известны заранее (например: «аттракцион рассчитан на 12 человек»). Другие – переменные (например: «ускорение при максимальной нагрузке должно быть не менее x G») и уточняются по мере развития решения.
НФТ, как и любые требования, должны быть измеримыми. На рисунке 5 показан пример формулировки НФТ с использованием свойств, описанных ранее на рисунке 3.
- Шаг 1 – определить качественную характеристику: её название, шкалу и способ измерения.
- Шаг 2 – определить количественные параметры: текущее (базовое), целевое и пороговое, при котором результат считается неприемлемым.
На рисунке 5 приведён пример формулировки НФТ для системы автономного вождения, связанного с распознаванием ограничений скорости.
Сейчас пользователи вручную корректируют скорость примерно 1 раз за 10 миль. Новая функциональность должна снизить это значение до 1 раза на 100 миль, при этом в процессе реализации значение не должно превышать 1.5 раза на 10 миль (или 15 раз на 100 миль).
Критерии для корректной формулировки НФТ:
- Ограничение контекстом. НФТ должны быть привязаны к конкретной предметной области. Например, надёжность системы управления полётом самолёта должна быть значительно выше, чем у мультимедийной системы на борту.
- Независимость. НФТ должны быть независимыми друг от друга, чтобы их можно было тестировать отдельно.
- Гибкость в обсуждении. Возможность договариваться и корректировать НФТ – важный фактор экономической эффективности.
- Тестируемость. НФТ должны быть проверяемыми с помощью объективных метрик и тестов.
Как НФТ влияют на разработку
НФТ могут сильно повлиять на разработку и тестирование решения. Поэтому архитекторам и разработчикам следует формулировать их осторожно. Например, требование «доступность 99,999%» звучит впечатляюще, но увеличивает трудозатраты на разработку примерно в 10 раз по сравнению с «доступностью 99,98%». Те, кто задаёт такие требования, должны хорошо понимать их влияние.
Во многих случаях помогает подход вариативного проектирования (Set-Based Design). Он сохраняет гибкость, задавая НФТ как диапазон значений (например, от 99,98% до 99,999%). Команды исследуют возможные варианты реализации, получают дополнительную информацию и принимают более экономически обоснованные решения. Иногда высокая надёжность на уровне 99,999% действительно оправдана, а иногда выгоднее выбрать более низкий уровень и компенсировать его другими операционными мерами.
Экономическая модель решения (рисунок 6) помогает оценить НФТ с учётом компромиссов между затратами и другими факторами. Нужно учитывать влияние и на поставщиков – их опыт и ограничения также важны при определении НФТ.
НФТ могут потребовать дополнительной работы – сейчас или в будущем. Иногда их нужно реализовать сразу, а иногда можно идти поэтапно:
- Сразу – некоторые НФТ появляются как новые требования и требуют немедленной реализации. Например, изменения в нормативных актах могут обязать организацию реагировать в установленные сроки, иначе есть риск нарушить закон.
- Постепенно – в других случаях у команд есть выбор. Например, Agile-команды могут повышать производительность шаг за шагом, добавляя улучшения в каждую пользовательскую историю.
Важно дать команде время на несколько циклов обучения, чтобы определить оптимальный уровень НФТ. Структура поезда также может влиять на реализацию НФТ. Например, поезда, организованные вокруг архитектурных слоёв, столкнутся с трудностями при реализации и тестировании НФТ. Поезда, состоящие из команд, ориентированных на потоки ценности, смогут легче внедрять, тестировать и поддерживать НФТ. Применение практик Agile-архитектуры помогает развивать НФТ и сохранять гибкость по мере изменения требований.
Тестирование НФТ
Сторонник XP и соавтор Agile-манифеста Брайан Марик помог создать подход Agile-тестирование и матрицу тестирования, которая систематизирует виды тестов. Этот подход развили в книге Agile Testing и расширили до масштабирования в Agile Software Requirements. На рисунке 7 показана актуальная версия матрицы с рекомендациями, что и когда тестировать.
Квадрант 4 матрицы Agile-тестирования описывает тесты на соответствие системы нефункциональным требованиям. Для этого часто нужны специальные автоматизированные инструменты (например, инструменты для тестирования нагрузки и производительности) или внутренняя телеметрия решения.
Из-за большого объёма тестов и требований к инструментам тестирование НФТ может потребовать помощи системной команды. Любые изменения в системе могут нарушить соответствие НФТ, поэтому такие тесты нужно запускать постоянно или хотя бы при каждом значимом изменении. Чтобы обеспечить встроенное качество, команды должны автоматизировать тестирование НФТ, чтобы оно выполнялось непрерывно вместе с другими тестами или по требованию, когда это необходимо.
