Vinkkejä onnistuneeseen vaatimusmäärittelyyn

 
 

Teen paljon vaatimusmäärittelyä osana kilpailutuksia 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 kilpsilutuksen osalta olen joutunut pohtimaan samaa ikuisuusasiaa: mikä on riittävää asiakkaalle (kuten myös toimittajalle)? 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 mää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 hankinta 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 mää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ä lista tarpeista (sekä toiminnallisista että ei-toiminnallisista, näistä lisää Projektin vaatimustenmäärittelyoppaassa), 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 riittävin resurssein on onnistumisen kannalta ehdoton edellytys!

Ymmärrettävä vaatimus

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. Vaatimukset tulee luokitella toiminnallisiin ryhmiin. Esimerkiksi ERP-järjestelmän osalla tarpeet voidaan jakaa tuotetiedon hallintaan, asiakkuuden hallintaan, varastonhallintaan, ostotilaustenhallintaan 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 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. Vaatimuksen 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.”
    Fin325-System-Negative-Requirements.jpg
  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 mää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 määrittelyn onnistunut koonti ei välttämättä takaa projektin onnistumista, mutta takaa hyvän pohjan sopimusneuvotteluille. Käyttöönottovaiheessa siirrytäänkin vaatimustenhallintaan, josta päästään taas muutostenhallintaan, mutta nämä ovat jo omien postausten arvoisia kokonaisuuksia. Vaatimustenhallinta voidaan nähdä kertaluontoisena projektina esimerkiksi kilpailutusta tehdessä sekä myös jatkuvana toimintona muutostenhallinnassa.

Lataa tästä vaatimusmäärittelyn työstämiseen vinkkilista graafisessa muodossa

Lataa tarkastuslista

 

Kirjoittaja, Päivi Kähönen – Anttila, toimii Pasaatissa vanhempana projektipäällikkönä.

Tutustu ladattaviin materiaaleihimme

Materiaalipankista voit ladata maksutta käyttöösi oppaita ja työkaluja onnistuneen projektin suunnitteluun ja toteutukseen.

LADATTAVAT MATERIAALIT

Ota Pasaati
projektikumppaniksi

Otetaan kaikki mahdollinen irti projektistasi

OTA YHTEYTTÄ TUTUSTU MEIHIN

 

AriV

Ari Vättö
ari.vatto@pasaati.com
+358 50 5588 914