Mittefunktsionaalsed nõuded

Allikas: Vikipeedia

Mittefunktsionaalsed nõuded täpsustavad tarkvara ja nõuete projekteerimises kriteeriume, mille alusel hinnatakse süsteemi töökäiku, mitte kindlaid omadusi. Nende vastandid on funktsionaalsed nõuded, mis defineerivad kindlad funktsioonid või käitumised. Plaan mittefunktsionaalseid nõudeid käiku viia asub süsteemiarhitektuuris, mitte süsteemidisainis, nagu see on funktsionaalsete nõuete korral. See on nii, kuna need on tavaliselt arhitektuuriliselt olulised nõuded.[1]

Üldjoontes defineerivad funktsionaalsed nõuded, mida süsteem peab tegema, ning mittefunktsionaalsed nõuded defineerivad, milline süsteem peab olema. Funktsionaalsed nõuded on üldiselt vormis "süsteem teeb <nõue>", individuaalne tegevus, mis on osa süsteemist, mille juurde see kuulub. Mittefunktsionaalset nõuet esitatakse kujul "süsteem hakkab olema <nõue>" ehk üldine süsteemi omadus või mingi eriline aspekt ja mitte täpne funktsioon. Süsteemi üldised omadused tavaliselt näitavad, kas projektiarendus on õnnestunud või läbikukkunud.

Mittefunktsionaalseid nõudeid kutsutakse süsteemi "kvaliteedi atribuutideks" või omadusteks, kvaliteedi eesmärkideks, kitsendusteks, mittekäitumispärasteks omadusteks.[2] Mittefunktsionaalsete nõuete alla kuuluvaid omadusi on võimalik jaotada kaheks põhikategooriaks:

  1. Täitmisomadused, nagu turvalisus ja kasutatavus, mis on jälgitavad süsteemi töö ajal.
  2. Arengulised omadused, nagu testitavus, hooldatavus, pikendatavus ja suurendatavus, mis on tarkvarasüsteemi staatilises struktuuris.[3][4]

Süsteemi taseme kvaliteedinõuded[muuda | muuda lähteteksti]

Süsteemi taseme kvaliteedinõuded seostuvad turvalisuse, hallatavuse, laiendatavuse, stabiilsuse ja porditavusega – need ei täida ärilist eesmärki. Nendele kvaliteedinõuetele mittevastamine võib mõjutada kasutajaid kaudselt läbi teiste, seostatud kvaliteedinõuete mittevastamise kaudu.

  • Turvalisus – süsteemi ei saa sisse ega kahjustada
  • Hallatavus – süsteem on organiseeritud ja kontrollitav
  • Hooldatavus – süsteem on kergesti hooldatav
  • Laiendatavus – süsteemi on võimalik laiendada
  • Stabiilsus – süsteemivigadega toimetuleku võime
  • Porditavus – süsteemi komponentide liigutamise võime

 Dokumenteerimine[muuda | muuda lähteteksti]

Projekti elutsüklis (kutsutakse ka projekti töö elutsükliks ehk PDLC-ks) on protsesse, mida tuleks kõigile kvaliteediomadustele vastavuse tagamiseks järgida. Kuigi need protsessid võivad eraldiseisvate organisatsioonide või äriüksuste puhul erineda, peaks põhilised dokumendid olema sarnased.

Mittefunktsionaalseid nõudeid saab dokumenteerida kahes kohas:

  1. Kindla kasutusjuhtumi spetsiifilisi, mittefunktsionaalseid nõudeid saab dokumenteerida osana "Kasutusjuhtumi kirjelduse" lõigust "Erinõuete" all. Need nõuded võivad kehtida nii kogu kasutusjuhtumile kui selle kindlatele sammudele.
  2. Kogu süsteemile rakenduvaid mittefunktsionaalseid nõudeid võib dokumenteerida lisatud spetsifikatsioonide dokumendis ja nõudeid saab formuleerida küsimuste ja vastustena.[5]

Näited[muuda | muuda lähteteksti]

Süsteemi ülesandeks võib olla kuvada andmebaasist kasutajale andmete arvu. See on funktsionaalne nõue. Mittefunktsionaalne nõue on selle arvu uudsus. Kui see arv peab olema uuendatav reaalajas, siis süsteemi loojad peavad kindlaks tegema, et süsteem võib uuendada andmete arvu kindla aja tagant, mis on kooskõlas andmete arvu muutumisega. Sobiv võrgukiirus võib olla süsteemi mittefunktsionaalne nõue.

