VAATIMUSMÄÄRITTELY

Motto: Erinomaisesti tehty järjestelmä ei ole mistään kotoisin, jos se toteuttaa väärät toiminnot.

Yleistä

Kehitystyön edetessä tarvitaan jatkuvasti seuraavia dokumentteja, joiden on ehdottomasti oltava erinomaisesti laadittuja:

Toimittajan kannalta on tärkeää, että vaatimusmäärittely on niin yksityiskohtainen, että kehitystyö voidaan perustaa sille. Asiakkaan kannalta on tärkeää, että käyttäjien kaikki tärkeimmät vaatimukset on kirjattu riittävän yksityiskohtaisesti ja että toimittaja ymmärtää ne selvästi. Vaatimusmäärittelyn tulee sisältää tarkka ja virheetön kuvaus, jossa on huomioitu

Joidenkin tutkimusten mukaan vaatimusmäärittelyssä olevan virheen korjaaminen vasta sitten, kun järjestelmä on jo käytössä, on vähintään 50 kertaa kalliimpaa kuin virheen korjaaminen jo vaatimusmäärittelyä laadittaessa.

Vaatimusten käsittelyn (requirements engineering, RE) osatehtävät ovat vaatimusten laatiminen ja vaatimusten hallinta. Vaatimusten laatiminen sisältää vaatimusten selvittämisen (elicitation), vaatimusten analysoinnin ja mallintamisen, vaatimusten dokumentoinnin ja vaatimuksista sopimisen ja niiden tarkastamisen.

Hyväksyminen tulee aikanaan perustumaan vaatimusmäärittelyyn. Hyväksymistestin suunnitelma onkin syytä laatia samalla, kun laaditaan vaatimusmäärittelyä.

Vaatimusmäärittelyn sisältö

Vaatimukset on ilmaistava mitattavissa tai todennettavissa olevina määrityksinä. Jokainen vaatimus on ilmaistava yksityiskohtaisesti ja tarkasti. Jos jonkin seikan suhteen ei ole vaatimuksia, niin myös tämä on ilmaistava selkeästi.

Esimerkki sisällysluetteloksi:

  1. Yleiskatsaus
  2. Viitteet
  3. Määritelmät
  4. Toiminnallisuuteen kohdistuvat vaatimukset
    • toimintovaatimukset (käyttäjän kannalta): kaikki toiminnot syötteiden, tulosten ja laskentojen tarkkuudella
    • yhteensopivuus
    • sovellusalueen standardien, säännösten tai yleisten tapojen noudattaminen
    • turvallisuus
    • toimintaympäristö
  5. Luotettavuuteen kohdistuvat vaatimukset
    • kypsyys
    • vikasietoisuus
    • toipumiskyky
  6. Käytettävyyteen kohdistuvat vaatimukset
    • ymmärrettävyys
    • opittavuus
    • operoitavuus
  7. Tehokkuuteen kohdistuvat vaatimukset
    • ajankäyttö
    • muiden resurssien käyttö
  8. Ylläpidettävyyteen kohdistuvat vaatimukset
    • analysoitavuus
    • muunneltavuus
    • stabiilisuus
    • testattavuus
  9. Siirrettävyyteen kohdistuvat vaatimukset
    • liitettävyys
    • asennettavuus
    • siirrettävyyteen liittyvien standardien noudattaminen
    • korvaavuus

Luotettavuusvaatimusten täytyy lausua asia käyttäjän näkökulmasta ja niiden pitää olla todennettavissa. Esimerkiksi seuraavat eivät ole hyväksyttäviä:

Tiukka vaatimus on paitsi työläs täyttää myös työläs todentaa. Vaatimukset voivat myös vaihdella järjestelmän eri osissa, koska toiset osat ovat yleensä kriittisempiä kuin toiset.

Vaatimusmäärittelyn laatiminen

Asiakkaalla voi olla vaatimusmäärittely valmiina, jolloin voidaan käynnistää suoraan katselmusmenettely, jolla varmistetaan, että vaatimusmäärittely on asianmukainen. Vaikka asiakas luulee tietävänsä millainen järjestelmän tulee olla niin useimmiten tämä "tieto" ei kuitenkaan ole oikea. Vaatimukset muuttuvat, kun asiaa ajatellaan pohjamutia myöten ja kun järjestelmän toiminta alkaa hahmottua yksityiskohdiltaan.

Vaatimusmääritelyä tehtäessä joudutaan tietoja usein lypsämään tilaajalta, sillä monesti vaatimus voi olla alitajuinen, hyväksymätön, nolostuttava tai vaikea löytää. Vaatimusmäärittelyn teko voi sisältää asiakkaan kouluttamisen käytettävien menetelmien ja kuvaustapojen käyttöön. Asiakaskeskeinen toiminta voi aiheuttaa myös ongelmia. Kontrolli voi karata järjestelmän rakentajilta asiakkaalle, voi syntyä aikataulu- ja budjettiongelmia tai jotkin osa-alueet saattavat ylikorostua. Lisäksi on olemassa "ryhmä-ajattelun" ja konservatismin vaara.

