Nem funkcionális követelmény

A rendszertervezésben és a követelménytervezésben a nem funkcionális követelmény (NFR) olyan követelmény, amely a rendszer működésének megítélésére használható kritériumokat határoz meg, nem pedig konkrét viselkedéseket. Ezzel szembeállítják azokat a funkcionális követelményeket, amelyek meghatározott viselkedést vagy funkciókat határoznak meg. A funkcionális követelmények megvalósításának tervét a rendszerterv részletezi. A nem funkcionális követelmények megvalósításának tervét a rendszer architektúra részletezi, mivel ezek általában architekturálisan jelentős követelmények.^[1]

Meghatározás

Általánosságban elmondható, hogy a funkcionális követelmények határozzák meg, hogy egy rendszernek mit kell tennie, a nem funkcionális követelmények pedig azt, hogy egy rendszernek milyennek kell lennie . A funkcionális követelményeknek általában azt jelenti, hogy a "rendszernek <követelmény>" formában kell lennie, lehet egy egyedi művelet vagy a rendszer része, esetleg kifejezetten matematikai függvény értelmében, egy fekete doboz leírásának bemeneti, kimeneti, folyamat- és vezérlési funkcionális modellje vagy az IPO modell . Ezzel szemben a nem funkcionális követelmények a "rendszernek <követelmény>-nek kell lenni" formában vannak, ami a rendszer egészének vagy egy adott aspektusának általános tulajdonsága, nem pedig egy konkrét funkció. A rendszer általános tulajdonságai gyakran jelzik, hogy a fejlesztési projekt sikeres volt-e vagy sem.

A nem funkcionális követelményeket gyakran a rendszer " minőségi jellemzőinek " nevezik. A nem funkcionális követelmények egyéb kifejezései a "minőségek", "minőségi célok", "szolgáltatási minőségi követelmények", "megszorítások", "nem viselkedési követelmények",^[2] vagy "műszaki követelmények".^[3] Informálisan ezeket néha " ilitások "-nak nevezik, olyan tulajdonságokból, mint a stabilitás és a hordozhatóság. A minőségek – vagyis a nem funkcionális követelmények – két fő kategóriába sorolhatók:

A működés során (futási időben) megfigyelhető végrehajtási tulajdonságok, például biztonság, biztonság és használhatóság.
Az fejlődési tulajdonságok, mint például a tesztelhetőség, karbantarthatóság, bővíthetőség és méretezhetőség, amelyek a rendszer statikus struktúrájában testesülnek meg.^[4]^[5]

Fontos, hogy a nem funkcionális követelményeket specifikus és mérhető módon határozzuk meg.^[6]^[7]

Példák

Egy rendszernek meg kell jelenítenie a felhasználó számára az adatbázisban lévő rekordok számát. Ez egy funkcionális követelmény. Az, hogy mennyire naprakésznek kell lennie ennek a számnak, egy nem funkcionális követelmény. Ha a számot valós időben frissíteni kell, a rendszertervezőknek gondoskodniuk kell arról, hogy a rendszer a rekordok számának változásától számított elfogadhatóan rövid időn belül képes legyen megjeleníteni a rekordszámot.

A megfelelő hálózati sávszélesség a rendszer nem funkcionális követelménye lehet.

További példák:

