Beta

Vaatimukset (perinteinen hanke)

Pohjat

Ohjeet

Käyttäjätarinat perinteisessä hankkeessa

Hyvä vaatimusmäärittely

Hyvä vaatimusmäärittely on onnistuneen hankinnan perusedellytys. Vaatimusten määrittely on haastavaa, mutta se säästää projektin kuluissa, nopeuttaa hankkeen läpivientiä ja varmistaa vaadittujen ominaisuuksien tuottamisen.

Vaatimuksilla viestitään tarjoajille ja viime kädessä toteuttajalle, millaista ratkaisua ollaan hankkimassa. Vaatimusten määrittely luo perustan hankinnalle, se määrittelee miksi ja mitä tarpeita hankinnan tulee tyydyttää. Vaatimusten määrittely on osa mitä tahansa hankintalain alaista hankintaa. Se siis tulee tehdä riippumatta siitä hankitaanko palvelua, fyysisiä tuotteita tai tietoteknologiaa - ollaanko hankkimassa standardijärjestelmää, esikonfiguroitua järjestelmäratkaisua, pilviratkaisua tai hankkivan organisaation tarpeisiin räätälöityä erikoissovellusta.

Vaatimusmäärittelyn lähtökohtana on hanketoimeksiannossa määritelty kehityksen tarve, ongelma tai mahdollisuus.

Katso yleiskuvaus vaatimustenhallintaprosessista täältä.

Vaatimusten priorisointi MVP-ajattelulla

MVP:llä (Minimitoiminnallisuus, Minimum Viable Product) tarkoitetaan juuri riittävää määrää toiminnallisuutta, jolla palvelu on käytettävissä.

Vaatimusmäärittelyissä jokaiselle vaatimukselle annetaan tärkeys:

1 - Pakollinen: Vaatimus pitää olla mukana uudessa ratkaisussa

2 - Hyödyllinen: Vaatimuksesta on paljon hyötyä toiminnalle

3 - Toivottu: Vaatimus auttaa tekemistä, mutta ei ole välttämätön

Pakolliset vaatimukset muodostavat MVP:n, eli ilman näitä pakollisia vaatimuksia palvelua ei voida ottaa käyttöön. Toisaalta pakollisiin vaatimuksiin ei sisälly sellaisia ominaisuuksia, joita ilmankin palvelua voidaan käyttää. Tämä ei tarkoita sitä, että muiden tärkeystasojen vaatimuksia ei toteutettaisi, vaan tärkeys määrittää järjestyksen vaatimusten toteuttamiselle. Jos käyttöönoton aikataulu on kriittinen ja uhkaa ylittyä, voidaan erillisellä päätöksellä siirtää 2- ja 3-tärkeystason vaatimuksia ylläpitovaiheeseen.

Toiminnalliset ja ei-toiminnalliset vaatimukset

Perinteisessä hankkeessa vaatimukset kuvataan useimmiten ns. toiminnallisina ja ei-toiminnallisina vaatimuksina. Molemmat tulee huomioida.

Toiminnalliset vaatimukset

Toiminnalliset vaatimukset määrittelevät kehitettävän tai hankittavan järjestelmän käyttäytymistä tai toiminnallisuutta. Ne määrittelevät mitä palveluja ohjelmiston on tarjottava ja miten se käyttäytyy annetuissa tilanteissa.

Toiminnalliset vaatimukset kuvataan vaatimushierarkiana: Päätoiminnot on ylätason vaatimuksia, jotka jakaantuvat joukoksi ominaisuuksia.

Esimerkki

Ei-toiminnalliset vaatimukset

Ei-toiminnalliset vaatimukset määrittelevät rajoitukset ja reunaehdot toiminnallisille vaatimuksille. Ei- toiminnalliset vaatimukset eivät liity suoraan palveluihin vaan kertovat, mitä ehtoja järjestelmän on täytettävä, jotta toiminnalliset vaatimukset voidaan toteuttaa.

Tietojärjestelmän ei-toiminnallisia laatuvaatimuksia tarvitaan erityisesti suunnittelu- ja toteutustyön vaativuuden ja mitoituksen arvioimiseksi. Ei-toiminnallisia laatuvaatimuksia on laadittu useille eri alueille ja niihin on hyvä tutustua määrittelytyön käynnistyessä. Näitä ovat mm. SÄHKE-normi.

Huomioi tietoturva ja tietosuoja

