Oikeanlaisella vaatimusmäärittelyllä pidät kustannukset hallinnassa
Vaatimusmäärittely tehdään hankintaa varten.
Toteutusvaiheessa tuotetaan rakentamista varten määrittely- ja suunnittelun kuvauksia, jotka perustuvat vaatimusmäärittelyyn ja täsmentävät sitä. Hankinnan taustalla on jokin toiminnan tarve, jonka ratkaisemiseen tarvitaan tietojärjestelmäuudistusta.
Mitä toiminta tarkalleen tarvitsee? Minkä osan hankittava tietojärjestelmä siitä toteuttaa?
Toiminnan tarve voidaan kuvata kolmen periaatteen mukaisesti:
1. käyttäjälähtöisesti
niin, että kaikki oleelliset käyttötilanteet (käyttötapaukset) tulevat ilmi
2. systemaattisesti
siten, että kaikki potentiaaliset toimittajat ymmärtävät “pihvin” oikein
3. kattavasti
niin, että kuvaus kattaa toimintaprosessin tarvittavat toiminnot.
Näin toimittajat osaavat tarjota omien lähtökohtiensa perusteella parasta ratkaisua ja tarjousten vertailu on helppoa ja tasapuolista.
Parhaassa tapauksessa toimitus suunnitellaan niin, että pilotointi ja käyttö voidaan tehdä vaiheittain. Tällöin kokemuksia ja hyötyjä saadaan heti alusta alkaen. Tämä edellyttää, että toiminnan kannalta tärkeimmät kokonaisuudet on tunnistettu vaatimusmäärittelyn yhteydessä.
Vaaran merkit, tunnista ja eliminoi!
Seuraavat piirteet johtavat usein epäonnistuneeseen ratkaisuun:
1. On kuvattu erilaisia piirteitä, joita järjestelmän tulisi toteuttaa.
Ei kuvata käyttäjien tarpeita, vaan osajoukko jostakin ratkaisusta perustuen oletettuun toteutustapaan.
Kuvaukset eivät ole systemaattisia ja kuvaustapa vaihtelee.
2. Osa kuvauksista liittyy vanhan järjestelmän toimintoihin ja määrityksiin.
Esim. näyttökuvia, vanhan järjestelmän kerrosarkkitehtuuripiirros, nykyisen tietokannan tietomalli tai yksittäisten toimintojen toteutustasoisia määrityksiä (jopa ohjelmiston lähdekoodia).
Kuvitellaan, että mitä yksityiskohtaisempia määrityksiä, sen parempi.
3. Exceliin on laadittu vaatimusluettelo, johon tilaajan eri henkilöt ovat listanneet lyhyesti toivomuksiaan uusina haluttuina piirteinä.
Luettelon rivit on kuvattu yhteen excelin soluun eikä ole kokoavaa kuvausta, josta ilmenisi toiminnallinen kokonaisuus, johon vaatimus liittyy (esim. käyttötilanne).
Jälkikäteen ei tiedetä, mistä kukin vaatimus on lähtöisin. Jos järjestelmän rajaus muuttuu, niin ei pystytä nimeämään, mitkä vaatimukset ovat sen jälkeen relevantteja.
4. Kaikki vaatimukset on merkitty pakollisiksi.
Jos vaatimusluettelo on vaikeasti tulkittava, on yksinkertaisinta (ja nopeinta) merkitä kaikki pakolliseksi.
5. Kuvausten ja vaatimusten kattavuudesta ei voida olla varmoja.
Jos toimintaprosesseja ja käyttötapauksia ei ole käyty systemaattisesti läpi, niin kuvaukset ja vaatimukset perustuvat siihen mikä on tullut mieleen.
6. Järjestelmän rajausta ei ole kuvattu täsmällisesti. Mistä järjestelmä vastaa ja miten se liittyy muihin järjestelmiin?
Eri käyttäjäryhmillä on eriävä käsitys siitä, mitä ajatellaan kuuluvan järjestelmään. Joku ajattelee sen rekisterinä, toinen laskentajärjestelmänä, kolmas asiointijärjestelmänä ja neljäs asianhallintajärjestelmänä.
7. Väärä mielikuva ketterästä kehittämisestä.
Ei kuvauksia tarvita, vaan asiat ratkaistaan ketterän toteutusvaiheen aikana!”
8. Ei-toiminnallisia vaatimuksia ei ole tunnistettu ja kuvattu
Toimintaympäristö saattaa asettaa vaatimuksia, mitkä olisi hyvä tuoda esille jo tarjouspyyntövaiheessa. Tiedossa voi olla esimerkiksi, että on tiettyinä aikoina vuodessa suorituskyky on koetuksella, tai voi olla tiettyjä toimialaan liittyviä regulaatioita ja muita säännöksiä, jotka on otettava huomioon
Keskity kokonaiskuvaan
Älä jumitu yksityiskohtiin. Hyvään lopputulokseen tarvitaan:
- Kokoava jäsennys siitä, mitä toimintaa tietojärjestelmän tulisi tukea.
Oleelliset käyttötilanteet tulee esittää systemaattisesti esim. käyttötapauksina, ei järjestelmän piirteinä. Aiempia kuvauksia ja toivelistoja voidaan käyttää työn tukena ja ne toimivat apumateriaaleina.
- Vaatimusluettelo
Vain osa vaatimuksista voi olla pakollisia ja jokaisesta vaatimuksesta tulisi tietää, mistä ne ovat peräisin. Vaatimusten kattavuus ja mahdolliset ristiriitaisuudet on tarkistettava. Toteutuksesta on syytä kuvata MVP (Minimum Viable Product) eli pienin toimiva tuote, jota voidaan käyttää toimintaprosessien tukena. Vaikka tietojärjestelmä toteutettaisiin ketterillä menetelmillä, vaatimukset pitää kuitenkin kuvata.
- Hankinnan kohteen kuvaus.
Hankinnan kohde tulee kuvata, jotta tilaajan eri käyttäjäryhmät ovat yksimielisiä hankinnasta ja toimittajat osaavat tarjota hyviä ratkaisuja. Jos asioita jätetään auki ketterään toteutusprojektiin, niin silloin tilaajan on varattava aikaa kysymysten ratkaisuun toteutusprojektin aikana. Avoimiin asioihin pitää ottaa silloin kantaa ja tilaajan edustajan on osattava kertoa kaikkien käyttäjäryhmien tarpeet. Tilanne voi eskaloitua ja valmistuminen viivästyä, koska tyypillisesti tilaajan edustaja osallistuu toteutusprojektiin vain muiden töidensä ohessa. Etukäteen systemaattisesti kuvatuilla vaatimuksilla helpotetaan toteutusprojektia, jossa voidaan keskittyä tarkemman toteutuksen määrittelyyn ja suunnitteluun.
- Käyttäjiä
Keskeistä on käyttäjälähtöisyys. Liiketoiminnan edustajat kuvaavat tarpeet ja kokenut vaatimusmäärittelijä koostaa riittävän kuvauksen, jolla päästään hankinnan valmisteluun. IT-asiantuntija ei osaa kuvata toiminnan tarpeita ja toiminnan edustajat eivät ole rutinoituneita vaatimusmäärittelyssä. Siksi vaatimusmäärittely kannattaa tehdä vuorovaikutteisesti yhdessä eri sidosryhmien ja erillisen vaatimusmäärittelijän kanssa.
Lisätietoja
Tagit
Liiketoimintaprosessi
Projektinhallinta |
Toimialakokemus
Asiantuntijapalvelut | |
Julkishallinto | |
Järjestöt ja yhdistykset |
Omat tagit
Graniitti Services - Asiantuntijat ja yhteyshenkilöt
Graniitti Services - Muita referenssejä
Graniitti Services - Muita bloggauksia
It- ja ohjelmistoalan työpaikat
- Laura - DevOps Engineer
- Laura - Senior ohjelmistokehittäjä
- Laura - Product Designer, Game Development Tools & UX
- Nordea - Technology Business Risk Manager
- Nordea - Senior IT Analyst in SWIFT area
- Frends iPaaS - Global Digital Marketing Manager | 4.5K-5.3K€/month
- Laura - Senior developer
Premium-asiakkaiden viimeisimmät referenssit
- TNNet Oy - TNNet tuntee Viherlandian IT-infran 20 vuoden ajalta
- Nodeon - Ratikka luo kasvua Vantaalle
- Sulava Oy - Business Finland: Tavoitteena puhdas Azure-pohjainen pilviympäristö
- Wunder - Metsanhoidonsuositukset.fi – onnistunut digiloikka painetuista oppaista innovatiivisiiin rajapintaratkaisuihin
- Wunder - Tikkurila – Sirpaleisesta saumattomaan digiin
- Wunder - Ara uudisti sivustonsa yhdessä Wunderin kanssa
- Red & Blue Oy - Chiller Oy:n kasvumarkkinointi
Tapahtumat & webinaarit
- 20.09.2024 - AamuAreena 20.9.2024: Data-avaruudet ja niiden hyödyntäminen
- 10.10.2024 - Palvelumuotoilu johtamisessa ja transformaatiossa
- 10.10.2024 - Miten tekoäly mullistaa digitaalisen asiakaskokemuksen?
- 30.10.2024 - Nordic NetSuite Summit 2024
- 19.11.2024 - The Future of Software - Embracing Collaboration in an AI-Powered World
Premium-asiakkaiden viimeisimmät bloggaukset
- Maxtech - Aluerajoitettu työaikakirjaus tekee työajanseurannasta hallittavampaa
- Maxtech - Aluerajoitettu työaikakirjaus tekee työajanseurannasta hallittavampaa
- TietoPiiri Oy - Osaamispankki - järjestön tehtävien ja vapaaehtoisen työvoiman kohtaamiseksi
- TietoPiiri Oy - Lahjoitusten integrointi kirjanpitoon - järjestön CRM TP FONSIN superkyky
- TNNet Oy - Tutustu: Tietoturvakoulutus ja hyökkäyssimulaatio
- Timeless Technology - Tuoteuutuus: ControlByWeb® Quick-Connect Sensor™ lämpötilan valvontaratkaisu.
- Identio Oy - Julius Rajalasta Idention operatiivinen johtaja
Digitalisaatio & innovaatiot blogimediaBlogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä |