Määrittelydokumentti

Määrittelydokumentti tehdään ennen kuin aloitetaan työn suunnittelu. Siinä kerrotaan, millainen tuotettava ohjelma on käyttäjälle. Dokumentissa kuvataan mm. mikä on ohjelman käyttötarkoitus, mitä se pystyy tekemään ja millainen käyttöliittymä siinä tulee olemaan. Määrittelydokumentin voi mieltää sopimukseksi asiakkaan ja työn tekijän välillä. Määrittelydokumentin rajauksesta lipsuminen ilman asiakkaan (=ohjaajan) mielipiteen ja luvan kysymistä on kuin autokauppias antaisi BMW:tä pyytäneelle asiakkaalle Wartburgin. Toisaalta määrittelydokumentti ei saisi olla liian epätarkka. Jos autokauppias lupaa vain toimittaa BMW:n asiakkaalle, niin tässä jää mm. auton vuosimalli, malli, lisävarustelut ym. auki, ja asiakas voi pettyä pahasti lopulta saamaansa tuotteeseen.

Tässä vaiheessa on syytä tarkentaa ja rajata aihetta. Harjoitustyön aikana dokumentointiin ja testaukseen kuluvaa aikaa ja vaikutusta arvosanaan ei sovi väheksyä. Mitä enemmän ominaisuuksia ohjelmassa on, sitä enemmän testattavaa ja dokumentoitavaa ohjelmaan tulee ja sitä kovempi kiire loppua kohti tulee.

Lopullinen ohjelma tuskin noudattaa täydellisesti määrittelydokumentin kuvausta, eikä tätä odotetakaan. Tämä ei kuitenkaan tarkoita, että määrittelydokumenttiin riittäisi ohjelmasta ylimalkainen kuvaus tyyliin "ikkunan alareunassa on joitakin painikkeita". Tässä painikkeiden määrä ja niiden painelusta seuraavat tapahtumat olisi hyvä selittää, esimerkiksi "Ikkunan alareunassa on kolme painiketta robotin ohjaamiseen. Vasemmanpuoleisin painike kääntää robottia 90 astetta vasemmalle, seuraava siirtää robottia yhden askelen eteenpäin ja kolmas kääntää robottia 90 astetta oikealle." Näin ohjelman toiminta saadaan selkeytettyä myös omassa päässä, jolloin jotkin mahdolliset aiheeseen liittyvät sudenkuopat voivat paljastua.

Jos ja kun ohjelma poikkeaa määrittelydokumentissa määritellystä, niin lupa tähän on kysyttävä asiakkaalta - eli ohjaajalta. Ohjelmaa ei kuitenkaan saisi mielellään jälkikäteen rajoittaa jo sovitusta määritelmästä.

Kirjoitusohjeita

Alle olevat kuusi lukua toimivat dokumentin esimerkkisisältönä. Riippuu kovasti aiheesta millaisia asioita siinä tulee määritellä: Joihinkin näistä lukuihin voi tulla paljonkin kerrottavaa ja joihinkin ei välttämättä (juuri) mitään. Sama asia saattaa toistua useassa eri luvussa, mutta se ei ole mitenkään vakavaa!

Ehdottoman sallittua on myös kirjoittaa tästä esimerkistä poikkeavan sisällön dokumenttiin, mikäli katsoo sen olevan johdonmukaisempi oman aiheen kannalta. Järjen käyttö ei ole kiellettyä!

Muutama sana vielä kirjoitusasusta: Otsikot tulisi erottaa leipätekstistä erikokoisella kirjaisimella. Kannattaa käyttää kappalejakoa sekä pyrkiä selkeään ja tiiviiseen ilmaisuun. Käytä kokonaisia lauseita ja pisteitä. Kaikkia pilkkujakaan ei saisi mielellään unohtaa!

Kansilehti

Määrittelydokumentin kanteen tulee:

• Työn nimi
• Dokumentin nimi (määrittelydokumentti)
• Oppilaan nimi
• Oppilaan sähköpostiosoite
• Ohjaajan nimi
• Kenelle tai mille työ on tehty (Helsingin yliopisto, Tietojenkäsittelytieteen laitos)
• Kurssin nimi
• päiväys

Kansilehdellä ei ole sivunumeroa. Määrittelydokumentti on niin lyhyt, ettei sisällysluetteloa ole pakko tehdä.

Sisältö

Ohjelman tarkoitus ja yleiskuvaus

Kerro mikä ohjelma on ja mihin sitä käytetään. Kuvaa ohjelman käyttäjät ja kerro mitä heidän tarpeita ohjelma voi toteuttaa. Lisäksi tulisi käydä läpi kaikki mahdolliset käyttötapaukset. Käyttötapauksilla tarkoitetaan erilaisia oikean elämän tilanteita, joissa ohjelmaa käytetään. Kerro mitkä käyttäjäryhmät käyttävät ohjelmaa missäkin käyttötapauksessa, ja mihin tarpeeseen. Esimerkiksi peleissä ei ole yleensä muita käyttäjiä kuin pelaajat, jotka käyttävät ohjelmaa pelaamiseen. Lisäksi jos voi säästää pelin tai pelituloksen niin yhtenä käyttötapauksena voisi olla vanhojen pelin lataaminen tai pelitulosten katsominen jälkikäteen, jne... Tässä tekstin määrä voi vaihdelsla paljoltikin aiheesta riippuen: hyötyohjelmissa kuten kortistossa voi olla peleihin nähden useita käyttäjäryhmiä ja enemmän käyttötapauksia.

Rajoitukset

Kerro millä tavalla haluat itse rajata ohjelman toteutusta ja millaisia rajoituksia käsiteltävällä datalla on. Mieti millaisia rajoituksia toteutusympäristö asettaa ohjelmallesi. Esimerkiksi ristinollapeliä tehdessä kannattaa rajata peliruudukon koko vaikkapa 50*50 ruudun kokoiseksi, koska jatkuvasti laajentuva pelilauta voi olla vaikeaa toteuttaa (oma rajoitus) ja ainakin teoriassa jos peli jatkuisi ja jatkuisi niin muisti voisi joskus loppua (toteutusympäristön asettama rajoitus).

Käsiteltävän datan kuvaus

Kerro millaista tietoa ohjelma käsittelee. Tässä vaiheessa ei tarvitse vielä miettiä mitä tietotyyppiä käyttäisi tms, se kuuluu vasta suunnitteluvaiheeseen. Tässä on tarkoitus vain antaa suuntaa-antavaa kuvausta käsiteltävästä datasta. Esimerkiksi kortisto-ohjelmassa voisi kertoa mitä dataa kukin kortti sisältää.

Tiedonkulun kuvaus

Kerro millaista tietoa kulkee käyttäjältä ohjelmalle, ohjelmalta käyttäjälle ja esimerkiksi tallettaessa tiedostoon. Selosta myös kuinka tiedon liikkuminen tapahtuu. Esimerkiksi voi kertoa mitä tietoja käyttäjä syöttää liikuttelemalla ja klikkailemalla hiirtä tai kirjottaessa näppäimistöltä, mitä informaatiota ohjelma piirtää tai tulostaa ruudulle.

Toimintojen kuvaus

Kerro mitä toimintoja ohjelmassa tulee olemaan. Kukin toiminto tulisi perustua johonkin yllä tekemääsi käyttötapaukseen. Esimerkiksi jossain yksinkertaisessa pelissä voisi olla toimintoina uuden pelin ottaminen, siirron tekeminen, pelin tallettaminen ja lataaminen, ja kaikissa ohjelmissa yleensäkin ohjelmasta poistuminen... Huom! Ohjelman toiminnot ovat tällä kurssilla tärkeämpi käsite kuin ehkä tässä vaiheessa ymmärtää. Suunnitteluvaiheessa sekvenssikaaviot perustuvat yleensä toimintoihin, käyttöohje usein jaotellaan toimintojen mukaisesti, ja toimintotestauksessa nimenmukaisesti testataan toimivatko toiminnot halutulla tavalla.

Käyttäytymisen kuvaus

Mieti miten ohjelmaa käytetään, ja miten se käyttäytyy. Tee ohjelman käyttöliittymästä kaavio, johon tulee kaikki ohjelman näytöt ja valikot sekä niiden väliset yhteydet. Oleellista käyttöliittymäkaaviossa on kaikkien ohjelman toimintojen ja erilaisten näyttöjen esittäminen. Kuvassa 1 on käyttöliittymäkaavio minimaaliseen valikoihin ja lomakkeisiin perustuvaan kortisto-ohjelmaan. Kuvassa 2 on hahmoteltu käyttöliittymäkaaviota grafiseen piirrustusohjelmaan. Lopuksi kirjoita ohjelman toimintoihin ja kaavioon perustuva lyhyt käyttöohje ohjelmalle.

kuva 1: kortisto-ohjelma

kuva 2. piirustusohjelma