stringtranslate.com

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

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

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

Определение

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

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

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

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

Примеры

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

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

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

Ссылки

  1. ^ Чен, Ляньпин; Али Бабар, Мухаммад; Нусейбех, Башар (2013). «Характеристика архитектурно значимых требований». IEEE Software . 30 (2): 38–45. doi :10.1109/MS.2012.174. hdl : 10344/3061 . S2CID  17399565.
  2. ^ Ричардс, Марк; Форд, Нил (2020). Основы архитектуры программного обеспечения: инженерный подход . O'Reilly Media, Incorporated. ISBN 978-1492043454.
  3. ^ Стеллман, Эндрю; Грин, Дженнифер (2005). Управление проектами прикладного программного обеспечения. O'Reilly Media . стр. 113. ISBN 978-0-596-00948-9. Архивировано из оригинала 2015-02-09.
  4. ^ Эмблер, Скотт. «Технические (нефункциональные) требования: введение в Agile». Agile Modeling . Ambysoft Inc . Получено 5 октября 2018 г. .
  5. ^ Вигерс, Карл; Битти, Джой (2013). Требования к программному обеспечению, третье издание . Microsoft Press. ISBN 978-0-7356-7966-5.
  6. ^ Янг, Ральф Р. (2001). Эффективные требования практики . Addison-Wesley. ISBN 978-0-201-70912-4.
  7. ^ Циммерманн, Олаф; Стокер, Мирко (2021). Репозиторий практики проектирования. LeanPub.
  8. ^ Глинц, Мартин (2008). «Подход к требованиям к качеству, основанный на оценке рисков и ценностно-ориентированный» (PDF) . IEEE Software . 25 (2): 34–41. doi :10.1109/MS.2008.31. S2CID  19015424.

Внешние ссылки