Нефункциональное требование
В системной инженерии и разработке требований ( нефункциональное требование NFR ) — это требование , определяющее критерии, которые можно использовать для оценки работы системы, а не конкретного поведения. Им противопоставляются функциональные требования , которые определяют конкретное поведение или функции. План реализации функциональных требований подробно описан в системы проекте . План реализации нефункциональных требований подробно описан в системы архитектуре , поскольку они обычно являются архитектурно значимыми требованиями . [1]
В архитектуре программного обеспечения нефункциональные требования известны как «архитектурные характеристики». Обратите внимание, что синхронная связь между компонентами архитектуры программного обеспечения запутывает их, и они должны иметь одни и те же архитектурные характеристики. [2]
Определение
[ редактировать ]система В широком смысле функциональные требования определяют, что должна делать , а нефункциональные требования определяют, какой система должна быть . Функциональные требования обычно имеют форму «система должна выполнять <требование>», отдельное действие или часть системы, возможно, явно в смысле математической функции , описания входных и выходных данных черного ящика , функциональной модели процесса и управления или Модель IPO . Напротив, нефункциональные требования имеют форму «система должна быть <требование>», общее свойство системы в целом или конкретного аспекта, а не конкретной функции. Общие свойства системы обычно определяют разницу между успехом или неудачей проекта разработки.
Нефункциональные требования часто называют « атрибутами качества » системы. Другими терминами для нефункциональных требований являются «качества», «цели качества», «требования к качеству обслуживания», «ограничения», «неповеденческие требования». [3] или «технические требования». [4] Неофициально их иногда называют « способностями » из-за таких атрибутов, как стабильность и мобильность. Качества, то есть нефункциональные требования, можно разделить на две основные категории:
- Качества исполнения, такие как безопасность, защищенность и удобство использования, которые можно наблюдать во время работы (во время выполнения).
- Качества эволюции, такие как тестируемость , ремонтопригодность, расширяемость и масштабируемость, которые воплощены в статической структуре системы. [5] [6]
Важно определить нефункциональные требования конкретным и измеримым способом. [7] [8]
Примеры
[ редактировать ] | Эта статья нуждается в дополнительных цитатах для проверки . ( февраль 2023 г. ) |
Может потребоваться, чтобы система предоставила пользователю отображение количества записей в базе данных. Это функциональное требование. Насколько актуальным должно быть это число, является нефункциональным требованием. Если число необходимо обновлять в режиме реального времени , архитекторы системы должны гарантировать, что система способна отображать количество записей в течение приемлемо короткого интервала изменения количества записей.
Достаточная пропускная способность сети может быть нефункциональным требованием системы. Другие примеры включают в себя:
- Доступность
- Адаптивность
- Аудитируемость и контроль
- Доступность (см. соглашение об уровне обслуживания )
- Резервное копирование
- Время загрузки
- Мощность , текущая и прогнозируемая
- Сертификация
- Согласие
- Управление конфигурацией
- Соответствие
- Стоимость, первоначальная стоимость и стоимость жизненного цикла
- Целостность данных
- Хранение данных
- Зависимость от других сторон
- Развертывание
- Среда разработки
- Аварийное восстановление
- Документация
- Долговечность
- Эффективность (потребление ресурсов при заданной нагрузке)
- Эффективность (результат производительности по отношению к затраченным усилиям)
- Эластичность
- Эмоциональные факторы (например, веселье, увлекательность или «Вау! Фактор»)
- Защита окружающей среды
- Условное депонирование
- Возможность использования
- Расширяемость (добавление функций и перенос настроек при следующем обновлении основной версии)
- Управление отказами
- Отказоустойчивость (например, мониторинг, измерение и управление операционной системы)
- Гибкость (например, для реагирования на будущие изменения требований)
- Уменьшение занимаемого места - уменьшите размер exe-файлов.
- Интегрируемость (например, способность интегрировать компоненты)
- Интернационализация и локализация
- Совместимость
- Юридические и лицензионные вопросы или возможность избежать нарушения патентных прав
- Ремонтопригодность (например, среднее время ремонта – MTTR)
- Управление
- Оптимизация памяти
- Модифицируемость
- Топология сети
- Открытый исходный код
- Работоспособность
- Производительность /время отклика ( инженерия производительности )
- платформы Совместимость
- Конфиденциальность (соблюдение законов о конфиденциальности )
- Портативность
- Качество устранения неисправностей (например, обнаруженные неисправности, выявленные неисправности, эффективность )
- Читабельность
- Надежность (например, среднее время между отказами/до отказа – MTBF/MTTF)
- Отчетность
- Устойчивость
- Ограничения ресурсов (скорость процессора, память, дисковое пространство, пропускная способность сети и т. д.)
- Время ответа
- Многоразовое использование
- Надежность
- Безопасность или коэффициент безопасности
- Масштабируемость (горизонтальная, вертикальная)
- Безопасность (кибер и физическая)
- Программное обеспечение, инструменты, стандарты и т. д. Совместимость
- Стабильность
- Поддержка
- Тестируемость
- Пропускная способность
- Прозрачность
- Юзабилити (человеческий фактор) по целевому сообществу пользователей
- Объемное тестирование
См. также
[ редактировать ]- ИСО/МЭК 25010 :2011
- Консорциум по качеству ИТ-программного обеспечения
- ИСО/МЭК 9126
- ФУРПС
- Анализ требований
- Требования к удобству использования
- Структура нефункциональных требований
- Архитектурно значимые требования
- Баллы SNAP
Ссылки
[ редактировать ]- ^ Чен, Ляньпин; Али Бабар, Мухаммед; Нусейбе, Башар (2013). «Характеристика архитектурно значимых требований». Программное обеспечение IEEE . 30 (2): 38–45. дои : 10.1109/MS.2012.174 . hdl : 10344/3061 . S2CID 17399565 .
- ^ Основы архитектуры программного обеспечения: инженерный подход . 2020. ISBN 978-1492043454 .
- ^ Стеллман, Эндрю; Грин, Дженнифер (2005). Управление проектами прикладного программного обеспечения . О'Рейли Медиа . п. 113. ИСБН 978-0-596-00948-9 . Архивировано из оригинала 9 февраля 2015 г.
- ^ Эмблер, Скотт. «Технические (нефункциональные) требования: гибкое введение» . Гибкое моделирование . Компания Ambysoft Inc. Проверено 5 октября 2018 г.
- ^ Вигерс, Карл; Битти, Джой (2013). Требования к программному обеспечению, третье издание . Майкрософт Пресс. ISBN 978-0-7356-7966-5 .
- ^ Янг, Ральф Р. (2001). Практика эффективных требований . Аддисон-Уэсли. ISBN 978-0-201-70912-4 .
- ^ Циммерманн, Олаф; Стокер, Мирко (2021). Репозиторий практики проектирования . ЛинПаб.
- ^ Глинц, Мартин (2008). «Ориентированный на риски и ценностно-ориентированный подход к требованиям к качеству» (PDF) . Программное обеспечение IEEE . 25 (2): 34–41. дои : 10.1109/MS.2008.31 . S2CID 19015424 .
Внешние ссылки
[ редактировать ]- Петтер Л. Х. Эйде (2005). «Количественная оценка и отслеживаемость требований». CiteSeerX 10.1.1.95.6464 .
- Долби, Джон. «Нефункциональные требования» . Csc.calpoly.edu . Проверено 3 октября 2017 г.
- «Моделирование нефункциональных аспектов сервис-ориентированной архитектуры» (PDF) . Cs.umb.edu . Архивировано из оригинала (PDF) 24 июля 2011 года . Проверено 3 октября 2017 г.
- «Нефункциональные требования: действительно ли помогают пользовательские истории?» . Methodsandtools.com . Проверено 3 октября 2017 г.
- «Нефункциональные требования будут здесь — CISQ — Консорциум по качеству ИТ-программного обеспечения» . it-cisq.org . Проверено 3 октября 2017 г.
- " "Отвечают ли архитектуры программного обеспечения дополнительным функциональным или нефункциональным требованиям?" " . 19 ноября 2020 г.
| Качества |
| ||||
|---|---|---|---|---|---|
| Стандарты и списки | |||||
| Процессы | |||||
| Базы данных органов управления : Национальные |
|---|
