Oikeanlaisella vaatimusmäärittelyllä pidät kustannukset hallinnassa
![](https://www.itewiki.fi/write/post_images/26566.png)
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.
![Graniitti Services Oy logo](https://www.itewiki.fi/thumb.php?src=https://www.itewiki.fi/write/logos/graniitti-services.png&size=x96)
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 - Senior developer
- Laura - IT Manager (F-35 Programme)
- Efima Oyj - Senior Solution Consultant, Microsoft Dynamics 365 Finance
- Laura - Director, Risk
- Laura - Senior Embedded Software Engineer
- Nordea - Sr IT Analyst - Adobe/SAS Marketing Automation
- Laura - Tietoanalyytikko, tietohallinto, yli 12kk
Premium-asiakkaiden viimeisimmät referenssit
- 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
- Altoros Finland Oy - Virtuaalinen tekoälyavusteinen kävelykierrosopas
- Softlandia Oy - Framery luottaa Softlandian osaamiseen vaativissa innovaatioprojekteissa
- SprintIT Oy - Näin Tele-Tukku vähensi manuaalista työtä ja säästi rahaa Odoon avulla
Tapahtumat & webinaarit
- 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
- Softlandia Oy - Arto Nyberg haastatteli Softlandian toteuttamaa tekoälyä
- Aveso Oy - IFS Cloud 24R1 julkaisun uudistukset
- Timeless Technology - Tempmate-GM2 dataloggeri kuljetusolosuhteiden ja -reitin seurantaan pilvipalvelulla.
- Maxtech - Maxtechin uudistuksilla etenkin teollisuuden työvuorosuunnittelu on entistäkin tehokkaampaa
- Softlandia Oy - Tekoälymoottori – sitä parempaa automaatiota
- Ready Solutions Oy - Data-alustan modernisaatio ja uudet vaatimukset
- Timeless Technology - Tietoliikenteen talteenotto ja analyysi.
![]() |
Digitalisaatio & innovaatiot blogimediaBlogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä |