Чек-лист нефункциональных требований: 14 категорий (2026)

Почему Фора Софт написала этот плейбук

Фора Софт выпустила более 625 проектов с 2005 года. Мы писали, обсуждали с клиентами и проверяли спецификации НФТ для BrainCert (мультиарендная платформа e-learning с годовой выручкой 750 млн ₽), CirrusMED (телемедицина уровня HIPAA), VALT (e-discovery для юристов с цепочкой хранения доказательств), TransLinguist (NHS UK, перевод с задержкой меньше секунды), StreamLayer (NBC, CBS, Red Bull) и EyeBuild (солнечные системы видеонаблюдения). У каждого проекта свой профиль НФТ; паттерны в этом руководстве — из этих внедрений.

Мы разбираем 80+ оценок подрядчиков в год, и главный источник промахов в прогнозе бюджета — пропуск НФТ. Подрядчик считает фичи, заказчик подписывает, на шестом месяце команда узнаёт, что нужны MFA, аудит-логи, размещение данных в ЕС по GDPR и SLA на 99,95 % — и бюджет взрывается. Этот плейбук — внутренняя инструкция, которой мы пользуемся, чтобы такого не случалось.

Если вы CTO и пишете RFP, нетехнический основатель, оценивающий предложения, или закупщик, ведущий выбор подрядчика — это руководство расскажет, какие 14 категорий НФТ описывать, как переводить прилагательные в числа, что изменилось в 2026 (HIPAA, EU AI Act, доступность) и как зашить НФТ в контракт так, чтобы подрядчик обязан был их выполнить.

Почему большинство проектов проваливается на нефункциональных требованиях

По данным PMI, 28 % промахов в прогнозе бюджета приходится на неточные оценки. Исследование IT-проектов McKinsey 2020 года показало, что крупные проекты в среднем вылезают за бюджет на 45 %. Обе цифры сходятся к одной первопричине: оценивали функционал, а сдавали функционал плюс все НФТ, которые с ним приходят.

В нашем портфеле из 80 ежегодных оценок четыре самых частых пропуска НФТ выглядят так:

1. Требования комплаенса всплывают по ходу разработки. «Нам понадобится отчёт SOC 2 до первого корпоративного клиента» — это слышишь на четвёртом месяце. Архитектура под это не проектировалась. Дорабатывать комплаенс задним числом — в 3 раза дороже, чем заложить его сразу.

2. Обещания по производительности превращаются в реальные числа слишком поздно. В брифе написано «чат в реальном времени». В реализации сообщения доставляются за 4 секунды на медленном соединении, потому что никто не задал p95-задержку.

3. Прогнозы по нагрузке ошибаются на порядок. Сделали под «несколько тысяч пользователей». Продукт стрельнул, в день запуска заходит 50 000 пользователей, база падает.

4. Доступность добавляют в панике. Аудит доступности перед запуском находит 200+ нарушений WCAG, доработка занимает 6–10 недель внепланово, а в части юрисдикций ещё и грозит исками о дискриминации.

Что такое нефункциональные требования и чем они отличаются от функциональных

Функциональное требование описывает, что делает система. НФТ — насколько хорошо, при каких условиях, какой ценой и как это будет проверено. «Пациент может записаться на видеоконсультацию» — функциональное. «Запись завершается менее чем за 3 секунды end-to-end на p95 при 1 000 одновременных пользователей» — это уже парное к нему НФТ.

Модель качества ISO 25010 формализует НФТ в 8 категорий верхнего уровня и 31 подкатегорию. Она исчерпывающая и академичная. На практике мы используем более плоскую модель из 14 категорий, которая ложится на реальные инженерные компромиссы и пункты контракта. Эти 14 категорий — ниже.

Три свойства, которые должны быть у любого НФТ. Число (или перечислимый порог), метод измерения и способ проверки. «Система должна быть быстрой» — это пожелание. «Время отклика API на p95 менее 250 мс, измеряется нагрузочным тестом k6 на staging при 1 000 одновременных пользователей» — это НФТ. Подрядчик может сдать второе, но не первое.

14 категорий нефункциональных требований с конкретными примерами

Матрица ниже — основа любой нашей спецификации. Под каждую категорию в таблице НФТ проекта идёт строка с целевым порогом, методом измерения и артефактом проверки, привязанным к контракту.

Готовый шаблон нефункциональных требований

Наш внутренний шаблон (Excel + Word) сопоставляет каждой из 14 категорий: целевой порог, обоснование, метод измерения, артефакт проверки, приоритет (must-have / should-have / nice-to-have), ответственного и критерий приёмки, который зашивается в контракт.

Например, одна строка по производительности выглядит так: «p95 времени установления видеосоединения <1,5 с; обоснование: выше 2 с пользователь воспринимает поток как сломанный; измерение: синтетический мониторинг через Pingdom из 5 регионов; верификация: еженедельный отчёт; приоритет: must-have; ответственный: Platform Eng; приёмка: подписывается QA на staging перед каждым релизом». Все строки спецификации построены по этому шаблону.

Пришлите нам бриф проекта — за 5 рабочих дней вернёмся с заполненным шаблоном НФТ. Бесплатно. См. CTA ниже.

Разбор: нефункциональные требования для телемедицины

Телемедицинский продукт в США, работающий с PHI: 50 врачей и 5 000 пациентов в первый день, рост до 30 000 пациентов в первый год. Релевантные НФТ (избранные):

Производительность. p95 времени установления видеоконсультации <2,5 с. Сквозная задержка glass-to-glass <1 с. Время ответа на запрос к EHR <500 мс.

Доступность. 99,95 % в месяц в часы приёма врачей (8:00–20:00 ET); 99,9 % в нерабочие часы. Деплой по нескольким AZ; задокументированный плейбук failover.

Безопасность. SSO через Auth0 + обязательный MFA для врачей; AES-256 на хранении с KMS-ключами под управлением клиента; DTLS-SRTP для видео; аудит-лог на каждый доступ к PHI с хранением 6 лет.

Комплаенс. Соответствие обновлению HIPAA Security Rule 2024 года; подписанные BAA со всеми вендорами в цепочке (AWS, Auth0, Datadog, видео-SDK, сервис субтитров); SOC 2 Type 1 к 9-му месяцу, Type 2 к 15-му.

Совместимость. Ресурсы FHIR R5 для пациентов и эпизодов; интеграция с Epic AppOrchard или Cerner через SMART-on-FHIR; записи эпизодов с CPT-кодами для биллинга.

Восстанавливаемость. RTO <1 час (медицинская срочность не позволяет дольше); RPO <5 мин; ежеквартальные учения по восстановлению после катастрофы.

Разбор: нефункциональные требования для платформы лайв-стриминга

OTT-платформа для прямых трансляций спорта: 1,4 млн одновременных зрителей на пиках, работа 24/7, монетизация рекламой плюс подписочный тариф. Избранные НФТ:

Производительность. Сквозная задержка glass-to-glass p50 <500 мс через WHIP/WHEP для интерактивного тарифа; p95 <1 с. Резерв на LL-HLS — <5 с. Время до первого кадра <800 мс.

Масштабируемость. Пики до 1,4 млн одновременных зрителей; автомасштабируемая SFU-сеть в 4 регионах; ежемесячный стресс-тест по сценарию «полный стадион» (10x от обычной нагрузки).

Доступность. 99,99 % во время запланированных трансляций (любая минута простоя в эфире матча — это прямые потери выручки); 99,9 % вне трансляций.

Экономичность. Стоимость CDN <12 % подписной выручки; целевая стоимость доставки минуты эфира <0,06 ₽.

Переносимость. Web, iOS, Android, Apple TV, Roku, Fire TV, Samsung Tizen, LG WebOS. У каждой платформы — своя строка НФТ по поддержке кодеков и DRM.

Разбор: нефункциональные требования для AI-агента

Голосовой AI-агент — например, ИИ-агент для регистратуры стоматологических клиник, собранный на OpenAI Realtime + LiveKit Agents. Избранные НФТ:

Производительность. Голос-в-голос задержка p50 <800 мс; p95 <1,4 с. Доля успешных вызовов инструментов >96 %.

Надёжность. Доля помеченных галлюцинаций <1 % (контролируется периодической выборкой). Доставляемость аудит-логов 100 %.

Комплаенс. Подпадает под классификацию рисков EU AI Act; в медицинском контексте попадает в Annex III — система высокого риска. Документация, человеческий контроль и пострелизный мониторинг — обязательны с первого дня.

Наблюдаемость. Helicone или LangSmith на каждой сессии агента: полный аудиозахват, транскрипт, все вызовы инструментов, задержка p50/p95 на каждом ходе, стоимость токенов на сессию.

Как глубина нефункциональных требований меняется по фазам проекта

Спецификация НФТ — не разовый артефакт. Она ужесточается по мере зрелости продукта, а цена ошибки растёт нелинейно от стадии к стадии.

