3 Tarkvara arendusnõuded

Selles peatükis õpid:

• selgitama nõuete määratlemise olulisust tarkvaraarenduses
• sõnastama funktsionaalseid ja mittefunktsionaalseid nõudeid
• koostama kasutajalugusid ja kasutusjuhte

Eelnevas peatükis õppisime, miks ei piisa tarkvara arendamiseks pelgalt sellest, kui klient esitab oma versiooni oma soovitud lahendusest arendusmeeskonnale. Sageli võivad sellisel juhul varju jääda kliendi tegelikud vajadused, mistõttu on arendusmeeskondades analüütikud, kes aitavad kliendi vajadusi põhjalikult uurides pakkuda välja sobivaima lahenduse. Selles peatükis uurime täpsemalt, kuidas analüütikud antud lahendusi kirjeldavad nii, et neid oleks mugav kliendiga kooskõlastada ja arendajatele nende põhjal tööülesandeid jagada.

Vaata allpool olevast videost, mis juhtub siis kui analüütik ei suuda kliendi soove arendajale selgeks teha 🙂

Funktsionaalsed nõuded

Iga süsteem luuakse eesmärgiga pakkuda kasutajale mõnda funktsiooni – süsteemi käitumist või tegevust, mille abil kasutaja saavutab oma soovitud tulemuse. Selleks kirjeldab analüütik süsteemi funktsionaalsed nõuded, et selliseid kasutajate ootuseid süsteemi käitumise ja tegevuste kohta oleks võimalik lihtsalt kliendiga valideerida. Kui alles peale süsteemi valmimist selgub, et kliendi nõudeid oli valesti mõistetud, on muudatuste tegemine oluliselt kulukam, mistõttu on nõuete kontrollimine koos kliendiga enne programmeerimise alustamist äärmiselt kriitiline. Lisaks annab nõuete täpne kirjeldamine kliendile võimaluse kontrollida peale süsteemi vastu võtmist, kas kõik kokku lepitud vajadused said täidetud.

Analüütik alustab funktsionaalsete nõuete kirjeldamist esmalt lühikeste lausetena, kirjeldamaks põhilisi kliendi ootuseid süsteemile. Sellised lühikesed kirjeldused peavad vastama küsimusele mida süsteem peab tegema, mitte aga täpselt selgitama kuidas süsteem neid tegevusi võimaldab. Kasutame siinkohal näitena võimalikke funktsionaalsete nõuete kirjeldusi Instagram’i mobiilirakendust:

• Süsteemis peab saama pilte üles laadida ükshaaval;
• Süsteemis peab saama pilte üles laadida pilte albumina kuni 10 pilti korraga;
• Süsteemis peab saama piltidele kommentaare jätta.

Süsteemi loomisel aga on vaja arvestada, et kasutajaid võib olla erinevaid tüüpi ning neil võivad olla erinevad õigused. Näiteks e-koolis on hinde panemise õigus vaid õpetajal, kuid mitte tudengil endal. Seepärast lisatakse funktsionaalsete nõuete kirjeldamisel sageli ka täpsustus, millises rollis või milliste õigustega kasutaja peab saama vastavat funktsionaalsust kasutada. Kasutame taaskord näitena Instagram’i mobiilirakendust:

• Sisselogitud kasutaja peab saama üles laadida pilte oma Instagrami kontole ükshaaval
• Sisselogitud kasutaja peab saama oma profiilil olevaid pilte teiste sisselogitud ja anonüümsete kasutajate eest varjata.
• Anonüümne kasutaja peab saama vaadata teiste kasutajate avalikke profiile

Kasutajalood ja kasutusjuhud

Selleks, et nõuete kirjeldamine oleks kõigi projekti osapoolte jaoks ühtmoodi arusaadav, on nõuete kirjeldamiseks välja töötatud erinevaid formaate. Siinkohal tutvume lähemalt kahe antud formaadiga – kasutajalugu (ehk user story) ja kasutusjuht (ehk use case).

Kasutajalugu on kõnekeeles kirjutatud süsteemi omaduse või funktsionaalsuse kirjeldus, mis kirjutatakse kindla kasutaja vaatenurgast. Kasutajalugude kirjeldamine tehakse nn lihtsas kõnekeeles selleks, et ka projekti klient või süsteemi kasutajad oleksid võimelised omalt poolt esitama ootuseid süsteemi funktsionaalsuste ja omaduste osas. Ühtlasi võimaldab kõnekeeles kasutajalugude kirjeldamine loodava süsteemi funktsionaalsuste nõudeid kasutajate ja kliendiga lihtsalt valideerida, sest nende mõistmine ei nõua IT-erialast tausta.

Kasutajalugude kirjeldamisel järgitakse reeglina kindlat formaati, mis keskenduvad kolmele küsimusele: kes (või kellena), mis (või mida) ja miks?

• Kes ehk millise kasutaja jaoks on vastav funktsionaalsus või süsteemi omadus vajalik;
• Mis ehk millist funktsionaalsust või süsteemi omadust antud kasutaja vajab;
• Miks ehk miks antud funktsionaalsus või süsteemi omadus on kasutaja jaoks oluline.

Nende kolme küsimuse toel on loodud kasutajaloo kirjeldamiseks kasutatav lauseformaat, mis on järgnev:

• (Kellena) ma saan/tahan süsteemis (teha mida), et (miks).

Kasutades jällegi näitena Instagram’i mobiilirakendust, on võimalik välja tuua järgnevad kasutajalugude näited:

• Sisselogitud kasutajana ma saan lisada kommentaare postitustele, et jagada oma mõtteid seoses antud postitusega;
• Sisselogitud kasutajana ma saan märkida oma kontot privaatseks, et piirata ligipääsu oma piltidele kasutajatele, kellele ma ei ole oma kontole ligipääsu andnud;
• Sisselogitud privaatse kontoga kasutajana ma saan süsteemis vastu võtta ja tagasi lükata teiste kasutajate poolt tehtud jälgimistaotlusi.

Nagu näha on võimalik kasutajalugusid kirjeldada nii detailsemalt kui ka vähemate detailidega. Kui arendusprojekti klient esitab oma nõuded kasutajalugudena, siis ongi täpselt analüütiku töö välja selgitada kasutajaloo juures puuduvad detailid. Näiteks on võimalik eelnevalt kirjeldatud esimese Instagram’i kasutajaloo kohta küsida hulk täpsustavaid küsimusi:

• Kas iga sisselogitud kasutaja peab saama kõikidele piltidele lisada kommentaare?
• Kui pikk võib olla kommentaar, mida lisada saab?
• Kas kommentaar või sisaldada pilte, faile või videosid?
• Kas kommentaarides on võimalik ära märkida teisi kasutajaid?
• Kas kommentaari on võimalik lisada teisele kommentaarile vastuseks?

Kui kasutajalood on pigem kõnekeelsed ja üldsõnalised kirjeldused süsteemi funktsionaalsustest, siis kasutusjuhud on detailsemad sammhaaval täpsustatud kirjeldused süsteemi funktsionaalsuse kasutamise kohta. Kasutusjuhte loovad reeglina analüütikud ja sõltuvalt nende detailsusastmest on võimalik neid ka vajadusel kasutada otseselt programmeerijate töö sisendina.

Ehkki kasutusjuhtude formaate on erinevaid, on nende peamised komponendid reeglina samad:

• Pealkiri
  • Funktsionaalsus, mida kasutusloona on kirjeldatud;
• Tegutsejad
  • Kasutajarollid, kes antud funktsionaalsust saavad kasutada;
• Eeltingimused
  • Tingimused, mis peavad olema täidetud, et antud kasutuslugu saaks alustada ja läbida;
• Protsessi põhivoog
  • Kirjeldatakse ükshaaval sammudena kogu funktsionaalsuse kasutamise protsess, kus on välja toodud nii kasutaja tegevused kui ka süsteemi reaktsioonid kasutaja tegevustele;
• Alternatiivsed protsessivood
  • Kui funktsionaalsuse kasutamises võib esineda mõningaid alternatiivseid voogusid, siis kirjeldatakse ka need sammudena ja märgitakse põhivoos ära, kus vastav alternatiivne voog saab alata;
• Järeltingimused
  • Millised tingimused on süsteemis saavutatud peale selle funktsionaalsuse läbimist.

Kasutame siinkohal näitena üht protsessi, millega kõik tuttavad on – pangaautomaadist sularaha välja võtmine:

• Kasutusjuhu pealkiri: X Panga automaadist sularaha välja võtmine
• Tegutsejad
  • X panga klient
• Eeltingimused
  • Tegutsejal peab olema X panga kaart
  • Tegutsejal peab olema kontol raha
  • Tegutseja peab teadma oma pangakaardi PIN-koodi
  • Pangaautomaadis peab olema piisav kogus sularaha
