Toiminnallinen määrittely ja määrittelyraportti

1. Tarkoitus

Toiminnallisen määrittelyn tarkoituksena on määritellä ohjelmatyössä toteutettava ohjelmisto niin tarkkaan kuin se on mahdollista ennen toteutuksen käynnistymistä. Tarkimmin määrittelyssä painotetaan sitä, miltä ohjelmisto tulee näyttämään ulospäin, eli miten käyttäjä näkee sen (ikkunat, toiminnot) tai miten järjestelmää käytetään muista systeemeistä käsin (API, protokollat).

Määrittelyn perustana on työn edellisessä vaiheessa syntynyt vaatimusmäärittely, johon kirjattiin asiakkaan edellyttämät vaatimukset priorisointeineen. Toiminnallisessa määrittelyssä asiakkaan esittämät vaatimukset analysoidaan ja tarkennetaan toiminnoiksi. Tiedossa olevien teknisten ratkaisujen takia voidaan esimerkiksi osaa asiakkaan esittämistä toiminnoista muuttaa toteutuksen kannalta mielekkäämmäksi.

2. Tehtävät

Ohjelmiston arkkitehtuuri ja toimintaympäristö sekä sen toiminnot, tiedot ja niiden väliset suhteet kuvataan siinä laajuudessa, että seuraavien työvaiheiden sisältö voidaan suunnitella. Määrittelyn käytännön toteuttaminen luonnollisesti vaihtelee käsiteltävän ongelman luonteen perusteella:

Tuotannonohjausjärjestelmän rakentamisessa määrittelyn keskeisenä sisältönä ovat tulevaa järjestelmää käyttävän organisaation henkilöiden toimenkuvat, materiaali- ja tietovirrat eri toimintojen välillä sekä kohdeyrityksen tuotannon ohjattavuuteen liittyvän problematiikan selvittäminen. Kääntäjää suunniteltaessa on kenties perehdyttävä leksikaalisella, syntaktisella ja semanttisella tasolla tapahtuvan jäsentelyn vaiheisiin; syöttö- ja tulostiedot ovat täsmällisesti etukäteen määriteltyjä.

Määrittelyvaiheen oleellisena ongelmana saattaa olla myös kyseeseen tulevien valmiiden järjestelmäkomponenttien (ohjelmistot, laitteet) soveltuvuuden selvittäminen, mitoitus, valinta ja mahdollinen hankinta. Jos toteutuksen pohjana on olemassaoleva osajärjestelmä tai prototyyppi voidaan joutua tekemään myös sen käänteissuunnittelu (reverse engineering), mikäli vanha dokumentaatio on puutteellinen tai ei ole ajan tasalla.

Raportoinnissa käytettävä esitystapa tulisi valita esitettävän asian perusteella. Organisaation tietovirtojen, järjestelmän toimintojen, tietokantojen ja arkkitehtuurin kuvaamiseen soveltuvat erilaiset tietokaaviotekniikat (Use Case, SADT, ER, DFD, OMT...), kun taas muodollista määrittelyä on paikallaan käyttää asioista, jotka ovat siten määriteltävissä (esim. kieliopit).

Mikäli käyttöliittymä on järjestelmän käytön kannalta keskeistä, voi olla eduksi havainnollistaa vuorovaikutusta mahdollisimman todenmukaisin esimerkein (esim. ikkunat ja dialogit eri toiminnoissa). Näin kannattaa menetellä erikoisesti silloin, kun halutaan palautetta toiminnoista kaaviotekniikoihin perehtymättömältä "peruskäyttäjältä".

Ongelma-alueeseen ja teknisiin ratkaisuihin perehtymisessä suositellaan mahdollisuuksien mukaan tutustumiskäyntejä alan yrityksiin, haastatteluja ja kirjallisuustutkimuksia, joista laaditaan selvitykset olennaisilta osin.

3. Tulokset

 

Määrittely on laadittava siten, että asiaan perehtymätönkin johtoryhmän jäsen kykenee nopeasti ymmärtämään, mistä on kysymys (esimerkiksi kunkin luvun yhteenvetojen avulla). Lisäksi seurantapalaveria varten on määrittelyn keskeinen sisältö kyettävä esittämään yhdellä A4-sivulla (yhteenveto). Toiminnallinen määrittely laaditaan yhteistyössä työn asiakkaan kanssa. Yksi esimerkki toiminallisen määrittelyn raportoinnista: Määrittelyraportti

Testaussuunnitelmaa pitää alkaa laatia järjestelmän ei-toiminnallisten ominaisuuksien pohjalta. Näin voidaan varmistaa, että toteutuksessa huomioidaan ei-toiminnallisten ominaisuuksien testattavuus. Testaussuunnitelma

3.1 Määrittelyraportti

Määrittelyraportti on kirjallinen dokumentti. Suositeltava pituus on riippuu tietenkin harjoitustyön laajuudesta, mutta minimi sivumäärä voisi olla neljä (4). Maksimimäärää ei ole. Määrittelyraportissa on oltava seuraavat asiat:

kansilehti sisällysluettelo varsinainen teksti mahdolliset liitteet.

Kansilehdellä tulevat seuraavat asiat:

organisaation nimi projektin nimi dokumentin nimi versionumero sivujen lukumäärä tekijät tila (hyväksytty, jätetty tarkastettavaksi, keskeneräinen) tarkastajan ja hyväksyjän nimi ja nimikirjoitukset

Sisällysluettelo malli voisi olla tällainen:


1.	Johdanto
1.1	Käsitteitä
1.2	Määrittely- ja vastuuhenkilöt
1.3	Käytettävät standardit
2.	Nykytila
2.1	Toimitusprosessi
2.2	Ongelmat
2.3	Nykyinen käyttöjärjestelmä-, ohjelma- ja laiteympäristö
3.	Tavoitetila
3.1	Järjestelmän tarkoitus
3.2	Tavoitteet
3.3	Yleiset vaatimukset
3.4	Tavoiteltavat hyödyt
4.	Toteutus
4.1	Sovellusympäristö
4.2	Järjestelmän osat
4.3	Toimitusprosessin etenemine
4.4	Käyttöliittymä
4.5	Tietokannat
4.6	Lomakkeet
4.7	Näkymät
4.8	Toiminnot
4.9	Tulosteet
4.10	Laitteet ja ohjelmistot
4.11	Tarvittavat liittymät muihin järjestelmiin
4.12	Rajaukset
4.13	Käyttörajoituksia ja oikeuksia
4.14	Ylläpito, virhe, muutos ja päivityskäytännöt
5.	Osavaihejaottelu, aikataulu ja projektisuunnitelma
5.1	Osavaiheet
5.2	Alustava aikataulu ja projektisuunnitelma
5.3	Kokonaiskustannusarvio

Jokaisella sivulla täytyy olla sivunumero, dokumentin nimi ja versio sekä päivämäärä.