Pohdintaa vaatimusmäärittelyn työstämisestä ja sen haasteista

Teen paljon vaatimusmäärittelyä osana kilpailutuksia hyvinkin laidasta laitaan erilaisten sovellusten (esimerkiksi ERP) valinnasta IT-palveluiden ulkoistamiseen tai konesalitoimittajan valintaan. Yhteinen haaste näille kaikille on ollut kaivaa esiin asiakkaan todellinen tarve, mikä on monesti asiakkaalta vielä hämärän peitossa. Jokaisen määrittelyn osalta olen joutunut pohtimaan samaa ikuisuusasiaa: mikä on riittävää asiakkaalle (kuten myös toimittajalle vaatimusmäärittelyn osalta) kilpailutusta tehdessä? Kilpailutukset ovat olleet melko suoraviivaisia käyttöönottoja, toimittajan kilpailutusta ja sopivimman toimittajan valintaa. Ei siis niinkään ketteriä sovellusprojekteja, joissa on aivan omat haasteensa.

Aivan ensimmäiseksi, ennen vaatimusmäärittelyn tekoa, tulee selvittää nykytila. Harvemmin on saatavilla kuvauksia nykytilanteesta saatikka prosessinomaisia kuvauksia toiminnasta. Nykyisen menetelmän tai prosessien kuvaaminen visuaalisesti auttaa muodostamaan käsityksen ratkaistavasta ongelmasta. Tämän pohjalta on helpompi määritellä mikä on tavoite tai visio. Esimerkiksi ERP-järjestelmät ovat laajoja kokonaisuuksia, jolloin helposti saattaa iskeä vauhtisokeus ja kaikki tuntuu tärkeältä ja hyödylliseltä.

Nykytilan kuvaus toimii myös vertailukohtana, kun mitataan uuden järjestelmän käyttöönoton tuomia hyötyjä. Monesti uutta työkalua hankittaessa joudutaan miettimään omia prosesseja ja työmenetelmiä uusiksi. Uuden työkalun käyttöönotto tuo aina jotain muutosta totuttuihin toimintatapoihin. Tavoite tai visio tulee pitää kirkkaana mielessä, sillä muutos itsessään on jo suuri. Kaikkea ei kannata haalia kerrallaan. Toiveiden tynnyri on purettava selkokielisiksi vaatimuksiksi ja tehtävä selkeät rajaukset, jotka sekä asiakas että toimittajat ymmärtävät. Jokainen asiakas on uniikki, joten vaatimusmäärittelyä et voi kopioida joltain toiselta. Et vaikka olisit hankkimassa ERP-järjestelmää samoin kuin naapuriyritys.

Kokosin muutamia seikkoja, joihin olen omissa vaatimusmäärittelyissä ja käyttöönottoprojekteissa törmännyt ja joihin mielestäni tulee erityisesti panostaa. Tarjouspyyntövaiheessa ei kannata säästää aikaa ja vaivaa. Selkeä määrittely, tapahtui projekti sitten ketterästi tai vesiputousmallilla, maksaa itsensä varmasti käyttöönottovaiheessa takaisin. Tärkeää on osallistaa määrittelyyn kaikki tarvittavat osapuolet. Mitä isommasta hankkeesta ja organisaatiosta on kyse, sidosryhmien määrä saattaa nousta yllättävän suureksi. Keitä muutos koskee? Ketkä kaikki tulevat käyttämään uutta järjestelmää? Ketkä vaikuttavat välillisesti työkaluun? Tai ketkä käyttävät ulkoistettuja IT-palveluita? Millaisia tarpeita heillä kullakin on? Haastatteluihin eri osapuolten kanssa tulee varata riittävästi aikaa. Tämä takaa varmasti onnistuneemman käyttöönoton ja tyytyväisemmät loppukäyttäjät. Asiakas tietää ja määrittelee omat tarpeensa, vaatimusmäärittelyä ei voi ulkoistaa täysin organisaation ulkopuoliselle. Asiakkaan osallistuminen vaatimusmäärittelyyn riittävin resurssein on onnistumisen kannalta ehdoton edellytys!

Vinkkejä vaatimusmäärittelyn tekemiseen

1. Mieti keitä hanke koskee, keiden tulee osallistua vaatimusmäärittelyyn?  Tee pienimuotoinen sidosryhmäanalyysi keitä uuden järjestelmän hankinta koskettaa. Voit yllättyä, miten moneen tahoon pienikin hankinta saattaa vaikuttaa.

2. Luokittele vaatimukset hierakisesti. Näin pystytään keskittymään jokaiseen kokonaisuuteen mahdollisimman kattavasti. Vaatimusmäärittelyä tehtäessä vaatimukset tulee luokitella toiminnallisiin ryhmiin. Esimerkiksi ERP-järjestelmän määrittelyssä tuotetiedon hallinta, asiakkuuden hallinta, varastonhallinta, ostotilaustenhallinta jne.

3. Identifioi vaatimukset. Vaatimukset, joita ei ole numeroitu, tekee jäljitettävyydestä suorastaan painajaisen. Vaatimuksiin on tällöin helppo viitata jälkeenpäin niitä läpikäytäessä.

4. Määrittele lyhenteet ja termit. Hyvä tapa on kuvata vaatimusmäärittelyn ensimmäisessä luvussa kaikki käytetyt termit ja lyhenteet.

