Требования — это не формальность. Это страховка от «мы же обсуждали».

Если вы когда-нибудь слышали на демо фразу «это не то, что мы просили», хотя вы точно помните, что именно это и просили — добро пожаловать в мир, где требования либо не были записаны, либо были записаны так, что каждый понял их по-своему.

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

В предыдущей статье о нефункциональных требованиях мы разобрали теорию. Сегодня — практика: конкретные примеры, готовые шаблоны и ошибки, которые я встречал у десятков команд.

Классификация требований: что относится к ФТ, а что к НФТ

Прежде чем лезть в примеры, давайте раз и навсегда зафиксируем разницу. Потому что на собеседованиях и в реальных проектах эту границу путают с завидной регулярностью.

Функциональное требование (ФТ / FR) — описывает конкретное поведение системы: что она делает в ответ на действие пользователя или внешнее событие.

Нефункциональное требование (НФТ / NFR) — описывает качественную характеристику системы: как быстро, надёжно, безопасно и удобно она выполняет свои функции.

Простая аналогия: вы заказываете пиццу. ФТ — «пицца с моцареллой и томатами». НФТ — «доставка за 30 минут, температура не ниже 60°C, курьер не роняет коробку». Если вам привезут правильную пиццу через 3 часа в холодном виде — функциональное требование выполнено, а нефункциональные провалены.

graph TD
  REQ["Требования к системе"]
  REQ --> FT["Функциональные<br/>требования (ФТ)"]
  REQ --> NFT["Нефункциональные<br/>требования (НФТ)"]

  FT --> FT1["Бизнес-логика<br/><i>Что система делает</i>"]
  FT --> FT2["Пользовательские<br/>сценарии"]
  FT --> FT3["Интеграции<br/>с внешними системами"]

  NFT --> PERF["Производительность"]
  NFT --> SEC["Безопасность"]
  NFT --> SCALE["Масштабируемость"]
  NFT --> REL["Надёжность"]
  NFT --> USE["Удобство<br/>использования"]
  NFT --> COMP["Совместимость"]
  NFT --> MON["Логирование<br/>и мониторинг"]
  NFT --> STD["Соответствие<br/>стандартам"]

  PERF --> PERF1["Время отклика<br/>Пропускная способность"]
  SEC --> SEC1["Аутентификация<br/>Шифрование"]
  SCALE --> SCALE1["Горизонтальное<br/>Вертикальное"]
  REL --> REL1["Uptime<br/>Отказоустойчивость"]

  style REQ fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style FT fill:#50c878,stroke:#3a9a5c,color:#fff
  style NFT fill:#f0a500,stroke:#c88400,color:#fff
  style FT1 fill:#50c878,stroke:#3a9a5c,color:#fff
  style FT2 fill:#50c878,stroke:#3a9a5c,color:#fff
  style FT3 fill:#50c878,stroke:#3a9a5c,color:#fff
  style PERF fill:#f0a500,stroke:#c88400,color:#fff
  style SEC fill:#f0a500,stroke:#c88400,color:#fff
  style SCALE fill:#f0a500,stroke:#c88400,color:#fff
  style REL fill:#f0a500,stroke:#c88400,color:#fff
  style USE fill:#f0a500,stroke:#c88400,color:#fff
  style COMP fill:#f0a500,stroke:#c88400,color:#fff
  style MON fill:#f0a500,stroke:#c88400,color:#fff
  style STD fill:#f0a500,stroke:#c88400,color:#fff
  style PERF1 fill:#e0e0e0,stroke:#999,color:#333
  style SEC1 fill:#e0e0e0,stroke:#999,color:#333
  style SCALE1 fill:#e0e0e0,stroke:#999,color:#333
  style REL1 fill:#e0e0e0,stroke:#999,color:#333

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

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

Теория без примеров — как API без документации: вроде существует, но пользоваться невозможно. Ниже — примеры ФТ и НФТ из четырёх популярных доменов.

Интернет-банк

E-commerce

Страхование

Общепит (система управления рестораном)

Шаблоны для описания требований

«А как это записывать?» — вопрос, который возникает у каждого аналитика после того, как он понял разницу между ФТ и НФТ. Вот три проверенных шаблона.

Шаблон 1: ФТ в формате User Story + критерии приёмки

1
Как [роль],
2
я хочу [действие],
3
чтобы [цель/ценность].
4

5
Критерии приёмки:
6
- Система должна [конкретное поведение]
7
- При ошибке система [поведение при ошибке]
8
- Допустимые входные данные: [ограничения]
9