Дискавери и прототип (недели 0–6). Всего 4–6 НФТ. Производительность (примерная цель по p95), безопасность (никаких утечек PII), переносимость (целевые браузеры и ОС). Остальное — «разумные значения по умолчанию». Закладывать две недели на спецификацию из 14 категорий ради одноразового прототипа — непрофессионально.

MVP и первый платящий клиент (месяцы 2–6). 8–15 НФТ по 6 категориям: производительность, масштабируемость, безопасность, комплаенс, удобство использования, наблюдаемость. Числа уже реальные, но консервативные; верификация — ручная или выборочная.

Рост и Series A и далее (месяцы 6–18). Все 14 категорий. Числа ужесточаются; верификация автоматизируется в CI; SLA-контракты начинают нести штрафы. Цена пропущенного НФТ на этой стадии — масштаба корпоративной сделки, а не бага.

Зрелость и регулируемый масштаб (год 2+). 80+ НФТ, иногда разбитых на отдельные спецификации по регулируемым доменам (HIPAA, SOC 2, EU AI Act). Внешние аудиторы проверяют каждый релиз. Нарушение НФТ — это инцидент безопасности.

Как обсуждать нефункциональные требования с подрядчиками

1. НФТ идут в RFP, а не в кикофф. Если подрядчик впервые слышит про HIPAA на кикофф-звонке, оценка ошибается на десятки тысяч долларов. Перечислите все НФТ прямо в RFP.

2. Подрядчик должен спорить с невыполнимыми НФТ. «p95 задержка <50 мс при глобальных пользователях» физически недостижима в публичном интернете. Зрелая команда оспорит такое требование; неопытная согласится со всем — и не дойдёт до цели.

3. Привяжите НФТ к критериям приёмки. Раздел приёмки в контракте должен перечислять каждое НФТ вместе с артефактом проверки (отчёт нагрузочного тестирования, транскрипт аудита, сканирование доступности). Без этого подрядчик может объявить «готово» по фичам и обойти НФТ.

4. Различайте must-have и should-have. Доступность 99,99 % дороже 99,9 % в 10 раз. Будьте честны с собой о том, какие НФТ действительно обязательны, а какие — обсуждаемы; подрядчик заложит цену соответственно.

Как проверить, что нефункциональные требования действительно выполнены

Производительность. Нагрузочные тесты k6 / Locust / JMeter на staging с профилями трафика, повторяющими прод. Синтетический мониторинг (Datadog Synthetics, Pingdom) — для непрерывной проверки.

Доступность. Мониторинг uptime с дашбордами SLA (Datadog, Better Uptime); пост-мортемы инцидентов с привязкой к целям RTO/RPO.

Безопасность. Внешний пентест перед запуском и ежегодно; SAST/DAST в CI; генерация SBOM; SLA на устранение уязвимостей.

Комплаенс. Внешний аудитор подписывает отчёт. Оценка рисков по HIPAA, аттестация SOC 2, GDPR ROPA — всё проверяется третьей стороной.

Доступность для людей с особыми потребностями. Автоматический скан (axe-core, Lighthouse) плюс ручной аудит сертифицированного консультанта по доступности.

Восстанавливаемость. Живые учения по восстановлению из бэкапов, при свидетелях и с протоколом. Минимум раз в квартал.

Модель затрат: сколько стоит работа над нефункциональными требованиями

Цифры — из нашей выборки 80 оценок подрядчиков в год, валидной для типичного SaaS-продукта на рынки США + ЕС. Используйте их как ориентиры для планирования, не как обещания.

Базовый комплаенс (HIPAA + SOC 2 Type 2). 2,2–6 млн ₽ на аудит плюс 4–8 недель работы senior-инженеров на внедрение контролей. Каждый дополнительный фреймворк (GDPR, PCI, FedRAMP) добавляет около 2 недель.

Доступность (WCAG 2.2 AA, ретрофит). 6–10 недель на зрелый продукт, около 1,8–4,5 млн ₽ с учётом сертифицированного ручного аудита. Если закладывать с первого дня — около 2 недель.

Закаливание производительности (базовый p95 + стенд нагрузочного тестирования). 3–5 недель плюс 0,5 FTE на постоянной основе для синтетического мониторинга и отлова регрессий. Цена резко растёт, когда p95 на глобальном масштабе уходит ниже 100 мс.

