Eelanalüüs ja detailanalüüs - mille poolest nad erinevad?

Kui otsida tarkvara kasutajanõude dokumendi definitsiooni, siis võime saada vastuseks kliendi ja tarkvaraarendaja vahelise lepingu, mille alusel tarkvaraarendaja võtab tarkvara väljatöötamise töösse. See on küllaltki levinud definitsioon, kuid sellisel lähenemisel on mitmeid probleeme.

Analüüs toimub arendusprotsessi algusest lõpuni välja ning selle metoodika erineb tugevalt näiteks ehitusvaldkonnas kasutatavast. Ehituses saame tõmmata selge joone, kus lõpeb projekteerimine ja algab füüsiline realiseerimistöö.

Tarkvaraarenduses meil sellist luksust pole, sest lahenduse kavandamine toimub tavaliselt kogu arendustöö jooksul.
 

Ükski tarkvara spetsifikatsioon ei saa olla lõpmata detailne

Ta ei saa vastata kõikidele võimalikele tarkvaraarendaja küsimustele, sest sellise dokumendi koostamise töömaht oleks samaväärne tarkvara enda valmis tegemise töömahuga.

Seega, kui ideaalse detailsuse tasemega kasutajanõuete dokumenti pole võimalik luua, siis peame välja mõtlema lähtepunktid, et leida detailsuse tase, mis just antud projekti puhul on mõistlik.

NB! Sageli räägitakse süsteemianalüüsi kontekstis eel- ja detailanalüüsist. Tegelikult on eel- ja detailanalüüsi mõistete kasutamisega palju segadust, kuna tegu on üldiste terminitega, mille definitsioonid on peaaegu iga tellija puhul erinevad.

Oleme näinud, kuidas üks klient tellib eelanalüüsi, mille tulemusena soovitakse palju suuremat detailsust, kui teisel tellijal, kes enda arvates soovib detailanalüüsi.

Eel- ja detailanalüüsi üldmõistete asemel võiks kasutada kolme järgnevalt kirjeldatud detailsuse taset. Oma töödes keskendume kahele esimesele.

Ärinõuete analüüs ehk visiooni tase – tegemist on äriliste vajaduste sõnastamisega, mis algab probleemi püstitamisest. Analüüsitakse, miks on täna arendust vaja ning milline on soovitava süsteemi eesmärk ja skoop.

Näiteks näeb äripool, et ettevõtte mahud kasvavad („praegu on 50 000 arvet kuus ja aasta pärast on vaja teha 100 000 arvet kuus, kuid olemasolev süsteem jääb juba praegu aeglaseks“).
 

Ärianalüüs on suunatud süsteemi omanikele ehk isikutele, kes teevad otsuse süsteemi investeerida. Kavandatava süsteemi kirjeldus peab olema selline, et ühelt poolt on võimalik mõista kavandatavast süsteemis saadavat kasu ja teiselt poolt saab hinnata arenduse maksumuse suurusjärku (näiteks, kas see on 50 000, 100 000 või 300 000 eurot).

Kui ärianalüüs on tehtud, siis tellija saab teha esimese ja väga tähtsa otsuse: kas alustada projekti ellu viimist täna, lükata see tulevikku või üldse loobuda sellest.

Detailne kasutajanõuete analüüs – defineerime, milline on süsteem kasutaja vaatepunktist. Analüüsime äriprotsessi ning jõuame edasi kasutuslugudeni (use case) või soovilugudeni (user story).

Paralleelselt algab töö ka interaktiivse kasutajaliidese prototüübiga. Kasutajaliidese prototüüp aitab kasutajal kõige paremini saada aru, kuidas süsteem lõppkasutaja jaoks välja hakkab nägema ning kuidas ta töötab.
 

Antud analüüs on suunatud süsteemi tulevastele lõppkasutajatele – inimestele, kes hakkavad tulevikus süsteemi kasutama. Kasutajanõuete analüüsi tulemusena saavad tulevased kasutajad öelda: „jah, sellisest tarkvarast oleks meile kasu“.

Süsteeminõuete analüüs – kirjeldame süsteemi käitumise aspektid, mis lõppkasutaja vaatepunktist pole esmatähtsad, kuid vajalikud tarkvara realiseerimiseks ja administreerimiseks.

Detailsete süsteeminõuete dokument peaks sisaldama kõiki eriolukordi, millega tarkvara arendaja peab arvestama. Näiteks, kuidas lahendatakse autentimise mehhanismid ja sisse logimised, kuidas on lahendatud andmeside tehnilised protokollid, kuidas tuleb süsteemi dokumenteerida ja millised tehnoloogilisi lahendusi tuleb kasutada.

Siia juurde võivad lisanduda ka nõuded arendusprotsessi kohta, näiteks kuidas testimine ja üleandmine peavad toimuma.

