JUHTA JHS XXX Tietojärjestelmän vaatimusten määrittely LUONNOS Versio: Julkaistu: Voimassaoloaika:

Transkriptio

1 1 JUHTA JHS XXX Tietojärjestelmän vaatimusten määrittely LUONNOS Versio: Julkaistu: Voimassaoloaika: 1 JOHDANTO Suosituksen tarkoitus SOVELTAMISALA TERMIT VAATIMUSTEN MÄÄRITTELYN VAIHEET Esitutkimus vaatimusten määrittelemiseksi Valmistautuminen vaatimusmäärittelyyn Tavoitteiden täsmentäminen Vaatimusten määrittelyn läpiviennin suunnittelu Vaatimusten määrittelyn tuottaminen Tarpeiden täsmentäminen ja analysointi Vaatimusten priorisointi Vaatimusten määrittelyn hyväksyminen Vaatimusten katselmointi Vaatimusten lopullinen hyväksyminen VAATIMUSTEN MÄÄRITTELYN ROOLIT PROJEKTIN OSITUS JA PROJEKTISSA TYÖSKENTELY VAATIMUSTEN HANKINTAMENETELMIÄ Dokumenttien tutkiminen Kyselylomakkeet Suullinen kysely Suullinen strukturoitu haastattelu Suullinen strukturoimaton haastattelu Ryhmäpohjaiset tapaamiset Aivoriihi Työpaja HYVÄN VAATIMUSILMAISUN KRITEERIT VAATIMUSMÄÄRITTELYSSÄ TUOTETTAVAT DOKUMENTIT Vaatimusluettelo ja tunnistetiedot Vanhan järjestelmän tietojen konversiot Järjestelmän tietoturvavaatimukset Järjestelmän tekniset reunaehdot Liiketoiminnan luokkamalli Sanasto Liittymät muihin järjestelmiin Käyttötilannemalli Käyttötilanteiden täsmentäminen käyttötapauksina Käyttäjäroolien kuvaaminen Prosessikuvaukset Raportit ja tulosteet JÄRJESTELMÄN EI-TOIMINNALLISET LAATUVAATIMUKSET OPASTAVAT TIEDOT...29

2 2 1 JOHDANTO 1.1 Suosituksen tarkoitus Tämän suosituksen tarkoituksena on opastaa tietojärjestelmiä hankkivia organisaatioita järjestelmän suunnittelussa, toteutuksessa ja hankinnassa antamalla ohjeita ja malleja järjestelmän vaatimusten määrittelemiseksi. Tietojärjestelmän vaatimusten määrittely ja sen laadukas organisointi on onnistuneen tietojärjestelmän hankinnan perusedellytys. Menetelmänä se on vaativa, mutta säästää projektin kuluissa, nopeuttaa hankkeen läpivientiä ja varmistaa oikeiden ominaisuuksien tuottamisen. Vaatimusmäärittely luo perustan hankinnalle, miksi ja mitä tarpeita hankinnan tulee tyydyttää. Vaatimusten määrittely ja vaatimusten hallinta on järjestelmällinen menettelytapa, jolla pyritään varmistumaan siitä, että järjestelmä tai yleisesti ottaen palvelu, jota ollaan hankkimassa, vastaa sille asetettuja vaatimuksia. Hyvän vaatimusten määrittelyn avulla myös lopputuloksen käyttötarkoituksen testaus eli hankkeen auditointi on helppoa. Kuva 1: Vaatimustenhallinta kattaa kaikki tietojärjestelmän elinkaaren vaiheet.

3 3 Riittämätön vaatimusmää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, mm: vaatimusten kerääjät ja käyttäjät eivät ymmärrä toisiaan, tilaaja on yleensä eri kuin varsinaiset loppukäyttäjät ja 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. Vaatimusmäärittely tulee tehdä riippumatta siitä, ollaanko hankkimassa standardijärjestelmää, esikonfiguroitua järjestelmäratkaisua, ASP-ratkaisua tai hankkivan organisaation tarpeisiin räätälöityä erikoissovellusta. Vaatimusmäärittelyn syvyys vaihtelee hankittavan järjestelmän mukaan. Kuva 2: Vaatimukset Liiketoimintalähtöiset vaatimukset esittävät korkean tason tavoitteita, joita organisaatio pyrkii saavuttamaan ohjelmiston tai järjestelmän tuella. Tällaiset liiketoimintalä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. 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ä ja jolloin myös liiketoimintalähtöiset vaatimuksetvaatimusmäärittelyn rooli valmisohjelmistoa hankittaessa on muodostaa perusta markkinoilla olevien vaihtoehtojen tutkimiseen ja vertailuun..

4 4 2 SOVELTAMISALA Tässä suosituksessa kuvataan tietojärjestelmän vaatimusten määrittelyn suunnittelun ja toteutuksen periaatteet ja kuvataan vaatimusten määrittelyssä tuotettavat dokumentit. Suosituksen kohderyhmät ovat seuraavat: - Tietojärjestelmien omistajat - Tietojärjestelmien hankinnasta päättävät tai tietojärjestelmiä hankkivat henkilöt - Hankintaa suunnittelevat henkilöt - Vaatimusten määrittelyä suorittavat henkilöt 3 TERMIT 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. Ei- toiminnalliset 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 yksilöistä, 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 liiketoimintaprosessit. Katselmointi Vaatimusten laadun varmistamista lukemalla, analysoimalla, puutteita tunnistamalla sekä keskustelemalla niistä ja sopimalla toimenpiteistä tunnistettujen puutteiden poistamiseksi. Kelpuutus Prosessi, jolla varmistetaan, että toteutettu järjestelmä täyttää todelliset sidosryhmävaatimukset (validation). "Lopullinen" järjestelmän kelpuutus tapahtuu sen käytön aikana.

5 5 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äytettävyys (usability) Ominaisuus, joka ilmentää sitä, miten järjestelmä, laite, ohjelma tai palvelu soveltuu suunniteltuun tarkoitukseen tietylle kohderyhmälle. 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 sarjaa toimintoja, joita toimija (ihminen tai järjestelmä tai sen osa) suorittaa tai aikaansaa järjestelmällä jonkin tavoitteen saavuttamiseksi. Käyttötilanne Järjestelmän toimintatila (esim. käynnistys, normaalikäyttö, ylläpitohuolto) Käyttöympäristö Laite tai käyttöjärjestelmä, jossa ohjelmisto toimii. Laatu (quality) Tuotteen tai prosessin [ominaisuuksien ja yhteyksien] ja siihen kohdistuvien [sidosryhmien] vaatimusten suhde. Laatu = vaatimustenmukaisuus. Luokkakaavio Kuvaa järjestelmän sisältämän tiedon rakennetta eli luokkia ja niiden välisiä suhteita. Luokka voi sisältää attribuutteja, jotka kuvaavat luokan tietosisältöä ja metodeja, jotka kuvaavat luokan toimintaa. 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ä.

6 6 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 (Accessibility) Ominaisuus, joka ilmentää sitä, kuinka helposti henkilö voi saada järjestelmän, laitteen, ohjelman tai palvelun käyttöönsä. 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ätarve Vapaamuotoinen ilmaisu siitä, mikä asia tai kykypuutos koetaan ongelmaksi. Skenaario Sanallinen tapahtumakuvaus järjestelmän käytöstä. Se kattaa sekä normaalin, suunnitellun käytön että poikkeustilanteet. Tarkastus (inspection) 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. Tietoturva Tietoturvalla tarkoitetaan sähköisessä muodossa säilytettävien, käsiteltävien ja siirrettävien tietojen, tietojärjestelmien ja palvelujen turvaamista. Tietoturvan suojaamismenetelmät ovat teknisiä, fyysisiä ja hallinnollisia. Keskeistä on myös tietoturvamotivaatio. Järjestelyt, joilla pyritään varmistamaan tiedon käytettävyys, eheys ja luottamuksellisuus. 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.

7 7 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). Vaatimusten määrittely Prosessi vaatimusten määrittelemiseksi ja dokumentoimiseksi.vaatimusten määrittelyn tavoitteena on selvittää ohjelmistolle asetettavat vaatimukset sellaisella tarkkuudella, että niiden perusteella voidaan tuottaa haluttu ohjelmisto. 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) 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.

8 8 4 VAATIMUSTEN MÄÄRITTELYN VAIHEET 4.1 Esitutkimus vaatimusten määrittelemiseksi Kuva 3: Esitutkimus Esitutkimuksen tai esiselvityksen 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. Esitutkimusraportti voi sisältää esimerkiksi organisaation kehittämishanketta koskevan nykytilanteen kuvaamisen sekä ongelmien kuvaukset, joihin haetaan ratkaisua. Esitutkimus on usein laaja selvitys, jossa on kuvattu viite- ja sidosryhmät, joita kehittämishanke koskee sekä alustavat järjestelmälle asetettavat tavoitteet ja rajaukset. Uuden järjestelmän kehittämistavoitteet ovat keskeinen osa esitutkimusta sekä toiminnan kehittämisen eri toimintavaihtoehdot. Esitutkimukseen on sisällytettävä alustava suunnitelma tietojärjestelmähankinnan läpiviemiseksi. Esitutkimuksen perusteella tehdään päätös järjestelmän kehittämisestä tai kehittämättä jättämisestä. 4.2 Valmistautuminen vaatimusmäärittelyyn Tietojärjestelmähankkeesta päätettäessä hankintaa suorittavalla organisaatiolla on yleensä käsitys siitä, mihin järjestelmää tarvitaan. Näkemys on voinut syntyä esitutkimuksen tai selvityksen puitteissa. Useimmiten alkuvaiheessa tunnistetut tarpeet eivät ole niin selkeitä, että ne voitaisiin vain kerätä yhteen vaatimuksiksi. Esitutkimuksen korkean tason vaatimukset ovat hyvä lähtökohta varsinaiselle vaatimus määrieelylle. Vaatimusten määrittelyprosessi koostuu valmistautumis-, tuottamis- ja hyväksymisvaiheista. Prosessin vaiheita on havainnollistettu alla olevassa kuvassa.

9 9 Kuva 4: Valmistautuminen vaatimusten määrittelyyn Vaatimusmäärittelyyn valmistautuminen jakautuu yleensä tavoitteiden täsmentämiseen ja läpiviennin suunnitteluun. Vaatimusmäärittelyprosessi voi saada alkunsa tietojärjestelmätutkimuksesta, varsinkin jos kyseessä on vanhan tietojärjestelmän kehittäminen tai ongelmien kartoitus. Vaatimusmäärittely voi myös saada alkunsa liiketoiminnan kehittämistyöstä ja sen kuluessa tehdystä toiminnan tavoiteprosessien kuvauksesta. Ennen vaatimusmäärittelyn alkamista kootaan esitutkimusasiakirjat, käydään ne läpi ja tunnistetaan päivitystarpeet. Jos esitutkimusta ei ole tehty, on siihen kuuluneet tehtävät suoritettava vaatimusmäärittelyn alussa, jotta saadaan riittävä pohja vaatimusmäärittelyn aloittamiseksi. Lähtötietoja voivat olla esimerkiksi hankkeen asettamisasiakirja liitteineen, vaatimusten määritysprojektin asettamisasiakirja, hankesuunnitelma ja esitutkimuksen asiakirjat 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 irrotettavat 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.

10 10 Kuva 5: Tarpeita ja vaatimuksia voidaan johtaa useilta eri alueilta Vaatimusten määrittelyn läpiviennin suunnittelu Vaatimusten määrittely on hyvä toteuttaa projektina. Suunniteltaessa määrittelyprojektia kaikki tarvittavat osatehtävät tulevat tunnistetuiksi, mikä auttaa laatimaan realistisen työsuunnitelman sekä auttaa arvioimaan työn vaatimat resurssit. Projektisuunnitelman laadinnan yhtenä lähtökohtana ovat esitutkimusasiakirjassa tai hankesuunnitelmassa luetellut rajoitteet, jotka koskeva esim. henkilöresursseja, kustannuksia tai aikataulua. Erityisesti vaatimusten määrittelyprojektissa pitää tavoitteiden täsmentämisen jälkeen tehdä henkilöresurssisopimukset, jotta vaatimusten määrittelytyö pystytään oikein suunnittelemaan ja tekemään. Suunnittelun lopputuloksena on projektisuunnitelma. 4.3 Vaatimusten määrittelyn tuottaminen Vaatimusten määrittelyn tärkeimpänä lopputuloksena tulee olla aito ja yhteinen ymmärrys liiketoiminnan ja tietohallinnon välillä kehittämisen kohteena olevan tietojärjestelmän tulevasta toiminnasta. Tämä vaihe vaatii eri osapuolten välillä sovittelua ja kompromissien hakua usein ristiriitaisten intressien aika-, rahoitus- ja/tai työvoimapulan takia. Toiminnallisuusvaatimukset kuvataan ensisijaisesti toimintaprosesseina (kokonaisuuksien hahmottamiseksi) ja käyttötapauksina (toimintojen hahmottamiseksi) siten, että keskeiset käyttötilanteet kuvataan. Myös keskeiset vaativat käsittelysäännöt on syytä kuvata.

11 11 Kuva 6: Vaatimusten määrittelyn tuottaminen Käyttäjät eritellään käyttäjäryhminä ja niiden rooleina esimerkiksi 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 osin. Projektin ennustettavuus riippuu toiminnallisten määrittelyjen tasosta. Sekä asiakas että toimittaja ovat jo melko tukevalla pohjalla jos määrittelyt ovat niin yksityiskohtaiset, että niiden perusteella pystytään ainakin karkealla tasolla arvioimaan tietojärjestelmän koko toimintopisteinä. Perusteellisen ja kattavan käyttötapausten kuvauksen lisäksi tulisi olla käytettävissä ainakin käsitemalli ja kuvaus järjestelmän ulkoisista yhteyksistä Tarpeiden täsmentäminen ja analysointi Kehitystarpeet rakennettavalle tietojärjestelmälle tai käytössä olevan tietojärjestelmän muutoksille etsitään joko esitutkimusvaiheessa tai vaatimusmäärittelyjen alussa. Esitutkimuksen tarpeiden keruun lopputuloksena olevat 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 esitutkimuksessa on kuvattu ei-toiminnallisia vaatimuksia ja rajoitteita. Tässä vaiheessa on hyvä rajata vaatimusmäärittelyn kohdealue ja päättää, mihin sovelluksiin tai prosessialueisiin tietojärjestelmän hankinta ja sen myötä vaatimusmäärittely kohdistetaan. Tarpeiden analysoinnin jälkeen ovat vaatimusmäärittelyn lähtökohtina priorisoidut toiminnot. Yleensä kaikkia toimintoja = tarpeita ja vaatimuksia ei voida toteuttaa eikä kaikkia ongelmia voida

12 12 ratkaista. Rajoitteet ovat seikkoja, jotka on otettava aina huomioon tietojärjestelmähankkeen kaikissa vaiheissa myös vaatimusmäärittelykuvausten tekemisen suunnittelussa Vaatimusten priorisointi Vaatimusten priorisointi on keskeinen tapa hallita järjestelmän kehitykseen tarjolla olevaa aikaa, rahaa ja ominaisuuksia. Tärkeimmät ominaisuudet ovat korkealla prioriteeteilla, jolloin niiden valmistumisesta varmistutaan projektin aikaisessa vaiheessa. Tärkeysjärjestyksen ohella tärkeää on ymmärtää vaatimusten alkuperä, eli onko kyseessä esimerkiksi tuotekehityksen luoma käytettävyysparannus tai asiakkaan liiketoiminnalle välttämätön ominaisuus Vaatimusten priorisoinnissa kannattaa pitäytyä 3-tasoisessa priorisoinnissa esimerkiksi; 1 = Välttämätön, 2 = Hyödyllinen, 3 = Toivottu. Luokitellut ja yksilöidyt vaatimukset edustavat jäsennettyä tietomassaa, joka on kooste kaikkien asiakas- ja sidosryhmien vaatimuksista. Priorisointi perustuu vaatimuksen pohdiskeluun 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 priorisoimiseksi on asetettava asiakkaat ja sidosryhmät tärkeysjärjestykseen: yleensä kehittämisohjelman tai hankkeen omistaja/rahoittaja on taho, jonka esittämiä vaatimuksia on pidettävä korkealle priorisoituina. Heti rahoittajan jälkeen tulee järjestelmää käyttävä taho ja sen jälkeen järjestelmän loppukäyttäjä. Muut sidosryhmät tulevat tyypillisesti vasta näiden jälkeen. 4.4 Vaatimusten määrittelyn hyväksyminen Vaatimusten hyväksymisen tarkoitus on testata vaatimusten oikeellisuus ja muu laatu. Vaatimusmäärittelyn kuvausten hyväksyminen jakautuu kahteen osaan: vaatimusten katselmointi ja päätöksen tekemiseen. Kuva 7: Vaatimusten määrittelyn hyväksyminen

13 Vaatimusten katselmointi Vaatimusten hyväksymisessä käytetään apuna katselmointeja. Katselmointitilaisuuden puheenjohtajana on hyvä olla ulkopuolinen henkilö. Hänen ei tarvitse olla sisällön tuntija. Hänen tehtävänään on huolehtia siitä, että katselmointitilaisuus etenee sujuvasti, eikä tilaisuudessa ryhdytä ratkomaan ongelmia ja virheitä. Kuva 8: Vaatimusten katselmointi 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. 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: 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.

14 Vaatimusten lopullinen hyväksyminen Katselmoinnissa hyväksyttyjen vaatimusmää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 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. 5 VAATIMUSTEN MÄÄRITTELYN ROOLIT Kuva 9: 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, toimialojen/yksiköiden asiantuntijat, tietohallinnon suunnittelijat ja tarvittaessa ulkopuoliset konsultit. Vaatimusten määrittelyyn osallistuvan ryhmän kokoonpanon suuruuteen ja laajuuteen vaikuttaa, onko kysymyksessä kokonaan räätälöity tietojärjestelmä, valmisohjelmisto vai ASP- sovellus. Tietojärjestelmän omistaja Tietojärjestelmän vaatimusten määrittelyprojektista vastaa tietojärjestelmän omistaja. Omistaja on yleensä 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ä. Projektipäällikkö/Vaatimusten määrittelyvastaava Projektipäällikkö vastaa kokonaisuutena vaatimusten määrittelystä, projektin osituksesta, resursoinnista sekä viestinnästä ja yhteydenpidosta eri sidosryhmiin. 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

15 15 järjestelmän osa-alueet riittävässä määrin, jotta he osaavat hahmottaa kokonaisuuden sekä kyettävä opponoimaan ja sparraamaan muita vaatimusten kirjoittajia sekä etsittävä omien vaatimustensa koeponnistamiseen sellaisia henkilöitä, jotka kykenevät vastaavasti auttamaan vaatimusten tarkastamisessa ja kehittämisessä. 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 konsultti (vaatimusten määrittelytyön asiantuntija) vastaa esimerkiksi vaatimusmäärittelyn suunnittelusta ja menetelmien koulutuksesta ja ohjauksesta. 6 PROJEKTIN OSITUS JA PROJEKTISSA TYÖSKENTELY Kuva 10: Esimerkki vaatimusten määrittelyn osituksesta Kehityksen kohteena oleva toiminta ja sitä tukeva tuleva tietojärjestelmä kannattaa jakaa kolmeen tai tarvittaessa useampaan loogiseen kokonaisuuteen. Tämä on perusteltua työn nopeuttamiseksi ja asiantuntijuuden varmistamiseksi. Jakoperusteena voidaan käyttää esimerkiksi toimintaprosessin alku-, keski- ja loppuvaihetta, liittymät, suorakäyttö, eräajot, tulosteet yms.). 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. Tyypillistä on, että osaa kuvauksista työstetään yhtä aikaisesti. Prosessien kuvaamisen yhteydessä kannattaa lähteä keräämään sanastoa. Käyttötilanteiden kuvaa-misen yhteydessä sanastoa täydennetään ja kuvataan jo alustavaa liiketoiminnan luokkakaaviota.

16 16 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ötilanne. Vastaavasti käyttötilanteessa käsitellään tietoja, joiden pitäisi löytyä liiketoiminnan luokkamallista. Kommunikaatio ja viestintä on tärkeää 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 rat-kaisut 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. 7 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. Seuraavissa on lueteltu lyhyesti muutamia vaatimusten hankinnassa käyttökelpoisia menettelytapoja: 7.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 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. 7.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

17 17 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 sovelluksissa voidaan vastausten analysointia automatisoida ja tuottaa vastauksista ristiinajoilla havainnollisia taulukkograafeja vastausten hajonnasta ja painotuksesta. Kyselylomakkeiden haittapuolena on alhainen vastausprosentti ainakin, vastausten palautumiseen voi kulua runsaasti aikaa, väärin täytetyt lomakkeet, oikeiden vastaajien valitseminen, vuorovaikutteisuuden puute. 7.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 lisäkysymyksillä syventää 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. 7.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 (seimi-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ä. 7.5 Suullinen strukturoimaton haastattelu Haastattelua varten sovitaan keskusteltava asia, haastattelija voi kuitenkin listata useita keskusteltavia asioita. Ks. myös kysely. 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 sopiminen voi olla vaikeaa. Strukturoimattomien haastattelujen purkaminen on vaikeaa ja usein haastattelijan kannattaa nauhoittaa keskustelu.

18 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, focusryhmät, työpajat, 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ä 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 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.

19 19 8 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 Kuva 11: 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öskin 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)

20 20 9 VAATIMUSMÄÄRITTELYSSÄ TUOTETTAVAT DOKUMENTIT 9.1 Vaatimusluettelo ja tunnistetiedot Vaatimuksista tulee kirjata ainakin seuraavat tässä luvussa esitetyt asiat. Kuva 12: Vaatimusluettelo 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. 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. Vaatimuksen kriittisyys sen omistajalle Vaatimusten priorisoinnissa kannattaa pitäytyä 3- tasoisessa priorisoinnissa esimerkiksi; 1 = Välttämätön, 2 = Hyödyllinen, 3 = Toivottu.

21 21 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 asiakkaan tai sidosryhmän todellinen tarve. 9.2 Vanhan järjestelmän tietojen konversiot Jos tietojärjestelmän hankintaan liittyy olemassa olevien tietojen siirto uuteen järjestelmään, kannattaa konversio- osuus laittaa mukaan tarjouspyyntöön ja pyytää siitä oma erillinen erittely tarjoukseen. Tarjouspyynnössä tai sen liitteenä pitää olla riittävät määrittelyt, joilla konversioosuutta voidaan arvioida. Tarjouspyyntöön kannattaa kirjoittaa, että toimittaja voi tarjota kokonaisuutta tai vain jotakin osaa, esim. konversiota. Tilaaja puolestaan voi hankkia koko tarjotun kokonaisuuden tai jakaa hankinnan eri toimittajille; esim. konversio voidaan hankkia eri toimittajalta kuin muut tietojärjestelmän osat. Huomattava on, että mikäli ollaan hankkimassa räätälöityä tietojärjestelmää, konversio voidaan suunnitella vasta, kun uuden järjestelmän suunnitelmat ovat varsin pitkällä (mm. tietorakenteet ja perustoiminnallisuus suunniteltuina). Tästä syystä toimittajat eivät välttämättä halua antaa tarjousta konversiosta heti, sillä konversion laajuuden arvioiminen on erittäin vaikeaa. Tarjouspyynnön liitteenä on annettava konvertoitavan vanhan järjestelmän tietokannan taulujen kuvaukset sekä kunkin sarakkeen tai kentän selkokieliset nimet. Oheen selitys, mitkä tiedot siirretään sellaisenaan ja minkä tietojen siirto toiseen kantaan tarvitsee käsittelysäännön muuttuakseen toisen kannan tiedoksi. Lisäksi tarvitaan selvitykset niistä uusista tiedoista, jotka lisätään uuteen tietokantaan sekä kaikista tiedoista tämän hetken volyymitiedot ja tietomassojen arvioitu lisääntyminen esim. viiden vuoden kuluessa. On huomattava, että mikäli ollaan hankkimassa valmisohjelmistoa, uusi ohjelmisto saattaa käsitellä tietoja omalla tavallaan, joka ei ehkä olekaan sama kuin olemassa olevan järjestelmän käsittelytapa. Tästä saattaa aiheutua lisähaasteita sekä konversiolle että konvertoidun tietosisällön käytölle uudessa järjestelmässä. 9.3 Järjestelmän tietoturvavaatimukset Tietoturvallisuusvaatimukset sisällytetään tarjouspyyntöön ja sopimuksiin. Tietoturvavaatimusten määrittelyssä tarkastetaan vastaako nykyinen infrastruktuuri, johon tietojärjestelmää rakennetaan mm. seuraavia tekijöitä: Yleisiä tietoturvavaatimuksia: salasanojen vaihtuvuus murtoyritysten seuranta ja seurantaan liittyvät toimintatavat järjestelmän ylläpitäjien ja tietokannanhoitajien vahvat oikeudet käyttöjärjestelmätasolle ja suoraan tietokantaan (pitää olla henkilökohtaiset tunnukset) muutoshistorian tarkastettavuus fyysiset turvamenettelyt (kulunvalvonta, lokit ja niiden sijainti, paloturva)

22 22 varmistukset järjestelmään sijoitetut tietoturvallisuusvaatimukset pääsynvalvonta luottamuksellisuus eheys käytettävyys tietoturvallisuusvaatimusten vaikutus tekniseen arkkitehtuuriin 9.4 Järjestelmän tekniset reunaehdot Tietojärjestelmän tekniset reunaehdot liittyvät sekä käyttäjien tarpeisiin (esimerkiksi vaadittavat päätelaitteet kuten työasemat, kämmentietokoneet, päätteet) että kohdeorganisaation tietohallinnon näkökulmaan (tuetut palvelinympäristöt, tietokantajärjestelmät jne.) suositelluista tai vaadituista ohjelmistoista, laitteistoista tai tietoliikenteestä ja muista mahdollisista yhteyksistä. Näkökulmina ohjelmistoihin ja laitteistoihin voidaan esittää: ohjelmistoarkkitehtuuri (erityisesti tasot kuten suora päätekäyttöisyys, asiakas- palvelin - arkkitehtuurin tasot) vaadittavat käyttöjärjestelmät ja muut mahdolliset varusohjelmistot ja niiden versiot vaadittavat kehitys-, testaus-, koulutus- ym. ympäristöt ohjelmistoineen ja laitteistoineen käyttöpalvelun tehtävät tuotantokäytön ympäristö ja laitteet Teknisenä reunaehtona voi olla esimerkiksi: Palvelimina käytetään vain A-tyypin palvelimia, joissa käyttöjärjestelmänä on B. 9.5 Liiketoiminnan luokkamalli Liiketoiminnan luokkamallin rakentaminen alkaa siitä, että kehityskohteen tärkeimmät käsitteet ryhmitetään ensin karkeantason käsitemalliksi. Käsitemalli voidaan kasata esim. keltaisilla muistilapuilla taululle ja piirtää käsitteiden väliset yhteysviidat tussikynällä. Kuva 13: Luokkamalli

23 23 Kun käsitemallin käsitteet ovat koossa ja niiden keskinäiset kytkökset on alustavasti mietitty, siirrytään seuraavaan työvaiheeseen eli käsitemallin jalostamiseen (liike)toiminnan luokkamalliksi. Kuva 14: Liiketoiminnan luokkamalli Esimerkkikuvasta havaitaan välittömästi seuraavat yhteydet: - henkilöön liittyy nolla, yksi tai useampia (0..*) työsuhteita - työsuhde liittyy yhteen (1) henkilöön - työsuhde liittyy yhteen (1) työnantajaan - työnantajaan liittyy yksi tai useampia (1..*) työsuhteita - työsuhteesta on yhteys itseensä. Tämän yhteyden nimi on Lähin esimies ja nimen vieress oleva nuolenpää osoittaa yhteyden nimen lukusuunnan. - Työsuhteeseen voi täten liittyä nolla tai yksi (0..1) lähintä esimiestä. Esimieheen voi liittyä nolla, yksi tai useampia (0..*) välitöntä alaista. Mikäli ollaan hankkimassa valmisohjelmistoa tai palvelua, yksityiskohtaista liiketoiminnan luokkamallia ei tarvitse kuvata. Sen sijaan on tärkeää kerätä käsitteiden tietosisältö, ts. mitä tietoja valmisohjelmistoon pitäisi voida tallettaa. Mikäli ollaan rakentamassa ohjelmistoa, jossa ei käytetä tietokantaa, karkeantason käsitemalli ja käsitteiden tietosisältö tulee kuvata. Liiketoiminnan luokkamallissa kuvataan todelliset, keskeiset kehityksen kohteena olevan toiminnan käsitteet (= luokat) ja niiden väliset suhteet. Liiketoiminnan luokkamalli ei sisällä teknisiä tietojärjestelmän tarvitsemia käsitteitä. Tietojärjestelmän tietosisältö (ja tallennettavat tiedot) kuvataan luokkina, joissa tiedot määritellään attribuutteina. Suunnittelu- ja toteutusvaiheessa luokkien kuvauksien perusteella tehdään tietokannan taulut. Liiketoiminnan luokkakaaviossa on kirjoitetut selitteet luokista ja luokkien attribuuteista, attribuuttien arvot ja ainakin yhteydet luokkien välillä lisättynä tarvittaessa sanallisilla selityksillä.