Подъём доступности (с 99,9 до 99,95). Удваивает стоимость инфраструктуры (мульти-регион, горячий резерв), добавляет дежурство, требует ранбуков и chaos-учений. С 99,95 до 99,99 — снова удвоение.

Стек наблюдаемости (Datadog или аналог). 75–375 ₽ за хост в месяц на низком масштабе, до 3 750–15 000 ₽ за хост при высокой кардинальности. Самохостинг Grafana снижает счёт, но добавляет 0,25 FTE на эксплуатацию.

Типичные ошибки в нефункциональных требованиях

1. Прилагательные вместо чисел. «Быстро», «надёжно», «безопасно» — это не НФТ. Замените каждое на число и метод измерения.

2. Конфликтующие НФТ без разрешения компромисса. «99,99 % доступности + потолок стоимости 150 ₽ на пользователя в месяц + p95 50 мс глобально» — это внутренне противоречивая система. Проставьте приоритеты и признайте компромисс.

3. Перебор на гринфилд-продуктах. Стартапу до PMF задавать SOC 2 Type 2 + SLA 99,95 % + WCAG AAA — это сжигание бюджета. Глубина НФТ должна соответствовать стадии.

4. Забытые обновления комплаенса. Обновление HIPAA Security Rule 2024 года сделало шифрование на хранении, MFA и инвентарь активов обязательными. EU AI Act действует с 2025 года для классификаторов высокого риска. Шаблон НФТ из 2022 года устарел.

5. НФТ в отдельном документе. Если НФТ лежат в файле, отдельном от функциональных требований, подрядчики читают функционал и забывают про НФТ. Сведите всё в одну спецификацию, где НФТ — сквозные заголовки.

Фреймворк принятия решений — выбираем глубину НФТ за пять вопросов

В1. До MVP или после MVP? До: 6 категорий (производительность, безопасность, масштабируемость, комплаенс, удобство использования, наблюдаемость). После: все 14.

В2. Регулируемая отрасль? Здравоохранение, финансы, госсектор и образование в ЕС — везде НФТ по комплаенсу обязательны, не опциональны.

В3. Профиль нагрузки? <10 тыс. DAU: масштабируемость — best-effort. 10 тыс.–1 млн DAU: must-have. >1 млн: масштабируемость доминирует в разделе НФТ.

В4. География? Мульти-региональный деплой меняет требования по доступности, восстанавливаемости и задержкам. Один регион — всё резко проще.

В5. Тип контракта? Fix-bid: НФТ должны быть точными (риск на подрядчике). T&M: НФТ могут эволюционировать, но дисциплина по компромиссам всё равно нужна.

KPI для оценки соответствия нефункциональным требованиям

KPI качества. Доля нарушенных НФТ на релиз (цель: 0 критичных, <3 минорных). Критичные находки пентеста (цель: 0 неустранённых старше 30 дней). Балл сканирования доступности (цель: 95+ в Lighthouse).

Бизнес-KPI. Нарушения SLA (цель: ноль клиентских инцидентов в квартал). Прохождение комплаенс-аудитов (цель: 100 % с первого раза).

KPI надёжности. Успешность учений по восстановлению (цель: 100 % успешных квартальных учений). MTTR инцидентов против целевого (цель: укладываемся в RTO).

Когда формальные нефункциональные требования избыточны

Одноразовые прототипы. Кликабельная демка на 2 недели, чтобы проверить UX-гипотезу. Пропускайте шаблон НФТ; задача — чтобы демка прошла end-to-end.

Внутренние инструменты на <10 пользователей. Математика компромиссов не оправдывает формальных НФТ. Достаточно разумных значений по умолчанию плюс обязательства по поддерживаемости.

Гипер-итеративный продуктовый дискавери. Если продукт меняется еженедельно по результатам исследований, профиль НФТ меняется быстрее, чем его можно формально зафиксировать. Закрепляйте НФТ на стабильном MVP, а не на v0.

Мини-кейс: ретрофит нефункциональных требований на телемедицинской платформе уровня Series A

Ситуация. Американский телемед-клиент подписал первую сеть госпиталей. Открытие: госпиталь требовал SOC 2 Type 2, шифрование на хранении с клиентскими ключами, аудит-лог с хранением 6 лет и доступность 99,95 % с задокументированным failover. В исходной спецификации НФТ было две строки: «соответствует HIPAA» и «высокая доступность». В анкете безопасности госпиталя — 287 вопросов.

