Нефункциональные требования (non-functional requirements, NFR) описывают как система должна работать — качество, ограничения и условия предоставления функциональности. Общее место НФТ среди бизнес-, функциональных и нефункциональных требований — в 02.03.01 Классификация требований (БТ, ФТ, НФТ); здесь фокус на таксономиях качества, нормативке и правилах формулировки, которые аналитик применяет при фиксации НФТ в спецификации.

1. Суть темы

НФТ пронизывают архитектуру, инфраструктуру и приёмку: без измеримых критериев «быстрая» и «надёжная» система не проверяется объективно. Хорошее НФТ — конкретное, достижимое, приоритизированное и трассируемое к бизнес-целям (→ 02.01.02 Цели, KPI и критерии успеха (SMART, GQM), 02.03.04 Трассировка требований (концепция)). Приоритизация конфликтующих НФТ — через 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано) и quality scenarios (см. §3).

1.1 Граница: НФТ, ограничения проекта и допущения

Три типа записей часто смешивают в одном разделе SRS — разнесите их явно:

ТипСутьПримерКуда в артефакте
НФТ (quality requirement)Измеримое качество поведения системы«95-й перцентиль GET /orders ≤ 300 мс при 500 RPS»Раздел quality / NFR в SRS
Ограничение проекта (design constraint)Нерушимое решение заказчика или контракта, не про «качество»«Только PostgreSQL 15+», «Размещение только в облаке X»Раздел constraints / FURPS+ «+»
Допущение (assumption)Непроверенное предположение, от которого зависит план«Пиковая нагрузка не превышает 10 000 одновременных пользователей»Реестр assumptions; при подтверждении — перенос в НФТ или constraint

Правило: если формулировку можно проверить нагрузочным тестом, pen-test или аудитом логов — это НФТ. Если это запрет на выбор технологии без метрики качества — constraint. Если команда ещё не знает, верно ли утверждение — assumption до валидации (→ 02.04.01 Верификация и валидация (V&V)). SLA контракта с заказчиком обычно декомпозируется: числовые цели → НФТ, юридические рамки → constraints и compliance-NFR (→ 08.06 Юридические и регуляторные требования РФ (PCI-DSS)).

1.2 Функциональная пригодность vs функциональные требования

ISO/IEC 25010 выделяет функциональную пригодность (functional suitability) — полноту, корректность и уместность реализации функций. Это метрика качества покрытия, а не дублирование ФТ:

  • ФТ — что система делает («Пользователь может отменить заказ до отгрузки»).
  • Functional suitability как НФТ — насколько хорошо реализовано («100 % сценариев из scope-документа покрыты ФТ с трассировкой на бизнес-правила»).

Это NFR на полноту спецификации — контрактный критерий «в SRS описано всё из scope», а не замена 02.03.04 Трассировка требований (концепция) или процесса покрытия из 02.04.03 Управление качеством требований. Матрица трассировки показывает связи; suitability-метрика задаёт порог полноты описания.

В SRS ФТ живут в функциональном разделе; suitability-метрики — в quality requirements, если заказчик требует формальной оценки полноты (типично для контрактных и регулируемых проектов).

2. Ключевые понятия

2.1 Модель ISO/IEC 25010:2011

Основа современной классификации качества продукта (наследник ISO 9126). Восемь характеристик с подхарактеристиками:

mindmap
  root((Качество продукта ISO 25010))
    Функциональная пригодность
      Полнота
      Корректность
      Целесообразность
    Производительность
      Время отклика
      Пропускная способность
      Использование ресурсов
      Масштабируемость
    Совместимость
      Сосуществование
      Интероперабельность
    Удобство использования
      Понятность
      Обучаемость
      Управляемость
      Защита от ошибок
      Эстетика
      Доступность интерфейса
    Надёжность
      Зрелость
      Отказоустойчивость
      Восстанавливаемость
      Доступность сервиса
    Безопасность
      Конфиденциальность
      Целостность
      Неотказуемость
      Подотчётность
      Аутентичность
    Сопровождаемость
      Модульность
      Переиспользуемость
      Анализируемость
      Изменяемость
      Тестируемость
    Переносимость
      Адаптируемость
      Устанавливаемость
      Замещаемость

Рис. Модель качества продукта по ISO 25010.

Редакции стандарта. В контрактах и аудитах встречаются обе редакции: ISO/IEC 25010:2011 (классическая восьмиблочная модель выше) и ISO/IEC 25010:2023 (переработанная структура характеристик). На проекте зафиксируйте одну редакцию в глоссарии; при расхождении с заказчиком — сверка через 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148). В этой базе таксономия приведена по :2011 как наиболее узнаваемой в SRS и FURPS-маппинге.

