Näkökulmia määrittelyyn (materiaali pääosin luvusta 4)

Esitys aiheesta: "Näkökulmia määrittelyyn (materiaali pääosin luvusta 4)"— Esityksen transkriptio:

1 Näkökulmia määrittelyyn (materiaali pääosin luvusta 4)
Määrittely eli speksaus Mitä vs. miten Hyvien vaatimusten ominaisuuksia Requirements Engineering Miten asiakasvaatimukset saa selville 18.11: vaatimustenhallinta ja speksin kirjoittamisesta jäi käsittelemättä /ijh

2 Määrittely Määrittely, eli kansanomaisesti speksaus, tarkoittaa yleisesti asioista sopimista asiakkaan ja toteuttajan välillä: Todetaan, että hanke voidaan (tai ei voida) viedä läpi. Toteuttaja tietää mitä tehdään. Asiakas tietää mitä saa. Epäselvät asiat ja riskit tulevat tunnistetuiksi. Käsitteet ja termit täsmentyvät. Määrittely pitää siis kirjoittaa sen lukijaa, so. asiakasta ajatellen. Määrittely Määrittelee kaiken tarpeellisen Ei määrittele mitään turhaa, eli ei kuvaa asioita, joita ei tarvitse vielä kiinnittää, ja/tai joista asiakkaan ei tarvitse tietää /ijh

3 Määrittelyyn liittyviä asioita
Ongelma Ongelman ja ratkaisun tavoitteiden määrittely. Ongelman analysointi (tiedon ja ymmärtämyksen hankkiminen) Sidosryhmien ja käyttäjien tunnistaminen Ratkaisu Toteutettavan järjestelmän rajaaminen ympäristöstä Vaatimusten määrittäminen Järjestelmän tietosisällön ja toimintojen määrittely Ei-toiminnallisten ominaisuuksien määrittely Rajoitteiden ja reunaehtojen etsiminen Riskien identifiointi ja hallinta. Verifiointi ja validointi (todentaminen ja kelpoistaminen) /ijh

4 rittely, mallintaminen ja
Esitutkimus – määrittely – toteutus ohjelmistonkehitysprosessissa (kuva ei kirjassa) esitutkimus määrittely 1. Jäsentämätön ongelma … 5. Validointi: 2. vs. 4. Määrittely- dokumentti (ohjelmisto- vaatimukset) … 8. Validointi:2. vs. 6. Toteutettu järjestelmä 2. Jäsennetty ongelma, vaatimukset ratkaisulle 6. Järjestelmän toteutus Määrittely- dokumentti 3. Järjestelmän rajaus, palvelut Asiakas- vaatimukset Ongelma Ratkaisu toteutus … 8. Verifiointi:4(&2). vs. 6. Toteutettu järjestelmä 4. Ratkaisun mää- rittely, mallintaminen ja dokumentointi Käyttö- tapaukset feature? /ijh

5 käyttäjät eivät osallistu määrittelyyn epätäydelliset vaatimukset
Ohjelmistokehityksen menestystekijät ja ongelmat (CHAOS Report, Standish Group 1995) käyttäjät eivät osallistu määrittelyyn epätäydelliset vaatimukset muuttuvat vaatimukset ja spesifikaatiot + käyttäjien osallistuminen + johdon tuki + selkeät vaatimukset ja määrittely Määrittelyvirheet ovat kalliita! /ijh

6 Ohjelmistojen tuottaminen = speksien tuottamista?
/ijh

7 Määriteltäviä asioita (kuva 3.2)
/ijh

8 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 sama asia vain yhdessä paikassa (ei redundanssia) (?) /ijh

9 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. /ijh

10 Requirements Engineering (Wiegers 1999)
develompement Requirements management Elicitation Analysis Verification Specification /ijh

11 Kirjanpito vaatimuksista
Yksikäsitteinen identifikaatio (numerointi) Vaatimuksen määrittely Vaatimuksen tarkoitus Viittaus käyttötapaukseen Vaatimuksen status, esim. esitetty, analysoitu, jäädytetty Vaatimuksen verifiointivaatimukset (miten voidaan voidaan todeta, että vaatimus on täytetty) Lähde: mistä vaatimus on peräisin Tärkeys, esim. välttämätön, toivottu, valinnainen Muutosherkkyys, esim. korkea, normaali, olematon Viittaukset liitemateriaaleihin Riippuvuudet muista vaatimuksista Ristiriidat muiden vaatimusten kanssa Versiohistoria … /ijh

12 Vaatimustenhallinta (kuva 4.2)
määrittely /ijh

13 Mistä asiakasvaatimukset tulevat: sidosryhmät (stakeholders)
Kuka tahansa, jonka toimintaan järjestelmä vaikuttaa/liittyy: Ketkä käyttävät järjestelmää (voi olla useita erilaisia ryhmiä)? Ketkä hyödyntävät järjestelmän tuotoksia? Järjestelmän aikaisemmat versiot? Mihin muihin järjestelmiin järjestelmä liittyy? Mihin muihin järjestelmiin järjestelmä vaikuttaa epäsuorasti? Keiden toimenkuvat muuttuvat? Kuka maksaa? Kuka hyötyy? Kuka arvioi järjestelmää? Kuka kehittää ohjelmistot? Kuva hyväksyy lopputuloksen? Kuka ylläpitää? Kenen laitteistolla järjestelmää ajetaan? Viranomaistahot ja –määräykset? … /ijh

14 Best Practices (Hofmann&Lehner 2001) in requirements engineering
Käyttäjien osallistuminen Tunnista ja tutki kaikki mahdolliset vaatimuslähteet Parhaat/kokeneimmat henkilöt vaatimusmäärittelyyn 15-30% koko projektin kustannuksista Hyvät dokumenttipohjat Tunnista sidosryhmät ja keskustele kaikkien kanssa Priorisoi vaatimukset Käytä malleja ja prototyyppejä Säilytä vaatimusten jäljitettävyys Katselmoi ja tarkasta /ijh

15 … ja muita hyväksi havaittuja konsteja
Toimialan tuntemus on tarpeen. 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 yritä keksiä uusi tehokkaampi toimintatapa. Ideointipalaverit. /ijh

16 Speksin kirjoittamisesta
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). /ijh