Ugrás a tartalomhoz

Nem funkcionális követelmény

A Wikipédiából, a szabad enciklopédiából

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

[szerkeszté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:

  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.[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

[szerkesztés]

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

[szerkesztés]
  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.)
  4. Wiegers, Karl. Software Requirements, Third Edition. Microsoft Press (2013). ISBN 978-0-7356-7966-5 
  5. Young, Ralph R.. Effective Requirements Practices. Addison-Wesley (2001). ISBN 978-0-201-70912-4 
  6. Zimmermann, Olaf. Design Practice Repository. LeanPub (2021) 
  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.  

Fordítás

[szerkeszté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

[szerkesztés]