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

В системной инженерии и разработке требований ( нефункциональное требование NFR ) — это требование , определяющее критерии, которые можно использовать для оценки работы системы, а не конкретного поведения. Им противопоставляются функциональные требования , которые определяют конкретное поведение или функции. План реализации функциональных требований подробно описан в системы проекте . План реализации нефункциональных требований подробно описан в системы архитектуре , поскольку они обычно являются архитектурно значимыми требованиями . ^[1]

В архитектуре программного обеспечения нефункциональные требования известны как «архитектурные характеристики». ^[2]

Определение [ править ]

система В широком смысле функциональные требования определяют, что должна делать , а нефункциональные требования определяют, какой должна быть система . Функциональные требования обычно имеют форму «система должна выполнять <требование>», отдельное действие или часть системы, возможно, в явном виде в смысле математической функции , описания входных и выходных данных черного ящика , функциональной модели процесса и управления или Модель IPO . Напротив, нефункциональные требования имеют форму «система должна быть <требование>», общее свойство системы в целом или конкретного аспекта, а не конкретной функции. Общие свойства системы обычно определяют разницу между успехом или неудачей проекта разработки.

Нефункциональные требования часто называют « атрибутами качества » системы. Другими терминами для нефункциональных требований являются «качества», «цели качества», «требования к качеству обслуживания», «ограничения», «неповеденческие требования». ^[3] или «технические требования». ^[4] Неофициально их иногда называют « способностями » из-за таких атрибутов, как стабильность и мобильность. Качества, то есть нефункциональные требования, можно разделить на две основные категории:

Качества исполнения, такие как безопасность, защищенность и удобство использования, которые можно наблюдать во время работы (во время выполнения).
Качества эволюции, такие как тестируемость , ремонтопригодность, расширяемость и масштабируемость, которые воплощены в статической структуре системы. ^[5]^[6]

Важно определить нефункциональные требования конкретным и измеримым образом. ^[7]^[8]

Примеры [ править ]

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

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

Доступность
Адаптивность
Аудитируемость и контроль
Доступность (см. соглашение об уровне обслуживания )
Резервное копирование
Время загрузки
Мощность , текущая и прогнозируемая
Сертификация
Согласие
Управление конфигурацией
Соответствие
Стоимость, первоначальная стоимость и стоимость жизненного цикла
Целостность данных
Хранение данных
Зависимость от других сторон
Развертывание
Среда разработки
Аварийное восстановление
Документация
Долговечность
Эффективность (потребление ресурсов при заданной нагрузке)
Эффективность (результат производительности по отношению к затраченным усилиям)
Эластичность
Эмоциональные факторы (например, веселье, увлекательность или «Вау! Фактор»)
Защита окружающей среды
Условное депонирование
Возможность использования
Расширяемость (добавление функций и перенос настроек при следующем обновлении основной версии)
Управление отказами
Отказоустойчивость (например, мониторинг, измерение и управление операционной системы)
Гибкость (например, для реагирования на будущие изменения требований)
Уменьшение занимаемого места - уменьшите размер exe-файлов.
Интегрируемость (например, способность интегрировать компоненты)
Интернационализация и локализация
Совместимость
Юридические и лицензионные вопросы или возможность избежать нарушения патентных прав
Ремонтопригодность (например, среднее время ремонта – MTTR)
Управление
Оптимизация памяти
Модифицируемость
Топология сети
Открытый исходный код
Работоспособность
Производительность /время отклика ( инженерия производительности )
платформы Совместимость
Конфиденциальность (соблюдение законов о конфиденциальности )
Портативность
Качество устранения неисправностей (например, обнаруженные неисправности, выявленные неисправности, эффективность )
Читабельность
Надежность (например, среднее время между отказами/до отказа – MTBF/MTTF)
Отчетность
Устойчивость
Ограничения ресурсов (скорость процессора, память, дисковое пространство, пропускная способность сети и т. д.)
Время ответа
Многоразовое использование
Надежность
Безопасность или коэффициент безопасности
Масштабируемость (горизонтальная, вертикальная)
Безопасность (кибер и физическая)
Программное обеспечение, инструменты, стандарты и т. д. Совместимость
Стабильность
Поддержка
Тестируемость
Пропускная способность
Прозрачность
Юзабилити (человеческий фактор) по целевому сообществу пользователей
Объемное тестирование

См. также [ править ]

Ссылки [ править ]

^ Чен, Ляньпин; Али Бабар, Мухаммед; Нусейбе, Башар (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 г.

[ASR_Chen-1] Чен, Ляньпин; Али Бабар, Мухаммед; Нусейбе, Башар (2013). «Характеристика архитектурно значимых требований». Программное обеспечение IEEE . 30 (2): 38–45. дои : 10.1109/MS.2012.174 . hdl : 10344/3061 . S2CID 17399565 .

[2] Основы архитектуры программного обеспечения: инженерный подход . 2020. ISBN 978-1492043454 .

[3] Стеллман, Эндрю; Грин, Дженнифер (2005). Управление проектами прикладного программного обеспечения . О'Рейли Медиа . п. 113. ИСБН 978-0-596-00948-9 . Архивировано из оригинала 9 февраля 2015 г.

[4] Эмблер, Скотт. «Технические (нефункциональные) требования: гибкое введение» . Гибкое моделирование . Компания Ambysoft Inc. Проверено 5 октября 2018 г.

[Wiegers13-5] Вигерс, Карл; Битти, Джой (2013). Требования к программному обеспечению, третье издание . Майкрософт Пресс. ISBN 978-0-7356-7966-5 .

[Young01-6] Янг, Ральф Р. (2001). Практика эффективных требований . Аддисон-Уэсли. ISBN 978-0-201-70912-4 .

[7] Циммерманн, Олаф; Стокер, Мирко (2021). Репозиторий практики проектирования . ЛинПаб.

[MGUZH-8] Глинц, Мартин (2008). «Ориентированный на риск и ценностный подход к требованиям к качеству» (PDF) . Программное обеспечение IEEE . 25 (2): 34–41. дои : 10.1109/MS.2008.31 . S2CID 19015424 .

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]