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

Конспект статьи. Автор оригинала: nortuldra (Наталья, МТС)

Ведущий системный аналитик МТС объясняет, зачем нужны нефункциональные требования (НФТ) и как их находить. Исходный пример: функция в системе есть, но работает так, что пользоваться ей неудобно или невозможно. Команды много обсуждают, что делает система, и почти не говорят о том, как она это делает.

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

Зачем их формализовать

Договорённости о качестве существуют всегда, но если они не записаны, то живут только в головах ключевых разработчиков. Когда эти люди уходят, новичкам приходится восстанавливать требования методом проб и ошибок.

FURPS+

• F — функциональность;
• U — удобство использования: эргономика, обучаемость, адаптивность;
• R — надёжность: доступность, отказоустойчивость, резервное копирование;
• P — производительность: время отклика, пропускная способность, масштабируемость;
• S — поддерживаемость: тестируемость, документированность, совместимость;
• «+» — дополнительные категории под проект, например соответствие GDPR.

Где взять НФТ

Задавать конкретные вопросы: какая нагрузка в час пик, какое время отклика допустимо, что происходит при сбоях, как часто делать резервные копии, как защищены персональные данные, нужен ли PCI DSS, допустим ли простой, какие SLA у похожих систем. Главное — перевести пожелания в измеримые критерии: не «максимально быстро», а «расчёт стоимости услуги в сети 3G не дольше 2 секунд». Полезно также договориться о приоритетах, например что для модуля доступность важнее скорости.

НФТ собираются постоянно

Пример — распродажа крупного ритейлера, когда сайт не выдержал пиковой нагрузки из-за несогласованности маркетинга и ИТ. Разбор инцидентов даёт новые требования к отказоустойчивости и мониторингу, а вопрос «что будет через три года при росте данных в десять раз» помогает заложить масштабируемость.

С чего начать

• сделать раздел НФТ обязательным в ТЗ для новых функций;
• после каждого инцидента формулировать требование, которое не даст проблеме повториться;
• прописать НФТ для 3–5 самых важных пользовательских сценариев.