T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. Päivämäärä 28.10.2002 Projektiryhmä Keimo keimo-dev@list.hut.fi Kirjoittajat Matti Kannala matti.kannala@hut.fi Muutokset PVM Tekijä Versio Selitys 27.10.2002 Matti Kannala 0.9 Dokumentti PP-vaiheen palautukseen 28.10.2002 Iiro Ojala 1.0 Dokumentin yhtenäistäminen 24.11.2002 Matti Kannala 1.1 Dokumentin yhtenäistäminen 30.11.2002 Matti Kannala 2.0 T1-vaiheen kokemukset 1
Sisällysluettelo 1 Yleistä... 3 2 projektissa... 3 3 Vaatimusten hyväksyminen ja testaus... 4 4 Käyttöönottsuunnitelma... 4 5 Käyttöönotto kokemukset... 4 5.1 T1-vaihe... 4 6 Lähteet... 5 2
1 Yleistä Vaatimukset ovat järjestelmän toimintoja, ominaisuuksia ja rajoituksia. on systemaattinen menetelmä vaatimuksien löytämiseen, dokumentointiin, organisointiin ja muutosten hallintaan. a tehdään koko projektin ajan. Vaatimusten määrittely Määrittely & Suunnittelu & Ohjelmointi & Testaus Hyväksymistestaus Vaatimusten hallinta 2 projektissa Tässä projektissa vaatimukset kerätään asiakastapaamisissa ja projektiryhmän palavereissa. Kaikille vaatimuksille annetaan yksilöllinen tunnus ja ne dokumentoidaan vaatimuslistaan. Vaatimuslista on yksinkertainen lista vaatimuksista tunnisteineen. Listasta jalostetaan käyttäjävaatimusdokumentti, johon toiminnalliset vaatimukset kirjataan käyttäjätapauksina ja ominaisuudet sekä rajoitukset kirjataan normaaleina vaatimuksina. Käyttäjävaatimusdokumentissa on vaatimusten lisäksi määritelty käyttäjäryhmät ja vaatimuksien prioriteettivaihtoehdot. Jokaiselle vaatimukselle määritellään molemmat näistä. Vaatimusten priorisointi tehdään Priorization scales - menetelmällä [1]. Käyttäjävaatimusdokumentissa on lisäksi kerrottu vaatimuksienmuutosprosessi ja vaatimuksientoteutumisen mittaamiseen käytettävät mittarit. Vaatimustenmäärittelyn jälkeen alkaa varsinainen vaatimustenhallinta. Keskimäärin 50% vaatimuksista tulee muuttumaan projektin aikana [2]. Vaatimustenhallinnassa ei käytetä mitään erityistä siihen tarkoitettua ohjelmistoa vaan käytössä on Microsoft Word 2000 ja tavallinen tekstieditori. Vaatimustenhallinnassa muutosehdotus käy läpi seuraavan prosessin: 1. Tehdään muutosehdoitus (mahdollisimman tarkka esitys) 2. Analysoidaan muutosehdoitus (vaikutus, kustannus, hyöty) 3. Tehdään päätös muutoksesta (sopimus asiakkaan kanssa) 4. Tehdään muutos (dokumentin päivitys, tiedotus) 3
3 Vaatimusten hyväksyminen ja testaus Projektisuunnitelma-vaiheen loputtua vaatimusmääritelmä hyväksytetään asiakkaalla ja samalla sitoudutaan noudattamaan vaatimuksia toimitettavassa tuotteessa. Sen jälkeen vaatimustenhallinnassa jokainen muutos vaatimuksiin käy läpi vaatimustenmuutosprosessin. Vaatimuksia, varsinkin käyttäjätapauksia käytetään tuotteen testien määrittelyyn. Näistä tärkein on vaatimuksien kannalta hyväksymistestaus, joka perustuu tarkasti vaatimuksiin. Sen avulla voidaan todeta onko tuote toteuttanut sille annetut vaatimukset ja onko se hyväksyttävä toimitettavaksi. 4 Käyttöönottsuunnitelma otettiin käyttöön projektissa heti projektin alettua. Projektin alkuvaiheessa vaatimustenhallinta oli lähinnä niiden keruuta ja vaatimusdokumentin kirjoittamista. Vaatimusten keruussa oli käytössä yksinkertainen teksti-editori, jolla asiakastapaamisissa tulleet vaatimukset listattiin. Vaatimustenkeruuta varten olisi kannattanut tehdä jonkinlainen kaavake, johon olisi ollut helppo syöttää vaatimuksia. Hyvä ratkaisu olisi ollut esimerkiksi HTML-kaavake, joka postittaa syötetyn vaatimuksen niiden kerääjälle. Seuraavassa vaiheessa alkaa varsinainen vaatimustenhallinta. Vaatimuksiin alkaa tulla muutoksia. Vaatimusten muutosehdoituksia varten tehdään HTML-lomake, jonne asiakas tai ryhmän jäsen voi syöttää muutosehdoituksen. Muutos ehdoitukset analysoidaan ryhmän viikkopalavarissa. Sen jälkeen niistä tehdään päätös asiakkaan kanssa asiakastapaamisessa. Lopuksi, jos päätös on myönteinen, muutetaan käyttäjävaatimusdokumenttia ja ilmoitetaan kaikilleosapuolille muutoksesta. 5 Käyttöönotto kokemukset 5.1 T1-vaihe Projektin suunnitteluvaiheessa kirjoitettuun käyttäjävaatimusdokumenttiin tuli muutoksia vain vaiheen alkupuolella. Asiakas antoi heti vaiheen alussa laajan palautteen, joka sisälsi korjaus- ja muutosehdoituksia. Pari ryhmän jäsentä kävi palautteen läpi ja sen jälkeen palaute käsiteltiin ryhmän viikkopalaverissa. Joitakin hieman epäselviä kohtia tarkennettiin asiakkaalta samaisen palaverin loppupuolella, jolloin asiakas oli myös paikalla. Lopuksi käyttäjävaatimusdokumenttiin tehtiin palaverin päätösten mukaiset muutokset. Lisäksi muutokset kirjattiin ylös dokumentissa niitä varten tarkoitettuun kappaleeseen. HTML-lomakketta ei käytetty tässä vaiheessa kertaakaan. Toisaalta asiakkaan palautteen lisäksi ei muita muutosehdoituksia tullut ja palautteen asioita olisi ollut turha lomakkeella kautta kierrättää. 4
Muutokset käyttäjävaatimusdokumenttiin T1-vaiheessa: Lisätty lokaaleihin valaistusmalleihin käyttötapaus valojen liikuttamisesta. Lisätty kaikkien visualisointien toimintoihin käyttötapaukset visualisointiohjelman ja yksittäisen visualisoinnin käynnistämisestä Lisätty käyttötapaus materiaalikirjastosta Varjot-visualisoinnin nimi muutettu Globaaleiksi valaistusmalleiksi ja prioriteetti laskettu suositeltavaksi Perustransformaatioiden prioriteettiä nostettu välttämättömäksi Lisätty kuva käyttöliittymän prototyypistä Dokumentti yhtenäistetty 6 Lähteet [1] QURE-projekti (Quality through Requirements), 16.11.2001 [2] G. Kotonya and I. Sommerville, Requirements Engineering Processes and Techiques, John Wiley & Sons, New York, 1998 5