24 24 Liiketoiminnan luokka sisältää yleensä yhden tai useamman attribuutin eli tietokentän. Käsitteiden attribuuttien ( tietokenttien ) täsmentäminen (tietotyypit, sallitut arvoalueet jne.) voidaan tehdä myöhemmin yhdessä toimittajan kanssa määrittelyvaiheessa (määrittelyjen tarkentamis- ja täsmentämisvaiheessa). 9.6 Sanasto Sanaston laatimisella luodaan perusta yhteiselle käsitteistölle ja sitä kautta helpotetaan viestintää eri osapuolten kesken. Sanasto sisältää kohdealueeseen ja tietojärjestelmän kehittämiseen liittyvät termit sekä termien määritelmät. Tyypillistä on, että samasta asiasta käytetään useaa nimitystä. Tällöin on sovittava, mitä termiä käytetään pääsääntöisesti kuvauksissa. Vaihtoehtoisesti esiintyy myös termejä, jotka tarkoittavat useaa eri asiaa. Tällöin pitää mahdollisuuksien mukaan sopia joko uusi termi toiselle asialle tai jokin tarkenne, jotta tiedetään, mitä asiaa tarkoitetaan. Sanastoa päivitetään koko ajan työn edistyessä ja siihen kerätään keskeiset termit ja lyhenteet käyttötilanteiden kuvauksen yhteydessä sekä niistä käytössä olevat synonyymit. Samalla tunnistetaan ja päivitetään keskeiset käsitteet ja termit liiketoiminnan luokkamallin kuvauksen yhteydessä ja kirjoitetaan kullekin termille lyhyt ymmärrettävä määritelmä, mitä termi tarkoittaa. Sanasto on olennainen vaatimusmäärittelyn lopputuote, joka auttaa vaatimusten ja vaatimus-määrittelykuvausten ymmärtämistä ja eri osapuolten keskinäistä viestintää. 9.7 Liittymät muihin järjestelmiin Hankittavan tietojärjestelmän sisäiset ja ulkoiset liittymät on kuvattava kokonaiskaaviona, josta ilmenee integrointi muihin jo olemassa oleviin, kehitteillä oleviin tai tuleviin järjestelmiin. Jotta tiedetään, miten liittymää hyödynnetään, yksittäiset järjestelmäliittymät kannattaa kuvata käyttötilannekuvauksina. Yhdellä liittymäjärjestelmällä voi olla useita liittymiä, riippuen esimerkiksi tiedon siirron suunnasta, sisällöstä, toiminnallisuudesta (tietoaineiston luonti, muunnokset ja muu käsittely, sisään luku ym.) ja käytön frekvenssistä. Järjestelmäliittymäkuvauksessa kuvataan liittymien luonne, alustava rajapintojen teknisen toteutuksen kuvaus, toiminnallisuus, volyymit ja tietosisällöt olennaisin osin. Järjestelmäliittymällä tarkoitetaan ajantasaista tai eräkäsittelyluonteista tiedonsiirtoa määrittelykohteena olevan tietojärjestelmän ja toisen järjestelmän välillä. Jokainen yksittäinen liittymä on kuvattava liittymäkuvauslomakkeella tai käyttötilanteena. Rajapinnan yli siirtyvät ja/tai vastaanotettavat tiedot pitää kuvata mahdollisimman tarkasti. Kuvaukset tarkennetaan myöhemmin määrittelyvaiheessa yhdessä toimittajan kanssa. Jos valitaan kuvaustavaksi käyttötilannekuvaus, hyvä piirtää kaavio, jossa kuvataan sen yhteys toisen järjestelmän rajapintaan. Käyttötilanteen tekstiosassa on kerrottava liittymän toiminta sanallisesti niin tarkasti kuin se kuvaushetkellä tiedetään. Rajapinnan yli siirtyvät ja/tai vastaanotettavat tiedot pitää kuvata samalla tarkkuudella kuin liiketoiminnan luokkamallin attribuutit.

25 25 Kuva 15: Asiakasrekisterin liittymät muihin järjestelmiin. Asiakasrekisteri hakee tietoja Väestörekisterikeskuksesta ja tallettaa tai siirtää tietoja Arkistointijärjestelmään. Postitusjärjestelmä hakee osoitetiedot Asiakasrekisteristä. Nuolen suunta ilmaisee ensimmäisen yhteydenoton suunnan. Liittymän tietomäärä- ja käytön useuden tarkoitus on antaa viitteitä esimerkiksi liittymän luotettavuuden ja tuotannollisen tehokkuuden (käsiteltävät tietomassat, tietoliikenneratkaisun kapasiteetti siirrettävien tietomäärien kannalta ym.) vaatimuksista. Liittymäkuvausten työstäminen voidaan aloittaa, kun tiedetään mitkä ovat rakennettavan tai hankittavan järjestelmän rajat ja mihin muihin järjestelmiin sen tulee olla yhteydessä. Usein liittymäkuvauksia päästään työstämään, kun käyttötilanteista on olemassa toisen iteraatiokierroksen kuvaukset ja kun alustava liiketoiminnan luokkamalli on olemassa. Liittymäkuvauksissa kannattaa tietovirrat rajapintojen yli kumpaankin suuntaan kuvata luetteloina, jossa tiedot on määritelty kuten liiketoiminnan luokkamallin attribuutit. Sen lisäksi on kuvattava vaatimukset siirtotavalle (salaukset ja tietoturva) ja tiedon siirtojen tiheys ja reaaliaikaisuus. Kaikki liittymäkuvaukset voi antaa yhden ryhmän tehtäväksi, jolloin ne tulee kuvattua samalla tavalla. Ryhmä voidaan koota kuten luokkamalliryhmäkin. Liittymien määrästä ja luonteesta riippuen liittymäkuvaukset voidaan tehdä myös käyttötilanneryhmissä. Tällöin on valvottava, että ratkaisut sekä suorapäivitys- että eräajopuolella ovat samanlaiset.

26 Käyttötilannemalli Prosessikuvauksista on esitutkimus- tai vaatimusmäärittelyvaiheessa etsittävä kaikki järjestelmän piirteet, joiden pohjalta johdetaan järjestelmän toiminnalliset vaatimukset. Ne tunnistetaan, kuvataan, dokumentoidaan, kommunikoidaan ja hallitaan käyttötilanteiden avulla. Käyttötilannemalli koostuu käyttötilannekuvauksista ja käyttötilannekaavioista. Kuva 16: Käyttötilannemalli Käyttötilannemallin sisältö - käyttäjäroolit - käyttötilannekaaviot - eri tyyppiset suhteet eri elementtien välillä (esim. extend ja include) - käyttötilanteiden kuvaukset (dokumentit) - yleiset toiminnalliset vaatimukset (esim. hetu-tarkistukset, pvm- tarkistukset) - skenaariot, visualisoivat kaaviot (tarvittaessa) - muu täydentävä dokumentaatio Käyttötilanteet kuvataan, kuten myös muut vaatimusmäärittelyn kuvaukset, kierroksittain eli iteratiivisesti. On myös huolehdittava siitä, että oikeat henkilöt ovat oikealla paikalla ja että ryhmässä on aina paikalla myös päätösvaltainen henkilö. Ryhmään kannattaa ottaa mukaan myös toimintaa vähemmän tunteva henkilö. Hänen roolinsa on auttaa tunnistamaan ja saamaan esille kuvauksiin helposti kuvaamatta jäävät itsestään selvyydet, jotka voivat tuoda yllättäviä aikataulu- ja kustannusongelmia. Käyttötilannekuvauksen ensimmäinen versio kannattaa kirjoittaa nopeasti lomakkeelle ja siirtyä sitten seuraavaan. Kun kaikki kuvaukset on kerran tehty, seuraa ensimmäinen tarkentava kierros. Tälläkään kierroksella ei kannata vielä yrittää tehdä täydellistä kuvausta. Ei se tietysti ole kiellettyä, mutta vaarana on töiden jumittuminen yhteen käyttötilanteeseen.

27 27 Toisella kierroksella on tärkeintä varmistua, että kyseessä on todellinen käyttötilanne. Joskus käyttötilannekuvauksissa tarkempi analyysi yhdistää kaksi käyttötilannetta toisiinsa. Useimmin käy kuitenkin niin, että käyttötilanne jakautuu kahdeksi jopa useammaksi käyttötilanteeksi. Näin käy varsinkin käyttöliittymiin liittyvissä käyttötilannekuvauksissa. Kolmannella kierroksella pyritään jo mahdollisimman tarkkaan kuvaukseen ja numeroidaan tapahtumien kulku. Tällä kierroksella on lopullisesti tarkistettava, että käyttö-tilanteen kuvauksen kaikki käsitteet ovat myös käsitemallissa = luokkamallissa. Tällä kierroksella aloitetaan tietojärjestelmän testauksen suunnittelu. Käyttötilannekuvauksiin liitetään testitapausten skenaariokuvaukset. Skenaariokuvaukset kannattaa tehdä parityönä pareina esimerkiksi toimialan ja tietohallinnon asiantuntijat 9.9 Käyttötilanteiden täsmentäminen käyttötapauksina Käyttöliittymään liittyvät käyttötilanteet voidaan tarkentaa käyttötapauksiksi. Tämä edellyttää riittävää UML:n mukaista määrittelytaitoa. Itse käyttötapauksen tekstikuvaukset kannattaa tehdä yhdessä toimittajan kanssa määrittelyvaiheessa. Käyttöliittymään liittyvät käyttötilanteet kannattaa jakaa käyttötapauksiksi, koska silloin voidaan myös tehdä karkean tason ikkunakartta ja navigaatiokaavio. Kuva 16: Käyttötapauslomake Käyttötilanteet nimetään käyttäen normaalia kieltä. Suositeltavaa on käyttää termiä 'käsittely', kun puhutaan jonkin lisäämisestä, päivittämisestä tai poistamisesta. Nämä vaihtoehtoiset toimintatavat voidaan siis kuvata samaan käyttötilanteeseen. Esim. Henkilötietojen käsittely. Käyttötapauksia laaditaan käyttötilanteiden pohjalta määrittelyvaiheessa yleensä toimittajan kanssa yhdessä.