Projektityö

Transkriptio

1 Projektityö Kevään luennot: 13.1 ja Kurssin käytäntöjä Vaatimusten määrittelystä Vaatimusten keräämisestä, erilaisia vaatimusluokkia Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto, Talentum, Luvut 3 (Spesifikaatioiden laatiminen), 4 (Vaatimusten hallinta), 5 (Toimintojen ja tietojenkuvaus), 6-10 (lukuja erilaisista kaavioista). Sommerville, Software Engineering 7, luvut 6 ja 7. Soren Lauesen, Software requirements, styles and techniques. Alkuperäiset kalvot: Isto Aho, muutoksia: Timo Poranen 1

2 Projektisuunnitelma Miten määritellyillä resursseilla päästään aikataulun puitteissa haluttuun lopputulokseen? Esitutkimus Miksi järjestelmä tulisi tehdä? Miksi sitä ei kannata tehdä? Vaatimusten määrittely Tarkastus Mikä on ratkaistava ongelma, onko ratkaisua olemassa, Mitä se maksaa, mitä reunaehtoja sillä on... Millainen järjestelmä täyttää ongelman vaatimukset Miten ohjelman pitäisi toimia, asiakkaan vaatimukset Suunnittelu Tarkastus Miten järjestelmä toteutetaan, järjestelmän osittaminen Toteutus Testaus Osien ohjelmointi Integrointi Testaus Osien yhteenliittäminen Käyttöönotto ja ylläpito Vesiputousmallista (Mukailtu lähteestä: Haikala ja Märijärvi: Ohjelmistotuotanto). 2

3 Kurssin suoritukseen liittyvää 1/2 Kurssin virallinen dokumenttipohja on fi/~projekti/dokumentit/maar-sisalto.txt. Kurssilla voi käyttää myös RE-kurssin pohjaa: edellyttäen, että sitä täydennetään vastaamaan virallista dokumenttipohjaa: Otetaan huomioon käyttöliittymäasiat (näistä voi projektikohtaisesti olla myös erillinen käyttöliittymädokumentti). Kaikki käyttötapaukset esitetään täsmällisesti (katso use-case -materiaali: Kiinnitä huomiota: tiedot ja tietokannat, suunnittelurajoitteet, hylätyt ideat, avoimet ongelmat. 3

4 Kurssin suoritukseen liittyvää 2/2 RE-kurssin dokumentista puuttuvia asioita voi myös laittaa erillisiksi liitteiksi. Katselmointi viimeistään Käykää vaatimustenmäärittelyä läpi asiakkaanne kanssa sitä mukaan kun se valmistuu, näin saatte palautetta jo kirjoitustyön aikana. Asiakkaan pitää hyväksyä vaatimustenmäärittely, joten yrittäkää saada asiakas mukaan katselmointiin! 4

5 Tavoitteista Luentojen jälkeen opiskelijan tulisi osata: Kerätä vaatimuksia erilaisia tekniikoita käyttäen. Käyttää erilaisia vaatimusten esitystekniikoita. Tunnistaa tärkeimmät vaatimuskategoriat. Arvioida vaatimusmäärittelyjen käyttökelpoisuutta ja vaatimusten onnistuneisuutta. 5

6 Sisällöstä Tavoitekalvon asioita. Miksi vaatimuksia kerätään? Vaatimusten muodostamisen ajankohta projekteissa. Käydään lävitse joukko vaatimustenkeruutekniikoita. Vaatimuksia kerätään tai esitetään mm. tiedosta ja sen esitysja käyttötavoista, muusta toiminnallisuudesta, laatuasioista, hallinnollisista asioista. Erilaisia esitystekniikoita on runsaasti: kaikkia ei voi välttämättä soveltaa samaan projektiin. (Mutta kurssilla toki yritetään kokeilla mahdollisimman useaa... ) 6

7 Motivointia Vaatimuksissa tapahtuneet virheet huomattavasti kalliimpia korjata kuin toteutusvaiheessa tehdyt virheet. Tarpeet (ohjelmistolle asetetut) voivat muuttua ajan myötä. Mikäli vaatimusten etsinnässä ja esittämisessä epäonnistuu, voi tehdä yhden projektitoiminnan perusvirheen: antaa ratkaisun väärään ongelmaan. 7

8 Vaatimukset ja projektin vaiheet Ohjelmiston kehitystyö alkaa yleensä analyysi- ja määrittelyvaiheella, jonka tuloksena saadaan mm. vaatimusmäärittely. Vaatimusmäärittely ohjastaa seuraavia vaiheita, kuten suunnitteluvaihetta. 8

9 Keneltä vaatimuksia Vaatimukset saadaan muodostettavan järjestelmän käyttäjiltä ja muilta asianosaisilta. Suunnittelija analysoi tarpeita ja muodostaa niistä johdonmukaisia käyttökelpoisia kokonaisia vaatimuksia. 9

10 Vaatimusten keruun vaikeuksia Vaatimusten muodostaminen voi olla hankalaa asianosaiset eivät välttämättä osaa ilmaista tarpeitansa asianosaiset saattavat pyytää ratkaisuja, jotka eivät vastaa todellisia tarpeita osa tarpeista voi olla keskenään ristiriitaisia uusia toimintatapoja ei välttämättä osata kuvitella uusien ratkaisujen kaikkia vaikutuksia ei välttämättä ymmärretä loppukäyttäjiä ei ole aina käytettävissä (esim. uusi tuote) 10

11 Mistä vaatimuksia yleensä esitetään? datasta käyttäytymisestä laadusta hallinnollisista asioista Myös muista asioista saattaa tulla vaatimuksia tai kommentteja vaatimusmäärittelyihin. 11

12 Datavaatimuksista Vaatimuksia voidaan esittää datalle. varastointi syöttäminen tulostaminen 12

13 Käyttäytymisvaatimuksista Kuinka dataa tallennetaan, lasketaan, muunnetaan, välitetään. Lisäksi käyttäytymisvaatimukset kertovat, mitä toimintoja ohjelmasta löytyy. Laadullisista vaatimuksista Laadulliset vaatimukset sisältävät tehokkuuteen, käytettävyyteen ja ylläpitoon liittyviä asioita. Hallinnollisista vaatimuksista Hallinnolliset vaatimukset kertovat toimitusajan, lakiin liittyvät asiat ja esimerkiksi kehitysprosessista. 13

14 Kuinka kerätä vaatimuksia? 1. Asianomaisten analyysi. Ketkä ovat asianosaisia? Mitä tavoitteita heillä on? Miksi he panostavat tähän? Mitä riskejä ja kuluja heille koituu? Mitä ratkaisuja ja toimittajia he harkitsevat? 2. (Ryhmä) haastattelu. Tiedon keruuta nykyisistä työtavoista ja ongelmista. 3. Tarkkailu. Käyttäjät eivät aina tiedä, mitä he tekevät ja kuinka. Esimerkiksi jonkin sivun hakeminen tutusta kirjasta käyttäjien mukaan tapahtuu hakemiston avulla lähes aina, vaikka todellisuudessa iso osa selailee suoraan kirjaa kunnes löytää halutun kohdan. 14

15 4. Tehtävä- ja toimintademo. Pyydetään käyttäjiä näyttämään, kuinka tekevät/toimittavat nykyiset tehtävät. (Joskus esittäminen on helpompaa kuin selittäminen.) 5. Dokumenttien tutkiminen. Saadaan esim. tietoa vanhasta datasta. 6. Kyselylomakkeet. Tiedonkeruuta usealta käyttäjältä: saadaan tilastollista näyttöä jostain asiasta, tai sitten mielipiteitä ja ehdotuksia. 7. Aivoriihet. Generoidaan ideoita. 15

16 8. Kohderyhmät (tulevaan keskittyvät ryhmätyöt). Hieman tavoitteellisempaa kuin kohdassa 7). Lähdetään nykykäytännöistä ja yritetään kuvitella tulevia työtapoja. 9. Perustoimintoryhmätyöt (domain workshops). Mitä toimintoja tarvitaan alalla? Kokeneet käyttäjät kertovat työstään. 10. Suunnitteluryhmätyöt. Käyttäjät ja suunnittelijat suunnittelevat jotain yhdessä. Usein käyttöliittymiä. 11. Prototyypit. Lopputuotteen yksinkertaistettu versio. Kuinka se toimisi todellisessa elämässä? 12. Pilottikokeilut. Uuden systeemin käyttöönoton riskien pienentämiseksi. 16

