5.1 Vaatimukset ja tarkoituksenmukaisuus

Minkään tuotteen, ratkaisun tai palvelun kehittäminen ei pitäisi alkaa ilman selkeästi määriteltyjä liiketoiminnallisia tarpeita ja tarkoituksenmukaisuuden tarkastamista. Selvitysten yksityiskohtia voidaan parannella matkan varrella, mutta oleellista on, että perusvaatimukset määritellään ennen kuin kehittäminen alkaa. Sen vuoksi vaatimusten määrittely on olennainen osa kehityspyyntöä, ja vaatimukset muodostavat kuvauksen, jonka pohjalta ratkaisu, tuote tai palvelu rakennetaan.

Vaatimusten keräämisen ja hallinnan menetelmät riippuvat valitusta kehitystavasta.

Kuten alla oleva kaavio osoittaa, jatkuvan kehityskulun menetelmässä resurssien määrän oletetaan olevan kiinnitetty ja kestoa rajoittavat sovitut aikaikkunat. Tämän vuoksi vaatimukset (tai ominaisuudet) ovat joustavia. Projektoidun kehityskulun menetelmää käytettäessä vaatimukset ja aika ovat kiinteitä, ja sen sijaan resurssien määrä vaihtelee.

Kuva 5.1.1 Projektoitu ja jatkuva kehittämistapa

 

Projektoitu kehityskulku

Projektoidun vaiheittaisen kehityskulun (eng. sequential development) menetelmässä suurin osa vaatimuksista määritellään ja viimeistellään ennen kuin kehittäminen alkaa. Näin voidaan määrittää projektin tavoite ja laatia kattava projektisuunnitelma. Lähestymistapa toimii hyvin silloin, kun liiketoiminnan vaatimukset ovat selkeät ja tavoitteet määritetty. Jos kehittämisen aloittamisen jälkeen tarvitaan muutoksia, on kuitenkin riskinä, että tuotokset perustuvat vanhentuneisiin vaatimuksiin eivätkä siten palvele liiketoiminnan lopullisia tavoitteita. Lisäksi muuttuneet vaatimukset voivat aiheuttaa viiveitä tai ylimääräisiä kustannuksia muutosten ja korjausten takia.

Kuva 5.1.2 Projektoitu kehittäminen

 

Seuraavat vaatimukset pitäisi olla dokumentoituna ennen kehittämisen aloittamista:

  • Liiketoimintavaatimukset, jotka selventävät, mitä liiketoimintakyvykkyyksiä ja niiden muutoksia tavoitellaan – ”miksi” ja ”miten”.
  • Vaatimukset lopputuotoksille selventämään sidosryhmien odotuksia – ”miten” ja ”milloin”.
  • Vaatimukset ratkaisulle, jotta saadaan kuvaukset ratkaisun ominaisuuksista, toiminnallisuuksista ja ominaispiirteistä.
  • Ei-toiminnalliset vaatimukset, jotta voidaan ennakoida laajuus-, suorituskyky-, tietoturva- ja käytettävyysvaatimukset sekä skaalautuvuus, ylläpidettävyys ja palveluaspektit.
  • Vaatimukset projektille, jotta voidaan suunnitella tehtävät, vaiheistukset, osaamisvaatimukset ja muut ehdot.
  • Vaatimukset tuotantoon siirrolle, jotta voidaan rakentaa tarvittavat valmiudet palvelun tuotantokäyttöä varten.
  • Laatuvaatimukset, joiden avulla varmistetaan hyväksymiskriteereiden täyttyminen.
  • Salkusta tulevat vaatimukset, jotta huomioidaan muista projekteista johtuvat odotukset, oletukset, riippuvaisuudet ja rajoitukset.

Bisneskehittäjät (eng. Business Analyst, BA) analysoivat, määrittelevät, dokumentoivat ja hallinnoivat vaatimuksia. He tunnistavat liiketoiminnan tarpeet, ja heidän vastuullaan on dokumentoida ja priorisoida vaatimuksia sidosryhmien kanssa. Bisneskehittäjät vastaavat myös siitä, että projektit tuottavat liiketoimintahyötyjä.

 

Jatkuva kehityskulku

Jatkuvan täydentävän kehityskulun (eng. incremental development) menetelmässä ei käytetä ennakkoon täydellisesti laadittua vaatimuslistaa vaan palautetta ja tarpeita kerätään jokaisen kehitysvaiheen (tai iteraation) jälkeen. Ratkaisun osittainen käyttö ja siten myös arvontuotto aloitetaan jo varhain. Vaatimusten kerääminen tai tuottaminen on näin ollen hyvin joustavaa, ja tyypillisesti sidosryhmät ja kehitystiimit ottavat aktiivisen roolin uusien ominaisuuksien ja vaatimusten luomisessa käyttäjätarinoiden (eng. user story) muodossa.

Vaatimukset joustavat kehittämisen aikana löydettyjen uusien muotoiluideoiden ja muuttuvien tarpeiden mukaan. Dokumentointi pitäisi pitää kevyenä, ja siihen tehdään päivityksiä vain kehitystiimin todellisten tarpeiden perusteella. Tiimillä on selkeä käsitys tuotteen visiosta, jonka perusteella on tehty visuaalinen etenemissuunnitelma, joka auttaa haluttujen tulosten saavuttamisessa.

Jatkuvan kehityskulun menetelmä tuo nopeutta ja ketteryyttä, mutta menetelmä ei aina huomioi isompaa viitekehystä eikä liiketoimintamuutokseen tarvittavaa aikaa, ponnisteluja tai koordinointia.

Kuva 5.1.3 Jatkuva kehittäminen

 

Vaatimukset voidaan esittää esimerkiksi seuraavilla tavoilla:

  • Käyttäjätarinat (eng. user stories) ovat loppukäyttäjän näkökulmasta kirjoitettuja lyhyitä vaatimuksia tai pyyntöjä.
  • Kehitysaihiot (eng. epics) ovat isompia työkokonaisuuksia ja jaettavissa useisiin pienempiin tehtäviin, joita kutsutaan tarinoiksi.
  • Aloitteet ovat kehitysaihiokokoelmia, jotka tähtäävät yhteiseen tavoitteeseen.
  • Teemat ovat organisaation läpi ulottuvia isompia fokusalueita.
  • Hyväksymiskriteerit ovat ehtoja hyväksynnän saavuttamiseksi.
  • Ei-toiminnalliset vaatimukset kuvaavat, kuinka järjestelmä toimii.

Kehityspäällikkö / tuoteomistaja on vastuussa vaatimusten tarkastamisesta, hyväksymisestä ja hallinnoinnista tuotteen kehitysjonossa. Tavoitteena on maksimoida kehitystiimien työn tuloksena syntyvän tuotteen hyöty.

 

Tarkoituksenmukaisuus

Valitusta kehittämismenetelmästä riippumatta tarkoituksenmukaisuuden (eng. feasibility) ja toteutuskelpoisuuden testaaminen auttaa välttämään kalliita virheitä ja vähentää riskejä tuotantoon siirrossa. Se myös antaa paremmat mahdollisuudet taata käyttäjätyytyväisyys ja toteuttaa suunnitellut hyödyt.

Tarkoituksenmukaisuuden ja toteutuskelpoisuuden testaaminen koostu muun muassa seuraavista toimenpiteistä:

  • Taloudellinen tarkoituksenmukaisuus varmistaa, että projektin kustannukset pysyvät hallittavissa olevissa ja taloudellisesti kannattavissa mittasuhteissa kehittämisen, toteutuksen, tukipalveluiden ja ylläpidon osalta. Odotettujen liiketoimintahyötyjen pitäisi paitsi korvata kustannukset myös tuottaa jotain ylimääräistä.
  • Tekninen toteutuskelpoisuus varmistaa, että suunniteltu ratkaisu sopii bisnesteknologiatoiminnon strategiaan, etenemissuunnitelmiin ja kokonaisarkkitehtuuriin. Samalla tulee varmistaa, että suunniteltu tekninen ratkaisu täyttää toiminnalliset ja tekniset vaatimukset.
  • Toimituksellinen kyvykkyys varmistaa, että oikeat resurssit, osaamiset ja kyvykkyydet ovat käytettävissä kehittämisketjun läpi aina tuotannossa pyörivään palveluun asti.

 

Taloudellinen tarkoituksenmukaisuus

Projektoidussa kehittämisessä hyötylaskelma tehdään suunnittelujakson aikana keräämällä vaatimuksia, vertaamalla ratkaisuja sekä arvioimalla arkkitehtuurista soveltuvuutta ja kehittämiskuluja. Tarkastelun tuloksena löydetään usein uusia monimutkaisuuksia ja toiminnallisuuksia, jotka tuovat uusia huomioitavia kuluja ja riskejä. Hyötylaskelma määrittää koko projektin tarkoituksenmukaisuuden, joka voi johtaa projektin laajuuden muutoksiin tai jopa projektin lopettamiseen.

