Как выявить нефункциональные требования до разработки
Практический гайд для тимлида и аналитика: как вывести нефункциональные требования из бизнес-рисков и превратить их в проверяемые условия.
Когда использовать
Нефункциональные требования часто вспоминают слишком поздно: на приемке, после инцидента, перед production-включением или в момент, когда уже нужно объяснять, почему “функционально все работает”, но выпускать страшно.
Материал нужен, когда задача затрагивает:
- данные;
- интеграцию;
- внешних пользователей;
- финансовый, юридический или операционный риск;
- чувствительную информацию;
- производительность;
- доступность;
- поддержку и диагностику;
- совместимость с существующими сценариями.
Задача тимлида - не лично написать все NFR. Его ответственность в том, чтобы команда не потеряла эти требования между идеей, аналитикой, разработкой, review, приемкой и релизом.
При этом заказчик не обязан приносить готовые SLA, RTO или перечень метрик. Обычно он знает другое: когда операция уже слишком долгая, какая ошибка обойдется дорого, что нельзя потерять и кто будет разбирать сбой. Из этих последствий и нужно выводить NFR.
Что считать NFR
Нефункциональные требования описывают не “что делает система”, а “каким должно быть поведение, чтобы результат был пригоден для реальной эксплуатации”.
Типовые зоны:
| Зона | Вопрос |
|---|---|
| Производительность | Как быстро сценарий должен отвечать при нормальной и высокой нагрузке? |
| Надежность | Что происходит при сбое, повторе, таймауте или частичном результате? |
| Безопасность | Кто имеет доступ, что нельзя раскрывать, где граница доверия? |
| Данные | Что является источником истины, что логируется, что маскируется? |
| Совместимость | Что не должно сломаться у текущих пользователей, клиентов или интеграций? |
| Наблюдаемость | Как команда увидит проблему и сможет ее разобрать? |
| Поддержка | Кто действует, когда автоматический сценарий не завершился? |
Если зона важна, она должна стать частью готовности задачи или критерия приемки, а не общим пожеланием “сделать надежно”.
Функция и качество результата
Функциональное требование отвечает на вопрос: «Что должно произойти?». NFR отвечает: «При каких условиях результат остается пригодным для реальной работы?».
| Функция | Качество результата |
|---|---|
| Оператор загружает файл. | Файл рабочего объема обрабатывается за время, допустимое для операции. |
| Система создает операции. | Повторная загрузка не создает дубли, а частичный сбой не теряет уже принятый результат. |
| Оператор видит итог. | По ошибке можно найти строку, причину, время и идентификатор операции. |
У одной функции может быть несколько критичных условий качества. Их не нужно размазывать по отдельному «NFR-документу»: они должны стать частью сценария, границы задачи и приемки.
Главная проверка
Перед разработкой спросите:
Что будет плохим результатом,
даже если основной сценарий работает?Ответы обычно и показывают NFR:
- работает только на тестовых данных, но падает на большом объеме;
- пользователь видит успех, хотя операция зависла;
- ошибка есть в логах, но поддержка не может найти заявку;
- API совместим по формату, но меняет смысл статуса;
- данные попали в лог;
- повторный запрос создает дубль;
- релиз нельзя безопасно проверить или откатить.
Как вывести NFR из бизнес-языка
Не спрашивайте «какой у вас SLA?», если собеседник не работает с этим термином. Идите от реальной работы и последствий:
| Что нужно узнать | Вопрос без аббревиатур |
|---|---|
| Объем и пики | Сколько операций бывает обычно и в самый тяжелый день? |
| Допустимое время | Когда задержка уже мешает работе и что ломается дальше? |
| Цена сбоя | Что произойдет, если операция не завершится или выполнится дважды? |
| Восстановление | Кто первым узнает о сбое и что он может сделать без разработчика? |
| Данные и доступ | Кто может видеть эти данные и что нельзя писать в логи? |
| Совместимость | Кто уже зависит от текущего формата и сколько времени ему нужно на переход? |
После разговора команда переводит ответы в измеримые границы, сценарии сбоя, правила доступа и сигналы для поддержки. Число нельзя брать из воздуха: у него должен быть источник — текущий пик, договор, регламент, измерение или явное решение владельца.
Сквозной пример: импорт реестра
Возьмем вымышленную задачу: «Дать оператору загружать реестр операций из CSV». Если остановиться на функции, команда сделает выбор файла, кнопку «Загрузить» и экран результата. Но пригодность решения зависит от контекста.
В вымышленном примере владелец процесса уточнил:
- в пиковый день в реестре бывает до 50 000 строк;
- оператору нужен итог не позднее чем через 10 минут после загрузки;
- при неясном ответе оператор повторяет загрузку;
- в файле есть данные, которые нельзя показывать другим подразделениям и писать в логи;
- если часть строк не прошла проверку, нужно понять, что принято, а что исправлять;
- партнеры не смогут перейти на новый формат файла в один день.
Это еще не готовые NFR, но уже источники для них. После проверки измерений, правил и технических ограничений команда фиксирует:
| Зона | Проверяемое условие | Откуда взялась граница | Кто подтверждает |
|---|---|---|---|
| Производительность | Реестр до 50 000 строк завершается за 10 минут в согласованном тестовом контуре. | Пиковый объем и операционное окно. | Владелец процесса и QA. |
| Надежность | Повтор того же файла не создает вторые операции и показывает оператору исход первой загрузки. | Ручной повтор после неясного ответа. | Аналитик и техлид. |
| Целостность данных | Итог хранит число принятых и отклоненных строк; для каждой отклоненной строки есть причина. | Ручная сверка реестра после частичной ошибки. | Владелец процесса и QA. |
| Безопасность | Загружать и скачивать отчет может только согласованная роль; содержимое строк не попадает в application logs. | Класс данных и матрица доступа. | Владелец данных и безопасность. |
| Наблюдаемость и поддержка | Оператор видит статус, время, число строк и correlation id; поддержка находит операцию по correlation id без доступа к содержимому файла. | Текущий ручной разбор инцидента. | Поддержка и техлид. |
| Совместимость | Текущий и предыдущий форматы принимаются в течение согласованного переходного периода. | График перехода партнеров. | Владелец продукта и аналитик. |
Здесь числа не прикидываются командой. Внутри примера у них есть явный источник. В реальной задаче источник нужно проверить, а не заменять «лучшей практикой».
После этого критичные условия нужно перенести в критерии приемки, а границы формата, ошибок, безопасности и совместимости — в контракт интеграции, если сценарий пересекает внешнюю границу.
1. Назвать критичные зоны
Не нужно писать длинный NFR-документ для каждой задачи. Нужно выбрать зоны, которые реально влияют на результат.
Короткая форма:
Задача:
Почему NFR важны:
Критичные зоны:
- Производительность:
- Надежность:
- Безопасность:
- Данные:
- Совместимость:
- Наблюдаемость:
- Поддержка:
Зоны вне scope первой версии:
Что сознательно не закрываем и какой риск принимаем.Если команда не может назвать критичные зоны, стоит провести короткий risk-review до разработки.
2. Перевести NFR в проверяемое условие
Слабые формулировки:
- “быстро”;
- “безопасно”;
- “надежно”;
- “удобно поддерживать”;
- “не ломать старое”;
- “должно логироваться”.
Проверяемые формулировки:
- “оператор видит последнюю ошибку и correlation id”;
- “повторный запрос с тем же ключом не создает второй бизнес-результат”;
- “новое значение статуса не отправляется старому потребителю без feature flag”;
- “персональные данные не попадают в application logs”;
- “smoke-check после deploy открывает основной сценарий и страницу диагностики”;
- “при таймауте заявка остается в статусе ожидания, а не успешного завершения”.
NFR должен заканчиваться критерием, который можно проверить.
3. Связать NFR с acceptance criteria
Если NFR важен, его нужно увидеть в приемке.
Пример:
Если внешний сервис не отвечает 30 секунд,
когда система выполняет повторную попытку,
тогда операция не создает дубль,
остается в статусе ожидания,
а поддержка видит correlation id и время последней попытки.Такой критерий одновременно проверяет надежность, данные, наблюдаемость и поддержку. Это лучше, чем отдельная строка “обработать ошибки”.
4. Отделить обязательное от желательного
Не все NFR одинаково важны для первой версии.
Полезно разделить:
| Уровень | Что означает |
|---|---|
| Обязательно до разработки | Без этого задача не готова или риск слишком дорогой. |
| Обязательно до релиза | Можно начать разработку, но нельзя выпускать без проверки. |
| Осознанное ограничение MVP | Риск принят, есть ручной обход или ясный пересмотр. |
| Будущее улучшение | Не блокирует текущий результат, но должно остаться видимым. |
Это помогает не превращать NFR в бесконечный список идеального продукта.
5. Зафиксировать владельца
Для каждого важного NFR нужен владелец проверки:
- аналитик формулирует сценарий и критерий;
- разработчик или техлид оценивает реализацию и ограничения;
- QA проверяет условия и данные;
- безопасность или эксплуатация подтверждает свою зону;
- тимлид следит, чтобы риск не исчез из потока работы;
- владелец результата принимает ограничение MVP.
Если владельца нет, NFR часто становится общей тревогой, которую никто не закрывает.
6. Когда нужна запись решения
Запись решения полезна, если команда:
- принимает риск не закрывать NFR в первой версии;
- выбирает ручной обход вместо автоматизации;
- меняет совместимость API;
- ограничивает производительность или объем данных;
- откладывает диагностику;
- выбирает безопасность или эксплуатационную границу;
- спорит, какой уровень надежности достаточен.
В записи важно назвать не только выбранный вариант, но и цену, которую команда принимает.
Шаблон NFR-проверки
Контекст:
Какая задача или изменение.
Критичные зоны:
Производительность:
Надежность:
Безопасность:
Данные:
Совместимость:
Наблюдаемость:
Поддержка:
Проверяемые условия:
1. Если ...
2. Если ...
3. Если ...
Ограничения MVP:
Что не закрываем сейчас и почему это допустимо.
Владельцы:
Кто проверяет каждую зону.
Решения:
Что нужно записать отдельно.
Релизная проверка:
Как увидим, что production ведет себя ожидаемо.Антипаттерны
Стоит остановиться, если:
- NFR появляются только перед релизом;
- “надежно” и “безопасно” не имеют проверяемого условия;
- NFR не попадают в acceptance criteria;
- команда принимает ограничение MVP, но не называет риск;
- ответственность за NFR лежит “на всех”;
- review обсуждает реализацию, но не проверяет эксплуатационный риск;
- релизный smoke-check не показывает критичный NFR.
Нефункциональные требования - это не отдельная бюрократическая форма. Это язык, на котором команда заранее договаривается, какой уровень качества нужен, чтобы изменение было пригодно для реальной работы.