Vaatimukset mitä ne ovat Miten teillä hanskataan vaatimukset? Ei juuri mitenkään. Ville Reijonen, Kauppalehti Online 27.8.2012 1
Asiakasvaatimuksista tuotteeseen asiakasvaatimukset Määrittely Suunnittelu& toteutus ohjelmistovaatimukset
Asiakasvaatimus...tekninen vaatimus Asiakasvaatimus tyypillisesti asiakkaan ongelma, jolle toivotaan ratkaisua: tuotetaan mahdollisimman virheettömiä dokumentteja. Ominaisuus, feature jokin asiakkaan kannalta mielekäs kokonaisuus ohjelmiston toiminnallisuudesta: tuki oikeinkirjoituksen tarkastamiselle. Ohjelman toiminto yksittäinen ohjelmistolla tehtävä asia: tarkasta oikeinkirjoitus, ehdota korjausta, korjaa automaattisesti... Tekniset vaatimukset miten ohjelmisto toteutetaan: tiedostopuskuri, dialogin toteutus,... Kannattaa huomata, että luokittelu ei ole mitenkään itsestään selvä. asiakasvaatimukset ohjelmistovaatimukset
Rajoitteiden rooli Rajoite 1 Rajoite 2 Kaikki mahdolliset ratkaisut
Hyvän speksin/vaatimuksen ominaisuuksia täydellisyys: kaikki tarpeellinen, ei mitään turhaa tarkkuus virheettömyys ymmärrettävyys testattavuus: miten voidaan "mitata", onko vaatimus täytetty jäljitettävyys: mistä vaatimus on peräisin, miten tärkeä se on, bisnesarvo sama asia vain yhdessä paikassa (ei redundanssia) (?)
Esimerkkejä Järjestelmän käytettävissä on 64k-tavun muisti. Luokalla voi siis olla vain yksi luokanvalvoja? Jos kuukauden toteutunut myynti alittaa tavoitteet, tulostetaan raportti, ellei toteutuneen myynnin ja tavoitteen ero ole vähemmän kuin puolet edellisen kuukauden tavoitteen ja toteutuneen myynnin erosta, tai toteutunut myynti alittaa tavoitteen alle 5%. Varaston kiertonopeus kasvaa. Ilmoituksen on oltava kuvaruudulla 300ms kuluessa hälytyksen tapahtumisesta. Suihkumoottoreita ei saa kytkeä pakille ellei kone ole kentällä. Suihkumoottoreita ei saa kytkeä pakille ellei nokkapyörä pyöri tai nopeus ole nolla.
Määrittelyvaihe Ideat, lähtökohdat, rajoitteet, reunaehdot Ongelman ymmärtäminen, vaatimusten kartoitus Määrittelyprosessi Toteutettavan järjestelmän spesifiointi Asiakasvaatimukset korjattavaa Ohjelmistovaatimukset Toiminnallinen määrittely, alustava käyttöohje, toteutusprojektin projektisuunnitelma, testaussuunnitelma Tarkastus Asiakasvaatimukset muuntuvat ohjelmistovaatimuksiksi OK Arkkitehtuurisuunnittelu
Miten asiakasvaatimukset saa selville Toimialan tuntemusta ei korvaa mikään. Tee luettelo sidosryhmistä (stakeholder). Mieti, mitä odotuksia/toiveita/pelkoja jne... kullakin sidosryhmällä on. Keskustele käyttäjien kanssa heidän työpaikallaan. Suunnittele vierailut etukäteen huolellisesti. Tekeydy hieman tyhmemmäksi kuin luulet olevasi. Esitä varmistavia kysymyksiä: tarkoitat siis, että Käytä esitystapoja, joita asiakas ymmärtää. Analysoi ja dokumentoi vierailun anti, tee yhteenveto. Yritä löytää alkuperäinen ongelma: miksi jokin asia pitää tehdä, voisiko sen jostain syystä jättää kokonaan tekemättä. yritä erottaa oleellinen pinttyneistä toimintatavoista Prototyypit. Käyttäjäkeskeinen suunnittelu (User Centered Design)
Mitä vaatimuksesta kirjataan (esimerkki) Luontipäivämäärä Tekijä Asiakas, vaatimuksen alkuperä Tyyppi (lisäys, muutos, korjaus) Vaatimuksen kuvaus Suhde muihin vaatimuksiin Tarpeellisuus (välttämätön, suotava, ekstra) Varmuus: ei muutu, saattaa muuttua, muuttuu todennäköisesti
Speksin kirjoittamisesta Ohjelmistojen tekeminen on speksien tekemistä. Kirjoita asiakkaan näkökulmasta. Yhdellä dokumentilla voi olla erilaisia asiakkaita (asiakkaan tietohallintopäällikkö, pääkäyttäjä, käyttäjä ). Etene yleiskuvauksesta yksityiskohtiin. Käytä selkeää yksinkertaista kieltä, ei maalailua tai huumoria. Havainnollista esimerkeillä. Vältä tarpeetonta toistoa (say it once and just once). Ei moniselitteisyyksiä ja ristiriitaisuuksia. Vaatimuksien toteutumisen on oltava kiistatta todettavissa. Dokumentoi myös syyt, miksi näin tehdään. Ole realisti: dokumentit vanhenevat nopeasti, eikä kaikkea kannata/ehdi ylläpitää. Käytä liitteitä: Täydelliset syntaksikuvaukset (esim. BNF, XML Schema) yms. raskaat speksit. Automaattisesti generoitavissa olevat osat (esim. rajapintakuvaukset). Usein muuttuvat osat. Ylläpitovaiheessa tarpeettomiksi käyvät osat (esim. yksityiskohtaiset käyttöliittymäkuvaukset).
Työkaluja vaatimustenhallintaan Caliber Polarion Wiki 27.8.2012 11
Vaatimusten mallintaminen: käyttötapaukset ja kaaviot A use case is a kind of classifier representing a coherent unit of functionality provided by a system, a subsystem, or a class as manifested by sequences of messages exchanged among the system (subsystem, class) and one or more outside interactors (called actors) together with actions performed by the system (subsystem, class)." A use case diagram is a graph of actors, a set of use cases, possibly some interfaces, and the relationships between these elements. The relationships are associations between the actors and the use cases, generalizations between the actors, and generalizations, extends, and includes among the use cases. The use cases may optionally be enclosed by a rectangle that represents the boundary of the containing system or classifier.
Dipparekisteri Ohjelmistotekniikan laitoksella valmistuu noin 100 diplomityötä vuodessa D-työn tekemiseen kuluu aikaa muutamista kuukausista useisiin vuosiin D-töitä ohjaavat laitoksen professorit, kukin hieman toisista poikkeavalla tavalla D-työstä ylläpidetään aina tiettyjä perustietoja, lisäksi ohjaajilla on henkilökohtaisia tapoja pitää muistiinpanoja D-töiden etenemistä seurataan: diplomityön rajaus valmis, aihe hyväksytty tk-neuvostossa, x sivua kirjoitettu, työ tuotu tarkastettavaksi, työ hyväksytty, seminaariesitelmän pvm, jne.) Järjestelmän pitää siis sisältää yhteinen tietovarasto, jossa on kaikkien diplomitöiden perustiedot ja toisaalta yksittäisen ohjaajan tietovaraston pitää olla henkilökohtaisiin tarpeisiin mukautettavissa (ja käytettävissä ilman verkkoyhteyttä?).
Käyttötapauskaavio, versio 1 Dipparekisteri Lisää uusi opiskelija Lisää uusi kenttä Ohjaaja Etsi ehdot täyttävät opiskelijat tee palaverimuisti o kirjoita lausunto Pohja järjestelmän hahmottamiselle ja siitä keskustelemiselle
Käyttötapauskaavio, versio 2 Dipparekisteri Lisää uusi opiskelija Lisää uusi kenttä Ohjaaja Etsi ehdot täyttävät opiskelijat tee palaverimuistio lisää/poista ohjaaja kirjoita lausunto Laitoksen johtaja tarkastele tilastoja
Toinen esimerkki KT-kaaviosta (kuva 8.6) Salinvarausjärjestelmä Varausten poistaminen Vastuu - henkilö Luentosalin varaaminen <<include>> <<include>> Perustietojen ylläpito ylläpitäjä <<include>> assistentti Harjoitussalin varaaminen <<include>> Käyttäjän identifiointi Salivuokran laskutus <<actor>> vuokrajärjestelmä
esimerkki (kuva 8.7) Nimi: Luentosalin varaaminen, versio 1.0 / ijh Osallistujat: Kurssin vastuuhenkilö Tuloehdot: Vastuuhenkilö ja kurssi on syötetty järjestelmään (KT henkilötietojen ylläpito) Kuvaus: Vastuuhenkilö seuraa WWW-linkkiä, joka johtaa järjestelmän pääsivulle. Hän syöttää järjestelmään käyttäjätunnuksensa ja salasanansa (include: KT käyttäjän identifiointi). Käyttäjä pyytää järjestelmää näyttämään salin varaustilanteen haluamaltaan aikaväliltä. Hän saa eteensä salin lukujärjestysnäytön (ks. liite). Käyttäjä näkee näytöstä vapaat ajat sekä myös, mille kursseille sali on milloinkin varattu ja kuinka monelle viikolle. Käyttäjä tekee varauksen joltain vapaaksi havaitsemaltaan ajankohdalta. [Poikkeus: varaus ei onnistu]. Poikkeukset: Varaus ei onnistu: Varaustilanne on voinut muuttua sillä aikaa kun varaaja tekee varausta. Järjestelmä ilmoittaa tilanteesta käyttäjälle ja käyttäjä yrittää uudelleen. Lopputulos:Varaukset kurssin luentoajoiksi on tehty. Muut vaatimukset:päivittäin käsitellään kiireisimpänäkin aikana enintään n. 100 varausta. Vastausajan on oltava alle 1 sekuntia, lukujärjestysnäytön päivitys saa kestää 5 sekuntia.
Käyttötapauksen kuvaaminen UML ei standardoi mitenkään esitystapaa, eikä oikeastaan juuri muutakaan niihin liittyvää => paljon erilaisia tulkintoja Käyttötapauksen sisältö voidaan kuvata esimerkiksi: Käyttötapauksen nimi: Kuvaava nimi Osallistujat: Mitkä aktorit osallistuvat Tuloehdot: Mitkä ehdot ovat voimassa, kun käyttötapaus aloitetaan Kuvaus: Epäformaali, voidaan käyttää myös sekvenssikaavioita Poikkeukset: Poikkeustilanteet (mainitaan myös kuvauksessa) Lopputulos: Mitkä ehdot ovat voimassa, kun käyttötapaus lopetetaan Muut vaatimukset: käyttötapaukseen liittyvät ei-toiminnalliset vaatimukset
Käyttötapauskaavio: notaatio Aktori: käyttötapaukseen osallistuva käyttäjärooli Järjestelmä Käyttötapaus Käyttötapaus sisältää laajennuskohtia, joihin toinen käyttötapaus voidaan sijoittaa <<extend>> Käyttötapaus Käyttötapaus Aktori Käyttötapaus sisältää toisen osanaan <<include>> Käyttötapaus Käyttötapaus on erikoistapaus toisesta
Vältä käyttötapausten välisiä suhteita Accounting System Pay invoice Byer <<extend>> Pay overdraft fee Perform interaction Seller Älä käytä erikoistamista ja laajentamista ja sisällyttämistäkin vain säästeliäästi.
Käyttötapausten laatimisesta Käyttötapauskaavio tukee käyttötapojen suhteiden kuvaamista, ei niiden sisällön kuvaamista. UML ei määrittele sisällön esitystapaa. Käyttötapausten tulee olla ymmärrettävissä sekä asiakkaan että suunnittelijan kannalta. Käyttötapauksen abstraktiotason on oltava sopiva (ei esim. yleensä käyttöliittymän yksityiskohtia). Kaikkia käyttötilanteita/asiakasvaatimuksia ei voi/kannata antaa käyttötapauksina. Käyttötapauksella tulee olla selkeä aloitustilanne ja lopetustilanne. Käyttötapauksen "suuruudesta" päättäminen voi olla vaikeaa: Käyttötapauksen tulisi olla suhteellisen lyhyt (yhden sivun kuvaus). Käyttötapaus tuottaa käyttäjälle lisäarvoa (ei yleensä yksittäinen ohjelmiston toiminto, vaan kokonainen tuloksen tuottava ketju toimintoja). Käyttötapaus ei siis yleensä ole yksittäinen ohjelmalla suoritettava toiminto (ei siis esimerkiksi: tekstin kopiointi
Miksi käyttötapauksia? Toimii apuna hahmotettaessa järjestelmää (yhteinen näkemys järjestelmästä) Liittää asiakasvaatimukset järjestelmän toimintoihin Mahdollistaa vaatimusten täsmentämisen Rajaa järjestelmän ympäristöstään Auttaa tunnistamaan kuka tai mikä käyttää järjestelmää Määrittää järjestelmän korkean tason toiminnallisuuden Auttaa jakamaan toiminnallisuuden osajärjestelmiin. Määrittää järjestelmän perustermit Apuna keskeisten käsitteiden tunnistamisessa Voidaan käyttää ohjelmistokehityksen organisointiin (iteraatioiden suunnittelu) Testauksen suunnittelu Käyttöohjeiden laatiminen
KT:a käytetään usein liittämään asiakasvaatimukset järjestelmä/ohjelmistovaatimuksiin (~kuva 8.8) Asiakasvaatimukset Ohjelmistovaatimukset tekstin kopiointi tekstin siirtäminen............ KT kopioi teksti KT siirrä teksti maalaa kopioi leikkaa siirrä kohdistin liitä............
Käyttäjätarina (user story) Ketterissä menetelmissä yleisesti käytetty termi. Muutamaan lauseeseen typistetty "käyttötapaus" Tarinasta selviää: rooli (aktori) mitä tehdään ja mahdollisesti mitä lisäarvoa tekeminen tuottaa käyttäjälle (usein tämä on kuitenkin ilmeistä) Esimerkiksi: Kurssin vastuuhenkilönä pystyn tekemään kaikki yhden kurssin luentosalivaraukset yhdellä varausoperaatiolla (silloin kun luentoajat ovat koko kurssin ajan samoina viikonpäivinä samaan kellonaikaan).