TTÜ informaatikatudengitele 17.10.2011

1. Süsteemi nõuete esiletoomine ja
analüüs
Priit Potter
priit@potter.ee

2. Priit Potter
• „Solution architect“
– Äri arendamine
– Selleks IT vahendite leidmine
– IT vahendite efektiivne arendamine
• Peamine taust ning kogemus Webmediast
• 10+ aastat IT projektide käivitamisi ja läbiviimist:
– EMT, Elion, Sertifitseerimiskeskus, Statistikaamet, EAS
– TeliaSonera, Fruugo
– Pangad, kindlustused, välisettevõtted jne

3. Kommunikatsioon ja vastutus
Äriarendus
Arendus,
testimine
jt
Süsteemianalüüs

4. Mille jaoks on mõtet tarkvara teha?
• Otsest rahalist võitu andvad eesmärgid
– Kõnekeskus vs iseteenindus
• Ajalist võitu andvad eemärgid
– Sünniakt
– Järjekorraautomaat
• “Seadusest” tulenevad eesmärgid
– Euro
– EL Struktuurifondide register
• Isiklikust motivatsioonist tulenevad eesmärgid

5. Tarkvara äriline kasu
• Äriettevõtte jaoks peab loodav tarkvara
(mingis perspektiivis) suurendama kasumit
• Kasum: tulud > kulud
• Iga lisakulu peab olema põhjendatud, sest
lükkab edasi kasumisse jõudmist!

6. Analüütiku vastutus
Analüütik vastutab selle eest, et
klient saab süsteemi, mida
vajab!

7. Loengu eesmärk
Kuidas esitada süsteemi
kirjeldus arendustiimile
võimalikult efektiivselt, st
võimalikult väikeste
lisakuludega?

8. Üks näide

9. • Infosüsteemi on võimalik kirjeldada
erinevatest aspektidest – sellist kirjeldamist
nimetame nõuete kogumiseks

10. Nõuded süsteemile
• „Nõue“ ei ole äri poolt esitatav nõudmine!
• Requirement: something required
– something wanted or needed : necessity <production
was not sufficient to satisfy military requirements>
– something essential to the existence or occurrence of
something else : condition <failed to meet the
school's requirements for graduation>
* http://www.merriam-webster.com/dictionary/requirement

11. Mis on nõue?
• Nõude 3 baasomadust:
– Ühene kontrollitavus – küsimusele „kas nõue on
täidetud?“ peab saama võimalikult üheselt vastata “jah”
või “ei”
– Kerge kontrollitavus – nõude kontroll ei tohi võtta
palju aega
– Sõnastuse lihtsus ja lühidus – nõude sisutekst ei
tohiks minna pikemaks kui nt 30 sõna, max 50 sõna

12. Kas need on head nõuded?
• „Iseteenindus peab suutma vastu võtta 50
liitumist tunnis“
• „Koduleht peab olema ilus“
• „Toetust ei maksta juhul, kui taotluse
esitamisel on vähemalt ühel lapsevanemal
võlgnevus Rae valla ees (sh maamaksu võlg)“
• „Liitumise leht peab avanema väga kiiresti“
• „Koduleht peab avanema kõigis maailma
riikides“

13. Nõuete kogumik
• Nõuete kogumiku moodustamisel on
eesmärgiks:
– Ühtlane kaetus – nõuete hulk peab ühtlaselt ja
piisava tihedusega katma kogu arendatavat
teemat.
– Piisav hulk – nõuete hulk peab olema piisavalt
suur, et katta kõik oluline. Aga mitte liiga detailne!
– Struktuurne jaotus – nõuete kogumik peaks
sisaldama hierarhilist struktuuri. Esmane jaotus
funktsionaalsed ja mittefunktsionaalsed nõuded.
13

15. Nõuete kogumik
• Nõuded on aluseks töö vastuvõtmisel!
– Dokumentatsioon
– Arendus (kood jm seotud tulemid)
– Testjuhtumite kirjeldused, testiraportid
– jne

16. Nõuete kogumik
Funktsionaalsed Mittefunktsionaalsed
Funktsionaalsus 1 Kasutatavus
Funktsionaalsus 2 Käideldavus
…
… Jõudlus …
…
Toetatavus
+

17. Nõuete kogumik
• FURPS+
– Functionality (funktsionaalsus)
– Usability (kasutatavus)
– Reliability (käideldavus)
– Performance (jõudlus)
– Supportability (toetus)
– + (disain, tehnilise realiseerimise piirangud, liideste
piirangud, majutuse piirangud jms)
• … samas: oluline ei ole metoodika, vaid see, et
kõik oluline saaks kirja!
17

18. Funktsionaalsed nõuded
sisend väljund
„Äriloogika“
Funktsionaalsed nõuded kirjeldavad, kuidas süsteem peaks
käituma kasutajapoolsete või teisest süsteemist pärinevate
sisendite peale.
Võimaldab kasutajal esitada pangale kaarditaotlus
Võimaldab otsida isikukoodi järgi võlgnevusi
Ei võta vastu taotlust kui laenusumma lahter on täitmata
Kuvab tähtajaks tasumata arved punasena
18

19. Näide: lift
• Peab saama lifti kutsuda
• Peab saama korrust valida
• Peab informeerima tellimuse vastuvõtmisest ja
täitmise progressist
• Peab saama abi kutsuda
• Peab saama lifti peatada
• Peab saama uksi avada
• Peab võimaldama „tuletõrje kasutust“
19

20. Kasutatavus (usability)
• Sobivus kasutaja mõttemudeliga: millised
kasutajad ja millises situatsioonis teie rakendust
kasutavad?
• Vahendid:
– Esteetika (disain, pildid, ikoonid)
– Õpitavus
– Tagasiside aeg (response time)
– Lihtne navigeerimine
– Kasutajaliidese ühtlus
– Abiinfo, dokumentatsioon
20

21. Kasutatavus (usability)
Eesmärk: pakkuda lõppkasutajale SUPERMANi
tunnet – süsteem võimaldab teha kõike, mis vaja
kasutajapoolse lisapingutuseta!
• Swype
• Metroo vs loomaaia värav
• Sõiduauto
21

22. Kasutatavus: lift

23. Kasutatavus: lift
• Lihtne kutsumine
• Selge korruse valik
• Info käesoleva korruse kohta
• Info kutsenupu seisundi kohta
• Valitud korruse indikaator peab olema eristatav
ka värvipimedale
23

24. Käideldavus (reliability)
• Lubatav vigade arv ning tõsidus
• Vigade esinemise vahele jääv ajavahemik (MTBF
– mean time between failures)
• Taastamisele kuluv aeg
• Väga kriitilised ärirakendused, reaalajasüsteemid
• Service Level Agreement
24

25. Käideldavus: lift
• Lifti mittetöötamist ei tohi olla rohkem kui 5
tundi (minutit) kuus
• Ei tohi juhtuda rohkem kui üks selline tõrge
aastas, mille tulemusena inimesed jäävad lifti
lõksu
• Sellist tüüpi vead tuleb lahendada 30 minuti
jooksul
25

26. Jõudlus (performance)
• Tegevuse kestus (keskmine, maks)
• Tegevuste arv (tegevusi sekundis)
• Võimsus (maks. samaaegsete klientide arv)
• Läbilaskevõime (lehekülgi või MB sekundis)
• Piirkoormus, lubatavad jõudluse languse piirid
kõrge koormuse tingimustes
26

27. Jõudlus: lift
• Lift peab suutma teenindada 300 inimest
tunnis
• Lift peab samaaegselt teenindama 8 inimest /
500 kg
• Lifti keskmine tulekuaeg peab jääma alla 1
minuti, tippajal alla 2 minuti
27

28. Toetatavus (supportability)
• Kui palju raha peab kulutama süsteemi käigus
hoidmisele?
• Testitavus (vigade diagnoosimise lihtsus)
• Hooldatavus (regulaarsed uuendused)
• Konfigureeritavus (runtime vs koodis)
• Laiendatavus
• Lokaliseeritavus
28

29. Toetatavus: lift
• Lifti tarkvara uuendamine ei tohi võtta üle 10
minuti
• Lift ei tohi nõuda hooldust tihemini kui kord
aastas
29

30. Nõuded: kokkuvõte
• Hästi organiseeritud ja läbi mõeldud nõuete
kogumik:
– Vähendab ümbertegemist ja sellest tekkivat stressi
– Vähendab ajakulu kõigis arenduse lõikudes
– Aitab keskenduda olulisele
• -> tagab lõpptarbijale
meeldivama/parema/efektiivsema lahenduse,
mille tagajärjel suureneb süsteemi eesmärkide
täitmine
30

31. Mis edasi?
• Nõuete kogumiku alusel koostatakse süsteem ja vajalikud
lisatulemid:
– Arenduse eelarve
– Kasutusjuhud
– Komponendi kirjeldused
– Andmemudel
– Programmikood
– Paigaldamise skriptid
– Automaattestid
– Manuaalsed testid
– Projekti aruanne
– Jne…
– Jne… vastavalt kliendiga kokkulepitule

32. • Millised neist tulemitest on hädavajalikud?
– Arenduse eelarve – Paigaldamise skriptid
– Kasutusjuhud – Automaattestid
– Komponendi – Manuaalsed testid
kirjeldused – Projekti aruanne
– Andmemudel – Jne
– Programmikood

33. Analüütiku vastutus
• Analüütik vastutab selle eest, et
klient saab süsteemi, mida ta
vajab!
• NB! Kõik saavad kirjutatust erinevat moodi aru!
• NB! Kes viitsib lugeda 500 lk dokumenti ja on
võimeline tagama, et seal kõik kirjas on?
• NB! Mis saab agiilsest arendusest??

34. Kuidas seda tagada?
• Hea, tasakaalus, hierarhiline nõuete kogumik
• Dokumentatsiooni koostamine
tasakaalustatult kogu projekti jooksul
• Elagu prototüüpimine!

35. Prototüüpimise vajalikkus?
• Lahendus mõeldakse detailides läbi
• Lõppkasutaja saab testida funktsionaalsust enne
realisatsiooni
• Tellijal ja täitjal ühine nägemus lõpptulemusest ja
vahetulemitest
• Leitakse vastused “väiksematele” aga olulistele
küsimustele
• Mis on lihtsam ja mis keerulisem funktsionaalsus
• Selgemalt saab eraldada, mis on muudatus, mis on
puudujääk ja mis täitja viga
• Selgem ülevaade kui palju projektist valmis on

36. Visualiseerimise meetodid
• Seinatehnika ja prototüübikaust
– Whiteboard ja fotoaparaat
– Paber, pliiats ja faksiaparaat
– ...
• Passiivsed kuvad
– Olemasolev rakendus ja „Paint“
– Excel, Visio, jne
– Tehniline ülesanne koos ekraanivaatega
– ...
• Staatilise infoga prototüüplahendused:
– Prototüübimootorid
– Lihtsamad HTML või klient-server rakendused
– „Mina ütlen, Sina joonistad“ lahendus
– ...

37. Wireframe’i näited

38. Wireframe’i näited
http://www.balsamiq.com/

39. Prototüübimootori näide

40. Ekraanivaadete elemendid
• Ekraanivaate elemendid
• Component library, UIG (User Interface
Guidelines kirjeldus) jne
• Miks neid vaja on?
– Mõju arenduskiirusele
– Rakenduse intuitiivsus
– Mõttemaailma raamid
– Lõppkasutajate koolitus

41. Kasutatavusest korra veel
Kuidas lõppkasutajad rakendust kasutavad?
• Kasutuslugude testimine koos lõppkasutajaga
• http://www.realeyesit.com/
• Analüüsimeetrika logides ja andmebaasides

42. Kokkuvõtteks
• Efektiivseks süsteemianalüüsiks on vaja:
– aru saada, milleks süsteem luuakse (!!)
– head nõuete kogumikku
– head viisi kliendiga skoobi jm detailide
kokkuleppimiseks

43. • Küsimusi?
Priit Potter
priit@potter.ee