Чек-лист нефункциональных требований: 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 пациентов в первый год. Релевантные НФТ (избранные):

Производительность. 95-й перцентиль времени установления видеоконсультации — менее 2,5 с. Сквозная задержка «стекло-к-стеклу» — менее 1 с. Время ответа на запрос к электронной медицинской карте — менее 500 мс.

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

Безопасность. 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-HTTP — <5 с. Время до первого кадра <800 мс.

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

Доступность. 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; в медицинском контексте относится к приложению 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 % в 10 раз дороже, чем 99,9 %. Честно оцените, какие НФТ действительно обязательны, а какие можно обсудить — подрядчик учтёт это при расчёте цены.

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

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

Доступность. Мониторинг времени работы с дашбордами 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).

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

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

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

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

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

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

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

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

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

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

FAQ

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

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

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

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