Vajadused ja nuded Targo Tennisberg Isehakanud guru http

Vajadused ja nõuded Targo Tennisberg Isehakanud guru http: //www. targotennisberg. com/tarkvara märts 2009

Nõuete olemus • “Nõuded” tähendavad erinevatele inimestele erinevaid asju Kasutaja jaoks on see. . . Arendaja jaoks on see. . . Nõuded Kõrgtaseme tootekontseptsioon Detailne kasutajaliidese disain Nõuded • Vahepeal veel terve spekter võimalusi • Ärge kunagi eeldage, et vastaspoolel on sama definitsioon

Näide: personaliosakond vs arendajad

Nõuded • Milleks meile nõuded? – Kui me ei tea, mis on meie vajadused, siis me ei tea, millal me valmis oleme – Täpsemad nõuded -> projekti tähtaja parem ennustatavus -> $$ • 3 nõuete taset – Ärilised • Rahuldavad ärilisi vajadusi (vt eespool) – Kasutajanõuded • Kirjeldavad, mida peab kasutaja saama produktiga teha – Funktsionaalsed • Süsteemi kirjeldus erinevates tingimustes • Kõik peavad olema kirjeldatud!

Ärivajadused • Organisatsiooni või kliendi kõrgtaseme vajadused • Võimalikud allikad – – Projekti sponsor Lõppkasutajate organisatsiooni juht “Visionäär” Turundus • Hea panna kirja skoobidokumenti • Tekstiredaktori näide: “tekstiredaktor peab laskma kasutajatel efektiivselt kirjavigu parandada” • Valmis olla võimalikeks tellijapoolseteks sisekonfliktideks – Sponsori huvide identifitseerimine kriitilise tähtsusega

Ärivajadused Funktsionaalsed sisendid Projekti visioon ja skoop Mittefunktsionaalsed sisendid

Kasutajanõuded • Kirjeldavad, mida kasutajad peavad saama teha • Erinevad formaadid – Kasutajalood – Stsenaariumikirjeldused – Event-response tabelid • Näide: uue reserveeringu tegemine hotelli veebisaidil • Tekstiredaktori näide: – Kasutajajuhtum: “leia kirjavead” – Kasutajajuhtum: “lisa uus sõnastikku”

Ärireeglid • • Eksisteerivad meie tarkvarast sõltumatult Seadused Ettevõtte eeskirjad Standardid – Nt tööstus- või raamatupidamisstandardid • Algoritmid • Turvanõuded – Kasutajagrupid

Ärivajadused Funktsionaalsed sisendid Mittefunktsionaalsed sisendid Projekti visioon ja skoop Ärireeglid Kasutajanõuded Kasutajalugude kirjeldus

Süsteemi nõuded • Süsteem koosneb definitsiooni järgi osadest • Mis realiseeritakse – Riistvaras? – Tarkvaras? – Inimeste poolt?

Kvaliteedinõuded • Kasutatavus – Tekstiredaktori näide: kirjutada lahti, mida tähendab tegelikult “efektiivselt”? • Porditavus • Efektiivus/jõudlus – Tekstiredaktori näide: peab võimaldama 10 MB dokumentide redigeerimist • Töökindlus – Mitu üheksat?

Funktsionaalsed nõuded • Tarkvarasüsteemi käitumise täielik kirjeldus • Kasutatakse – Arenduseks – Testimiseks – Projektijuhtimiseks • Tekstiredaktori näide: – Valesti kirjutatud sõna leidmine ja esiletõstmine – Soovitatavate paranduste dialoogi näitamine – Valesti kirjutatud sõnade asendamine kogu dokumendis

Ärivajadused Funktsionaalsed sisendid Mittefunktsionaalsed sisendid Projekti visioon ja skoop Ärireeglid Kasutajanõuded Kvaliteedinõuded Kasutajalugude kirjeldus Süsteemi nõuded Funktsionaalsed nõuded

Liidesed ja kitsendused • Liidesed kirjeldavad uue süsteemi ja välise maailma vahelist suhtlust • Kitsendused kirjeldavad arendajatele esitatavaid piiranguid ja valikuid

Ärivajadused Funktsionaalsed sisendid Mittefunktsionaalsed sisendid Projekti visioon ja skoop Ärireeglid Kasutajanõuded Kvaliteedinõuded Kasutajalugude kirjeldus Süsteemi nõuded Funktsionaalsed nõuded Spetsifikatsioon Välised liidesed Kitsendused

Nõuetest üldiselt • Nõuded peavad olema dokumenteeritud – Hulk emaile, märkmeid paberil ja koosolekuprotokolle ei ole veel nõuded – Projektimeeskonna vahetumine + dokumenteerimata nõuded = kuri klient • Eri liiki nõuded tulevad tavaliselt erinevatelt inimestelt • Nõuded ei tohiks sisaldada arhitektuuri ja realisatsiooni detaile – Välja arvatud välised piirangud • Mitte kunagi ära eelda mitte midagi • 70 -85% ringi tehtud projektide kulust on valesti mõistetud või puudulike nõuete tõttu

Nõuete kogumine • Süsteemi kasutajagruppide identifitseerimine • Gruppide esindajate vajaduste kogumine • Kasutajate ülesannete ja eesmärkide tundmaõppimine • Kasutajatelt saadud info analüüs: – Sorteerida funktsionaalsed/mittefunktsionaalsed nõuded, ametikirjeldused, ärireeglid, soovitatavad lahendused ja liigne müra

Nõuete kogumine 2 • Kõrgtaseme nõuete jagamine arhitektuuriliste komponentide vahel • Kvaliteedinõuete prioritiseerimine • Realisatsiooni prioriteetide läbirääkimine • Spetsifikatsioonide kirjutamine • Spetsifikatsioonide ülevaatamine

Esimene nõuete lõks • Meile ei anta ligipääsu lõppkasutajatele – Näide: keemikud • Alati vaja tellijale jutlustada kasutajate kaasamise tähtsust

Teine nõuete lõks • Klient kirjutab nõuete kogule alla – Tegelikult ta ei analüüsinud seda korralikult – Loomulikult tekivad muutused • Arendajad ütlevad: ise kirjutasid alla, ise süüdi • Kasutajad ei hakka aga süsteemi kasutama – Esimene projekt selle kliendiga jääb ka viimaseks • Alati on vaja defineerida nõuete muudatuste protsess

Nõuete haldamine • Defineerida nõuete baaskogum – Kehtib mingil konkreetsel ajahetkel – Kõik osalised nõustuvad • Nõuete muutused läbi vaadata • Nõuete muutused kontrollitud moel projektile lisada • Parandada projektiplaanid vastavalt muutunud nõuetele • Läbi rääkida uued lubadused • Vastavalt muudatustele parandada arhitektuur, lähtekood ja testimisplaan

Projekti visioon Visioon Projekti 1 skoop Projekti 2 skoop Projekti 3 skoop . . . Projekti n skoop

Visioonidokumendi struktuur 1. 2. 3. 4. Ärivajadused Lahenduse visioon Skoop ja piirangud Äriline kontekst

1. Ärivajadused 1. 2. 3. 4. 5. - Taust Miks me seda üldse teeme? Situatsiooni kirjeldus ja ajalugu, mis viis antud probleemi/lahenduseni Äriline võimalus Näide: kasutada ära võistleva toote halba mainet turvalisuse osas Ärilised eesmärgid ja edukriteeriumid SMART Näide: saavutada 80% turuosa tänu erialaajakirjades ilmuvatele hinnangutele ja turu-uuringutele Kasutaja või turu vajadused Näide: turvalisem toode Lisada ka selgitus, miks praegune olukord võistlev toode kasutajat ei rahulda Äririskid Kui riskid või muu info on juba mujal loetletud, pole vaja kopeerida, võib viidata

2. Lahenduse visioon 1. Visiooni lühikirjeldus - Näide: keemikud 2. Lahenduse peamised võimalused - Rõhutada võimalusi, mis eristavad uut toodet senisest või konkurentidest 3. Eeldused ja sõltuvused - Erinevatel osalistel erinevad eeldused, seetõttu kirja panna Sõltuvused on nt standardid, seadused, teised projektid, kolmandad parteid jne.

3. Skoop ja piirangud 1. - 2. 3. - Esimese väljalaske skoop Keskenduda võimalustele, mis pakuvad vähima vaevaga enim väärtust Muude võimaluste väärtus täpsustub pärast esimest väljalaset niikuinii Näide: Share. Point Skoobikirjeldus on esimene kaitseliin uute nõuete klassifitseerimisel Järgmiste väljalasete skoop Järgmiste väljalasete ligikaudne kirjeldus ja tähtaegade eesmärgid Mida lühemad, seda parem Piirangud ja väljajätted Mida ma arvame, et mõni osaline võib soovida, aga mida me kindlasti ei tee

