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 sellaiset asiat kuin millaisella laitteella loppukäyttäjät tuotetta käyttävät on määriteltävä tässä vaiheessa. Eli onko tarkoitus tehdä web-sovellus tai mobiili-sovellus tai työpöytä-sovellus vai jopa kaikki em.
Määrittelyvaiheessa luodaan vaatimusmäärittely ( requirement analysis ). 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.
Määrittelyvaiheessa syntyvää dokumenttia kutsutaan usein toiminnalliseksi määrittelyksi. Se vastaa kysymykseen "mitä" järjestelmän tulee tehdä.
Järjestelmän ominaisuudet voidaan jakaa toiminnallisiin ominaisuuksiin ja ei-toiminnallisiin ominaisuuksiin. Toiminnallisiin ominaisuuksiin kuuluu mm. käyttöliittymät, järjestelmän käsittelemät tiedot. Ei-toiminnallisiin kuuluvat esimerkiksi suorituskyky, luotettavuus, turvallisuus ja siirrettävyys.
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.
Kustakin käyttötapauksesta laaditaan käyttötapauskortti, jossa käyttötapaus kuvataan yksityiskohtaisesti. Kortin kuvausosio (skenaario) paljastaa toiminnallisia vaatimuksia, joita ei pelkästä käyttötapauskaaviosta selviä. Asiakas hyväksyy kortit ennen kuin projektissa siirrytään suunnitteluvaiheeseen.
Esimerkki käyttötapauksesta Lisää tuote koriin ja maksa tilaus:
| TUNNISTE | KT-0010 | VERSIO | 1.0 |
|---|---|---|---|
| NIMI | Lisää tuote koriin ja maksa tilaus | ||
| SUORITTAJAT | Asiakas, Verkkokaupan järjestelmä, Maksujärjestelmä | ||
| TAVOITE | Asiakas on onnistuneesti lisännyt haluamansa tuotteen ostoskoriin ja suorittanut tilauksen. | ||
| ESIEHDOT | Asiakas on kirjautunut sisään tai jatkaa vieraana. Tuote on saatavilla varastossa. | ||
| KUVAUS |
1. Asiakas selaa tuotteita ja valitsee haluamansa tuotteen. 2. Asiakas lisää tuotteen ostoskoriin. 3. Asiakas siirtyy ostoskoriin ja tarkistaa tilauksen sisällön. 4. Asiakas siirtyy kassalle ja syöttää toimitustiedot. 5. Asiakas valitsee maksutavan ja vahvistaa tilauksen. 6. Järjestelmä ohjaa asiakkaan maksujärjestelmään. 7. Maksujärjestelmä vahvistaa maksun onnistuneesti. (P1) 8. Järjestelmä kirjaa tilauksen ja lähettää vahvistuksen asiakkaan sähköpostiin. |
||
| LOPPUEHDOT | Tilaus on kirjattu järjestelmään ja asiakas on saanut tilausvahvistuksen sähköpostiin. | ||
| POIKKEUKSET | P1: Maksu epäonnistuu – järjestelmä ilmoittaa virheestä ja asiakas voi yrittää uudelleen tai valita toisen maksutavan. | ||
| AVOIMET ASIAT | Voiko asiakas muuttaa toimitustapaa tilauksen tekemisen jälkeen? | ||
Vaatimusmäärittelydokumentin sisältö voisi olla esimerkiksi seuraavanlainen. Alla oleva rakenne perustuu IEEE 830-1998 standardiin, joka on yksi yleisimmin käytetyistä malleista ohjelmiston vaatimusmäärittelyn dokumentoinnissa.
1. Johdanto
2. Yleiskuvaus
3. Tiedot ja tietokanta
4. Toiminnot
5. Ulkoiset liittymät
6. Muut ominaisuudet
7. Suunnittelurajoitteet
8. Hylätyt ratkaisuvaihtoehdot
9. Jatkokehitysajatuksia