Омоним «доступность» — обязательное разведение терминов

В русском языке оба английских термина часто переводят как «доступность». В спецификации всегда указывайте английский термин в скобках:

Русская формулировкаEnglishХарактеристика ISO 25010Пример
Доступность сервисаAvailabilityНадёжностьUptime 99,95 % в месяц
Доступность интерфейсаAccessibilityУдобство использованияСоответствие WCAG 2.1 AA

ID требования и категория в шаблоне должны отражать различие (например, NFR-REL-AVAIL-01 vs NFR-USA-ACCESS-01) — см. 10.01.12 Шаблон нефункциональных требований (NFR).

Краткий обзор характеристик с примерами

Производительность (performance efficiency): время отклика, пропускная способность, использование ресурсов, масштабируемость (elastic scaling, деградация при росте нагрузки). Примеры: «95-й перцентиль GET /orders ≤ 300 мс»; «авто-масштабирование от 2 до 20 реплик при CPU > 70 % в течение 5 мин». Инфраструктурные следствия — 03.06.03 Rate Limiting — управление пропускной способностью, 03.06.04 Стратегии балансировки нагрузки.

Совместимость (compatibility): сосуществование и интероперабельность. Пример: «API соответствует профилю FHIR R4» — детали контрактов в 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf), 03.01.04 Интерфейсы и интеграционные взаимодействия.

Удобство использования (usability): понятность, защита от ошибок, accessibility (WCAG). Связь с 02.02.04 Прототипирование и UI/UX-исследования.

Надёжность (reliability): availability (uptime), отказоустойчивость, восстанавливаемость (RTO/RPO). Архитектурные следствия — 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая), 03.06.01 Архитектурные паттерны распределённых систем.

Безопасность (security): подхарактеристики 25010 — confidentiality, integrity, non-repudiation, accountability, authenticity. Формулируйте через эти термины, а не разрозненный список «аутентификация / аудит»:

  • Confidentiality: HTTPS, TLS 1.2+, шифрование ПДн.
  • Integrity: проверка подписи (ГОСТ Р 34.10-2012).
  • Authenticity / accountability: OAuth 2.0, аудит действий с фиксацией субъекта и времени.
  • Non-repudiation: неотказуемость критичных транзакций.

Детали OWASP, threat modeling, SAST/DAST — 08.07 Основы кибербезопасности для системного аналитика; регуляторика — 08.06 Юридические и регуляторные требования РФ (PCI-DSS).

Сопровождаемость (maintainability) и эксплуатация (operability): модульность, анализируемость (логи, трассировка), тестируемость. Observability — метрики, алерты, SLI/SLO, структурированное логирование («локализация инцидента по логам ≤ 15 мин»). Operability — то, что ops-команда делает с системой в проде, и часто выпадает из SRS:

  • Окна деплоя: «релизы prod — вторник/четверг 02:00–04:00 MSK, без простоя > 5 мин».
  • RTO процедур backup/restore vs RTO сервиса: восстановление БД из бэкапа ≤ 4 ч — отдельное NFR от «сервис доступен 99,9 %»; иначе DR-план не сходится с SLA.
  • Runbook: «инцидент P1 — runbook в Confluence, время первого действия on-call ≤ 15 мин».

Связь с 07.06 CICD и конвейеры — влияние на требования.

Переносимость (portability): адаптируемость к платформам, замещаемость компонентов.

Privacy / compliance NFR (часто выделяют отдельным подразделом): retention персональных данных, локализация хранения (152-ФЗ), право на удаление — рядом с security, не вместо него.

2.2 FURPS+ и согласование с ISO 25010

FURPS+ — практичная схема группировки в SRS:

FURPS+Соответствие ISO 25010Примечание для аналитика
F — FunctionalityFunctional suitability + часть SecurityВ FURPS security иногда кладут как «функцию защиты»
U — UsabilityUsability (включая Accessibility)
R — ReliabilityReliability (Availability)Не путать с Accessibility
P — PerformancePerformance efficiencyВключая масштабируемость
S — SupportabilityMaintainability + operabilityObservability, runbook, окна деплоя
+ constraintsНе НФТDesign constraints, интерфейсы, физические ограничения

Правило разнесения security: в проектах на ISO 25010 все требования безопасности фиксируйте в категории Security, даже если FURPS-шаблон заказчика предлагает subsection в Functionality. Дублирование одного требования в F и S запрещено — выберите одну таксономию в глоссарии проекта. OWASP ASVS — чек-лист для детализации security-NFR, не замена категории.

ISO/IEC 9126 — legacy-модель в старых документах. При миграции на 25010 сверяйте термины построчно:

ISO 9126 (1991)ISO/IEC 25010:2011
EfficiencyPerformance efficiency
MaintainabilityMaintainability
PortabilityPortability
UsabilityUsability
ReliabilityReliability
FunctionalityFunctional suitability
—Compatibility, Security (выделены отдельно)

Полные таблицы соответствия — в 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).

2.3 Стандарты документирования

СтандартРоль сегодняСвязь с НФТ
ISO/IEC/IEEE 29148:2018Актуальная практика SRS; наследует подход IEEE 830Разделяет stakeholder requirements (зачем) и system requirements (что система должна обеспечить); quality requirements — подмножество system requirements с измеримыми критериями и методами verification (→ 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148))
IEEE 830-1998Исторический шаблон SRS; ещё встречается в контрактахРаздел 3.4 «Non-functional requirements» — ориентир для legacy
ISO/IEC 25030:2019Руководство по quality requirements на базе 25010Связка категории → измеримый критерий
Volere, BABOK v3 (гл. 9.5)Чек-листы и процесс elicitationПроцесс выявления — 02.02.01 Интервьюирование и анкетирование и соседние; формат артефакта — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD), 02.03.03 Спецификация требований (SRS, Use Case, User Story)

3. Как применяется в работе аналитика

3.1 Выявление и формулировка

Чек-лист категорий и полей записи — в 10.01.12 Шаблон нефункциональных требований (NFR). Выявление значений: интервью с заказчиком и ops (→ 02.02.01 Интервьюирование и анкетирование), сессии по категориям 25010/FURPS+ (→ 02.02.05 Мозговой штурм и креативные техники). Минимальный набор действий:

  1. Пройти категории ISO 25010 или FURPS+ с заказчиком и ops-командой.
  2. Для каждого НФТ задать измеримый критерий, метод верификации и владельца.
  3. Зафиксировать assumptions, которые нужно подтвердить до baseline.
  4. Связать риски с целевыми quality attributes: «потери X ₽/ч простоя» → целевой availability (→ 08.05 Управление рисками на этапе анализа).

Пример вопросов по категориям: пиковая нагрузка и перцентили (performance); бизнес-потери за час простоя (availability); WCAG vs мобильный контекст (accessibility); retention ПДн (privacy); окна деплоя и RTO restore (operability).

Для числовых критериев вместо «быстро/надёжно» допустим Planguage (Tom Gilb) — шаблон {Scale} {Meter} {Must/Plan} {Past/Now}: «Response time {95-й перцентиль} {≤ 300 мс при 500 RPS} {Must} {—}». Альтернатива свободному тексту при контрактной строгости; детали — в источниках (Wiegers/Beatty).

3.2 Quality scenarios и компромиссы

При конфликте НФТ (performance vs security, availability vs cost) используйте quality scenarios — краткий сценарий «stimulus → response → measure» (подход ATAM/Bass). Utility tree — иерархия: характеристика → подкатегория → сценарий → приоритет (H/M/L). Это дополняет MoSCoW: показывает, какой quality attribute жертвуем при trade-off, а не только «Must vs Should». Взаимные ограничения между NFR-ID фиксируйте в реестре зависимостей (→ 02.05.01 Управление зависимостями между требованиями).

Пример quality scenario (конфликт latency vs encryption):

ЭлементЗначение
Stimulus1000 одновременных запросов GET /orders с JWT и TLS
ResponseСервис обрабатывает запросы без отказа; payload at rest зашифрован AES-256
Measure95-й перцентиль ≤ 400 мс (не 300 мс без шифрования); throughput ≥ 800 RPS
Приоритет в utility treeSecurity / Confidentiality — H; Performance — M

Сценарий попадает в utility tree под Performance → Latency и Security → Confidentiality; при пересмотре архитектуры команда видит, что жертва latency допустима до 400 мс, но не до 800 мс.

3.3 НФТ → архитектура → проверка

НФТ — главный вход для архитектурно значимых требований (ASR): availability 99,99 % → мультизона; шифрование at rest → выбор облачного KMS. Аналитик передаёт измеримые НФТ архитектору; паттерны реализации — не в этой статье (→ 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая)). Решения фиксируйте в ADR с трассировкой на NFR-ID (→ 10.01.13 Шаблон архитектурного решения (ADR)).

Два уровня проверки — не смешивайте:

