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
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:
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ä.
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:
Ohjelmistokehityspäällikkö / tuoteomistaja on vastuussa vaatimusten tarkastamisesta, hyväksymisestä ja hallinnoinnista tuotteen kehitysjonossa. Tavoitteena on maksimoida kehitystiimien työn tuloksena syntyvän tuotteen hyöty.
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ä:
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ä:
Kehittämisessä täytyy ottaa huomioon ratkaisuarkkitehtuurin vaatimukset. Näin pystytään ottamaan huomioon tekniset vaatimukset, joihin kuuluu tyypillisesti muun muassa seuraavat asiat:
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ä.
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.
