T-121.300 KÄYTTÖLIITTYMÄSUUNNITTELU Luento 2. Vaatimusmäärittelyt käyttöliittymäsuunnittelussa

1. T-121.300KÄYTTÖLIITTYMÄSUUNNITTELULuento 2. Vaatimusmäärittelyt käyttöliittymäsuunnittelussa Marko Nieminen Teknillinen korkeakoulu Käyttöliittymät ja käytettävyys Marko.Nieminen@hut.fi

2. Vaatimusmäärittelyt käyttöliittymän suunnittelussa Luennon sisältö: • Vaatimusmäärittelyt yleisesti/perinteisesti • Käyttäjäkeskeisen suunnittelun erityispainotukset vaatimusmäärittelyille Marko Nieminen

3. Mihin vaatimusmäärittelyjä tarvitaan? • Perinteisesti vaatimusmäärittelyissä (spesifikaatioissa) pyritään kuvaamaan lopputuloksena syntyvä järjestelmä sellaisella tarkkuudella, että suunnittelijat voivat toteuttaa järjestelmän. • Käyttäjät ja asiakkaat allekirjoittavat sopimuksen ja sitoutuvat siten tehtyyn suunnitelmaan. Onko ongelmia? • Hankaluuksia helposti ymmärtämättömyyden ja puuttuvan osaamisen vuoksi • Vaihtoehtoja massiivisille vaatimusmäärittelydokumenteille: paperiprototyypit ja iteratiivinen suunnittelutapa Marko Nieminen

4. Vaatimusmäärittelyt (trad.) • Vaatimusmäärittelyt kuvaavat yksityiskohtaisesti ne tarpeet, joihin järjestelmän pitää tuottaa ratkaisu • Vaatimusten analysointi ja määrittely on alku perinteisen vesiputousmallin mukaisessa suunnitteluprosessissa • (Vaatimusten analysointi -> Määrittely -> Suunnittelu (arkkitehtuuri, yksityiskohdat) -> Toteutus -> Integrointi -> Ylläpito) • Tiukimmin tulkittuna seuraavaa vaihetta ei aloiteta ennen kuin edellinen vaihe on päättynyt; edelliseen vaiheeseen ei myöskään palata • Esimerkkejä vaatimusmäärittelyiden rakenteesta löytyy mm. IEEE:ltä (alkaen 830-1984) Marko Nieminen

5. Vaatimusmäärittelyn rakenne(Pressman 1987) • Johdanto • tavoitteet (toiminta, liiketoiminta), projektin reunaehdot • Tietomalli • yksityiskohtainen kuvaus ongelmasta, jonka järjestelmä ratkaisee • tietovirrat, tietosisällöt, tiedon rakenteet, järjestelmärajapinnat (hw, sw, hci!) • Toiminnallinen kuvaus • toiminnalliset osat, toimintojen kuvaukset (toimintaselostus, rajoitukset, suorituskykyvaatimukset, suunnittelurajoitukset, kuvaavat diagrammit) • Validointikriteerit • suorituskyvyn reunaehdot, käytettävät testit, erityishuomiot • (Viitteet, liitteet) Marko Nieminen

6. Vaatimusmäärittelyjen tuottaminen • Aikamoista kysely- ja luonnostelutyötä; asioiden hoksaamista ja pohdiskelua, kuitenkin yleensä varsin tiukoissa aikatauluraameissa Vaiheet • Ongelman tunnistaminen • Arviointi ja syntetisointi • Määrittely • Katselmointi Marko Nieminen

7. Vaatimusmäärittelyn haasteita • Kommunikointi • Ymmärtäminen • Käyttäjä/asiakaskaan ei aina tiedä mitä haluaa tai mitä vaaditaan... • Analysoijan rooli keskeinen! Ymmärrettävä sekä asiakkaan tarpeet että kehitysorganisaation näkökulmat. • Hoksattava abstrakteja käsitteitä, uudelleenjärjestettävä loogisesti, syntetisoitava uusia ratkaisuja uusien rakenteiden pohjalta • Kyettävä tunnistamaan keskeiset ja tärkeät seikat ristiriitaisista ja sekavistakin lähteistä • Kyky ymmärtää käyttäjän/asiakkaan toimintaympäristöä • Kyky sovittaa teknisiä elementtejä/ratkaisuja em. toimintaympäristöön • Kyky kommunikoida selkeästi sekä keskustellen että kirjallisesti • Kyky nähdä metsä puilta Analysoija on - asiakkaan näkökulmasta konsultti ja “tiedustelija”- kehittäjien näkökulmasta määrittelijä ja “korkean tason” suunnittelija Marko Nieminen

