Vaatimusmäärittelyistä

Vaatimusmäärittelyistä JOTU 15.09.2014 15.9.2014 JOTU2014/K.Systä 1

Tiedotuksia Jos tulee tarve muutella IDLE:ssä harjoitustyön assistenttitapaamista, ottakaa yhteyttä assistenttiin. Jos olette ryhmässä, Lukekaa sähköpostianne Jos ette ole yhteydessä ryhmäänne eikä assistentti saa teitä kiinni, pois potkiminen ryhmästä ja kurssilta tapahtuu nopeasti. 15.9.2014 JOTU2014/K.Systä 2

OHJELMISTO ON ABSTRAKTI 15.9.2014 JOTU2014/K.Systä 3

Kilpailu 15.9.2014 JOTU2014/K.Systä 4

Oppimistavoiteet Mitä on vaatimusmäärittely? Mitkä ovat keskeiset termit? Miten sitä tehdään? 8.9.2014 JOTU/K.Systä 5

Tässä kuvassa on koko kurssin sisältö? 15.9.2014 JOTU2014/K.Systä 6

Testaus, laadunvarmistus Viime kerrasta Kehitysprosessit: erilaisia variaatioita samasta teemasta Asiakkaan ongelma asiakasvaatimukset Määrittely ohjelmistovaatimukset, määrittely Suunnittelu tekniset vaatimukset, suunnittelu Toteutus asiakastoimitus Seuraava versio Hyväksymistestaus 15.9.2014 JOTU2014/K.Systä 7

Viime kerrasta Vesiputousmalli Määrittely Suunnittelu Toteutus Testaus 15.9.2014 JOTU2014/K.Systä 8

Viime kerrasta Iteratiiviset, ketterät yms Toimittaja tutkimus tot tot tot tot tarjous määr. test demo test demo test demo test käyt.otto määr. demo demo demo käyt.otto tarjouspyyntö Asiakas tarjous Demo tarkoittaa yhdessä käyttäjän kanssa tehtävää uudelleen pohdintaa. 9 15.9.2014 JOTU2014/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. 15.9.2014 JOTU2014/K.Systä 10

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. 15.9.2014 JOTU2014/K.Systä 11

Kiva löytö: (Ken Schwaber: Agile project managemet) Far from agreement Anarchy Complicated Complex Close to agreement Simple Complicated Close to certainty Far from certainty 15.9.2014 JOTU2014/K.Systä 12

Asiakasvaatimuksista tuotteeseen asiakasvaatimukset Määrittely Suunnittelu& toteutus ohjelmistovaatimukset 15.9.2014 JOTU2014/K.Systä 13

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ä. Asiakasvaatimukset Ohjelmistovaatimukset 15.9.2014 JOTU2014/K.Systä 14

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ä. 15.9.2014 JOTU2014/K.Systä 15

Rajoitteiden rooli Rajoite 1 Rajoite 2 Kaikki mahdolliset ratkaisut 15.9.2014

Vaatimusmäärittely työvaiheena 15.9.2014 JOTU2014/K.Systä 20

Vaatimusmäärittely vs - hallinta -Kartoittaminen -Analysointi -Dokumentointi -Validointi -sidosryhmien tarpeet (asiakkaat, käyttäjät, markkinointi, johto...) -olemassa olevat järjestelmät -sovellusalueen erityispiirteet -asiakasorganisaation käytännöt -viranomaismääräykset -... Vaatimukset seuraaviin tuoteversioihin Hyväksytyt vaatimukset hyväksytyt muutokset Vaatimusmäärittely Vaatimustenhallinta vaatimusmuutokset Vaatimusten muutosprosessi muutokset projektissa 15.9.2014 JOTU2014/K.Systä 21

Vaatimusmäärittely ja hallinta ketterässä vaatimusmuutokset -Kartoittaminen -Analysointi -Dokumentointi -Validointi Hyväksytyt vaatimukset Vaatimusten muutosprosessi hyväksytyt muutokset Vaatimukset seuraaviin tuoteversioihin Vaatimusmäärittely Vaatimustenhallinta muutokset projektissa 15.9.2014 JOTU2014/K.Systä 22

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) JOTU2014/K.Systä 23

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) JOTU2014/K.Systä 24

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 JOTU2014/K.Systä 25

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) (?) JOTU2014/K.Systä 26

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. JOTU2014/K.Systä 27

Tämän viikon sattumus Ariane 5 kantoraketin onnettomuus 15.9.2014 JOTU2014/K.Systä 28

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 15.9.2014 JOTU2014/K.Systä 29

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 15.9.2014 JOTU2014/K.Systä 30

