Всем привет! Меня зовут Наталья, я ведущий системный аналитик в MWS. В ИТ полно примеров того, как попытки решить задачу приводят к появлению совершенно непригодных инструментов. Формально они работают, но пользоваться ими либо крайне неудобно, либо невозможно. Кнопку вроде сделали, но кривую и не там. Сайт работает, но падает под нагрузкой. Парковку предусмотрели, но только для 10% клиентов.

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

Помните этот эпизод из «Приключений Алисы в Стране чудес» Льюиса Кэрролла?

«Дверей в зале было множество, но все оказались заперты; Алиса попробовала открыть их — сначала с одной стороны, потом с другой, но, убедившись, что ни одна не поддается, она прошла по залу, с грустью соображая, как ей отсюда выбраться. Вдруг она увидела стеклянный столик на трех ножках; на нем не было ничего, кроме крошечного золотого ключика, и Алиса решила, что это ключ от одной из дверей, но — увы! — то ли замочные скважины слишком велики, то ли ключик слишком мал, только он не подошел ни к одной, как она ни старалась. Пройдясь по залу во второй раз, Алиса увидела занавеску, которую не заметила раньше, а за ней оказалась маленькая дверца дюймов в пятнадцать вышиной. Алиса вставила ключик в замочную скважину — и, к величайшей ее радости, он подошел!

Она открыла дверцу и увидела за ней нору, совсем узкую, не шире крысиной, встала на колени и заглянула в нее — нора вела в сад удивительной красоты. Ах, как ей захотелось выбраться из темного зала и побродить между яркими цветочными клумбами и прохладными фонтанами. Но она не могла просунуть в нору даже голову. “Даже если б моя голова и прошла, — подумала бедная Алиса, — что толку! Кому нужна голова без плечей? Ах, почему я не складываюсь, как подзорная труба! Если б я только знала, с чего начать, я бы, наверное, сумела”».

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

• не подумали про совместимость — размер ключа не соответствует замочной скважине;

• не учли удобство использования — стол на трех ножках вызывает вопросы, а дверь высотой в 15 дюймов (38,1 см) и вовсе делает попытку пройти бессмысленной;

• не вспомнили про концептуальную целостность — судя по всему, последнюю дверь делали «другие подрядчики», раз спрятали ее за занавеской, нарушив единый стиль.

Что такое НФТ

Нефункциональные требования (NFR, Non-Functional Requirements) описывают качество работы системы — то, как система должна работать. Если функциональные требования отвечают на вопрос «что?», то нефункциональные — на вопросы «как?», «когда?», «где?» и «сколько?». Именно NFR напрямую влияют на то, понравится ли продукт клиентам и захотят ли они его использовать.

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

Как описать НФТ

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

Для классификации требований к ПО существует международный стандарт ISO 25010, но это не единственный подход. Широко используется модель FURPS+, предложенная Hewlett-Packard еще в начале 1990-х. Она помогает не упустить важные аспекты.

Модель FURPS+

• F — Functionality (функциональность) — классические функциональные требования. Пример: нужна возможность выбора способа доставки на этапе оформления заказа.

• U — Usability (удобство использования) — характеристики, определяющие удобство и привлекательность системы: эргономика, эстетика, интуитивность, обучаемость. Пример: адаптивный дизайн, который подстраивается под разные размеры экранов.

• R — Reliability (надежность) — способность системы работать без сбоев и восстанавливаться после них: доступность, непрерывность, отказоустойчивость. Пример: наличие резервного копирования и автоматического восстановления после сбоя.

• P — Performance (производительность) — скорость и эффективность работы: время отклика, пропускная способность, масштабируемость. Пример: система должна обрабатывать не менее 1000 запросов в секунду при нагрузке до 10 000 одновременных пользователей.

• S — Supportability (поддерживаемость) — легкость сопровождения и модификации: тестируемость, документированность, совместимость. Пример: система должна быть написана на языке Python с использованием фреймворка Django.

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

Где брать НФТ и как их не упустить

В погоне за работоспособностью продукта нефункциональные требования часто остаются в тени. Но именно они определяют архитектуру и съедают значительную часть бюджета. Согласитесь: устройство системы, которая должна обслуживать удаленных пользователей 24/7, отличается от той, что работает только с парой сотрудников в офисе с 9 до 18. 

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

• Какая максимальная нагрузка системы ожидается в час пик?

• Какая должна быть скорость отклика системы при выполнении запросов (например, время загрузки страницы, время обработки оплаты)?

• Как система будет реагировать на сбои в работе (например, автоматическое переключение на резервный сервер)?

• Как часто должна проводиться резервная копия данных пользователей и как долго они должны храниться?

• Какие меры защиты используются для защиты персональных данных пользователей (например, шифрование, двухфакторная аутентификация)?

• Как система защищена от атак DDoS и других киберугроз?

• Как система обрабатывает и хранит платежные данные (например, соответствует ли система требованиям PCI DSS)?

• Готовы ли пользователи смириться с прерыванием работы или им критически важен непрерывный доступ?

• Должна ли система соответствовать законодательным нормам (в сфере безопасности, персональных данных и так далее)? Требуется ли лицензирование?

• Какие системы решали похожую задачу ранее? Каковы были их соглашения об уровне обслуживания (SLA)?

• Существуют ли готовые паттерны архитектуры и DevOps, политики безопасности (в части шифрования, аутентификации и так далее)?

Ваша главная задача на этом этапе — перевести расплывчатые пожелания в измеримые критерии, исключающие разночтения.

• Плохо: «Приложение должно максимально быстро реагировать на действия пользователя».

• Хорошо: «Пользователь, находясь в сети 3G, должен получать расчет стоимости услуги не более чем за 2 секунды».

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

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

Сбор НФТ — это не разовая акция, а непрерывный процесс. Встройте его в свои рабочие ритуалы:

• анализируйте сбои — это отличный источник требований по отказоустойчивости и мониторингу;

• представляйте путь развития системы. Задайте себе вопрос: «Что будет через три года, когда данных станет в 10 раз больше?». Ответ на него поможет заложить масштабируемость заранее.

С чего начать, если раньше НФТ никто не писал

Не пытайтесь объять необъятное и задокументировать все требования для уже работающей системы. Это демотивирует и займет вечность. Попробуйте начать с малого:

• сделайте раздел с НФТ в техническом задании обязательным для нового функционала и значимых изменений;

• на ретроспективах по инцидентам спрашивайте: «Какое формальное требование мы можем записать, чтобы эта проблема больше не повторилась?»;

• возьмите 3–5 самых важных пользовательских сценариев и пропишите НФТ специально для них.

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

Но этих проблем можно избежать. Документирование НФТ фиксирует ожидания бизнеса, задает четкие критерии качества и синхронизирует взгляды заказчиков, разработчиков и администраторов. Это снижает риски, экономит деньги и, в конечном счете, помогает создавать системы, которые не просто работают, а делают это удобно, надежно и предсказуемо.