Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

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

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

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

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

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

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

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

  • ИСО / МЭК 25010 : 2011
  • Консорциум по качеству ИТ-программного обеспечения
  • ИСО / МЭК 9126
  • Шубы
  • Анализ требований
  • Требования к юзабилити
  • Структура нефункциональных требований
  • Архитектурно значимые требования
  • Пункты SNAP

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

  1. ^ Чен, Ляньпин; Али Бабар, Мухаммед; Нусейбе, Башар (2013). «Характеризация архитектурно значимых требований». Программное обеспечение IEEE . 30 (2): 38–45. DOI : 10.1109 / MS.2012.174 . ЛВП : 10344/3061 .
  2. ^ Стеллман, Эндрю; Грин, Дженнифер (2005). Управление прикладными программными проектами . O'Reilly Media . п. 113. ISBN 978-0-596-00948-9. Архивировано из оригинала на 2015-02-09.
  3. ^ Эмблер, Скотт. «Технические (нефункциональные) требования: гибкое введение» . Гибкое моделирование . Ambysoft Inc . Проверено 5 октября 2018 года .
  4. ^ Вигерс, Карл; Битти, Джой (2013). Требования к программному обеспечению, третье издание . Microsoft Press. ISBN 978-0-7356-7966-5.
  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 года .