Vaatimusmäärittelyistä

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 JOTU2013/K.Systä 3

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 16.9.2013 JOTU2013/K.Systä 4

Viime kerrasta Vesiputousmalli Määrittely Suunnittelu Toteutus Testaus 16.9.2013 JOTU2013/K.Systä 5

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. 6 16.9.2013 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 JOTU2013/K.Systä 7

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) Far from agreement Anarchy Complicated Complex Close to agreement Simple Complicated Close to certainty Far from certainty 16.9.2013 JOTU2013/K.Systä 9

Asiakasvaatimuksista tuotteeseen asiakasvaatimukset Määrittely Suunnittelu& toteutus ohjelmistovaatimukset 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ä. Asiakasvaatimukset Ohjelmistovaatimukset 16.9.2013 JOTU2013/K.Systä 11

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

Rajoitteiden rooli Rajoite 1 Rajoite 2 Kaikki mahdolliset ratkaisut 16.9.2013

Vaatimusmäärittely työvaiheena 16.9.2013 JOTU2013/K.Systä 14

Määrittelyvaihe (kuva 3.8) Ideat, lähtökohdat, rajoitteet, reunaehdot Ongelman ymmärtäminen, vaatimusten kartoitus Määrittelyprosessi Toteutettavan järjestelmän spesifiointi Asiakasvaatimukset korjattavaa Ohjelmistovaatimukset Toiminnallinen määrittely, alustava käyttöohje, toteutusprojektin projektisuunnitelma, testaussuunnitelma Tarkastus Asiakasvaatimukset muuntuvat ohjelmistovaatimuksiksi 16.9.2013 OK Arkkitehtuurisuunnittelu

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 16.9.2013 JOTU2013/K.Systä 16

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 16.9.2013 JOTU2013/K.Systä 17

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

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

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

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

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

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

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

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 16.9.2013 JOTU2013/K.Systä 26

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ä?). 16.9.2013 JOTU2013/K.Systä 27

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 16.9.2013 JOTU2013/K.Systä 28

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 16.9.2013 JOTU2013/K.Systä 29

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ä 16.9.2013 JOTU2013/K.Systä 30

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 16.9.2013 kestää 5 sekuntia. 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

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 16.9.2013 JOTU2013/K.Systä 33

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 16.9.2013 JOTU2013/K.Systä ja sisällyttämistäkin vain säästeliäästi. 34

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). 16.9.2013 JOTU2013/K.Systä 35

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 16.9.2013 JOTU2013/K.Systä 36

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ä............ 16.9.2013 JOTU2013/K.Systä 37............

16.9.2013 JOTU2013/K.Systä 38

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