Seekordset postitust tundub paslik alustada ühe väga tabava tsitaadiga:

“Analysis sounds like something that just kind of happens through staring at requirements long enough“

“Software Requirements Essentials” Karl wiegers, candase hokanson

See tsitaat on väga tabav ja kirjeldab minu arust üsna täpselt seda, kuidas analüüsi tegevust laiemalt mõistetakse. Teine väärarusaam on see, et analüüs koosnebki ainult intervjuude läbiviimisest ja nende põhjal memode kirjutamisest. Käesolevas postituses avan natuke analüüsi läbiviimise tööprotsessi ehk seda, millistest etappidest see koosneb ning millised on iga etapi tavapärased tegevused. Natuke teise nurga alt olen analüütiku tööprotsessist kirjutanud ka ühes oma varasemas blogipostituses.

Analüüsi läbiviimise tööprotsess

Tuvastamise etapp

Inglise keeles on sellel etapil palju kõnekam nimetus kui eestikeelne tuvastamine. Elicitation tähendab otsetõlkes esile tooma või välja meelitama ning tegelikult annavadki need tegusõnad väga hästi edasi seda mõtet, mida analüütik antud etapis tegema peab.

Seotud osapoolte peades on väga palju erinevate nõuete fragmente – näiteks mingi kindel visioon konkreetsest kasutajaliidese kuvast või konkreetsete andmete kirjeldused, mida neil vaja on või hoopis rahulolematus/probleemid oma praeguse süsteemi/tööprotsessiga. Sellised fragmendid ei ole tihtilugu ei struktureeritud ega ka terviklikud, mis tähendab, et nõuete formuleerimiseks peab analüütik nendega veel vaeva nägema.

Seega võiks öelda, et nõuete kogumine on ainult üks tegevus nõuete tuvastamise etapist. Lisaks kuuluvad sinna sellised tegevused nagu uurimine, avastamine ja leiutamine. Analüütik peab suutma väga erinevate töövõtete abil endale selgeks teha, millist probleemi lahendatakse ja milline võiks olla tellija jaoks rahuldustpakkuv lahendus. Lisan ka mõned enimkasutatavate meetodite märksõnad – dokumentide analüüs, protsesside kaardistamine ja analüüs, andmekaevandamine, kasutajaliideste analüüs, intervjuud ja fookusgrupid, kasutajate vaatlus, ajurünnak. Konkreetse meetodi valik sõltub sinu sihtrühmast, projekti ajakavast ja eelarvest, projekti arendusmeetoodikast jne.

Analüüsimise etapp

Nõuete tuvastamise etapis kogutud, avastatud ja välja uuritud info vajab nüüd süsteemset ja parimatest praktikatest lähtuvat korrastamist. Mida siis analüüsimise tegevus ikkagi endast kujutab? Analüüsimine on sisuliselt kogutud info klassifitseerimine, filtreerimine, sorteerimine, visualiseerimine ning info omavaheline võrdlemine. See annab analüütikule võimaluse kontrollida, et kogutud info on omavahel kooskõlas ja et tal ei ole midagi kahe silma vahele jäänud.

Analüüsimise etapi tulemina võivad tekkida nõuete kirjeldused, mis on kujutatud, kas tekstiliselt või mudeli kujul või hoopis prototüübina. Siinkohal tahan igaks juhuks üle rõhutada, et ei ole olemas ühte notatsiooni, mis kataks kõikide erinevate info esitamise viiside vajadused. Väga kummaline on vahel analüüsi tellinud osapoole nõuetest lugeda, et kõik mudelid peavad olema koostatud UML (Unified Modelling Language) notatsioonis. Samas kui äriprotsesside modelleerimiseks on soovituslik kasutada üldse BPMN-i (Business Process Management Notation) või andmevoogude visualiseerimiseks DFD-d (Data Flow Diagram).

Kogutud info analüüsimise abil kontrollib analüütik, kas kõikide seotud osapoolte vajadustega on arvestatud ning kas on olemas kokkulepe kõiki nõudeid rahuldava lahenduse osas. Eelmises lauses on üks olulisemaid sõnu “kokkulepe” – see eeldab, et misiganes esitlusviisil kirja pandud nõuded on ka tellijaga valideeritud ning saadud tema kinnitus.

Määratlemise etapp

Antud etapi vajalikkust annab edasi järgnev tsitaat:

“However, the cost of recording knowledge is small compared to the cost of acquiring that knowledge or reacquiring it in the future.”

“Software Requirements Essentials” Karl wiegers, candase hokanson

Väga levinud väärarusaam on see, et agiilses arenduses dokumenteeritakse võimalikult vähe ning dokumentatsiooni nõudmine on justkui vananenud praktika. Mina olen seisukohal, et dokumentatsioon on oluline kommunikatsioonivahend ning see kajastab mingi hetke seisu tellija ja arendaja vahelisest kokkuleppest. Ausalt öeldes ei ole minu pea küll prügikast, et suudan sinna kõik kokkulepped ja nüanssid salvestada ning hiljem neid väikse vaevaga meenutada. Mul on oma mälumahuga parematki teha, kui seda sellel eesmärgil kasutada.

Mõned soovitused spetsifikatsiooni kirjutamisel:

  • Lähtu nõuete kirjeldamisel samast stiilist ja detailsusastmest ning mõtle läbi, milline esitlusviis annab kõige paremini edasi nõude/nõuete olemust;
  • Organiseeri nõuded struktuurselt ja lugeja jaoks loogiliselt – loo endale nõuete kirjeldmise mallid, mida saad erinevates projektides taaskasutada;
  • Ära unusta välja selgitada ja kirjeldada ärireegleid (business rules);
  • Loo nõuete arusaadavuse suurendamiseks sõnastik.

Kinnitamise etapp

Nõuete kinnitamise etapis hinnatakse, kas kirjapandud nõuded tegelikult ka rahuldavad tellija vajadusi ning kas need aitavad kaasa äriliste eesmärkide saavutamisele. Selle etapi olulisust tihti alahinnatakse ning pingelises projektiplaanis on selle etapi ärajätmise ahvatlus suur. Mida ei mõisteta on see, et selles etapis vigade avastamine ja nende parandamine on mitmeid kordi odavam, kui mõnes hilisemas etapis.

Arendusmeeskonna liikmed saavad kontrollida nõudeid (verification) – st hinnata, kas midagi realiseeriti õigesti. Tellija meeskonna liikmed saavad kinnitada nõudeid (validation) – st hinnata, kas tehti üldse õiget asja. Mõlemad sammud on vajalikud ja nende läbiviimiseks on erinevaid võimalusi. Kontrollimiseks on väga efektiivne töövorm teise sama rolli kandva isiku poolt tehtud töö üle vaatamine (nn. peer-review, code-review jne). Kinnituse saamiseks on minu arust kõige sobivam meetod koos tellijaga kinnitamist vajavate nõuete läbikäimine ning selle raames tellija kinnituse küsimine. Kirja teel kinnituse küsimine võib päädida sellega, et sinu kirja ignoreeritakse või ei saada täpselt aru, millele kinnitust on vaja.

Kosemudeli stiilis analüüsi protsessi ei ole olemas!

Nagu postitusele lisatud protsessiskeemilt näha, siis saab analüüsi protsessis peaagu igast etapis liikuda tagasi eelmisesse etappi ning see on igasuguse analüüsi puhul täiesti normaalne töövoog. Räägitakse küll arendusprojektidest, mis järgivad kosemudelit (waterfall) aga isegi sellistes projektides ei ole võimalik kõiki detaile ette analüüsida. Kuna tellija teadlikkus ajas kasvab ja tema nõuded muutuvad, siis tuleb isegi väga detailselt ette defineeritud analüüsis kindlasti ette muutmisvajadusi.

Muutmisvajadused võivad selguda:

  • Kui analüütik on hakanud nõudeid analüüsima (st grupeerima, korrastama, võrdlema), siis võib tulla välja, et mingid nõuded on üldse kogumata ning peab minema tagasi nõuete tuvastamise etappi;
  • Kui nõuded on spetsifikatsioonina kirja pandud, võib selguda, et mingid nõuded on analüüsimata või kogumata ning peab minema tagasi, kas nõuete analüüsimise või tuvastamise etappi;
  • Kui toimub nõuete kontrollimine ja kinnitamine, võivad selguda asjaolud, mistõttu võib olla vajadus minna tagasi, kas nõuete tuvastamise, analüüsimise või määratlemise etappi.

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust, millele käigus õpetan täpsemalt, kuidas tööprotsesse kaardistada ja optimeerida –  https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus.

Hetkel on välja töötamisel ka koolitus targale tellijale, mille käigus mõtestatakse lahti vajalikud eelteadmised ja oskused IT projektide juhtimiseks ning õpetatakse, millisel tasemel ja detailsusega analüüsi võiks üks tark tellija ise osata teha. Kui tahad selle koolituse kohta rohkem kuulda, siis võta minuga julgelt ühendust!