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.

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", vagy "műszaki követelmények". 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:

1. 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.
2. 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.

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

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

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. (Hozzáférés: 2017. október 3.)
• "Do Software Architectures Meet Extra-Functional or Non-Functional Requirements?", 2020. november 19.