Vaatimustenhallinta
Vaatimusten määrittelyprosessi
Vaatimusmäärittelyn lähtökohdaksi on hanketoimeksiannossa määritelty kehityksen tarve, ongelma tai mahdollisuus sekä muun muassa lakeihin, määräyksiin, arkkitehtuuriin ja teknologioihin perustuvat reunaehdot. Laeista ja määräyksistä tulevat keskeisimmät reunaehtot koskevat tietosuojaa ja tietoturvaa, tiedonhallintaa, riskienhallintaa ja saavutettavuutta.
Iteratiivinen vaatimusten tarkentuminen ja hankinta
Kun hanke on tarkoitus toteuttaa iteratiivisesti on kyse ketterästä toteutuksesta. Tässä mallissa vaatimukset tarkentuvat toteutuksen edetessä ja siksi ratkaisun hankintamalli muuttuu oleellisesti.
Toimittajakandidaateilla ei ole mahdollisuutta tarjota yksityiskohtaisesti, sillä vaatimukset on vielä kuvattu puutteellisesti. Iteratiivinen eteneminen tarkoittaa huolellista ratkaisuvaatimusten pilkkomista vaiheittaisiin toteutuksiin. Ellei kokonaisvaatimuksia kyetä kuvaamaan riittävällä tasolla koko hankkeelle, johtaa se tavanomaisesti peräkkäin pilkottuihin erillisiin kilpailutuksiin tai ainakin hankintoihin. Tästä syystä ketterässä toteutuksessa ostetaan useimmiten työtä ratkaisun sijaan.
Hankintalaki edellyttää jokatapauksessa aina kiinteän hankinnan kohteen määrittämistä, eivätkä tietosuoja- ja tietoturvavaatimukset ole luonteeltaan myöskään iteratiivisia.
Vaatimukset voivat kuitenkin työtä ostettaessa olla ylätasolla ja luonteeltaan linjaavia, jotta niitä voidaan helpommin tarkentaa toteutuksen kuluessa. Samalla tämä tarkoittaa sitä, että hankkeen alussa ei ole tarkasti määriteltyä tavoiteratkaisua tarkkoine vaatimuksineen. Tavoiteratkaisun kuvaus on kuitenkin riittävän ja täsmällinen, jotta hankinnan kohde on selkeä ja yksikäsitteinen sekä tietosuoja ja tietoturva ja saavutettavuusedellytykset on sitovasti täytettävä kyseisten lakien edellyttämällä tavalla.
Periaatteellinen ero iteratiivisen ja vesiputousmallin välillä kulminoituu tähän hankinnan erilaisuuteen.
Iteratiivisella mallilla on hyvin vaikea määrittää vaatimuksia etukäteen niin selkeästi, että hankinta voi päätyä Toimittajaa sitovaan toimituksen sisältöön. Iteratiivista mallia käytetään silloin, kun ratkaisun vaatimuksia ei voi hankintamielessä kuvata tarkasti niin, että ne voidaan kohtuullisella riskillä myös saavuttaa. Tällöin hyötynä on nopeampi toteuttamisen aloittaminen ja haittana vastaavasti heikompi yhteisymmärrys tavoiteltavasta lopputuotoksesta. Silloin riskimielessä on erityinen syy varmistaa tietosuoja ja tietoturva sekä hankintalain mukaisuus.
Iteratiivinen ja ketterä toimintatapa lähtee siitä ajatuksesta, ettei etukäteistä yhteisymmärrystä lopullisesta ratkaisusta ole mahdollista saavuttaa. Iteratiivisessa toimintatavassa yleinen laskutyömalli myös tarkoittaa sitä, ettei Toimittajalla ole vastaavaa sanktioitua ratkaisun toimitusvastuuta kuin kokonais- ja tavoitehintaisissa sopimuksissa perinteisellä tavalla toimien. Hankinnassa korostuvat ratkaisuvaatimusten sijaan yksilöiden osaamisprofiilit.
Iteratiivisesti toteutettavassa perinteisessä hankkeessa vaatimukset kuvataan ns. EPICeinä sekä kokonaisuutta rajaavina tietosuoja- ja tietoturvavaatimuksina ja saavutettavuusvaatimuksina, jotka pilkotaan sprinteissä toteutettaviin käyttäjätarinoihin. Vaatimusten priorisointi ja kehitysjonojen hallinta edellyttää läheistä yhteistyötä palvelusta vastaavan (tuoteomistajan) ja kehitystiimin välillä.
Katso vinkkejä iteratiivisessa vaatimustenhallinnassa käytettävästä työkaluista ketterän toteutuksen vaatimusmäärittelyn kuvauksista.
Kuvauksen tarkkuustaso kasvaa hankkeen edetessä
Kuvauksen tarkkuustaso valitaan tarkoituksenmukaiseksi hankkeen laajuudesta, hankintatavasta, kehitysmenetelmästä ja vaiheesta riippuen.
Toiminnalliset vaatimukset kuvataan käyttötapauksina. Käyttötapauksista kuvataan aina käyttötapauskaavio ja käyttötapauskuvaukset valitulla tarkkuustasolla. Esimerkki käyttötapauskaaviosta:
1. Yleiskuvaustaso
Yleiskuvaustasolla käyttötapaukset on tunnistettu, mutta niiden sisältö esitetään joko nimellä tai muutaman lauseen yleiskuvauksella. Toiminnallisuuden yleiskuvauksen avulla lukija saa järjestelmän toiminnallisuudesta hyvän ja selkeän yleiskuvan. Tässä voidaan viitata prosessiin, jota käyttötapaukset tukevat. Käyttötapaukset voidaan kuvata prosessin mukaisessa järjestyksessä. Yleiskuvaustasolla käyttötapauksen toiminnallisuus kuvataan muutamalla lauseella, jossa kuvataan sen keskeinen toiminnallisuus.
Tämä taso on sopiva valmisteluvaiheessa tehtävään ratkaisun kuvaukseen.
2. Toimintokuvaustaso
Kunkin käyttötapauksen toiminnallisuudesta koostetaan taulukkomuotoinen yhteenveto käyttötapaukset -asiakirjaan. Toimintokuvaustasolla käyttötapauksen toiminnallisuus kuvataan määrittelemällä toiminnot ja niiden vaihtoehtoiset toteutustavat sekä mahdolliset virheet ja poikkeukset.
Tämä taso vaaditaan kilpailutusta varten tehtävissä vaatimusmäärittelydokumenteissa.
3. Tarkka taso
Kuvauksia tarkennetaan tarvittaessa yhteistyössä toimittajan kanssa ennen toteutuksen aloittamista.
Hankkeessa voidaan kuvata osa käyttötapauksista eri tarkkuustasolla, tällöin käytetään yllä kuvattua kuvaustapaa kullakin tarkkuustasolla.
Käyttötapauskuvausten rakenteeseen vaikuttaa ratkaisun koko (tai muut tarpeet). Laaja ratkaisu voidaan kuvata toimintakokonaisuuksin, jolloin kustakin toimintakokonaisuudesta tehdään vaaditut kuvaukset.
Toiminnallisuutta tai käyttötapauksia kuvatessa tulee varmistaa, että
- Käyttötapauskuvauksen yleiskuvaus antaa selkeän ja ymmärrettävän kuvan ratkaisun tai sen osa toiminnallisuudesta
- Käyttötapauskaavio on mukana ja siinä/niissä esitetään kaikki järjestelmän käyttötapaukset
- Ratkaisu on jaettu selkeisiin ja loogisiin kokonaisuuksiin
- Kaikki käyttötapaukset on lueteltu ja (tarvittaessa) kuvattu
Tunnista toimijat
Toimija on henkilö, organisaatio, ulkopuolinen järjestelmä tai laite, joka käyttää määriteltävän ratkaisun palveluja tai tuottaa ratkaisun tarvitsemaa tietoa.
Toimijasta kuvataan seuraavaa:
- mitä tai ketä toimija edustaa
- miksi toimijaa tarvitaan (järjestelmän määrittelyssä, perustelee toimijan olemassaolon)
- mitä toimija tekee/odottaa järjestelmältä
- taitotaso
- lukumäärä
Toimijoita kuvatessasi varmista että…
- olet käyttänyt toimijoiden lähtökohtana esiselvityksessä tunnistettuja ratkaisun sidosryhmiä
- se on nimetty yksikössä, käyttäen toiminnalle tyypillistä termiä/sanaa/kieltä ja että nimi vastaa roolia ja on kuvaava
- se kuvaa roolia, eikä asemaa tai henkilöä
- toimijat on tyypitetty (Käyttäjä, toinen järjestelmä, muu…)
- olet tunnistanut kaikki toimijat (varmista asia vielä kun olet tunnistanut kaikki käyttötapaukset, jokaisella on oikea toimija)
- jokainen toimija käyttää ainakin yhtä käyttötapausta
- useampi toimija ei ole samassa tai samankaltaisessa roolissa suhteessa ratkaisuun (yhdistä tällaiset roolit)
- yksi toimija ei käytä ratkaisua useammalla eri tavalla tai on useampi tarkoitus ratkaisun käyttöön (erota toimija omikseen).
Toimijat voidaan esittää kuvauksissa graafisesti, esim.
