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

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ä

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ää

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)

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

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

6. Ohjelmistojen tuottaminen = speksien tuottamista?

7. Määriteltäviä asioita (kuva 3.2)

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) (?)

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.

10. Requirements Engineering (Wiegers 1999) Requirements engineering Requirements develompement Requirements management Elicitation Analysis Verification Specification

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 • …

12. Vaatimustenhallinta (kuva 4.2) määrittely

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? • …

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

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.

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).