Hozzáférhetőség
Alkalmazkodóképesség
Auditálhatóság és ellenőrzés
Rendelkezésre állás (lásd szolgáltatási szint megállapodás)
Biztonsági mentés
Indítási idő
Kapacitás, jelenlegi és előrejelzett
Tanúsítás
Megfelelőség
Konfigurációkezelés
Megfelelés
Költség, kezdeti és életciklus költség
Adatintegritás
Adatmegőrzés
Függőség más felektől
Telepítés
Fejlesztési környezet
Katasztrófa utáni helyreállítás
Dokumentáció
Tartósság
Hatékonyság (erőforrás-fogyasztás adott terhelés esetén)
Hatékonyság (az erőfeszítéshez viszonyított teljesítmény)
Rugalmasság
Érzelmi tényezők (például szórakoztató vagy magával ragadó vagy van "Wow! Faktor")
Környezetvédelem
Letét
Kihasználhatóság
Bővíthetőség (funkciók hozzáadása és a testreszabások továbbvitele a következő fő verziófrissítésnél)
Hibakezelés
Hibakerülés (pl. operációs rendszer figyelése, mérése és kezelése)
Rugalmasság (pl. a jövőbeli követelmények változásainak kezelése)
Lábnyom csökkentése - az exe fájlok méretének csökkentése
Integrálhatóság (pl. komponensek integrálhatósága)
Nemzetközivé tétel és lokalizáció
Interoperabilitás
Jogi és licencelési kérdések vagy szabadalomsértés elkerülhetősége
Karbantarthatóság (pl. átlagos javítási idő - MTTR)
Menedzsment
Memóriaoptimalizálás
Módosíthatóság
Hálózati topológia
Nyílt forráskód
Üzemeltethetőség
Teljesítmény / válaszidő (teljesítménymérnökség)
Platform kompatibilitás
Adatvédelem (az adatvédelmi törvények betartása)
Hordozhatóság
Minőség (pl. feltárt hibák, szállított hibák, hibaeltávolítási hatékonyság)
Olvashatóság
Megbízhatóság (pl. átlagos idő a hibák között/hírekig - MTBF/MTTF)
Jelentéskészítés
Rugalmasság
Erőforrás korlátok (processzor sebesség, memória, lemezterület, hálózati sávszélesség stb.)
Válaszidő
Újrahasznosíthatóság
Robusztusság
Biztonság vagy biztonsági tényező
Skálázhatóság (vízszintes, függőleges)
Biztonság (kiber és fizikai)
Szoftver, eszközök, szabványok stb. Kompatibilitás
Stabilitás
Támogathatóság
Tesztelhetőség
Átviteli sebesség
Átláthatóság
Használhatóság (emberi tényezők) a célzott felhasználói közösség számára
Mennyiség tesztelés

Hivatkozások

↑ Chen (2013). „Characterizing Architecturally Significant Requirements”. IEEE Software 30 (2), 38–45. o. DOI:10.1109/MS.2012.174.
↑ Stellman, Andrew. Applied Software Project Management [archivált változat]. O'Reilly Media, 113. o. (2005). ISBN 978-0-596-00948-9 [archiválás ideje: 2015. február 9.]
↑ Ambler: Technical (Non-Functional) Requirements: An Agile Introduction. Agile Modelling. Ambysoft Inc.. (Hozzáférés: 2018. október 5.)
↑ Wiegers, Karl. Software Requirements, Third Edition. Microsoft Press (2013). ISBN 978-0-7356-7966-5
↑ Young, Ralph R.. Effective Requirements Practices. Addison-Wesley (2001). ISBN 978-0-201-70912-4
↑ Zimmermann, Olaf. Design Practice Repository. LeanPub (2021)
↑ Glinz (2008). „A Risk-Based, Value-Oriented Approach to Quality Requirements”. IEEE Software 25 (2), 34–41. o. DOI:10.1109/MS.2008.31.

Fordítás

Ez a szócikk részben vagy egészben a Non-functional requirement című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

További információk

Dalbey: Nonfunctional Requirements. Csc.calpoly.edu. (Hozzáférés: 2017. október 3.)
Modeling Non-Functional Aspects in Service Oriented Architecture. Cs.umb.edu. [2011. július 24-i dátummal az eredetiből archiválva]. (Hozzáférés: 2017. október 3.)
Non-Functional Requirements: Do User Stories Really Help?. Methodsandtools.com. (Hozzáférés: 2017. október 3.)
Non-Functional Requirements Be Here - CISQ - Consortium for IT Software Quality. it-cisq.org. [2018. szeptember 26-i dátummal az eredetiből archiválva]. (Hozzáférés: 2017. október 3.)
"Do Software Architectures Meet Extra-Functional or Non-Functional Requirements?", 2020. november 19.

[ASR_Chen-1] Chen (2013). „Characterizing Architecturally Significant Requirements”. IEEE Software 30 (2), 38–45. o. DOI:10.1109/MS.2012.174.

[2] Stellman, Andrew. Applied Software Project Management [archivált változat]. O'Reilly Media, 113. o. (2005). ISBN 978-0-596-00948-9 [archiválás ideje: 2015. február 9.]

[3] Ambler: Technical (Non-Functional) Requirements: An Agile Introduction. Agile Modelling. Ambysoft Inc.. (Hozzáférés: 2018. október 5.)

[Wiegers13-4] Wiegers, Karl. Software Requirements, Third Edition. Microsoft Press (2013). ISBN 978-0-7356-7966-5

[Young01-5] Young, Ralph R.. Effective Requirements Practices. Addison-Wesley (2001). ISBN 978-0-201-70912-4

[6] Zimmermann, Olaf. Design Practice Repository. LeanPub (2021)

[MGUZH-7] Glinz (2008). „A Risk-Based, Value-Oriented Approach to Quality Requirements”. IEEE Software 25 (2), 34–41. o. DOI:10.1109/MS.2008.31.

[1]

[2]

[3]

[4]

[5]

[6]

[7]