T-121.300

KÄYTTÖLIITTYMÄSUUNNITTELU

Luento 2. Vaatimusmäärittelyt käyttöliittymäsuunnittelussa

Marko NieminenTeknillinen korkeakoulu

Käyttöliittymät ja käytettävyys

Marko.Nieminen@hut.fi

Marko Nieminen

Vaatimusmäärittelyt käyttöliittymän suunnittelussa

Luennon sisältö:

Vaatimusmäärittelyt yleisesti/perinteisesti

Käyttäjäkeskeisen suunnittelun erityispainotukset vaatimusmäärittelyille

Marko Nieminen

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

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

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

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

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

Analysoija on - asiakkaan näkökulmasta konsultti ja “tiedustelija”- kehittäjien näkökulmasta määrittelijä ja “korkean tason” suunnittelija

Marko Nieminen

Vaatimusmäärittelyn deliveraabeli

Vaatimusmäärittelydokumentti validointikriteereineen

Mutta myös: Prototyypit Alustava käyttöohje

Marko Nieminen

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)

04/21/23 Marko Nieminen

Vaatimusmäärittelyissä kuvattavat asiat(ISO 9241)

Käyttäjä

Tehtävä

Laitteet javälineet

Ympäristö

Tavoitteet

Tuottavuus/vaikuttavuus

Tehokkuus

TyytyväisyysKäyttö-

konteksti

Tuote Käytettävyydenmittarit

Vuoro-vaikutuksen

tulos

Aiotutlopputulokset

Käytettävyys

Vaatimusmäärittely:

JOHDANTO

(tavoitteet)

Vaatimusmäärittely:

JOHDANTO

(tavoitteet)

Vaatimusmäärittely:

VALIDOINTIKRITEERIT

Vaatimusmäärittely:

VALIDOINTIKRITEERIT

Vaatimusmäärittely:

JOHDANTO

(toiminta-liiketoiminta)

Tämän kuvaaminentuottaa puitteetvaatimusmääritte-lyn muiden osientuottamiselle.

Vaatimusmäärittely:

JOHDANTO

(toiminta-liiketoiminta)

Tämän kuvaaminentuottaa puitteetvaatimusmääritte-lyn muiden osientuottamiselle.

04/21/23 Marko Nieminen

Käyttäjäkeskeiset toimenpiteet vaatimusten määrityksessä

V1 V2 V3 V4 V5

TyylioppaatTarkistuslistat

Heuristiset säännötKognitiivinen läpikäynti

Pienimuotoiset käytettävyystestitKäytettävyystavoitteiden tarkastelu

KäytettävyystestitTulosten vertailu

käytettävyystavoitteisiin

Katselmoinnit

Vaatimus-määrittely

Suunnittelu jaToteutus

Testaus Seuranta

Asiakaspalautetuotekehittäjille asti!

Käyttäjätietouden keruu

Tuotehallinta

Käyttäjien tunnistaminen ja ryhmittelyKäyttäjäluonnehdinnatTehtäväanalyysitYmpäristö- ja tilanneanalyysitKäytettävyystavoitteiden luonti

Käyttäjien tunnistaminen ja ryhmittelyKäyttäjäluonnehdinnatTehtäväanalyysitYmpäristö- ja tilanneanalyysitKäytettävyystavoitteiden luonti

Käyttäjien tunnistaminen ja ryhmittelyKäyttäjäluonnehdinnatTehtäväanalyysitYmpäristö- ja tilanneanalyysitKäytettävyystavoitteiden luonti

04/21/23 Marko Nieminen

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!

Marko Nieminen

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

Harjoitustehtävä

Hahmottele vierustoverisi kanssa skenaario opiskelijasta, joka haluaa varata kirjan korkeakoulun kirjastosta internet-palvelun kautta

Marko Nieminen

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.

04/21/23 Marko Nieminen

User Characterisation(Booth 1989)

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

04/21/23 Marko Nieminen

Task Analysis(Booth 1989)

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

04/21/23 Marko Nieminen

Situational Analysis(see Booth 1989)

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

04/21/23 Marko Nieminen

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?

04/21/23 Marko Nieminen

Käytettävyystavoitteet(ks. Whiteside & al 1988)

Käytettävyys-tekijä

Mittauskohde MittayksikköHuonoin

tasoSuunniteltu

tasoParastaso

Tilannenyt

Ensivaikutelmajärjestelmästä

vastaajienmäärä

50 %neg.

90 %pos.

100%pos.

Opittavuus Koulutus aika 1 pv+ kouluttaja

1 h+ kouluttaja

1 h(ei koul.)

MuistettavuusKäyttöliittymänpainikkeiden muistaminen

hlö-määrä

70 %muistaa

4 / 7

90 %muistaa

6 / 7

100 %muistaa

7 / 7

VirheetTehtävä: tarkistahenkilön tiedot

Virheidenmäärä 4 0 0

Tehokkuus

Tehtävä: vastaapuhelintiedusteluun, jossa

pyydetään henkilön puhelinnumeroa

tiedon hakuunkulunut aika 30 sek 7 sek 3 sek

Tyytyväisyys

Marko Nieminen

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

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

mutta...

Marko Nieminen

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