Tietosuojan ja tietoturvan vaatimuspohjan sisällöillä tarkennetaan ja täsmennetään tietosuoja- ja salassapitoliitteessä asetettuja ehtoja. Tietosuojan ja tietoturvan oma vaatimuspohja sisältää tietosuojaan tai tietoturvaan vaikuttavalta hankinnalta edellytettäviä tietosuoja- ja tietoturvavaatimuksia. Pohjaa ei ole tarkoitus sellaisenaan liittää hankintaan mukaan. Siitä poimitaan tarpeelliset vaatimukset kunkin hankinnan vaatimusmäärittelyyn, jotka tulevat tarjouspyynnön ja sopimuksen liitteeksi. Varsinaisiin sopimusasiakirjoihin on myös sisällytettävä itse tietosuoja- ja salassapitoliite.

Tietoturvaan ja tietosuojaan liittyvät vaatimukset voivat olla joko toiminnallisia tai ei-toiminnallisia. Toiminnallinen tietoturvallisuuteen liittyvä vaatimus on tietoturvan varmistamiseksi tarvittava ominaisuus, esimerkiksi jos tietojen tulee olla vain kaupungin työntekijöiden käytössä tarvitaan tämän tietoturvapiirteen toteuttamiseksi järjestlemään tunnistus- tai sisäänkirjautumistoiminto. Ei-toiminnallinen tietoturva- tai tietosuojavaatimus voi liittyä esimerkiksi lokien sisältämiin tietoihin tai syötteiden laatutarkistuksiin.

Tietoturvan riskianalyysissä tehty riskienkäsittelysuunnitelma toimii syötteenä vaatimusluettelon tietoturvavaatimuksille. Tietosuojavaatimusten määrittelyssä puolestaan hyödynnetään vaikutustenarviointia ja riskianalyysia tai tietosuojan tarkistuslistaa.

Huomioi käyttö ja ylläpito

Ratkaisulinjauksessa määriteltyyn käytön ja ylläpidon järjestämistapaan ja palvelun ylläpitoon liittyvät vaatimukset tulee huomioida osana vaatimusmäärittelyjä.

Näitä ovat esimerkiksi:

Vaatimukset palvelun tavoitettavuudelle ja luotettavuudelle
Palvelun järjestämiseen liittyvät vaatimukset (jos hankitaan pilviratkaisua, myös ratkaisun tyyppi)

Nämä vaatimukset ohjaavat toimittajan kanssa tehtävän käyttö- ja ylläpitosopimuksen ehtojen (kuten SLA) määrittelyä.

Alustava vaatimusmäärittely

Jotta johto-/ohjausryhmä voi antaa luvan käynnistää hankinnan valmistelu, on vastaavien vaatimusten oltava selvillä hyvällä alustavalla tasolla. Ne ovat tärkein hankinnan kohdetta kuvaava sisällöllinen liite itse hankintailmoituksessa, joita vasten tarjoaja esittää tarjouksensa. Vaatimuksia tuetaan joko käyttötapauskuvauksilla, tai vastaavasti käyttäjätarinoilla.

Vaatimusmäärittely käynnistysvaiheessa

Käynnistysvaiheessa tehdään tarkemmat vaatimusmäärittelyt toteutuksen hankintaa varten. Viimeistään kun työstetään hankintailmoitusta ja sen liitteitä, hankkeen vaatimusten tulee olla lopullisella tasolla. Hankintailmoitus on liitteineen sitova ja vaatimukset ovat tärkein hankinnan kohdetta kuvaava sisällöllinen liite.

Tässä vaiheessa vaatimukset on siis viimeisteltävä huolella, koska jälkikäteen niitä ei voi enää kilpailutuksen osalta muuttaa. Liian tiukat tai tarpeesta ohi menevät vaatimukset voivat myös johtaa siihen, että soveltuvimmat tarjoajat jättävät tarjoamatta tai osallistumatta.

Vaatimusmäärittely totetusvaiheissa

Toteutusvaiheissa alkuperäisiä vaatimuksia tarkennetaan edelleen toteutuksen edetessä. Siltä osin kuin vaatimusten tarkentuminen muuttaa hankkeen laajuutta, eli sisältöä tai luonnetta vaatimusten muuttuminen on osa muutoksenhallintaa. Kun hankkeen kokonaissisältö muuttuu tarkentuneiden vaatimusten seurauksena oleellisesti, kyse on johto/ohjausryhmän päätöksenteosta.

Lisätietoa

Tarkempia ohjeita vaatimusmäärittelyjen tekemiseen löytyy esimerkiksi täältä:

Luonnos