Tiivistetysti voidaan sanoa, että määrittelyvaiheen tehtävä on vastata kysymykseen mitä (eli mitä halutaan saada aikaan). Määrittelyvaiheessa asioita tarkastellaan asiakkaan (loppukäyttäjien) näkökulmasta. Tässä vaiheessa ei siis yleensä oteta kantaa toteutukseen liittyviin yksityiskohtiin, kuten millaista tietokantaa aiotaan käyttää tai tarvitaanko edes tietokantaa. Sen sijaan määrittelyvaiheessa on selvitettävä esimerkiksi, millaisilla laitteilla ja missä käyttöympäristöissä loppukäyttäjät haluavat tuotetta käyttää. Käytetäänkö tuotetta tietokoneella, tabletilla vai älypuhelimella? Tarvitaanko tuotetta liikkeellä ollessa tai ilman verkkoyhteyttä? Näiden vaatimusten perusteella voidaan myöhemmässä suunnitteluvaiheessa ratkaista, toteutetaanko tuote web-sovelluksena, mobiilisovelluksena, työpöytäsovelluksena vai näiden yhdistelmänä.

On kuitenkin hyvä huomata, että joskus tilaaja voi asettaa jo vaatimusmäärittelyvaiheessa myös toteutustapaa koskevia vaatimuksia. Tilaaja voi esimerkiksi edellyttää, että tuotteesta tehdään nimenomaan web-sovellus tai että sen on toimittava tietyssä käyttöympäristössä. Tällöin kyseessä on vaatimus, joka on huomioitava myöhemmässä suunnittelussa. Vaatimusmäärittelyssä ei siis ole tarkoitus välttää kaikkia teknisiä kannanottoja, vaan erottaa toisistaan asiakkaan asettamat vaatimukset ja niiden toteuttamiseen liittyvät tekniset ratkaisut.

Määrittelyvaiheessa laaditaan vaatimusmäärittely eli dokumentti, jota kutsutaan usein toiminnalliseksi määrittelyksi. Sen tarkoitus on kuvata millainen järjestelmä täyttää ongelman vaatimukset. Siinä kuvataan ohjelmiston toiminnot, toteutukselle asetettavat ulkoiset vaatimukset ja rajoitukset. Toimintojen yhteydessä määritellään ohjelmistolla toteutettavat ominaisuudet, kuten käyttöliittymä ja kommunikointi ulkoisten järjestelmien kanssa.

Vaatimusmäärittelyn tehtävä on toimia pohjana asiakkaan ja toimittajan tekemälle tilaus-sopimukselle. Molempien kannalta on tärkeää, että siinä mainitaan kaikki ne ominaisuudet, jotka lopputuotteelta halutaan.

Järjestelmälle asetettavat vaatimukset jaetaan usein toiminnallisiin vaatimuksiin ja ei-toiminnallisiin vaatimuksiin. Eron voi hahmottaa kahden kysymyksen avulla:

• Toiminnallinen vaatimus: mitä järjestelmän pitää tehdä? Se kuvaa järjestelmän toimintaa, kuten tuotteen hakemista, ostoskoriin lisäämistä tai tilausvahvistuksen lähettämistä.
• Ei-toiminnallinen vaatimus: miten hyvin tai millä ehdoilla järjestelmän pitää toimia? Se kuvaa esimerkiksi suorituskykyä, käytettävyyttä, luotettavuutta tai yhteensopivuutta koskevaa tavoitetta tai rajoitetta. Se ei tarkoita teknistä toteutusohjetta, vaan vaatimusta lopputulokselle.

Esimerkiksi verkkokaupassa toiminnallinen vaatimus voisi olla: ”Asiakas voi hakea tuotteita nimellä.” Samaan toimintoon liittyvä ei-toiminnallinen vaatimus voisi olla: ”Hakutulokset näytetään enintään kahdessa sekunnissa vähintään 95 prosentissa hauista, kun palvelussa on 100 samanaikaista käyttäjää.” Ensimmäinen kertoo, että hakutoiminnon on oltava olemassa, ja toinen, kuinka nopeasti sen on toimittava sovitussa kuormituksessa. Pelkkä ”haun pitää olla nopea” olisi liian epämääräinen vaatimus.

Miksi jako tehdään? Se auttaa muistamaan sekä tarvittavat toiminnot että niiden laatua ja käyttöolosuhteita koskevat vaatimukset. Verkkokaupassa voi olla kaikki sovitut toiminnot, mutta jos haku kestää minuutin, palvelu voi silti olla asiakkaalle käyttökelvoton. Jaottelu auttaa myös suunnittelussa ja hyväksymisen tarkistamisessa: toiminnallisesta vaatimuksesta tarkistetaan, onnistuuko tuotteen hakeminen, ja suorituskykyvaatimuksesta mitataan, toteutuuko sovittu vasteaika sovitulla kuormalla. Molemmat vaatimusryhmät ovat siis tärkeitä, ja vaatimukset tulee kuvata niin, että niiden täyttyminen voidaan todentaa.

