Vaikka pääasiallinen toimenkuvamme muodostuu arkkitehtuurista ja prosessien kuvaamisesta, teemme välillä myös perinteisiä määrityksiä. Eli vaikkapa käyttötapauksia. Joskus käyttötapaukset ovat toiminta-arkkitehtuurin lähtökohta, eli dokumentti, joka toiminnallisuudesta on kirjoitettu. Aikoinaan olen ollut paljonkin tekemisissä käyttötapausten kanssa, mm. ohjannut niiden kirjoittamista ja katselmoinut niitä. Käyttötapausten katselmointi ei ole mitään rakettitiedettä, kun sen oikein oivaltaa. Tässäpä teillekin sovellettavaksi muutama vinkki, jos joskus joudutte käyttötapauksia lukemaan.
1. Ei passiivia
Käyttötapauksen tarina on kirjoitettava aktiivimuodossa. Passiivin käyttö nimittäin hämärtää sen, kuka mistäkin tekemisestä on vastuussa. Älä siis kirjoita ”asiakasnumero tarkastetaan” vaan ”järjestelmä x tarkastaa asiakasnumeron”. Parhaimmillaan käyttötapaus on hyvin yksinkertaista kieltä: subjekti predikaatti objekti. Voit käyttää jopa lapsellisen jankkaavaa tyyliä: ”käyttäjä syöttää asiakkaan nimen alkuosan” ”järjestelmä hakee listan asiakkaista, joiden nimen alkuosa täsmää hakukriteeriin” jne.
2. Älä vaihtele terminologiaa tai sanamuotoja
Myös kaiken muun, mistä äidinkielen ainekirjoituksessa sai hyviä numeroita, voi unohtaa. Kuten vaihtelevat ja värikkäät kielikuvat, lauseenvastikkeet jne. Kaikki vääriä valintoja, kun kirjoitetaan IT-määrityksiä. Käytä samasta asiasta aina samaa termiä.
3. Käyttötapauksen tekstin on mahduttava A4-kokoon
Joskus näkee mallipohjia, joissa käyttötapausten väliotsikot ovat otsikkotyyliä. Se usemmiten pidentää dokumenttia tarpeettomasti. Lukijalle on mukavinta, jos hän näkee koko käyttötapauksen yhdellä kertaa. Taulukkomuotoinen esitystapa pakkaa tekstin riittävän tiukkaan.
Entä jos käyttötapaus on oikeasti niin monimutkainen, ettei se kertakaikkiaan mahdu yhteen sivuun? Usein ongelma on joku muu kuin käyttötapauksen monimutkaisuus. Ensinnäkin käyttötapauksia tunnistettaessa kannattaa pyrkiä ”siedettävään kokoon”. Käyttötapaus on kerralla suoritettava käyttäjälle lisäarvoa tuova kokonaisuus. Esimerkiksi verkkopankissa yksi käyttötapaus on ”Maksa lasku” ei ”Katso tilitiedot, maksa lasku ja tee laskusta toistuvaissuoritus”.
Toinen tapa saada käyttötapaukset siedettävän kokoisiksi ja luettaviksi on erottaa käsittelysäännöt liitteeksi. Käsittelysäännöillä tarkoitan vaikkapa henkivakuutuksen laskemiseen tarvittavaa matemaattista kaavaa. Liiketoimintalogiikkaa kuvaavat päättelysäännöt kannattaa koota erikseen jo senkin takia, että niihin useimmiten joutuu viittaamaan useammasta kuin yhdestä käyttötapauksesta.
4. Käyttötapaus kuvaa järjestelmään toteutettavaa toiminnallisuutta
Käyttötapauskaavioihin on mahdollista lisätä system boundary ja sen käyttö on mielestäni poikkeuksetta suositeltavaa. System boundary on suorakaiteen muotoinen laatikko ja sen sisällä ovat ne käyttötapaukset, jotka järjestelmän x on toteutettava. Jos analysoitavana on kaksi järjestelmää, joista toinen toimii taustalla ja toinen tarjoaa käyttäjärajapinnan, kannattaa kummallekin järjestelmälle piirtää oma system boundary. Esimerkki alla olevassa kuvassa.
Jos yllä oleva tuntuu monimutkaiselta, voi ajatella sääntöä seuraavasti ”jos määritykset käsittelevät kahta eri järjestelmää, on selvästi erotuttava kumpaa milloinkin tarkoitetaan”.
5. Jos et keksi älyllistä kirjoitettavaa, jätä kohta tyhjäksi
Joskus olen nähnyt leikepöydän kautta monistettuja käyttötapauksia, joista dokumentin pituudesta huolimatta puuttuu sisältö lähes täysin. Jos käyttötapaus on ”tee asia x”, on sen esiehto ”asia x on tehtävä”. Arvatkaapas mikä silloin on jälkiehto? Luonnollisesti ”asia x on tehty”. Käyttötapauksen dokumentoinnin tarkoitus ei ole, että sinne tahkotaan sisältöä oli sanottavaa tai ei. Itse asiassa on jopa parempi, että joku kohta on tyhjä, koska silloin lukija herää miettimään, onko joku asia oikeasti jäänyt huomioimatta.
Suunnilleen näihin vinkkeihin kulminoituu minun kokemukseni käyttötapausten katselmoinnista, harvemmin olen joutunut huomauttamaan muista asioista. Minähän olen katselmoinut lähinnä käyttötapausten muodollista oikeellisuutta. Katselmoinneissa on aina ollut mukana liiketoiminnan edustajat erikseen ja heillä on toki paljon tarkastettavaa siinä, onko toiminnallisuus oikein kuvattu. Nämä muotoseikat eivät kuitenkaan ole vähäpätöisiä. Jos käyttötapauksista ei saa mitään selvää, on tulevan järjestelmätoteutuksen mahdoton niitä noudattaa.
Käyttötapausten kirjoittaminen on toki vaikeampaa kuin niiden lukeminen. Pystyyhän kuka tahansa lukemaan menestyskirjan, mutta harva osaa sellaisen kirjoittaa. Yllä mainituilla vinkeillä on helppo tunnistaa laatupoikkeamat, niiden korjaamiseen saattaa tarvita konsultin apua.