Vaatimusmäärittely tehdään hankintaa varten. 

Toteutusvaiheessa tuotetaan rakentamista varten määrittely- ja suunnittelun kuvauksia, jotka perustuvat vaatimusmäärittelyyn ja täsmentävät sitä. Hankinnan taustalla on jokin toiminnan tarve, jonka ratkaisemiseen tarvitaan tietojärjestelmäuudistusta.

Mitä toiminta tarkalleen tarvitsee? Minkä osan hankittava tietojärjestelmä siitä toteuttaa?

Toiminnan tarve voidaan kuvata kolmen periaatteen mukaisesti:

1. käyttäjälähtöisesti

niin, että kaikki oleelliset käyttötilanteet (käyttötapaukset) tulevat ilmi 

2. systemaattisesti

siten, että kaikki potentiaaliset toimittajat ymmärtävät “pihvin” oikein

3. kattavasti

niin, että kuvaus kattaa toimintaprosessin tarvittavat toiminnot. 

Näin toimittajat osaavat tarjota omien lähtökohtiensa perusteella parasta ratkaisua ja tarjousten vertailu on helppoa ja tasapuolista.

Parhaassa tapauksessa toimitus suunnitellaan niin, että pilotointi ja käyttö voidaan tehdä  vaiheittain. Tällöin kokemuksia ja hyötyjä saadaan heti alusta alkaen. Tämä edellyttää, että toiminnan kannalta tärkeimmät kokonaisuudet on tunnistettu vaatimusmäärittelyn yhteydessä. 

Vaaran merkit, tunnista ja eliminoi!

Seuraavat piirteet johtavat usein epäonnistuneeseen ratkaisuun:

1. On kuvattu erilaisia piirteitä, joita järjestelmän tulisi toteuttaa.

Ei kuvata käyttäjien tarpeita, vaan osajoukko jostakin ratkaisusta perustuen oletettuun toteutustapaan. 

Kuvaukset eivät ole systemaattisia ja kuvaustapa vaihtelee.

2. Osa kuvauksista liittyy vanhan järjestelmän toimintoihin ja määrityksiin.

Esim. näyttökuvia, vanhan järjestelmän kerrosarkkitehtuuripiirros, nykyisen tietokannan tietomalli tai yksittäisten toimintojen toteutustasoisia määrityksiä (jopa ohjelmiston lähdekoodia). 

Kuvitellaan, että mitä yksityiskohtaisempia määrityksiä, sen parempi. 

3. Exceliin on laadittu vaatimusluettelo, johon tilaajan eri henkilöt ovat listanneet lyhyesti toivomuksiaan uusina haluttuina piirteinä.

Luettelon rivit on kuvattu yhteen excelin soluun eikä ole kokoavaa kuvausta, josta ilmenisi toiminnallinen kokonaisuus, johon vaatimus liittyy (esim. käyttötilanne). 

Jälkikäteen ei tiedetä, mistä kukin vaatimus on lähtöisin. Jos järjestelmän rajaus muuttuu, niin ei pystytä nimeämään, mitkä vaatimukset ovat sen jälkeen relevantteja.

4. Kaikki vaatimukset on merkitty pakollisiksi.

Jos vaatimusluettelo on vaikeasti tulkittava, on yksinkertaisinta (ja nopeinta) merkitä kaikki pakolliseksi. 

5. Kuvausten ja vaatimusten kattavuudesta ei voida olla varmoja.

Jos toimintaprosesseja ja käyttötapauksia ei ole käyty systemaattisesti läpi, niin kuvaukset ja vaatimukset perustuvat siihen mikä on tullut mieleen. 

6. Järjestelmän rajausta ei ole kuvattu täsmällisesti. Mistä järjestelmä vastaa ja miten se liittyy muihin järjestelmiin?

Eri käyttäjäryhmillä on eriävä käsitys siitä, mitä ajatellaan kuuluvan järjestelmään. Joku ajattelee sen rekisterinä, toinen laskentajärjestelmänä, kolmas asiointijärjestelmänä ja neljäs asianhallintajärjestelmänä.

7. Väärä mielikuva ketterästä kehittämisestä.

Ei kuvauksia tarvita, vaan asiat ratkaistaan ketterän toteutusvaiheen aikana!”

8. Ei-toiminnallisia vaatimuksia ei ole tunnistettu ja kuvattu 

Toimintaympäristö saattaa asettaa vaatimuksia, mitkä olisi hyvä tuoda esille jo tarjouspyyntövaiheessa. Tiedossa voi olla esimerkiksi, että on tiettyinä aikoina vuodessa suorituskyky on koetuksella, tai voi olla tiettyjä toimialaan liittyviä regulaatioita ja muita säännöksiä, jotka on otettava huomioon

Keskity kokonaiskuvaan 

Älä jumitu yksityiskohtiin. Hyvään lopputulokseen tarvitaan:

- Kokoava jäsennys siitä, mitä toimintaa tietojärjestelmän tulisi tukea.

Oleelliset käyttötilanteet tulee esittää systemaattisesti esim. käyttötapauksina, ei järjestelmän piirteinä. Aiempia kuvauksia ja toivelistoja voidaan käyttää työn tukena ja ne toimivat apumateriaaleina.

- Vaatimusluettelo

Vain osa vaatimuksista voi olla pakollisia ja jokaisesta vaatimuksesta tulisi tietää, mistä ne ovat peräisin. Vaatimusten kattavuus ja mahdolliset ristiriitaisuudet on tarkistettava. Toteutuksesta on syytä kuvata MVP (Minimum Viable Product) eli pienin toimiva tuote, jota voidaan käyttää toimintaprosessien tukena. Vaikka tietojärjestelmä toteutettaisiin ketterillä menetelmillä, vaatimukset pitää kuitenkin kuvata. 

- Hankinnan kohteen kuvaus.

Hankinnan kohde tulee kuvata, jotta tilaajan eri käyttäjäryhmät ovat yksimielisiä hankinnasta ja toimittajat osaavat tarjota hyviä ratkaisuja. Jos asioita jätetään auki ketterään toteutusprojektiin, niin silloin tilaajan on varattava aikaa kysymysten ratkaisuun toteutusprojektin aikana. Avoimiin asioihin pitää ottaa silloin kantaa ja tilaajan edustajan on osattava kertoa kaikkien käyttäjäryhmien tarpeet. Tilanne voi eskaloitua ja valmistuminen viivästyä, koska tyypillisesti tilaajan edustaja osallistuu toteutusprojektiin vain muiden töidensä ohessa. Etukäteen systemaattisesti kuvatuilla vaatimuksilla helpotetaan toteutusprojektia, jossa voidaan keskittyä tarkemman toteutuksen määrittelyyn ja suunnitteluun.

- Käyttäjiä

Keskeistä on käyttäjälähtöisyys. Liiketoiminnan edustajat kuvaavat tarpeet ja kokenut vaatimusmäärittelijä koostaa riittävän kuvauksen, jolla päästään hankinnan valmisteluun. IT-asiantuntija ei osaa kuvata toiminnan tarpeita ja toiminnan edustajat eivät ole rutinoituneita vaatimusmäärittelyssä. Siksi vaatimusmäärittely kannattaa tehdä vuorovaikutteisesti yhdessä eri sidosryhmien ja erillisen vaatimusmäärittelijän kanssa.