Analüüsi tulemust tuleks eelkõige hinnata järgmiste kvaliteedikriteeriumite alusel

Konsensuslik – analüüsi tulemeid on korduvalt läbi arutatud ja kõik osapooled on ühiselt veendunud, et just see ongi süsteem, mida saada soovitakse. Kuna infosüsteemide muudatused puudutavad tavaliselt mitmeid eri valdkonna inimesi, siis peame veenduma, et kõik osapooled jagavad ühist nägemust.

Analüüsiprotsessi lõpuks on nad veendunud, et tegemist on süsteemiga, mis on nende organisatsioonile kasu(m)lik.

Arusaadav – dokument on vormistatud ja kirjutatud selliselt, et ärikasutaja saab temast suurema vaevata aru.

Mahuka dokumentatsiooni puhul on oluline, et dokument oleks hästi struktureeritud, liikudes üldiselt tasemelt detailsemale ja dokumentatsiooni osad on täpselt viidatavad ning ka erialaterminid on lahti kirjutatud. Kasutajanõuete kirjutamisel mõelge, kas nii tarkvara tulevane kasutaja kui ka tavaline arendaja saab teie sõnakasutusest aru.

Te võite joonistada väga intrigeerivaid UML diagramme, kuid tihtipeale ei saa dokumentatsiooni lugejad nendest aru. Seega tekitate ebavajalikku segadust. Kasutage hoopis äärmiselt elementaarset notatsiooni.

Vastuoludeta – dokumentatsioon ei tohi iseendale vastu rääkida. Samuti ei tohi erinevad dokumendid vastu käivat informatsiooni sisaldada.

Tavaliselt tulevad vead sisse siis, kui sama projektiga töötab mitu inimest. Nii võime olla silmitsi olukorraga, kus andmed küll tulevad, aga süsteemis ei ole kohta, kuhu neid panna.

Terviklik – analüüs katab kogu ulatuse. Ei tohi teha viga, et süvenetakse mingi huvitava probleemi lahendamisesse, aga kui arendusmahud on ära hinnatud ja töö käib, siis selgub, tegelikult on teine pool maailmast juures. Detailsus pole siinkohal isegi oluline. Oluline on sisuline terviklikkus.

Sõltumatu - kui räägime esimesest 2 tasemest, siis peaks analüüs olema konkreetsest tehnoloogilisest lahendusest sõltumatu. Seda sellepärast, et ta ei mõjutaks ega piiraks põhjendamatul kombel tehnolooga valikuid.

Reeglina üritame seda enda töös vältida. Kui kirjutada kasutajanõuetesse tehnoloogiline lahendus sisse, siis selles etapis peab selliste piirangute seadmine olema väga hästi põhjendatud.

Testitav ja verifitseeriv - detailsed nõuded peavad olema üheselt kontrollitavad. Ärianalüüsi tulemusena ehk visioonis sätestatud vajaduste täitmine pole alati nii üheselt kontrollitavad, sest annavad pigem üldiseid suuniseid.

Detailid võivad mõjutada süsteemi lõplikku headust. Seepärast peavad detailsed kasutajanõuded olema kirjeldatud piisavalt detailselt, et testimise käigus saaks objektiivselt mõõta või kontrollida nende täidetust. Seetõttu pole näiteks „kiire“ hea nõue.

Teisisõnu „toiming võtab kolm sekundit“ on mõõdetav, kuid „süsteem on kiire“ ei ole mõõdetav. Nõuded, mida me tihtipeale oma töös näeme käib süsteemi kasutusmugavuse kohta.

„Süsteem peab olema mugav“ ei ütle tegelikult midagi. Kui teeme kasutajaliidese prototüüpi, siis on meie ülesandeks detailselt lahti kirjutada, mida „mugav“ tegelikult tähendab, sest sageli sõltub tegelik kasutusmugavus pisiasjadest, näiteks kas süsteem omistab olulised vaikeväärtused.
 

Kuidas edasi?

Kui olete tellija, siis peaksite mõtlema, millises faasis te oma ideega olete ning kui selge on teie enda nägemus kavandatavast tarkvarast. Näiteks, kas arendusprojekti käivitamise otsustamiseks vajalik ärianalüüs juba mõttes ära tehtud.

Vorm ei ole tegelikult esmatähtis. Analüüs võib olla tehtud analüüsitarkvaras, paberil või teie enda mõtetes. Tähtis on, et tarkvara tellija võtmeisikutel on selge ja ühine visioon.
 

Tulge ja räägime teie vajadustest

Vajadustest rääkimine on loomulik müügiprotsessi osa. Rääkige oma mure ära. Tulge, näitame näiteid ja läbirääkimiste käigus küsitavate küsimuste kaudu saate aru, mis teil on tehtud, mis on veel segane ja kuidas kõige otstarbekamalt oma projektiga jätkata saate.