• Protsessi põhivoog
  • 1. Tegutseja sisestab oma pangakaardi pangaautomaati.
  • 2. Süsteem küsib tegutsejalt pangakaardi PIN-koodi.
  • 3. Tegutseja sisestab PIN-koodi ja vajutab OK.
  • 4. Süsteem kontrollib tegutseja PIN-koodi.
    • Alternatiivvoog 1: Vale PIN-kood
  • 5. Kui PIN-kood on korrektselt sisestatud, kuvab süsteem tegutsejale valiku võimalikest funktsionaalsustest.
  • 6. Tegutseja valib sularaha välja võtmise funktsionaalsuse.
  • 7. Süsteem kuvab tegutsejale valiku võimalikest summadest, mida välja saab võtta.
  • 8. Tegutseja valib summa, mida soovib automaadist sularahana välja võtta.
  • 9. Süsteem väljastab valitud summa.
  • 10. Süsteem kuvab tegutsejale valiku, kas ta soovib jätkata või soovib väljutada pangakaardi automaadist.
  • 11. Tegutseja soovib pangakaardi väljutamist pangaautomaadist.
  • 12. Süsteem väljutab pangakaardi.
  • 13. Tegutseja võtab pangakaardi.
  • 14. Süsteem kuvab teksti: “Täname teid tehingu eest!”
• Alternatiivsed protsessivood
  • Alternatiiv 1. Vale PIN-kood
    • A1_1. Süsteem kuvab teate “Vale PIN-kood” ja kuvab uuesti PIN-koodi sisestamise välja.
    • A1_2. Tegutseja sisestab PIN-koodi ja vajutab OK.
    • A1_3. Süsteem kontrollib tegutseja PIN-koodi.
      • Kui PIN-kood on korrektselt sisestatud, jätkub protsess põhivoo sammust 5.
      • Kui PIN-kood on valesti sisestatud teist korda, jätkub protsess alternatiivvoo 1 sammust A1_1.
      • Kui PIN-kood on valesti sisestatud kolmandat korda, jätkub protsess alternatiivvoo 1 sammust A1_4.
    • A1_4. Süsteem kuvab teate “Vale PIN-kood. Pöörduge X panga kontorisse uue kaardi väljastamiseks” ja hävitab pangakaardi.

• • Alternatiiv 2. Suletud/varastatud pangakaart (jätame selle siinkohal detailselt lahkamata)

• Järeltingimused
  • Tegutseja pangakonto seis vähenes välja võetud sularaha summa võrra.
  • Tegutsejal on soovitud hulk sularaha.

Mittefunktsionaalsed nõuded

Lisaks funktsionaalsetele nõuetele on analüütiku tööks koos kliendiga paika panna ka süsteemi mittefunktsionaalsed nõuded. Mittefunktsionaalsed nõuded keskenduvad süsteemi käitumise täpsustamisele, mitte konkreetsete funktsionaalsuste või omaduste kirjeldamisele. Sellistele nõuetele tuleb tähelepanu pöörata, et oleks võimalik hinnata ka süsteemi toimimise kvaliteeti, mitte lihtsalt tegevusi, mida süsteem võimaldab.

Mittefunktsionaalsete nõuete täpsustamisel paneb analüütik üheskoos kliendiga paika näiteks järgnevad süsteemi kvaliteedi eesmärgid:

• Kui kiiresti peab veebirakenduse puhul brauser veebilehe kuvama;
• Kui palju kasutajaid peavad saama süsteemi korraga kasutada, ilma süsteemi kiirust kahjustamata;
• Millistes veebilehitsejates peab olema veebirakendus kasutatav;
• Süsteem peab olema kasutatav ka vaegnägijate puhul.

Rühmatööülesanne

1. Valige välja üks tuttav infosüsteem (nt. kalendri-äpp telefonis) ja las iga rühmaliige koostab selle kohta ühe kasutajaloo ja ühe kasutusjuhu (andke need ülesanded ka Trellos)
2. Võtke rühmakaaslase sõnastatud kasutusjuht ja sõnastage selle kohta üks funktsionaalne nõua
3. Sõnastage ühes koos vähemalt kaks mittefunktsionaalset nõuet sama süsteemi kohta.
4. Esitage oma tulemused Trellos.

Kasutatud allikad:

https://infosysteemianalyys.weebly.com/42-analuumluumlsi-faas-ja-etapid.html