Teknillinen korkeakoulu Tik-76.601 Ohjelmistotuotannon perusopintojakso Requirements Elicitation Plan Henna Pietiläinen 45356D Ti Vaatimusmäärittelymenetelmien suunnittelu 1. Johdanto Vaatimustenhallinnan keskeisin tehtävä on varmistaa että lopputuote vastaa asiakkaan vaatimuksia. Lopputuotteessa on oltava kaikki halutut ominaisuudet ja vain ne. Lisäksi vaatimusmäärittely toimii järjestelmän toiminnallisen ja teknisen määrittelyn, sekä kustannusarvion pohjana. Varsinkin isoissa, SAD-projektin kaltaisissa tuotekehityshankkeissa on tavallista, että asiakasvaatimuksia on paljon ja että ne muuttuvat projektin aikana. Lisäksi ohjelmiston käyttäjäkunnan vaatimukset saattavat olla erilaisia ja keskenään ristiriitaisia. Vaatimustenhallinta alkaa asiakasvaatimusten kartoittamisesta. Joukosta alustavia vaatimuksia alustetaan joukko täsmällisesti muotoiltuja keskenään yhteensopivia asiakasvaatimuksia. Näitä menetelmiä, joilla vaatimukset saadaan kerättyä käsitellään tässä muistiossa. Vaatimukset voidaan jakaa karkeasti neljään eri tyyppiin: toiminnallisiin vaatimuksiin (miten järjestelmä toimii, mitä se tekee), tuotteen vaatimuksiin (suorituskyky, luotettavuus, käytettävyys, siirrettävyys), prosessin vaatimuksiin (standardit, ohjelmointikielet) ja ulkoisiin vaatimuksiin (kustannukset). Asiakasvaatimuksia ja niistä johdettavia vaatimusmäärittelykandidaatteja saadaan mm. markkinoilta, omasta organisaatiosta, prototyyppejä rakentamalla, ideointiaivoriihien tuloksena ja tutkimalla kilpailijoiden tuotteita. Vaatimuksia voidaan kartoittaa myös käyttötapausten (use case) avulla, joissa kuvataan järjestelmän käyttäjien tapaa käyttää järjestelmää. Koska vaatimukset tulevat muuttumaan projektin suorituksen aikana on myös vaatimusten muutostenhallinta tärkeää. Muutostenhallintaa varten pitää määritellä erityiset menettelytavat. On ainakin sovittava miten muutoksia asiakasvaatimuksiin hyväksytään. 2. Käytettävien metodien määrittely Vaatimusten määrittelyssä voidaan käyttää ainakin seuraavia tekniikoita ja menetelmiä: havaintoja, valmisteltuja ja valmistelemattomia haastatteluja, protokolla-analyysejä, korttien lajittelua, ohjelmistokaavioita, brainstormingia, alkeellisia prototyyppejä, skenaarioanalyysiä, RAD-menetelmää ja kansantieteellisiä menetelmiä. Aikaisemmin Softwhere ei ole käyttänyt vaatimusmäärittelyissään mitään erityisiä menetelmiä tai tekniikoita, vaan läheiset suhteet asiakkaisiin ovat mahdollistaneet vaatimusmäärittelyjen teon epävirallisemmin. Nyt kuitenkin SAD-projektin asiakasryhmä on hyvin hajanainen ja asiakkaita on ympäri maailmaa, jolloin tarvitaan selkeät menetelmät vaatimusmäärittelyn tekoon. Seuraavassa esittelen kaksi mielestäni hyvää ja kaksi huonoa menetelmää vaatimusmäärittelyn tekoon. 2.1 Hyvät menetelmät Mielestäni SAD-projektin vaatimusten määrittelyyn sopivia menetelmiä ovat prototyyppien teko ja kansantieteellinen menetelmä. Prototyyppien teko on mielestäni hyvä tapa tutkia käyttäjien vaatimuksia, koska siinä käyttäjä pystyy aidon tuntuisessa tilanteessa tutkimaan tulevaa järjestelmää, millaisia toimintoja siinä haluaisi olevan sekä kertomaan millainen sen käyttöliittymän tulisi olla. Prototyyppien avulla saadaan käyttäjältä selkeää palautetta ja korjausehdotuksia. Huonona puolena on kuitenkin se, että prototyypin tekemiseen kuluu aikaa. Kansantieteellinen menetelmä taas tarkoittaa sitä, että SAD-projektista joku asiantuntija viettäisi aikaa asiakkaan organisaatiossa ja tutustuisi siellä käytettyihin menetelmiin ja niihin tarpeisiin joita uudelle järjestelmälle on asetettu. Mielestäni tämä on hyvä menetelmä koska tällä tavoin saadaan järjestelmä vastaamaan asiakkaan jokapäiväisiä tarpeita, termistö on oikeanlaista ja organisaation työtavoista voidaan ottaa mallia järjestelmän käyttöominaisuuksiin. 2.2 Huonot menetelmät Mielestäni SAD-projektin vaatimusten määrittelyyn sopivat erityisen huonosti haastattelut ja brainstorming. Haastattelut eivät mielestäni sovellu, koska käyttäjiä on niin paljon ja he edustavat eri kansallisuuksia, jonka takia jo kulttuurierojen vuoksi ajattelevat asioista eri tavalla. Tämän takia on hankalaa keksiä kaikille yhteiset, selkeät kysymykset joiden vastausten perusteella vaatimusmäärittely voitaisiin tehdä. Lisäksi haastatteluilla on hyvin vaikea löytää todellisia vaatimuksia. Kysymyksistä tulee helposti johdattelevia, siten että vaatimusmäärittelystä ei tulekaan asiakkaiden vaatimuksia vaan kysymysten tekijän vaatimuksia. Jos kysymykset taas ovat kovin avoimia on asiakkaan vaikea keksiä niihin vaatimuksia, kun hänellä ei ole vielä selkeää kuvaa tulevasta järjestelmästä. Brainstorming taas on mielestäni huono menetelmä siksi, että sen avulla saadaan luultavasti hyvin toisarvoisia vaatimuksia kun taas kaikkein oleellisemmat vaatimukset saattavat unohtua. Tämä johtuu siitä että brainstormingissa ei kukaan ole ohjaamassa keskustelua ja ideointia vaan ne lähtevät leviämään laajalle alueelle. Kuitenkin vaatimusmäärittelyssä olisi tärkeintä saada ensin tietoon ne keskeiset perusvaatimukset ja sitten vaikka myöhemmin esittää toiveita joidenkin yksityiskohtien vaatimuksista. 3. Vaatimusten dokumentointi Vaatimukset voitaisiin mielestäni dokumentoida vaatimusmäärittelyyn sen jälkeen kun ne ensin on määritelty prototyyppien ja asiakkaan organisaatioon tutustumisen avulla. Tämän jälkeen vaatimusmäärittelydokumentti käytäisiin yhdessä läpi asiakkaan edustajan kanssa ja tutkittaisiin vaatimusten oikeellisuus ja riittävyys. Kun vaatimusmäärittelydokumentti on saatu kaikkia osapuolia tyydyttävään muotoon se talletetaan ohjenuoraksi toiminnallista ja teknistä määrittelyä varten. Lisäksi sitä voidaan käyttää apuna kustannusanalyysin teossa. 4. Vaatimusten muutostenhallinta Koska on hyvin oletettavaa, että asiakkaan vaatimukset tulevat muuttumaan SAD-projektin suorituksen aikana pitää Softwheren mielestäni perustaa erillinen muutostenhallintatoimikunta, joka huolehtii vaatimusmäärittelyyn tulevista muutoksista. Muutostenhallintatoimikunta on tarpeellinen, koska kun asiakas haluaa muuttaa vaatimuksiaan, pitää ennen vaatimusten muuttamiseen suostumista tutkia tarkasti paljonko lisää työtä uudet vaatimukset tuovat, sopia näiden muutosten aiheuttamista kustannuksista ja ylipäänsä varmistaa ovatko asiakkaan haluamat muutokset edes mahdollisia tai kannattavia toteuttaa. 5. Vastuualueet Vaatimusmäärittelyn tekemiseksi tarvitsemme prototyypin tekijöitä, sekä asiakkaan organisaatioihin perehtyviä ihmisiä. Ehdotan että koko käyttöliittymätiimi valmistelee prototyyppiä ja erityisesti sen käyttöliittymää, mikä kuitenkin on erittäin oleellinen osa prototyyppiä. Toimintotiimi taas valmistelee prototyyppiin muutaman perustoiminnallisuuden, joiden avulla asiakkaat pystyvät saamaan järjestelmästä jonkinlaisen kuvan. Vastuu prototyypin valmistumisesta tulee siis käyttöliittymän osalta käyttöliittymätiimin vetäjälle Keijo Käylille ja toiminnallisuuden osalta toiminnallisuustiimin vetäjälle Timo Toiminnalle. Testaustiimistä taas voisi 5 ihmistä tutustua viiteen tärkeimpään organisaatioon, joissa järjestelmää tullaan käyttämään. Organisaatioihin tutustumisesta ja asiakkaiden työtapojen tutkimisesta ja niiden dokumentoinnista on vastuussa testitiimin vetäjä Tero Testi. Lisäksi tarvitsee nimetä muutostenhallintatoimikunta, joka hoitaa asiakkaan vaatimusten muutoksien hyväksymisestä tai hylkäämisestä. Ehdotan että toimikunnan jäseniä olisivat: Niilo Nörtti, tekninen asiantuntija Keijo Käyli, käyttöliittymäasiantuntija Timo Toiminto, toiminnallisuuden asiantuntija Pekka Porho, kustannusten asiantuntija Henna Pietiläinen, projektin vastaava 6. Aikataulu Vaatimusmäärittely pitää mielestäni saada valmiiksi mahdollisimman nopeasti, jotta sen pohjalta voidaan ruveta valmistelemaan toiminnallista ja teknistä määrittelyä. Ehdotankin että prototyypin valmistaminen aloitetaan välittömästi ja että se pyritään saamaan valmiiksi kolmessa viikossa. Kun prorotyyppi on valmis voisi Pierre Lebum mielestäni vastata siitä että sopiva määrä (20?) asiakasta tutkii prototyyppiä ja esittää parannusehdotuksensa ja omat vaatimuksensa. Pierre voisi mielestäni myös vastata noiden vaatimusten dokumentoinnista. Samoin mielestäni pitää heti ruveta selvittämään mitkä ovat ne viisi tärkeintä organisaatiota, joihin lähetämme asiantuntijamme tutustumiskäynnille. Tutustumisaika voisi mielestäni olla viikon mittainen, jonka jälkeen välittömästi organisaatioissa vierailleet asiantuntijat raportoivat havaintonsa. Myös muutostenhallintatoimikunta kannattaa mielestäni perustaa heti, vaikkei sitä vielä tarvitakaan, siksi että se on sitten toimintavalmiina kun sitä ensimmäisen kerran tarvitaan. Kun tarvittavat vaatimukset on saatu kerättyä asiakkaalta, työstetään niistä vaatimusmäärittelydokumentti. Vaatimusmäärittelydokumentin vastuuhenkilönä voisin toimia minä itse. Dokumentin tekemiseen varataan yksi päivä aikaa. Kun dokumentti on valmis sovitaan tapaaminen Pierre Lebumin, Klaus Ordnungin ja mahdollisesti muiden asiakkaan edustajien kanssa ja käydään vaatimusdokumentti läpi. Jos dokumenttiin halutaan muutoksia tehdään tarvittavat korjaukset mahdollisimman nopeasti ja hyväksytetään dokumentti asiakkaalla uudestaan.