В инженерных систем и требований техники , нефункциональные требования (NFR) является требование , которое определяет критерии , которые могут быть использованы для оценки работы системы, а не конкретное поведение. Они противопоставляются функциональным требованиям, которые определяют конкретное поведение или функции. План реализации функциональных требований подробно описан в системе проектирования . План реализации нефункциональных требований подробно описан в архитектуре системы , поскольку они обычно являются архитектурно значимыми требованиями .[1]
Определение
В широком смысле функциональные требования определяют, что система должна делать, а нефункциональные требования определяют, какой должна быть система . Функциональные требования обычно имеют форму «система должна выполнять <требование>», отдельное действие или часть системы, возможно, явно в смысле математической функции , ввода, вывода описания черного ящика , функциональной модели процесса и управления или Модель IPO . Напротив, нефункциональные требования имеют форму «система должна быть <требование>», общее свойство системы в целом или конкретного аспекта, а не конкретной функции. Общие свойства системы обычно определяют разницу между успехом или неудачей проекта разработки.
Нефункциональные требования часто называют « атрибутами качества » системы, однако между ними есть различие. Нефункциональные требования - это критерии для оценки того, как программная система должна работать, и программная система должна иметь определенные атрибуты качества, чтобы соответствовать нефункциональным требованиям. Поэтому, когда мы говорим, что система должна быть «безопасной», «высокодоступной», «переносимой», «масштабируемой» и так далее, мы говорим о ее характеристиках качества. Другими терминами нефункциональных требований являются «качества», «цели качества», «требования к качеству обслуживания», «ограничения», «неповеденческие требования» [2] или «технические требования». [3] Неофициально их иногда называют « способностями », исходя из таких атрибутов, как стабильность и переносимость. Качества, то есть нефункциональные требования, можно разделить на две основные категории:
- Качество исполнения, такое как безопасность, защищенность и удобство использования, наблюдаемые во время работы (во время выполнения).
- Эволюционные качества, такие как тестируемость , ремонтопригодность, расширяемость и масштабируемость, которые воплощены в статической структуре системы. [4] [5]
Примеры
От системы может потребоваться предоставить пользователю отображение количества записей в базе данных. Это функциональное требование. Насколько актуальным должен быть этот номер, - это нефункциональное требование. Если число необходимо обновлять в режиме реального времени , системные архитекторы должны гарантировать, что система способна отображать количество записей в приемлемо коротком интервале изменения количества записей.
Достаточная пропускная способность сети может быть нефункциональным требованием системы. Другие примеры включают:
- Доступность
- Адаптивность
- Проверяемость и контроль
- Доступность (см. Соглашение об уровне обслуживания )
- Резервное копирование
- Время загрузки
- Емкость , текущая и прогноз
- Сертификация
- Согласие
- Управление конфигурацией
- Стоимость , начальная стоимость и стоимость жизненного цикла
- Целостность данных
- Хранение данных
- Зависимость от других сторон
- Развертывание
- Среда разработки
- Аварийное восстановление
- Документация
- Долговечность
- КПД (потребление ресурсов при заданной нагрузке)
- Эффективность (результативность по отношению к усилиям)
- Эластичность
- Эмоциональные факторы (например, веселье, увлечение или наличие фактора «Вау!»)
- Защита окружающей среды
- Условное депонирование
- Возможность использования
- Расширяемость (добавление функций и перенос настроек при следующем обновлении основной версии)
- Управление отказами
- Отказоустойчивость (например, мониторинг, измерение и управление операционной системой)
- Гибкость (например, чтобы справиться с будущими изменениями требований)
- Уменьшение следа - уменьшить размер exe-файлов
- Интегрирование способность интегрировать компоненты
- Интернационализация и локализация
- Совместимость
- Юридические и лицензионные вопросы или возможность предотвращения нарушения патентных прав
- Ремонтопригодность (например, среднее время ремонта - MTTR)
- Управление
- Оптимизация памяти
- Возможность модификации
- Топология сети
- Открытый источник
- Работоспособность
- Производительность / время отклика (разработка производительности )
- Совместимость платформ
- Конфиденциальность (соблюдение законов о конфиденциальности )
- Портативность
- Качество (например, обнаруженные неисправности, доставленные неисправности, эффективность устранения неисправностей )
- Читаемость
- Надежность (например, среднее время наработки на отказ / наработка на отказ - MTBF / MTTF)
- Составление отчетов
- Устойчивость
- Ограничения ресурсов (скорость процессора, память, дисковое пространство, пропускная способность сети и т. Д.)
- Время отклика
- Возможность повторного использования
- Надежность
- Безопасность или запас прочности
- Масштабируемость (горизонтальная, вертикальная)
- Безопасность (кибер и физическая)
- Программное обеспечение, инструменты, стандарты и т. Д. Совместимость
- Стабильность
- Поддерживаемость
- Тестируемость
- Пропускная способность
- Прозрачность
- Юзабилити (человеческий фактор) целевым сообществом пользователей
- Объем
Смотрите также
- ИСО / МЭК 25010 : 2011
- Консорциум по качеству ИТ-программного обеспечения
- ИСО / МЭК 9126
- Шубы
- Анализ требований
- Требования к юзабилити
- Структура нефункциональных требований
- Архитектурно значимые требования
- Пункты SNAP
Рекомендации
- ^ Чен, Ляньпин; Али Бабар, Мухаммед; Нусейбе, Башар (2013). «Характеризация архитектурно значимых требований». Программное обеспечение IEEE . 30 (2): 38–45. DOI : 10.1109 / MS.2012.174 . ЛВП : 10344/3061 .
- ^ Стеллман, Эндрю; Грин, Дженнифер (2005). Управление прикладными программными проектами . O'Reilly Media . п. 113. ISBN 978-0-596-00948-9. Архивировано из оригинала на 2015-02-09.
- ^ Эмблер, Скотт. «Технические (нефункциональные) требования: гибкое введение» . Гибкое моделирование . Ambysoft Inc . Проверено 5 октября 2018 года .
- ^ Вигерс, Карл; Битти, Джой (2013). Требования к программному обеспечению, третье издание . Microsoft Press. ISBN 978-0-7356-7966-5.
- ^ Янг, Ральф Р. (2001). Эффективные практики требований . Эддисон-Уэсли. ISBN 978-0-201-70912-4.
Внешние ссылки
- Петтер Л. Х. Эйде (2005). «Количественная оценка и прослеживаемость требований» . Idi.ntnu.bo . Проверено 3 октября 2017 года .
- Далби, Джон. «Нефункциональные требования» . Csc.calpoly.edu . Проверено 3 октября 2017 года .
- «Моделирование нефункциональных аспектов в сервис-ориентированной архитектуре» (PDF) . Cs.umb.edu . Архивировано из оригинального (PDF) 24 июля 2011 года . Проверено 3 октября 2017 года .
- «Нефункциональные требования: действительно ли помогают истории пользователей?» . Methodsandtools.com . Проверено 3 октября 2017 года .
- «Нефункциональные требования здесь - CISQ - Консорциум по качеству программного обеспечения ИТ» . it-cisq.org . Проверено 3 октября 2017 года .