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

Non-functional requirement

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

Определение

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

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

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

Примеры

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

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

Смотрите также

Рекомендации

  1. ^ Чен, Ляньпин; Али Бабар, Мухаммед; Нусейбе, Башар (2013). «Характеризация архитектурно значимых требований». Программное обеспечение IEEE. 30 (2): 38–45. Дои:10.1109 / MS.2012.174. HDL: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.

внешняя ссылка