17 13. Samanlaiset yrityksien tutkailut. Voi antaa uusia ideoita. 14. Toimittajakyselyt. Heidän etuihinsa kuuluu antaa ideoita heidän tuotteden myyntiin liittyen. 15. Neuvottelu. Ratkaistaan mahdollisia konflikteja (voivat olla mm. eri asiakasryhmien välillä). 16. Riskianalyysi. Riskien etsintää ja niihin varautumista. Niitä voi etsiä yhdessä asianosaisten kanssa. Kuinka heidän työnsä muuttuu järjestelmän käyttöönoton jälkeen? Mitä muutoksia tarvitaan? Mitä mahdollisia konflikteja heidän mielestään saattaa tulla esille? 17

18 17. Hinta- ja hyötyanalyysi. Voidaan esittää rahana, mutta jako raha- ja laatutekijöihin esiintyy. 18. Tavoite- ja ala-analyysi (goal-domain). (Liike)toimintatavoitteiden ja tehtävien suhde. Tavallaan tarkistustekniikka mutta voi muuttaa vaatimuksia paljon. 19. Ala- ja vaatimusanalyysi (domain-req.). Samanlaista kuin edellisessä kohdassa mutta alemmalla tasolla. 18

19 Keräystekniikoiden tuloksia Edelle mainituilla tekniikoilla voi löytää vaatimuksia nykytyölle, nykyisille ongelmille ja saada esille tavoitteita ja avainkysymyksiä. Lisäksi voidaan saada ideoita tulevalle systeemille, hahmottaa realistiset mahdollisuudet ja kartoittaa seurauksia sekä riskejä. Edelleen halutaan saada selville, kuinka projektiin sitoudutaan ja kuinka mahdolliset konfliktit ratkaistaan. Tuloksena saadaan vaatimuksia, prioriteetteja ja tietoa, kuinka täydellisesti vaatimukset ja prioriteetit on onnistuttu kartoittamaan. 19

20 Kuinka esittää vaatimuksia datan (tiedon) suhteen? 1. Tietomalli (data model). Esimerkiksi ER-malli, oliomalli tms. tarpeen mukaan. 2. Tietohakemisto (data dictionary). (TODO, tarkista!) Datan kuvaus tekstinä (aina tietohakemisto ei ole tarpeen, vaan voidaan jättää esim. suunnittelijan huoleksi). 20

21 3. Tietoilmaisut (data expression). Käytetään datan esittämiseen jotain formaalimpaa menetelmää, erityisesti jos datalla on rakennetta, kuten koosteisessa datassa tai protokollissa. Esimerkiksi säännöllisiä lausekkeita tai BNF-notaatiota (Backus-Naur Form). (Jos ei tuttuja, niin tutustu unixin grep-komentoon vaikka aluksi). 4. Virtuaali-ikkunat (virtual windows). Yksinkertaistettuja näyttökuvia, joista löytyy grafiikkaa ja realistista dataa mutta ei esimerkiksi nappuloita saati menuja. 21

22 Kuinka esittää toiminnallisuuden (käyttäytymisen) suhteen vaatimuksia? 1. Ihminen/tietokone - kuka tekee mitäkin? Tässä voi käyttää esimerkiksi yksinkertaisia tietovirtakaavioita, prosessikaavioita ( kaveri ) ja varmaan UMLstä löytyy kasa kaavioita, jotka kelpaavat yhtä hyvin. Saadaan toiminnallisuuden fyysinen malli. Alla olevat kohdat tarkentavat: 2. Kontekstikaaviot. Tuotteen ja sen ympäristön kuvaavat kaaviot näyttävät tuotteen laajuuden. Notaationa jonkinlainen tietovirtakaavio varmaan toimii parhaiten. 22

23 3. Tapahtuma- ja toimintolistat. Tuotteen käsittelemät tapahtumat. Ihmisen+koneen käsittelemät tapahtumat. Päätapahtumat voidaan esittää käyttötapauksina (use cases). Tuotetapahtumia sanotaan usein viesteiksi (messages). 4. Ominaisuusvaatimukset. Esimerkiksi tekstiä tuote laskee/tallentaa/näyttää... (Voi johtaa väärään käyttäjien ja analysoijan turvallisuuden tunteeseen.) 5. Näytöt ja prototyypit. Mitä nappulasta tapahtuu? 23

24 6. Toimintokuvaukset. Rakenteellista tekstiä käyttäjän toimintojen kuvaamiseen. Toiminnot voidaan jakaa koneen ja ihmiseen osuuksiin. Koneen osuudet voidaan esittää esimerkiksi käyttötapauksin (use case). Yhdessä käyttötapauksessa (tai toimintokuvauksessa) voidaan kertoa mm. tapauksen nimi, tarkoitus, esiehto ja laukaisija, esiintymistiheys, kriittisyys, osatapaukset ja muunnelmat. 7. Piirteitä toimintokuvauksista. Toimintojen käytössä pärjättävä ilman hiirtä... 24

25 8. Tehtävät ja tukitoiminnot. Rakenteellista tekstiä, joka kuvaa tehtävät, pääongelmat ja mahdollisen tuen niille. Halutaan selvittää kriittiset asiat. Esim. jos käyttötapauksissa saadaan jokin tehtävät jaettua osatehtäviin, voidaan osatehtävien kohdalla huomata kysymyksiä ja ongelmia, joihin on vastattava. Tekemällä kaksi palstaa, voi vasemmassa olla nuo osatehtävät ja huomatut kysymykset, ja oikealla puolella esimerkkiratkaisuja (jotka myöhemmin projektin edetessä muuttuvat ehdotetuiksi ratkaisuiksi ja lopulta sovituiksi ratkaisuiksi). 25

26 9. Hahmotelmat (skenaariot). Jokin tapaus joka valottaa yhtä tai useampaa toimintoa, tai jotain tiettyä testattavaa tapausta. Näiden avulla pystyy parantamaan käyttäjien ymmärrystä (mutta ei anna vaatimuksia). 10. Käyttötapaukset (use cases). Booch et al. (1999) A use case is a description of a set of sequences of actions, including variants, that a system performs to yield an observable result to an actor. UMLstä löytyy omia kaaviotyyppejä tälle. Kohdan 6 kuvaus kertoo myös käyttötapauksista. Aktiviteettikaavio (jossa näkyy käyttäjä tekemässä kaikenlaista). 26

27 11. Toiminnot datan kanssa. Rakenteellista tekstiä, kuvaavat käyttötapauksien osatoiminnot ja niiden tarvitseman datan. Kuten kohdassa 8, mutta nyt käytössä kolme saraketta: ensimmäiseen osatoiminto, toisessa kuvataan kunkin osatoiminnon näkyvä data ja kolmannessa listataan virtuaali-ikkunat. 12. Tietovirtakaaviot. (DFD, data flow diagram, PSPEC, processing specification, CSPEC, control specification.) Näyttää toiminnot, datan virtaamassa eri toimintojen välillä. Lisäksi mukana saattaa näkyä toimijoita (esim. kaveri -ohjelmisto). 13. Standardit. Nämä tekstinä: tuote tukee standardia xx. 14. Kehitysprosessiin liittyvät vaatimukset. Esimerkiksi vaatimus, että käytetään jotain tiettyä menetelmää vaatimusten keräämiseen. 27

28 Laatuvaatimuksista Kuinka systeemin tulee suorittaa toimintonsa? Millaiset vasteajat? Kuinka helppokäyttöinen sen on oltava? Miten tietoturva? 28

29 Laatutekijät Laatutekijöitä voi kerätä erilaisiin listoihin, joita voi käyttää tarkistuslistoina. Esimerkkinä kolme eri tapaa, McCall ja Matsumoto, ISO 9126 ja IEEE 830. McCall ja Matsumoto: Toiminnallisuus: eheys (turvallisuus), oikeellisuus, luotettavuus, käytettävyys, tehokkuus. Korjattavuus: ylläpidettävyys, testattavuus, joustavuus. Muunnettavuus: siirrettävyys, liitettävyys (muihin systeemeihin), uudelleen käytettävyys (reusability). 29

30 ISO 9126 (vain päätason laatutekijät): Toiminnallisuus, luotettavuus, käytettävyys, tehokkuus, ylläpidettävyys, siirrettävyys, sopivuus (tarkoituksenmukaisuus), mukautuvaisuus ja yhdenmukaisuus sekä uudet osatekijät. IEEE 830: Tehokkuusvaatimukset, ohjelmiston systeemiominaisuudet, luotettavuus, käyttökelpoisuus, turvallisuus, ylläpidettävyys, siirrettävyys ja helppokäyttöisyys. Listoihin voi tarpeen vaatiessa lisätä uusia kohteita. Seuraavilla kalvoilla esitetään tekniikoita, kuinka esittää joitain yllä olevista laatutekijöistä. 30

31 Laatutaulukko (quality grid) Laitetaan valitut laatutekijät riveinä taulukkoon, jonka sarakkeita ovat esim. kriittinen, tärkeä, tavallinen, ei-tärkeä ja sivuutetaan. Esim: kriitt. tärkeä tav. ei-tärkeä sivuut. Toiminnallisuus: eheys (turvallisuus) oikeellisuus luotettavuus 1 käytettävyys 2 tehokkuus 3 Korjattavuus: ylläpidettävyys X X X 31

32 Taulukon jälkeen voi antaa numeroille selitykset, miksi luotettavuus on tärkeää, miksi käytettävyys kriittistä jne. Jos jotain laittaa tavallista tärkeämmäksi, pitäisi löytyä myös asioita, jotka eivät ole yhtä tärkeitä tai jotka sivuutetaan (kaikkeen ei voi panostaa samalla tavalla). Laatua voi parantaa työskentelemällä kovemmin, saamalla lisää rahoitusta, sivuuttamalla merkityksettömät asiat ja käyttämällä parempia tekniikoita. 32

33 Avoimet mittarit ja päämäärät Joskus voi olla vaikeaa valita sopiva mittari (metriikka) laadun mittaamista varten. Tai päättää jostain arvosta. Esimerkiksi jos halutaan ennusteita jostain asiasta, pitäisi päättää, kuinka kauan ennusteen laskemiseen saa käyttää aikaa, ja kuinka tarkkoja ennusteiden pitäisi olla. Joissain tilanteissa toimittajalta voi kysyä noita. Tällöin laskenta-aika jää vaatimuksissa avoimeksi päämääräksi ja ennusteen tarkkuuden mittari avoimeksi mittariksi. 33

34 Planguage-kieli on kehitetty laatutekijöistä keskustelemiseen (Tom Gilb). Se koostuu seuraavista kohdista: Tag (laatutekijä), Gist (tavoitteesta yleisin termein), Scale (mitta-asteikko), Meter (kuinka mitataan), Must, Plan, Wish, Past. Nyt esimerkiksi avoin päämäärä vastaisi plan -kohdan jättämistä auki. 34

35 Kapasiteetti- ja täsmällisyysvaatimukset (tarkkuus-) Yksinkertaisimpia ellei peräti triviaaleja laatutekijöitä, jotka usein unohdetaan. Yhtäaikaisia käyttäjiä 50, kasvaa vuosittain 10%. Täytyy toimia alle 1Mb muistissa. Nimikentässä käytetään 150 merkkiä. Joissain standardeissa tarkkuusvaatimukset ovat osa toiminnallisia vaatimuksia. 35

36 Tehokkuusvaatimukset Vasteajat, huippukuorma, jne. Teknisiä ja psykologisia rajoja. Voidaan ilmaista ylä- ja alarajoina, ja keskimääräisinä arvoina. Monen käyttäjän systeemeissä esimerkiksi max-vasteaikaa ei tulisi määrittää, koska sen takaaminen on vaikeaa, ellei mahdotonta. Sen sijaan 95% rajan käyttö on ok. Esim. että vastaukset saapuvat 2 sekunnissa 95% tapauksista. Tehokkuusvaatimuksia voi esittää myös joukolle toimintoja tai vain kriittisimmille toiminnoille, jos toimintoja on paljon. Joissain useista erillisistä osista koostuvissa systeemeissä (esim. eri toimittajilta) ei aina voi rajoja laittaa lainkaan. 36

37 Käytettävyys Käytettävyysongelmat voidaan havaita käytettävyystesteillä. Vaatimus systeemi on helppokäyttöinen ei toimi vaatimuksena. Parempi olisi esimerkiksi, että 80% uusista käyttäjistä pystyy kirjaamaan henkilötiedot viidessä minuutissa, tekemään tilauksen kymmenessä minuutissa. (Minkä jälkeen kerrotaan, mitä uudella käyttäjällä tarkoitetaan.) Käytettävyyttä voi parantaa tekemällä prototyyppejä, käytettävyystestaamalla prototyyppejä ja suunnittelemalla ja muuntelemalla prototyyppejä. Tuloksena ohjelmointi helpottuu ja asiakastyytyväisyys paranee. Käytettävyystestit on syytä tehdä ennen kuin koodia on aloitettu kirjoittamaan, jo paperinäyttöjen käyttö voi paljastaa osan ongelmista. 37

38 Käytettävyysvaatimukset Voivat olla tai koskea: ongelmalaskureita, tehtävän suoritusaikoja, näppäinten painalluslaskureita, mielipidemittauksia, ymmärtämispisteytyksiä, suunnittelutason vaatimuksia, 38

39 tuotetason vaatimuksia, tyylioppaan noudattamista (guideline adherence) ja tuotantoprosessin vaatimuksia. Luettelon eri kohtien käyttäminen aiheuttaa erilaisia riskejä sekä toimittajalle että asiakkaalle (jotkut kohdista ovat arveluttavia esim. asiakkaan kannalta). 39

40 Turvallisuus Suojauksia väärinkäyttöä ja onnettomuuksia vastaa. Uhkien kartoitusta ja niiden vaikutusten arviointia (turvallisuusriskien arviointia). Omaisuuden suojaamista, tässä yhteydessä datan ja prosessointikyvykkyyden turvaaminen. CIA+A malli: luotettavuus (dataa käytetään vain luvallisiin tarkoituksiin), eheys (datan), saavutettavuus (data näkyvillä vain luvan omaavilla henkilöillä) ja autentikointi (Confidentiality, Integrity, Availability, ja Authenticity). 40

41 Suojautumiskeinoja voivat olla: estäminen, havaitseminen ja korjaaminen. 41

42 Uhkia voivat olla: fyysinen häiriö, onnettomuus, yksinkertainen käyttäjän virhe, ohjelmointivirhe, sabotaasi (tahallinen rikkominen), luvaton kirjautuminen tai salasanojen varastaminen, väärennös, verkon kuuntelu, verkossa liikkuvan datan muuntaminen, ohjelmoitu rikos. Kukin uhista voi kohdistua syöttö-, tallennus- tai tulostusprosesseihin. 42

43 Turvavaatimukset Ensin on syytä arvioida turvallisuusriskit. Toimittajalta voi kysyä, kuinka suojautua uhkiin, joihin liittyy suuren tappion tms. mahdollisuudet. Esim. Tuote suojattu kovalevyn rikkoutumisia vastaan. Arvioidut ongelmat alle kerran sadassa vuodessa. Tuote sisältää firewall-ratkaisun ja virusskannerin. 43

44 Ylläpito Systemaattista puutteiden korjaamista, tuotteen laajentamista ja käyttäjien tiedottaminen ja kouluttamista. Usein erotetaan kolme ylläpitotoimintoa, korjaava ylläpito, ennaltaehkäisevä ylläpito ja täydentävä ylläpito. 44

45 Ylläpitoon liittyy sykli, johon liittyy ongelman raportointi, sen analyysi, päätösvaihtoehtojen kartoitus, vastaus, mahdollisen ratkaisun testaus ja lopulta päätöksen toteuttaminen. 45

46 Lisäksi pitää ratkaista, milloin kyseessä on puutteen tai virheen korjaus (joka ehkä tehdään takuutyönä), ja milloin asiakkaan tulee maksaa muutoksista. Virheitä voivat olla mm. ohjelmointivirhe, vaatimuksen rikkominen, järkevän ja oletetun toiminnon rikkominen (kaikkia vaatimuksia ei voi kirjata) ja ehkä jotkut käytettävyysongelmat. 46

47 Ylläpidettävyysvaatimukset Taattu korjausaika on turvallista asiakkaalle mutta toimittajalle riskialtista. Toimittaja voi veloittaa korkeaa hintaa muutoksista: asiakas voi kysyä hintaa muutosyksikköä kohden. Ylläpidon tehokkuus, tuen ominaisuudet ja kehitysprosessin vaatimuksia. Lisäksi tähän liittyen saatetaan esittää tuotteen mutkikkuuden ja tuotteen ominaisuuksien suhteen vaatimuksia. 47