10
НФТ:
11
- Производительность: [время отклика] при [нагрузка]
12
- Безопасность: [требование к защите данных]
13
- Доступность: [uptime]

Пример заполненного шаблона:

1
Как клиент интернет-банка,
2
я хочу перевести деньги на счёт другого клиента по номеру телефона,
3
чтобы не запоминать номера счетов.
4

5
Критерии приёмки:
6
- Система находит получателя по номеру телефона, привязанному к счёту
7
- При отсутствии привязки — сообщение «Получатель не найден»
8
- Максимальная сумма перевода: 500 000 ₽ в сутки
9

10
НФТ:
11
- Производительность: поиск получателя < 1 сек, перевод < 3 сек
12
  при нагрузке до 2 000 RPS
13
- Безопасность: подтверждение через SMS/push, данные по TLS 1.3
14
- Доступность: 99.95% uptime

Шаблон 2: таблица НФТ с метриками

Этот шаблон хорош для технической документации и передачи в разработку:

Шаблон 3: НФТ как часть спецификации API

Для REST API удобно фиксировать НФТ прямо в спецификации эндпоинта:

1
POST /api/v1/orders
2

3
Описание: Создание нового заказа
4

5
Функциональные требования:
6
- Создаёт заказ с переданными товарами
7
- Рассчитывает итоговую стоимость с учётом скидок
8
- Возвращает ID созданного заказа
9

10
Нефункциональные требования:
11
- Время ответа: p99 < 2 сек
12
- Rate limit: 100 запросов/мин на пользователя
13
- Максимальный размер тела запроса: 1 МБ
14
- Идемпотентность: поддержка Idempotency-Key
15
- Логирование: каждый запрос в audit log

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

Давайте пройдёмся по каждой категории НФТ с конкретными формулировками. Это не абстрактные «безопасность должна быть на высоте» — а измеримые требования, которые можно проверить.

1. Производительность (Performance)

Самая очевидная категория, но и самая часто неверно описанная. «Система должна работать быстро» — это не требование, это пожелание.

2. Безопасность (Security)

3. Масштабируемость (Scalability)

4. Надёжность (Reliability)

5. Удобство использования (Usability)

6. Совместимость (Compatibility)

7. Логирование и мониторинг (Observability)

8. Соответствие стандартам (Compliance)

Как ФТ и НФТ связаны с архитектурой системы

Вот что большинство аналитиков упускают: НФТ — это не «бумажка для галочки». НФТ напрямую диктует архитектурные решения. Плохо сформулированные НФТ = плохая архитектура = «мы потом перепишем» (а мы знаем, что потом — это никогда).

graph LR
  subgraph "Требования"
      FT["ФТ: Пользователь<br/>оплачивает заказ"]
      NFT1["НФТ: < 3 сек"]
      NFT2["НФТ: 99.99% uptime"]
      NFT3["НФТ: PCI DSS"]
  end

  subgraph "Архитектурные решения"
      A1["Кэширование<br/>корзины в Redis"]
      A2["Два инстанса<br/>+ failover"]
      A3["Токенизация<br/>карт, HSM"]
      A4["Асинхронные<br/>уведомления"]
  end

  subgraph "Инфраструктура"
      I1["Redis Cluster"]
      I2["K8s + Helm<br/>+ health checks"]
      I3["Vault + HSM<br/>+ сертификаты"]
      I4["RabbitMQ /<br/>Kafka"]
  end

  FT --> A4
  NFT1 --> A1
  NFT2 --> A2
  NFT3 --> A3
  A1 --> I1
  A2 --> I2
  A3 --> I3
  A4 --> I4

  style FT fill:#50c878,stroke:#3a9a5c,color:#fff
  style NFT1 fill:#f0a500,stroke:#c88400,color:#fff
  style NFT2 fill:#f0a500,stroke:#c88400,color:#fff
  style NFT3 fill:#f0a500,stroke:#c88400,color:#fff
  style A1 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style A2 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style A3 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style A4 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style I1 fill:#7b68ee,stroke:#5a4db2,color:#fff
  style I2 fill:#7b68ee,stroke:#5a4db2,color:#fff
  style I3 fill:#7b68ee,stroke:#5a4db2,color:#fff
  style I4 fill:#7b68ee,stroke:#5a4db2,color:#fff