8. Vaatimusmäärittelyn deliveraabeli • Vaatimusmäärittelydokumentti validointikriteereineen Mutta myös: • Prototyypit • Alustava käyttöohje Marko Nieminen

9. Vaatimusmäärittelyt käyttöliittymäsuunnittelussa • Myös käyttöliittymäsuunnittelussa pitää lähteä liikkeelle vaatimusten määrittelystä • Toisaalta käyttöliittymäsuunnittelu voi olla myös iteratiivinen osa vaatimusten määrittelyä • Käyttäjälle näkyvän järjestelmän osan - käyttöliittymän - vaatimusmäärittelyjen pitää tarkastella käyttäjälle keskeisiä asioita • Taustalla todelliset, kattavat ja edustavat kuvaukset • Perinteisesti: abstraktit ja osittaiset tehtäväkuvat • Keinot, joilla määritykset tuotetaan, ratkaisevat vaatimusmääritysten laadukkuuden (prosessilähtöinen näkökulma) Marko Nieminen

10. Vaatimusmäärittelyissä kuvattavat asiat(ISO 9241) Vaatimusmäärittely: JOHDANTO (tavoitteet) Aiotut lopputulokset Käyttäjä Tavoitteet Vaatimusmäärittely: JOHDANTO (toiminta-liiketoiminta) Tämän kuvaaminentuottaa puitteetvaatimusmääritte-lyn muiden osientuottamiselle. Tehtävä Käytettävyys Laitteet ja välineet Tuottavuus/ vaikuttavuus Ympäristö Tehokkuus Vaatimusmäärittely: VALIDOINTIKRITEERIT Vuoro- vaikutuksen tulos Käyttö- konteksti Tyytyväisyys Tuote Käytettävyyden mittarit

11. Käyttäjäkeskeiset toimenpiteet vaatimusten määrityksessä Vaatimus- määrittely Testaus Seuranta Suunnittelu ja Toteutus Käyttäjien tunnistaminen ja ryhmittely Käyttäjäluonnehdinnat Tehtäväanalyysit Ympäristö- ja tilanneanalyysit Käytettävyystavoitteiden luonti V1 V2 V3 V4 V5 Käyttäjien tunnistaminen ja ryhmittely Käyttäjäluonnehdinnat Tehtäväanalyysit Ympäristö- ja tilanneanalyysit Käytettävyystavoitteiden luonti Tyylioppaat Tarkistuslistat Heuristiset säännöt Kognitiivinen läpikäynti Pienimuotoiset käytettävyystestit Käytettävyystavoitteiden tarkastelu Käytettävyystestit Tulosten vertailu käytettävyystavoitteisiin Asiakaspalaute tuotekehittäjille asti! Käyttäjätietouden keruu Tuotehallinta Katselmoinnit

12. Tunnista käyttäjä! Jos tuotteesi edes yrittää olla myyntikelpoinen, joku käyttää sitä! • Kuka käyttää tuotetta? • Millainen henkilö hän on? • Miksi hän käyttää tuotetta? Mitä käytöllä tavoitellaan? • Missä tilanteessa tuotetta käytetään? • Miten tuotetta yritetään käyttää? Tunnista, valitse ja kuvaa tuotteen käyttäjät!

13. Tehtäväkuvaus • Konkreettinen, yksityiskohtainen esimerkki tehtävästä, jonka käyttäjä suorittaa • kertoo, mitä käyttäjä haluaa tehdä, muttei sitä, miten käyttäjä tekee asian • on hyvin yksityiskohtainen, kertoo esimerkissä asiat todellisilla käsitteillä -- ei yleistyksiä • kuvaa kokonaisen työtehtävän • tehtäväkuvaukset osoittavat, ketkä työtä tekevät • laajennettavissa skenaarioksi (mm. storyboard), joka kertoo, miten käyttäjä suorittaa tietyt toimenpiteet tietyn järjestelmän avulla Marko Nieminen

14. Harjoitustehtävä • Hahmottele vierustoverisi kanssa skenaario opiskelijasta, joka haluaa varata kirjan korkeakoulun kirjastosta internet-palvelun kautta Marko Nieminen

15. Kuvausten taustalla todelliset havainnot! • Tärkeää on perustaa käyttäjäkuvaukset todellisuuteen • Havainnointikeinona esim etnografinen havainnointi tai sen johdannaiset; “Contextual Inquiry”; myös osallistuvan suunnittelun keinoin voidaan saada selville kuvausten vaatimia faktoja. Marko Nieminen

