Представьте, что вы покупаете мотоцикл. Чего вы от него ожидаете? Чтобы он мог разгоняться до 180км/час и при этом не разваливался? Чтобы к нему можно было прикрепить коляску? И не забудем про систему безопасности.

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

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

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

Что это вообще такое?

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

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

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

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

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

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

Теперь, когда общая картина требований понятна, рассмотрим нефункциональные требования подробнее.

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

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

1. Производительность (Performance) — насколько быстро система возвращает результат.

2. Масштабируемость (Scalability) — как изменяется производительность при росте нагрузки.

3. Переносимость (Portability) — на каком оборудовании, операционных системах, браузерах и их версиях может работать система.

4. Совместимость (Compatibility) — не конфликтует ли система с другими приложениями или процессами.

5. Надёжность (Reliability) — как часто происходят критические сбои.

6. Сопровождаемость (Maintainability) — сколько времени требуется для устранения проблемы при её возникновении.

7. Доступность (Availability) — каков средний простой системы.

8. Безопасность (Security) — насколько хорошо защищены система и данные от атак.

9. Удобство использования (Usability) — насколько легко пользователю взаимодействовать с системой.

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

Требования к производительности

Производительность определяет, насколько быстро программная система (или её компонент) реагирует на действия пользователя при определённой нагрузке. Это один из ключевых типов нефункциональных требований — без него не обходится ни одна система.

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

Но в рамках этого раздела мы сосредоточимся на показателях производительности, влияющих на взаимодействие пользователя с системой.

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

• Посадочная страница, поддерживающая 5 000 пользователей в час, должна обеспечивать время отклика не более 6 секунд в браузере Chrome на десктопе, включая загрузку текста и изображений при подключении уровня LTE.

• Результаты поиска по товарам должны отображаться не более чем за 3 секунды в 90% запросов при нормальной нагрузке.

• Система должна быть способна принимать потоки данных со скоростью не менее 1 000 000 записей в минуту из различных источников без потери данных.

• Для обновления данных на дашборде в реальном времени, система должна обновлять и отображать новые аналитические данные в течение 10 секунд после получения новых данных.

Как работать с требованиями к производительности

Начните с рекомендаций Google для обычных веб‑страниц. Google уделяет особое внимание скорости загрузки на десктопах и мобильных устройствах. Поэтому, если вам нужны базовые ориентиры производительности для публичных веб‑страниц, используйте сервис Google PageSpeed Insights. Он поможет оценить время полной загрузки, время до полного рендера, отклик интерфейса на действия пользователя.

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

Базовые рекомендации по времени отклика появились еще в 1993 году, их выделил Якоб Нильсен и они представляют собой три ключевых порога времени реакции системы. Несмотря на то, что эти значения появились давно, они по‑прежнему актуальны, поскольку основаны на особенностях восприятия и внимания человека:

Как правило, до 10 секунд доходить нельзя, потому что около 55% пользователей покидают сайт, если он грузится дольше 3 секунд.

А согласно исследованию Portent:

«Сайт, загружающийся за 1 секунду, имеет конверсию в 3 раза выше, чем сайт, загружающийся за 5 секунд».

То есть время в прямом смысле деньги.

Что нужно учесть

Уточняйте сценарий измерения производительности. При формулировании требований важно указать что именно измеряется и включает ли метрика только время доставки данных до браузера (время ответа сервера) или полное время рендера страницы?

Если разные типы контента загружаются с разной скоростью, то для каждого из них нужны отдельные ограничения.

Также уточняйте нагрузочный сценарий. Если, к примеру, днем на сайте 5000 активных пользователей, а ночью 1000, необходимо указать, к какому сценарию относится метрика (средняя нагрузка, пиковая или стресс‑тест). Иногда фиксируют оба варианта.

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

Требования к масштабируемости

Масштабируемость определяет, при какой максимальной нагрузке система всё ещё способна соответствовать требованиям к производительности и удобству использования. Важно понимать, что масштабируемость относится к способности системы справляться с ростом как объёма данных, так и нагрузки со стороны пользователей.

Существует два основных способа масштабирования системы по мере увеличения нагрузки:

1. Горизонтальное масштабирование — добавление новых серверов в пул ресурсов.

2. Вертикальное масштабирование — увеличение мощности существующих серверов (добавление CPU, RAM и так далее).

Таким образом, ключевая цель требований к масштабируемости — обеспечить, чтобы система оставалась стабильной и сохраняла требуемый уровень производительности при увеличении числа пользователей, объема данных, количества бизнес‑процессов, количества модулей и интеграций.

Примеры требований к масштабируемости

• Веб‑сайт должен масштабироваться до 1 000 000 одновременных посещений, сохраняя оптимальную производительность.

• ERP‑система должна быть способна увеличивать объёмы хранения и обработки данных по мере роста компании, включая потенциальное увеличение числа транзакций в 10 раз за пять лет.

• Система мониторинга IoT‑устройств должна поддерживать масштабирование с 10 000 до 500 000 устройств, без потери точности данных или снижения качества наблюдения.

• eCommerce‑платформа должна быть способна выдерживать рост трафика на 300% в периоды распродаж или сезонных пиков без ухудшения времени отклика и доступности сервиса.

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

1. Определяйте ожидания с точки зрения бизнеса. Сначала оцените текущую нагрузку: количество пользователей, транзакций, объём данных. Затем определите прогноз роста. Сколько пользователей планируется поддерживать в будущем? Какие рынки предполагается расширять? Какие новые модули или функции могут быть добавлены позже?

2. Учитывайте особенности отрасли. Например для eCommerce, игр, видеостриминга критичен рост числа пользователей. Если мы говорим про финтех или банки, ключевыми параметрами будут являться скорость и объем транзакций.

3. Делайте требования измеримыми. Используйте конкретные параметры, такие как количество одновременных пользователей, объем данных, скорость обработки транзакций, время отклика при максимальной нагрузке.

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

Требования к доступности

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

Доступность один из наиболее критичных бизнес‑показателей, но чтобы корректно определить ее, необходимо так же учитывать надежность (то есть как часто случаются сбои) и сопровождаемость (как быстро система восстанавливается.

Примеры требований к доступности

• Дашборд должен быть доступен пользователям из РФ 99.98% времени в месяц в рабочие часы по МСК.

• Приложение должно обеспечивать стабильную работу на разных устройствах с уровнем надёжности 99%.

• Видеостриминг должен быть непрерывным 99,8% времени при нормальных сетевых условиях.

Как формулировать требования к доступности

1. Начните с бизнес‑ограничений. Поймите, допустимо ли, чтобы приложение было недоступно 5% времени? Какой финансовый или KPI‑ущерб это создаст? Полностью безотказных систем не существует в природе, нужно определить критический порог.

2. Уточните, для какого компонента определяется доступность. Часто разные части системы имеют разные SLA, например платежные модули, лендинги, админ‑панель.

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

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

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

Продолжить осваивать базу системного анализа — от фиксации требований до проектирования интерфейсов и API — можно на курсе «Системный аналитик. Basic». Это практический курс: научитесь формулировать NFR, декомпозировать и приоритизировать требования, оформлять документацию и проводить приёмку.

Чтобы оставаться в курсе актуальных технологий и трендов, подписывайтесь на Telegram-канал OTUS.