Каждое НФТ тянет за собой цепочку архитектурных и инфраструктурных решений. Требование «< 3 сек» приводит к кэшированию. Требование «99.99% uptime» — к отказоустойчивым кластерам. Требование «PCI DSS» — к аппаратным модулям безопасности. Именно поэтому НФТ нужно фиксировать на ранних этапах — когда архитектура ещё гибкая, а не когда монолит уже закатан в бетон.

Больше о том, как требования формируют архитектуру, можно найти в подборке ресурсов для аналитиков и архитекторов.

Типичные ошибки при описании ФТ и НФТ

За годы работы я видел одни и те же паттерны ошибок. Некоторые из них стоили командам месяцев переработки. Вот пятёрка лидеров:

1. НФТ описаны абстрактно — без метрик

1
❌  «Система должна быть быстрой и надёжной»
2
✅  «API отвечает за < 200 мс (p95), uptime 99.9%, RTO = 10 мин»

Если требование нельзя проверить тестом — это не требование. Это надежда.

2. НФТ не привязаны к конкретным ФТ

Когда НФТ живут в отдельном документе и никак не связаны с функциональными требованиями, разработчики их просто игнорируют. «А к какой фиче это относится?» — и документ уходит в архив.

Решение: каждое НФТ привязывайте к конкретному сценарию или эндпоинту (как в шаблонах выше).

3. Забыли про нагрузку

«Авторизация работает за 200 мс» — при одном пользователе. А при 10 000 одновременных запросов? Всегда указывайте нагрузку:

1
❌  «Время ответа < 200 мс»
2
✅  «Время ответа < 200 мс (p95) при нагрузке 5 000 RPS»

4. ФТ и НФТ перепутаны

Это классика собеседований и реальных проектов. «Система должна шифровать данные» — это ФТ или НФТ? Зависит от контекста:

• Вы делаете приложение-шифровальщик? Это ФТ — шифрование и есть основная функция.
• Вы делаете интернет-банк? Это НФТ — шифрование описывает как система защищает данные, а не что она делает.

5. НФТ написаны «под копирку» без учёта домена

Копировать шаблон из интернета и вставлять «99.99% uptime» для внутреннего инструмента на 15 пользователей — это не инженерный подход. Это карго-культ. НФТ должны отражать реальные потребности бизнеса, а не красивые цифры из чужих SLA.

Матрица приоритизации: какие НФТ описывать в первую очередь

Не все НФТ одинаково важны. Для MVP внутреннего инструмента и для платёжного шлюза приоритеты будут разными. Вот матрица, которая поможет определить, что описывать в первую очередь:

Начинайте с категорий, помеченных Критичный в вашем домене. Для e-commerce это производительность и usability — потому что медленный сайт теряет деньги (каждая дополнительная секунда загрузки — минус 7% конверсии, если верить исследованиям). Для финтеха — безопасность и compliance, потому что штрафы за нарушение PCI DSS измеряются в миллионах.

Как не превратить НФТ в бюрократию

Есть соблазн описать НФТ для каждого чекбокса в системе. Не надо. Золотое правило:

Описывайте НФТ для критического пути пользователя и для точек интеграции. Всё остальное — по потребности.

Критический путь — это последовательность действий, без которых система теряет смысл. Для интернет-магазина: поиск → корзина → оплата → подтверждение. Для каждого шага этой цепочки НФТ обязательны.

Точки интеграции — это места, где ваша система общается с внешним миром: платёжные провайдеры, внешние API, SMTP-серверы. Здесь всегда нужны таймауты, retry-политики и fallback-стратегии.

Для внутренней админки, которой пользуется 5 человек? Хватит базовых требований: «работает в Chrome, открывается за 5 сек, доступна в рабочее время». Не нужно вычислять p99 для кнопки «Экспорт в Excel» (хотя если этот Excel содержит данные за 10 лет — может, и нужно).

Заключение

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

Три ключевых правила:

1. Измеримость — если нельзя проверить тестом, это не требование
2. Привязка — каждое НФТ связано с конкретным сценарием или компонентом
3. Адекватность — НФТ соответствует реальным потребностям, а не копипасте из чужого SLA

И помните: хорошо описанные требования экономят месяцы разработки. Плохо описанные — добавляют месяцы отладки. Выбор, как говорится, за вами.

PS: Если ваш PM говорит «НФТ — это потом, сначала сделаем функционал», покажите ему таблицу с компромиссами. Обычно после фразы «99.99% uptime означает 52 минуты простоя в год» разговор становится продуктивнее.