Tietojärjestelmäprojekti saa alkunsa vaatimuksista: jos ei tiedetä, miksi jotain pitäisi tehdä, mitä pitäisi tehdä ja miten sen pitäisi toimia, niin ollaan hukassa koko projektin ajan.

Liiketoiminnalliset vaatimukset kertovat, mitä liiketoiminnalle tulevia hyötyjä järjestelmältä odotetaan ja missä ajassa. Eli näiden vaatimusten pitäisi vastata siihen, miksi tällainen järjestelmä tehdään. Näistä osaltaan johdetaan tarkemmat vaatimukset ja tietenkin projektisuunnittelu. Joskus näitäkin vaatimuksia ja varsinaista liikeideaa pitää testata ennen järjestelmän rakentamista esim. palvelumuotoilun ja protoilun keinoin.

Toiminnalliset vaatimukset kertovat nimensä mukaan siitä, mitä toiminnallisuutta järjestelmässä pitäisi olla. Näitä on erilaisia ja eritasoisia: vaatimusmäärittely, epic, feature, toiminnallisuus, käyttötapaus, tarina tms. Nämä pitää olla keskenään kunnossa, jotta johonkin toiminnallisuuteen liittyvät tarinat ovat linjassa toiminnallisuuden määrittelyn kanssa.

Ei-toiminnalliset vaatimukset – toisin sanoen laadulliset vaatimukset – kertovat miten järjestelmän pitäisi toimia. Kaikkihan tietävät, että uuden mobiili/web-järjestelmän pitäisi olla helppokäyttöinen, nopea, luotettava ja tietoturvallisuuden pitäisi olla kunnossa. Näissä vaatimuksissa on usein kuuluisa harmaa vyöhyke, koska usein asiakas tai loppukäyttäjä eivät osaa kertoa tarkkoja arvoja näille vaatimuksille. Näille vaatimuksille on useasti olemassa joku tavoitearvo ja alin hyväksyttävä arvo, mutta näitä ei ole kirjattu mihinkään. Jos näitä on vaikea kirjata, niin kannattaa kirjata vertailuesimerkkejä vanhoista järjestelmistä, kilpailijoiden ratkaisuista yms.

Näiden vaatimustyyppien lisäksi on sitten neljäskin ulottuvuus, eli vaatimukset tai rajoitukset, jotka kertovat järjestelmän ympäristövaatimuksista, yhteensopivuuksia tai mitä muita määräyksiä ja standardeja pitää noudattaa (esim. lääkelaitteet). Tällä on vaikutuksia kumpaankin aiemmin mainittuihin teknisempiin vaatimustyyppeihin. Esimerkkinä se, mitä Android- / iOS-käyttöjärjestelmien versiota järjestelmän pitäisi tukea. Tämä rajaus vaikuttaa loppukäyttäjien lukumäärään ja on suoraan yhteydessä liiketoiminnallisiin vaatimuksiin.

En ole väittämässä, että kaikki vaatimustyypit pitäisi olla täydellisesti määritelty heti projektin alussa, vaan että yleiset ja suuremmat linjat pitäisi olla kunnossa. Vaikka ketterän kehityksen pitäisikin ottaa huomioon muuttuvat vaatimukset, niin se ei ole tekosyy linjattomuudelle.

Hyvää työpäivän jatkoa!