Keemikud: kontekstidiagramm Keemikud Tarnija Kemikaalide ladu Kataloogi tellimus Tarnija Kemikaali. Tellimuse Kemikaalikataloog anum staatus anum Inventariraport Inventarimuutused Tellimus Kemikaalide arvestuse süsteem Kemikaalide kasutuse raport Tööohutuse osakond Koolitussertifikaadi päring Kemikaalide kasutuse päring Koolitussertifikaat Ribakoodi lugeja Ohtlike ainete koolituste andmebaas

4. Äriline kontekst 1. Peamised osalised - Osaliste huvid: tööviljakus, kulude kokkuhoid, automatiseerimine, uued võimalused, seadustega kooskõlastamine, parem kasutatavus 2. Projekti prioriteedid - Kiviat’i diagramm 3. Tegutsemiskeskkond - Nõuded kättesaadavusele, jõudlusele, töökindlusele 24/7 internetirakendusele hoopis teised nõuded kui kontoris aeg-ajalt kasutatavale rakendusele

• Ärivajadused 1. 2. Skoop ja piirangud 1. Taust - 3. - Näide: kasutada ära võistleva toote halba mainet turvalisuse osas Ärilised eesmärgid ja edukriteeriumid - 4. 2. SMART Näide: saavutada 80% turuosa tänu erialaajakirjades ilmuvatele hinnangutele ja turu-uuringutele 5. Näide: turvalisem toode Lisada ka selgitus, miks praegune olukord võistlev toode kasutajat ei rahulda - 3. Äririskid - Kui riskid või muu info on juba mujal loetletud, pole vaja kopeerida, võib viidata Visiooni lühikirjeldus Lahenduse peamised võimalused - 3. Rõhutada võimalusi, mis eristavad uut toodet senisest või konkurentidest Eeldused ja sõltuvused - Erinevatel osalistel erinevad eeldused, seetõttu kirja panna Sõltuvused on nt standardid, seadused, teised projektid, kolmandad parteid jne. Mida ma arvame, et mõni osaline võib soovida, aga mida me kindlasti ei tee Äriline kontekst 1. Peamised osalised - Lahenduse visioon 1. 2. Järgmiste väljalasete ligikaudne kirjeldus ja tähtaegade eesmärgid Mida lühemad, seda parem Piirangud ja väljajätted - - Keskenduda võimalustele, mis pakuvad vähima vaevaga enim väärtust Muude võimaluste väärtus täpsustub pärast esimest väljalaset niikuinii Näide: Share. Point Skoobikirjeldus on esimene kaitseliin uute nõuete klassifitseerimisel Järgmiste väljalasete skoop - Kasutaja või turu vajadused - Esimese väljalaske skoop - Miks me seda üldse teeme? Situatsiooni kirjeldus ja ajalugu, mis viis antud probleemi/lahenduseni Äriline võimalus - - - 2. Osaliste huvid: tööviljakus, kulude kokkuhoid, automatiseerimine, uued võimalused, seadustega kooskõlastamine, parem kasutatavus Projekti prioriteedid - 3. Kiviat’i diagramm Tegutsemiskeskkond - Nõuded kättesaadavusele, jõudlusele, töökindlusele 24/7 internetirakendusele hoopis teised nõuded kui kontoris aeg-ajalt kasutatavale rakendusele

Kuidas tunda oma kasutajat • • Lugu: töötajate andmebaas Kasutajatega kaasamine on ainus võimalus “nõuete augu” täitmiseks 1) 2) 3) 4) Identifitseerida kasutajaklassid Identifitseerida kasutajanõuete allikad Leida igast kasutajaklassist esindaja Kokku leppida, kes otsustab vajaduste üle • Kui mittekasutaja (ülemus, arendaja vms) ütleb, et ta teab niigi, mida kasutajal vaja on – Väga suure tõenäosusega pole tal õigus

Kasutajaklassid • Jagatavad mitmesuguste tunnuste alusel: • Kui sagedasti nad toodet kasutavad • Senine valdkonna- ja arvutikasutuse kogemus – Tihti ignoreeritakse seda erinevust! – Power user ja algaja on erinevad kasutajaklassid, isegi kui nad teevad sama tööd • Toote võimalused, mida nad kasutavad • Ülesanded, mida nad äris sooritavad • Ligipääsuõiguste tase (külaline, kasutaja, admin)

