Vaatimusten ja käyttöliittymäratkaisujen suhde nykyisessä vaatimusmäärittelyssä ja kuinka prosessia voisi kehittää Marju Kettunen, 7.2.2007 Seminaari:

Esitys aiheesta: "Vaatimusten ja käyttöliittymäratkaisujen suhde nykyisessä vaatimusmäärittelyssä ja kuinka prosessia voisi kehittää Marju Kettunen, 7.2.2007 Seminaari:"— Esityksen transkriptio:

1 Vaatimusten ja käyttöliittymäratkaisujen suhde nykyisessä vaatimusmäärittelyssä ja kuinka prosessia voisi kehittää Marju Kettunen, Seminaari: Käyttöliittymän suunnittelun vaikutukset ohjelmistoprosessiin

2 Sisältö Yleisesti vaatimuksista Esimerkkiprojektit
Ohtu-projektien vaatimusmäärittelyohjeet ja niiden toteutuminen esimerkkiprojekteissa Mistä vaatimukset tulivat? Mitkä vaatimukset kiinnittävät käyttöliittymäratkaisuja ja mitkä eivät? Käyttöliittymäratkaisusta näkyvät vaatimukset Vaatimusten ominaisuuksista Pohdintaa Johtopäätökset Kysymyksiä? Lähteet

3 Yleisesti vaatimuksista 1/6 - implisiittiset
Laadukkaat ohjelmistot toteuttavat implisiittiset vaatimukset Esim. Ylläpidettävyys Virheettömyys Ei välttämättä listata erikseen Vaatimushierarkia [Som04]

4 Yleisesti vaatimuksista 2/6 - eksplisiittiset
Esim. Ohjelman toiminnot Vasteajat Käyttäjämäärät Kirjataan vaatimusmäärittelyyn Vaatimushierarkia [Som04]

5 Yleisesti vaatimuksista 3/6 - toiminnalliset ja ei-toiminnalliset
Ohjelmiston tarjoamat palvelut Syötteisiin reagointi Mitä ohjelmiston ei pidä tehdä Luonnollista kieltä tai kaavioita Intuitiivisesti selkeitä Ei-toiminnalliset Eivät liity suoraan palveluihin Ohjelmiston ja toteutuksen rajoitukset Täsmällisiä lukuarvoja Apuna voidaan käyttää vanhojen ohjelmistojen vaatimuksia Esim. Nopeus Koko Luotettavuus Vaatimushierarkia [Som04] Toiminnallinen Ohjelmistoon pitää pystyä tekemään kyselyjä kulloinkin paikalla olevista käyttäjistä. Ei-toiminnallinen Ohjelmiston on selvitettävä 25 kyselyä sekunnissa. Esimerkkejä vaatimuksista [Som04]

6 Yleisesti vaatimuksista 4/6 - käyttäjävaatimukset
Ohjelmiston palvelut ja rajoitukset Luonnollinen kieli ja kaaviot Analyysin pohja Yhteydenpito asiakkaan kanssa (ei välttämättä teknistä osaamista) Vaatimushierarkia [Som04] Toiminnallinen käyttäjävaatimus [Som01]

7 Yleisesti vaatimuksista 5/6 - järjestelmävaatimukset
Periaatteessa samat kuin käyttäjävaatimukset, mutta yksityiskohtaisemmin Suunnittelun pohja Sopimus asiakkaan ja ohjelmistoyrityksen välillä Vaatimushierarkia [Som04] Toiminnallinen järjestelmävaatimus [Som01]

8 Yleisesti vaatimuksista 6/6 - ympäristövaatimukset
Lähtökohtana toimintaympäristö, ei käyttäjät Jos vaatimuksia ei täytetä, ohjelmisto ei ehkä toimi Esim. Rajapinnat Laskutoimitukset Vaatimushierarkia [Som04] There shall be a standard user interface to all databases which shall be based on the Z39.50 standard. The deceleration of the train shall be computed as: Dtrain = Dcontrol + Dgradient where Dgradient = 9.81ms2 * compensated gradient/alpha and where the values of 9.81ms2/alpha are known for different types of train. Esimerkkejä ympäristövaatimuksista [Som04]

9 Esimerkkiprojektit Oops Ostrobotnia
Osteri-tilanvarausjärjestelmä Ostrobotnian tiloille Asiakas: Ostrobotnia-talo 5 ryhmäläistä Java-sovellus webiin Osterin etusivu Admin-ryhmään kuuluvalle [Blo05]

10 Ohtu-projektien vaatimusmäärittelyohjeet ja niiden toteutuminen esimerkkiprojekteissa
Johdanto Sanasto Käyttötapaukset Käyttäjävaatimukset Järjestelmäarkkitehtuuri Järjestelmävaatimukset Järjestelmämallit Järjestelmän elinkaari Liitteet Ohtu-projektien Vaatimusmäärittelyohje [Pro06] Oops [Hei05] Ostrobotnia [Blo05]

11 Mistä vaatimukset tulivat? 1/3 - Ostrobotnia [Blo05]
Käyttäjävaatimukset Järjestelmävaatimukset Asiakas Käyttötapaukset Projektiryhmä Järjestelmäarkkitehtuuri Käyttöliittymäprototyyppi

12 Mistä vaatimukset tulivat? 2/3 - Oops [Hei05]
Käyttäjävaatimukset Järjestelmävaatimukset Asiakas Tehtävänanto Haastattelut Käyttötapaukset Projektiryhmä Järjestelmäarkkitehtuuri Tavoitepohjaiset käyttötapaukset Prioriteettirajaus Käyttöliittymäprototyyppi Kokoarvio ?

13 Mistä vaatimukset tulivat? 3/3
Ostrobotnia Oops

14 Mitkä vaatimukset kiinnittävät käyttöliittymäratkaisuja ja mitkä eivät
“In principle, requirements should state what the system should do and the design should describe how it does this.” -Sommerville Käyttöliittymäratkaisun voi kiinnittää kahdella tasolla Vaatimus kiinnittää toiminnon, mutta ei sen toteutusta Vaatimus kiinnittää toiminnon yksityiskohtaisesti Osa vaatimuksista ei kiinnitä käyttöliittymäratkaisuja lainkaan Käyttötapaus Käyttäjä haluaa perua tekemänsä muutoksen Kuvaus Käyttäjä painaa UNDO-painiketta. Käyttötapaus, joka kiinnittää käyttöliittymäratkaisun yksityiskohtaisesti [Hei05]. Toiminnallinen järjestelmävaatimus, joka kiinnittää toiminnon, mutta ei sen toteutusta [Hei05]. Ympäristövaatimus, joka ei kiinnitä käyttöliittymäratkaisuja [Blo05].

15 Mitkä vaatimukset kiinnittävät käyttöliittymäratkaisuja ja mitkä eivät
Vain toiminnon kiinnittävät vaatimukset ovat pääasiallisesti toiminnallisia käyttäjävaatimuksia tai järjestelmävaatimuksia saattavat luoda turhia toimintoja, joita ei oikeasti tarvittaisi, jos käyttöliittymä suunniteltaisiin ensin jollain systemaattisella menetelmällä Toiminnallinen käyttäjävaatimus, joka kiinnittää toiminnon, mutta ei sen toteutusta [Blo05].

16 Mitkä vaatimukset kiinnittävät käyttöliittymäratkaisuja ja mitkä eivät
Vaatimukset, jotka kiinnittävät käyttöliittymäratkaisun yksityiskohtaisesti ovat pääasiassa toiminnallisia järjestelmävaatimuksia (myös joitain ei-toiminnallisia) käyttötapauksia skenaarioita Ei-toiminnallinen järjestelmävaatimus, joka kiinnittää käyttöliittymäratkaisun yksityiskohtaisesti [Blo05]. Toiminnallinen järjestelmävaatimus, joka kiinnittää käyttöliittymäratkaisun yksityiskohtaisesti [Hei05]. Käyttötapaus tilan poistamisesta [Blo05].

17 Mitkä vaatimukset kiinnittävät käyttöliittymäratkaisuja ja mitkä eivät
Vaatimukset, jotka eivät kiinnitä käyttöliittymäratkaisuja ovat pääasiallisesti ympäristövaatimuksia suurin osa ei-toiminnallisista vaatimuksista Ympäristövaatimus, joka ei kiinnitä käyttöliittymäratkaisuja [Hei05]. Ei-toiminnallinen järjestelmävaatimus, joka ei kiinnitä käyttöliittymäratkaisuja [Blo05].

18 Käyttöliittymäratkaisusta näkyvät vaatimukset
Toimintoa kuvaavat vaatimukset näkyvät käyttöliittymästä Esim. undo-toiminto undo-painike Osa ei-toiminnallisista vaatimuksista (ei kiinnitä toimintoja) Ei ympäristövaatimukset Kaikkiaan selvästi suurin osa vaatimusdokumentin vaatimuksista Ei-toiminnallinen järjestelmävaatimus, joka näkyisi systemaattisesti suunnitellusta käyttöliittymästä, mutta ei kiinnitä toimintoja [Hei05]. Ei-toiminnallinen järjestelmävaatimus, joka näkyisi systemaattisesti suunnitellusta käyttöliittymästä, mutta ei kiinnitä toimintoja [Hei05].

19 Vaatimusten ominaisuuksista 1/3
Vaatimusten ominaisuuksia, joihin liittyy ongelmia, jotka voisivat helpottua systemaattisen käyttöliittymäsuunnittelun avulla Virheettömyys Ristiriidattomuus Täydellisyys Tarpeellisuus Todennettavuus

20 Vaatimusten ominaisuuksista 2/3
Virheettömyys Virhe vaatimuksissa heijastuu koko ohjelmistotuotantoprosessiin Virheet helpompi huomata käyttöliittymän kuvasarjasta tai prototyypistä kuin tekstistä Ristiriidattomuus Riski kasvaa, jos useampi henkilö kokoaa vaatimuksia ja tekee vaatimusmäärittelyn eri osioita Voidaan vähentää huolellisella vaatimusten analysoinnilla Käyttöliittymästä on helpompi saada ristiriidaton ja siitä on helppo poimia vaatimuksia

21 Vaatimusten ominaisuuksista 3/3
Täydellisyys Liika tarkkuus heikentää dokumentin luettavuutta Luonnollinen kieli tuottaa ongelmia, jotka johtavat joskus vaatimusten muuttumiseen Asiakas saattaa muuttaa mieltään Käyttöliittymästä näkee, miten vaatimukset on tulkittu ja miten ne tullaan toteuttamaan Tarpeellisuus Tarpeellisuuden selvittäminen hankalaa Asiakas ei ehkä osaa priorisoida Esim. GDD auttaa näissä tilanteissa Todennettavuus Jokaisen vaatimuksen on löydyttävä ohjelmistosta ja jokaisen ominaisuuden on oltava tunnistettava vaatimus GDD auttaa

22 Pohdintaa 1/3 Onko käyttäjävaatimuksista nykyisessä muodossa mitään hyötyä? Ovat liian yleisellä tasolla, jotta niillä voitaisiin tehdä suunnittelua tmv. Vastaavat asiat voitaisiin nähdä käyttöliittymästä Nykyisellä menetelmällä niitä näytettäisiin käyttävän vain järjestelmävaatimusten syötteinä, mihin käyttöliittymä kävisi myös hyvin Käyttäjävaatimusten lukijakunta eroaa järjestelmävaatimusten lukijoista siinä, että siihen kuluu ei-teknisiä henkilöitä helpompi katsoa vaatimuksia käyttöliittymästä, helpottaa asiakkaan kanssa kommunikointia System end-users Client engineers System architects Client managers Contractor managers Software developers User requirements System requirements Vaatimusten lukijakunnat [Som04]

23 Pohdintaa 2/3 Kuinka paljon vaatimusmäärittelyihin eksyy vaatimuksia, joita ei oikeasti tarvita? Miksi? Ovatko ne lähtöisin asiakkaasta? Kuka vain tarkastelee peruttuja varauksia? Generoidaanko käyttötapauksilla turhia toimintoja, jotta saadaan kaikki halutut (asiakkaan haluamat?) vaatimukset mukaan? -Käyttötapaus [Blo05]

24 Pohdintaa 3/3 Kuinka paljon nykyisestä vaatimusmäärittelydokumentista voitaisiin korvata käyttöliittymäsuunnittelulla? Ainakin Käyttäjävaatimukset Käyttötapaukset (use cases) Joitain kaavioita, esim. käyttötapauskaavio Kuinka paljon tarvitaan lisäksi sanallista selvitystä? Tarkemmat tekniset yksityiskohdat Vaatimukset, jotka eivät näy käyttöliittymästä Onko sellaisia vaatimuksia, jotka nyt eivät vaikuta näkyvän käyttöliittymästä, mutta voisivat näkyä? XP?

25 Johtopäätökset 1/2 Systemaattisesta käyttöliittymäsuunnittelusta vaatimusmäärittelyprosessin alussa olisi hyötyä vaatimusten kartoitukseen ja kirjaamiseen Vaatimuksia löytyy paremmin haastatteluilla ja tarkkailuilla kuin asiakkaalta kysymällä Asiakkaan on vaikea kuvailla vaatimuksia sanallisesti, mistä aiheutuu epäselvyyksiä On vaikeaa löytää oikeanlaisia kysymyksiä, joilla saisi tarvittuja vastauksia Asiakas ei aina tiedä, mitä haluaa tai ei ehdi tai osaa ottaa siitä selvää

26 Johtopäätökset 2/2 Käyttöliittymäkuvat ja –kuvasarjat ovat yksiselitteisempiä ja helpompia ymmärtää kuin luonnollinen kieli ja kaaviot (vaativat jonkinlaista asiantuntemusta) helpompi kommunikoida asiakkaan kanssa Käyttöliittymäsuunnittelu alussa voisi helpottaa vaikeana pidettyä vaatimusmäärittelyvaihetta

27 Kysymyksiä?

28 Lähteet [Blo05] Blomqvist K. et al., Vaatimusdokumentti, Potta, Ohjelmistotuotantoprojekti, Helsingin yliopisto, Helsinki, Suomi, [Hei05] Heikkinen I. et al., Vaatimusdokumentti, Kaapo – kaavioiden piirto-ohjelma, Ohjelmistotuotantoprojekti, Helsingin yliopisto, Helsinki, Suomi, [Myös ] [Pro06] Ohjelmistotuotantokurssin projektiohje, ( ), Vaatimusdokumentti [Som01] Sommeville I., Software Engineering, Sixth Edition, Addison Wesley, Harlow, UK, 2001. [Som04] Sommeville I., Software Engineering, International Computer Science Series, Seventh Edition, Pearson Education Limited, 2004. [Tai05] Taina J., Vaatimusmäärittely – luentokalvot, Ohjelmistotuotanto-kurssi, kevät 2005.