16. USER DATA Identify the target user group Proportion of males and females Average age / age range Cultural characteristics (language etc.) JOB CHARACTERISTICS Job role description Main activities Main responsibilities Reporting structure Reward structure Schedules Status / quality Turnover rate USER BACKGROUND Relevant education / knowledge / experience Relevant skills Relevant training USAGE CONSTRAINTS Voluntary vs. mandatory use Motivators vs. de-motivators PERSONAL PREFERENCES AND TRAITS Learning style Interactional style Aesthetic preference Personality traits Physical traits User Characterisation(Booth 1989)

17. GOALS Identify goals and list important supporting tasks For each important task: TASK INTRINSICS Task identifier Inputs and outputs Transformational process Operational procedures & patterns Planning, decision points, problem solving Terminology Equipment TASK DEPENDENCY AND CRITICALITY Dependency on other tasks & systems Concurrent effects Criticality of tasks (linked to dependency) CURRENT USER PROBLEMS PERFORMANCE CRITERIA Speed, Accuracy, Quality TASK CRITERIA Sequence, frequency & importance of actions Functional relationships between actions Availability of functions Flexibility of operation USER DISCRETION Can the user control or determine pace, priority & procedure? TASK DEMANDS Physical, Perceptual, Cognitive, Environmental Health and safety requirements Task Analysis(Booth 1989)

18. EQUIPMENT (what equipment) does not meet performance criteria does not meet specification fails SURROUNDINGS Physical environment Social environment Changes in surroundings POLICY Changing laws, rules, standards, guidelines AVAILABILITY missing data missing materials missing personnel missing support OVERLOADS too many people/machines using resource too much data, information, materials, etc. INTERRUPTIONS process breakdown things missed/forgotten restart required Situational Analysis(see Booth 1989)

19. Kysymyksiä... • Missä tuotetta käytetään? • Kuka on käyttäjä tai käyttäjäorganisaatio? Missä ympäristössä tuotetta käytetään? • Keitä ovat tuotteen käyttäjät? • Mitkä ovat käyttäjien toimenkuvat/tehtävänimikkeet? Minkä nimisiä käyttäjät ovat? • Mitä käyttäjät haluavat tehdä tuotteella? • Mitä tavoitteita käyttäjillä on tuotetta käyttäessään? • Missä tilanteessa tuotetta käytetään? • Mitä tapahtuu tyypillisessä käyttötilanteessa? Miten tilanteet etenevät? Missä vaiheissa tehtävää tuotetta käytetään? Mitä muita osia käyttäjän tehtävään kuuluu? Mikä on tyypillisin käyttötilanne/käyttötapahtuma? • Mitä tietoja tarvitaan tuotteen käyttämiseksi? • Kokemusta? Koulutusta? Mitä tietoa EI tarvita? • Miten tuotteen pitäisi palvella käyttäjää käyttötilanteessa?

20. Käytettävyystavoitteet(ks. Whiteside & al 1988) Käytettävyys- tekijä Huonoin Suunniteltu Paras Tilanne Mittauskohde Mittayksikkö taso taso taso nyt Ensivaikutelma vastaajien 50 % 90 % 100% Tyytyväisyys järjestelmästä määrä neg. pos. pos. 1 h 1 pv 1 h Opittavuus Koulutus aika + kouluttaja + kouluttaja (ei koul.) 100 % 70 % 90 % Käyttöliittymän hlö- Muistettavuus muistaa muistaa muistaa painikkeiden määrä 7 / 7 4 / 7 6 / 7 muistaminen Tehtävä: tarkista Virheiden Virheet 4 0 0 henkilön tiedot määrä Tehtävä: vastaa puhelintiedusteluun, jossa tiedon hakuun Tehokkuus 30 sek 7 sek 3 sek pyydetään henkilön kulunut aika puhelinnumeroa

21. Oliopohjainen analyysi • Soveltuu oliopohjaisiin kehitysympäristöihin • Keskeiset käsitteet: • objektit (objects) • jaetaan kuuluviksi joko ongelma-alueeseen (problem space) tai toteutukseen (solution space) • operaatiot (operations/methods) • ominaisuudet (attributes/properties) • liittyvät sekä olioihin että operaatioihin • Vaiheet: • Kuvataan järjestelmä sopivalla tarkkuudella vapaamuotoisesti, mutta kirjallisesti • objektit=substantiivit; ominaisuudet=adjektiivit; operaatiot=verbit; operaatioiden ominaisuudet=adverbit Marko Nieminen

22. Vaatimusmäärittelyt • kertovat, mihin tarpeisiin käyttäjät (asiakkaat) haluavat järjestelmän/tuotteen vastaavan • antavat pohjan järjestelmän/tuotteen toiminnallisen kuvauksen kirjoittamiselle Marko Nieminen

23. mutta...

24. The First Law of System Engineering(Bersoff 1980) No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle Marko Nieminen

25. Marko Nieminen