План на 12 недель. Недели 1–2: написана и привязана к контракту спецификация НФТ из 14 категорий. Недели 3–6: внедрение контролей (ротация KMS, обязательный MFA, структурированные аудит-логи в защищённое от изменений хранилище, мульти-AZ failover с задокументированными RTO/RPO). Недели 7–9: подключён внешний аудитор для аттестации SOC 2 Type 1. Недели 10–12: нагрузочные тесты, chaos-учения, аудит доступности, пентест безопасности, сухой прогон 287-вопросной анкеты госпиталя.

Результат. До: p95 запроса к EHR — 4 секунды, аудит-лога нет, деплой в одной AZ, 0 % прохождения анкеты. После: p95 запроса к EHR — 380 мс, полный аудит-лог по доступу к PHI с хранением 6 лет, мульти-AZ с задокументированным failover за 23 минуты, 94 % прохождения анкеты (оставшиеся 6 % — неблокирующие документационные запросы). Отчёт SOC 2 Type 1 — на 14-й неделе. Контракт с госпиталем закрыт на 16-й неделе.

FAQ

В чём разница между функциональными и нефункциональными требованиями?

Функциональные требования описывают, что делает система («пациент может записаться на приём»). НФТ описывают, насколько хорошо, при каких условиях, какой ценой и как это будет проверено («запись завершается за <3 с на p95 при 1 000 одновременных пользователей»). Нужны и те, и другие: функциональные отвечают на «что», нефункциональные — на «насколько хорошо».

Сколько НФТ должно быть у типового проекта?

До MVP: 8–15 НФТ по 6 категориям. Зрелый SaaS: 30–60 НФТ по всем 14. Enterprise / регулируемый: 80+. Качество важнее количества — у каждого НФТ должны быть число, метод измерения и способ проверки.

НФТ — это то же, что атрибуты качества?

По сути да — НФТ и атрибуты качества ПО — это синонимы. ISO 25010 называет их «характеристиками качества продукта». SAFe называет «нефункциональными требованиями». На практике термин НФТ удобнее для контракта, потому что он формулирует обязательства.

Как писать НФТ по доступности WCAG?

Выберите версию и уровень соответствия WCAG (2.2 AA — дефолт 2026 года). Задайте пороги автоматического сканирования (балл доступности в Lighthouse ≥ 95). Добавьте требование ручного аудита перед запуском. Сошлитесь на European Accessibility Act, если вы работаете в ЕС.

Что изменилось в 2026 году в комплаенс-НФТ?

Обновление HIPAA Security Rule 2024 года сделало шифрование на хранении, MFA и инвентарь активов обязательными (раньше — «по возможности»). Классификация рисков EU AI Act действует с 2025 года для любых классификаторов, работающих с лицами, поведением и биометрией. European Accessibility Act вступил в силу в июне 2025 года. Обновите шаблон НФТ из 2022 года до следующего аудита.

Можно ли проверять НФТ в CI/CD?

Да — тестируемые НФТ (производительность, сканирование безопасности, сканирование доступности, уязвимости зависимостей) идут в CI. Добавьте quality gates, которые блокируют деплой при превышении порога. Ручные НФТ (аттестация комплаенса, ручной аудит доступности) — на этап подписания релиза.

Кто владеет НФТ — продукт или инженерия?

И те, и другие. Продукт владеет НФТ с бизнес-эффектом (экономичность, удобство использования, целевая доступность). Инженерия — реализационными (поддерживаемость, наблюдаемость, продуктивность разработки). НФТ по комплаенсу и безопасности — совместные, чаще всего у CISO или DPO.

Как НФТ влияют на оценку?

Сильно. Один комплаенс (HIPAA + SOC 2) — это 2,2–6 млн ₽ на аудит плюс 4–8 недель работы senior-инженеров. Доступность, добавленная поздно, обходится в 6–10 недель.

Что почитать дальше

Готовы описывать НФТ, которые действительно работают?

НФТ — это 30–60 % работы по проекту, но в брифе им достаётся 5 %. Решение — модель из 14 категорий с числовыми порогами, методами измерения, способами проверки, приоритетами и ответственными. Зашейте всё в контракт. Проверяйте на каждом релизе. Обновляйте по мере изменения комплаенса — в HIPAA 2024 года, EU AI Act 2025 года и European Accessibility Act планка уже сместилась.

Подрядчик, который спорит с невыполнимыми НФТ и считает по реалистичным, — это партнёр, который вам нужен. Подрядчик, который говорит «да, всё сделаем», — это партнёр, который удивит вас change orders на четвёртом месяце.