4. Vaatimusanalyysi Laadukkaiden ohjelmistojen tuottaminen ei ole helppo tehtävä. Sen lisäksi, että ohjelman täytyy toimia virheettömästi, sen täytyy täyttää sille asetetut implisiittiset ja eksplisiittiset vaatimukset. Implisiittiset vaatimukset: ominaisuudet, jotka oletetaan olevan kaikilla kehitettävän tyyppisillä laadukkailla ohjelmistoilla. Tällaisia ovat esimerkiksi hyvä ylläpidettävyys, selkeä ja yhdenmukainen käyttöliittymä ja virheettömyys. Näitä ei välttämättä listata erikseen, mutta siitä huolimatta tuotettavan ohjelman täytyy toteuttaa ne. Eksplisiittiset vaatimukset: vaatimukset, jotka on lueteltu erikseen ja jotka tuotettavan ohjelman täytyy toteuttaa. Nämä selvitetään vaatimusanalyysissa. Sivu - 65 - Vaatimusanalyysin tavoitteet Vaatimusanalyysin tavoitteena on selvittää ohjelmistolle asetettavat vaatimukset sellaisella tarkkuudella, että niiden perusteella voidaan tuottaa haluttu ohjelmisto. Lineaarisissa malleissa työvaiheen lopputuloksena saadaan täydellinen lista vaatimuksista ja analyysi niiden vaikutuksista. Iteratiivisissa malleissa saadaan lista tällä iteraatiokierroksella vaikuttavista vaatimuksista. Vaatimukset ovat eritasoisia. Osa on hyvin korkealla tasolla, osa menee syvälle yksityiskohtiin. Sivu - 66-1
Vaatimusten luonteesta Dokumentoitavien vaatimusten on oltava virheettömiä. Vaatimusanalyysissä tehty virhe vaikuttaa koko projektin elinkaaren ajan ja tulee kalliiksi. ristiriidattomia. Ristiriitaisuus syntyy puhutun ja kirjoitetun kielen moniselitteisyydestä. täydellisiä. Vaatimukset muuttuvat lähes poikkeuksetta projektin elinkaaren aikana, joten täydellisyyteen (ja virheettömyyteen) ei päästä. realistisia. Vaatimusanalyysissa selvitetään myös järjestelmäsuunnittelun ja toteutusympäristön asettamat rajoitukset. tarpeellisia. Tarpeellisten vaatimusten selvittäminen on yllttävän vaikea tehtävä. Vaatimukset kannattaa priorisoida. todennettavissa. Jokainen vaatimus on löydettävä tuotteesta, ja tuotteen jokainen ei-triviaali ominaisuus on oltava tunnistettu vaatimus. jäljitettävissä. Jokaisella vaatimuksella on esittäjä, joka on voitava selvittää tarpeen vaatiessa. Sivu - 67-4.1. Vaatimustyypit Vaatimusanalyysia vaikeuttaa, että vaatimukset on tarkoitettu eri tarkoituksiin: Vaatimuksia käytetään kuvaamaan tehtävää ohjelmistoa Vaatimukset toimivat sopimuksena asiakkaan ja ohjelmistoyrityksen välillä. Vaatimukset kuvaavat ohjelmiston toiminnan yksityiskohtia Vaatimukset toimivat suunnittelun perustana. Vaatimusten monimerkityksisyyden johdosta Sommerville jakaa vaatimukset kolmeen tyyppiin: käyttäjän vaatimukset (user requirements), järjestelmävaatimukset (system requirements) ja ohjelmiston määrittelykuvaukset (software design specification). Sivu - 68-2
Vaatimustyypit jatkuvat Käyttäjän vaatimukset Vaatimukset listaavat ohjelmiston tarjoamat palvelut ja ohjelmistolle asetettavat rajoitukset. Vaatimukset kuvataan luonnollisella kielellä ja kaavioilla. Käyttäjän vaatimuksia käytetään analyysin pohjana ja yhteydenpidossa asiakkaan kanssa. Järjestelmävaatimukset Vaatimukset kuvaavat ohjelmiston palvelut ja rajoitukset yksityiskohtaisesti. Kaikki vaatimukset kuvataan samalla formaatilla. Järjestelmävaatimuksia käytetään sopimuksena asiakkaan ja ohjelmistoyrityksen välillä. Ohjelmiston määrittelykuvaukset Määrittelykuvaus on yksityiskohtainen ja kattava kuvaus ohjelmistosta. Kuvauksessa käytetään standardoituja menetelmiä, kaavioita ja strukturoitua kuvausta. Kuvaus toimii suunnittelun esiasteena. Sivu - 69-4.2. Vaatimusten luokittelu Äsken tyypiteltiin, nyt luokitellaan vaatimuksia. Käyttäjä- ja järjestelmävaatimukset voidaan luokitella toiminnallisiin (functional) vaatimuksiin ja eitoiminnallisiin (non-functional) vaatimuksiin. Toiminnalliset vaatimukset: Nämä määrittelevät, mitä palveluja ohjelmiston on tarjottava, miten ohjelmisto reagoi syötteisiin ja miten se käyttäytyy annetuissa tilanteissa. Joskus toiminnalliset vaatimukset myös määrittelevät, mitä ohjelmiston ei pidä tehdä. Ei-toiminnalliset vaatimukset: Nämä määrittelevät rajoitukset ja reunaehdot toiminnallisille vaatimuksille. Sivu - 70-3
Vaatimusten luokittelu (jatkuu) Esimerkiksi vaikka näin: Ohjemistoon pitää pystyä tekemään kyselyjä kulloinkin paikalla olevista käyttäjistä (toiminnallinen vaatimus). Ohjelmiston on selvittävä sadasta kyselystä sekunnissa (eitoiminnallinen vaatimus). Ohjelmiston on reagoitava hälytykseen hälytysmerkkiäänellä ja vilkkuvalla näytöllä (toiminnallinen vaatimus). Hälytykseen on reagoitava alle 0,1 sekunnin sisällä hälytyksen aiheuttaneen signaalin saapumisesta (ei-toiminnallinen vaatimus). Ohjelmistossa on oltava ylläpidolle tarjotut palvelut toiseen käyttöympäristöön siirtymiseksi (toiminnallinen vaatimus). Ohjelmiston on toimittava Windows- ja Linux-ympäristöissä (eitoiminnallinen vaaatimus). Sivu - 71 - Toiminnalliset vaatimukset Toiminnalliset vaatimukset ovat intuitiivisesti selkeitä. Tarkoitus on listata, mitä palveluja järjestelmä tarjoaa. Toiminnallisiin vaatimuksiin kuuluvat luonnollisesti ohjelmiston normaalit palvelut, mutta niihin kuuluvat myös virhetilanne- ja poikkeuskäsittelyn tarjoamat toiminnot ja toipumistavat. Toiminnalliset vaatimukset etsitään alkaen suurista kokonaisuuksista ja edeten kohti pienempiä osia. Vaatimukset pyritään kartoittamaan eri näkökulmista, jotta vaatimuksista saadaan mahdollisimman kattavat. Sivu - 72-4
Ei-toiminnalliset vaatimukset Koska ei-toiminnalliset vaatimukset eivät liity suoraan palveluihin, ne eivät ole yhtä intuitiivisia kuin toiminnalliset vaatimukset. Ei-toiminnalliset vaatimukset asettavat ohjelmistolle ja sen toteutukselle rajoituksia. Rajoitus: jokin sääntö, joka ohjelmiston on toteutettava. Esimerkiksi edellä esimerkissä oli aika- ja ylläpitorajoituksia. Koska ei-toiminnalliset vaatimukset eivät suoraan käsittele ohjelmiston tarjoamia palveluja, niiden löytäminen, luokittelu ja validointi on vaikeampaa kuin toiminnallisten vaatimusten. Sivu - 73 - Ei-toiminnallisia vaatimusluokkia Seuraava luokittelu voi auttaa löytämään eitoiminnallisia vaatimuksia: Nopeus: tapahtumia sekunnissa, vasteajat, päivitysajat ym. Koko: ohjelmiston koko, syöttö-/tulostiedoston koko ym. Helppokäyttöisyys: koulutusaika, opastusjärjestelmä ym. Luotettavuus: vikasietoisuusaste, saavutettavuusaika ym. Sitkeys (robustness): toipumisaika, kaatumistodennäköisyys, virhetilanteessa tietojen katoamistodennäköisyys ym. Porability: alustariippuvan koodin määrä, tuettavien järjestelmäalustojen määrä ym. Ei-funktionaaliset vaatimukset pyritään aina kuvaamaan tarkasti numeroarvoilla. Sivu - 74-5
Ympäristövaatimukset Ympäristövaatimukset (domain requirements) ovat vaatimuksia, joiden lähtökohtana on ohjelmistoa ympäröivä toimintaympäristö käyttäjien sijaan. Ympäristövaatimukset voivat olla joko toiminnallisia tai ei-toiminnallisia vaatimuksia. Ympäristövaatimukset ovat tärkeitä, sillä ne määrittelevät ehdot, jotka ohjelmiston tulee täyttää, jotta se voi toimia järjestelmässä. Ympäristövaatimuksia ovat esimerkiksi ohjelmistolle määriteltävät rajapinnat muihin ohjelmistokomponentteihin. Sivu - 75-4.3. Vaatimusdokumentti Vaatimusanalyysin lopputuloksena saadaan vaatimusdokumentti. Se kuvaa yksiselitteisesti kaikki ohjelmistolle asetetut vaatimukset ja kehitetyt mallit. Vaatimusdokumentin täytyy täyttää seuraavat vaatimukset: Se määrittelee vain ulkoisen toiminnan: mitä ohjelmisto tarjoaa. Se määrittelee toteutukselle asetettavat rajoitukset. Se on helposti muutettavissa. Se toimii lähdeteoksena ohjelmiston ylläpitäjille. Se sisältää arvion tuotteen elinkaaresta. Se käsittelee myös virhetilanteet. Sivu - 76-6
Vaatimusdokumentti (jatkuu) Jokaisella yrityksellä on vaatimusdokumentin pohja, joka helpottaa vaatimusdokumentin kirjoittamista. Kirjallisuudesta löytyy myös standardoituja pohjia, kuten IEEE:n standardi vaatimusdokumenteille (IEEE/ANSI 830-1993). Vaatimusdokumentti hyväksytään sekä asiakkaan että ohjelmistoyrityksen puolelta. Sen pitää olla rakenteeltaan sellainen, että kaikki sidosryhmät voivat käyttää sitä: asiakkaat, johtoryhmä, laadunvalvontaryhmä, halinto, projektipäällikkö, projektiryhmä ym. Sivu - 77 - Vaatimusdokumentin sisällysluettelo Seuraava lista perustuu Sommervillen esittämään vaatimusdokumentin rakenteeseen. 1. Esipuhe (preface) Selvittää kenelle dokumentti on tarkoitettu, dokumentin versiohistorian ja yhteenvedon edellisen version jälkeen tehdyistä muutoksista. 2. Johdanto Sisältää järjestelmän yleiskuvauksen, tärkeimmät tehtävät ja yhteistyön muiden järjestelmien kanssa. Johdanto voi sisältää myös lyhyen vanhan järjestelmän kuvauksen ja viitteet vanhan järjestelmän dokumentaatioon. 3. Sanasto Määrittelee dokumentissa käytetyt termit. Dokumentin tulee olla myös alan sanastoa tuntemattoman henkilön luettavissa. Sivu - 78-7
Sisällysluettelo (jatkuu) 4. Käyttäjän vaatimukset Määrittelee käyttäjän vaatimukset luonnollisella kielellä ja kaavioilla. Myös mahdolliset käyttäjän vaatimuksiin laskettavat ympäristövaatimukset luetellaan täällä. 5. Järjestelmäarkkitehtuuri Antaa yleiskuvan toteutettavan ohjelmiston rakenteesta. Luku sisältää myös tiedot jo valmiina olevista ohjelmistokomponenteista. Järjestelmäarkkitehtuurista tarvitaan sopivalla kuvaustekniikalla tehty kaaviokuva. 6. Järjestelmävaatimukset Märittelee yksityiskohtaiset toiminnalliset ja ei-toiminnalliset vaatimukset. Sivu - 79 - Sisällysluettelo (jatkuu II) 7. Järjestelmämallit Sisältää yksityiskohtaisemmat mallit järjestelmän osajärjestelmistä, komponenteista ja niiden välisistä suhteista. Järjestelmämallit ovat suunnittelun perustana. Ne kuvataan yhdellä tai useammalla kuvaustekniikalla. 8. Järjestelmän kehitys Selittää odotetut laitteiston, käytön ja ohjelmiston vaatimusten muutokset. 9. Liitteet Sisältää sellaiset olemassaolevat dokumentit tai viitteet, jotka vaikuttavat tuotteeseen, mutta joita ei ole määritelty vaatimusanalyysissa. Esimerkiksi käytettävän tietokannan hallintajärjestelmän kuvaus voi olla tällainen liitedokumentti. 10. Hakemisto Sivu - 80-8
4.4. Vaatimusanalyysin vaiheet Vaatimusanalyysissa on seuraavat työvaiheet: Kelpoisuusselvitys (feasibility study). Katsotaan, kannattaako ohjelmistoa ylipäänsä toteuttaa. Vaatimusten kartoitus ja analyysi (requirements elicatation and analysis). Kerätään vaatimuksia yhteistyössä asiakkaan kanssa ja mallinnetaan löydettyjen vaatimusten perusteella kehitettävää järjestelmää. Vaatimusten tyypittely(requirements specification). Jaetaan kartoitetut vaatimukset käyttäjävaatimuksiin ja järjestelmävaatimuksiin. Kehitetään ohjelmiston määrittelykuvaukset. Vaatimusten validointi (requirements validation). Varmennetaan, että löydetyt vaatimukset todella määrittelevät asiakkaan haluaman järjestelmän. Sivu - 81 - Kelpoisuusselvitys Kelpoisuusselvitys on lyhyt esivaihe vaatimusanalyysille. Siinä pyritään vastaamaan: 1. Tuoko kehitettävä järjestelmä lisäarvoa asiakkaalle? 2. Voidaanko järjestelmä toteuttaa nykyisellä teknologialla, projektille varatulla aikataululla ja budjetilla? 3. Voidaanko järjestelmä integroida jo olemassaoleviin järjestelmiin? Lisäksi, vaikka Sommerville ei sitä listaa: 4. Kannattaako järjestelmä toteuttaa, vai voidaanko vastaava järjestelmä ostaa valmiina. Onko ostettava järjestelmä sovitettavissa asiakkaan tarpeisiin? Tuloksena saadaan päätös siitä, kannattaako järjestelmän kehitystyötä jatkaa. Sivu - 82-9
Vaatimusten kartoitus ja analyysi Tavoitteena on löytää, luokitella ja mallintaa kaikki prosessin työvaiheeseen kuuluvat vaatimukset. Vesiputousmallissa tämä tarkoittaa kaikkia vaatimuksia. Prorotyyppimallissa tämä tarkoittaa seuraavalle prototyypille asetettavia vaatimuksia jne. Työvaiheeseen kuuluvat seuraavat osavaiheet: 1. Sovellusympäristön selvitys (domain understanding). 2. Vaatimusten keruu (requirements collection). 3. Vaatimusten luokittelu (classification). 4. Ristiriitaisuuksien selvitys (conflict resolution). 5. Vaatimusten priorisointi (priorisation). 6. Vaatimusten tarkastus (requirements checking). Sivu - 83 - Käyttöesimerkit Eräs tapa kartoittaa vaatimuksia on pyytää asiakkaalta käyttöesimerkkejä (scenarios) nykyisestä ja tulevasta järjestelmän toiminnasta. Käyttöesimerkit ovat kuvauksia järjestelmän käytöstä eri näkökulmista. Esimerkki sisältää järjestelmän tilan kuvauksen ennen toiminnan alkua, normaalin toiminnan kuvauksen, poikkeustilanteiden kuvauksen, tiedot mahdollisista muista samanaikaisista tapahtumista, jotka vaikuttavat tähän käyttöesimerkkiin ja järjestelmän tilan kuvauksen toiminnan päättymisen jälkeen. Sivu - 84-10
Käyttötapaukset Käyttötapaus (use-case) sisältää yhden tai useamman käyttöesimerkin järjestelmästä. Samankaltaiset tai samoihin järjestelmän osiin vaikuttavat käyttöesimerkit kootaan saman käyttötapauksen alle. Jokainen käyttötapaus kertoo yhden tavan toimia kehitettävässä järjestelmässä, toiminnan tehtävät ja toimintaan osallistuvat sidosryhmät. Käyttötapaukset voivat olla selväkielistä tekstiä tai niihin voidaan käyttää sopivaa kuvaustekniikkaa. Käyttötapauksia voidaan tarkentaa käymällä asiakkaan luona katsomassa nykyistä toimintaa. Sivu - 85 - Vaatimusten tyypittely Kun vaatimukset on saatu kerättyä, luokiteltua ja mallinnettua, ne tyypitellään käyttäjän vaatimuksiin ja järjestelmävaatimuksiin. Samalla tarkistetaan, että vaatimukset vastaavat kehitettyjä malleja ja että mallit ovat täydelliset ja riittävät. Tarvittaessa palataan takaisin keräämään ja analysoimaan lisää vaatimuksia. Tämän työvaiheen tuloksena saadaan yksityiskohtaiset vaatimuslistat ja korkean tason ohjelmistosuunnitelmat kehitettävästä ohjelmistosta. Sivu - 86-11
Vaatimusten validointi Viimeisenä vaiheena kerätyt, analysoidut, tarkennetut ja tyypitellyt vaatimukset validoidaan. Tarkoituksena on selvittää, että saatu vaatimuslista ja vaatimusten perusteella kehitetyt mallit ovat yhtenäiset ja toteuttavat vaatimuksille asetetut ominaisuudet: Vaatimusten on oltava virheettömiä, ristiriidattomia, täydellisiä, realistisia, tarpeellisia, todennettavissa ja jäljitettävissä. Vaatimusten validointia varten saatetaan rakentaa järjestelmästä prototyyppi tai kirjoittaa alustava käyttöohje. Sivu - 87-4.5 Vaatimusanalyysin hallinta Vaatimusanalyysi on prosessi, joten se tarvitsee hallintaa. Hallinnan tehtävä on organisoida työvaiheet ja varustautua siihen, että vaatimukset muuttuvat projektin edetessä. Myös vaatimusanalyysiin kuuluu riskienhallintaa. Riskit tunnistetaan ja niihin varaudutaan. Esimerkiksi jos on todennäköistä, että vaatimukset elävät voimakkaasti projektin aikana, kehitetään mieluummin lisäävällä mallilla tai prototyyppimallilla ohjelmistoa vähän kerrassaan toivottuun suuntaan. Sivu - 88-12