Функциональные и нефункциональные требования

Первый вопрос почти любого собеседования на системного аналитика — и первый, на котором заваливаются, отвечая заученным определением.

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

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

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

Развёрнутый ответ. Функциональное требование описывает поведение: какое действие пользователь может совершить и какой результат получит. «Пользователь может отменить заказ, пока он не передан в доставку» — функциональное. Оно проверяется вопросом «система это делает или нет?», ответ бинарный.

Нефункциональное требование описывает свойство системы в целом или свойство конкретной функции: производительность, доступность, безопасность, совместимость, удобство сопровождения. «Страница списка заказов открывается за 2 секунды на 95% запросов при 500 одновременных пользователях» — нефункциональное. Оно проверяется измерением, а не наблюдением.

Полезная мысленная проверка: уберите требование и спросите, что сломается. Если исчезает возможность сделать что-то — оно функциональное. Если возможность остаётся, но система становится медленной, небезопасной, ненадёжной или неудобной — нефункциональное.

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

Группа	О чём	Пример формулировки
Производительность	время отклика, пропускная способность	p95 отклика API — не более 300 мс при 200 RPS
Надёжность и доступность	сколько система может лежать	доступность 99,9% в месяц, окно планового обслуживания — до 2 часов в ночь воскресенья
Масштабируемость	запас роста	рост числа заказов в 5 раз без изменения архитектуры
Безопасность	доступ, хранение, аудит	персональные данные хранятся в зашифрованном виде, доступ логируется 3 года
Совместимость	окружение, браузеры, интеграции	поддержка двух последних мажорных версий Chrome, Safari, Firefox
Сопровождаемость	как систему чинят и меняют	развёртывание новой версии без остановки сервиса

Вопрос 2. Приведите пример нефункционального требования и скажите, как его проверить

Что проверяют. Умеете ли вы писать измеримо. Половина кандидатов выдаёт «система должна быть быстрой и надёжной» — и на этом интервью по требованиям, по сути, заканчивается.

Плохое нефункциональное требование неизмеримо, поэтому его нельзя ни протестировать, ни принять:

ПЛОХО:  Система должна работать быстро.
ПЛОХО:  Интерфейс должен быть удобным.
ПЛОХО:  Система должна выдерживать высокую нагрузку.

Хорошее содержит метрику, значение, условия измерения и точку измерения:

ХОРОШО: 95-й перцентиль времени ответа GET /orders — не более 300 мс
        при нагрузке 200 запросов в секунду, измерение на стороне
        API-шлюза, тестовый набор данных — 1 млн заказов.

ХОРОШО: Доступность сервиса оплаты — не менее 99,9% в календарный
        месяц, считается по успешным ответам health-check раз в 30 с.

Обратите внимание на формулу: метрика + пороговое значение + условия + способ измерения. Такое требование можно передать тестировщику, и он сам поймёт, как писать нагрузочный сценарий.

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

nfr:
  - id: NFR-PERF-01
    category: performance
    scope: "GET /orders"
    metric: "p95 response time"
    target: "<= 300 ms"
    conditions: "200 RPS, 1M orders in DB"
    verification: "нагрузочный тест перед релизом"
  - id: NFR-SEC-03
    category: security
    scope: "персональные данные клиентов"
    metric: "шифрование хранения"
    target: "AES-256 на уровне БД"
    verification: "чек-лист безопасности + аудит доступа"

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

Функциональное требование обычно означает «написать ещё немного кода». Нефункциональное часто означает «переделать архитектуру». Требование «доступность 99,99%» вместо «99,5%» превращает один сервер в кластер с репликацией базы, балансировщиком и резервным контуром — это разница в стоимости и сроках в разы, а функциональность при этом ровно та же.

Поэтому нефункциональные требования собирают до проектирования, а не после. Аналитик, который принёс архитектору «ах да, ещё нужно 10 000 одновременных пользователей» на этапе приёмки, — это дорогой аналитик в плохом смысле.

Типичные ошибки кандидатов

Отвечают определением из ГОСТа и замолкают, не приводя ни одного примера. Интервьюер ждёт примеров.
Считают нефункциональными все требования, где нет слова «пользователь». Требование «система отправляет уведомление в очередь» — функциональное, даже если пользователь его не видит.
Пишут неизмеримые формулировки: «быстро», «удобно», «надёжно».
Забывают про условия измерения. «Отклик 300 мс» без указания нагрузки и объёма данных бессмыслен: на пустой базе и в один поток почти всё быстро.
Не различают ограничение (constraint) и требование. «Использовать PostgreSQL, потому что так решил архитектурный комитет» — это ограничение, а не нефункциональное требование.

Как ответить кратко

Функциональные требования отвечают на вопрос «что система делает» — их проверяют по принципу «работает или нет». Нефункциональные описывают качество: производительность, доступность, безопасность, масштабируемость, — их проверяют измерением. Ключевое правило: нефункциональное требование обязано содержать метрику, целевое значение и условия измерения, иначе оно нетестируемо. Например, вместо «система должна быть быстрой» — «p95 ответа GET /orders не более 300 мс при 200 RPS на базе в миллион заказов». И собирать их надо до проектирования, потому что именно они определяют архитектуру и бюджет.