1. Johdanto. Kurssin otsikko

Transkriptio

1 Bray luvut Johdanto 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: vaatimus, edellytys, tarve requirements engineering: vaatimusten muodostaminen vaatimusten käsittely täsmällisyys, systemaattisuus, hallitut työtavat ja menetelmät epämääräistä! vaatimusmäärittely huom: ei tarkoita samaa kuin termi requirement specification kevät 2008 REQ, Juha Taina 2 1

2 Mistä on kysymys? monta sidosryhmää monenlaisia tarpeita eri näkökulmia 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 2

3 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 3

4 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 4

5 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 5

6 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 6

7 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 7

8 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 8

9 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 pelkistämällä = karsimalla epäolennaisuuksia mikä on epäolennaista? käsittely ko. vaiheen yhteydessä yhtenä kokonaisuutena 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 9

10 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 kevät 2008 REQ, Juha Taina 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 10

11 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 11

12 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 12

13 Validointi 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 kevät 2008 REQ, Juha Taina 25 Yhteys ohjelmistoprosessiin esimerkkejä: vaatimusten jäljittäminen validointi vaatimuksia vasten vaatimusmäärittely Vesiputousmalli eritasoiset vaatimukset V-malli kevät 2008 REQ, Juha Taina 26 13

14 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? huom. ajoitus! kevät 2008 REQ, Juha Taina 27 Vaatimusmäärittelyprosessi Bray: kuva 2.1 (kalvo 31) vaiheet tietovarastot tiedon siirtyminen vaiheesta toiseen vaiheiden aikajärjestys kevät 2008 REQ, Juha Taina 28 14

15 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 kevät 2008 REQ, Juha Taina 29 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 30 15

16 Kuvalla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 31 Vaatimuksia vaatimuksille 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 32 16

17 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 17

18 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 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 18

19 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 Tietolähteitä asiakkaat käyttäjät entinen järjestelmä tuleva järjestelmä tehtäväalueen asiantuntijat 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 19

20 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 20

21 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 21

22 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 22

23 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 23

24 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 24

25 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 25

26 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 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 26

27 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 27

28 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 kevät 2008 REQ, Juha Taina 55 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 56 28

29 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 (PDOA) lähtökohtana tehtäväaluetyypin/-tyyppien tunnistaminen kevät 2008 REQ, Juha Taina 58 29

30 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) kevät 2008 REQ, Juha Taina 59 Rakenteinen analyysi SA 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 60 30

31 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 31

32 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 kevät 2008 REQ, Juha Taina 63 Figure 4.5 Kuvilla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 64 32

33 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 Esimerkkijärjestelmä E4 SA 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 33

34 Kritiikkiä (Bray) SA 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 Olioanalyysi OOA 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 34

35 Olioanalyysi OOA erilaisia olioluokkia: käsitteelliset = tehtäväalueen luokat rajapintaluokat toteutusluokat analyysivaiheessa spesifiointivaiheessa suunnitteluvaiheessa 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 Olioanalyysi OOA 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 35

36 Esimerkkijärjestelmä E1 OOA 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 Esimerkkijärjestelmä E1 OOA 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 36

37 Kuvilla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 73 Esimerkkijärjestelmä E1 OOA enter new boat user calculate results print report Kuvaa järjestelmän kontekstia, ei niinkään vaatimuksia. race officer kevät 2008 REQ, Juha Taina

38 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 Esimerkkijärjestelmä E2 OOA 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 38

39 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 39

40 Kuvilla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 79 Kritiikkiä (Bray) OOA 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 80 40

41 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) PDOA kevät 2008 REQ, Juha Taina 81 Tehtäväkehykset PDOA 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 41

42 Tehtäväaluetyypit PDOA 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) kevät 2008 REQ, Juha Taina 83 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 PDOA kevät 2008 REQ, Juha Taina 84 42

43 Sanallinen kuvaaminen PDOA 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 Tehtäväalueen luokittelu PDOA 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 43

44 Analyysin eteneminen PDOA 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 Työkalu PDOA 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 44

45 Kuvilla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 89 Ohjaus PDOA 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 90 45

46 Kuvilla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 91 Tietojärjestelmä PDOA 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ä esim. opiskelijarekisteri, lennonohjaus 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 kevät 2008 REQ, Juha Taina 92 46

47 Kuvilla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 93 Kuvalla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 94 47

48 Muunnos PDOA 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ä PDOA 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 itsenäinen esim. käyttöliittymä, potilaan tarkkailu laite konkreettinen itsenäinen tehtäväalueen ja laitteen tietojen yhteensopivuus taulu 4.9 tehtäväalue: tilat, tapahtumat vaatimukset: kuvaus alueiden välillä kevät 2008 REQ, Juha Taina 96 48

49 Kuvilla (C) Ian Bray, 2002 kevät 2008 REQ, Juha Taina 97 Monta kehystä PDOA 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 kevät 2008 REQ, Juha Taina 98 49

50 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 PDOA 50

51 Esimerkkijärjestelmä E2 PDOA 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, kevät 2008 REQ, Juha Taina 101 Esimerkkijärjestelmä E2 PDOA 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

52 Esimerkkijärjestelmä E3 PDOA 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) kevät 2008 REQ, Juha Taina 103 Esimerkkijärjestelmä E4 PDOA 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

53 Arviointia PDOA 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ä? kevät 2008 REQ, Juha Taina 105 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

54 5. Vaatimusten spesifiointi rajapinta tehtäväalue ratkaisujärjestelmä Bray luku 5 requirements specification ratkaisun ja tehtäväalueen rajapinta miten ratkaisun pitää toimia, jotta se täyttäisi asetetut vaatimukset kevät 2008 REQ, Juha Taina 107 Spesifiointivaiheen tehtävät 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

55 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

56 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.: Eachliftshouldbeusedan 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

57 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

58 Suoriutumisvaatimukset myös suoriutumisvaatimukset voivat vaatia täsmentämistä kapasiteettivaatimukset aikavaatimukset erityisesti tosiaikajärjestelmissä tehokkuus? kyllä! käytettävyys? luotettavuus? 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

59 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 järjestelmä- ja laiterajapinnat usein valmiiksi määriteltyjä käyttäjärajapinnat voi olla paljonkin suunniteltavaa esim. kyselyt, virheilmoitukset jne. kuvaustapa: tietohakemisto kevät 2008 REQ, Juha Taina

60 Miten tietoa välitetään 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 kevät 2008 REQ, Juha Taina 119 Ratkaisun tietomalli 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

61 Ratkaisujärjestelmän reaktiot 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ä kevät 2008 REQ, Juha Taina 121 Syöte-reaktioparit 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

62 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

63 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 kevät 2008 REQ, Juha Taina 125 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

64 Miten käyttäytyminen kuvataan funktionaalinen kuvaus kuvaa lopputuloksen ei kerro miten siihen päästään helpompi laatia helpompi ymmärtää proseduraalinen kuvaus kuvaa toiminnot joiden avulla lopputulokseen päästään ottaa kantaa toteutustapaan suositeltava! 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

65 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 kevät 2008 REQ, Juha Taina 129 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

66 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