Jaottelu tehdään yksittäisen vaatimuksen sisällön perusteella. Esimerkiksi tietoturvaan voi liittyä sekä toiminnallinen vaatimus (”Järjestelmä pyytää käyttäjältä kertakäyttöisen vahvistuskoodin kirjautumisen yhteydessä”) että ei-toiminnallinen vaatimus (”Käyttäjän ja palvelun välinen tietoliikenne on salattava”). Pelkkä aihe, kuten tietoturva tai käyttöliittymä, ei siis vielä ratkaise vaatimuksen tyyppiä.

Määrittelyvaiheessa siis paneudutaan systeemille asettuihin vaatimuksiin ja tuotetaan spesifikaatio, jossa ne on kuvattu mahdollisimman kattavasti. Usein pelkkä sanallinen kuvaus ei ole tarpeeksi selkeä, vaan käytetään esim. UML-mallinnuskielen erilaisia kaavioita.

Alla on esimerkki vaatimusmäärittelydokumentin rakenteesta. Malli mukailee IEEE 830-1998 -standardin sisältösuosituksia, mutta sen lukujakoa on sovellettu ja täydennetty.

IEEE 830-1998 on historiallinen standardi, jonka korvasi ISO/IEC/IEEE 29148:2011. Sitä käytetään tässä havainnollisena esimerkkinä vaatimusmäärittelyn rakenteesta. Standardin englanninkielinen teksti on luettavissa Kansasin yliopiston sivuilla (PDF); liitteessä A esitellään vaihtoehtoisia dokumenttirakenteita. Tieto standardin korvaamisesta löytyy IEEE:n viralliselta standardisivulta.

1. Johdanto

1.1 Tarkoitus ja kattavuus: kuvataan, mihin vaatimusmäärittelydokumenttia käytetään ja mitä järjestelmää tai sen osaa dokumentin vaatimukset koskevat.

1.2 Tuote ja ympäristö: kuvataan lyhyesti, mikä kehitettävä tuote on, mihin sitä käytetään ja millaisessa käyttöympäristössä se toimii, esimerkiksi millä laitteilla sitä käytetään ja mihin muihin järjestelmiin se liittyy.

1.3 Määritelmät, termit ja lyhenteet

1.4 Viitteet

1.5 Yleiskatsaus dokumenttiin: kuvataan vaatimusmäärittelydokumentin rakenne ja eri lukujen keskeinen sisältö.

2. Yleiskuvaus

2.1 Ympäristö

2.2 Toiminta

2.3 Käyttäjät

2.4 Yleiset rajoitteet

2.5 Oletukset ja riippuvuudet

3. Tiedot ja niiden käsittely

Tässä kuvataan, mitä tietoja järjestelmä tarvitsee, miten niitä pitää voida käsitellä ja mitä niiden säilyttämiseltä edellytetään. Esimerkiksi verkkokaupan tilauksesta on säilytettävä tuotteet, määrät, hinnat ja toimitustiedot, ja asiakkaan on voitava tarkastella aiempia tilauksiaan. Suunnitteluvaiheessa ratkaistaan, tarvitaanko näiden vaatimusten toteuttamiseen tietokanta, mikä tallennusratkaisu valitaan ja miten tiedot järjestetään. Jos asiakkaan ennalta antama rajoite edellyttää esimerkiksi olemassa olevan tietokannan käyttöä, se kirjataan kuitenkin jo vaatimusmäärittelyyn.

3.1 Tietosisältö

3.1.1 Käsitteet omiin alakohtiinsa

3.2 Käyttöintensiteetti

3.3 Kapasiteettivaatimukset

3.4 Tiedostot ja asetustiedostot

4. Toiminnot

4.1 Kukin toiminto omaan alakohtaansa

5. Ulkoiset liittymät

5.1 Laitteistoliittymät

5.2 Ohjelmistoliittymät

5.3 Tietoliikenneliittymät

6. Muut ominaisuudet

6.1 Suorituskyky ja vasteajat

6.2 Saatavuus (availability), toipuminen, turvallisuus, suojaukset

6.3 Ylläpidettävyys

6.4 Siirrettävyys ja yhteensopivuus

6.5 Operointi

6.6 Käytettävyys (Usability), käytön tehokkuus, käyttäjien tyytyväisyys

7. Suunnittelurajoitteet

7.1 Standardit

7.2 Laitteistorajoitteet

7.3 Ohjelmistorajoitteet

7.4 Muut rajoitteet

8. Hylätyt ratkaisuvaihtoehdot

9. Jatkokehitysajatuksia