Рабочий реестр NFR с измеримыми порогами, контекстом нагрузки и трассировкой. Классификация и теория качества — 02.03.01 Классификация требований (БТ, ФТ, НФТ) и 08.02 Нефункциональные требования (НФТ) — классификация и стандарты.
1. Назначение
Документ пишет системный аналитик; его читают архитектор, разработка, DevOps/SRE, QA, информационная безопасность, владелец продукта и compliance на этапах проектирования, реализации, нагрузочного тестирования и приёмки.
Шаблон закрывает четыре задачи:
- Измеримый контракт качества — каждое NFR содержит метрику, целевое значение, условия (нагрузка, объём данных, процентиль) и метод проверки; не «быстро» и «надёжно».
- Мост бизнес → эксплуатация — цели из BRD (штрафы за простой, time-to-market, регуляторика) переводятся в SLO/SLA, RTO/RPO, классы данных и пороги latency.
- Единый реестр для смежных артефактов — User Story, REST API, Kafka, ролевая модель и ADR ссылаются на NFR-ID, не дублируя числа в каждом документе.
- Точка трассировки и верификации — NFR → SRS → архитектура → load test / audit / мониторинг; основа для приёмки релиза и регрессии по качеству.
NFR описывает как система должна работать в эксплуатации, а не что она делает. Функциональное поведение — в User Story, Use Case, API spec; обоснование архитектурных компромиссов — в 10.01.13 Шаблон архитектурного решения (ADR).
2. Когда использовать
Подходит, если:
- формируете SRS или приложение к нему с разделом Non-Functional Requirements;
- нужны проверяемые цели по latency, throughput, uptime, RTO/RPO, retention, шифрованию;
- несколько команд и сервисов — нужен единый каталог NFR (canonical catalog), чтобы пороги не расходились между API-доками;
- BRD содержит бизнес-ограничения по простоям, штрафам, compliance (152-ФЗ, PCI-DSS, GDPR);
- перед freeze требований нужно согласовать SLO с DevOps/SRE и инструментами мониторинга.
Не подходит или требует дополнения, если:
- нужен только пошаговый сценарий «что делает система» — 10.01.01 Шаблон User Story / 10.01.02 Шаблон Use Case;
- детали контракта endpoint'ов (схема, коды ошибок) — 10.01.04 Шаблон спецификации REST API; NFR задаёт пороги и политики, API spec — контракт;
- выбор технологии, топологии, паттерна отказоустойчивости — 10.01.13 Шаблон архитектурного решения (ADR); NFR фиксирует цель, ADR — почему так достигаем;
- нужен полный threat model, capacity plan или compliance dossier — шаблон даёт якоря и трассировку, глубина — отдельные артефакты;
- внутренний инструмент без SLA и регуляторики — достаточно минимального набора (см. ниже); не разворачивайте реестр «для полноты ISO».
Минимальный набор для внутреннего инструмента без SLA — три строки каталога (метрика и верификация обязательны):
| NFR-ID | Категория | Формулировка | Метрика / цель | Условия | DoD | Верификация | Business driver | Trace |
|---|---|---|---|---|---|---|---|---|
NFR-LOG-001 | Maintainability | Correlation ID во всех логах сервиса | 100% запросов с X-Request-Id | Prod | Log sample review | Code review + smoke | Корпоративный стандарт observability | CON-TECH-001 |
NFR-BKP-001 | Reliability | Резервное копирование данных | RPO ≤ 24 h; backup daily | Prod, если хранятся данные | Restore drill 1×/квартал | Restore test | Политика ИТ | NFR-BKP-001 → runbook |
NFR-SEC-001 | Security | Базовая аутентификация | SSO или login+password; TLS 1.2+ | Prod | Config review pass | Pen test light / checklist | Нет enterprise IdM | RM-xxx или API-xxx |
Constraints по стеку — по необходимости.
Входные условия: границы scope согласованы (02.01.04 Определение границ решения (Scope Modelling)), business goals из BRD известны, ключевые сценарии и нагрузка хотя бы оценочно описаны.
Constraint vs goal: жёсткое ограничение (стек, локализация данных, бюджет latency) фиксируйте в разделе Constraints; целевые NFR можно пересмотреть по ADR. Смешение в одной записи мешает change control. Изменения CON-* проходят тот же контур версионирования, что и NFR (02.05.05 Жизненный цикл требования; 02.05.02 Управление изменениями (Change Control Board) при формальном CCB) — отдельный «статус quo» для constraints на review не оставляйте.
3. Структура документа
Скопируйте блок в Confluence, RM-инструмент или репозиторий документации. Поля с пометкой обяз. нужны для «готовности к разработке»; категории качества — чеклист полноты по ISO/IEC 25010 (08.02 Нефункциональные требования (НФТ) — классификация и стандарты).
3.0. Бланк для копирования
Минимальный старт: метаданные + одна эталонная строка каталога со всеми обязательными полями.
Метаданные (фрагмент):
| Поле | Значение |
|---|---|
| ID документа | NFR-{SERVICE}-001 |
| Название | {Product} — {Service} v{X.Y} |
| Версия / статус / дата | Draft · 2026-08-27 · {author} |
| Upstream | BRD-GOAL-xxx, SRS-xxx |
| Владелец NFR | PO + SRE lead |
| Окружения | dev (best effort); stage (нагрузка ×0.8, latency/uptime = prod); prod (контрактные SLO) |
Эталонная строка каталога:
| NFR-ID | Категория | Приоритет | Формулировка | Метрика / цель | Условия / сценарий | DoD | Метод верификации | Business driver | Trace links | Owner мониторинга |
|---|---|---|---|---|---|---|---|---|---|---|
NFR-PERF-001 | Performance | Must | … | p95 ≤ … ms | … RPS, … GB | 3 прогона load test pass | k6 на stage | BRD-GOAL-xxx | API-xxx, US-xxx, alert slo-… | SRE / slo-… |
Остальные разделы (§3.1–3.9) заполняйте по мере зрелости документа; для internal tool достаточно §3.0 + Constraints.
3.1. Метаданные
| Поле | Обяз. | Что писать |
|---|---|---|
| ID документа | да | Уникальный идентификатор, напр. NFR-PORTAL-001. Схема ID — 10.01.15 Шаблон матрицы трассировки. |
| Название | да | Продукт / сервис / релиз + «NFR», напр. «HR Portal — Leave Service v2.1». |
| Версия, статус, дата | да | Draft → Review → Approved; автор последнего изменения. |
| Продукт / сервис / релиз | да | Система, bounded context или набор микросервисов в scope. |
| Upstream: BRD / SRS / Vision | да | BRD-GOAL-xxx, SRS-xxx, ссылка на Vision & Scope — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD). |
| Downstream: ADR / API / мониторинг | нет | Ссылки на связанные ADR, OpenAPI, runbook, дашборды — без дублирования содержимого. |
| Владелец NFR (business / SRE) | да | Кто утверждает пороги и изменения. |
| Окружения | да | dev / stage / prod и правило коэффициентов (см. ниже). |
Правило коэффициентов между средами:
| Параметр | dev | stage | prod |
|---|---|---|---|
| Нагрузка load test | best effort или явный минимум | коэффициент к prod (напр. ×0.8 RPS / concurrent users) | контрактная нагрузка из §3.2 |
| Latency / uptime SLO | не контракт | равно prod (stage — pre-prod verification) | контракт |
| Security / compliance | ослабленные секреты допустимы | равно prod для проверяемых NFR-SEC / NFR-DATA | контракт |
Коэффициент нагрузки указывайте явно в метаданных (напр. «stage: 0.8× prod RPS»); не применяйте коэффициент к latency и uptime без ADR.
3.2. Scope и контекст
| Поле | Обяз. | Что писать |
|---|---|---|
| Scope (внутри) | да | Сервисы, каналы (web, mobile, API), интеграции, входящие в реестр. |
| Out of scope | да | Смежные системы, legacy без изменений в релизе, внутренние инструменты вендора. |
| Стейкхолдеры | нет | Кто задаёт SLA, кто проверяет compliance — 02.01.03 Анализ заинтересованных сторон (Stakeholder Map). |
| Сценарии нагрузки (верхний уровень) | да | Типовой день, пик (напр. Black Friday), batch-окно; согласовано с Use Case / BPMN при сквозных сценариях — 10.01.10 Шаблон описания Airflow-триггеров и автоматических процессов для SLA batch-джоб. |
3.3. Глоссарий, допущения и зависимости
| Поле | Обяз. | Что писать |
|---|---|---|
| Термины | нет | Единые определения: p95, RTO, error budget — 10.01.14 Шаблон глоссария и словаря данных. |
| Assumptions | да | Инфраструктура, смежные системы, объём данных «на старте»; без них NFR неоднозначны. |
| Dependencies | да | Внешние API, IdM, CDN, очереди — что должно выполнять свои SLO, чтобы наш NFR достижим — 02.05.01 Управление зависимостями между требованиями. |
| Platform NFR scope | нет* | Для каждой платформенной зависимости (K8s, shared DB, enterprise IdM): наследуем platform NFR, делегируем владельцу платформы или не дублируем — ссылка на platform catalog. *Обязательно при shared infrastructure. |
3.4. Каталог NFR (основной артефакт)
Каждая запись — одна проверяемая характеристика качества. Группируйте по категориям (performance, availability, scalability, security, usability, maintainability, compliance и др.) или в одной таблице с колонкой «Категория».
| Поле | Обяз. | Что писать |
|---|---|---|
| NFR-ID | да | Стабильный идентификатор, напр. NFR-PERF-001, NFR-SEC-012. |
| Категория | да | Домен качества: ISO 25010 / внутренняя матрица проекта — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты. |
| Формулировка | да | Однозначное «система / сервис shall…» без FR-поведения («логировать вход» — FR; «retention audit log 7 лет» — NFR). Для security допустимо «shall not» (запрет хранения секретов в логах, plaintext credentials). |
| Приоритет | да | MoSCoW или P0–P3 — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано). |
| Метрика и целевое значение | да | Число или диапазон: p95 ≤ 300 ms, uptime ≥ 99.9%, RPO ≤ 15 min, max payload 5 MB. |
| Условия / сценарий | да | Нагрузка: 500 concurrent users, 200 RPS, 10 GB данных; процентиль; AZ; окно измерения SLA (30 дней). Для scalability — горизонт роста (пользователи, объём данных) без перепроектирования. |
| Критерии приёмки / DoD | да | Что считается pass: «3 прогона load test подряд», «pen test без Critical», «дашборд без красных SLO 7 дней на stage». |
| Метод верификации | да | Load test (k6, JMeter), penetration test, UX-метрика, code review checklist, мониторинг prod — 02.04.01 Верификация и валидация (V&V); статическая проверка формулировок до кодирования — 08.03 Тестирование требований (статическое тестирование). |
| Business driver / источник | да | BRD-GOAL-xxx, регулятор, архитектурный стандарт, договор SLA. |
| Trace links | да | Минимум одна связь: SRS-REQ, US/UC, API operation, компонент, test case, alert name. |
| Owner мониторинга | нет | Команда и имя алерта / дашборда для эксплуатации после релиза. |
| Примечания / trade-off | нет | Компромисс с другим NFR; ссылка на ADR при конфликте. |
Правило качества записи NFR (quality gate формулировки, не SMART для целей BRD — см. 02.01.02 Цели, KPI и критерии успеха (SMART, GQM)): однозначная формулировка; измеримая метрика; достижимость согласована с архитектором / SRE (зависимости и error budget); поле business driver заполнено; окно SLA или горизонт измерения указаны. Качество формулировок до freeze — 02.04.03 Управление качеством требований. Не путать с 02.04.02 Критерии приёмки (Acceptance Criteria) для User Story — AC проверяют функцию, NFR — свойство системы в заданном контексте.
Правило RTO / RPO: одна пара RTO/RPO + один сценарий = одна строка каталога. Partial failure (отказ AZ, failover) и total disaster (полная потеря региона, restore from backup) — разные NFR-RES-* / NFR-DR-*. §3.7 не дублирует числа: только ссылки на ID строк и общие политики (backup frequency, correlation ID).
Scenario-based NFR: «При пике…», «При отказе AZ…» — согласуйте с 10.01.08 Шаблон сквозной фичи (BPMN-процесс) и 10.01.02 Шаблон Use Case для сквозных сценариев; достижимость multi-AZ — 03.06.01 Архитектурные паттерны распределённых систем.
Scalability / capacity: отдельная строка каталога, если заявлен рост нагрузки или данных на горизонте (напр. «до 2× RPS за 12 мес без смены архитектуры»).
Верификация по этапам (Agile):
| Когда | Что проверяем | Примеры NFR |
|---|---|---|
| Sprint / CI | config, unit-level, static review | TLS flags, log format, RBAC config vs RM |
| Stage / release candidate | load, chaos, integration SLO | p95, uptime на stage, DR drill |
| Prod / post-release | мониторинг, pen test, compliance audit | error budget, ASVS, erasure procedure |
DoD строки каталога должен соответствовать этапу: не требуйте load test в каждом sprint, если NFR помечен «release gate».
3.5. Ограничения (Constraints)
| Поле | Обяз. | Что писать |
|---|---|---|
| Constraint-ID | да | CON-001 — отдельная нумерация от NFR. |
| Тип | да | Технология, локализация данных, лицензия, бюджет, срок, организационное. |
| Формулировка | да | Жёсткое «должно / нельзя» без целевого улучшения. |
| Обоснование | да | Регулятор, корпоративный стандарт, контракт. |
| Impact | нет | На какие NFR и ADR влияет. |
Изменение constraint — тот же workflow, что у NFR: версия документа, impact на зависимые строки каталога, согласование владельца (02.05.05 Жизненный цикл требования).
3.6. Соответствие и безопасность — чеклист тем
Не отдельный обязательный раздел документа, а перечень тем, которые при ПДн / платёжных данных / ИБ обязаны быть закрыты строками каталога (
NFR-DATA-*,NFR-SEC-*). Нормы, OWASP, threat model — 08.06 Юридические и регуляторные требования РФ (PCI-DSS) и 08.07 Основы кибербезопасности для системного аналитика.
| Тема (чеклист) | Где фиксировать | Обязательность |
|---|---|---|
| Регуляторика (152-ФЗ, PCI-DSS, GDPR) | строка каталога, категория Compliance | * при ПДн / платежах |
| Классификация данных, маскирование PII в логах | NFR-DATA-* или NFR-SEC-* | * при ПДн |
| Шифрование in transit / at rest | NFR-SEC-*; детали алгоритмов — 08.07 | по классу данных |
| Audit / retention | NFR-SEC-*; связь с 10.01.11 Шаблон ролевой модели | для критичных операций |
| Удаление / erasure | NFR-DATA-* | * при ПДн |
| Security verification (ASVS, pen test scope) | метод верификации NFR-SEC-* | по политике ИБ |
§3.6 заполнять таблицей «тема → NFR-ID» или отметкой «покрыто каталогом §3.4» — отдельные пустые поля §3.6 без строк каталога не считаются готовностью к разработке.
3.7. Эксплуатация и observability
Раздел фиксирует эксплуатационные якоря документа (один раз на весь реестр). Числовые RTO/RPO — только в строках каталога (§3.4); здесь — ссылки и общие политики. Детали SRE — 08.01 Метрики и KPI процесса анализа.
| Поле | Обяз. | Что писать |
|---|---|---|
| Логирование / трассировка | да | Уровни, correlation ID — NFR-ID или ссылка на строку каталога. |
| Метрики и алерты | да | SLI → SLO → alert; error budget policy — см. Google SRE — Service Level Objectives. |
| NFR → мониторинг (mapping) | да* | Для каждого NFR-PERF / NFR-AVAIL — alert / SLI или «см. trace в строке». *Без mapping приёмка SLO не закрыта. |
| DR summary | да* | Ссылки на NFR-RES-*, NFR-DR-*, NFR-BKP-* — без повторения RTO/RPO. *Обязательно для business-critical. |
| Backup / DR runbook | нет | Частота, geo-redundancy — 07.06 CICD и конвейеры — влияние на требования; влияние деплоя — 05.04 DevOps и непрерывная поставка — влияние на анализ. |
| Деплой и rollback | нет | Zero-downtime, max downtime окна — если не в ADR. |
Обязательность мониторинга: §3.7 обязателен на уровне документа; для NFR-PERF и NFR-AVAIL trace link на alert / SLI в строке или запись в mapping §3.7 обязательны.
3.8. Риски и компромиссы
| Поле | Обяз. | Что писать |
|---|---|---|
| Конфликт NFR | нет | Напр. latency vs consistency; решение — ADR + пересмотр порога. |
| Риск недостижимости | нет | Вероятность, impact, mitigation — 08.05 Управление рисками на этапе анализа. |
| Assumption risk | нет | Что если dependency не выполнит SLO — 02.05.01 Управление зависимостями между требованиями. |
3.9. История изменений и согласование
| Поле | Обяз. | Что писать |
|---|---|---|
| Согласующие | да | Архитектор, SRE, ИБ, PO — подпись или статус Approved. |
| История изменений | да | Версия, дата, автор, суть; изменение порога = impact на тесты и мониторинг — 02.05.05 Жизненный цикл требования. |
3.10. Чеклист качества перед Review
- У каждого NFR — уникальный ID, категория, приоритет, измеримая метрика и условия нагрузки; все обяз. поля §3.4 заполнены (включая DoD, business driver, метод верификации).
- Нет формулировок «удобный», «быстрый», «надёжный» без чисел — 02.04.03 Управление качеством требований.
- FR не дублируются как NFR (логирование как функция vs retention как NFR).
- Cross-check REST: timeout, rate limit (10.01.04 Шаблон спецификации REST API) согласованы с NFR latency; SOAP — parity (10.01.05 Шаблон спецификации SOAP API).
- Cross-check БД: pool size, query timeout, retention на уровне СУБД (10.01.03 Шаблон спецификации БД сервиса) vs
NFR-PERF-*/NFR-DATA-*. - Rate limit / throughput / durability для messaging — 10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ) / 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ).
- Batch / Airflow: окно джоб и SLA согласованы с
NFR-PERF-*/ availability — 10.01.10 Шаблон описания Airflow-триггеров и автоматических процессов. - Security NFR не дублируют матрицу 10.01.11 Шаблон ролевой модели — OAuth/TLS в API spec; в RM — permissions; в NFR — session TTL, MFA, audit level.
- Scalability / capacity на горизонте роста — отдельная строка или явное «не в scope релиза».
- Platform NFR: наследование / делегирование задокументировано в §3.3.
- UX / accessibility (WCAG), если web/mobile UI в scope — NFR или ссылка на 10.01.09 Шаблон описания экранной формы и логики на FE.
- При ПДн: темы §3.6 покрыты строками каталога (erasure, retention, локализация).
- Resilience: partial (AZ) и total disaster — разные строки каталога; §3.7 ссылается на ID, не дублирует RTO/RPO.
- Constraints отделены от целевых NFR; изменения
CON-*в том же change control. - Trace link к BRD/SRS и минимум один downstream (test, API, alert).
- Цели по средам и коэффициент нагрузки stage явно указаны; latency/uptime stage = prod.
- DoD строк согласован с этапом верификации (sprint vs release gate).
- Trade-offs с ADR задокументированы.
- Review gate — 10.04 Чеклист аналитика перед стартом разработки.
4. Пример заполнения
Сокращённый фрагмент для HR Portal — сервис leave-service (данные условны).
Метаданные: NFR-HR-LEAVE-001 · HR Portal — Leave Service v2.1 · v1.0 · Approved · Upstream: BRD-GOAL-011, SRS-HR-LEAVE-v2 · Окружения: dev (best effort); stage (нагрузка ×0.8 к prod, latency/uptime = prod); prod.
Scope. REST API leave-service, web UI модуля Leave Management, интеграция с notification-service. Out of scope: Payroll, mobile app v1.
Assumptions. Kubernetes prod, 2 AZ; PostgreSQL primary + replica; notification-service SLA ≥ 99.5%; SSO корпоративный IdM.
Dependencies. notification-service — доставка email ≤ 5 min (отдельный NFR NFR-NOTIF-003). Platform NFR: K8s cluster SLA ≥ 99.95% — наследуем из platform catalog NFR-PLATFORM-K8S-001, не дублируем.
§3.6 (чеклист): покрыто строками NFR-DATA-001, NFR-DATA-002, NFR-SEC-001–003 — отдельная таблица §3.6 не дублируется.
Каталог NFR (фрагмент — все обязательные колонки):
| NFR-ID | Категория | Приор. | Формулировка | Метрика / цель | Условия / сценарий | DoD | Метод верификации | Business driver | Trace links | Owner мониторинга |
|---|---|---|---|---|---|---|---|---|---|---|
NFR-PERF-001 | Performance | Must | Время ответа API чтения списка заявок | p95 ≤ 300 ms, p99 ≤ 600 ms | 200 RPS, до 500k записей в БД, payload ≤ 50 KB | 3 прогона k6 pass на stage | Load test k6, release gate | BRD-GOAL-011 | API-LEAVE-001 op GET /requests, US-0247, alert slo-leave-latency | SRE / slo-leave-latency |
NFR-SCALE-001 | Scalability | Should | Рост нагрузки без перепроектирования | До 400 RPS при ≤ 1M записей, p95 ≤ 400 ms | Горизонт 12 мес | Capacity review signed | Capacity review + load test | BRD-GOAL-011 | ADR ADR-LEAVE-014 | — |
NFR-AVAIL-001 | Availability | Must | Доступность leave-service | Uptime ≥ 99.9% / календарный месяц | Искл. maintenance ≤ 4 h/мес | Error budget не исчерпан 30 дней prod | Мониторинг prod | BRD-GOAL-011, договор SLA | alert slo-leave-uptime | SRE / slo-leave-uptime |
NFR-RES-001 | Resilience | Must | Failover при отказе одной AZ | RTO ≤ 15 min; in-flight с idempotency-key не теряются | Partial: отказ 1 AZ в prod | Chaos test pass | Chaos test / failover drill | BRD-GOAL-011 | UC-LEAVE-003, NFR-AVAIL-001 | SRE |
NFR-DR-001 | Reliability | Must | Восстановление после полной потери региона | RTO ≤ 1 h, RPO ≤ 15 min | Total disaster; restore from backup | Restore drill 1×/полугодие pass | DR drill, release gate | BRD-GOAL-011, политика ИТ | runbook RB-LEAVE-DR, NFR-BKP-001 | SRE |
NFR-SEC-001 | Security | Must | Аутентификация API | OAuth2 Bearer; TLS 1.2+ | Все endpoints prod | Pen test без Critical | Pen test + config review | Политика ИБ | API-LEAVE-001 security scheme | SecOps |
NFR-SEC-002 | Security | Must | Audit критичных операций | 100% approve/reject/delete с userId, timestamp, requestId | Prod | TC-AUDIT-005 pass | Log review + test | 152-ФЗ audit trail | RM-HR-LEAVE-001, perm leave_request:approve | SecOps |
NFR-DATA-001 | Compliance | Must | Хранение ПДн | DC ru-central only; audit retention 7 лет | 152-ФЗ | Compliance checklist signed | Compliance review | BRD-GOAL-011, CON-DATA-001 | CON-DATA-001 | Compliance |
NFR-DATA-002 | Compliance | Must | Удаление ПДн по запросу | Полное удаление из prod ≤ 30 дней | Запрос субъекта ПДн | Procedure test pass | Procedure test | 152-ФЗ erasure | NFR-DATA-001 | Compliance |
Примечание к trace: спецификация REST — API-LEAVE-001 (10.01.04 Шаблон спецификации REST API); ролевая модель — RM-HR-LEAVE-001 (10.01.11 Шаблон ролевой модели).
Constraints:
| ID | Формулировка | Источник |
|---|---|---|
CON-DATA-001 | Персональные данные сотрудников не выходят за контур РФ | Политика ИБ, 152-ФЗ |
CON-TECH-001 | Стек: Java 17, PostgreSQL 15 — без смены в релизе v2.1 | Корпоративный стандарт |
Эксплуатация (§3.7): correlation ID X-Request-Id — NFR-LOG-001 (не показан); DR summary: partial → NFR-RES-001, total → NFR-DR-001 + backup NFR-BKP-001; mapping: NFR-PERF-001 → slo-leave-latency, NFR-AVAIL-001 → slo-leave-uptime.
Trade-off: NFR-PERF-001 vs полнотекстовый поиск — отложено; ADR ADR-LEAVE-014 (read replica + cache).
Трассировка: BRD-GOAL-011 → NFR-PERF-001…NFR-DATA-002 (первичные ID) → SRS-NFR-012–021 (1:1) → API-LEAVE-001, RM-HR-LEAVE-001 → load LT-LEAVE-002, pen test PT-2026-Q1.
5. Связанные артефакты
На входе (upstream)
| Артефакт | Связь |
|---|---|
| Vision & Scope, BRD | Business goals, штрафы за простой, регуляторика, UX-ожидания — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD) |
| SRS (черновик FR) | NFR дополняет FR; может быть приложением §Non-Functional Requirements |
| 10.01.08 Шаблон сквозной фичи (BPMN-процесс) | Сквозные сценарии нагрузки и RTO для процесса |
| 10.01.02 Шаблон Use Case | Сценарии для scenario-based NFR (пик, отказ) |
| 10.01.13 Шаблон архитектурного решения (ADR) | Достижимость NFR, trade-offs |
| 10.01.14 Шаблон глоссария и словаря данных | Термины метрик и классов данных |
| Stakeholder Map | Кто владелец SLA и compliance — 02.01.03 Анализ заинтересованных сторон (Stakeholder Map) |
На выходе (downstream)
| Артефакт | Когда создавать / обновлять |
|---|---|
| SRS (NFR section) | Формальные REQ-ID из каталога NFR — см. правило ниже |
| 10.01.03 Шаблон спецификации БД сервиса | Pool, query timeout, индексы под latency; retention vs NFR-DATA-* |
| 10.01.04 Шаблон спецификации REST API / 10.01.05 Шаблон спецификации SOAP API | Timeout, rate limit, max payload, idempotency, security scheme — ссылка на NFR-ID |
| 10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ) / 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ) | Throughput, lag, durability, DLQ — как NFR с метриками |
| 10.01.10 Шаблон описания Airflow-триггеров и автоматических процессов | Batch-окно, SLA джоб, retry vs availability NFR |
| 10.01.11 Шаблон ролевой модели | Permissions и критичные операции; security NFR: session TTL, MFA — не дублировать матрицу ролей |
| 10.01.09 Шаблон описания экранной формы и логики на FE | UX NFR: время отклика UI, accessibility — по ссылке |
| 10.01.01 Шаблон User Story | В story — только NFR-xxx и story-specific отклонения, не метрики в AC |
| 10.01.13 Шаблон архитектурного решения (ADR) | При конфликте NFR или выборе паттерна для достижения SLO |
| 10.01.15 Шаблон матрицы трассировки | BRD goal → NFR → FR/API → test → мониторинг |
| Load test plan / runbook | Метод верификации из каталога NFR |
Правило NFR-ID ↔ SRS-REQ-ID: NFR-ID — первичный идентификатор в реестре и 10.01.15 Шаблон матрицы трассировки; change control и diff ведутся по NFR-ID. В SRS допустимо: 1:1 (SRS-NFR-012 = NFR-PERF-001), 1:N (один REQ перечисляет несколько NFR-ID в trace) или приложение — полный каталог NFR без дублирования формулировок в теле SRS. Не создавайте REQ без обратной связи на NFR-ID. Атрибуты quality requirements в IEEE/ISO 29148 (формулировка, критерии проверки, источник) соответствуют полям строки каталога — см. 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).
Типичный порядок работы аналитика
- Цели и ограничения из BRD → черновик категорий NFR (чеклист ISO 25010).
- Сценарии нагрузки с архитектором / SRE → метрики и пороги.
- Заполнить каталог NFR; отделить Constraints; зафиксировать platform NFR scope; пройти чеклист §3.6 строками каталога.
- Cross-check с API, БД, messaging, batch, ролевой моделью; согласовать с ИБ compliance-NFR.
- Трассировка в SRS и 10.01.15 Шаблон матрицы трассировки; привязка тестов и алертов (§3.7 mapping).
- Review gate перед freeze (10.04 Чеклист аналитика перед стартом разработки); изменения порогов — версионирование и impact analysis (02.05.05 Жизненный цикл требования; 02.05.02 Управление изменениями (Change Control Board) при формальном CCB).
6. Связи с другими разделами базы
Теория и поток артефактов — §5. Дополнительно (не перечислено там как артефакты):
- Классификация БТ, ФТ и НФТ — 02.03.01 Классификация требований (БТ, ФТ, НФТ)
- Таксономия качества, ISO 25010 — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты
- Архитектурные паттерны availability/resilience — 03.06.01 Архитектурные паттерны распределённых систем
- Agile: что проверять в sprint vs на release — 05.02 Scrum и Kanban (аналитик в Agile)
- Регуляторика и кибербезопасность (глубина тем) — 08.06 Юридические и регуляторные требования РФ (PCI-DSS), 08.07 Основы кибербезопасности для системного аналитика
7. Источники и дополнительные материалы
Книги и стандарты
- ISO/IEC 25010 — Systems and software engineering — System and software quality models (таксономия характеристик качества) — https://www.iso.org/standard/35733.html
- ISO/IEC 25000 (SQuaRE) — обзор семейства стандартов качества, зеркало при недоступности iso.org — https://iso25000.info/index.php/en/iso-25000-standards
- IEEE 29148-2018 — Systems and software engineering — Life cycle processes — Requirements engineering — https://standards.ieee.org/standard/29148-2018.html
- ГОСТ Р ISO/IEC 25010-2015 — модель качества ПО (русскоязычный контекст) — https://docs.cntd.ru/document/1200100114
- IREB — CPRE Syllabus (качественные и нефункциональные требования) — https://www.ireb.org/en/cpre/
- IIBA — Business Analysis Body of Knowledge (BABOK) — non-functional / solution requirements — https://www.iiba.org/standards-and-resources/business-analysis-body-of-knowledge-babok-guide/
- NIST SP 800-53 Rev. 5 — Security and Privacy Controls (источник compliance-NFR) — https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
Статьи и практики
- Atlassian — Non-functional requirements (практика формулировок) — https://www.atlassian.com/agile/project-management/non-functional-requirements
- Google SRE — Service Level Objectives (связь NFR ↔ SLO / error budget) — https://sre.google/sre-book/service-level-objectives/
Спецификации
- OWASP — Application Security Verification Standard (ASVS) (NFR для security verification) — https://owasp.org/www-project-application-security-verification-standard/
- W3C — Web Content Accessibility Guidelines (WCAG) 2.x (UX/accessibility NFR) — https://www.w3.org/WAI/standards-guidelines/wcag/
Примечание: страницы iso.org могут отдавать 403 автоматическим проверкам, но открываться в браузере; перед публикацией в vault перепроверьте актуальность URL.