Привет, Хабр! Я старший системный аналитик, эксперт онлайн-школы по системному анализу Ольги Пономарёвой Материал основан на реальных кейсах из практики: мы в школе System Analyst не просто рассказываем теорию, а делимся тем, что действительно работает на проектах.

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

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

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

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

Функциональные требования всем давно знакомы, но вот какие бывают нефункциональные? Начнем с того, какие вообще категории нефункциональных требований бывают и зачем они нужны. По стандарту ISO 25 010 (да‑да, мы любим стандарты, хоть и ругаем их иногда) НФТ делятся на несколько ключевых категорий, каждая из которых отвечает за свою часть «качества» системы.

Производительность

Это не просто «чтобы моментально загружалось», а конкретные метрики: например, страница должна грузиться не дольше 2 секунд при нагрузке в 1000 rps. Если не прописать эти цифры явно, потом выяснится, что для разработчиков «моментально» — это 5 секунд, а для бизнеса — 0.5.

Безопасность

Данное нефункциональное требование не только про «поставить HTTPS». Сюда входит и аутентификация, и шифрование данных, и соответствие регуляторным требованиям вроде GDPR. Грустно, когда про безопасность вспоминают уже после того, как систему взломали — поэтому лучше прописать эти требования заранее ?

Масштабируемость 

Масштабируемость часто упускают из виду, пока не становится поздно. Система должна не только функционировать здесь и сейчас, но и иметь запас на рост. Например, выдерживать увеличение числа пользователей на 50%. Если этого не предусмотреть, в один прекрасный день ваш успешный сервис рухнет под большим rps.

Надёжность

Это требование определяет, как часто и надолго система может выходить из строя, и как она должна себя вести в случае сбоев. Чаще всего она выражается в процентах доступности (uptime) за определенный период. Ключевая ошибка — соглашаться на абстрактные формулировки. Цифры всегда говорят лучше:

• «99.9%» звучит впечатляюще, но в реальности это разрешает системе простаивать до 8 часов 46 минут в год. Для интернет‑магазина в час распродажи или для банковского приложения такие простои могут обернуться колоссальными репутационными и финансовыми потерями, исчисляемыми миллионами рублей.

• «99.99%» — это уже более строгое требование, допускающее не более 52 минут простоя в год. Такой уровень часто требуется для критически важных сервисов.

Удобство использования

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

• Эргономика и обучаемость: Сколько времени потребуется новому пользователю, чтобы выполнить ключевую задачу? Сколько кликов или действий для этого требуется? Существуют ли отраслевые стандарты или внутренние корпоративные гайдлайны, которых необходимо придерживаться?

• Доступность (Accessibility): Требует ли бизнес соответствия стандартам WCAG (Web Content Accessibility Guidelines)? Это необходимо для обеспечения равного доступа людям с ограниченными возможностями (например, с нарушениями зрения, слуха или моторики). Несоблюдение этих норм не только сужает целевую аудиторию, но и влечет за собой риск судебных исков и крупных штрафов во многих странах и для госучреждений.

• Кросс‑платформенность: Должен ли интерфейс быть одинаково удобным на desktop, mobile и tablet? Требуется ли для мобильных устройств нативное приложение или достаточно адаптивной версии сайта?

Совместимость 

И наконец, совместимость — с какими браузерами, ОС и legacy‑системами должна работать ваша разработка и бизнес. Актуально для корпоративных решений или продуктов, где ещё встречаются Windows XP и IE11. Если не прописать эти требования явно, потом придётся экстренно делать совместимость, когда клиенты начнут жаловаться.

…и чуть менее распространенные нефункциональные требования…

Переносимость

Это про то, насколько легко систему можно перенести на другую инфраструктуру или платформу. Например, если сегодня ваше приложение развернуто на AWS, а завтра бизнес захочет перейти на Google Cloud — насколько болезненным будет этот процесс? Какие задачи будут стоять? Или сможет ли ваша система адаптироваться как к Windows, так и к Linux? Актуально для госпроектов, где вдруг может появиться требование «только отечественное ПО». Если не продумать переносимость заранее, миграция превратится в многомесячный кошмар.

Обслуживаемость

Возможно, самая недооцененная категория. Это требования к тому, насколько легко команда будет поддерживать и развивать систему после сдачи в продакшен. Сюда входит всё: от качества документации и логирования до простоты развертывания новых версий. Яркий пример — когда для исправления мелкого бага команде нужно останавливать всю систему на 3 часа посреди рабочего дня, а это огромные потери для бизнеса. Хорошая обслуживаемость экономит кучу денег и нервов на долгосрочной дистанции.

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

Теперь самое интересное — как вытащить нефункциональные требования из заказчиков. Особенно из тех, кто сам не знает, чего хочет. Если спросить: «Какие у вас требования к производительности?», в 90% случаев получишь что‑то вроде «ну чтобы быстро функционировало» или назовут первое попавшееся значение из головы, ничем не подкрепленное.

Спросить

Банальный и действенный метод. Но задавать стоит не абстрактные вопросы, а максимально конкретные. Пример:

Анализ аналогичных систем

Если делаете приложение интернет-магазина, посмотрите, как ведут себя конкуренты в пиковые часы. Какое у них время отклика, как реализована безопасность. Это даст вам конкретные значения, которые можно положить в основу требований. Особенно полезно, когда заказчик сам не понимает, что ему нужно — можно показать: «Вот так действует наш конкурент, вам так же или лучше?»

Законодательные и отраслевые требования

Последний и важный пункт. Их часто забывают, а потом оказывается, что система/приложение не соответствует каким-нибудь ФЗ. Лучше выяснить наперед, какие нормативные акты и стандарты применяются в конкретной области к вашему продукту/проекту — банковской, медицинской, госсекторе. Поверьте, переделывать систему под требования регуляторов постфактум гораздо дороже.

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

Как удостовериться, что все эти красивые нефункциональные требования не пылятся в документации, а реально соблюдены. 

Начнём с нагрузочного тестирования — нашего главного инструмента для учета производительности. Для решения данной задачи мы на своем проекте используем фреймворк Gatling, который устраивает нашей системе настоящий стресс-тест. Важно не протестировать, как система ведёт себя в штатном режиме, а устроить ей адский час пик — вдруг выяснится, что при 900 пользователях база данных начинает нещадно тормозить, а при 1200 — вообще падает в обморок. 

И да, обязательно проверяйте не только «сухие» цифры RPS, но и поведение системы в час пик — как скоро восстанавливается, нет ли утечек памяти, как ведёт себя кеш. Gatling помогает нам имитировать поведение N пользователей в системе, а потом выдает детальный отчет по ее состоянию: сколько пользователей было на пике, какой был показатель 99 процентиля в мс, сколько было успешных/неуспешных запросов, какие методы тяжеловесные и так далее. Пример такого отчета:

Безопасность — это отдельная песня. Тут нам поможет OWASP Top 10 — как библия всех возможных уязвимостей. Нужно учесть всё: от банальных SQL-инъекций до сложных CSRF-атак. Может получиться весело, когда ваш «супербезопасный» API спокойно отдаёт чужие персональные данные по ID ?

Юзабилити-тестирование — это когда вы наблюдаете, как реальные пользователи ковыряются в вашем интерфейсе и непроизвольно матерятся. A/B-тесты помогут понять, какой вариант интерфейса действительно удобнее, а не просто красивее выглядит. Мы проводим такие тестирования еще на этапе проектирования интерфейсов, реализуя кликабельные прототипы в Figma.

И наконец метрики — SLA, SLO и прочие страшные аббревиатуры. Это наши KPI, по которым мы понимаем, выполняются ли требования на практике. Например, если в SLA описано 99.9% uptime, а система падает каждую неделю — пора бить тревогу. Error Rate покажет, сколько вызовов завершается ошибками — и если показатель растёт, значит, где-то затаился баг, который вот-вот выстрелит. Данные метрики нужно точно описывать в проектной документации.

Вот таблица с ключевыми метриками для нефункциональных требований:

Помните: если требование нельзя протестировать — это не требование, а пожелание. В идеале описать сценарии тестирования для каждой метрики, иметь мок данные. Поэтому всегда продумывайте заблаговременно, как именно вы будете тестировать каждое NFR. Иначе окажется, что вы построили красивый замок, который разваливается от первого же дуновения ветра.

Заключение

Вот и подошли мы к финалу нашей истории про нефункциональные требования. Если вы дочитали до этого места — поздравляю, теперь вы знаете об НФТ чуть больше, чем раньше (я на это надеюсь).

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

Перед тем как отпустить вас в свободное плавание, вот чек-лист, который спасёт не один ваш проект:

• Не ограничивайтесь функциональными требованиями — продумайте все категории НФТ для вашего проекта для более качественной работы. Производительность, безопасность, масштабируемость — это must have, а не nice to have.

• Формулируйте требования по SMART. «Быстро» — не требование, «95% вызовов ≤1 сек при 500 RPS» — требование.

• Договоритесь с командой разработки и тестирования, КАК вы будете тестировать выполнение каждого НФТ. Если требование нельзя протестировать — это не требование, а пожелание.

❗️Запомните: хороший аналитик думает не только о том, ЧТО делает система, но и о том, КАК она это делает. Потому что в реальном мире «работает» и «работает хорошо» — это две большие разницы. Теперь вы знаете, как добиться второго варианта.

Больше полезного по системному анализу — в нашем Telegram-канале. Там делимся кейсами, шаблонами для работы и другими материалами для роста в профессии.