УровеньКогдаЧто проверяетГде в базе
Статика формулировокДо разработки, на рецензии SRSИзмеримость, категория, отсутствие ambiguity08.03 Тестирование требований (статическое тестирование), 08.04 Рецензирование и инспекции (техники Фейгана)
Динамическая приёмкаПосле реализацииСистема meets критерий NFR02.04.01 Верификация и валидация (V&V), 02.04.02 Критерии приёмки (Acceptance Criteria)

Краткая карта «категория → тип исполнительной проверки»:

КатегорияПроверка
Performance / scalabilityНагрузочное тестирование, профилирование
SecurityASVS-чек-лист, pen-test, SAST/DAST в конвейере
Reliability / availabilityFailover drills, chaos-тесты
Usability / accessibilityЮзабилити-тесты, аудит WCAG
Observability / operabilityПроверка метрик, алертов, SLO; прогон runbook на staging

Аналитик участвует в приёмке: сверка результатов исполнительных тестов с исходными критериями NFR.

3.4 Agile и гибрид

НФТ оформляют как отдельные NFR-stories, критерии в функциональных историях или пункты Definition of Done («95-й перцентиль новых эндпоинтов ≤ 500 мс»). Формат зависит от методологии — см. 05.02 Scrum и Kanban (аналитик в Agile), 04.02 Пользовательские истории (User Stories) и Job Stories; строгость критериев не снижается.

3.5 Жизненный цикл и изменение НФТ

SLA, профиль нагрузки и регуляторика меняются — НФТ подлежат тому же управлению изменениями, что и ФТ (→ 02.05.05 Жизненный цикл требования, 02.05.02 Управление приоритетами в условиях изменчивости). При изменении NFR:

  1. Пересмотрите затронутые ASR и quality scenarios.
  2. Обновите или создайте ADR для архитектурных следствий (→ 10.01.13 Шаблон архитектурного решения (ADR)).
  3. Проверьте зависимости между NFR-ID (→ 02.05.01 Управление зависимостями между требованиями).

3.6 Пример записи

ID: NFR-SEC-01
Категория: Security / Confidentiality
Описание: Персональные данные между клиентом и сервером передаются только по шифрованному каналу.
Критерий: HTTPS, TLS ≥ 1.2; запрет алгоритмов с ключом < 128 бит; HTTP → 301 на HTTPS.
Приоритет: Must (MoSCoW)
Связи: F-LOGIN-01; BR-COMPL-01 (152-ФЗ)
Верификация: автотест редиректа в CI; инспекция конфигурации балансировщика

Полный набор полей — в 10.01.12 Шаблон нефункциональных требований (NFR).

3.7 Метрики качества самих НФТ

Для процесса анализа (→ 08.01 Метрики и KPI процесса анализа) имеет смысл отслеживать:

  • доля NFR с числовым критерием и методом верификации;
  • покрытие чек-листа ISO 25010 по категориям проекта;
  • количество дефектов «неизмеримое NFR» на рецензии (→ 02.04.03 Управление качеством требований).

4. Типовые ошибки и ограничения

  • Смешение availability и accessibility в одной категории «доступность» — ломает трассировку и тест-план.
  • Constraints в разделе NFR («только PostgreSQL») — невозможно верифицировать как quality attribute.
  • Дублирование security между FURPS-F и ISO Security — противоречивые приоритеты.
  • Functional suitability в функциональном разделе без явной метрики — размывает границу с ФТ.
  • НФТ без перцентиля, окна измерения и профиля нагрузки — «быстро» не тестируется.
  • Игнорирование observability и operability — система «соответствует uptime», но инциденты не локализуются, restore не укладывается в RTO.
  • Отсутствие quality scenarios при trade-off — команда спорит о MoSCoW, не понимая, какой атрибут качества проигрывает.
  • Копирование чужих SLA без расчёта стоимости (99,99 % vs 99,9 % — разный класс архитектуры).
  • Privacy только ссылкой на закон без retention, маскирования и локализации в NFR.
  • Изменение NFR без пересмотра ADR — архитектура расходится со спецификацией.

Одна таксономия (25010 или FURPS+ с явной маппинг-таблицей) на проект лучше, чем смешение двух без глоссария.

Связи с другими разделами базы

Источники и дополнительные материалы

Стандарты

Книги

  • Карл Вигерс, Джой Битти. «Разработка требований к программному обеспечению» (3-е изд.) — гл. 11 «Нефункциональные требования»; Planguage для quality attributes.
  • Сюзанна Робертсон, Джеймс Робертсон. «Управление требованиями» (Mastering the Requirements Process) — Volere и НФТ.
  • Лен Басс, Пол Клементс, Рик Казман. «Архитектура программного обеспечения на практике» (3-е изд.) — quality scenarios, utility tree, ASR.

Статьи