Loodava süsteemi üldiseks reaktsiooniajaks (töövõime nõue) määratakse üks sekund. Võib aga olla kasutusjuhtumeid, kus on teada, et peab kasutama välist teenusepakkujat. Siis võib reaktsiooniaja piirangut lõdvendada viie sekundi peale. Kogu süsteemile üldiselt rakenduvat nõuet dokumenteeritakse osana lisatud spetsifikatsioonide dokumendist. Viie sekundi nõuet aga kirjeldatakse kasutusjuhtumi all kui "erinõuet". Lisatud spetsifikatsioonid ja funktsionaalsed spetsifikatsioonid (kasutusjuhtumid ja valdkonna mudelid) moodustavad koos süsteemi nõuete spetsifikatsioonide dokumendi.[5]

Veel näiteid mittefunktsionaalsetest nõuetest:

  • Ligipääsetavus
  • Audit ja kontroll
  • Saadavus
  • Varund
  • Võimsus, praegune ja prognoositav
  • Sertifitseerimine
  • Vastavus
  • Konfiguratsiooni haldamine
  • Sõltuvus teistest osapooltest
  • Dokumentatsioon
  • Katastroofiabi
  • Kasutegur (mingi koguse jaoks vajalikud ressursid)
  • Tõhusus (töö ja jõudluse suhe)
  • Emotsionaalsed tegurid
  • Keskkonnakaitse
  • Lähtekoodi hoiustus
  • Ärakasutatavus
  • Laienduste võimalus (funktsioonide lisamine jms)
  • Nurjumiste haldus
  • Vea tolerants (nt süsteemi töötamise monitooring, mõõtmine ja haldus)
  • Õigused ja litsentsid
  • Koostalitlusvõime
  • Hooldatavus
  • Võrgu topoloogia
  • Avatud lähtekoodiga
  • Töökindlus
  • Jõudlus
  • Platvormide ühilduvus
  • Hind
  • Privaatsus
  • Kaasaskantavus
  • Kvaliteet
  • Taastatavus (nt keskmine aeg taastamiseni)
  • Usaldusväärsus (nt keskmine aeg vigade vahel)
  • Aruandlus
  • Vastupidavus
  • Vahendite piiratus (protsessori kiirus, mälu, kettaruum, võrgu ribalaius jne)
  • Reaktsiooniaeg
  • Taaskasutatavus
  • Stabiilsus
  • Ohutus või FoS
  • Mastaapsus (horisontaalne, vertikaalne)
  • Turvalisus
  • Tarkvara, tööriistad, standardid jms
  • Stabiilsus
  • Toetatavus
  • Testitavus
  • Läbipaistvus
  • Kasutatavus sihtgrupis

Raamistik[muuda | muuda lähteteksti]

Mittefunktsionaalsed nõuded (MFN) on sihimudelil põhinev raamistik. Analüüsi alguses sätestatakse tarkvaralised sihid, millega kõik osanikud nõustuvad. Tarkvaralised sihid on raskesti väljendatavad eesmärgid, mis on tavaliselt ülesüsteemilised omadused, näiteks süsteemi kasutatavus, turvalisus, jõudlus ja paindlikkus. Need eesmärgid jagatakse väiksemateks üksusteks ja korrastatakse ning moodustatakse puustruktuur eesmärkidest ning tarkvaralistest sihtidest. Tõenäoliselt leitakse saadud puustruktuuridest üksteist häirivaid tarkvaralisi sihte. Näiteks turvalisuse eesmärgid häirivad tihti kasutatavust. Need puud moodustavad tarkvaraliste sihtide graafi. Viimaks valitakse mingi kindel leht graafist, mis rahuldaks kõiki juuresolevaid tarkvaralisi sihte.[6]

Mõõtmine[muuda | muuda lähteteksti]

Kui funktsioonipunktid (FP) mõõdavad funktsionaalseid nõudeid, arvestades andmevoo läbivust läbi tarkvara rakenduse, siis IFPUG-i (International Function Point User Group) SNAP (tarkvara mittefunktsionaalse hinnangu protsess) mõõdab mittefunktsionaalseid nõudeid. SNAP-i mudel koosneb neljast kategooriast, mis omakorda jaguvad 14 alamkategooriaks, et mõõta mittefunktsionaalseid nõudeid. Mittefunktsionaalsed nõuded jagatakse alamkategooriatesse. Iga alamkategooria suurus tehakse kindlaks ning nõude suuruseks saab kõikide alamkategooriate suuruste summa.

