Vaatimusmäärittelyistä

Transkriptio

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

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

3 OHJELMISTO ON ABSTRAKTI JOTU2014/K.Systä 3

4 Kilpailu JOTU2014/K.Systä 4

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

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

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

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

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

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

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

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

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

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

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

16 Rajoitteiden rooli Rajoite 1 Rajoite 2 Kaikki mahdolliset ratkaisut

17

18

19

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

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

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

23 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

24 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

25 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

26 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

27 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

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

29 Ariane 5 analyysi (koko analyysi: 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 JOTU2014/K.Systä 29

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

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

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

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

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

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

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

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

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

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

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

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

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

43 JOTU2014/K.Systä 43

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

45 Vaatimukset ja Scrum JOTU2014/K.Systä 45

46 Scrum JOTU2014/K.Systä 46

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

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

49 Luento-aikatauluista JOTU2014/K.Systä 49

50 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 : : IPR, sopimukset, open source 25.11: 1.12: Kertausta JOTU/K.Systä 50