Что такое нефункциональные требования в программной инженерии?

⚡ Умное резюме

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

📘 Определение: Нефункциональное требование (НФТ) описывает, насколько хорошо система работает с точки зрения производительности, безопасности, удобства использования, надежности и переносимости.
🇧🇷 Общие типы: Удобство использования, безопасность, надежность, масштабируемость, производительность, доступность, ремонтопригодность и соответствие нормативным требованиям — вот категории, к которым относятся команды. tracчаще всего.
📊 Модель FURPS+: FURPS+ группирует нефункциональные требования по следующим критериям: функциональность, удобство использования, надежность, производительность, возможность поддержки, а также ограничения, связанные с дизайном или интерфейсом.
🎯 Проверяемые утверждения: Замените слова «быстрый» или «безопасный» числовыми пороговыми значениями и методами проверки, чтобы можно было протестировать и принять нефункциональные требования.
🆚 Функциональный контраст: Функциональные требования описывают, что делает система; нефункциональные требования описывают, насколько хорошо она это делает в реальных условиях.
✅ Воздействие на бизнес: Отсутствие нефункциональных требований является основной причиной производственных инцидентов, замечаний со стороны регулирующих органов и дорогостоящей доработки архитектуры на поздних стадиях разработки.

Читать

Что такое нефункциональное требование?

A Нефункциональное требование Нефункциональные требования (НФТ) определяют качественные характеристики программной системы. НФТ оценивают систему по таким параметрам, как скорость отклика, удобство использования, безопасность, переносимость и другие качественные характеристики, критически важные для успеха. Распространенный пример нефункционального требования: «Как быстро загружается сайт?» Несоответствие нефункциональным требованиям приводит к созданию систем, вызывающих у пользователей разочарование.

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

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

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

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

Удобство использования
исправность
Управляемость
Восстанавливаемость
Безопасность.
Данные Integrity
Рабочий диапазон
Доступность
Масштабируемость
Взаимодействие
Надежность
Ремонтопригодность
Соответствие нормативным требованиям
Экологические ограничения

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

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

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

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

Основные различия между функциональными и нефункциональными требованиями заключаются в следующем:

Параметры	Функциональное требование	Нефункциональное требование
Что это такое?	глагол	Атрибуты
Требование	Это обязательно	Это необязательно
Тип захвата	Он фиксируется в варианте использования.	Это фиксируется как атрибут качества.
Конечный результат	характеристика продукта	Свойства продукта
Захват	Легко захватить	Трудно захватить
Цель	Помогает вам проверить функциональность программного обеспечения.	Помогает вам проверить работоспособность программного обеспечения.
Область внимания	Сосредоточьтесь на требованиях пользователя	Концентрируется на ожиданиях пользователя.
Документация	Опишите, что делает продукт	Описывает, как работает продукт
Тип тестирования	Функциональное тестирование например, системное, интеграционное, сквозное тестирование, тестирование API и т. д.	Нефункциональное тестирование, такое как производительность, стресс, удобство использования, тестирование безопасности и т. д.
Выполнение теста	Выполнение теста выполняется перед нефункциональным тестированием.	После функционального тестирования
Информация о продукции	Особенности продукта	Свойства продукта

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

Основные преимущества Нефункциональное тестирование составляют:

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

Недостатки нефункциональных требований

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

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

Модель FURPS+ для классификации нефункциональных требований

FURPS+ — наиболее широко используемая таксономия для нефункциональных требований. Первоначально разработанная в Hewlett-Packard, она группирует атрибуты качества в пять основных категорий, а также дополнительные ограничения, отмеченные знаком «+». Эта модель помогает бизнес-аналитикам избежать пропуска целого класса требований.

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

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

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

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

Определите качественный атрибут. Сопоставьте проблему с категорией FURPS+, чтобы команда знала, относится ли она к требованиям производительности, удобства использования, безопасности или надежности.
Выберите показатель. Для каждого нефункционального параметра (NFR) необходимо указать единицу измерения — миллисекунды, количество запросов в секунду, количество одновременно работающих пользователей, процент времени безотказной работы или стандарт соответствия, например, ISO 27001.
Установите числовой пороговый уровень. Замените «быстрый» на «менее 400 миллисекунд на 95-м процентиле». Замените «высокая доступность» на «99.9% ежемесячного времени безотказной работы».
Опишите состояние. Укажите нагрузку, среду или сегмент пользователей, к которым применяется пороговое значение, например: «во время пиковых продаж с 10 000 одновременных пользователей».
Определите метод проверки. Обратите внимание на тип теста — нагрузочный тест, тест на проникновение, эксперимент на хаос, аудит доступности — и инструмент, который подтвердит пороговое значение.
Проведите проверку SMART. Перед тем как включить требование в список задач, убедитесь, что оно является конкретным, измеримым, достижимым, актуальным и ограниченным по времени.

Пример перефразирования: «Система должна быть быстрой» превращается в «Страница оформления заказа должна отвечать менее чем за 500 миллисекунд при 95-м процентиле и 5,000 одновременных пользователях, что подтверждено...» JMeter «Проводите нагрузочное тестирование каждого релиза». Пересмотренное заявление позволяет разработчикам проектировать с учетом этого, тестировщикам проверять его, а владельцам продукта принимать его без возражений.

Часто задаваемые вопросы (FAQ)

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

Системы Copilot и GPT преобразуют расплывчатые описания качества в измеримые нефункциональные требования (НФТ) с использованием метрик, пороговых значений, условий и методов проверки. Бизнес-аналитики проверяют каждый черновик на соответствие категориям FURPS+ и структуре SMART, прежде чем принять его в бэклог.

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

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

Выберите метрику с единицей измерения, установите числовой пороговый уровень, опишите условия, при которых она применяется, и укажите метод проверки. Например, время ответа менее 400 миллисекунд на 95-м процентиле при 5,000 пользователях, проверенное с помощью JMeter.

Шифрование данных в состоянии покоя и при передаче, надежность аутентификации, авторизация на основе ролей, ведение журналов аудита, тайм-аут сеанса и соответствие таким стандартам, как ISO 27001, PCI DSS и GDPR, — это нефункциональные требования безопасности, которые документирует большинство команд.

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

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