Jatkuvassa kehittämisessä ei käytetä etukäteen kokonaan määritettyjä vaatimuksia tai toiminnallisuuksia. Sen vuoksi hyötylaskelma tehdään arvovirtakohtaisesti eikä tietylle projektille. Arvovirtaperusteinen rahoittaminen ei edellytä kehitysaloitteiden osalta merkittävää taloudellista esiselvitystä ja seurantaa, mikä nopeuttaa kehityskulkua.

Hyötylaskelmasta tulee ilmetä selvästi suunnitellut liiketoimintahyödyt. Seuraava lista esittelee seitsemän tyypillistä liiketoimintahyötyä:

  • myyntitulojen kasvu
  • myyntikatteen kasvu
  • laadun ja liiketoiminnan jatkuvuuden kasvu
  • liiketoimintavalmiuden kasvu
  • vähentyneet tuotantokustannukset
  • vähentyneet rahoituskustannukset
  • vähentyneet toiminnan kulut
  • vähentyneet riskit.

 

Tekninen toteutuskelpoisuus

Kehittämisessä täytyy ottaa huomioon ratkaisuarkkitehtuurin vaatimukset. Näin pystytään ottamaan huomioon tekniset vaatimukset, joihin kuuluu tyypillisesti muun muassa seuraavat asiat:

  • Sovellusarkkitehtuuri, joka määrittelee miten eri komponentit toimivat.
  • Integraatioarkkitehtuuri, joka määrittelee, miten yksittäiset komponentit tai palvelut toimivat keskenään, mukaan lukien linkit ulkopuolisiin järjestelmiin ja palveluihin.
  • Tietoarkkitehtuuri (data-arkkitehtuuri), joka määrittelee, miten dataa kerätään, jäsennellään, jaetaan ja hallitaan.
  • Tietoturva-arkkitehtuuri, joka määrittelee, kuinka sovellus suojataan ja kuinka säädöksistä tai laista tulevia määräyksiä noudatetaan.
  • Infrastruktuuri, joka määrittelee, mihin tuotannolliseen ympäristöön ratkaisu sijoitetaan ja miten sitä tuetaan sovitun mukaisella käytettävyystasolla.
  • Palvelujohtaminen, joka määrittelee, miten ratkaisua hallitaan ja tuetaan käyttöönoton jälkeen.

Arkkitehtuurinen tarkoituksenmukaisuus ja toteutuskelpoisuus tuo suunnitteilla olevalle ratkaisulle uskottavuutta. Projektimainen vaiheittainen kehittäminen tarjoaa tarkastelulle tyypillisesti enemmän yksityiskohtia kuin jatkuva täydentävä kehittäminen, jossa ratkaisu tarkentuu vasta kehittämisen aikana. Jatkuvan kehityskulun mallissa on kuitenkin myös tarpeellista kattaa riittävä määrä yksityiskohtia, jotta kokonaisratkaisulle saadaan riittävä uskottavuus.

Jatkuvan kehityskulun mallissa arkkitehtuurisuunnitelmaa voi myös testata kehittämisen alussa käyttämällä prototyyppejä sekä suunnittelemalla ja toteuttamalla vaikeimmat tekniset toiminnallisuudet jo varhaisessa kehitysvaiheessa. Tämä mahdollistaa tunnistettujen ongelmien korjaamisen aikaisessa vaiheessa. Toisaalta projektoitu kehittäminen nojautuu yleensä vakioituihin ratkaisuihin käyttöönottovaiheessa ja sisältää näin ollen vähemmän riskejä.

 

Tuotantoonsiirtokelpoisuus

Tuotosten laatu riippuu usein kehitystiimien osaamisesta ja kyvyistä hallita koko kehittämisketjua. Tarvittavan osaamisen tunnistaminen ja oikeanlaisen osaamisen hankinta tiettyihin rooleihin ja tiimeihin on sen vuoksi tärkeää jo suunnitteluvaiheessa.

Käytettäessä ulkopuolisia resursseja on tärkeää käyttää arviointikriteereitä, jotka auttavat valitsemaan luotettavia ja osaavia kumppaneita. Yleisesti käytettyjä arviointikriteereitä ovat muun muassa seuraavat: työnantajan koko, osaamisalue, aiemmat ja nykyiset asiakasreferenssit, kulttuurinen sopivuus, hyöty vs. kustannukset, maantieteellinen sijainti ja resurssien saatavuus.