Sageli keskendume süsteemi arendamise käigus sellele, et veenduksime, et täidame kõiki süsteemi funktsionaalseid nõudeid. Kuigi funktsionaalsed nõuded on tõepoolest väga olulised, pole need ainus viis, kuidas lõppkasutajad ja ettevõtete omanikud süsteemi hindavad. Kui kasutaja saab tõepoolest krediitkaardi väljavõtte hankida, kuid selleks kulub viis minutit, ei ole kasutaja tõenäoliselt tootega rahul. Mõelgem sellele näitele. Mike Gray raamatus „Rünnaku nurk“ käsitleb ta nõuete mõju esimese inimese Kuule saatmise püüdlustele. Ta mainib kahte mittefunktsionaalset nõuet, mis tulid president John F. Kennedylt. Esiteks oli see, et astronaudid tagastati ohutult. (Mulle tundub mõistlik. Kes oleks vabatahtlik, kui see poleks nõutav?) Teiseks, et projekt viiakse lõpule praeguse kümnendi jooksul. Selle raamatu lugemine pani mind mõistma, kuidas selline lihtne nõue nagu „selle kümnendi jooksul“ võib muuta kogu arendustegevuse ulatust ja fookust. Sellisel juhul keskendusid kõik arendustegevused tavapäraste süsteemitehnika tavade läbimise ja riskianalüüsi tegemise asemel kiire katse-eksituse meetodil kiire lahenduse leidmisele. Kogu protsess muutus selle ainsa nõude põhjal. Astronautide ohutu tagasitoomise nõude tulemuseks oli täiesti uus projekt, mis hõlmas astronautide tagasitoomist kuult ja tagasi kosmoselaevu, et koju naasta.
Funktsionaalsete nõuete puudumine nõuete haldamisel Mul on oma näide mittefunktsionaalsete nõuete mõjust. Relva juhtimissüsteemi kallal töötades oli meil usaldusväärsuse nõue. Kui hakkasime uurima usaldusväärsust, mida me vajame saavutamiseks, leidsime ainsa võimaluse vajaliku töökindluse saavutamiseks lisada teine protsessor varukoopiana. Tundus mõistlik tegu. Lõpuks sai sellest õudusunenägu. Andmete ja protsesside varundamine ning täpse oleku jälgimine protsesside ja andmete mahalaadimise ajal oli väga keeruline. Selle testimine oli hoopis teine probleem. Olukorra võimalikke permutatsioone oli nii palju, et neid kõiki oli võimatu testida. Selle ühe nõude toetamiseks vajalikud jõupingutused olid palju rohkem kui keegi meist oskas oodata.
Mida rohkem on süsteemis mittefunktsionaalseid nõudeid, seda kallim on nii välja töötada kui ka testida ja seda suurem on risk. Eelkõige mõjutavad kogu süsteemi mõjutavad nõuded kõige rohkem ajakava ja kulusid.
Mida teha mittetoimivate nõuetega
Mida me siis kõigi nende mittefunktsionaalsete nõuetega teeme? Loomulikult pole lihtsalt võimalik neid lihtsalt välja visata. Parim, mida saame teha, on hoolikalt uurida kõiki mittetoimivaid nõudeid. Kui kasutajad määravad mittefunktsionaalsed nõuded, küsige neilt, miks see on oluline. Veenduge, et nõue on tõesti vajalik, mõistes selle tähtsust lõppkasutajatele. Veenduge, et läbimise / ebaõnnestumise kriteeriumid kehtivad. Mõnel juhul ütlevad kasutajad, et süsteem peab olema 100% ajast kättesaadav, mõtlemata selle peale, mida nad ütlevad. Küsige siis, kas see on raske number või mida kasutaja sooviks näha.
Kui kasutajad väidavad mittefunktsionaalseid nõudeid, näiteks „kasutajasõbralik”, siis ärge laske sellel väikesel nõudmisel teie dokumenti libiseda, mõistmata, mida see kasutaja jaoks tähendab. Küsige, kuidas kasutaja süsteemi testib, et teha kindlaks, kas see on kasutajasõbralik. Koostage koos kasutajaga kriteeriumid, mille abil saab kindlaks teha, kas nõue on täidetud. Nende kriteeriumide dokumenteerimine koos kasutajatega tagab, et kõik mõistavad nõude eesmärki.
Lühidalt öeldes veenduge, et teate, miks mittefunktsionaalne nõue on kasutaja jaoks oluline ja kuidas edu mõõdetakse. Selle teabe hankimine kohe aitab teil luua parema lahenduse.
