Vaatimushallinta, vieläkö sitä tarvitaan?

Mikä on vaatimus?

Vaatimushallinnan ensimmäinen kompastuskivi on ymmärrys, mitä vaatimus missäkin kontekstissa tarkoittaa. Tuoteliiketoiminnassa vaatimukset jaetaan usein kolmeen kategoriaan:

1. Liiketoimintavaatimukset, jotka määrittävät mitä yritys haluaa tuotteella tai palvelulla saavuttaa.
2. Asiakasvaatimukset, eli mitä asiakkaiden tarpeiden täyttämiseen tarvitaan.
3. Tuotevaatimukset, eli miten tuote/ratkaisu/palvelu/ohjelmisto tulee kehittää, jotta kohdat 1 ja 2 toteutuvat.

Vaatimuksia tuotekehitykselle voi tulla myös yrityksen ulkopuolelta, kuten regulaatiosta ja kumppaneilta. Yksinkertaistaen vaatimus on tarve tai rajoite, joka tuotekehityksessä tai tuotannossa pitää huomioida.

Toinen tapa kategorisoida vaatimuksia on jakaa ne toiminnallisiin vaatimuksiin (functional requirements) ja rajoitteisiin (non-functional requirements). Näistä ensimmäiset kertovat, miten tuotteen halutaan toimivan ja jälkimmäiset määrittävät toiminnalle reunaehdot.

Toiminnalliset vaatimukset (Functional requirements)

Toiminnalliset vaatimukset määrittävät, miten tuotetta käytetään ja miten se eri tapauksissa vastaa käyttäjän tarpeisiin. Ohjelmistokehityksessä toiminnallisten vaatimusten kuvaamisessa käytetään usein käyttäjätarinoita, joissa määritetään missä roolissa tuotetta käytetään ja mitä sen avulla halutaan saada aikaan. Hyvin määritetyt toiminnalliset vaatimukset jättävät tilaa erilaisille toteutuksille.

Huononäköisenä puhelimen käyttäjänä haluan, että sovellusten teksti on helposti luettavaa, jotta voin käyttää puhelinta myös ilman lukulaseja.

Muut rajoitteet (Non-functional requirements)

Toiminnallisten vaatimusten lisäksi tuotteeseen yleensä liittyy paljon muita vaatimuksia, jotka usein määrittävät aseman markkinoilla. Näitä ovat esimerkiksi erilaiset suorituskykyvaatimukset, eri markkina-alueiden regulaatiot, rajapinta- ja muut yhteensopivuusvaatimukset sekä turvallisuuteen liittyvät vaatimukset. Hyvin kirjoitetut rajoitteet ovat eksplisiittisiä, eivätkä jätä tilaa väärinymmärryksille.

Puhelimen latausliittymän pitää tukea USB-C standardia.

Kenelle vaatimukset kirjoitetaan?

Usein valitun tuotekehitystavan ajatellaan määrittävän miten vaatimushallintaa tehdään. Kärjistäen ketterässä kehityksessä vaatimuksia ei tarvita ja vesiputousmaailmassa taas kaikki kehitys perustuu ennakolta tehtyyn vaatimusdokumenttiin. Mutta tuliko muna vai kana ensin? Onko siis ketterän kehityksen ajatus dokumentoinnin minimoinnista itse asiassa seuraus vai syy? Vaatimusmäärittelyn tärkeyttä ei määritä valittu tuotekehitysmalli vaan tarvittavan kommunikoinnin määrä.

Jos kolme kaverusta laittavat startupin pystyyn tehdäkseen verkkokaupan käytetyille huppareille, niin tarpeet dokumentoinnille ovat minimaaliset. Kaikki tarvittava asiakastarpeista kehitykseen ja testaukseen voidaan piirtää valkotaululle tai sopia suullisesti. Ulkoisiakaan sidosryhmiä ei ole, joten miksi kirjoittaa käyttäjätarinoita ja hyväksymiskriteerejä itselleen?

Kun sama yrityksen liiketoiminta on lähtenyt lentoon ja yrityksessä onkin kolmen perustajan lisäksi 15 kehittäjää, 5 testaajaa ja 2 pari myyntimiestä ja 2 tuotepäällikköä ja tuotanto, niin kommunikaatiorajapintojen määrä on kasvanut eksponentiaalisesti.

Uudelleenkäytettävyys ja toistettavuus (Dokumentoinnin määrä)

Vaatimushallinnan osalta puhutaan usein myös raudan ja mekaniikan sekä ohjelmistojen erilaisista tarpeista. Tarkasti ottaen kyse ei kuitenkaan ole siitä, miten vaatimukset toteutetaan. Hyvä vaatimus ei edes ota kantaa toteutukseen. Sen sijaan oleellista on ymmärtää, miten paljon työtä vaatimusten dokumentointiin kannattaa laittaa. Siihen vaikuttaa oleellisesti, kuinka monta kertaa vaatimuksia tullaan käyttämään sekä miten ja kenelle tiedon tulee liikkua.

Uudelleenkäyttö — yksi tuote vai tuoteperhe

Kun tarkoituksena on kehittää SaaS-palvelu, niin vaatimuksilla tuskin on paljoa uudelleenkäyttötarvetta. Vaatimusten dokumentointi voidaan tehdä ajatuksella, että niiden elinkaari päättyy, kun tuote tai ominaisuus valmistuu.

Jos tuotteesta tai komponentista sen sijaan tehdään useita erilaisia versioita (esim. sähkömoottorien tuoteperhe), niin vaatimushallintaa ei kannata joka kerran aloittaa alusta. Ottamalla hyvin dokumentoidut vaatimukset tuotekehityksen pohjaksi ja tekemällä vain tarvittavat muutokset ja lisäykset, säästetään huomattavasti aikaa ja vaivaa.

Sidosryhmät

Vaatimusten yleisimpiä käyttäjiä ovat tuotekehitykseen osallistuvat tahot. Heidän lisäksi vaatimuksilla voi olla muita käyttäjiä, kuten esimerkiksi kokonaisratkaisun muut osat, auditoijat tai esimerkiksi tuotteen käyttöönottoon osallistuvat. Mitä lähempänä nämä sidosryhmät ovat, sitä helpompaa kommunikointi on. Sama pätee myös toisinpäin: Mitä kauempana sidosryhmät tai kehittäjät ovat, sitä enemmän vaatimusten dokumentoinnin ja saatavuuden eteen pitää tehdä töitä.

Osaoptimointi on vaatimushallinnan suurin ongelma

Mitä suuremmaksi organisaatio kasvaa ja mitä enemmän se siiloutuu, sitä vaikeammaksi vaatimushallinta muodostuu. Vaatimukset ovat harvoin kenenkään työn lopputulos, vaan pelkästään väline, jonka avulla tuotekehityksen kriittinen informaatio kulkee eri toiminteiden välillä. 

Yleinen esimerkki osaoptimoinnista on projektinhallintaohjelmiston käyttäminen vaatimushallintaan. Ajatuksena on, että käytettäessä samaa ohjelmistoa sekä työn suunnitteluun että tarpeiden kuvaamiseen, ohjelmistokehitykseltä säästyy aikaa ja vaivaa eikä useampia ohjelmistoja tarvita. Samalla saatetaan kuitenkin estää tiedon optimaalinen virtaus osapuolilta toisille (kts. Kuva 1). Pahimmassa tapauksessa myynnin vaatimukset eivät ikinä päädy järjestelmään, vaatimusten ei voi uudelleenkäyttää, koska ne katoavat tehdyn projektin mukana, dokumentointi vaikeutuu tai jopa näkyvyys vaatimuksiin katoaa osalta organisaatiota. Vaatimushallinnan kokonaisprosessia ei pidä katsoa vain yhden organisaation osan näkökulmasta, vaan miettiä informaation virtaa kokonaisuutena.

Vaatimushallinta on tuotekehityksen tukiranka

Hyvän tuotteen perusedellytys on, että se vastaa kohdeasiakkaiden tarpeisiin. Jotta näin on, niin asiakasvaatimukset pitää olla hyvin ymmärretty, kommunikoitu eteenpäin, toteutettu ja testattu. Ei siis ole pienintäkään epäilystä etteikö vaatimushallinta edelleen olisi menestyksekkään tuotekehityksen tukiranka, myös ketterässä kehityksessä.

Tärkeämpi kysymys on, miten vaatimushallintaa kannattaa tehdä. Millä tavalla vaatimukset kuvataan, mihin työkaluun ja kuinka tarkkaan. Tarpeet vaihtelevat eri tuotteiden ja toimialojen välillä, mutta myös yrityksen sisällä ja jopa tuotteen elinkaaren vaiheiden mukaan.

Hyvien vaatimushallintakäytäntöjen luominen vaatiikin kokemusta, näkemystä ja empatiaa myös muiden sidosryhmien tarpeille. Kun yrityksessänne seuraavan kerran mietitään vaatimushallinnan tarpeita, niin kannattaa muistaa että suurin osa yrityksen ongelmista kiteytyy kommunikaatioon. Ja sitähän se vaatimushallintakin perimmäiseltä tarkoitukseltaan on.