Требование — это проверяемое утверждение о том, какой должна быть система. Функциональные требования (FR) описывают, что система делает: «пользователь может оплатить заказ картой». Нефункциональные (NFR) описывают, насколько хорошо она это делает: быстро, надёжно, безопасно, под нагрузкой. Функциональные обычно помнят — без них фичи просто нет. Нефункциональные забывают — и узнают о них в проде, когда система ложится под нагрузкой или утекают данные. Правило: НФТ без числа — это не требование, а пожелание. Не «быстро», а «p95 < 300 мс».
Я видел спеку на платёжный сервис, где было идеально расписано, как создаётся платёж, как он подтверждается, какие статусы бывают. Сорок страниц функциональных требований. А потом в чёрную пятницу сервис лёг — потому что нигде не было написано, сколько платежей в секунду он должен держать. Никто не задал вопрос «насколько хорошо», все спрашивали только «что делает». Это и есть разница между FR и NFR, и стоила она компании одного очень плохого вечера.
Что такое требование вообще
Требование — это утверждение о системе, которое можно проверить. Ключевое слово — проверить. «Система должна быть удобной» — это не требование, это благое намерение: как вы докажете, что она удобна? «Пользователь оформляет заказ не более чем за 3 шага» — вот это требование, его можно взять и измерить.
Все требования к системе грубо делятся на две корзины. В первой — что система должна уметь делать. Во второй — какими свойствами она при этом обладает. Первая корзина — функциональные требования, вторая — нефункциональные.
Функциональные требования: что система делает
Функциональное требование описывает поведение: какое действие система выполняет в ответ на что. Если можно сформулировать как «система делает X, когда происходит Y» — это функциональное.
- Пользователь может зарегистрироваться по номеру телефона.
- При оплате система отправляет чек на email.
- Администратор может заблокировать аккаунт.
- Если на складе нет товара, система не даёт оформить заказ.
Их легко проверить: либо система это делает, либо нет. Именно поэтому функциональные требования почти никогда не забывают — без них продукта попросту не существует. Заказчик первым делом расскажет именно про них, потому что это и есть его «хотелка».
Нефункциональные требования: насколько хорошо
Нефункциональное требование описывает не действие, а качество: насколько быстро, надёжно, безопасно, для скольких пользователей одновременно. Система может делать ровно то, что нужно, и при этом быть непригодной — если делает это за десять секунд или роняется при сотне пользователей.
НФТ удобно держать в голове по категориям. Это не строгая классификация, а чек-лист, чтобы ничего не забыть:
| Категория | Отвечает на вопрос | Пример требования |
|---|---|---|
| Производительность | Насколько быстро? | p95 ответа API < 300 мс при 200 RPS |
| Масштабируемость | Выдержит ли рост? | Держит 10 000 одновременных сессий, горизонтально масштабируется |
| Надёжность | Часто ли падает? | Доступность 99.9% в месяц (≈ 43 минуты простоя) |
| Безопасность | Защищены ли данные? | Пароли хранятся хешированными (bcrypt), трафик по TLS 1.2+ |
| Доступность (a11y) | Доступно ли всем? | Соответствие WCAG 2.1 уровня AA |
| Поддерживаемость | Легко ли менять? | Покрытие тестами ключевой логики не ниже 70% |
Не путайте «доступность» с «доступностью»
В русском одно слово на два разных понятия. Availability — это надёжность, доля времени, когда система работает (те самые 99.9%). Accessibility (a11y) — это пригодность для людей с ограничениями: чтение с экрана, контраст, навигация с клавиатуры. В требованиях лучше уточнять, какую именно «доступность» вы имеете в виду, иначе разработчик и тестировщик поймут по-разному.
Почему НФТ забывают и чем это бьёт
Причина простая: функциональные требования видны, нефункциональные — нет. Заказчик говорит «хочу, чтобы можно было оплатить картой» — и не говорит «и чтобы это работало при десяти тысячах оплат в минуту в чёрную пятницу», потому что для него это само собой разумеется. А для системы — нет.
Беда в том, что НФТ почти всегда влияют на архитектуру, а архитектуру дорого менять задним числом. Если требование «держать 10 000 пользователей» появляется на старте — закладывают горизонтальное масштабирование, кеш, очереди. Если оно появляется после запуска, когда система спроектирована под сотню, — это часто переписывание половины бэкенда. Функциональную фичу можно дозакрутить. Нефункциональную — нередко только переделать.
Где это бьёт по аналитику
Когда система ложится под нагрузкой или утекают данные — первый вопрос будет «а где это было в требованиях?». Если в спеке нет ни слова про нагрузку и безопасность, отвечать придётся вам. Поэтому я завёл привычку: к каждой спеке прохожусь по чек-листу категорий выше и явно пишу либо число, либо «не применимо». Пустое место — это не «по умолчанию нормально», это пропущенный вопрос.
Как формулировать НФТ измеримо
Главная ошибка — прилагательные без чисел. «Быстро», «надёжно», «безопасно», «удобно» — это не требования, потому что их нельзя проверить. Что для одного «быстро», для другого «тормозит». Тестировщик не сможет написать тест на слово «быстро».
Рецепт: к каждому прилагательному добавьте метрику, число и условие.
Плохо: Система должна работать быстро.
Лучше: 95% запросов к API заказов отвечают быстрее 300 мс
при нагрузке 200 запросов в секунду.
Плохо: Сервис должен быть надёжным.
Лучше: Доступность сервиса не ниже 99.9% в календарный месяц,
измеряется по health-check каждые 30 секунд.Обратите внимание на «p95» в примере. Это не среднее, а перцентиль: 95% запросов уложились в этот порог, а 5% самых медленных — нет. Для производительности средние почти бесполезны: один очень медленный запрос на тысячу быстрых испортит опыт реальному пользователю, но в среднем всё будет «нормально». Поэтому в НФТ почти всегда пишут перцентили (p95, p99), а не среднее. Если в спеке видите «среднее время ответа» — это повод уточнить. А как требование «надёжно» доводят до числа и договариваются, за чей счёт простой, — в записи про SLA, SLO и инциденты.
Откуда это взялось
Деление на функциональные и нефункциональные требования пришло не из IT, а из системной инженерии — дисциплины проектирования сложных систем (самолёты, ракеты, заводы), где «что делает изделие» и «в каких условиях оно должно работать» разделяли ещё в середине XX века. В софт это перекочевало в 1970–90-х вместе с инженерным подходом к разработке. Сегодня многие предпочитают термин «атрибуты качества» (quality attributes) вместо «нефункциональные» — потому что слово «нефункциональные» сбивает с толку: они очень даже функциональны для бизнеса. Но «FR/NFR» прижилось и встречается чаще.
Требования — это половина дела. Вторая половина — описать их так, чтобы их не поняли неправильно: про это в записи как написать ТЗ, а способы формулировать сами требования (story, use case, критерии приёмки) — в отдельной записи.
Частые вопросы
Какие бывают нефункциональные требования, приведи примеры?
Основные категории: производительность («p95 ответа < 300 мс»), масштабируемость («держит 10 000 одновременных сессий»), надёжность и доступность («uptime 99.9% в месяц»), безопасность («пароли хешируются, трафик по TLS»), accessibility («соответствие WCAG 2.1 AA»), поддерживаемость («покрытие тестами от 70%»). Общий признак: они описывают не действие системы, а его качество, и должны быть выражены измеримо — с числом и условием.
Чем функциональные требования отличаются от нефункциональных?
Функциональные описывают, что система делает: «пользователь может оплатить заказ картой». Нефункциональные описывают, насколько хорошо она это делает: «оплата проходит за < 2 секунд при 200 операциях в секунду». Простой тест: если требование можно сформулировать как «система делает X» — оно функциональное; если как «система делает это с качеством Y» — нефункциональное.
Что важнее — функциональные или нефункциональные требования?
Оба обязательны, но опасность асимметрична. Без функциональных требований фичи просто нет — и это заметят сразу. Без нефункциональных фича есть, но в проде она тормозит, падает под нагрузкой или утекает данными — и это вскроется в самый неудачный момент. Поэтому функциональные забывают редко, а нефункциональные — постоянно, и именно их я проверяю по чек-листу в каждой спеке.