Useimmiten uuden IT-ratkaisun määrittelytyö keskittyy ratkaisun toiminnallisiin vaatimuksiin: Tietojärjestelmältä haluttuja toimintoja kuvataan käyttäjätarinoiden (user story), käyttötapausten (use case) ja käyttöliittymän näköismallien (wireframe / mockup) avulla. Toiminnalliset vaatimukset kuvaavat kattavasti ja yksityiskohtaisesti käyttäjän vuorovaikutuksen tietojärjestelmän kanssa. Ne määrittelevät, millä tavalla ja mitä syötteitä käyttäjä antaa tietojärjestelmään sekä järjestelmän antamat vasteet käyttäjän syötteisiin.
Tietojärjestelmän ei-toiminnalliset tai laadulliset vaatimukset (non-functional requirements) sen sijaan määrittelevät miten tietojärjestelmä antaa vasteet syötteisiin tai millainen se on. Ei-toiminnallisia vaatimuksia ovat esimerkiksi:
- Saatavuus (availability). Jos IT-ratkaisun tulee olla käytettävissä 99 % ajasta, saako se olla pois käytöstä 14 minuuttia päivässä vai yhtäjaksoisesti 3,5 päivää vuodessa? Miten IT-arkkitehtuurilla ja toimintatavoilla varmistetaan, että ratkaisun suunnitellut ylläpitotoimenpiteet ja yllättävät virhetilanteet hoidetaan saatavuusvaatimukset täyttäen?
- Skaalautuvuus (scalability). Jos IT-ratkaisu toimii 100 yhtäaikaisen käyttäjän kuormalla, niin toimiiko se samalla suorituskyvyllä myös 500 käyttäjän kuormalla? Miten IT-arkkitehtuurilla varmistetaan, että ratkaisu voidaan pienillä muutoksilla (infrastruktuuriin, alustaan tai sovellukseen) saada toimimaan myös 10 000 käyttäjän kuormalla?
- Siirrettävyys (portability). Jos IT-ratkaisu toimii Windows PC:llä, niin toimiiko se myös Applen Mac-tietokoneella (OS X), Samsungin Galaxy-puhelimella (Android) tai Nokian Lumia-puhelimella (Windows Phone)? Miten teknologiavalinnoilla varmistetaan ratkaisun alustariippumattomuus tai minimoidaan työ, joka vaaditaan ratkaisun siirtämiseen uudelle alustalle?
Muita ei-toiminnallisia vaatimuksia ovat esimerkiksi tietojärjestelmän tietoturvaan (security), käytettävyyteen (usablity), ylläpidettävyyteen (maintainability), räätälöitävyyteen (modifiability), integroitavuuteen (interoperability) tai suorituskykyyn (performance) liittyvät vaatimukset. Kuten yllä olevat esimerkit auttavat ymmärtämään, ei-toiminnalliset vaatimukset määrittelevät rajoitteita ja reunaehtoja tietojärjestelmän tekniselle toteutukselle ja hallinnoinnille.
Tietojärjestelmän ei-toiminnallisia vaatimuksia on haastavaa määritellä selkeästi, koska ne liittyvät järjestelmän sisäisiin ja teknisiin ominaisuuksiin. Uuden tietojärjestelmän vaatimuksia määriteltäessä kiinnostavat tyypillisesti eniten ratkaisun käyttäjälle tarjoamat toiminnot eli toiminnalliset vaatimukset. Kuitenkin ei-toiminnalliset vaatimukset voivat työmäärällisesti vastata useita kymmeniä prosentteja ratkaisun toteutuksen kokonaistyömäärästä.
Ei-toiminnallisilla vaatimuksilla on kriittinen rooli tietojärjestelmän laadun, luotettavuuden ja kustannustehokkuuden takaamisessa koko elinkaaren ajan. Panostus ei-toiminnallisten vaatimusten määrittelyyn heti alussa on tärkeää, koska ratkaisun toteutuksen jälkeen ei-toiminnallisia vaatimuksia voi olla hyvin työlästä tai jopa mahdotonta täyttää.
Realististen ei-toiminnallisten vaatimusten määrittelyyn tarvitaan yhdistelmä teknistä ja liiketoiminnallista ymmärrystä. Ei-toiminnalliset vaatimukset laatii tyypillisesti projektin suunnitteluvaiheessa IT-arkkitehti, joka tasapainottelee liiketoiminnan ja tietohallinnon tarpeiden sekä teknologian mahdollisuuksien välillä. Ei-toiminnallisten vaatimusten määrittelyssä tarvitaan kompromisseja ja vaatimusten välistä priorisointia (trade-off), koska useimmiten kaikkia vaatimuksia ei ole mahdollista toteuttaa käytössä olevilla rajallisilla resursseilla. Esimerkiksi ratkaisun suorituskyvyn parantaminen saattaa vähentää ratkaisun siirrettävyyttä tai integroitavuus saattaa vähentää tietoturvaa.
Yksinkertaistaen voisi sanoa, että ratkaisun toiminnalliset vaatimukset määrittelevät ratkaisun liiketoiminnallisen hyötypotentiaalin (prosessien mahdollistaminen, tehostaminen, tukeminen), kun taas ei-toiminnalliset vaatimukset määrittelevät ratkaisun luotettavuuden, kustannustehokkuuden ja teknisen mukautuvuuden tulevaisuuden tarpeisiin. Usein määrittelyvaiheessa eniten keskustelua herättävä ei-toiminnallinen vaatimus on järjestelmän saatavuus, jonka voidaan erityisesti liiketoimintakriittiselle järjestelmälle suoraviivaisesti vaatia olevan 100 %. Keskusteluun tuo perspektiiviä se, että AT&T:n puhelinverkko USA:ssa on ainut tekninen järjestelmä maailman historiassa, jossa on tiettävästi paikallisesti päästy 99,999 % saatavuuteen. Esimerkiksi Google tähtää palveluissaan 99,99 %:n saatavuuteen, mutta ei uskalla luvata käyttäjille sitäkään.
Lisätietoa:
The New York Times
Wikipedia
Haluatko saada lisätietoja tietojärjestelmien toiminnallisista tai ei-toiminnallisista vaatimuksista? Tutustu palveluihini ja kysy lisää!
Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.