5. Imperatiivien käyttö. Käytä ainoastaan yhtä tapaa johdonmukaisesti. Esimerkiksi ”Asiakkaan yhteyshenkilön tulee saada hälytykset vikatilanteista.”, ei ”Asiakkaan tulisi saada…” tai ” Järjestelmän on hälytettävä tiettyjen asetettujen hälytysrajojen lauetessa”.

6. Varmista, että jokainen vaatimus on testattavissa tai varmennettavissa. Toki palveluita määritettäessä laadullisten vaatimusten mittaaminen saattaa olla haasteellista, muttei mahdotonta. Esimerkiksi ”Palveluntarjoajalla on riittävän teknisen osaamisen omaava lähitukihenkilö, jolla on myös ymmärrystä asiakkaan liiketoiminnasta ja IT-tarpeista.” Mikä on riittävää? Mitä teknistä osaamista tarvitaan? Mitä ymmärrystä ja millä tasolla? Pelkkä ylätason vaatimus ei riitä, toimittajan on todistettava vaatimuksen täyttyminen. Osaamista voidaan arvioida esim. vaatimalla näyttöä osaamisesta, määrittelemällä tekninen osaaminen mahdollisimman tarkoin, kuvaamalla vaadittava liiketoimintaosaaminen tarkemmin, CV:n avulla ja kyselemällä referensseiltä. Itse soitan mielelläni myös sellaisille referensseille, joita toimittaja ei ole tarjouksessaan luetellut. Tällä tavoin olen saanut erittäin arvokasta tietoa ja hyviä vinkkejä asiakkaiden näkökulmasta kilpailutuksia tehdessäni.

7. Vaatimus tulee olla lyhyt, ytimekäs ja yksiselitteinen. Useimmiten vaatimusta joudutaan kuvaamaan tarkemmin. Vaatimukset voidaan otsikoida, jolloin otsikko on ytimekäs ja vaatimusta tarkennetaan kuvauksessa. Esimerkiksi ”Palvelupyyntöjen hallintaprosessi. Toimittajalla tulee olla asiakkaiden palvelupyyntöjen hallintaprosessi, joka kattaa häiriöiden (incident) lisäksi asiakkaiden avainhenkilöiden neuvontapalvelun sekä toimeksiantojen vastaanoton ja käsittelyn (customer request management).”  Ensin siis selkeä, ytimekäs otsikko, mitä vaaditaan (”Palvelupyyntöjen hallintaprosessi”). Vaatimuksessa tarkennetaan mitä hallintaprosessilta odotetaan.

8. Muista, että vaatimus sisältää vain yhden vaatimuksen! Ei näin: ”Palvelun tulee kattaa häiriöhallinnan ja korjaukset sekä muutostenhallinnan ja toimittaja vastaa ko. palveluiden kuvausten ja määrittelyiden tuottamisesta.” vaan häiriöhallinta ja muutostenhallinta omina vaatimuksinaan. Häiriönhallinnan kriittisyydestä riippuen tätä voi tarvittaessa pilkkoa useammaksikin vaatimukseksi jatkuvuuteen ja vikasietoisuuteen liittyvän luokittelun alle.

9. Älä käytä epämääräisiä tai epäselviä sanoja. Näitä on yleensä adverbit, adjektiivit ja verbit, joilla ei ole konkreettista kvantitatiivista merkitystä. Hyvä vaatimus ei sisällä seuraavia sanoja: tehokas, tehostaa, nopea, nopeasti, nopeuttaa, helppo, luotettava, normaali, käyttäjäystävällinen, vähän, jne.

10. Käytä kielteisiä vaatimuksia todella harkiten.  Käytä negatiivista vaatimusta vain korostaaksesi jonkin vaarallisen tai haitallisen toiminnan kieltämiseksi. Älä käytä negatiivista vaatimusta, mikäli se voidaan ilmaista positiivisesti! Esimerkki funktionaalisesta vaatimuksesta: ”Käyttäjiä, joilla on kolme tai useampia käyttäjätunnuksia, ei saa siirtää.” Muunnettuna positiiviseksi vaatimukseksi: ”Järjestelmä siirtää vain ne käyttäjät, joilla on vähemmän kuin kolme käyttäjätunnusta.”

11. Vältä käyttämästä / merkkiä. Merkin tulkinta on epäselvää. Tarkoittaako se, ”ja”, ”tai”, ”yksi jostain” tai niiden yhdistelmää (ja / tai)? Kukin tulkitsee sen omalla tavallaan.

12. Käy vaatimusmäärittely vielä lopuksi kaikkien asianomaisten kanssa läpi. Varmista, että vaatimukset ovat ymmärrettäviä ja kaikki osapuolet ymmärtävät ne samalla tavalla.

13. Mikään vaatimusmäärittely ei ole täydellinen. Valmistaudu ja varaudu muutoksiin ja tarkentuviin vaatimuksiin. Toimittajan asiantuntijat tuntevat työkalut paremmin kuin myyntihenkilöstö ja osaavat ohjata työkalua konfiguroitaessa oikeaan suuntaan.

Pelkän vaatimusmäärittelyn onnistunut koonti ei välttämättä takaa käyttöönottoprojektin onnistumista, mutta takaa hyvän pohjan sopimusneuvotteluille.