Vaatimusten selvittäminen

Järjestelmälle asetettavien vaatimusten selvillesaamiseksi on selvitettävä erilaisia erilaisia asioita. Tällaisia ovat mm.

Vaatimusten selvittämiseksi voidaan käyttää erilaisia menetelmiä:

Eri menetelmät sopivat erilaisiin tilanteisiin ja täydentävät toisiaan. Jokaisessa projektissa onkin valittava sopiva menetelmien joukko.

Vaatimusten analysointi ja mallintaminen

Mallintamisen syitä:

Mallintamisen kohteita:

Mallintamisen tekniikoita:

Toiminnallisten vaatimusten mallintaminen, esim:

Ei-toiminnallisten vaatimusten mallintaminen, esim:

Usein tarvitaan joukko erilaisia malleja eri asioista. UML (Unified Modeling Language) on mallinnuskieli, joka tukee koko elinkaarta ja jolle on olemassa eri toimittajien valmistamia välineitä. Ne sisältävät erilaisia kaaviotyyppejä, kuten käyttötapauskaavio, luokkakaavio, oliokaavio, komponenttikaavio, sijoittelukaavio, sekvenssikaavio, yhteistyökaavio, tilakaavio ja toimintokaavio.

Vaatimusten analysointia use case -analyysia käyttäen on käsitelty tarkemmin sivulla käyttötapausanalyysi.

Vaatimusten dokumentointi

Vaatimusmäärittelyn on oltava yksiselitteinen, täydellinen, ristiriidaton, todennettavissa oleva, muutettavissa oleva, jäljittyvä ja käyttökelpoinen ylläpidon aikana. Kustakin vaatimuksesta on kirjattava kaikki tarpeelliset tiedot. Tällaisia tietoja ovat esimerkiksi

Tiedot voidaan säilyttää tekstidokumenttina tai tietokannassa.

Vaatimukset on priorisoitava. Priorisointiasteikko voisi olla esimerkiksi:

  1. Välttämätön
  2. Hyödyllinen
  3. Mahdollinen

Vaatimuksista sopiminen ja niiden tarkastaminen

Vaatimusmäärittelyn täydellisyydestä ja oikeellisuudesta varmistutaan tekemällä vaatimusmäärittelylle muodollinen tarkastus. Tarkastuksen tarkoituksena on validoida vaatimusmäärittely. Tarkastajina on ehdottomasti oltava käyttäjien edustajia. Toimittajan edustajien tehtävä on lähinnä tarkastaa se, että kaikki tarvittavat asiat ovat mukana. Myös mahdolliset ristiriidat sovitetaan tarkastusmenettelyn avulla.

Vaatimusten hallinta

Vaatimusten hallinnan ongelmia ovat esimerkiksi vaatimusten sekalaisuus, erilaiset muutokset ja vaatimusten ristiriitaisuus.

Vaatimusmäärittelyn tekemisessä on huomioitava mm. seuraavat asiat:

Edellisistä seuraa, että vaatimusmäärittely on asetettava versiohallinnan alaisuuteen ja että vaatimusmäärittelyn jäljitettävyyteen on kiinnitettävä erityistä huomiota.

Pienten järjestelmien vaatimusten hallinta voidaan toteuttaa yleiskäyttöisillä välineillä (tekstinkäsittely, taulukkolaskenta, tietokanta). Kyseisten välineiden käyttö vaatii kuitenkin suunnittelua ja kurinalaista työskentelyä. Lisäksi ylläpito on hankalaa.

Vaatimusten hallintaan on saatavilla myös erityisvälineet (CORE, DOORS, RequisitePro, ...), jotka tarjoavat aidon tuen vaatimusten hallinnalle. Kyseisille välineille on kuitenkin usein suuri käyttöönottokynnys.

Hyväksyminen

Hyväksymistestissä järjestelmää verrataan vaatimusmäärittelyyn. Hyväksymistesti onkin pääpiirteissään suunniteltava samalla kun laaditaan vaatimusmäärittely. Vaatimusmäärittelyn tapaan myös hyväksymistestin laatiminen ja suorittaminen on asiakkaan vastuulla ja toimittajalla on vain avustava tehtävä.

Hyväksyminen voidaan jakaa seuraaviin vaiheisiin:

  1. Hyväksymistestin suunnittelu. Suunnittelun tekee asiakas projektipäällikön avustuksella. Projektin johtoryhmä hyväksyy suunnitelman. Tässä vaiheessa määritellään hyväksymisperusteet (vaatimusmäärittelyn pohjalta), tarvittavat resurssit (henkilöt, laitteet, apuohjelmat), aikataulu ja yksityiskohtaiset toimintaohjeet.
  2. Ohjelmiston asennus (yleensä) asiakkaan koneelle. Asennuksen tekee toimittaja.
  3. Hyväksymistestin suoritus. Testin tekee asiakas projektipäällikön avustuksella.
  4. Kirjallisen hyväksynnän antaminen. Hyväksynnän antaa asiakas.

Vain jäsenille: