JHS 173 ICT-palvelujen kehittäminen: Vaatimusmäärittely

JHS 173 ICT-palvelujen kehittäminen: Vaatimusmäärittely Versio: 1.1 5.10.2012 Julkaistu: 11.9.2009 Voimassaoloaika: Toistaiseksi Sisällys 1 Johdanto... 2 2 Soveltamisala... 4 3 Termit ja määritelmät... 5 4 Prosessikuvaukset... 8 5 Vaatimusten hallinta... 8 6 Vaatimusten määrittelyn vaiheet... 11 6.1 Valmistautuminen vaatimusten määrittelyyn... 11 6.1.1 Tavoitteiden täsmentäminen... 12 6.1.2 Vaatimusten määrittelyn läpiviennin suunnittelu... 13 6.2 Vaatimusten määrittelyn tuottaminen... 13 6.2.1 Tarpeiden täsmentäminen ja analysointi... 14 6.2.2 Vaatimusten priorisointi... 15 6.3 Vaatimusten määrittelyn hyväksyminen... 15 6.3.1 Vaatimusten katselmointi... 16 6.3.2 Vaatimusten hyväksyminen... 16 7 Vaatimusten määrittelyn roolit... 17 7.1 Tietojärjestelmän omistaja... 17 7.2 Projektipäällikkö/Vaatimusten määrittelyvastaava... 17 7.3 Vaatimusten esittäjät ja kirjoittajat... 17 7.4 Muut asiantuntijat... 17 8 Vaatimusten määrittelyn ositus ja käytännön työskentely... 17 9 Vaatimusten hankintamenetelmiä... 18 9.1 Dokumenttien tutkiminen... 18 9.2 Kyselylomakkeet... 19 9.3 Suullinen kysely... 19 9.4 Suullinen strukturoitu haastattelu... 19 9.5 Suullinen strukturoimaton haastattelu... 19 9.6 Ryhmäpohjaiset tapaamiset... 20 9.6.1 Aivoriihi... 20 9.6.2 Työpaja... 20 10 Hyvän vaatimusilmaisun kriteerit... 20 11 Vaatimusmäärittelyssä tuotettava dokumentaatio... 22 11.1 Vaatimusluettelo ja tunnistetiedot... 22 11.1.1 Vaatimuksen tunnistetieto... 22 1/29

11.1.2 Vaatimuksen esittäjä... 22 11.1.3 Vaatimuksen kriittisyys sen omistajalle... 22 11.1.4 Perustelu... 22 11.1.5 Toimittajan kommentit... 23 11.2 Vanhan järjestelmän tietojen konversiot... 23 11.3 Järjestelmän tietoturvavaatimukset... 23 11.4 Järjestelmän ei-toiminnalliset vaatimukset... 25 11.5 Järjestelmän tekniset reunaehdot... 25 11.6 Sanasto... 25 11.7 Liittymät muihin järjestelmiin... 26 11.8 Käyttäjäroolien kuvaaminen... 26 11.9 Käyttötapausmalli... 26 11.10 Raportit ja tulosteet... 28 12 Opastavat tiedot... 29 13 Liitteet... 29 1 Johdanto Tämän suosituksen tarkoituksena on opastaa tietojärjestelmiä hankkivia organisaatioita järjestelmän hankinnassa antamalla ohjeita ja malleja järjestelmän vaatimusten määrittelemiseksi. Suositus perustuu julkisen sektorin hyviin käytäntöihin ja eri organisaatioiden laatimiin ohjeisiin. Lähdemateriaalina on käytetty mm. Valtiokonttorin ja Puolustusvoimien ohjeistoa. Tämä suositus on osa ICT-palvelujen kehittäminen suositussarjaa. Vaiheena suositus sijoittuu esiselvityksen jälkeen. 2/29

Kuva 1 ICT-palvelujen kehittämisen vaiheet Ennen vaatimusmäärittelyn aloittamista on suositeltavaa, että suosituksissa JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen sekä JHS 172 ICT-palvelujen kehittäminen: Esiselvitys kuvatut tehtävät ja toimenpiteet on suoritettu ja niissä tuotettu dokumentaatio ja muu materiaali on käytettävissä. Tämän suosituksen taustalla on valtiovarainministeriön ValtIT:n laatima kokonaisarkkitehtuurimenetelmä, joka on alun perin tehty kuvaamaan valtionhallinnon kokonaisarkkitehtuurin kuvaamista ja mallintamista. Valtionhallinnon kokonaisarkkitehtuuri on toiminnan prosessien ja palvelujen, tietojen, tietojärjestelmien ja niiden tuottamien palvelujen muodostaman kokonaisuuden rakenne. Valtionhallinnon kokonaisarkkitehtuuri pitää sisällään arkkitehtuurilinjaukset ja -kuvaukset, arkkitehtuurin hallintamallin sekä arkkitehtuurimenetelmän. Suosituksessa on huomioitu lisäksi kuntanäkökulma. Tässä suosituksessa kuvataan oheisen prosessin (kuva 2) kohtaa Vaatimusten hallinta. Kuva 2 Kokonaisarkkitehtuurin suunnitteluprosessi (lähde: ValtIT:n Kokonaisarkkitehtuurimenetelmä) Tietojärjestelmän vaatimusten määrittely ja sen laadukas organisointi on onnistuneen tietojärjestelmän hankinnan perusedellytys. Vaatimusten määrittely on vaativaa, mutta se säästää projektin kuluissa, nopeuttaa hankkeen läpivientiä ja varmistaa vaadittujen ominaisuuksien tuottamisen. Vaatimuksilla viestitään tarjoajille, millaista ratkaisua ollaan hankkimassa. Vaatimusten määrittely luo perustan hankinnalle, se määrittelee miksi ja mitä tarpeita hankinnan tulee tyydyttää. Vaatimusten määrittely tulee tehdä riippumatta siitä, ollaanko hankkimassa standardijärjestelmää, esikonfiguroitua järjestelmäratkaisua, ASP-ratkaisua tai hankkivan organisaation tarpeisiin räätälöityä erikoissovellusta. 3/29

2 Soveltamisala Tässä suosituksessa kuvataan tietojärjestelmän vaatimusten määrittelyn periaatteet ja kuvataan vaatimusten määrittelyssä tuotettavat dokumentit. Suosituksen kohderyhmiä ovat: Tietojärjestelmien omistajat Tietojärjestelmien hankinnasta päättävät tai tietojärjestelmiä hankkivat henkilöt Hankintaa suunnittelevat henkilöt Projektipäälliköt Vaatimusten määrittelyä suorittavat henkilöt 4/29

3 Termit ja määritelmät Arkkitehtuurimalli Arkkitehtuurimalli kuvaa mitä järjestelmään kuuluu ja minkä muiden järjestelmien kanssa järjestelmä toimii yhteistyössä. Arkkitehtuurimallia voidaan käyttää sekä kuvaamaan kehitettävän järjestelmän yhteyksiä ulkomaailmaan että järjestelmän jakautumista osajärjestelmiksi. Asiakas Asiakas tarkoittaa sitä tahoa, joka määrittää järjestelmälle asetettavat vaatimukset. Attribuutti Vaatimuksen ominaisuus (tai lisätieto), joka on hyödyllinen vaatimusten määrittelyssä, lajittelussa, luokittelussa ja/tai vaatimustenhallinnassa. Ei-toiminnalliset vaatimukset Ei-toiminnalliset vaatimukset määrittelevät rajoitukset ja reunaehdot toiminnallisille vaatimuksille. Eitoiminnalliset vaatimukset eivät liity suoraan palveluihin vaan kertovat, mitä ehtoja järjestelmän on täytettävä, jotta toiminnalliset vaatimukset voidaan toteuttaa. Elinkaari Järjestelmän olemassaolon kestoaika: ajanjakso järjestelmän ensimmäisen vaatimuksen määrittelystä järjestelmän käytöstä poistoon. Järjestelmä (system) Järjestelmä koostuu osista, joilla on keskinäisiä yhteyksiä ja yhteyksiä muihin kohteisiin eli järjestelmän ympäristöön; järjestelmällä on siis koostumus ja rakenne; osat (komponentit) ovat kaikki joko konkreettisia tai käsitteitä. Esim. tavara, kone, yhteisö, yhdyskunta; käsitemalli. Järjestelmävaatimus Ilmaisee mitä, millä ehdoin ja kuinka hyvin järjestelmän on tehtävä (jotain) tai millainen sen on oltava (reunaehto) sidosryhmien tarpeiden tyydyttämiseksi. Järjestelmämalli Järjestelmämalli on graafinen kuvaus, joka voi kuvata kehitettävää järjestelmää tai tuotteeseen liittyvät (liike)toimintaprosessit. Katselmointi Vaatimusten laadun varmistamista lukemalla, analysoimalla, puutteita tunnistamalla sekä keskustelemalla niistä ja sopimalla toimenpiteistä tunnistettujen puutteiden poistamiseksi. Konfigurointi Konfigurointi tarkoittaa tyypillisesti modulaarisen tuotteen toimitettavien moduulien valintaa sekä sovelluksen virittämistä asiakkaan tarpeisiin parametroinnin avulla. Konversio Konversio tai konvertointi on tiedon muuttamista toiseen käyttötarkoitukseen tai toiseen tekniseen ympäristöön - yleensä vanhasta uuteen järjestelmään - kelpaavaan muotoon. Käsitemalli Käsitemalli kuvaa määriteltävän kohteen keskeiset toimijat tai tietosisällöt. Luokkamalli on yksi käsitemallin esitystapa ja se koostuu tekstistä ja luokkakaaviosta. Luokkakaaviossa käytetään UML-notaatiota. Käytettävyys käytettävyysmitta, miten hyvin määrätyt käyttäjät voivat käyttää tuotetta tietyssä käyttötilanteessa saavuttaakseen määritetyt tavoitteet tuloksellisesti, tehokkaasti ja tyytyväisinä. 5/29

Käyttäjä Yksilö tai ryhmä, joka (päivittäin) käyttää järjestelmää sen oikeassa käyttöympäristössä, Käyttäjävaatimus (sidosryhmävaatimus) Määrämuotoinen ilmaisu siitä mitä, kuinka hyvin ja millä rajoituksin käyttäjä (tai muu sidosryhmä) haluaa järjestelmällä tehdä tai aikaansaada, tai mitä ominaisuuksia järjestelmän on omattava. Vaatimuksella on varottava ilmaisemasta erityistä ratkaisua tarpeeseen tai ongelmaan. Käyttöliittymä Ohjelman tai laitteen osat, joiden kautta käyttäjä seuraa ja ohjaa ohjelman tai laitteen toimintaa ja saa tietoa toiminnasta. Käyttötapaus Käyttötapaus kuvaa käyttäjän ja järjestelmän tai kahden järjestelmän välistä vuorovaikutusta sarjana toimintoja, joita toimija (ihminen tai järjestelmä tai sen osa) suorittaa tai aikaansaa järjestelmällä jonkin tavoitteen saavuttamiseksi. Käyttötilanne Käyttäjät, tehtävät, laitteet (laitteisto, ohjelmisto ja aineistot) sekä fyysinen ja sosiaalinen ympäristö, jossa tuotetta käytetään. Käyttöympäristö Laite tai käyttöjärjestelmä, jossa ohjelmisto toimii. Laatu Tuotteen tai prosessin [ominaisuuksien ja yhteyksien] ja siihen kohdistuvien [sidosryhmien] vaatimusten suhde. Laatu = vaatimustenmukaisuus. Priorisointi Asian tärkeysjärjestykseen asettaminen Rajapinta Standardin mukainen käytäntö tai yhtymäkohta, joka mahdollistaa tietojen siirron laitteiden, ohjelmien tai käyttäjän välillä. Rajoitus Vaatimus, joka selkeästi ja tarkoituksella rajoittaa järjestelmän suunnittelua, toteutusta, käyttöä, elinkaarta tai päätöksentekoa joko suorasti tai epäsuorasti (synonyymi: reunaehto). Saavutettavuus Ominaisuus, joka ilmentää sitä, kuinka helposti henkilö voi saada järjestelmän, laitteen, ohjelman tai palvelun käyttöönsä. Saatavuus Saatavuus määrittelee, onko tieto saatavilla käyttötarkoituksen mukaisesti. Sidosryhmä Yksilö, ryhmä tai organisaatio, jolla on jokin intressi järjestelmän suhteen tai vaatimuksia järjestelmälle, tai johon järjestelmä vaikuttaa jollain tavalla joskus sen elinkaaren aikana. Tahot tai osapuolet, jotka määrittävät järjestelmälle asetettavat vaatimukset. Sidosryhmät voivat olla sisäisiä tai ulkoisia. Esimerkiksi käyttäjät muodostavat sisäisen sidosryhmän. Lakien ja asetusten säätäjät edustavat ulkoista sidosryhmää. Skenaario Sanallinen tapahtumakuvaus järjestelmän käytöstä. Se kattaa sekä normaalin, suunnitellun käytön että poikkeustilanteet. 6/29

Tarkastus Tarkastus on kokous, jossa tarkastetaan jonkin työvaiheen tuotos tai osa siitä, ja yritetään löytää siitä puutteita ja virheitä. Tarve Sidosryhmän kokema kapasiteettipuutos, joka on ilmaistu tarpeena, vaatimuksena tai velvoitteena tehdä/saada aikaan jotakin Vaatimus Ilmaisu, joka kuvaa kohteelta odotettua kyvykkyyttä, ominaisuutta tai laatua ja josta on hyötyä tai jolla on arvoa sen esittäjälle Tarveilmaisu Tarpeen, toiveen, odotuksen, velvoitteen tai mahdollisuuden ilmaisu. Testaus Prosessi etukäteen määritettyjen vaatimusten täyttymisen osoittamiseksi ja mahdollisten virheiden löytämiseksi. Vaatimukset voivat olla joko käyttäjä- tai järjestelmävaatimuksia. Testaus on yleisnimitys sekä todentamiseen että kelpuutukseen liittyvistä toimenpiteistä vaatimustenmukaisuuden osoittamiseksi. Tietovuokaavio Tietovuokaavio kuvaa järjestelmän toiminnan yksityiskohtia. Malli kuvaa prosessit (tehtävät), prosessien välillä kulkevat syötteet ja tulosteet sekä mahdolliset tieto- ja materiavarastot. Toimija Toimija tai rooli liittyy yhteen tai useampaan käyttötapaukseen ja yhteen käyttötapaukseen liittyy yksi tai useampi toimija. Yksi henkilö voi olla useassa eri roolissa eli useana eri toimijana käyttötapauksessa. Todentaminen Prosessi, jolla varmistetaan, että järjestelmä tai ratkaisu täyttää järjestelmävaatimukset (verification). Toiminnallinen vaatimus Vaatimus, joka määrittelee kehitettävän tai hankittavan järjestelmän käyttäytymistä tai toiminnallisuutta. Toiminnalliset vaatimukset määrittelevät, mitä palveluja ohjelmiston on tarjottava, miten ohjelmisto reagoi syötteisiin ja miten se käyttäytyy annetuissa tilanteissa. Voi olla joko käyttäjä- tai järjestelmävaatimus. Ulkoinen vaatimus (liityntävaatimus) Vaatimus, joka liittyy järjestelmän ulkoisiin liityntöihin (fyysiset liitynnät muihin järjestelmiin). UML UML-mallinnus (engl. Unified Modeling Language) on Object Management Groupin (OMG) vuonna 1997 standardoima graafinen mallinnuskieli, joka sisältää 13 erilaista kaaviota. Kaavioista kuudella kuvataan rakennetta, kolmella käyttäytymistä ja neljällä vuorovaikutusta. UML on alun perin kehitetty järjestelmä- ja ohjelmistokehitystä varten. Se syntyi yhdistämällä kolme johtavaa oliomallinnustekniikkaa (OMT, Booch, OOSE). Uusin UML-standardi on 2.0 vuodelta 2004. Vaatimusten määrittely Prosessi vaatimusten määrittelemiseksi ja dokumentoimiseksi. Vaatimusten määrittelyn tavoitteena on selvittää ohjelmistolle asetettavat vaatimukset sellaisella tarkkuudella, että niiden perusteella voidaan kommunikoida eri osapuolille, millainen ohjelmiston halutaan olevan. Vaatimustenhallinta (requirements management, RM) Vaatimustenhallinta sisältää seuraavat osa-alueet: 1) Vaatimusten kokoaminen ja yhdistäminen useista erillisistä lähteistä, kuten järjestelmän omistajat, käyttäjät, olemassa olevat standardit, organisaation toimintalinjaukset, kansalliset ja monikansalliset lait ja määräykset. 2) Kerättyjen vaatimusten analysointi ja muokkaaminen yhtenäiseksi vaatimusdokumentiksi, joka muodostaa hankkeelle yhtenäisen lähtökohdan. 3) 7/29

Ratkaisua vaativien vaatimusten tunnistaminen, mitkä vaatimukset edellyttävät tarkentamista tai jatkomäärittelyä esimerkiksi kustannus-hyöty-tarkastelun vuoksi. 4) Vaatimusten dokumentointi ja ylläpito koko järjestelmän elinkaaren ajan. Ympäristövaatimukset Ympäristövaatimukset (domain requirements) ovat vaatimuksia, joiden lähtökohtana on ohjelmistoa ympäröivä toimintaympäristö käyttäjien sijaan. 4 Prosessikuvaukset Hankittavaan tai uudistettavaan järjestelmään liittyvien prosessikuvausten tulisi olla tehtyinä riittävällä tasolla ennen esiselvitystä ja vaatimusmäärittelyä. Riittävällä tasolla tarkoitetaan tasoa, josta käy selkeästi ilmi kokonaiskuva prosessin kulusta, osa-puolista sekä siinä käytettävistä järjestelmistä. Yleensä suosituksessa JHS 152 Prosessien kuvaaminen kuvatut tasot 2 ja 3 riittävät. 5 Vaatimusten hallinta Vaatimusten määrittely ja hallinta on järjestelmällinen menettelytapa, jolla pyritään varmistumaan siitä, että järjestelmä tai palvelu, jota ollaan hankkimassa, vastaa sille asetettuja vaatimuksia. Vaatimusten määrittely on osa vaatimustenhallintaa. Aikajänne vaatimusten määrittelystä käyttöönottoon saattaa olla useita vuosia. Vaatimusten määrittely alkaa jo kehittämiskohteiden tunnistamisvaiheessa (kts. JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen) tarpeiden keräämisellä ja kerättyjä tarpeita muokataan vaatimuksiksi läpi koko ICT-palvelujen kehittämisen ajan. Hyvä vaatimusten määrittely mahdollistaa paitsi onnistuneen kilpailutuksen ja hankinnan niin se myös varmistaa, että järjestelmää käyttöönotettaessa voidaan todentaa, että toimittajan kanssa sovitut järjestelmän ominaisuudet toteuttavat vaaditut määrittelyt. 8/29

Kuva 3 Vaatimusten hallinta tietojärjestelmän hankinnan eri vaiheissa Riittämätön vaatimusten määrittely on yleisin yksittäinen syy ohjelmistoprojektien epäonnistumiseen. Joidenkin tutkimusten mukaan vaatimusten määrittely on puutteellinen yli 75 prosentissa kaikista epäonnistuneista projekteista. Syitä vaatimusten määrittelyn epäonnistumiseen on monia. Vaatimusten kerääjät ja käyttäjät eivät aina ymmärrä toisiaan, tilaaja on yleensä eri kuin varsinaiset loppukäyttäjät ja 9/29

tilaajan käsitys saattaa poiketa todellisten loppukäyttäjien vaatimuksista. Menetelmät vaatimusten keräämiseen ja dokumentointiin voivat olla puutteellisia ja mikäli määrittelyä ei suunnitella projektina, resurssit saatetaan mitoittaa alakanttiin. Hankintatarpeen kartoituksessa ja hankinnan suunnitteluvaiheeseen liittyvässä esiselvityksessä on päätetty (JHS 172 ICT-palvelujen kehittäminen: Esiselvitys) hankintatapa (oma järjestelmä, sovellusvuokraus, ratkaisun hankkiminen palveluna). Jos esiselvityksessä on päädytty ratkaisun hankintaan palveluna, esiselvitysvaiheessa on myös päätetty, miten palveluhankinnan vaatimusten määrittely laaditaan tarjouspyyntöä varten. Tämän suosituksen lähtökohtana on, että organisaatio on arvioinut investoinnin kustannukset ja suorittanut investointivarauksen järjestelmän hankkimiseksi. Vaatimusten määrittelydokumentit ovat tilaajan ja toimittajan välisen kommunikoinnin kivijalka. Mitä selkeämmin ja kattavammin vaatimukset ilmaistaan, sitä riskittömämmäksi järjestelmän valinta ja käyttöönotto muodostuu. Vaatimusten määrittelyn syvyys ja rooli vaihtelee hankittavan järjestelmän mukaan. Vaatimukset voidaan jakaa kolmeen ryhmään: Toimintalähtöiset vaatimukset. Käyttäjävaatimukset. Järjestelmän toiminnalliset ja ei-toiminnalliset vaatimukset. Kuva 4 Vaatimusryhmät ja niiden hierarkia Toimintalähtöiset vaatimukset esittävät korkean tason tavoitteita, joita organisaatio pyrkii saavuttamaan ohjelmiston tai järjestelmän tuella. Toimintalähtöiset vaatimukset perustuvat usein toimintaprosesseihin, joiden avulla määritellään haluttu tavoitetila. Tällaiset toimintalähtöiset vaatimukset dokumentoidaan projektin vision ja laajuuden avulla. Visio voi olla esimerkiksi Saumaton hoitoketju. Käyttäjävaatimukset kuvaavat toimia, joita käyttäjien tulee kyetä toteuttamaan järjestelmää tai ohjelmistotuotetta hyväksikäyttäen. Käyttäjävaatimukset kuvataan käyttötapauksina, toteutuneiden esimerkkien avulla tai käyttäen skenaarioita. Käyttäjävaatimuksia voi nimittää myös tarpeiden tunnistukseksi, jossa nykytilan ongelmat analysoidaan. Esiselvityksessä tehty nykytilan analysointi ja kehitystarpeiden listaus muodostavat hyvän perustan käyttäjävaatimusten laadinnalle. Mikäli nykytilan ongelmien tunnistaminen ja kehitystarpeiden analysointi 10/29

jätetään vaatimusten määrittelyvaiheessa tehtäväksi, tämä yleensä venyttää määrittelyn suorittamista ja hidastaa vaatimusten sisäistä priorisointia ja hyväksymistä. Määrittelyn sijasta työstä muodostuukin tavoitetilan toiminnan kehittämisprojekti. Järjestelmän toiminnalliset vaatimukset määrittelevät ohjelmiston toiminnallisuuden, jonka ohjelmiston kehittäjien tulee luoda järjestelmään. Toiminnallisten vaatimusten määritteleminen synnyttää täsmennetyt vaatimukset. Toiminnallisten vaatimusten tarkoituksena on luoda edellytykset käyttäjille, jotta he kykenevät suoriutumaan vaadituista tehtävistä. Ei-toiminnalliset vaatimukset määrittelevät järjestelmälle sen toiminnalle asetettavia toiminnallisuuksiin sitomattomat vaatimukset, kuten esimerkiksi käytettävyyteen, luotettavuuteen ja tietoturvallisuuteen liittyvät vaatimukset. Vaatimuksissa on kyettävä hahmottamaan tulevaisuuden tarpeet. Kaikki ne toiminnallisuudet, joiden halutaan sisältyvän järjestelmään, on kuvattava esitettävä vaatimuksina. Mikäli esimerkiksi sähköinen allekirjoitus on tarkoitus ottaa käyttöön kaksi vuotta käyttöönoton jälkeen, tämä on hyvä huomioida vaatimuksia määriteltäessä. 6 Vaatimusten määrittelyn vaiheet 6.1 Valmistautuminen vaatimusten määrittelyyn Tietojärjestelmähankkeesta päätettäessä hankintaa suorittavalla organisaatiolla täytyy olla selkeä käsitys siitä, mihin järjestelmää tarvitaan. Näkemys on voinut syntyä esiselvityksen puitteissa. Useimmiten alkuvaiheessa tunnistetut tarpeet eivät ole niin selkeitä, että ne voitaisiin vain kerätä yhteen vaatimuksiksi. Kehittämiskohteiden tunnistamisvaiheessa tunnistetut tarpeet ja esiselvitysvaiheessa niistä tarkennetut korkean tason vaatimukset eli käyttäjävaatimukset ovat hyvä lähtökohta varsinaiselle vaatimusten määrittelylle. Korkean tason vaatimusilmaisu voi olla esimerkiksi, että järjestelmän on mahdollistettava ajasta ja paikasta riippumaton työskentely. Kuva 5 Valmistautuminen vaatimusten määrittelyyn Vaatimusten määrittelyprosessi koostuu valmistautumis-, tuottamis- ja hyväksymisvaiheista. Prosessin vaiheita on havainnollistettu alla olevassa kuvassa. Ennen vaatimusten määrittelyä suoritettavien kehittämiskohteiden tunnistamis- sekä esiselvitysvaiheiden tehtävänä on tuottaa tietoa tietojärjestelmän kehittämisestä päättäville sekä määrittää lähtökohdat mahdolliselle tietojärjestelmän hankinnalle. Edellä 11/29

mainittujen vaiheiden perusteella on jo kuvattu esimerkiksi organisaation kehittämishanketta koskeva nykytilanne sekä ongelmat, joihin haetaan ratkaisua. Vaatimusten määrittelyyn valmistautuminen jakautuu yleensä tavoitteiden täsmentämiseen ja läpiviennin suunnitteluun. Vaatimusten määrittelyprosessi voi saada alkunsa tietojärjestelmätutkimuksesta, varsinkin jos kyseessä on vanhan tietojärjestelmän kehittäminen tai ongelmien kartoitus. Vaatimusten määrittely voi myös saada alkunsa liiketoiminnan kehittämistyöstä ja sen kuluessa tehdystä toiminnan tavoiteprosessien kuvauksesta. Ennen vaatimusten määrittelyn alkamista kootaan esiselvityksessä ja kehittämiskohteiden tunnistamisen yhteydessä tehdyt asiakirjat, käydään ne läpi ja tunnistetaan päivitystarpeet. Lähtötietoina määrittelylle käytetään kehittämiskohteiden tunnistamisvaiheessa tehtyjä asiakirjoja ja määrittelyitä sekä mahdollisia muita dokumentteja, joita voivat olla hankkeen asettamisasiakirja liitteineen, vaatimusten määritysprojektin asettamisasiakirja sekä hankesuunnitelma. Asiakirjoja ovat mm. strategiset vaatimukset ja tavoitteet nykytilan ja tavoitetilan prosessikuvaukset tavoiteratkaisun kuvaukset tarveluettelo organisaation ja sidosryhmien kuvaukset Jos esiselvitystä ei ole tehty, on siihen kuuluneet tehtävät suoritettava vaatimusten määrittelyn alussa, jotta saadaan riittävä pohja vaatimusten määrittelyn aloittamiseksi. Projektin tai järjestelmän omistajan ja projektipäällikön on päätettävä ja sovittava esimerkiksi organisaation osto-osaston kanssa, mitkä kaikki asiakirjat ja dokumentit vaatimusten määrittelyssä tuotetaan. Työn laajuuteen ja syvyyteen vaikuttaa luonnollisesti erittäin paljon se, onko kyseessä räätälöidyn järjestelmän, sovellusvuokrauksen (ASP) vai valmisohjelmiston vaatimusten määrittely. Lisäksi on huomioitava lainsäädännön mahdollisesti asettamat vaatimukset tulevalle tietojärjestelmälle tai sen toiminnallisuuksille ennen kuin määrittely aloitetaan. 6.1.1 Tavoitteiden täsmentäminen Tavoitteiden täsmentämisen tehtävänä on tarkentaa vaatimusten määrittelyyn vaikuttavia tekijöitä. Näitä voivat olla esimerkiksi lainsäädännön määräämä toteutusajankohta, vaatimusten määrittelyn käyttöön suunnitellut henkilöresurssit ja heidän osaamisensa ja muiden käynnissä olevien kehityshankkeiden sanelemat ehdot. Vaatimusten määrittelyyn valmistauduttaessa on tärkeää sopia erityisesti työn tavoitteista ja lähtökohdista, tavoiteltavista tuloksista ja niiden hyväksymiskriteereistä, dokumenttien hyväksyjistä, käytössä olevista henkilö ja muista resursseista sekä muista vaatimusten määrittelytyön läpiviennin näkökohdista. 12/29

Kuva 6 Tarpeita ja vaatimuksia voidaan johtaa useilta eri alueilta. 6.1.2 Vaatimusten määrittelyn läpiviennin suunnittelu Vaatimusten määrittelyn suunnittelun tuloksena syntyy suunnitelma, miten vaatimusten määrittely tullaan toteuttamaan, milloin määrittely tapahtuu ja keiden toimesta. Vaatimusten määrittely kannattaa suunnitella ja toteuttaa projektina. Suunniteltaessa määrittelyn läpivienti projektina, kaikki tarvittavat osatehtävät tulevat tunnistetuiksi, mikä auttaa realistisen työsuunnitelman laadinnassa sekä auttaa arvioimaan työn vaatimat resurssit. Projektisuunnitelman laadinnan yhtenä lähtökohtana ovat esiselvitysraportissa tai hankesuunnitelmassa luetellut rajoitteet, jotka koskevat esim. henkilöresursseja, kustannuksia tai aikataulua. Erityisesti vaatimusten määrittelyprojektissa pitää tavoitteiden täsmentämisen jälkeen tehdä henkilöresurssien käytöstä sopimukset, jotta vaatimusten määrittelytyö pystytään suunnittelemaan ja toteuttamaan. Suunnittelun lopputuloksena valmistuu projektisuunnitelma. 6.2 Vaatimusten määrittelyn tuottaminen Vaatimusten määrittelyn tärkeimpänä lopputuloksena tulee olla eri osapuolien aito ja yhteinen ymmärrys hankittavan tietojärjestelmän tulevasta toiminnasta. Tämä vaihe vaatii eri osapuolten välillä sovittelua ja kompromissien hakua usein ristiriitaisten intressien aika-, rahoitus- ja/tai esimerkiksi työvoimapulan takia. Ylimmän johdon sitouttaminen hankkeeseen ja resurssien varmistamiseen on ratkaisevan tärkeää. Ilman sitä eri osapuolten välinen sovittelu ei riitä. 13/29

Kuva 7 Vaatimusten määrittelyn tuottaminen Vaatimusten määrittelyyn kannattaa ottaa mukaan mahdollisuuksien mukaan järjestelmän nykyisiä käyttäjiä, sillä he ovat toiminnan parhaita asiantuntijoita. Järjestelmästä riippuen työskentelyyn kannattaa kutsua eri alueiden erityisasiantuntijoita. Esimerkiksi asiakirjahallinnolla on keskeinen merkitys tehokkaampien ja taloudellisempien asiankäsittelyprosessien aikaansaamisessa. Samalla tietojärjestelmän vaatimusten määrittelyssä tulee otettua huomioon asiakirjahallintoon liittyvän lainsäädännön asettamat vaatimukset, kuten tietojärjestelmässä käsiteltävän ja säilytettävän tiedon hävittäminen. Toiminnallisuusvaatimukset kuvataan ensisijaisesti toimintaprosesseina (kokonaisuuksien hahmottamiseksi) ja käyttötapauksina (toimintojen hahmottamiseksi) siten, että keskeiset käyttötilanteet kuvataan. Myös keskeiset vaativat käsittely- ja laskusäännöt on syytä kuvata. Tällaisia ovat esimerkiksi energialaskuihin liittyvät PRODAT-sanomat ja erilaiset sähköiseen maksamiseen ja allekirjoitukseen liittyvät tilanteet. Käyttäjät eritellään käyttäjäryhminä ja niiden rooleina esimerkiksi työnkuvan, käyttöoikeuksien tai käytön laajuuden mukaan. Käytön laajuutta kuvaavilla volyymitiedoilla ja frekvenssitiedoilla ja näköpiirissä olevilla kasvuennusteilla kuvataan nykytoimintaa ja tulevaa kehitystä. Näitä voivat olla esimerkiksi tietomäärät, tapahtumamäärät ja käyttäjämäärät, mielellään nykytilassa että jollain tulevaisuuden ajanhetkellä (esim. 5 vuotta eteenpäin) arvioituna. Tietosisältö kuvataan niiltä osin kuin sitä on määritelty, yleensä vähintään tietokokonaisuuksittain. Käsitemalli on riittävä kuvauksen taso. Hankittavan järjestelmän liittymät ja integrointi muihin jo olemassa oleviin järjestelmiin, kehitteillä oleviin tai tuleviin järjestelmiin esitetään kokonaiskaaviona. Liittymien luonne, toiminnallisuus, volyymit ja tietosisältö kuvataan olennaisilta osiltaan. Projektin ennustettavuus riippuu toiminnallisten määrittelyjen tasosta. Perusteellisen ja kattavan käyttötapausten kuvauksen lisäksi tulisi olla käytettävissä ainakin käsitemalli ja kuvaus järjestelmän ulkoisista yhteyksistä. 6.2.1 Tarpeiden täsmentäminen ja analysointi Tarpeiden täsmennys ja esimerkiksi käytössä olevan tietojärjestelmän kehitystarpeet tunnistetaan joko esiselvitysvaiheessa tai vaatimusten määrittelyjen alussa. Esiselvityksessä tuotetut toiminnallisuuden kuvaukset ovat tietojärjestelmään kohdistuvia piirteitä, vaatimuksia ja ongelmia. Niitä kutsutaan yhteisellä nimellä toiminnoiksi, koska niiden erottaminen toisistaan voi olla välillä hankalaa. Lisäksi esiselvityksessä on kuvattu ei-toiminnallisia vaatimuksia ja rajoitteita. Tässä vaiheessa on hyvä rajata vaatimusten määrittelyn kohdealue ja päättää, mihin sovelluksiin tai prosessialueisiin tietojärjestelmän hankinta ja sen myötä vaatimusten määrittely kohdistetaan. Tarpeiden analysoinnin jälkeen vaatimusten määrittelyn lähtökohtina ovat priorisoidut toiminnot. Yleensä kaikkia toimintoja, tarpeita ja vaatimuksia ei voida 14/29

toteuttaa eikä kaikkia ongelmia voida ratkaista. Rajoitteet ovat seikkoja, jotka on otettava aina huomioon tietojärjestelmähankkeen kaikissa vaiheissa myös vaatimusten määrittelykuvausten tekemisen suunnittelussa. 6.2.2 Vaatimusten priorisointi Vaatimusten priorisointi on keskeinen tapa hallita järjestelmän hankintaan tarjolla olevaa aikaa, rahaa ja ominaisuuksia. Tärkeimmät ominaisuudet ovat korkealla prioriteetilla, jotta niiden toteutumisesta varmistutaan projektin aikaisessa vaiheessa. Tärkeysjärjestyksen ohella tärkeää on ymmärtää vaatimusten alkuperä ja onko kyseessä esimerkiksi käytettävyysparannus tai toiminnalle välttämätön ominaisuus. Vaatimusten priorisoinnissa kannattaa pitäytyä 3-tasoisessa priorisoinnissa (ks. kappale 11.1.3). Vaatimusten ilmaisijoiden ja kirjoittajien on hyödyllistä ymmärtää, että kaikki vaatimukset eivät voi olla pakollisia. Mikäli laitetaan pakollisiksi vaatimuksiksi sellaisia, joiden kohdalla se ei olisi tarpeellista, saatetaan hankintavaiheessa tarpeettomasti sulkea osa toimittajia pois kilpailutuksesta. Lisäksi on hyvä ymmärtää, että kaikilla vaatimuksilla on hintalappu. Luokitellut ja yksilöidyt vaatimukset edustavat jäsennettyä tietomassaa, joka on kooste kaikkien sidosryhmien vaatimuksista. Priorisointi perustuu vaatimuksen tarkasteluun liiketoiminnan kannalta. Priorisoidut vaatimukset toimivat apuna kun päätetään, mitkä ominaisuudet halutaan mukaan hankittavaan ohjelmistoversioon ja mitkä voidaan jättää toteutettavaksi myöhemmin. Priorisoinnista on hyötyä myös silloin, kun taloudellisten tai aikataulupaineiden takia joudutaan karsimaan toteutettavia ominaisuuksia. Vaatimusten priorisointitapa ja osallistujat on syytä suunnitella projektin alussa. Yleensä vaatimusten esittäjät (omistajat) ovat määrittelyn kohteena olevan alueen prosessinomistajia tai pääkäyttäjiä ja heillä on näkemystä suorittaa priorisointi oikein. Mikäli jo priorisoidun vaatimuksen tärkeyttä halutaan muuttaa, tästä on syytä keskustella vaatimuksen esittäjän kanssa perustellen tarve priorisoinnin muuttamiseen. 6.3 Vaatimusten määrittelyn hyväksyminen Vaatimusten hyväksymisen tarkoitus on varmistaa vaatimusten oikeellisuus ja muu laatu. Vaatimusten määrittelykuvausten hyväksyminen jakautuu kahteen osaan: vaatimusten katselmointiin ja hyväksymiseen. Kuva 8 Vaatimusten määrittelyn hyväksyminen 15/29

6.3.1 Vaatimusten katselmointi Vaatimusten hyväksymisessä käytetään apuna katselmointeja. Katselmointitilaisuuden puheenjohtajan on hyvä olla ulkopuolinen henkilö. Hänen ei tarvitse olla sisällön tuntija. Puheenjohtajan tehtävänä on huolehtia siitä, että katselmointitilaisuus etenee sujuvasti, eikä tilaisuudessa ryhdytä ratkomaan ongelmia ja virheitä. Tilaisuudesta laaditaan pöytäkirja, josta selviävät läpikäydyt asiat, läsnäolijat, sovitut muutokset, muutosten aikataulu ja vastuuhenkilö sekä katselmoinnin tulos. Katselmuksen merkitys on moninainen. Järjestelmän hankinnan kannalta se mahdollistaa etenemisen asianmukaisen valvonnan ja ohjauksen sekä ulkoisen laadunvarmistuksen. Lisäksi tietojärjestelmä-hankinnan keskeiset omistajat saavat tietoa hankkeen etenemisestä. Merkittävää on, että katselmuksessa varmistutaan siitä, että siihen mennessä tehty työ vastaa asiakkaan näkemyksiä ja tarpeita. Kuva 9 Vaatimusten katselmointi Hyvin järjestettynä katselmuksessa kyetään hyödyntämään asiakkaan osaamista virheellisten vaatimusten havaitsemiseksi ja korjaamiseksi sekä saadaan asiakkaan hyväksyntä tehdylle työlle ja lupa jatkaa hanketta katselmuksessa mahdollisesti sovituin korjauksin ja tarkennuksin. Lisäksi hankkeen tekemien vaatimusdokumenttien ja suunnitelmien hyväksyntä katselmoinnissa sitouttaa asiakkaat ja sidosryhmät vaatimuksista johtuviin seurannaisvaikutuksiin, kuten resurssitarpeisiin, ennen kaikkea henkilöstöön ja varoihin. Edellä kuvattujen seikkojen vuoksi katselmukseen tulisi saada mahdollisimman laaja osanotto asiakas- ja sidosryhmistä. Vaatimusdokumentin katselmoinnissa keskitytään tarkastelemaan vaatimusten: 6.3.2 Ymmärrettävyyttä: kaikki vaatimuskatselmukseen osallistuvat ymmärtävät vaatimuksen sisällön ja merkityksen. Oikeellisuutta: kaikki katselmukseen osallistuvat näkevät vaatimuksen oikeaksi. Riittävää tarkkuutta ja riippumattomuutta: vaatimusta ei tarvitse tarkentaa eikä se viittaa johonkin standardiin tai muuhun dokumenttiin, joka ei ole osa vaatimusdokumentaatiota. Vaatimusten hyväksyminen Katselmoinnissa hyväksyttyjen vaatimusten määrittelyasiakirjojen lopullisen hyväksymisen tekee projektin ohjausryhmässä puheenjohtaja/tietojärjestelmän omistaja, jolle on annettu valtuudet hyväksyä tai hylätä vaatimusmäärittely. Vaatimusten määrittelyn projektipäällikkö valmistelee päätösesityksen vaatimusmäärittelyn hyväksymisestä päätöksentekijälle. Päätöksentekijä (järjestelmän omistaja tai hänen edustajansa) hyväksyy vaatimusmäärittelyn, keskeyttää sen tai palauttaa sen takaisin vaatimusmäärittelyn laatimisprosessiin viimeisteltäväksi, täydennettäväksi tai korjattavaksi päätöstilanteessa käsitellyin evästyksin. Hyväksytystä vaatimusmäärittelystä on lopputuloksena vaatimusmäärittely, jolle annetaan versionumero 1.0. Tätä kutsutaan myös ns. baseline-dokumentiksi, jolla vaatimukset vakiinnutetaan sille tasolle, joka on 16/29

tarjouspyynnön pohjana. Päätöksestä tiedotetaan sidosryhmille. Myös vaatimusten määrittelytyöhön palautetusta vaatimusmäärittelystä tiedotetaan, mikäli sillä on vaikutuksia esimerkiksi aikatauluun tai kustannuksiin. 7 Vaatimusten määrittelyn roolit Vaatimusten määrittely suoritetaan yleensä projektina, johon osallistuvat kootaan linjaorganisaatioiden asiantuntijoista. Keskeiset roolit vaatimusten määrittelyssä ovat tällöin projektipäällikkö, järjestelmän omistaja, prosessien omistajat, toimialojen/yksiköiden asiantuntijat, tietohallinnon suunnittelijat ja tarvittaessa ulkopuoliset asiantuntijat. Vaatimusten määrittelyyn osallistuvan ryhmän kokoonpanon suuruuteen ja laajuuteen vaikuttaa, onko kysymyksessä kokonaan räätälöity tietojärjestelmä, valmisohjelmisto vai ASP- sovellus. 7.1 Tietojärjestelmän omistaja Tietojärjestelmän vaatimusten määrittelyprojektista vastaa tietojärjestelmän omistaja. Omistaja on se, jolla on korkeimmat ja määräävimmät vaatimukset. Tämä henkilö yleensä myös asettaa vaatimusten määrittelyprojektin. Omistaja voi olla myös muu asettajan valtuuttama esimies. Järjestelmän omistaja vastaa vaatimusten määrittelytyön ohjauksesta ja valvonnasta sekä määrittelykuvauksien hyväksymisestä. 7.2 Projektipäällikkö/Vaatimusten määrittelyvastaava Projektipäällikkö vastaa kokonaisuutena vaatimusten määrittelystä, projektin osituksesta, resursoinnista sekä viestinnästä ja yhteydenpidosta eri sidosryhmiin. 7.3 Vaatimusten esittäjät ja kirjoittajat Vaatimusten esittäjien, kirjoittajien ja kokoajien on tunnettava oma organisaationsa; sen tehtävä, rooli, rakenne ja toiminta. Heidän on tunnettava kyseessä oleva hanke kokonaisuutena ja nähtävä myös muiden hankkeeseen osallistuvien tahojen rooli ja merkitys hankkeelle. Heidän on tunnettava järjestelmän osa-alueet riittävässä määrin, jotta he osaavat hahmottaa kokonaisuuden sekä kyettävä opponoimaan ja tukemaan muita vaatimusten kirjoittajia sekä etsittävä omien vaatimustensa koeponnistamiseen sellaisia henkilöitä, jotka kykenevät vastaavasti auttamaan vaatimusten tarkastamisessa ja kehittämisessä. 7.4 Muut asiantuntijat Toimialan asiantuntijat (toiminnan hyvin tuntevat käyttäjät) vastaavat halutun toiminnallisuuden kuvaamisesta (suullisesti ja/tai kirjallisesti) sekä ei-toiminnallisten ominaisuuksien kuvaamisesta (suullisesti ja/tai kirjallisesti). Tietohallinnon asiantuntija vastaa toiminnallisuuden standardin mukaisesta kuvaamisesta (esim. UML) yhdessä toimialan asiantuntijan kanssa (lomakepohjien täyttö tai ainakin niiden viimeistely) sekä ei-toiminnallisten ominaisuuksien kuvaamisesta menetelmän vaatimalla tavalla. Ulkopuolinen asiantuntija (vaatimusten määrittelytyön asiantuntija) vastaa esimerkiksi vaatimusten määrittelyn suunnittelusta ja menetelmien koulutuksesta ja ohjauksesta. 8 Vaatimusten määrittelyn ositus ja käytännön työskentely Kehityksen kohteena oleva toiminta ja sitä tukeva tuleva tietojärjestelmä kannattaa jakaa kolmeen tai tarvittaessa useampaan loogiseen kokonaisuuteen. Kokonaisuuksia voivat olla esimerkiksi prosessikuvausten päivitys, käyttötilanteet liittymäkuvaukset vaatimusluettelon laadinta vanhojen tietojen konversiot raportit ja tulosteet 17/29

käyttötapauskuvaukset. Vaatimusten määrittelyn osittaminen on perusteltua työn nopeuttamiseksi ja asiantuntijuuden varmistamiseksi. Jokaista kokonaisuutta lähtee yhtä aikaa työstämään oma ryhmä tai asiantuntija. Tarvittaessa koko projektiryhmä voidaan joskus koota jonkun tai joidenkin asioiden yhteiseen pohdiskeluun tai esiintyvien ongelmien ratkaisujen etsimiseen yhdessä. Yksi hyvä tapa on yhden tai kahden päivän mittainen teemaseminaari, jossa keskitytään ryhmän kanssa vain tiettyjen etukäteen nimettyjen asioiden käsittelyyn ja määrittelyyn. Aina tarvittaessa koko projektiryhmä voidaan koota jonkun tai joidenkin asioiden yhteiseen pohdiskeluun tai esiintyvien ongelmien ratkaisujen etsimiseen yhdessä. On suositeltavaa, että projektin käynnistysvaiheessa kaikki osallistujat kokoontuvat yhteen. Tyypillistä on, että osaa kuvauksista työstetään yhtä aikaisesti. Prosessien kuvaamisen yhteydessä kannattaa lähteä keräämään sanastoa. Käyttötilanteiden kuvaamisen yhteydessä sanastoa täydennetään ja kuvataan jo alustavaa liiketoiminnan luokkakaaviota. Lähes jokaiseen tehtäväkokonaisuuteen kuuluu myös siihen liittyvien testausskenaarioiden suunnittelu. Lisäksi tarvitaan testausskenaarioita, jotka menevät yli tehtäväkokonaisuuksien. Esimerkiksi prosessiin liittyvässä testausskenaariossa on syytä tarkistaa, löytyykö siinä järjestelmän avulla suoritettavalle toiminnallisuudelle vastaava käyttötapaus. Vastaavasti käyttötapauksessa käsitellään tietoja, joiden pitäisi löytyä liiketoiminnan luokkamallista. Kommunikaatio ja viestintä ovat erittäin tärkeitä vaatimuksia määriteltäessä. Ryhmä kannattaa koota esimerkiksi kerran viikossa yhteiseen viikkopalaveriin projektipäällikön johdolla. Kukin ryhmä esittelee toisten ryhmien jäsenille oman ryhmänsä töiden edistymisraportin suullisesti. Samalla voidaan nostaa esille mahdolliset avoimet, päätöksiä tarvitsevat asiat, uhkakuvat, riskit ja ongelmat. Säännöllinen viikkopalaveri on luonteeltaan paitsi tiedotustilaisuus myös ryhmän sisäinen katselmointitilaisuus. Viikkopalaverin eräs tarkoitus onkin, että ryhmissä tehdyt ratkaisut ovat myös koko projektiryhmän yhteisessä tiedossa ja yhteisesti hyväksymiä. Viikkopalaverissa ei siis suunnitella asioita eikä pohdita ratkaisuja ongelmiin, vaan ne annetaan tehtäväksi nimetyille henkilöille. Tehtävälle annetaan määräaika ja ratkaisut esitellään seuraavassa viikkopalaverissa. Viikkopalavereista on pidettävä pöytäkirjaa, johon kirjataan ryhmän periaatepäätökset, avoimet asiat ja niiden ratkaisutoimenpiteet ja muut keskeiset ryhmän työskentelyyn liittyvät asiat. 9 Vaatimusten hankintamenetelmiä Vaatimusten hankinta on tiedonkeruuta, jonka tavoitteena on kartuttaa ongelma-alueeseen liittyvää tietoa, jota käytetään järjestelmän tai integraatioratkaisun kehittämisessä ja valinnassa. Vaatimusten hankinnassa on päätettävä mikä on oikeaa ja tarvittavaa kerättävää tietoa, keneltä tieto saadaan parhaiten kerättyä ja miten menetellä kerätyn tiedon kanssa myöhemmissä vaiheissa. Vaatimusten hankinnassa eri tahoilta tulee kiinnittää huomiota ongelman kuvaamiseen siten, että kuvaus muodostaa kattavan ja riittävän pohjan jatkotyölle. Esimerkiksi kirjallisessa muodossa olevien tehtävänkuvausten ym. dokumenttien tulisi vastata varsinaisia tehtäviä. Eri osapuolet kertomat asiat esim. tekemistään tehtävistä voivat poiketa niistä asioista, joita he todellisuudessa tekevät. Tietämys on myös usein hajaantunut siten, että tietyt tahot näkevät vain osan kokonaisuudesta. Seuraavassa on lueteltu lyhyesti muutamia vaatimusten hankinnassa käyttökelpoisia menettelytapoja: 9.1 Dokumenttien tutkiminen Dokumenttien tutkimisen tavoitteena on löytää olennaisia vaatimuksia valmiin materiaalin perusteella. Vaatimusten määrittelyä suorittava ryhmä kartoittaa olemassa olevaa materiaalia esim. integrointitilanteeseen liittyvistä järjestelmistä (jo tehdyt määritykset, valmiit standardit, käyttöohjeet, koulutusmateriaali, oppikirjat, kirjallisuuskatsaukset, arviointimateriaali). Materiaalia tutkitaan etsien 18/29

kyseisen ongelman kannalta olennaisia kohtia, ja kirjataan löydettyjen asioiden osalta vaatimuksia. Erityisesti kohdat, joissa kuvataan tavoitteita ja tärkeitä ominaisuuksia ovat olennaisia: Järjestelmän tulee.. jne. Dokumenttien tutkiminen on systemaattisesti tehtynä aikaa vievää ja työlästä. Etuja on, että näin varmistetaan olemassa olevien ratkaisujen hyödyntäminen ja tuotettavien ratkaisujen yhteensopivuus jo tehtyjen ratkaisujen kanssa. 9.2 Kyselylomakkeet Kyselyt ovat hyvä tapa löytää selkeisiin kysymyksiin runsaasti vastauksia, kerätä nopeasti tietoa, mielipiteitä ja tietämystä. Kyselyä suunniteltaessa kartoitetaan ja valitaan halutut vastaajaryhmät ja kriteerit, joilla ryhmän edustajat valitaan. Tämän jälkeen määritellään miltä alueilta ja mistä näkökulmista halutaan kerätä tietoa tai mitä halutaan mitata. Kyselylomakkeet voivat sisältää suljettuja ja/tai avoimia kysymyksiä. Kysymykset kannattaa suunnitella lyhyiksi, yksiselitteisiksi ja johdonmukaisiksi. Kyselyillä on mahdollisuus tavoittaa suuri määrä vastaajia edullisesti. Mikäli käytössä on verkkokyselyjärjestelmä tai taulukkolaskentasovellus, jo yksinkertaisillakin sovelluksilla voidaan vastausten analysointia automatisoida ja tuottaa vastauksista ristiinajoilla havainnollisia taulukkograafeja vastausten hajonnasta ja painotuksesta. Kyselylomakkeiden haittapuolia ovat mm. alhainen vastausprosentti, vastausten palautumiseen kuluva aika, väärin täytetyt lomakkeet, oikeiden vastaajien valitseminen sekä vuorovaikutteisuuden puute. 9.3 Suullinen kysely Suullisilla kyselyillä ja haastatteluilla kerätään tietoa, mielipiteitä ja tietämystä vastausten saamiseksi selkeisiin kysymyksiin. Haastattelujen suunnittelun alkuvaiheessa määritellään halutut vastaajaryhmät ja kriteerit, joilla ryhmän edustajat valitaan. Kyselyt on hyvä suunnitella määrämittaisiksi - tämä helpottaa vastausten käsittelyä ja analysointia. Suulliset kyselyt ja haastattelut kannattaa toteuttaa käyttäen etukäteen laadittuja haastattelulomakkeita. Haastattelujen nopeuttamiseksi lomakkeet voidaan lähettää haastateltaville etukäteen tutustuttavaksi. Suullisen kyselyn etuja ovat mm. vuorovaikutteisuus ja mahdollisuus syventää lisäkysymyksillä vastausten aihealueita. Monissa tapauksissa tiedon lisääntyminen on molemminpuolista. Haastattelussa kyselijä voi antaa haastateltavalle runsaasti tietoa määrittelyn kohteena olevan järjestelmän hankinnan aikataulusta ja tavoitteista. Suullisen kyselymenetelmän haittoja ovat haastatteluaikojen kalenterointi sekä oikeiden vastaajien valitseminen. Mikäli haastateltavia on runsaasti, haastatteluihin ja niiden kirjalliseen purkamiseen saattaa kulua useita viikkoja. 9.4 Suullinen strukturoitu haastattelu Haastattelun kulku ja aikataulu suunnitellaan kuten edellisessä menetelmässä. Haastattelussa seurataan tarkkaa suunnitelmaa (strukturoitu) tai poiketaan ja syvennetään eri asioita haluttaessa, tai on listattu asiakokonaisuudet, joista puhutaan (semi-strukturoitu). Menetelmän etuna on haastattelun helppous ja se, että eri haastattelijat voivat saada samanlaisia vastauksia helpommin kuin strukturoimattomassa haastattelussa. Menetelmän haittapuoli on, että etukäteen suunniteltujen kysymysten on oltava oikeita ja sopivia, strukturointi vähentää spontaania vuorovaikutusta, haastattelut vaativat kykyä pysyä aiheessa ja sovellusalueen tuntemusta. Haastatteluaikojen sopiminen sekä vastausten purku vaatii työtä. 9.5 Suullinen strukturoimaton haastattelu Haastattelua varten sovitaan keskusteltava asia, haastattelija voi kuitenkin listata useita keskusteltavia asioita. Suullinen strukturoimaton haastattelu on hyvin vuorovaikutteinen ohjattu keskustelu, jossa haastattelija saa haastateltavan mielestä tärkeää ja oikeaa tietoa. Menetelmä on haastava, sillä se vaatii haastattelijalta haastateltavan oman alueen hyvää tuntemusta, haastattelutaitoa. Riskinä on, että keskustelu rönsyilee ja eksyy aiheesta. Kuten haastatteluissa ja henkilökohtaisissa tapaamisissa yleensäkin, haastatteluaikojen 19/29

sopiminen voi olla vaikeaa. Strukturoimattomien haastattelujen purkaminen on vaikeaa ja usein haastattelijan kannattaa nauhoittaa keskustelu. 9.6 Ryhmäpohjaiset tapaamiset Ryhmäpohjaisissa tapaamisissa kerätään valituilta henkilöiltä tietoa ja reaktioita esitettyihin asioihin sekä pyritään löytämään sidosryhmien kesken yhteiset näkemykset. Ryhmäpohjaisten menetelmien keskeisenä tavoitteena on myös sitouttaa osallistujia. Yleisimpiä menetelmiä ovat aivoriihi, focus-ryhmät ja työpajat. Muita menetelmiä ovat mm. FAST (facilitated application specification technique), JAD (Joint Application Design) sekä RAD (Rapid Application Development)-ryhmämenetelmä. Menetelmät mahdollistavat luonnollisen vuorovaikutuksen sekä hiljaisen tiedon, ideoiden ja kokemusten vaihdon osallistujien kesken. Ryhmäpohjaiset menetelmät soveltuvat erittäin hyvin hankkeisiin, joihin osallistuu useita organisaatioita tai toimijaverkostoja. Ryhmäpohjaisten tapaamisten haittoja ovat kaikille avainhenkilöille sopivan ajan järjestäminen. Ryhmätapaamiset ovat yleensä usean tunnin mittaisia ja ryhmiin voi olla vaikea saada parhaita asiantuntijoita, sillä he ovat yleensä muutenkin kiireisimpiä. Ryhmäpohjaiset menetelmät vaativat toteuttajalta hyvää menetelmän tuntemusta ja ryhmädynamiikan tuntemusta. Onnistuessaan ryhmäpohjaiset tapaamiset ovat tehokas tapa määritellä vaatimuksia mutta epäonnistuessaan saattavat vaikeuttaa vaatimusten määrittelyn etenemistä. 9.6.1 Aivoriihi Aivoriihessä valituilta henkilöiltä kerätään tietoa ja reaktioita esitettyihin asioihin, pyritään löytämään yhteiset näkemykset tärkeiden sidosryhmien kesken ja sitoutetaan osallistujia. Aivoriiheen valmistaudutaan tunnistamalla oikeat henkilöt, sopimalla ajankohta, aikataulu ja paikka. Käynnistyksessä selitetään toiminnan kulku. Synteesivaiheessa viritetään keskustelu, heitellään ja luodaan vapaasti ideoita, tunnistetaan epäkohtia. Analyysivaiheessa etsitään yhteiset asiat, käsitellään perustelut, järjestellään asiat oikeiden otsikoiden alle ja kirjataan saavutetut tulokset. Aivoriihi mahdollistaa luonnollisen vuorovaikutuksen sekä ideoiden ja kokemusten vaihdon osallistujien kesken. Aivoriihi soveltuu erittäin hyvin hankkeisiin, joihin osallistuu useita organisaatioita tai toimijaverkostoja. Aivoriihen käytön vaikeutena on kaikille avainhenkilöille sopivan ajan järjestäminen, sopiminen ja tarkentaminen. Menetelmä vaatii kokeneen vetäjän. 9.6.2 Työpaja Työpaja on tarkoin ohjattu menetelmä ennalta valittujen teemojen ja aiheiden työstämiseksi. Työpajan vetäjä/vetäjät vastaa suunnittelusta, valmistelusta ja työpajan ohjauksesta (työpajan sääntöjen esiin tuonti, kysymykset, kuuntelu, tarkkailu, analysointi, ongelmien esiin nostaminen), samoin kuin asioiden yhteenvedosta. Työpajassa nimensä mukaisesti työskennellään tavoitteellisesti ja tuloksia tuottaen. Kaikki tulokset, keskustelut ja päätökset kirjataan. Työpajassa kannattaa nimetä dokumentoinnista vastaava henkilö. Kirjuri kirjaa kaikki keskustellut asiat ja päätökset ja voi samalla jo analysoida saatuja vaatimuksia. Työpajan osallistujat tuovat keskusteluun omat tietonsa edustaen omia sidosryhmiään. Myös osallistujien tulisi valmistautua ja sitoutua työpajaan ja kyetä päätöksentekoon työpajassa. Työpaja on menetelmänä osallistava ja osallistujia motivoiva. Työpaja vaatii sitä huolellisempaa valmistelua, mitä vaikeammasta työskentelyn kohteesta on kysymys. Yleensä Työpajaan kannattaa kutsua käsiteltävää aihetta ja sen eri näkökulmia avaavia puheenvuoroja. 10 Hyvän vaatimusilmaisun kriteerit Vaatimuksen sisältö on tärkein vaatimuksesta kerättävä tieto. Sisältö luonnollisesti vaihtelee huomattavasti, eikä ns. oikeata vaatimusta voida määritellä. Vaatimusten on oltava yksikäsitteisiä. Vaatimuksen sisältöosuuteen kirjataan luonnollisesti se mitä halutaan. Tässä yhteydessä on syytä korostaa vaatimustekstin lyhyyttä, selkeyttä ja yksiselitteisyyttä. Vaatimus pitää aina kirjoittaa siten, että samaan lauseeseen ei sisälly useampia vaatimuksia. 20/29

Kuva 10 Vaatimusilmaisun rakenne Vaatimuksen on sisällettävä kaikki se tieto, joka tarvitaan vaatimuksen mukaisen ominaisuuden suunnittelemiseksi. Esimerkiksi vaatimus järjestelmää on voitava myöhemmin laajentaa ei itse asiassa tarkoita mitään, koska siinä ei kuvata miten tai miltä osin ja kuinka paljon järjestelmään on varattava laajennusvaraa. Jos sen sijaan kuvataan, että järjestelmään on voitava lisätä myöhemmin tietyn kokoinen, painoinen ja tehoinen laitteisto, tai että tila-, paino- ja tehobudjeteissa on varattava 10 % marginaali myöhemmille järjestelmäpäivityksille, suunnittelija kykenee ottamaan nämä vaatimukset huomioon ja ne voidaan myös verifioida Kaikki tarpeeton teksti on hyvä poistaa. Lyhyysvaatimus ei kuitenkaan tarkoita, että vaatimuksesta pitäisi karsia tarpeellista informaatiota. Kunkin virkkeen tulee sisältää vain yksi vaatimus. Tämä estää vaatimuksen hukkumisen. Vaatimusten määrittelyn tärkeimpänä lopputuloksena tulee olla aito ja yhteinen ymmärrys toimialan ja tietohallinnon välillä kehittämisen kohteena olevan tietojärjestelmän tulevasta toiminnasta. Tämä vaihe vaatii aina eri osapuolten välillä sovittelua ja kompromissien hakua aika-, rahoitus- ja/tai työvoimapulan takia. Hyvän vaatimuksen laadun tunnusmerkkejä ovat: oikeellisuus (tietojärjestelmä täyttää asiakastarpeet) yksiselitteisyys (ymmärrettävä ja ymmärretään yhteisellä tavalla) täydellisyys (kaikki oleellinen on kuvattu) yhdenmukaisuus (ristiriidaton) todennettavissa oleva laitettavissa järjestykseen (tärkeimmät toiminnot ylimpänä ) muutettavuus (muutos helppo ja turvallinen) jäljitettävyys (osiin voidaan palata ja viitata) toteutettavuus (vaatimus on projektin resursseilla tai muilla rajoitteilla mahdollinen toteuttaa) mitattavuus (vaatimuksen toteutuminen voidaan jälkikäteen todentaa). 21/29

11 Vaatimusmäärittelyssä tuotettava dokumentaatio 11.1 Vaatimusluettelo ja tunnistetiedot Vaatimuksista tulee kirjata ainakin seuraavat tässä luvussa esitetyt asiat. Kuva 11 Vaatimusluettelo Vaatimusluettelo-taulukon pohja löytyy liitteestä 2. 11.1.1 Vaatimuksen tunnistetieto Jokainen vaatimus yksilöidään yksiselitteisesti. Vaatimusten yksilöinti toteutetaan juoksevalla numeroinnilla läpi koko asiakirjan. Numeroinnin etuna on vaatimuksen tunnistaminen, jolloin mahdollinen muutos kyetään kohdentamaan juuri oikeaan vaatimukseen. Mikäli vaatimuksia on useita satoja, ilman tunnistetietoa yksittäisen vaatimuksen hakeminen vaatimusten joukosta muodostuu erittäin työlääksi. 11.1.2 Vaatimuksen esittäjä Vaatimusten esittäjä tarkoittaa tahoa, joka ilmaisee vaatimuksen sisältämän tarpeen. Vaatimusten asettajia löytyy järjestelmän kaikista sidosryhmistä. Vaatimuksen voi esittää kuka tahansa taho, jolta vaatimuksia kerätään. Vaatimusten kerääjän on kuitenkin pyrittävä mahdollisuuksien mukaan löytämään kaikille esitetyille vaatimuksille omistaja. Joissakin tapauksissa nimittäin vaatimuksen voi esittää taho, joka tuntee käsiteltävän aihealueen ja havaitsee tarpeen esittää järjestelmän toteutukselle tai suorituskyvylle jonkin vaatimuksen, mutta ei kuitenkaan itse vastaa tästä aihealueesta. Tällä menettelyllä kyetään välttämään monta sudenkuoppaa ja hyödyntämään organisaatiossa olevaa osaamista yli organisaatiorajojen. 11.1.3 Vaatimuksen kriittisyys sen omistajalle Vaatimusten priorisoinnissa kannattaa pitäytyä 3- tasoisessa priorisoinnissa esimerkiksi; 1 = Pakollinen, 2 = Hyödyllinen, 3 = Toivottu. 11.1.4 Perustelu Vaatimuksen perustelu ei ole välttämätön, mutta se on usein kuitenkin hyödyllinen lisätieto. Perustelu voi auttaa mieltämään mitä ylempää vaatimusta vaatimus tukee, vaikka se ei kävisikään kohdasta ilmi. Perustelu voi myös auttaa vaatimuksen luokittelussa ja priorisoinnissa. Pyytämällä vaatimuksen esittäjää perustelemaan vaatimuksensa voidaan myös suhteellisen helposti selvittää, onko kyseessä todellakin toteutusriippumaton vaatimus tai tarpeellinen reunaehto, vai alitajuisesti tehty toteutussidottu ratkaisu. Jos vaatimuksen esittäjä ei kykene perustelemaan vaatimustaan, vaatimus on mahdollisesti väärä, virheellisesti esitetty tai jopa tarpeeton. Yksinkertainen kysymys miksi voi olla paras keino paljastaa sidosryhmän todellinen tarve. 22/29