Kasutajaklassid 2 • Keemikute näide – Keemikud – Kemikaaliostjad – Laotöötajad – Ohutusreeglite eest vastutajad • Mõne kasutajaklassi ignoreerimine maksab enamasti kätte • Kasutajaklassidel on prioriteedid: kõik pole võrdsed

Kasutajate esindaja võimalikud tegevused • Tihti täidab seda rolli tellijapoolne projektijuht – Peaks olema ikkagi ka süsteemi tegelik kasutaja • Planeerimine – – Täpsustab toote skoopi ja piiranguid Defineerib liidestusi teiste süsteemidega Hindab uue süsteemi mõju äriprotsessidele Defineerib üleminekuprotsessi vanalt süsteemilt uuele • Nõuded – – – Kogub nõudeid teistelt kasutajatelt Kujundab stsenaariume ja kasutajalugusid Lahendab nõuetealaseid konflikte Seab realisatsiooni prioriteete Seab kvaliteedi ja jõudluse nõudeid

Kasutajate esindaja võimalikud tegevused 2 • Kontroll – – – Kontrollib nõuete dokumente Defineerib vastuvõtukriteeriume Defineerib testimisstsenaariume Hangib testandmeid Testib • Kasutajaabi – Kirjutab abitekste ja juhendeid – Valmistab ette koolitusmaterjale – Demonstreerib süsteemi teistele kasutajatele • Muudatuste haldus – – Hindab ja prioritiseerib veaparandusi Hindab ja prioritiseerib täiendusi Hindab muudatuste mõju kasutajatele ja äriprotsessile Osaleb muudatuste üle otsustamises

Vajaduste üle otsustamine • Konflikt ühe kasutajaklassi sees – Kasutajate esindaja otsustab • Konfliktid kasutajaklasside vahel – Otsustatakse kasutajaklassi prioriteedi põhjal – Või ärilise eesmärgi prioriteedi põhjal • Tellijapoolsed juhid ja kasutajad pole vajaduste osas ühel nõul – Aidata esile tõsta kasutajate esindaja rolli • Arendajad ja kasutajad pole vajaduste osas ühel nõul – Tellija peaks saama otsustada • Kas kliendil on alati õigus? – Ei, aga kliendil on alati “point”

Projekti mõõdikud • Kui asja ei saa mõõta, ei saa seda ka juhtida • Mõõdikud tuleks üles seada projekti alguses – Hiljem palju raskem infot taastada • Mõõdikud hindavad: – – – Ajagraafiku ja eelarve adekvaatsust Kulutatud energiat Toote mahtu Toote kvaliteeti Projekti staatust

Mida mõõta? • Mõõdikud ei tohi olla juhuslikud • Eesmärk -> küsimus -> mõõdik • Eesmärkide näiteid: – Vähendada vanade projektide hoolduskulusid 50% – Parandada ajahinnangute täpsust 10%-ni – Vähendada projekti üleandmise ja heakskiitmise aegu 2 nädala võrra – Vähendada vigade parandamiseks kuluvat keskmist aega 40%

Mida küsida? • Näide: kui eesmärgiks oli vähendada vanade projektide hoolduskulusid 50% • Kui palju me kulutame igas kuus hooldusele? • Milline osa meie hoolduskuludest läheb igale erinevale projektile? • Kui palju aega me kulutame: – Keskkonnast tulenevatele muudatustele reageerimisele? – Täienduste tegemisele? – Vigade parandamisele? • Nende küsimuste põhjal saamegi üles seada mõõdiku

Olulisemad mõõdikud • Toote suurus – Koodiread, funktsioonid, klassid, nõuded, kasutajalood, kasutajaliidese ekraanid – Esialgseid mõõdikuid võib korrutada “keerukuskonstandiga” • Hinnanguline ja tegelikult kulunud aeg – Kalendripäevades • Hinnanguline ja tegelikult tehtud pingutus – Töötundides – See pole päris sama, mis eelmine mõõdik! • Millistele tegevustele aeg kulus – Vastuseks protsendid ja suhtarvud • Vead – Vigade arv, tüüp, tõsidus, staatus ja allikad (testimine, ülevaatused, kliendid) • Nõuete staatus – Esitatud, heaks kiidetud, realiseeritud, kontrollitud ja tagasi lükatud nõuete arv

