Ensinnäkin se on termihirviö. 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.

Vaatimusten määrittely käynnistyy peruskysymyksillä

Sovellus- tai ohjelmistoprojekti alkaa siis siitä, että vaatimusmäärittelyssä laaditaan lyhyet kuvaukset sekä asiakkaan liiketoimintaympäristöstä että 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” – Systems Gardenin sovelluskehittäjä Sanna

Vaatimusmäärittely varmistaa, että sovelluskehityksessä puhutaan 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.

– Joskus ei ymmärretä sitä, mistä sovellus koostuu. Toisaalta saatetaan luulla puhuttavan samasta asiasta, vaikka näin ei todellisuudessa olekaan. Molemmissa tilanteissa syntyy projektin aikana helposti väärinkäsityksiä, ja siksi yhteisen kielen löytäminen on todella tärkeää, Sanna teroittaa.

Vaatimusten 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äärittelyllä vastataan käyttäjän tarpeisiin

Jouni kertoo, että sovellus- ja ohjelmistokehityksessä puhutaan toiminnallisista ja ei-toiminnallisista vaatimuksista.

Toiminnalliset vaatimukset ovat kuvauksia siitä, miten sovellus toimii ja mitä se tekee. Toiminnalliset vaatimukset määritellään usein erikseen, mutta yksi vaatimusmäärittelyn 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ä vaatimusmäärittelyssä käsiteltävistä 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

Muista myös nämä asiat ohjelmiston vaatimusmäärittelyssä

Sanna ja Jouni huomauttavat, että ohjelmiston 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.

– Ohjelmistosuunnittelu 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.

Sanna mainitsee, että liiketoiminnan vaatimusmäärittelyn yhteydessä voi toisinaan ilmetä muutakin huomionarvoista.

– Jos ohjelmiston vaatimusmää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.

Jussi Rautjärvi
jussi.rautjarvi@systemsgarden.com
+358 50 306 2515