SNAP-i mõõteprotsess sarnaneb funktsionaalpunkti mõõteprotsessiga. Rakenduse sees seostatakse mittefunktsionaalseid nõudeid kategooriate ning alamkategooriatega. Standardiseeritud põhikriteeriumite komplekti kasutades mõõdetakse iga alamkategooria vastavalt sellele tüübile ning raskusele (sellise nõude suurus on võrdne selle alamkategooriate summaga). Need suurused arvutatakse kokku, et anda tarkvara rakenduse mittefunktsionaalsuse mõõde.

Mudeli beetatestimine 2012. aasta sügisel näitas, et SNAP-i suurusel on tugev korrelatsioon tööjõuvajadusega, et arendada mittefunktsionaalne osa tarkvara rakendusest.[7]

SNAP-i kategooriad[8][muuda | muuda lähteteksti]

SNAP kasutab nelja kategooriat, mis omakorda jaotuvad alamkategooriateks. Igat alamkategooriat hinnatakse kasutades meetodiga, mis on kirjas SNAP-i käsiraamatus.[7]

1. Andmetoimingud
1. Andmesisestuse kinnitamised
2. Loogilised ja matemaatilised operatsioonid
3. Andmevormindamine
4. Sisemised andmeliikumised
5. Kasutajatele lisaväärtuse kohaletoimetamine andmekonfiguratsiooni kaudu
2. Liidese disain
1. Kasutajaliidesed
2. Abimeetodid
3. Sisendmeetodid
4. Väljundmeetodid
3. Tehniline keskkond
1. Platvormid
2. Andmebaasi tehnoloogia
3. Töötlusüksuste protsessid
4. Arhitektuur
1. Komponendipõhine tarkvara
2. Mitmed sisend- ja väljundliidesed

SNAP-i plussid[muuda | muuda lähteteksti]

Tänu mittefunktsionaalsete nõuete mõõtmisele on lihtsam hinnata tarkvara arendavat tööjõudu.

See täiustatud tööjõu hinnang viib parema planeeringu, ressursijaotuse ning vähemate riskideni.

Projektimeeskondade produktiivsust saab paremini hinnata, kuna mõõdetakse rohkemaid töö väljundeid.

Kasutades mõlemat, funktsionaalset ja mittefunktsionaalset tööd, saab tellijale paremini oma toodete väärtust demonstreerida.[9]

Vaata ka[muuda | muuda lähteteksti]

Viited[muuda | muuda lähteteksti]

  1. ↑ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Characterizing Architecturally Significant Requirements". IEEE Software. 30 (2): 38–45. DOI:10.1109/MS.2012.174.
  2. ↑ Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management. O'Reilly Media. Lk 113. ISBN 978-0-596-00948-9.
  3. ↑ Wiegers, Karl; Beatty, Joy (2013). Software Requirements, Third Edition. Microsoft Press. ISBN 978-0-7356-7966-5.
  4. ↑ Young, Ralph R. (2001). Effective Requirements Practices. Addison-Wesley. ISBN 978-0-201-70912-4.
  5. ↑ 5,0 5,1 Margus Kreinin https://web.archive.org/web/20161118224927/https://www.ria.ee/public/publikatsioonid/Mittefunk_nouded.doc
  6. ↑ Mylopoulos, Chung, and Yu: "From Object-oriented to Goal-oriented Requirements Analysis" Communications of the ACM, January 1999 http://www.utdallas.edu/~chung/ftp/CACM.f.doc
  7. ↑ 7,0 7,1 SNAP-i hindamise käsiraamat https://web.archive.org/web/20161011162744/http://www.ifpug.org/Documents/SNAPInABox.pdf
  8. ↑ SNAP-i kategooriad https://web.archive.org/web/20130907190548/http://www.ifpug.org/ISMA6/ITPC%20SNAP-SW%20Non-Functional%20Assessment%20Process-Sept13.pdf
  9. ↑ About Snap. https://web.archive.org/web/20161119055950/http://www.ifpug.org/about-ifpug/about-snap/
Pärit leheküljelt "https://et.wikipedia.org/w/index.php?title=Mittefunktsionaalsed_nõuded&oldid=6255049"