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
- Nordea - Senior IT Analyst, Finnish language required
- Laura - DevOps Engineer
- Aveso Oy - ERP tekninen projektipäällikkö
- Aveso Oy - IFS ERP -konsultti
- Laura - Digiasiantuntija, PAMin keskustoimistoon Helsinkiin
- Nordea - Senior Test Automation Engineer with Python, Nordea Payments
- Nordea - Senior Manual Test Engineer, Nordea Payments
Premium-asiakkaiden viimeisimmät referenssit
- Valve - Helsingin yliopiston ylioppilaskunnan verkkopalvelun siirto WordPressiin
- Valve - Eezy Valmennuskeskuksen verkkokauppa-uudistus
- Valve - Danonen Nutricia ja Aptaclub -brändien sivustot
- Hellon - Identifying growth opportunities with global Moomin fans
- Hellon - Award-Winning Inclusive Customer Experience for Northern
- Hellon - Developing a Life-Saving App to Boost Blood Donations
- Hellon - Decarbonising Farming with Yara International
Tapahtumat & webinaarit
- 30.10.2024 - Nordic NetSuite Summit 2024
- 30.10.2024 - Webinaari: Hakukoneoptimointi on strateginen valinta
- 14.11.2024 - RoimaDay 2024
- 14.11.2024 - Verkkolaskufoorumin syysseminaari 2024
- 19.11.2024 - The Future of Software - Embracing Collaboration in an AI-Powered World
- 27.11.2024 - Green ICT -ekosysteemitapaaminen III: Ohjelmistojärjestelmien virrankulutuksen mittaaminen ja kasvihuonepäästöjen arviointi
Premium-asiakkaiden viimeisimmät bloggaukset
- Timeless Technology - Mihin koodittomat ohjelmoitavat logiikat soveltuvat automaatiossa?
- Efima Oyj - Copilot-tekoälyavustajat Dynamics 365 -sovelluksissa: Commerce ja Sales
- TietoPiiri Oy - Lahjoittajatutkimus 2024: some ja tuttavat ovat tärkeimmät tietolähteet
- Ready Solutions Oy - Azuren palvelut integraatioiden kehittämiseen
- Nordea - Kesätyö Nordealla antaa kokemusta opintojen tueksi ja vahvistusta urasuunnitelmiin
- Softlandia Oy - Konenäöllä eroon datan palastelusta RAG-toteutuksissa
- Timeless Technology - ControlByWeb IIoT-laitteet ja tuetut protokollat
Digitalisaatio & innovaatiot blogimediaBlogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä |