1. Johdanto Bray luvut 1-2 mistä vaatimusmäärittelyssä on kyse? miksi sitä tarvitaan? milloin sitä tarvitaan? aihepiirin keskeiset käsitteet kirjan esimerkkitapaukset kevät 2008 REQ, Juha Taina 1 Kurssin otsikko engineering: insinööritaito, tekniikka (myös: koneoppi, konepajateollisuus) requirement: täsmällisyys, vaatimus, edellytys, tarve systemaattisuus, hallitut työtavat requirements engineering: ja menetelmät vaatimusten muodostaminen epämääräistä! vaatimusten käsittely vaatimusmäärittely huom: ei tarkoita samaa kuin termi requirement specification kevät 2008 REQ, Juha Taina 2 monta sidosryhmää eri näkökulmia Mistä on kysymys? monenlaisia tarpeita ristiriitoja? epätäsmällinen lähtökohta mutta tuloksen pitäisi olla riittävän täsmällinen, että se sopii suunnittelun ja toteutuksen pohjaksi kevät 2008 REQ, Juha Taina 3 Mistä on kysymys? vaatimusmäärittely: mitä? mitä järjestelmä tekee mitkä ovat sen tehtävät vrt. suunnittelu (design): miten? miten järjestelmä tekee tehtävänsä myös: ohjelmiston tekeminen on ongelmanratkaisua mikä on ongelma, joka halutaan ratkaista? miten päästään huonosti määritellystä ongelmasta riittävän täsmälliseen (= ratkaistavissa olevaan)? kevät 2008 REQ, Juha Taina 4 Miksi tarvitaan? väärät tai puuttuvat vaatimukset ovat projektien epäonnistumisen yleisin syy miksi? lähtökohta luonnostaan epätäsmällinen tavoite: asiakkaan ja ohjelmiston kehittäjien yhteistyö ja vuorovaikutus mutta: erilaiset näkökulmat tietääkö asiakas mitä haluaa? ymmärtääkö kehittäjä mitä halutaan? kevät 2008 REQ, Juha Taina 5 Miksi tarvitaan? onko vaatimusten määrittelyn tavoite edes saavutettavissa? eri asiakasryhmien odotukset voivat olla jo lähtiessä keskenään ristiriitaisia vaatimukset muuttuvat elinkaaren aikana mistä tiedetään, onko syntyvä tuote kelvollinen? ei ehkä tiedetäkään, ellei vaatimuksia ole esitetty täsmällisesti! kevät 2008 REQ, Juha Taina 6 1
Miksi tarvitaan? halutaan täsmällinen kuvaus, mutta kaikki vaatimukset eivät sovi kuvattaviksi samoilla esitystavoilla: toiminnallisuus vs. laadulliset tarpeet perinteinen kuvaustapa: vapaata tekstiä täsmällisemmät kuvaukset edellyttävät formalismia ymmärtääkö asiakas niitä? vaatimukset muuttuvat: ylläpito? (sopivimman) esitystavan valinta kevät 2008 REQ, Juha Taina 7 Milloin tarvitaan / ei tarvita? vaatimusmäärittelyä ei tarvita, jos tehtävä on pieni ja yksinkertainen samanlainen sovellus on tehty ennenkin (tai jos virheillä ei ole niin väliä!) selvitä: mitkä ovat vaatimuksiin liittyvät riskit? mitkä ovat vaatimusriskin toteutumisesta aiheutuvat kustannukset? välttämätöntä ainakin jos projekti on suuri tai keskikokoinen kevät 2008 REQ, Juha Taina 8 Keskeisiä käsitteitä tehtäväalue (problem domain) ratkaisu(järjestelmä) (solution system) ohjelmistokehityksen päävaiheet: tehtäväalueen analysointi tehtäväalueen ja ratkaisun vuorovaikutus ratkaisun muodostaminen rajapinta vaatimusmäärittely tehtäväalue ratkaisujärjestelmä suunnittelu ja toteutus kevät 2008 REQ, Juha Taina 9 Tehtäväalueiden tyyppejä työväline (workpiece) toiminnan kohde on ratkaisun osa esim. tekstinkäsittely ohjausjärjestelmä (control system) toiminnan kohde on tehtäväalueen osa esim. teollisuusprosessin ohjaus tietojärjestelmä (information system) tehtäväalueen tiedon käsittely muunnosjärjestelmä (transformation system) esitystavan muunnos kytkentäjärjestelmä (connection system) rajapinta osapuolien välillä Tehtäväalueen tyyppiä voi hyödyntää vaatimusten määrittelyssä. kevät 2008 REQ, Juha Taina 10 Lisää käsitteitä sidosryhmä (stakeholder) henkilöt tai ryhmät joihin tuote vaikuttaa esim. asiakkaat, käyttäjät, kehittäjät, ylläpitäjät vaatimuksiin liittyvät dokumentit kirjava käsitteistö: tarkista ennen käyttöä! vaatimusmäärittelyn eri vaiheissa voi syntyä useita erillisiä dokumentteja: tarkemmin vaihejaon yhteydessä kevät 2008 REQ, Juha Taina 11 Vaatimusten luokittelua perinteinen luokittelu: toiminnalliset (functional) vaatimukset mitä järjestelmän pitää tehdä ei-toiminnalliset (non-functional) vaatimukset myös: laatuvaatimukset miten järjestelmän pitää toimia suorituskyky, käytettävyys, luotettavuus, miten järjestelmä pitää toteuttaa ylläpidettävyys, siirrettävyys, kevät 2008 REQ, Juha Taina 12 2
Vaatimusten luokittelua Bray: toiminnalliset (functional) vaatimukset mitä järjestelmän pitää tehdä (kuten edellä) suoriutumisvaatimukset (performance) miten järjestelmän pitää toimia: suorituskyky, käytettävyys, luotettavuus, liittyvät yleensä (yhteen tai useampaan, jopa kaikkeen) toiminnallisuuteen rajoitteet (constraints) suunnittelua koskevat rajoitteet liiketoiminnalliset rajoitteet kevät 2008 REQ, Juha Taina 13 Vaatimusten luokittelua välttämättömät vaatimukset edellytyksenä tuotteen hyväksyttävyydelle voivat kuulua mihin tahansa em. luokista valinnaiset vaatimukset toteuttaminen riippuu esim. aikataulusta, kustannuksista jne. edellyttävät priorisointia ratkaistava missä versiossa toteutetaan (jos ollenkaan) luokittelu tärkeyden mukaan kevät 2008 REQ, Juha Taina 14 Vaatimusten luokittelua käyttäjävaatimukset: korkean tason vaatimukset käyttäjän ymmärtämässä muodossa järjestelmävaatimukset: matalan tason vaatimukset täsmällisessä (formaalissa) muodossa vaatimuksen työstämisen työvaiheita kevät 2008 REQ, Juha Taina 15 Vaatimusten luokittelua eksplisiittiset vaatimukset ne vaatimukset jotka kirjataan dokumentteihin vain näistä on sovittu implisiittiset vaatimukset käyttäjän julkilausumattomat odotukset mutta nämäkin voivat olla hyväksyttävyyden kannalta välttämättömiä kevät 2008 REQ, Juha Taina 16 Tekniikoista alalla käytössä lukuisia eri tekniikoita jotkut sopivat vain tiettyyn vaiheeseen osa soveltuu useaan vaiheeseen erityisesti: mallittaminen olennainen osa ohjelmistotyötä tavoitteena ymmärryksen parantaminen käsittely ko. vaiheen yhteydessä yhtenä kokonaisuutena pelkistämällä = karsimalla epäolennaisuuksia mikä on epäolennaista? esitystavat (notation) taulu 8.1 (seuraava kalvo) kevät 2008 REQ, Juha Taina 17 Kuvalla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 18 3
Kirjan esimerkkitapaukset purjehduskilpailun tuloslaskenta perinteinen tietojärjestelmä hissin ohjaus sulautettu tosiaikajärjestelmä tiedostoformaatin muunnos työkaluohjelman käyttämän esitysmuodon konversio Petri-verkkojen käsittely CASE-työkalu Esimerkkijärjestelmien vaatimusmäärittelyn päävaiheet on esitelty oppikirjan luvuissa 15-18. kevät 2008 REQ, Juha Taina 19 2. Vaatimusmäärittelyn vaiheet Bray luku 2 tavoite: epämääräisistä tarpeista täsmälliseksi vaatimusten kuvaukseksi mistä epämääräiset tarpeet saadaan? miten niitä karsitaan ja muokataan? miten niistä tehdään täsmällisiä? miten varmistutaan, että kaikki tarvittava on mukana? kevät 2008 REQ, Juha Taina 20 Vaiheet päävaiheet: vaatimusten kartutus vaatimusten analysointi ja sovittelu vaatimusten spesifiointi vaatimusten validointi ei yleensä lineaarisesti vaan iteroiden! muita tehtäviä: vaatimusten hallinta jäljittäminen sateenvarjotoimintoja kevät 2008 REQ, Juha Taina 21 Kartutus elicitation muita suomennosehdotuksia: esiinkaivelu, keräily, etsiskely, pyydystäminen, keskeisiä kysymyksiä: mitä tietoa tarvitaan? keneltä/mistä sitä voitaisiin saada? millä keinoin sitä voidaan saada? tulos (elicitation notes): läjä muistiinpanoja, nauhoitteita, kevät 2008 REQ, Juha Taina 22 Analysointi problem domain analysis tavoite: tehtäväalueen ja ongelman olennaisten piirteiden ymmärtäminen vaatii yleensä iterointia kartutuksen kanssa: havaitaan lisätiedon tarve kartutusta osana myös eri näkemysten sovittelu tulos (requirements document): tehtäväalueen kuvaus kevät 2008 REQ, Juha Taina 23 specification Spesifiointi ulkoisen käyttäytymisen suunnittelu (external design) huom. tämäkään vaihe ei ota kantaa siihen miten se tehdään vrt. suunnitteluvaiheessa tehtävä idesign toteutuksen suunnittelu (internal design) tulos: ratkaisujärjestelmän halutun käyttäytymisen täsmällinen kuvaus kevät 2008 REQ, Juha Taina 24 Bray: edesign 4
Validointi Yhteys ohjelmistoprosessiin validation varmistettava että tehtäväalue on ymmärretty oikein vaatimukset on kirjattu oikein jos toteutettu järjestelmä toimii kuten on spesifioitu, niin se täyttää vaatimukset keinoja: vaatimusten katselmointi, prototyypit, vrt. validointi myöhemmin projektissa esimerkkejä: vaatimusmäärittely Vesiputousmalli vaatimusten jäljittäminen eritasoiset vaatimukset validointi vaatimuksia vasten V-malli kevät 2008 REQ, Juha Taina 25 kevät 2008 REQ, Juha Taina 26 Käyttöliittymän suunnittelu Bray: käyttöliittymän suunnittelu on osa vaatimusmäärittelyä osa spesifiointia tai oma erillinen vaiheensa (käyttöliittymän yksityiskohtainen suunnittelu) useimmiten katsotaan kuuluvaksi (toteutuksen) suunnitteluvaiheeseen esitetäänkö käyttöliittymälle vaatimuksia? käyttöliittymä vs. (muut) vaatimukset? Vaatimusmäärittelyprosessi Bray: kuva 2.1 (kalvo 31) vaiheet tietovarastot tiedon siirtyminen vaiheesta toiseen vaiheiden aikajärjestys kevät 2008 REQ, Juha Taina 27 huom. ajoitus! kevät 2008 REQ, Juha Taina 28 Dokumentit Bray erottaa toisistaan kartutusmuistiinpanot (elicitation notes) analyysidokumentti (requirements document, analysis document) spesifikaatiodokumentti (specification) käyttöliittymädokumentti (HMI design document) nähdään usein jatkumona: vaatimuksia kartutetaan ja täsmennetään vähitellen Spesifikaatiodokumentti vaatimusmäärittelyvaiheen keskeinen lopputulos sopimus asiakkaan ja kehittäjän välillä tämän perusteella vastuu siirtyy asiakkaalta kehittäjälle dokumentti joka toimii suunnittelun lähtökohtana testauksen ym. validoinnin viitepohjana kevät 2008 REQ, Juha Taina 29 kevät 2008 REQ, Juha Taina 30 5
Vaatimuksia vaatimuksille Kuvalla (C) Ian Bray, 2002 virheettömyys yksiselitteisyys kattavuus ristiriidattomuus todennettavuus muokattavuus jäljitettävyys juuri tätäkö asiakas halusi? malli vs. luonnollinen kieli tässäkö kaikki mitä asiakas halusi? vaatimukset suhteessa toisiinsa onko validointi edes mahdollista? käyttö versiosta toiseen eteneminen projektin aikana kevät 2008 REQ, Juha Taina 31 kevät 2008 REQ, Juha Taina 32 Vaatimusmäärittely vs. suunnittelu (design) terminologiaongelmia: vaatimusmäärittely käyttäytymisen suunnittelu vs. toteutuksen suunnittelu tehtäväalueen jäsentäminen vs. suunnittelu ratkaisun jäsentäminen (design) molempien kuvaamiseen sopivat (usein/osittain) samat tekniikat suomessa vielä lisäksi: työskentelyn suunnittelu (planning) vs. toteutuksen suunnittelu (design) kevät 2008 REQ, Juha Taina 33 Vaatimusmäärittely vs. suunnittelu (design) mitä tietoa näissä käsitellään: tehtäväaluetta kuvaava tieto vs. (vain) ratkaisua koskeva tieto vaatimusmäärittelyn yhteydessä laadittava tietomalli vs. toteutuksen osana laadittava tietomalli tyypillisesti vaatimusmäärittelyssä koottava tieto on osa suunnittelun tietokokoelmaa vaatimusmäärittely suunnittelu (design) kevät 2008 REQ, Juha Taina 34 Vaatimusmäärittely vs. suunnittelu (design) olennainen ero: vaatimusmäärittelyssä kerätään ja jäsennetään olemassa olevaa tietoa: tehtäväalue ja tarpeet ovat todellisia, ne pitää vain löytää ja kuvata suunnitteluvaiheessa luodaan uutta: ainoata oikeata tai edes parasta ratkaisua ei välttämättä (yleensä?) ole olemassa! tämä ei suinkaan merkitse, että vaatimusmäärittely olisi helpompaa! kevät 2008 REQ, Juha Taina 35 3. Vaatimusten kartutus Bray luvut 3, 9 requirements elicitation kartutus ei ole suoraviivaista olemassa olevien vaatimusten poimintaa piilevä tieto (latent) julkilausumaton tieto (tacit) perinteinen kartutusmenetelmä: käytetään tervettä järkeä vrt. asiantuntijajärjestelmien vaatima asiantuntemuksen keruu kevät 2008 REQ, Juha Taina 36 6
Mitä tietoa etsitään? tehtäväaluetta koskevat tiedot tehtäväalueen rajaus tehtäväalueen olennaiset ominaisuudet eri sidosryhmät ja niiden näkemys tehtäväalueesta myös: ratkaisun muodostamiseen liittyvät tiedot miksi? tarpeiden priorisointi milloin? Kartutuksen tavoitteena on koota riittävät tiedot, jotta tehtäväalue ja siihen sisältyvä ongelma voidaan ymmärtää. kevät 2008 REQ, Juha Taina 37 asiakkaat käyttäjät entinen järjestelmä tuleva järjestelmä tehtäväalueen asiantuntijat Tietolähteitä aiemmat vastaavat järjestelmät kilpailevat tuotteet dokumentit standardit lait ja määräykset käytä mieluiten useita lähteitä samoillekin asioille valitse oikeat (= parhaat) lähteet tunnista ja ota mukaan kaikki sidosryhmät kevät 2008 REQ, Juha Taina 38 Kartutusstrategia tavallisesti tarvitaan useita kierroksia aluksi sovelluksen tyyppi kuka/ketkä ovat asiakkaat/sidosryhmät? miksi tätä tehdään (= mikä on ongelma)? haetaan yleiskuvaa tehtäväalueesta ja tarpeesta myöhemmillä kierroksilla keskittyminen osa-alueisiin analyysin perusteella muodostetun kuvan oikeellisuuden tarkistaminen kevät 2008 REQ, Juha Taina 39 Annos (henkilöstö)politiikkaa otettava huomioon asiakasyrityksen henkilösuhteet ja organisaatiokulttuuri osallistuvien henkilöiden omat intressit voivat vääristää saatavaa tietoa minähän sanoin jo etukäteen, että sidosryhmien sisällä voi myös olla aidosti erilaisia näkemyksiä: esim. eri osastoilla, eri tehtävissä mitkä ominaisuudet ovat tärkeitä? tarvitaanko järjestelmää ylipäätään? kartuttaja kerää tietoa, ei ota kantaa! kevät 2008 REQ, Juha Taina 40 Ristiriidat erotettava toisistaan faktat ja mielipiteet karsittava virheet useiden lähteiden käyttö ristiriitaisten tietojen tuominen esille todellinen vai vain kuviteltu ristiriita? todellisten ristiriitojen tilanteessa kuka on ylin auktoriteetti? kompromissit useita rinnakkaisia vaihtoehtoja sisältävä ratkaisu kustannus-hyöty-analyysi kevät 2008 REQ, Juha Taina 41 Vaatimusten muuttuminen (ei liity vain kartutukseen vaan kaikkiin vaatimusmäärittelyn vaiheisiin) tehtäväalue vs. vaatimukset tehtäväalue on yleensä stabiili(mpi) vaatimukset voivat helpommin muuttua lisää vaatimuksia entisten vaatimusten muutoksia muutosten ennakointi? kerättävä myös tätä koskevaa tietoa kevät 2008 REQ, Juha Taina 42 7
Kartutustekniikoita kirjalliseen materiaaliin perustuvat: tehtäväalueeseen tutustuminen lukemalla taustamateriaalia esim. esitteet, toimintasuunnitelmat dokumenttien tutkiminen erit. aiemman järjestelmän dokumentit vaatimusten poiminta (requirements stripping) esim. asiakkaan vaatimuskuvauksista tai muiden järjestelmien vaatimusdokumenteista kevät 2008 REQ, Juha Taina 43 Kartutustekniikoita henkilöihin perustuvat: haastattelut usein paras (tai jopa ainoa) käyttökelpoinen menetelmä suurin potentiaali tiedonvälitykseen (sanat, piirrokset, mahdollisuus tarkentaa) kyselylomakkeet osittain samat tavoitteet kuin haastatteluissa suurempi kohdejoukko joustamattomuus kevät 2008 REQ, Juha Taina 44 Kartutustekniikoita käyttötilanteisiin perustuvat: käyttäjän tarkkailu (task observation) mitä tapahtuu todellisessa tilanteessa etukäteen suunnitellut tehtävät tarkkailun häiritsevä vaikutus? käyttötapausten tai skenaarioiden käyttö kuvitellun käyttötilanteen simulointi käyttäjän kanssa myös: erilaiset prototyypit mutta: perustuvat jo (yhteen) ratkaisumalliin kevät 2008 REQ, Juha Taina 45 Kartutustekniikoita muita tekniikoita: aivoriihet (brainstorming) joukko ihmisiä pystyy yhdessä tuottamaan ideoita, joita ei yksin tulisi ajatelleeksi lumipalloefekti edellytyksenä vapaa, kritiikitön asenne markkinatutkimukset saadaan paljon (tilastollista) tietoa tarpeista kohderyhmän valikointi? tulosten luotettavuus? kevät 2008 REQ, Juha Taina 46 Muita lähestymistapoja JAD = joint application development kartutus ryhmäsessioissa session kesto useita tunteja tai jopa päiviä eri sidosryhmien edustajat mukana RAD = rapid application development ei vain kartutus vaan koko tuotteen nopea valmistus parhaalla mahdollisella tiimillä lähtökohtana JAD-tyyppinen tiedonkeruu myös: ketterät prosessimallit jatkuva vaatimusten kartutus ja analysointi? kevät 2008 REQ, Juha Taina 47 Haastattelun järjestelyt ennakkosuunnitelma mitä tietoa haetaan? kysymyslista haastateltavien valmistelu valitaan oikeat (= asiaa tuntevat) henkilöt tiedotetaan haastattelun tavoitteesta tiedonkeruuvälineet muistiinpanot (itse vai kirjuri?) nauhoitus, videointi kevät 2008 REQ, Juha Taina 48 8
Haastattelun tekniikasta ymmärrettävyys käytä haastateltavan käsitteitä pysy erossa omasta ammattislangistasi! sitkeys älä luovuta, ellet ymmärrä varmasti kysy uudelleen (eri sanoin, myöhemmin) pyydä (ja käytä) esimerkkejä joustavuus ohjaa haastattelua sen mukaan, missä ongelmat tuntuvat olevan säilytä silti tavoite vastaanottavuus älä takerru omaan ennakkokäsitykseesi älä tarjoa vastauksia haastateltavalle kevät 2008 REQ, Juha Taina 49 Haastattelussa kysyttävää lähtökohta: WHAT, WHO, WHEN, WHERE & WHY kaaviokuva tms. havainnollistava esitys visiot, vaihtoehtoiset ideat priorisointi välttämättömät ominaisuudet (= minimi) tarpeelliset mutta ei niin kiireelliset utopiat myös: itse haastattelun toimivuus kevät 2008 REQ, Juha Taina 50 Kartutuksen muistiinpanot elicitation notes läjä muistiinpanoja, nauhoitteita, kokoelman purkaminen tarkennustarpeet? muistiinpanoihin kirjattava myös mistä tieto on peräisin miksi tällainen vaatimus esitetään mitkä asiat liittyvät toisiinsa jäljitettävyys vaatimusten hallinta kevät 2008 REQ, Juha Taina 51 4. Vaatimusten analysointi Bray luku 4 problem domain analysis tehtäväalueen ymmärtäminen sovellusalueen käsitteistö ongelma johon etsitään ratkaisua sidosryhmien tarpeet tehtäväalueen tai sidosryhmien asettamat rajoitteet näiden keskinäiset suhteet kevät 2008 REQ, Juha Taina 52 Analyysi vs. spesifiointi tehtäväalue rakenne: osa-alueet ja niiden suhteet ominaisuudet mitä siellä tapahtuu ongelmat, tarpeet mitä ratkaisulta odotetaan = description of the problem domain + a list of problems to be solved vrt. spesifiointi: kuvataan ratkaisujärjestelmää miten ratkaisujärjestelmä toimii millä tavoin se täyttää asetetut vaatimukset = definition of a behaviour of the solution system that will meet the requirements kevät 2008 REQ, Juha Taina 53 Tehtäväalue vs. ratkaisu rajapinta tehtäväalue ratkaisujärjestelmä keskityttävä tehtäväalueen käsitteisiin käytännössä tämä on usein vaikeaa: sekoitetaan tehtäväalueen ja ratkaisun kuvaaminen olennaisia asioita voi jäädä puuttumaan, jos ne eivät sovi ratkaisun käsitteisiin kevät 2008 REQ, Juha Taina 54 9
Tehtäväalue vs. vaatimukset kartutusvaiheessa kerätään tietoa tehtäväalueesta tarpeista ja ongelmista (joista tulee vaatimuksia) analyysin tehtävä on jäsentää molemmat: rakenne sisältö yhteydet Analyysidokumentti analysis document, requirements document tiedon välittäminen asiakkaalta (sidosryhmiltä) spesifikaation laatijoille ratkaisujärjestelmän suunnittelijoille kaikkien voitava ymmärtää ja hyväksyä yksikäsitteinen, ristiriidaton, kattava selkeä, järjestelmällinen helppo muokata ja todentaa kevät 2008 REQ, Juha Taina 55 kevät 2008 REQ, Juha Taina 56 Analyysidokumentin rakenne tunnistetiedot tehtäväalueen kuvaus kokonaiskuva osa-alueet vaatimukset toiminnalliset vaatimukset suoriutumisvaatimukset rajoitteet tietohakemisto (data dictionary) lähteet kaaviot usein havainnollisimpia tässä vaiheessa voidaan parhaiten esittää tekstinä kevät 2008 REQ, Juha Taina 57 Analyysin lähestymistapoja rakenteinen analyysi (SA) lähtökohtana tehtäväalueen rakenteen jäsentäminen olioanalyysi (OOA) lähtökohtana tehtäväalueella toimivien olioiden (olioluokkien) tunnistaminen tehtäväaluepohjainen analyysi () lähtökohtana tehtäväaluetyypin/-tyyppien tunnistaminen kevät 2008 REQ, Juha Taina 58 Rakenteinen analyysi SA Rakenteinen analyysi SA tehtäväaluetta jäsennetään tutkimalla tiedon kulkua ja muunnoksia sopii parhaiten tietojärjestelmiin mallituksen lähtökohta: aiempi järjestelmä (voi olla myös manuaalinen) tai uuden järjestelmän ja sen ympäristön vuorovaikutus (konteksti) tiedon käsittely = tietoa muokkaavat prosessit: tietovuokaavio (data flow diagram) tiedon sisältö ja rakenne: tietohakemisto (data dictionary) tietojen keskinäiset suhteet ja riippuvuudet: ER-kaavio (entity relationship diagram) kevät 2008 REQ, Juha Taina 59 kevät 2008 REQ, Juha Taina 60 10
Esimerkkijärjestelmä E1 SA purjehduskilpailun tuloslaskenta perustuu kartutuksessa kerättyihin tietoihin nykykäytännöistä (luku 15) tietovuokaavio: kuva 4.1 tietohakemisto relaatiot ER-kaaviona: kuva 4.2 täydennyksiä tietohakemistoon avainkentät kevät 2008 REQ, Juha Taina 61 Kuvilla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 62 Esimerkkijärjestelmä E1 SA lähtökohta voi olla myös korkean tason ratkaisuidean mallitus: konteksti tietovuokaaviona: kuva 4.3 tietohakemisto korkean tason rakenne (esim.): kuva 4.4 tarvittaessa tarkennetaan: esim. kuva 4.5 alin taso kuvataan pseudokoodina huom. tässä on kyse yhden mahdollisen toteutuksen rakenteen mallittamisesta Figure 4.5 Kuvilla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 63 kevät 2008 REQ, Juha Taina 64 Esimerkkijärjestelmä E4 SA Esimerkkijärjestelmä E4 SA Petri-verkkojen piirrostyökalu ei aiempaa järjestelmää mallittamisen lähtökohdaksi kontekstikaavio: kuva 4.14 (kirjassa) käsiteltävät tiedot: ei ole selvää mitä toimintoja tarvitaan tietohakemisto ER-kaavio: kuva 4.15 (kirjassa) kevät 2008 REQ, Juha Taina 65 korkean tason tietovuokaavio: yksi mahdollinen ratkaisu: kuva 4.16 (kirjassa) muita vaihtoehtoja on paljon ongelmia (Bray): kaikki kuvan prosessit eivät kuulu tehtäväalueen käsitteisiin (esim. handle) otettu kantaa siihen, miten eräät halutut toiminnot toteutetaan (esim. undo) ei silti kerrota mitä toiminnoissa tapahtuu kevät 2008 REQ, Juha Taina 66 11
Kritiikkiä (Bray) SA Olioanalyysi OOA ero analyysin ja spesifioinnin välillä? usein lähempänä ratkaisun mallittamista aiemman järjestelmän mallittaminen onko se aina hyvä lähtökohta (hyvä malli?) rajanveto toteutuksen suunnitteluun? jäsentelyn tuloksena saatu rakenne ohjaa helposti myös suunnittelua ratkaisuun kuuluvia käsitteitä saattaa tulla mukaan jo tehtäväalueen kuvaukseen kevät 2008 REQ, Juha Taina 67 tehtäväalueella toimivat olioluokat attribuutit ja metodit käyttäytyminen luokkien väliset suhteet olioanalyysi jatkuu luonnostaan oliosuunnitteluna analyysin olioluokat edelleen käytössä uusia luokkia tarvittaessa erikoistamalla jo määritellyistä kevät 2008 REQ, Juha Taina 68 Olioanalyysi erilaisia olioluokkia: käsitteelliset = tehtäväalueen luokat rajapintaluokat toteutusluokat vaatimusten tunnistamiseksi voidaan käyttää käyttötapauksia: vrt. käyttö kartutuksen yhteydessä sopii erityisesti jos tehtäväalue on jo ennestään tuttu, mutta vaatimukset uusia kevät 2008 REQ, Juha Taina 69 OOA analyysivaiheessa spesifiointivaiheessa suunnitteluvaiheessa Olioanalyysi luokkakaavio tehtäväalueen olioluokkien tunnistaminen näiden ominaisuudet = attribuutit luokkien tarpeet toistensa suhteen = niiden tarvitsemat/tarjoamat palvelut luokan käyttäytyminen tilakaavio järjestelmälle asetettavat vaatimukset käyttötapauskaavio kevät 2008 REQ, Juha Taina 70 OOA Esimerkkijärjestelmä E1 purjehduskilpailun tuloslaskenta luokkaehdokkaat (taulu 4.1) luokka ja sen data näistä valitaan ne jotka tarvitsevat tai tarjoavat palveluja kuva 4.17 operaatiot: tyypilliset operaatiot ovat suoraviivaista attribuuttien käsittelyä mitä luokan oliot oikeastaan tekevät? kevät 2008 REQ, Juha Taina 71 OOA Esimerkkijärjestelmä E1 luokkien väliset relaatiot: (kuva 4.17) vrt. ER-kaavio periytyminen luokan käyttäytyminen: tilakaavio: esim. kuva 4.18 (boat) ongelmia: todellisuus vs. malli: käsittelevätkö oliot oikeasti omaa dataansa? (esim. boat) mikään kaavio ei kuvaa vaatimuksia! käyttötapauskaavio? kevät 2008 REQ, Juha Taina 72 OOA 12
Esimerkkijärjestelmä E1 OOA enter new boat user calculate results Kuvilla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 73 print report Kuvaa järjestelmän kontekstia, ei niinkään vaatimuksia. race officer kevät 2008 REQ, Juha Taina 74... Esimerkkijärjestelmä E2 OOA Esimerkkijärjestelmä E2 OOA hissin ohjausjärjestelmä luokkaehdokkaat: taulu 4.2 luokka user: ei attribuutteja tai operaatioita mutta käyttää muiden luokkien palveluja kysymyksiä: ovatko luokkien attribuutit myös niiden reaalimaailman attribuutteja? (esim. floor) ovatko luokkien operaatiot myös niiden reaalimaailman operaatioita? (esim. button) kevät 2008 REQ, Juha Taina 75 toiminta: tilakaavio: esim. kuva 4.19 (motor) kaavio kuvaa todellisen olion toimintaa esim. hissi voi vaihtaa suuntaa nopeudesta riippumatta tarvitaan vaatimus, että ennen suunnan vaihtoa pitää pysähtyä haluttua tilannetta voisi kuvata esim. kuvalla 4.20 huom. ei ole osa tehtäväaluetta vaan ratkaisua, joten se ei kuulu analyysiin kevät 2008 REQ, Juha Taina 76 Esimerkkijärjestelmä E2 OOA luokkien väliset relaatiot: assosiaatiot: kuva 4.21 palvelujen käyttö: kuva 4.22 oliot eivät juuri käytä toistensa palveluja! miten kuvataan vaatimusten määrittelyn kannalta kiinnostavat tapahtumat? yksi mahdollinen ratkaisu olisi kuva 4.23 mutta: lift-controller = toteutettava ohjelmisto! kevät 2008 REQ, Juha Taina 77 Kuvilla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 78 13
Kritiikkiä (Bray) OOA Kuvilla (C) Ian Bray, 2002 tämä ei ole analyysia! ei yritetäkään tehdä eroa vaatimusten määrittelyn ja (toteutuksen) suunnittelun välillä toimii jos lähtökohtana tehtäväalueen tuntemus vaatimusten kuvaaminen käyttötapauksina korkean tason ratkaisun mallittaminen entä jos tehtäväalue on vieras? kevät 2008 REQ, Juha Taina 79 kevät 2008 REQ, Juha Taina 80 Tehtäväaluepohjainen analyysi pidetään analyysi ja spesifiointi erillään: tuloksena täysin erilliset dokumentit analyysin esitystapoina graafiset mallit sanallinen kuvaus mallitusstrategia: tehtäväkehykset (problem frames) kevät 2008 REQ, Juha Taina 81 Tehtäväkehykset tehtäväalue koostuu osa-alueista mikä tahansa mielekkäästi rajattavissa oleva osa vrt. konteksti (rajapinta ratkaisuun päin) kaikki osa-alueet eivät ole suoraan yhteydessä ratkaisujärjestelmään analyysin lähtökohta: tunnistetaan jako osa-alueisiin analysoidaan kukin osa-alue sen mukaan, millaisesta kehyksestä on kysymys kevät 2008 REQ, Juha Taina 82 Tehtäväaluetyypit työväline (workpiece) ohjaus (control system) sääntöihin perustuva ohjaus tai operaattorin komennot tietojärjestelmä (information system) jatkuva tiedon välitys tai raportointi pyynnöstä muunnos (transformation system) kytkentä (connection system) Kuvaustekniikka kaavioilla voidaan kuvata osa-alueita ratkaisujärjestelmää alueiden välisiä nimettyjä yhteyksiä alueiden välisiä nimettömiä yhteyksiä vaatimusten viittauksia alueisiin vaatimusten rajoitteita alueisiin alueen sisältymistä toiseen esimerkkinä Petri-verkkotyökalua kuvaava kehysrakenne: kuva 4.29 kevät 2008 REQ, Juha Taina 83 kevät 2008 REQ, Juha Taina 84 14
Sanallinen kuvaaminen Tehtäväalueen luokittelu sanamuodon perusteella voidaan erottaa tehtäväaluetta koskevat faktat ja ratkaisuun vaikuttavat tarpeet (vaatimukset) esim. tapaluokat (mood): faktat: on, tekee, lasketaan, tarpeet: pitää olla, täytyy tehdä, joskus käytetään sanamuotoa myös kuvaamaan vaatimuksen voimakkuutta: täytyy olla vs. voi olla kevät 2008 REQ, Juha Taina 85 osa-alueen kehystyypin tunnistaminen alueiden ominaisuuksia: staattisuus vs. dynaamisuus muutoksia aiheuttavat tekijät ennustettavuus konkreettisuus kuva 4.30 näiden perusteella tehtäväalueet voidaan luokitella eri kehystyyppeihin kevät 2008 REQ, Juha Taina 86 Analyysin eteneminen Työkalu tunnistetaan tehtäväalueen (osaalueiden) kehystyyppi/-tyypit kuvataan tehtäväalueen kehysrakenne: osa-alueiden ominaisuudet alueiden väliset relaatiot ja viittaukset analyysidokumenttiin sisältyy erilaisia osia riippuen kehystyypistä tehtäväalueen kuvaukseen kuuluvia osia vaatimuksia kevät 2008 REQ, Juha Taina 87 kehysrakenne: kuva 4.31 työkalu on osa ratkaisua epäkonkreettinen työkalun tila muuttuu ainoastaan käyttäjän toiminnan seurauksena esim. piirrostyökalut, tekstinkäsittelyjärjestelmät, taulukkolaskentaohjelmat käyttäjän pyynnöt spontaaneja eivät ole (täysin) ennustettavissa taulu 4.5 tehtäväalue: ulospäin näkyvä tiedon rakenne vaatimukset: miten käyttäjän pyyntöihin pitää reagoida kevät 2008 REQ, Juha Taina 88 Ohjaus Kuvilla (C) Ian Bray, 2002 ohjaus voi perustua sääntöihin: kuva 4.32 käyttäjän käskyihin: kuva 4.33 ohjauksen kohde ei ainakaan täysin autonominen usein konkreettinen esim. hissi, palohälytin, teollisuusprosessin ohjaus käyttäjän käskyt ei ennustettavissa taulu 4.6 tehtäväalue: tietomalli ohjattavan järjest. käyttäytyminen vaatimukset: mitä komentoja voidaan antaa miten järjestelmän pitää reagoida niihin kevät 2008 REQ, Juha Taina 89 kevät 2008 REQ, Juha Taina 90 15
Tietojärjestelmä Kuvilla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 91 raportointi voi olla jatkuva: kuva 4.34 pyynnöstä: kuva 4.35 raportoitava todellisuus (real world) järjestelmä sisältää tietoa (tietomallin) kuva 4.36 päivitystietoja raportointipyyntöjä todellisuus autonominen kuvataan järjestelmässä usein mallina kuva 4.37 taulu 4.7 tehtäväalue: tietomalli, tapahtumat, tilat vaatimukset: mitä raportteja ym. pitää tuottaa esim. opiskelijarekisteri, lennonohjaus kevät 2008 REQ, Juha Taina 92 Kuvilla (C) Ian Bray, 2002 Kuvalla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 93 kevät 2008 REQ, Juha Taina 94 Muunnos Kytkentä kuva 4.38 syötetieto staattista ei yleensä konkreettista joskus konkreettinen lähtökohta, josta muokataan syöte esim. skanneri, kassapääte, työkalujen välinen esitystapamuunnos tulostieto ei muutu itsekseen vaan järjestelmän toiminnan tuloksena taulu 4.8 tehtäväalue: syötteiden rakenne tulosteiden rakenne vaatimukset: kuvaus syötteistä tulosteiksi kevät 2008 REQ, Juha Taina 95 kytkentä alueiden välillä, jotka eivät suoraan ymmärrä toisiaan välittäjänä voi olla laadittava ohjelma itse: kuva 4.39 laite: kuva 4.40 tehtäväalue konkreettinen laite konkreettinen itsenäinen tehtäväalueen ja laitteen tietojen yhteensopivuus taulu 4.9 tehtäväalue: tilat, tapahtumat vaatimukset: itsenäinen kuvaus alueiden esim. käyttöliittymä, välillä potilaan tarkkailu kevät 2008 REQ, Juha Taina 96 16
Kuvilla (C) Ian Bray, 2002 Monta kehystä kaikki tehtäväalueet eivät ole kuvattavissa yhdellä kehyksellä erotetaan osa-alueet käsitellään kutakin osa-aluetta tyyppinsä mukaan päällekkäisten osien käsittely? molemmat yhdessä vai kumpikin erikseen? esimerkkejä kuvissa 4.41-4.44 kevät 2008 REQ, Juha Taina 97 kevät 2008 REQ, Juha Taina 98 Kuvilla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 99 Esimerkkijärjestelmä E1 purjehduskilpailun tulokset tietojärjestelmä raportteja tuotetaan pyydettäessä vrt. kuva 4.35: pyynnöt = raporttipyyntöjä raportit = kilpailutulokset jne. tietomalli ER-kaavio: kuva 4.45 (kirjassa) tietohakemisto osa-alueiden kuvaus esimerkki (teksti) entity life history: kuva 4.46 (kirjassa) tiedon syöttö käyttäjältä vaatimukset esimerkkejä (teksti) kevät 2008 REQ, Juha Taina 100 Esimerkkijärjestelmä E2 Esimerkkijärjestelmä E2 hissin ohjaus kontekstikaavio: kuva 4.47 (kirjassa) ei sisällä kaikkia osaalueita (esim. itse hissi puuttuu) kehysrakenne kuva 4.48 (kirjassa) huom. osa-alueiden väliset yhteydet käyttäjien toiminta osittain ennustett. muut osa-alueet laitteisto on tiedossa joten toiminta täysin ennustettavissa jos suunniteltavana olisi myös laitteisto, tehtäväalue olisi hyvin erilainen: ihmiset, rakennus, tietomalli kuva 16.4 (kirjassa) osa-alueiden kuvaus mitä tietoa tarvitaan suunnitteluvaiheessa eri kuvaustapoja esim. moottorin toiminta: päätöstaulut 4.14 ja 4.15 (kirjassa) sanalliset kuvaukset havaittavissa olevat tapahtumat tai toiminnot taulut 4.16 ja 4.17 (kirjassa) viiveet yms. esimerkki (teksti) vaatimukset esimerkkejä (teksti) kevät 2008 REQ, Juha Taina 101 kevät 2008 REQ, Juha Taina 102 17
Esimerkkijärjestelmä E3 Esimerkkijärjestelmä E4 työkaluohjelman esitystapamuunnos kehysrakenne kuva 4.49 (kirjassa) syötteiden ja tulosteiden kuvaus syntaksiesitys rakennekaavioina tai BNF esimerkki (BNF) syötteen alkuperä, tuloksen päämäärä esimerkki (teksti) vaatimukset kuvaussäännöt: taulu 4.19 (kirjassa) lisäksi voi olla tarpeen esittää esim. suoriutumisvaatimuksia (teksti) sekä työkaluun että ohjaukseen liittyviä piirteitä kuva 4.50 (kirjassa) työkalu: lähtökohtana ulos näkyvä (tiedon) rakenne ohjaus: lähtökohtana järj. käyttäytyminen tiedon rakenne ER-kaavio: kuva 4.51 (kirjassa) tietohakemisto vaatimukset: operaatiot ja niiden vaikutus esimerkki (teksti) huom. kuvaus on tässä vaiheessa vielä varsin abstrakti kevät 2008 REQ, Juha Taina 103 kevät 2008 REQ, Juha Taina 104 Arviointia tämä lähestymistapa ei ole vielä vakiintunut idea on houkutteleva: samantyyppiset kehykset tarvitaan samantyyppistä tietoa tehtäväalueesta vaatimusmäärittelyn osaamisen uudelleenkäyttöä vrt. suunnittelumallit löytyykö lisää kehystyyppejä? Vaatimusten sovittelu requirements negotiation sidosryhmien tarpeiden yhteensovitus sisältää: ristiriitaisten vaatimusten käsittelyä priorisointia mihin vaiheeseen sovittelu kuuluu? kartutusta vai analyysia vaatimuksia ei voida sovitella, ennen kuin ne on ymmärretty riittävän hyvin kevät 2008 REQ, Juha Taina 105 kevät 2008 REQ, Juha Taina 106 5. Vaatimusten spesifiointi Spesifiointivaiheen tehtävät Bray luku 5 rajapinta requirements specification tehtäväalue ratkaisujärjestelmä ratkaisun ja tehtäväalueen rajapinta miten ratkaisun pitää toimia, jotta se täyttäisi asetetut vaatimukset ulkoisen toiminnallisuuden suunnittelu (external design) kohteena toiminnalliset vaatimukset suoriutumisvaatimukset em. suunnitelman kuvaaminen (=dokumentointi) täsmällisessä muodossa (specification) lopputuloksena spesifiointidokumentti kevät 2008 REQ, Juha Taina 107 kevät 2008 REQ, Juha Taina 108 18
Toiminnallisuuden suunnittelu luovaa suunnittelutyötä vrt. analyysi: todellisuuden kuvaus yleensä on mahdollista keksiä useita vaihtoehtoisia käyttäytymistapoja, jotka täyttävät vaatimukset valitaan näistä yksi (paras?) huom. ei oteta kantaa ratkaisun tekniseen puoleen (enempää kuin on välttämätöntä) kevät 2008 REQ, Juha Taina 109 Ulkoinen vs. sisäinen suunnittelu toiminnallisuuden suunnittelu (edesign) suunnittelua ohjaa analyysidokumentti dokumenttia lukevat sekä asiakkaat että järjestelmän kehittäjät oltava sidosryhmien ymmärrettävissä ja hyväksyttävissä osa vaatimusmäärittelyä toteutuksen rakennesuunnittelu (idesign) kokonaisuus jaetaan osajärjestelmiin alemman tason suunnittelua ohjaa ylemmän tason suunnitelma dokumenttia lukevat vain järjestelmän kehittäjät osa suunnitteluvaihetta kevät 2008 REQ, Juha Taina 110 Vaatimusta vastaava toiminta yksi vaatimus vastaavan toiminnallisuuden kuvaus esim.: A lift will only reverse direction when stopped at a floor. yksi vaatimus suuri joukko toiminnallisuuksia esim.: Each lift should be used an approximately equal amount. miten valitaan mikä hissi lähetetään? kevät 2008 REQ, Juha Taina 111 Vaatimusta vastaava toiminta useita mahdollisia ratkaisuja esim.: Subject to constrants detailed below, the user can enter, amend and delete details of: boat-class, boat, series, race, series-entry, race-entry. miten valitaan paras ratkaisu? vaatimusten priorisointi mitä tehdään usein? mikä on tärkeintä? suoriutumisvaatimukset kevät 2008 REQ, Juha Taina 112 Käyttöliittymän suunnittelu käyttäjärajapinta sisältää usein eniten ratkaisuvaihtoehtoja: erilaiset i/o-laitteet komennot vs. graafinen käyttöliittymä käli-suunnittelu on oma osa-alueensa: käyttäjän toimintojen optimointi muistirasituksen minimointi (ml. valittujen ratkaisujen yhdenmukaisuus) palaute ja peruutusmahdollisuus kevät 2008 REQ, Juha Taina 113 Ratkaisun rajapinnat rajapinnan toisena osapuolena ihmiset muut järjestelmät laitteet voidaanko eri rajapinnat erottaa? joskus voi olla selvä hissin käyttäjä vs. huoltomies voi olla paljonkin päällekkäisyyttä kuinka tarkasti rajapinta täytyy määritellä? ainakin looginen toiminnallisuus on määriteltävä entä fyysinen taso? riippuu tehtävästä riippuu liittymän monimutkaisuudesta riippuu asiakkaasta kevät 2008 REQ, Juha Taina 114 19
Suoriutumisvaatimukset myös suoriutumisvaatimukset voivat vaatia täsmentämistä kapasiteettivaatimukset aikavaatimukset erityisesti tosiaikajärjestelmissä tehokkuus? käytettävyys? luotettavuus? kyllä! kyllä! ei! Bray jos ne riippuvat toiminnallisuuden suunnittelusta kevät 2008 REQ, Juha Taina 115 Asiakkaan osallistuminen vaihtelevia käytäntöjä: ääripäät: ei lainkaan koko ajan mukana onko asiakkaan osallistumisesta hyötyä? prototyypit välivaiheiden evaluointi voi paljastaa puutteita vaatimuksissa mutta: kuinka hyvin asiakas tietää, mitkä ovat mahdollisia ratkaisuja? kaikissa tapauksissa asiakkaan täytyy hyväksyä lopputuote kevät 2008 REQ, Juha Taina 116 Käyttäytymisen dokumentointi 1. ratkaisujärjestelmän saamat syötteet syntaksi ja semantiikka 2. ratkaisujärjestelmän tuottamat tulosteet syntaksi ja semantiikka 3. syötteiden ja tulosteiden väliset yhteydet (relationships) reagointi syötteisiin ajalliset riippuvuudet huom. kirjan lyhenne: ER = event response kevät 2008 REQ, Juha Taina 117 Syötteet ja tulosteet analyysivaiheesta saadaan suoraan: tehtäväalueen kuvaus usein myös (suurin) osa syötteistä ja tulosteista riippuu paljon tehtäväalueesta kuvaustapa: tietohakemisto järjestelmä- ja laiterajapinnat usein valmiiksi määriteltyjä käyttäjärajapinnat voi olla paljonkin suunniteltavaa esim. kyselyt, virheilmoitukset jne. kevät 2008 REQ, Juha Taina 118 Miten tietoa välitetään Ratkaisun tietomalli syöttö-/tulosvirta (data stream) tyypillinen siirtotapa esim. kahden järjestelmän välillä käsittely saapumisjärjestyksessä (FIFO) puskurointi tieto on luettavissa vain kerran tietoallas (data pool) moniulotteinen data data käytettävissä, kunnes sen päälle kirjoitetaan samanaikainen käsittely parametrit ohjelmointikielen mukainen tuki periaatteessa ei kuulu kuvattaviksi vaatimusmäärittelyssä syötteet ja tulosteet kertovat kaiken vaatimuksiin liittyvän tiedon yleensä on tapana laatia ratkaisun looginen tietomalli perustana tehtäväalueen tietomalli (laadittu analyysivaiheessa) lisäksi ratkaisun edellyttämä data kevät 2008 REQ, Juha Taina 119 kevät 2008 REQ, Juha Taina 120 20
Ratkaisujärjestelmän reaktiot Syöte-reaktioparit syöte = tapahtuma (event) järjestelmän reaktio syötteeseen (response) voi olla tuloste järjestelmän sisäisen tilan muuttuminen ei mitään reaktiota reaktio voi riippua yhdestä syötteestä useista syötteistä järjestelmään kertyneestä tiedosta järjestelmän tila = tähänastinen syötehistoria reaktio riippuu vain tilasta ja syötteestä auttavat spesifioinnin jäsentämisessä rajapintojen luokittelu laite käyttäjä operaattori ohjelmisto (API) reaktioiden luokittelu kelvollinen syöte tuloste kelvollinen syöte tilanmuutos kelvoton syöte kevät 2008 REQ, Juha Taina 121 kevät 2008 REQ, Juha Taina 122 laite usein ohjaus- tai yhteysjärjestelmien osana, joskus myös tietojärjestelmissä syöttövirta tai tietoallas ohjelmisto tyypillisimmin alijärjestelmissä syöttövirta tai parametrit Rajapintatyypit käyttäjä usein työkaluissa ja tietojärjestelmissä erityislaitteet (hiiri, näppäimistö, näyttö) syöttövirta lomakkeet, näyttö = tietoallas operaattori ihminen, mutta joustavampi kuin tavallinen käyttäjä kevät 2008 REQ, Juha Taina 123 Tulosteen muodostaminen suunnitellaan vastaavien vaatimusten mukaan tehtäväalueen kuvauksen pitäisi sisältää tarvittavat tiedot esim. hissin pysäytys hissin nopeus sensoreilta tuleva syöte moottorille annettavat komennot pysähtymiseen kuluva aika kevät 2008 REQ, Juha Taina 124 Tilanmuutos ratkaisujärjestelmän käytös kuvattu usein jo analyysivaiheessa tarkennetaan suhteessa tietomallin sisältöön esim. hissijärjestelmän asetukset ominaisuudet määritelty analyysissa tilanmuutoksia aiheuttavat tapahtumat voidaan esittää kaaviona Virhetilanteet ratkaisun toiminnan reunaehdot on määritelty analyysissa vaatimukset voivat liittyä esim. hyväksyttävien syötteiden rajoihin esim. hissijärjestelmän asetukset virheelliset arvot jätetään huomiotta tai annetaan käyttäjälle virheilmoitus kuvaus esim. tekstinä tai päätöstauluna kevät 2008 REQ, Juha Taina 125 kevät 2008 REQ, Juha Taina 126 21
Miten käyttäytyminen kuvataan funktionaalinen kuvaus kuvaa lopputuloksen ei kerro miten siihen päästään helpompi laatia helpompi ymmärtää suositeltava! proseduraalinen kuvaus kuvaa toiminnot joiden avulla lopputulokseen päästään ottaa kantaa toteutustapaan kevät 2008 REQ, Juha Taina 127 Spesifiointidokumentti tunnistetiedot yleiskuvaus tehtäväalue + ratkaisu vaatimukset järjestelmän käyttäytyminen tietohakemisto tehtäväalueen + ratkaisun käsitteet lähteet analyysidokumentista kevät 2008 REQ, Juha Taina 128 Vaatimuksia spesifiointidokumentille ymmärrettävä kaikki sidosryhmät selkeästi jäsennelty hierarkkisuus osien numerointi viittaukset muokattavuus jäljitettävyys laadukas yksiselitteinen kattava ristiriidaton automaattista käsittelyä tukeva tarkastus testien generointi animointi Spesifiointidokumentin käyttö vaatimusten kuvaus katselmointi hyväksyminen suunnittelun ja toteutuksen perusta testauksen perusta hyväksymisen vertailukohta tiedon välitys kehittäjille käyttöohjeen laatijoille ylläpitäjille myöhemmät projektit uudelleenkäyttö työmäärän arviointi kevät 2008 REQ, Juha Taina 129 kevät 2008 REQ, Juha Taina 130 Formaali spesifiointi spesifiointi käyttäen täsmällistä matem. notaatiota tavoitteena spesifikaation looginen ristiriidattomuus ratkaisun oikeaksi todistaminen kirjassa on esimerkki formaalista spesifioinnista (VDM) edellyttää käytetyn formalismin hyvää hallintaa käyttäjät ym. sidosryhmät? sopii vain tietyille sovellusalueille esimerkkejä Vienna Development Method (VDM) Z kevät 2008 REQ, Juha Taina 131 Spesifiointitekniikat syötteet ja tulosteet analysoinnissa käytettyjen kuvausten laajentaminen käyttöliittymä piirrokset, prototyypit ratkaisujärjestelmän käyttäytyminen monia erilaisia mallitustapoja ratkaisujärjestelmän tilat ja tilan muutokset tilakaaviot suoriutumisvaatimukset sanalliset kuvaukset (kaaviot) kevät 2008 REQ, Juha Taina 132 22
Esimerkkijärjestelmistä esimerkeissä esitellään samalla tekniikoita tekstiä, kaavioita kehysrakenne ja vaatimusluettelo minkä osa-alueiden kanssa ratkaisujärjestelmällä on rajapintoja? mitkä ovat vaatimukset? tarvittaessa tärkeysjärjestyksessä ensin looginen käyttäytyminen, sen jälkeen fyysiset yksityiskohdat kevät 2008 REQ, Juha Taina 133 lähtökohtana vaatimukset R1, R8, R15 suunnittelun ratkaisuja: käyttöliittymä WIMP (R15) oma ikkuna kullekin editointitavalle raportti tilataan editointi-ikkunasta Esimerkki E1 esimerkki: veneluokan käsittely näytön kuva (paperiproto) kuva 5.12 käyttäytymisen selostaminen esimerkki: liikkuminen ikkunoiden välillä tilakaavio kuva 5.14 kevät 2008 REQ, Juha Taina 134 Esimerkki E1: valikoidut vaatimukset R1: Subject to the constraints detailed below, the user can enter, amend and delete details of: boatclass, boat, race, series, race-entry, series-entry. R8: Upon command from the user, the system will produce the following reports: R8.1 boat-class-list R8.2 boat-list R8.3 series-list R8.4 series-details R8.5 series-outcome R8.6 race-outcome R15: A WIMP type interface is required (WIMP = Windows, Icons, Mouse, Pointer) kevät 2008 REQ, Juha Taina 135 Kuvilla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 136 Esimerkki E2 rajapinnat: kehysrakenteesta ja kontekstikaaviosta kuva 4.48 laitteet (napit, sensorit, moottorit) toimivat yhteen epäsuorasti myös hissit ja käyttäjät laitteet muodostavat käyttäjärajapinnan huoltomies (R16) muusta toiminnasta (enimmäkseen) erillinen rajapinta kuvat 5.4, 5.5 myös R17, R18 huom. myös yhteys muun järjestelmän käyttäytymiseen: hissit pysähtyvät huollon ajaksi Kuvilla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 137 kevät 2008 REQ, Juha Taina 138 23
käyttäjälle näkyvä rajapinta Esimerkki E2 käydään läpi kaikki vaatimukset laitteisto käyttäytyminen? laiterajapinnan kaaviossa R8, R11, R12: teksti R5: (esim. aiemmin) kuvaus taulu 5.5 suoriutumisvaatimukset: laitteiden toiminta: mitä tapahtumia mitä tiloja mitä riippuvuuksia usein tekstinä käyttötapaukset havainnollistaminen tilakaavio kuvat 5.15, 5.16 validointi kevät 2008 REQ, Juha Taina 139 Esimerkki E2: valikoidut vaatimukset R5: With the stop delay correctly configured the lift should stop within +/- 1.5 cm of the floor being serviced. R8: To service a send-button call, the relevant lift must stop at that floor. A call-button call may be serviced by any lift that is travelling in the correct direction stopping at that floor. R11: Where there is more than one lift: Call-button calls should be serviced by the lift that is likely to arrive there soonest. (It is appreciated that this cannot be guaranteed because the selected lift might be requested to service a new call whilst en route.) R12: Where there is more than one lift: Each lift should be used an approximately equal amount. R16: The service technician must be able to set: R16.1 number of lifts R16.2 number of floors R16.3 stop signal delay, for each lift (in the range 0.10 to 0.40 seconds) R17: The maximum number of lifts is 4, the minimum 1. R18: The maximum number of floors is 20, the minimum 2. kevät 2008 REQ, Juha Taina 140 6. Vaatimusten validointi Kuvilla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 141 Bray luku 6 requirements validation etsitään ja korjataan vaatimusten määrittelyn virheitä ja puutteita analyysidokumentti: virhe = kohta jossa kuvaus ei vastaa todellisuutta spesifiointidokumentti: puute = kohta jossa kuvaus ei toteuta haluttuja vaatimuksia rinnakkain muiden vaiheiden kanssa myös menetelmät osittain päällekkäisiä kevät 2008 REQ, Juha Taina 142 Tarkistukset onko kaikki tarvittava otettu huomioon kartutus: kaikki sidosryhmät analyysi: kaikki osa-alueet spesifiointi: kaikki rajapinnat kaikki vaatimukset periaatteessa näiden pitäisi olla kunnossa, käytännössä useinkin unohduksia kevät 2008 REQ, Juha Taina 143 = kaikki kartutusmuistiinpanot = koko analyysidokumentti Vertaaminen standardeihin verrataan dokumenttia standardeihin poikkeamat kootaan ja korjataan dokumentin laatijat korjaavat korjaukset hoidettava ennen katselmointia (elleivät ole aivan vähäisiä) korjaaminen voi aiheuttaa uusia virheitä standardit on tarkoitettu helpottamaan lukemista: (turhien) muotovirheiden puuttuminen tehostaa katselmointia (sama koskee myös kielivirheitä) kevät 2008 REQ, Juha Taina 144 24
inspection review walk-through riippuu formaaliuden asteesta osallistujat: esittelijä kirjuri vetäjä tehtäväalueen asiantuntijat Katselmointi etsitään, ei korjata havainnot kirjataan korjausten seuranta suoritettava ajoissa suunnittelu etenee joka tapauksessa kallista, mutta tehokasta (jos on hyvin valmisteltu) kaikilta tarvittavilta osa-alueilta kevät 2008 REQ, Juha Taina 145 Looginen tarkastus vaatimusmäärittelyn syntaksin ja semantiikan tarkastus edellyttää sääntöpohjaisuutta formaalit menetelmät myös: muut kuvaustavat joissa on käytössä täsmälliset säännöt esim. monet kaaviot automatisointi? syntaksiohjatut CASE-työkalut erillinen tarkastustoiminto kevät 2008 REQ, Juha Taina 146 Prototyypit spesifikaatio proto kuvataan sama asia kahdella erilaisella tavalla havainnollistaa määrittelyä esim. animointi myös paperiprotot automatisointi? mahdollisia ongelmia: onko proto yhtäpitävä määrittelyn kanssa? onko määrittely oikea? kevät 2008 REQ, Juha Taina 147 Testitapausten suunnittelu vaatimusmäärittelyn tulee olla testattava hyväksymistestit pitää suunnitella (dokumentoitujen) vaatimusten perusteella jos testejä ei voi suunnitella, tuotetta ei voi testata! testejä suunniteltaessa voi paljastua ongelmia: puutteita ratkaisun suunnittelussa puutteellisesti dokumentoidut vaatimukset Ilmaista : testit täytyy joka tapauksessa suunnitella! kevät 2008 REQ, Juha Taina 148 Käyttöohjeen suunnittelu myös käyttöohjeen pitäisi olla tehtävissä vaatimusten kuvauksen perusteella edellyttää että käyttöliittymä on kuvattu erityisesti voidaan löytää käytettävyysongelmia rinnakkaisuuden hyödyt suunnittelun ja käyttöohjeen laatimisen vuorovaikutus lisäksi: asiakkaat ovat tässä vaiheessa usein paremmin tavoitettavissa kuin myöhemmin Ilmaista : käyttöohje täytyy joka tapauksessa suunnitella! kevät 2008 REQ, Juha Taina 149 Tarkistuslistat tukevat monia validoinnin osatehtäviä esim. puuttuuko joitakin vaatimuksia onko vaatimusten välillä ristiriitoja onko teksti ymmärrettävää (kaikille) voiko jonkin vaatimuksen ymmärtää monella eri tavalla onko dokumentin rakenne selkeä ja jäsennelty onko dokumenteissa jäljitystä ajatellen riittävät viitteet noudattaako dokumentti sovittuja standardeja kevät 2008 REQ, Juha Taina 150 25
Validointi osana prosessia vaatimusten validoinnin pitäisi olla osa vaatimusmäärittelyn elinkaarta huom. ei erillisenä vaiheena vaan kaikkien vaiheiden osana validointimenetelmien pitäisi taata että vaatimukset ovat kunnossa onko tämä edes mahdollista? (kaikissa oppikirjoissa ei edes mainita vaatimusten validointia!) kevät 2008 REQ, Juha Taina 151 7. Laatuvaatimukset quality requirements myös: ei-toiminnalliset vaatimukset (non-functional requirements, NFR) suoriutumisvaatimukset (performance requirements) tavoitteet (goals) lähde: Chung, Nixon, Yu, Mylopoulos, Non-functional Requirements in Software Engineering, luvut 1-2, Kluwer 2000 perustuu artikkeliin Chung, Nixon, Yu 1994 kevät 2008 REQ, Juha Taina 152 Laatuvaatimusten jaottelua Lisää jaottelua (Sommerville) laatuvaatimukset (Rome Laboratory) Non-functional requ ir em ent s suoriutumisvaatimukset suunnitteluyms. rajoitteet käyttäjälähtöiset (consumer-oriented) tekniset (technically-oriented) P ro du ct requir em ents Or gan izational requ ir em ent s External requirements suoriutuminen (performance) suunnittelun laatu (design) sopeutuvuus (adaptation) laajennettavuus (expandability) joustavuus (flexibility) yhteentoimivuus (interoperability) siirrettävyys (portability) uudelleenkäytettävyys (reusability) tehokkuus (efficiency) turvallisuus (integrity) luotettavuus (reliability) säilyvyys (survivability) käytettävyys (usability) virheettömyys (correctness) ylläpidettävyys (maintainability) todennettavuus (verifiability) kevät 2008 REQ, Juha Taina 153 Efficiency Reliability Portability Interoperability Ethical requir em ents requirements requirements requirements requirements Usability Delivery Implementation Standards Leg islat ive requirements requirements requir em ents requirements requ irements Perform ance Sp ace Privacy Safety requirements requir em ents requirements requ irements Kuva I. Sommerville 2000 kevät 2008 REQ, Juha Taina 154 Lisää jaottelua (Chung et al) tuotelähtöiset (product-oriented) mitataan tuotteen ominaisuuksia edellyttää että on tuote jota mitata! prosessilähtöiset (process-oriented) tarkastellaan laatuominaisuuksien yhteyttä prosessiin mikä on suunnittelupäätösten vaikutus laatuun tarkastelu lähinnä kvalitatiivista (myös kvantitatiivinen lähestymistapa on mahdollinen: tätä on sivuttu mm. laitoksen MAISA-projektissa) miten nämä sopivat vaatimusmäärittelyyn? kevät 2008 REQ, Juha Taina 155 Laatuvaatimusten piirteitä subjektiivisuus suhteellisuus keskinäiset riippuvuudet /ristiriidat ei voida lisätä jälkeenpäin vaikeasti tunnistettavissa tavoitteen täyttyminen: voi täyttyä: täysin suurimmaksi osaksi kohtuullisesti hieman ei ollenkaan hyväksyttävyys kevät 2008 REQ, Juha Taina 156 26