Spetsifikatsioonid: sihtgrupp • Spetsifikatsiooni loevad paljud inimesed • Klient – Mis see on, mille ta saab • Projektijuht – Ajakava ja kulutuste planeerimine • Arendajad – Mis see on, mida nad peavad looma • Testijad – Testimisplaanide ja protseduuride loomine

Spetsifikatsioonid: sihtgrupp 2 • Hooldus ja help desk – Mida süsteemi erinevad osad peavad tegema • Koolitajad – Juhendite ja materjalide koostamine • Juristid jt – Seadustele ja reeglitele vastavuse kontroll • Allhankijad – Töö planeerimine – Peatöövõtja poolne töö kontrollimine • Spetsifikatsioon peab arvestama kõigi nende gruppide vajadustega!

Spetsifikatsiooni struktuur 1. 2. Sissejuhatus 1. 2. 3. 4. 5. Eesmärk Standardite ja struktuuri kirjeldus Sihtgrupp Projekti skoop Viited 1. 2. 3. 4. 5. 6. 7. Toote kontekst Toote võimalused Kasutajaklassid ja nende eripärad Töökeskkond Disaini ja realisatsiooni piirangud Kasutajajuhendite kirjeldus Eeldused ja sõltuvused Üldine kirjeldus

Spetsifikatsiooni struktuur 2 3. Süsteemi võimalused (features) x. Feature X 1. 2. 3. Kirjeldus ja prioriteet Diagrammid Funktsionaalsed nõuded 4. Liidesed 1. 2. 3. 4. Kasutajaliidesed Riistvaraliidesed Tarkvaraliidesed Kommunikatsiooniliidesed

Spetsifikatsiooni struktuur 3 5. Mittefunktsionaalsed nõuded 1. 2. 3. 4. Jõudlus Ohutus Turvalisus Kvaliteet 6. Muud nõuded Lisa 1. Terminoloogiasõnastik Lisa 2. Joonised, tabelid, diagrammid Lisa 3. Lahtised probleemid

Nõuete visualiseerimine • 1 pilt on väärt 1024 sõna • Protsessid – Andmevoodiagramm • Olemid – Olemi-suhte-diagramm • Osalejad – Kasutajaloodiagramm • Olekumuutused – Olekudiagramm • Tegevused – Tegevusdiagramm

Prototüüpimine • “Ma tean, mida ma tahan, kui ma seda näen” • Prototüübi eesmärgid: – Täpsustada vajadusi – Uurida alternatiive – Vähendada ebakindlust ja riske • Võib olla väga lihtne – Paberist prototüüp – Wizard of Oz prototüüp – Aga ta peab olemas olema!

Prototüüpimise reeglid • Prototüüpimine peab olema osa projektiplaanist ja ajagraafikust • Enne prototüübi ehitamist tuleb defineerida tema eesmärk • Üks prototüüp on hea, mitu prototüüpi on parem • Mida odavam, seda parem • Jäta välja valideerimised, veahaldus, koodi dokumentatsioon jne – prototüüp on äraviskamiseks • Hästi tuntud probleeme pole vaja prototüüpida • Kasuta realistlikke andmeid • Prototüüp ei asenda spetsifikatsiooni!

Prioritiseerimine • Lugu: Me tahame kõike! – Tegelikus elus tuleb jagada, vähemalt ajaliselt • Prioriteedimaatriks – – Võimalusest saadav kasu Võimaluse ärajätmisest tekkiv kahju Kulu Risk • Prioriteet = (kasu + ärajääv kahju) / (kulu + risk) • Valemile võib lisada kaalusid ja muid parameetreid – Analüütiline lähenemine parem kui emotsionaalne

Nõuete pädevuse kontroll • Iga spetsifikatsioon tuleb ka osaliste poolt läbi vaadata – Analüütik (+ mõni teine analüütik) – Valdkonna asjatundja – Arendaja – Liidestatavate süsteemide haldaja • 2 faasi – Iseseisev läbivaatus – Arutluskoosolek

Näidisdokumendid • Cafeteria Ordering System Vision and Scope Document – http: //users. csc. calpoly. edu/~djanzen/courses/50 8 W 09/sampledocs/COS_vision_and_scope. doc • Software Requirements Specification for Cafeteria Ordering System – http: //users. csc. calpoly. edu/~djanzen/courses/50 8 W 09/sampledocs/COS_SRS. doc

Kokkuvõte • Täpsem ennustatavus -> edukas projekt • Täpsemad nõuded -> täpsem ennustatavus • Tegelike asjaosaliste sisend -> täpsemad nõuded