UML-kaaviot Käyttötapauskaavio Use Use case case diagram Luokkakaavio Class/Package/Object diagrams Tap.sekv.kaavio Sequence diagram Yhteistyökaavio Collaboration diagram Driver driver Handle tree Cut log Tree pine: Tree 1..* Log :Tree pine:tree :Log Driver Cut <<create>> calcullate Feed setmeasures 1. Cut 2. Feed pine:tree :Log 2.1. setmeasures 1.2. calculate 1.1. <<create>> Aktiviteettikaavio Activity diagram Tilakaavio State machine diagram (State chart) Komponenttikaavio Component diagram Sijoittelukaavio Deployment diagram H Catch hold of tree Fall the tree H Cut / ^Start chain Saw idle CutOK / ^StopChain H.U.I. Production Production <<Laptop>> H.U.I. <<CAN>> H.U.I. Production Feed&saw Select tree variety H H Saw operational Production Tree Log <<processor>> Main Unit 15.9.2014 JOTU2014/K.Systä 31

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ä?). 15.9.2014 JOTU2014/K.Systä 32

Käyttötapauskaavio, versio 1 Dipparekisteri Lisää uusi opiskelija Lisää uusi kenttä Ohjaaja Etsi ehdot täyttävät opiskelijat tee palaverimuisti o kirjoita lausunto Pohja järjestelmän hahmottamiselle ja siitä keskustelemiselle 15.9.2014 JOTU2014/K.Systä 33

Käyttötapauskaavio, versio 2 Dipparekisteri Lisää uusi opiskelija Lisää uusi kenttä Ohjaaja Etsi ehdot täyttävät opiskelijat tee palaverimuistio lisää/poista ohjaaja kirjoita lausunto Laitoksen johtaja tarkastele tilastoja 15.9.2014 JOTU2014/K.Systä 34

Toinen esimerkki KT-kaaviosta (kuva Salinvarausjärjestelmä 8.6) Varausten poistaminen Vastuu - henkilö Luentosalin varaaminen <<include>> <<include>> Perustietojen ylläpito ylläpitäjä <<include>> assistentti Harjoitussalin varaaminen <<include>> Käyttäjän identifiointi Salivuokran laskutus <<actor>> vuokrajärjestelmä 15.9.2014 JOTU2014/K.Systä 35

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 15.9.2014 kestää 5 sekuntia. JOTU2014/K.Systä 36

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 15.9.2014 JOTU2014/K.Systä 37

Käyttötapauskaavio: notaatio Aktori: käyttötapaukseen osallistuva käyttäjärooli Järjestelmä Käyttötapaus Käyttötapaus sisältää laajennuskohtia, joihin toinen käyttötapaus voidaan sijoittaa <<extend>> Käyttötapaus Käyttötapaus Aktori Käyttötapaus sisältää toisen osanaan <<include>> Käyttötapaus Käyttötapaus on erikoistapaus toisesta 15.9.2014 JOTU2014/K.Systä 38

Vältä käyttötapausten välisiä suhteita Accounting System Pay invoice Byer <<extend>> Pay overdraft fee Perform interaction Seller Älä käytä erikoistamista ja laajentamista 15.9.2014 JOTU2014/K.Systä ja sisällyttämistäkin vain säästeliäästi. 39

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). 15.9.2014 JOTU2014/K.Systä 40

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 15.9.2014 JOTU2014/K.Systä 41

KT:a käytetään usein liittämään asiakasvaatimukset järjestelmä/ohjelmistovaatimuksiin (~kuva 8.8) Asiakasvaatimukset Ohjelmistovaatimukset tekstin kopiointi tekstin siirtäminen KT kopioi teksti KT siirrä teksti maalaa kopioi leikkaa siirrä kohdistin liitä............ 15.9.2014 JOTU2014/K.Systä 42............

15.9.2014 JOTU2014/K.Systä 43

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). 15.9.2014 JOTU2014/K.Systä 44

Vaatimukset ja Scrum 15.9.2014 JOTU2014/K.Systä 45

Scrum 15.9.2014 JOTU2014/K.Systä 46

Tiivistetysti Jonkinlainen alustava vaatimusmäärittely ennen tarvitaan ennen töihin ryhtymistä Product backlog on (muuttuva) vaatimusmäärittely) 15.9.2014 JOTU2014/K.Systä 47

Oppimistavoiteet Mitä on vaatimusmäärittely? Mitkä ovat keskeiset termit? Miten sitä tehdään? 8.9.2014 JOTU/K.Systä 48

Luento-aikatauluista 15.9.2014 JOTU2014/K.Systä 49

Alustava luentoaikataulu 25.8: Johdanto + historiaa, mitä on ohjelmistotuotanto 1.9: Ohjelmistojen roolista ja tyypeistä ohjelmistotyön merkitys 8.9: Miten ohjelmistotyö organisoidaan (vaihejako ja prosessi-mallit) 15.9: Vaatimusmäärittelyt 22.9: Tiedon mallintaminen 29.9: Käyttäjä ja käyttäjäkokemus ohjelmisto-projektissa (Jarmo Palviainen) 6.10: Esimerkkiprojekti (M-files on alustavasti lupautunut) 20.10: Yleiset notaatiot erityisesti UML 27.10: Projektitoiminta 3.11: Asiakasroolista 10.11: Ohjelmisto osana laitetta 1 17.11: : IPR, sopimukset, open source 25.11: 1.12: Kertausta 8.9.2014 JOTU/K.Systä 50