Millainen on hyvä liiketoiminnan vaatimusmäärittely?
Millainen on hyvä liiketoiminnan vaatimusmäärittely?
Ensinnäkin se on termihirviö, mutta toisekseen sillä on ensiarvoinen rooli siinä, että sovelluskehitys käynnistyy sujuvasti, toteutuu sovitussa ajassa ja budjetissa sekä vastaa vieläpä tarkoitustaan. Toisin sanottuna liiketoiminnan vaatimusmäärittelyn merkitys jatkuu projektin alkumetreiltä pitkälle sovelluksen elinkaarta.
Systems Gardenin sovelluskehittäjät Sanna ja Jouni kertovat, että liiketoiminnan vaatimusten määrittely tarkoittaa sitä, minkälaisia asioita asiakkaan liiketoiminnassa tulee ottaa huomioon sovellusta kehitettäessä ja mitä sovelluksen tulee tehdä palvellakseen liiketoimintaa. Määrittely käynnistyy näitä asioita koskevilla peruskysymyksillä.
– Prosessi alkaa siitä, että laaditaan lyhyet kuvaukset asiakkaan liiketoimintaympäristöstä ja sovelluksen tarkoituksesta ja kirjataan projektin tavoitteet. Alussa selvitetään, mitä asiakas haluaa heille rakennettavan ja miksi, Jouni muotoilee.
– Jos alussa ei ole selvää, mitä projektin aikana tehdään, on vaikea varmistua siitä, että lopputulos on sitä mitä piti, Sanna lisää.
Sovelluskehityksessä puhuttava samaa kieltä
Systems Gardenin asiantuntijat kertovat, että asiakkaille itselleen sovellukselta toivottavat ominaisuudet voivat olla niin itsestään selviä, että kaikkea ei välttämättä huomata kertoa. Toisaalta asiakkaat eivät aina itsekään tarkkaan tiedä, mitä sovellukselta tarvitsevat. Koska molemmissa tapauksissa vaatimukset tulisi kuitenkin onnistua kommunikoimaan sovelluksen toteuttajille, oikea terminologia nousee suureen rooliin.
– Jos ei ymmärretä sitä, mistä sovellus koostuu, tai luullaan puhuttavan samasta asiasta, vaikka näin ei todellisuudessa olekaan, syntyy projektin aikana helposti väärinkäsityksiä. Siksi yhteisen kielen löytäminen on todella tärkeää, Sanna teroittaa.
Määrittelyn edetessä tarkennetaan sitä, miksi sovellus on tarpeellinen organisaatiolle ja minkälaisiin haasteisiin sen tulisi vastata. Lisäksi käydään läpi sitä, mihin osaan asiakkaan prosessia ja mihin muihin asiakkaan käytössä oleviin ohjelmistoihin sovelluksen tulisi liittyä.
– Esimerkkinä toimii vaikkapa sellainen liiketoiminta, jossa tallentuu paljon puheluita, sähköposteja, lomakkeita tai kohdekäyntejä tietokantaan, jossa niitä täytyisi päästä tilastoimaan, raportoimaan tai ihan vain tarkastelemaan, Jouni listaa.
Liiketoiminnan vaatimusmäärittely varmistaa vastaavuuden käyttäjän tarpeisiin
Jouni kertoo, että sovelluskehityksessä puhutaan toiminnallisista ja ei-toiminnallisista vaatimuksista, joista ensin mainitut ovat kuvauksia siitä, miten sovellus toimii ja mitä se tekee.
– Toiminnalliset vaatimukset määritellään usein erikseen, mutta yksi esimerkki on vaikkapa eri käyttäjäryhmien määrittely, eli minkälaisilla rooleilla sovellusta käytetään. Raportointisovelluksessa kyseessä on asiakkaan asiakas. Oman organisaation sisällä se voi vaihdella esimerkiksi pelkästä lukuoikeudesta jonkin rajatun tiedon muokkaamiseen, toimitusjohtajan pääsyyn tai ylläpito-oikeuksiin.
Ei-toiminnalliset vaatimukset puolestaan tarkoittavat Jounin mukaan sellaisia rajoituksia ja laatuominaisuuksia, joilla varmistetaan, että järjestelmä vastaa käyttäjän tarpeita. Siksi ne liitetään usein vahvemmin juuri liiketoimintavaatimusten määrittelyyn.
Esimerkkejä ei-toiminnallisista vaatimuksista:
- Potentiaalinen käyttäjien määrä. Kuinka sovellus skaalautuu, mikäli määrä kasvaa vaikkapa 10 000 käyttäjästä 100 000 käyttäjään?
- Käsiteltävän datamassan suuruus ja kyky suoriutua siitä.
- Kriittisyys liiketoiminnan kannalta. Tuleeko sovelluksen toimia yhtä nopeasti kaikille? Pysäyttääkö sen kaatuminen liiketoiminnan?
- Lokalisointi. Tukeeko sovellus esimerkiksi eri kieliä eri maissa?
- Infrastruktuuri. Tuleeko sovelluksen toimia yhteen jonkin muun järjestelmän kanssa?
- Tietoturva, datan yksityisyys, varmuuskopiointi
Myös nämä kannattaa hoksata
Sanna ja Jouni huomauttavat, että liiketoiminnan vaatimusmäärittelyssä kannattaa toteuttaa swot- tai riskianalyysi, jotta se mikä projektissa voi mennä pieleen on mahdollisimman hyvin huomioitu etukäteen.
Samalla on hyvä määritellä se, minkälaisessa aikataulussa projekti tulisi pystyä viemään läpi ja minkä suuruisessa budjetissa.
– Sovelluskehitys on enemmän taidetta kuin tiedettä. Vaikka kyseessä olisi kuinka pieni sovellus tahansa, jos ei ole määritelty sitä, milloin se on valmis, kehitystä voidaan jatkaa loputtomiin, Jouni toteaa.
– Määrittelyn ansiosta saattaa myös toisinaan käydä ilmi, ettei sovelluksen kehittäminen ehkä olekaan kannattavaa. Sekä asiakkaalle että meille on hyvä asia, että tämä huomataan ajoissa.
Sanna mainitsee, että liiketoiminnan vaatimusmäärittelyn yhteydessä voi toisinaan ilmetä muutakin huomionarvoista.
– Jos määrittelyssä tunnistetaan esimerkiksi jokin tietty kehitystarve, joka ei kuitenkaan tule kuulumaan kyseiseen sovellusprojektiin, se on hyvä kirjata ylös. Näin sen pariin muistaa paremmin palata ja liikkeelle lähtö on sujuvampaa.
