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

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

Классификация и виды

Нефункциональные требования охватывают широкий спектр характеристик, которые можно разделить на несколько основных категорий. В зависимости от стандарта (например, ISO/IEC 25010, IEEE 830) и конкретного проекта, классификация может варьироваться, но чаще всего выделяют следующие группы:

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

Требования, связанные с временными характеристиками работы системы:

Время отклика — максимально допустимое время между запросом пользователя и получением ответа (например, не более 2 секунд для 95% запросов).
Пропускная способность — количество операций, транзакций или запросов, которые система может обработать за единицу времени (например, 1000 запросов в секунду).
Масштабируемость — способность системы увеличивать производительность при добавлении ресурсов (например, поддержка 10 000 одновременных пользователей).

Надёжность и доступность (Reliability & Availability)

Требования к стабильности работы и способности системы восстанавливаться после сбоев:

Доступность — процент времени, в течение которого система работоспособна (например, 99,9% — «три девятки»).
Среднее время наработки на отказ (MTBF) — среднее время между двумя последовательными сбоями.
Среднее время восстановления (MTTR) — время, необходимое для восстановления работоспособности после сбоя.
Отказоустойчивость — способность продолжать работу при отказе отдельных компонентов.

Безопасность (Security)

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

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

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

Требования, определяющие лёгкость освоения и использования системы:

Обучаемость — время, необходимое новому пользователю для выполнения базовых задач.
Эффективность — скорость выполнения задач опытным пользователем.
Запоминаемость — способность пользователя вернуться к работе после перерыва без повторного обучения.
Эстетика интерфейса — визуальное оформление, соответствие стандартам (например, ГОСТ Р ИСО 9241).

Поддерживаемость (Maintainability)

Требования к лёгкости внесения изменений, исправления ошибок и адаптации системы:

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

Портативность (Portability)

Требования к возможности переноса системы на другую платформу или среду:

Совместимость — работа с различными операционными системами, браузерами, базами данных.
Переносимость — возможность установки на новое аппаратное обеспечение без существенных доработок.

Другие категории

Интероперабельность — способность взаимодействовать с другими системами (например, обмен данными по протоколу REST или SOAP).
Законодательные и нормативные требования — соответствие законам (например, 152-ФЗ «О персональных данных» в Российской Федерации, GDPR в Европейском союзе).
Эргономика — физические аспекты взаимодействия (например, для аппаратных систем).

Методы определения и документирования

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

SMART-критерии — требования должны быть конкретными (Specific), измеримыми (Measurable), достижимыми (Achievable), релевантными (Relevant) и ограниченными по времени (Time-bound). Например, вместо «система должна быть быстрой» — «время загрузки главной страницы не должно превышать 3 секунд при 1000 одновременных пользователей».
Количественные метрики — числовые показатели (проценты, секунды, количество ошибок на тысячу операций).
Сценарии и атрибуты качества — использование шаблонов (например, шаблон Planguage) для описания контекста, меры, шкалы и контрольного значения.
Прототипирование и моделирование — создание прототипов для оценки удобства использования или производительности.

Значение в разработке

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

В методологиях управления требованиями (например, в Rational Unified Process, Scrum) нефункциональные требования фиксируются отдельно от функциональных и часто включаются в бэклог продукта или документ «Техническое задание» (в российской практике — ГОСТ 34.602-89). В гибких методологиях (Agile) они могут быть представлены в виде «критериев готовности» (Definition of Done) или «историй пользователя» (User Stories) с указанием ограничений.

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

Производительность: «Время обработки запроса на поиск не должно превышать 1 секунды при нагрузке до 500 запросов в секунду».
Надёжность: «Система должна быть доступна 99,9% времени в течение месяца, за исключением плановых простоев».
Безопасность: «Все пароли должны храниться в хешированном виде с использованием алгоритма bcrypt с солью».
Удобство использования: «Новый пользователь должен выполнить регистрацию и первый заказ не более чем за 5 минут без обращения к документации».
Поддерживаемость: «Код должен быть написан на Java 17 с использованием модульной архитектуры, покрытие тестами — не менее 80%».

Связь с функциональными требованиями

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

Проблемы и критика

Сбор и документирование нефункциональных требований сопряжены с рядом трудностей:

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

Для решения этих проблем применяются практики архитектурного анализа, ревью требований, а также использование стандартов качества (например, ISO/IEC 25010:2011 «Systems and software Quality Requirements and Evaluation (SQuaRE)»).

Источники

IEEE Std 830-1998 — Recommended Practice for Software Requirements Specifications.
ISO/IEC 25010:2011 — Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models.
ГОСТ 34.602-89 — Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
Sommerville I. — Software Engineering, 10th Edition, 2015.
Wiegers K., Beatty J. — Software Requirements, 3rd Edition, 2013.
Bass L., Clements P., Kazman R. — Software Architecture in Practice, 3rd Edition, 2012.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →