Vaatimusmäärittelyistä

JOTU 16.09.2013

16.9.2013 JOTU2013/K.Systä 1

Tiedotuksia

• Harjoitusryhmiin ilmoittautuminen on vihdoin avautunut IDLE:ssä

• Ryhmän maksimi koko on 4 henkeä

• Ilmoittautumisen takaraja on 24.9!

16.9.2013 JOTU2013/K.Systä 2

Tässä kuvassa on koko kurssin sisältö?

16.9.2013

3 JOTU2013/K.Systä

16.9.2013 4

Viime kerrasta Kehitysprosessit: erilaisia variaatioita samasta teemasta

Asiakkaan ongelma

Määrittely

asiakasvaatimukset

Suunnittelu

ohjelmistovaatimukset, ”määrittely”

Toteutus

tekniset vaatimukset, ”suunnittelu”

Hyväksymistestaus

asiakastoimitus

Te

sta

us, la

ad

un

va

rmis

tus

Seuraava versio

JOTU2013/K.Systä

Viime kerrasta Vesiputousmalli

16.9.2013 5

Määrittely

Suunnittelu

Toteutus

Testaus

JOTU2013/K.Systä

Viime kerrasta Iteratiiviset, ketterät yms

16.9.2013

6

Toimittaja

Asiakas

tutkimus

määr.

tot

test

käyt.otto

tarjouspyyntö

tarjous

tarjous

määr. käyt.otto

demo

demo

tot

test

demo

demo

tot

test

tot

test

demo

demo

Demo tarkoittaa yhdessä käyttäjän

kanssa tehtävää uudelleen

pohdintaa.

JOTU2013/K.Systä

Viime kerrasta Kaksi erilaista johtopäätöstä

1. Kannattaa käyttää alussa paljon aikaa vaatimusten

miettimiseen ja kirjaamiseen ennen kuin kirjoittaa

yhtäkään koodiriviä.

2. Vaatimukset – tai ainakin ymmärrys niistä – muuttuu

projektin aikana kuitenkin. Joten parasta iteroida

palanen kerrallaan.

16.9.2013 7 JOTU2013/K.Systä

Kuitenkin

• Käyttäjän ja asiakkaan ongelman

ymmärtäminen ja toimivaksi ohjelmaksi

muuttaminen on edelleen se haaste.

• Ainakin alustavat vaatimukset on oltava

kasassa ennen kuin projektia aloitetaan.

• Käymme ensiksi asiat läpi kuin ketteryyttä ei

tarvittaisi ja sitten tuomme mukaan

ketteryyden.

16.9.2013 JOTU2013/K.Systä 8

Kiva löytö: (Ken Schwaber: Agile project managemet)

16.9.2013 JOTU2013/K.Systä 9

Close to

agreement

Far from

agreement

Close to certainty Far from certainty

Simple

Complicated

Complicated

Complex

Anarchy

Asiakasvaatimuksista tuotteeseen

Määrittely

Suunnittelu& toteutus

ohjelmistovaatimukset

asiakasvaatimukset

16.9.2013 JOTU2013/K.Systä 10

Erilaisia vaatimuksia - esimerkki

• Asiakasvaatimus – tyypillisesti asiakkaan ongelma, jolle toivotaan ratkaisua: tuotetaan mahdollisimman virheettömiä dokumentteja.

• Ominaisuus, feature – jokin asiakkaan kannalta mielekäs kokonaisuus ohjelmiston toiminnallisuudesta: tuki oikeinkirjoituksen tarkastamiselle.

• Ohjelman toiminto – yksittäinen ohjelmistolla tehtävä asia: tarkasta oikeinkirjoitus, ehdota korjausta, korjaa automaattisesti...

• Tekniset vaatimukset – miten ohjelmisto toteutetaan: tiedostopuskuri, dialogin toteutus, ...

Kannattaa huomata, että luokittelu ei ole mitenkään itsestään selvä.

16.9.2013 JOTU2013/K.Systä 11

Asiakas- vaatimukset

Ohjelmisto- vaatimukset

Vaatimukset vs. rajoitteet

• Toiminnallinen vaatimus (functional requirement), esimerkiksi ohjelmassa on tuki oikeinkirjoituksen tarkastamiselle.

• Ei-toiminnallinen vaatimus (non-functional requirement), esimerkiksi ohjelman käyttöliittymä on UI-tyyliopas mukainen tai ohjelmiston asennus saa käyttää korkeintaan 5MB levytilaa.

• Reunaehdot (constraints), esimerkiksi ohjelmisto on toteutettava Windows-ympäristöön C++-kielellä.

16.9.2013 JOTU2013/K.Systä 12

16.9.2013

Rajoitteiden rooli

Kaikki mahdolliset ratkaisut

Rajoite 1 Rajoite 2

Vaatimusmäärittely työvaiheena

16.9.2013 JOTU2013/K.Systä 14

16.9.2013

Määrittelyvaihe (kuva 3.8)

Asiakasvaatimukset

muuntuvat ohjelmistovaatimuksiksi

OK

korjattavaa

Määrittelyprosessi Ideat,

lähtökohdat,

rajoitteet,

reunaehdot Ongelman

ymmärtäminen,

vaatimusten

kartoitus

Toteutettavan

järjestelmän

spesifiointi

Tarkastus

Toiminnallinen

määrittely, alustava

käyttöohje,

toteutusprojektin

projektisuunnitelma,

testaussuunnitelma

Arkkitehtuuri-

suunnittelu

Asiakasvaatimukset Ohjelmistovaatimukset

-sidosryhmien tarpeet (asiakkaat, käyttäjät, markkinointi, johto...) -olemassa olevat järjestelmät -sovellusalueen erityispiirteet -asiakasorganisaation käytännöt -viranomaismääräykset -...

-Kartoittaminen -Analysointi -Dokumentointi -Validointi

Vaatimusten muutosprosessi

Hyväksytyt vaatimukset

Vaatimukset seuraaviin tuoteversioihin

Vaatimusmäärittely

Vaatimustenhallinta

vaatimusmuutokset muutokset projektissa

hyväksytyt muutokset

Vaatimusmäärittely vs - hallinta

16.9.2013 JOTU2013/K.Systä 16

-Kartoittaminen -Analysointi -Dokumentointi -Validointi

Vaatimusten muutosprosessi

Hyväksytyt vaatimukset

Vaatimukset seuraaviin tuoteversioihin

Vaatimusmäärittely

Vaatimustenhallinta

vaatimusmuutokset muutokset projektissa

hyväksytyt muutokset

Vaatimusmäärittely ja –hallinta ketterässä

16.9.2013 JOTU2013/K.Systä 17

16.9.2013

Miten asiakasvaatimukset saa selville (kehittäjänäkökulma)

• Toimialan tuntemusta ei korvaa mikään. • Tee luettelo sidosryhmistä (stakeholder).

– Mieti, mitä odotuksia/toiveita/pelkoja jne... kullakin sidosryhmällä on.

• Keskustele käyttäjien kanssa heidän työpaikallaan. • Suunnittele vierailut etukäteen huolellisesti. • Tekeydy hieman tyhmemmäksi kuin luulet olevasi. • Esitä varmistavia kysymyksiä: tarkoitat siis, että… • Käytä esitystapoja, joita asiakas ymmärtää. • Analysoi ja dokumentoi vierailun anti, tee yhteenveto. • Yritä löytää alkuperäinen ongelma:

– miksi jokin asia pitää tehdä, voisiko sen jostain syystä jättää kokonaan tekemättä.

– yritä erottaa oleellinen pinttyneistä toimintatavoista

• Prototyypit. • Käyttäjäkeskeinen suunnittelu (User Centered Desing)

JOTU2013/K.Systä 18

16.9.2013

Miten asiakasvaatimukset saa kerrottua (asiakasnäkökulma)

• Muista että toimittajalla ei aina ole toimialan tuntemusta – Voisi olla valintakriteeri

• Tee luettelo sidosryhmistä (stakeholder). – Mieti, mitä odotuksia/toiveita/pelkoja jne... kullakin on.

• Keskustele käyttäjien kanssa heidän työpaikallaan. • Suunnittele vierailut etukäteen huolellisesti. • Tekeydy hieman tyhmemmäksi kuin luulet olevasi. • Esitä varmistavia kysymyksiä: tarkoitat siis, että… • Käytä esitystapoja, joita toimittaja ymmärtää. • Analysoi ja dokumentoi vierailun anti, tee yhteenveto. • Yritä löytää ja kertoa alkuperäinen ongelma:

– Et ehkä tiedä miten asia kannattaisi ratkaista – Mitä ja miten ovat eri asioita

• Prototyypit. • Käyttäjäkeskeinen suunnittelu (User Centered Desing)

JOTU2013/K.Systä 19

16.9.2013

Mitä vaatimuksesta kirjataan (esimerkki)

• Luontipäivämäärä

• Tekijä

• Asiakas, vaatimuksen alkuperä

• Tyyppi (lisäys, muutos, korjaus)

• Vaatimuksen kuvaus

• Suhde muihin vaatimuksiin

• Tarpeellisuus (välttämätön, suotava, ekstra)

• Varmuus: ei muutu, saattaa muuttua, muuttuu todennäköisesti

JOTU2013/K.Systä 20

16.9.2013

Hyvän speksin/vaatimuksen ominaisuuksia

• täydellisyys: kaikki tarpeellinen, ei mitään turhaa

• tarkkuus

• virheettömyys

• ymmärrettävyys

• testattavuus: miten voidaan "mitata", onko vaatimus täytetty

• jäljitettävyys: mistä vaatimus on peräisin, miten tärkeä se on

• sama asia vain yhdessä paikassa (ei redundanssia) (?)

JOTU2013/K.Systä 21

16.9.2013

Esimerkkejä

• Järjestelmän käytettävissä on 64k-tavun muisti. • Luokalla voi siis olla vain yksi luokanvalvoja? • Jos kuukauden toteutunut myynti alittaa tavoitteet,

tulostetaan raportti, ellei toteutuneen myynnin ja tavoitteen ero ole vähemmän kuin puolet edellisen kuukauden tavoitteen ja toteutuneen myynnin erosta, tai toteutunut myynti alittaa tavoitteen alle 5%.

• Varaston kiertonopeus kasvaa. • Ilmoituksen on oltava kuvaruudulla 300ms kuluessa

hälytyksen tapahtumisesta. • Suihkumoottoreita ei saa kytkeä “pakille” ellei kone ole

kentällä. • Suihkumoottoreita ei saa kytkeä “pakille” ellei nokkapyörä

pyöri tai nopeus ole nolla.

JOTU2013/K.Systä 22

Tämän viikon ”sattumus” Ariane 5 kantoraketin onnettomuus

16.9.2013 23 JOTU2013/K.Systä

Ariane 5 – analyysi (koko analyysi: http://www.ima.umn.edu/~arnold/disasters/ariane5rep.html)

• Ongelman alkulähde on vaakanopeutta seuraava yksikkö

• 64bittinen liukuluku muunnettiin 16-bittiseksi kokonaisluvuksi

– Tällä kertaa syntyi ylivuoto

– Tämä oli voitu välttää tarkistuksilla, mutta juuri tätä muuttujaa ei oltu suojattu.

– Joten syntyi ns. ”poikkeus” ja yksikkö lähetti ”potaskaa”

• Vääristyneiden mittausarvojen tuloksena ohjausraketit yrittivät massiivista korjausliikettä

• Ylivuoto syntyi koska Ariene 5:n suorituskyky oli suurempi kuin edeltäjän (Ariane 4) mutta Arian 5 uudelleen käytti vanhan järjestelmän softaa

• Ylivuotoon joutunut järjestelmä oli vikatilanteiden vuoksi kahdennettu mutta ajoi samaa ohjelmistoa

16.9.2013 24 JOTU2013/K.Systä

Ariane 5

• Ylivuotoon joutunut järjestelmä oli tarpeen vain silloin kun raketti vielä seisoo laukaisualustalla ja se oltaisiin voitu ottaa jo pois päältä

– Sen piti olla päällä edellisessä versiossa

• Ongelmana oli vaakanopeus jonka kukaan ei ollut uskonut kasvavan liian suureksi

16.9.2013 25 JOTU2013/K.Systä

16.9.2013 26

UML-kaaviot

Use case

driver

Handle tree

Cut log

Use case diagram

Käyttötapauskaavio

Sijoittelukaavio Komponenttikaavio Tilakaavio Aktiviteettikaavio

Yhteistyökaavio Tap.sekv.kaavio Luokkakaavio Class/Package/Object diagrams

Log Tree

1..*

pine: Tree :Tree

Sequence diagram

pine:Tree :Log

Driver

Cut <<create>>

calcullate

Feed setMeasures

Collaboration diagram

pine:Tree

:Log

Driver

1. Cut

2. Feed

1.1. <<create>>

1.2. calculate

2.1. setMeasures

Activity diagram

H

H

Select tree

variety

Catch hold of tree

Fall the tree

Feed&saw

State machine diagram (State chart)

H

H

Saw idle

Saw operational

Cut / ^Start chain

CutOK / ^StopChain

Component diagram

Production

Production H.U.I.

Log Tree

Production

Deployment diagram

<<Laptop>> H.U.I.

Production

H.U.I.

<<processor>> Main Unit

<<CAN>>

JOTU2013/K.Systä

16.9.2013 27

Dipparekisteri

• Ohjelmistotekniikan laitoksella valmistuu noin 100 diplomityötä vuodessa

• D-työn tekemiseen kuluu aikaa muutamista kuukausista useisiin vuosiin

• D-töitä ohjaavat laitoksen professorit, kukin hieman toisista poikkeavalla tavalla

• D-työstä ylläpidetään aina tiettyjä perustietoja, lisäksi ohjaajilla on henkilökohtaisia tapoja pitää muistiinpanoja

• D-töiden etenemistä seurataan: diplomityön rajaus valmis, aihe hyväksytty tk-neuvostossa, x sivua kirjoitettu, työ tuotu tarkastettavaksi, työ hyväksytty, seminaariesitelmän pvm, jne.)

• Järjestelmän pitää siis sisältää yhteinen tietovarasto, jossa on kaikkien diplomitöiden perustiedot ja toisaalta yksittäisen ohjaajan tietovaraston pitää olla henkilökohtaisiin tarpeisiin mukautettavissa (ja käytettävissä ilman verkkoyhteyttä?).

JOTU2013/K.Systä

16.9.2013 28

Käyttötapauskaavio, versio 1

Ohjaaja

Lisää uusi

opiskelija

Etsi ehdot

täyttävät

opiskelijat

kirjoita

lausunto

tee

palaverimuisti

o

Lisää uusi

kenttä

Dipparekisteri

Pohja järjestelmän

hahmottamiselle ja siitä

keskustelemiselle

JOTU2013/K.Systä

16.9.2013 29

Käyttötapauskaavio, versio 2

Ohjaaja

Laitoksen johtaja

Lisää uusi

opiskelija

Etsi ehdot

täyttävät

opiskelijat

kirjoita

lausunto

tee

palaverimuistio

tarkastele

tilastoja

lisää/poista

ohjaaja

Lisää uusi

kenttä

Dipparekisteri

JOTU2013/K.Systä

16.9.2013 30

Toinen esimerkki KT-kaaviosta (kuva 8.6)

Varausten

poistaminen

Salinvarausjärjestelmä

Vastuu -henkilö

assistentti

ylläpitäjäPerustietojen

ylläpito

Luentosalin

varaaminen

Harjoitussalin

varaaminen

Käyttäjän

identifiointi

Käyttäjän

identifiointi

<<include>>

<<include>>

<<include>>

<<include>>

Salivuokran

laskutus

Salivuokran

laskutus <<actor>>

vuokra-

järjestelmä

<<actor>>

vuokra-

järjestelmä

JOTU2013/K.Systä

… esimerkki (kuva 8.7) Nimi: Luentosalin varaaminen, versio 1.0 / ijh

Osallistujat: Kurssin vastuuhenkilö

Tuloehdot: Vastuuhenkilö ja kurssi on syötetty järjestelmään (KT henkilötietojen

ylläpito)

Kuvaus: Vastuuhenkilö seuraa WWW-linkkiä, joka johtaa järjestelmän

pääsivulle. Hän syöttää järjestelmään käyttäjätunnuksensa ja salasanansa

(include: KT käyttäjän identifiointi). Käyttäjä pyytää järjestelmää näyttämään

salin varaustilanteen haluamaltaan aikaväliltä. Hän saa eteensä salin

lukujärjestysnäytön (ks. liite). Käyttäjä näkee näytöstä vapaat ajat sekä myös,

mille kursseille sali on milloinkin varattu ja kuinka monelle viikolle. Käyttäjä

tekee varauksen joltain vapaaksi havaitsemaltaan ajankohdalta. [Poikkeus:

varaus ei onnistu].

Poikkeukset: Varaus ei onnistu: Varaustilanne on voinut muuttua sillä aikaa kun

varaaja tekee varausta. Järjestelmä ilmoittaa tilanteesta käyttäjälle ja käyttäjä

yrittää uudelleen.

Lopputulos:Varaukset kurssin luentoajoiksi on tehty.

Muut vaatimukset:Päivittäin käsitellään kiireisimpänäkin aikana enintään n.

100 varausta. Vastausajan on oltava alle 1 sekuntia, lukujärjestysnäytön päivitys

saa kestää 5 sekuntia. 16.9.2013 JOTU2013/K.Systä 31

Käyttötapauksen kuvaaminen UML ei standardoi mitenkään esitystapaa, eikä oikeastaan juuri

muutakaan niihin liittyvää => paljon erilaisia tulkintoja

Käyttötapauksen sisältö voidaan kuvata esimerkiksi:

Käyttötapauksen nimi: Kuvaava nimi

Osallistujat: Mitkä aktorit osallistuvat

Tuloehdot: Mitkä ehdot ovat voimassa, kun käyttötapaus aloitetaan

Kuvaus: Epäformaali, voidaan käyttää myös sekvenssikaavioita

Poikkeukset: Poikkeustilanteet (mainitaan myös kuvauksessa)

Lopputulos: Mitkä ehdot ovat voimassa, kun käyttötapaus

lopetetaan

Muut vaatimukset: käyttötapaukseen liittyvät ei-toiminnalliset vaatimukset

16.9.2013 JOTU2013/K.Systä 32

16.9.2013 33

Käyttötapaus

Käyttötapaus

Aktori <<include>>

Käyttötapaus

<<extend>>

Aktori: käyttötapaukseen

osallistuva käyttäjärooli

Käyttötapaus sisältää

laajennuskohtia, joihin

toinen käyttötapaus

voidaan sijoittaa

Järjestelmä

Käyttötapaus sisältää

toisen osanaan

Käyttötapaus

Käyttötapaus on

erikoistapaus

toisesta

Käyttötapauskaavio: notaatio

JOTU2013/K.Systä

Pay overdraft fee

Pay invoice

<<extend>>

Accounting System

Perform

interaction Byer

Seller

Vältä käyttötapausten välisiä suhteita

Älä käytä erikoistamista ja laajentamista

ja sisällyttämistäkin vain säästeliäästi. 16.9.2013 JOTU2013/K.Systä 34

16.9.2013 35

Käyttötapausten laatimisesta

• Käyttötapauskaavio tukee käyttötapojen suhteiden kuvaamista, ei niiden sisällön kuvaamista. UML ei määrittele sisällön esitystapaa.

• Käyttötapausten tulee olla ymmärrettävissä sekä asiakkaan että suunnittelijan kannalta.

• Käyttötapauksen abstraktiotason on oltava sopiva (ei esim. yleensä käyttöliittymän yksityiskohtia).

• Kaikkia käyttötilanteita/asiakasvaatimuksia ei voi/kannata antaa käyttötapauksina.

• Käyttötapauksella tulee olla selkeä aloitustilanne ja lopetustilanne. • Käyttötapauksen "suuruudesta" päättäminen voi olla vaikeaa:

– Käyttötapauksen tulisi olla suhteellisen lyhyt (yhden sivun kuvaus). – Käyttötapaus tuottaa käyttäjälle lisäarvoa (ei yleensä yksittäinen

ohjelmiston toiminto, vaan kokonainen tuloksen tuottava ketju toimintoja).

– Käyttötapaus ei siis yleensä ole yksittäinen ohjelmalla suoritettava toiminto (ei siis esimerkiksi: tekstin kopiointi leikkuupöydälle).

JOTU2013/K.Systä

16.9.2013 36

Miksi käyttötapauksia? • Toimii apuna hahmotettaessa järjestelmää (yhteinen näkemys

järjestelmästä)

• Liittää asiakasvaatimukset järjestelmän toimintoihin

• Mahdollistaa vaatimusten täsmentämisen

• Rajaa järjestelmän ympäristöstään

• Auttaa tunnistamaan kuka tai mikä käyttää järjestelmää

• Määrittää järjestelmän korkean tason toiminnallisuuden

• Auttaa jakamaan toiminnallisuuden osajärjestelmiin.

• Määrittää järjestelmän perustermit.

• Apuna olioiden (keskeisten käsitteiden) tunnistamisessa.

• Voidaan käyttää ohjelmistokehityksen organisointiin (iteraatioiden suunnittelu)

• Testauksen suunnittelu

• Käyttöohjeiden laatiminen

JOTU2013/K.Systä

16.9.2013 37

KT:a käytetään usein liittämään asiakasvaatimukset järjestelmä/ohjelmistovaatimuksiin (~kuva 8.8)

tekstin kopiointi

tekstin siirtäminen

maalaa

kopioi

leikkaa

siirrä

kohdistin

liitä

...

...

...

...

KT kopioi teksti

maalaa

kopioi

siirrä

kohdistin

liitä KT siirrä teksti

maalaa

leikkaa

siirrä

kohdistin

liitä

Asiakasvaatimukset Ohjelmistovaatimukset

...

...

...

... JOTU2013/K.Systä

16.9.2013 38 JOTU2013/K.Systä

Käyttäjätarina (user story)

• Ketterissä menetelmissä yleisesti käytetty termi. • Muutamaan lauseeseen typistetty "käyttötapaus" • Tarinasta selviää:

– rooli (aktori) – mitä tehdään – ja mahdollisesti mitä lisäarvoa tekeminen tuottaa

käyttäjälle (usein tämä on kuitenkin ilmeistä)

• Esimerkiksi: Kurssin vastuuhenkilönä pystyn tekemään kaikki yhden kurssin luentosalivaraukset yhdellä varausoperaatiolla (silloin kun luentoajat ovat koko kurssin ajan samoina viikonpäivinä samaan kellonaikaan).

16.9.2013 JOTU2013/K.Systä 39

Vaatimukset ja Scrum

16.9.2013 JOTU2013/K.Systä 40

Scrum

16.9.2013 JOTU2013/K.Systä 41

Tiivistetysti

• Jonkinlainen alustava vaatimusmäärittely ennen tarvitaan ennen töihin ryhtymistä

• Product backlog on (muuttuva) vaatimusmäärittely)

16.9.2013 JOTU2013/K.Systä 42