sådan skriver du krav til brugervenlighed - · pdf filesådan skriver du krav til...

Sådan skriver du Krav til brugervenlighed

Med eksempler fra Rejsekort

18 januar 2013

Udarbejdet af DialogDesign ved Rolf Molich, Skovkrogen 3, 3660 Stenløse, Danmark

Sådan skriver du krav til brugervenlighed Generel vejledning

Januar 2013 Udarbejdet af DialogDesign, www.DialogDesign.dk Side 2



Indhold 1. Formålet med denne vejledning................................................................................................... 5

1.1. Baggrund .............................................................................................................................. 5 1.2. Bidragydere .......................................................................................................................... 5

2. Formålet med usability krav ........................................................................................................ 7 2.1. Udarbejdelse af en usability kravspecifikation..................................................................... 7 2.2. Anvendelse af en usability kravspecifikation ....................................................................... 8

3. Typer af usability krav............................................................................................................... 11 3.1. Andre typer af krav............................................................................................................. 11

4. Krav til udviklingsproces........................................................................................................... 15 4.1. Usability test ....................................................................................................................... 16

5. Krav til produkt.......................................................................................................................... 19 5.1. Krav til nytte....................................................................................................................... 19 5.2. Krav til effektivitet ............................................................................................................. 20 5.3. Krav til tilfredshed.............................................................................................................. 21 5.4. Gode råd ............................................................................................................................. 21 5.5. Klassiske fejl....................................................................................................................... 22

6. Krav til usability kompetence ..................................................................................................... 25 7. Yderligere information ............................................................................................................... 27 8. Eksempler ................................................................................................................................... 29

8.1. Grundlæggende model for brug af Rejsekort ..................................................................... 29 8.2. Anvendte konventioner....................................................................................................... 29

Appendiks A. Eksempler på krav til udviklingsproces.................................................................. 30 A.1. Planlægning ...................................................................................................................... 30 A.2. Analyse ............................................................................................................................. 30 A.3. Brugerkrav ........................................................................................................................ 31 A.4. Design............................................................................................................................... 31 A.5. Vurdering.......................................................................................................................... 32

Appendiks B. Eksempler på krav til produkt................................................................................. 33 B.1. Eksempler på krav til nytte ................................................................................................ 33 B.2. Eksempler på krav til effektivitet....................................................................................... 33 B.3. Eksempler på krav til tilfredshed ....................................................................................... 39

Appendiks C. Supplerende oplysninger......................................................................................... 41 C.1. Kerneopgaver..................................................................................................................... 41 C.2. Testdeltagere til usability test ............................................................................................ 41



Hvis du er ligeglad med kvalitet, så er dit arbejde trivielt

-- Gerald M. Weinberg



1. Formålet med denne vejledning Denne vejledning forklarer, hvad en præcis kravspecifikation for usability (brugervenlighed) for et it-system bør indeholde. En usability kravspecifikation er normalt en del af en kravspecifikation for et it-system. Den komplette kravspecifikation for et produkt indeholder mange andre typer krav, f.eks. funktionelle krav, proceskrav, forretningsmæssige krav, sikkerhedskrav og kvalitetskrav.

Vejledningen henvender sig til personer, som udarbejder kravspecifikationer for interaktive it-systemer. Usability kravspecifikationen kan anvendes i en vilkårlig brugercentreret udviklingsmetode.

Vejledningen består af en generel vejledning i afsnit 2-7 efterfulgt af konkrete eksempler i afsnit 8 og appendiks A og B. Eksemplerne bygger på Rejsekort. Appendiks A viser konkrete krav, som kunne sikre at usability bliver tilgodeset i udviklingsprocessen for Rejsekort. Appendiks B viser konkrete usability krav, som rejsende kunne stille til Rejsekort.

En usability kravspecifikation fastlægger krav til udviklingsprocessen og/eller krav til selve it-systemets brugergrænseflade i form af krav til nytte, effektivitet og tilfredshed for relevante brugere i en relevant sammenhæng. Tidlige diskussioner af kravene kan afsløre misforståelser og uoverensstemmelser tidligt i udviklingsforløbet, hvor problemerne er nemme at rette.

En god usability kravspecifikation yder populært sagt en vis sikkerhed mod, at kunden kommer i kløerne på en leverandør, som ikke magter usability opgaven. Opfyldelse af kravspecifikationen bør være en forudsætning for, at leverandøren får den aftalte betaling for sin leverance. Derfor skal kravspecifikationen være præcis. For hvert krav skal en neutral person, f.eks. en dommer eller en voldgiftsmand, klart kunne afgøre, om kravet er opfyldt eller ej.

En usability kravspecifikation kan naturligvis også anvendes internt i et firma til at synliggøre aftaler om usability mellem brugere og udviklingsteamet.

1.1. Baggrund Mine erfaringer fra mange års arbejde for kunder viser, at kendskabet til hvordan man opstiller præcise, målelige krav til usability (brugervenlighed) er begrænset. Mine erfaringer viser desuden, at det kræver indsigt at omsætte begrebet "usability" til præcise usability krav.

1.2. Bidragydere Jeg takker følgende personer for værdifulde kommentarer til tidligere udkast: Søren Lauesen (ITU), Anker Helms Jørgensen (ITU), Peter Carstensen (Alexandra Instituttet) og Jan Chr. Clausen (Nykredit).

Ophavsretten til dette dokument tilhører DialogDesign, www.DialogDesign.dk

Du er velkommen til at kopiere dette dokument, også i uddrag. Ved kopiering skal du angive, at teksten stammer fra dokumentet "Usability kravspecifikation", som er udarbejdet af DialogDesign.



Din kravspecifikation skal være så robust,

at du fortsat er situationens herre, hvis leverandøren mister lysten

til at samarbejde konstruktivt efter at have fået ordren

-- Rolf Molich



2. Formålet med usability krav Usability kravspecifikationen bruges som bilag til en udviklingskontrakt. Kontrakten indgås mellem to parter: en leverandør, som skal leve op til kravene, og en kunde, som ønsker en række usability krav opfyldt for at sikre, at brugere kan finde ud af at bruge it-systemet.

2.1. Udarbejdelse af en usability kravspecifikation Usability krav indgår normalt i en kravspecifikation, som også stiller krav til materiel, funktionalitet, pålidelighed, sikkerhed og meget andet.

Usability kravene udarbejdes normalt af kunden sammen med de øvrige krav. I praksis er det kundens egne usability specialister, som udarbejder kravene, eller kunden benytter sig af ekstern konsulentbistand.

Usability krav udarbejdes med henblik på bestemte målgrupper. Forskellige målgrupper kan have vidt forskellige krav til det samme system.

Leverandøren tager hensyn til kravene, når han udarbejder tilbud. Kravene forhandles ofte mellem kunde og leverandør, indtil der er nået et kompromis mellem kvalitet og pris, som begge parter finder acceptabelt.

Usability krav kan være ressourcekrævende at teste, fordi de ofte involverer et større antal typiske brugere, de såkaldte testdeltagere. F.eks. kan en test med 100 testdeltagere kræve mange ressourcer. En test med 10 testdeltagere er væsentlig billigere men øger risikoen for, at et par atypiske testdeltagere giver et ukorrekt resultat. Kunde og leverandør må på forhånd afgøre, om testen er pengene værd. En seriøs leverandør kan beregne et højt risikotillæg for at opfylde krav, som er kostbare at efterprøve, eller som leverandøren ikke er helt sikker på, at han kan opfylde.

2.1.1. Opstilling af usability krav Jeg anbefaler følgende fremgangsmåde for opstilling af konkrete usability krav:

1. Arranger en workshop med en varighed på 2-3 timer.

2. Indbyd op til 12 personer: a. Projektejeren b. Projektlederen og hans/hendes stedfortræder c. Et par repræsentative brugere d. Interessenter, dvs. repræsentanter for grupper, hvis daglige arbejde påvirkes af

det nye it-system. For Rejsekort systemet kunne det være togførere, togrevisorer, billetsælgere og supportpersonale.

e. En eller to udviklere f. En eller to usability specialister som har erfaring i opstilling af usability krav. De

officielle titelbetegnelser er "usability engineer" og "usability requirements engineer"

g. En ordstyrer, som ikke har nogen særlige interesser i projektet, dvs. hverken er interessent eller udvikler. Ordstyreren kan også være referent.

3. Start mødet med at lade en usability specialist forklare reglerne for usability krav

4. Brainstorm forslag til målgrupper.



5. Brainstorm forslag til de 10-20 vigtigste arbejdsopgaver, de såkaldte kerneopgaver. Gør dette også selv om udviklerne allerede har opstillet en liste med kerneopgaver.

6. Brainstorm usability krav til hver kerneopgave og målgruppe.

7. Prioriter kravene under hensyntagen til at det næppe er realistisk at have mere end 30-50 krav i usability delen af kravspecifikationen.

8. Efter workshoppen formulerer referenten de krav, som workshoppen nåede frem til, og udsender dem til workshopdeltagerne til kommentering.

9. Deltagerne kommenterer de nedskrevne krav.

10. Referenten reviderer kravene på grundlag af deltagernes kommentarer. Hvis der er væsentlig uenighed mellem workshopdeltagerne, træffer projektejeren en beslutning eller indkalder til et møde med henblik på at diskutere uenighederne og opnå større forståelse af problemerne.

11. Deltagerne godkender usability kravene.

2.2. Anvendelse af en usability kravspecifikation Kunden kan stille krav om en tidlig, forebyggende kontrol af, om usability kravene ser ud til at kunne opfyldes ("early proof of concept"). En tidlig kontrol er ofte knyttet til en mulighed for at opsige kontrakten.

Når leverandøren mener, at systemet er færdigt, afholdes en afleveringsforretning, hvor kunden og leverandøren i fællesskab gennemgår systemet med udgangspunkt i de aftalte krav. For hvert krav undersøges, om kravet er opfyldt, delvis opfyldt eller ikke opfyldt. På baggrund af afleveringsforretningen afgør kunden, om han vil acceptere systemet. Hvis systemet ikke lever op til de aftalte krav, skal leverandøren ændre systemet, så det lever op til kravene. Det sker normalt for leverandørens egen regning.

Hvis det efter forhandlinger og et rimeligt antal forsøg viser sig, at leverandøren ikke kan leve op til usability kravene, kan kunden opsige aftalen.



Brugere mener, at brugergrænsefladen

ER systemet. Hvis brugerne

ikke kan finde ud af det, så virker det ikke

-- Susan Dray



3. Typer af usability krav Der er følgende typer af usability krav:

Krav til udviklingsproces Krav til udviklingsprocessen beskriver krav til en række milepæle undervejs i et udviklingsforløb. Ved hver milepæl skal leverandøren vise, at udviklingsprojektet er på rette spor, gennem en delleverance, der lever op til forud aftalte krav, og som kunden kan vurdere. Se afsnit 4 og eksemplerne i appendiks A.

Krav til produkt Produktkrav beskriver præcise procedurer for hvordan kunde og leverandør afgør, om det færdige produkt lever op til usability krav, som er aftalt på forhånd. Se afsnit 5 og eksemplerne i appendiks B.

Krav til usability kompetence Kompetencekrav beskriver, hvordan en kunde kan sikre, at leverandørens medarbejdere har de usability kompetencer, som er nødvendige for at levere et brugervenligt produkt, inden han skriver under på aftalen. Se afsnit 6.

3.1. Andre typer af krav Der findes en række andre typer krav, som lejlighedsvis forveksles med usability krav. Disse typer krav er kort omtalt i de følgende afsnit.

3.1.1. Forretningsmæssige krav Forretningsmæssige krav (engelsk: "business requirements") fastlægger overordnede, forretningsmæssige mål for hele systemet. De beskriver, hvad kunden ønsker at opnå med systemet.

Eksempler på forretningsmæssige krav til Rejsekort:

Rejsekort systemet skal efter 2 år medføre 5% flere rejser. [Begrundelse: Den nemme adgang til billetter vil medføre flere spontane rejser. Kommentar: Opfyldelse af dette krav er vanskelig at måle i praksis. Antallet af rejser påvirkes af mange andre forhold, f.eks. benzinpriser og takstpolitikken.]

Rejsekort systemet skal efter 2 års drift medføre en besparelse på mindst 5% i omkostningerne til billethåndtering. [Begrundelse: Omkostningstunge billetsalgssteder kan nedlægges.]

Rejsekort skal kunne anvendes til betaling af offentlig transport med bus og tog overalt i Danmark.

Under normal drift skal Rejsekort systemet fungere uden at brugere behøver kontakte personale. Manuelt betjente salgs- eller servicesteder må ikke være nødvendige.

Forretningsmæssige krav opstilles af ledelsen hos kunden.



3.1.2. Funktionelle krav Funktionelle krav (engelsk: "functional requirements") stiller overordnede krav til hvordan systemet skal implementeres for at opfylde de forretningsmæssige krav.

Eksempler på funktionelle krav til Rejsekort:

Rejsekort systemet skal være papirløst

Rejsekortet skal fysisk ligne et betalingskort

På hver station skal rejsende kunne se saldo på deres rejsekort og prisen for nylig foretagne rejser. Desuden skal de kunne overføre penge til deres rejsekort.

På internettet skal rejsende kunne se saldo på deres rejsekort og prisen for nylig foretagne rejser. Desuden skal de kunne overføre penge til deres rejsekort.

Rejsende skal tjekke ind, når de påbegynder en rejse.

Rejsende skal tjekke ud, når de afslutter en rejse.

Rejsekort systemet skal være brugervenligt.

Det sidstnævnte krav er udmærket som funktionelt krav, men det er ikke et usability krav. Usability krav omsætter det overordnede krav om brugervenlighed til noget måleligt.

3.1.3. Brugerkrav Brugerkrav (engelsk: "user requirements") beskriver brugeres overordnede ønsker til hele systemet.

Eksempler på brugerkrav til Rejsekort:

Det må ikke koste mere at rejse med Rejsekort end at rejse med det nuværende klippekort.

Det må ikke være mere besværligt at bruge Rejsekort end at bruge de nuværende klippekort.

Det må ikke være dyrere at bruge Rejsekort end at bruge de nuværende klippekort.

Det skal være mindst lige så sikkert at bruge Rejsekort som det er at bruge de nuværende klippekort.

Rejsekort systemet skal være brugervenligt.

Krav til nytte og effektivitet konkretiserer brugerkrav til noget måleligt. Som det fremgår af eksemplerne, kan funktionelle krav og brugerkrav være delvis sammenfaldende.

Brugerkrav formuleres af usability specialister på grundlag af brugerbehov (engelsk: "user needs"). Brugerbehov afdækkes bl.a. ved hjælp af interview og spørgeskemaundersøgelser med typiske brugere af det kommende system.



Du kan kun styre det, som du kan måle

-- Tom DeMarco



4. Krav til udviklingsproces Krav til udviklingsprocessen formuleres som krav til en række milepæle undervejs i et udviklingsforløb. Ved hver milepæl skal leverandøren vise, at udviklingsprojektet er på rette spor, gennem en delleverance. Kunden har mulighed for at vurdere, om delleverancen lever op til forud aftalte usability krav.

Milepæle og delleverancer kan tage udgangspunkt i udviklingsprocessen i ISO standard 9241-210, Human-centred design for interactive systems: ISO 9241-210 aktivitet

Leverance til kunde

Opstil plan for brugercentreret design i udviklingsprojektet

1. Plan, der beskriver milepæle, dvs. leverancer, som er af betydning for det brugercentrerede design. For hver leverance beskriver planen indhold og leveringstidspunkt.

Forstå og beskriv de situationer, hvor systemet skal bruges: Brugere, arbejdsopgaver, kontekst og teknologi

2. Oversigt over målgrupper og interessenter

3. Beskrivelser af typiske brugere (personas)

4. Oversigt over vigtige arbejdsopgaver (kerneopgaver)

5. Use cases. Beskrivelser af alle arbejdsopgaver, som systemet skal kunne håndtere

6. Brugssituationer (scenarier med relevant kontekst)

Specificér brugerkrav 7. Usability kravspecifikation

Design systemet i overensstemmelse med brugerkravene

8. Kravspecifikation for usability test af prototype, herunder liste med kerneopgaver, som skal testes

9. Prototyper, der skitserer det planlagte design. Hver prototype skal være egnet til en usability test af udvalgte kerneopgaver.

10. Testrapport og videooptagelser fra usability test af prototype

11. Evt. gentagelse af ovenstående milepæl 8-10 for prototyper, som dækker andre kerneopgaver.

12. Designstandard og wireframes

13. Designspecifikation, herunder fejlmeddelelser og brugerstøtte

14. Jævnlige usability test af halvfærdige versioner af systemet under implementeringen. Hver test opbygges som trin 8-10.

15. Jævnlig kontrol af, at implementeringen nøje overholder designspecifikationen.

Vurdér designet i forhold til usability kravspecifikationen.

16. Kravspecifikation for usability test af færdigt system

17. Testrapport og videooptagelser fra usability test af færdigt system



Det er muligt at opstille præcise krav til hver af ovenstående leverancer. Præcise krav til leverance 7, 10, 14, 16 og 17 fremgår direkte eller indirekte af afsnit 4.1.

Kunden vurderer hver leverance, evt. med sagkyndig bistand. Hvis vurderingen viser, at en leverance ikke opfylder kravene, skal leverandøren fortsætte udviklingen ved at genoptage en eller flere af de foregående aktiviteter. Udviklingsprocessen er derfor iterativ, dvs. gentagen.

Brugssituationer kan være vanskelige at identificere tidligt. Derfor er det nødvendigt, at leverandøren udarbejder prototyper, som kan testes med repræsentative brugere. Testresultaterne bruges til at opstille detaljerede krav og detaljerede mål.

Kunden kan stoppe samarbejdet, hvis kunde og leverandør ikke kan blive enige om væsentlige detaljer, eller hvis leverandøren ikke kan leve op til kundens minimumskrav.

Du kan finde konkrete eksempler på krav til udviklingsproces i appendiks A.

4.1. Usability test Usability test indtager en central plads i vurderingen af et produkts usability og dermed også i en usability kravspecifikation. Derfor indeholder dette afsnit en nærmere beskrivelse af, hvad der forstås ved en "usability test".

Du kan evt. kopiere de følgende 3 afsnit helt eller delvis til din kravspecifikation.

4.1.1. Definition En usability test eller en test af brugervenlighed (i det følgende også kaldet en test) udføres af en testleverandør for en kunde på grundlag af en kravspecifikation for usability test. En test består af en række testseancer. I hver testseance løser en testdeltager, som tilhører en forud aftalt målgruppe, en række testopgaver med et produkt under overvågning af en testleder. Forløbet af en testseance er beskrevet i en drejebog. Efter testen udarbejder testlederen en testrapport, som bruges til at kommunikere testresultaterne til kunden.

De anvendte udtryk i ovenstående definition er forklaret bl.a. i Regler for standardtest af brugervenlighed, som er nærmere beskrevet i næste afsnit.

4.1.2. Regler for standardtest af brugervenlighed Usability test, som er foreskrevet i denne kravspecifikation, arrangeres og betales normalt af kunden. De skal udføres i overensstemmelse med Regler for standardtest af brugervenlighed version 09, dateret 2003-08-12. Reglerne findes på webstedet for Foreningen for interaktionsdesign i Danmark, SIGCHI.dk http://www.sigchi.dk/sigchi/ressourcer/index.html

Usability testen skal udføres af en kompetent leverandør af usability test, som er uafhængig af kunde og leverandør. Usability testene skal videooptages. De ubearbejdede videooptagelser skal udleveres til kunden og leverandøren sammen med testrapporten.

4.1.3. Opfølgning på resultater fra usability test En usability test resulterer i en række usability testresultater. Principielt skal leverandøren rette alle påpegede usability problemer. Populært sagt: Det skal laves om til det virker. I praksis bør kunde og leverandør forhandle om usability problemer, hvor leverandøren



kan påvise, at omkostningerne ved at rette et problem ikke står i et rimeligt forhold til problemets betydning.

Hvis testleverandøren klassificerer et eller flere usability problemer som "kritisk problem", jf. Regler for standardtest af brugervenlighed (se afsnit 4.1.2), skal leverandøren rette problemerne og derefter afholde en ny usability test uden omkostninger for kunden med henblik på at vise, at de kritiske problemer er løst.



Hvis dit system tvinger mennesker i stedet for at hjælpe dem,

duer du ikke som datamatiker -- Chr. Andersen



5. Krav til produkt Produktkrav stiller konkrete usability krav til det færdige produkt. De kan opdeles i tre typer usability krav:

Nytte Kan systemet løse de opgaver, som brugere ønsker løst?

Effektivitet Kan brugere løse relevante opgaver inden for en rimelig tid?

Tilfredshed Synes brugere at systemet er behageligt at bruge?

Disse typer krav stammer fra definitionen af usability i ISO 9241-11 standarden. ISO 9241-11s definition siger, at usability er

The effectiveness, efficiency and satisfaction with which specified users achieve specified goals in particular environments.

Effectiveness: the accuracy and completeness with which specified users can achieve specified goals in particular environments

Efficiency: the resources expended in relation to the accuracy and completeness of goals achieved

Satisfaction: the comfort and acceptability of the work system to its users and other people affected by its use

ISO 9241-11 standarden er udgivet af International Organization for Standardization, www.ISO.ch. Den er temmelig dyr, og indeholder ikke andre informationer, som er nødvendige for at skrive gode usability kravspecifikationer.

Du kan finde konkrete eksempler på krav til produkt i appendiks B.

5.1. Krav til nytte Krav til nytte fastlægger, hvad systemet skal kunne.

Eksempel på krav til nytte:

Rejsekort skal kunne anvendes til betaling af offentlig transport med bus og tog overalt i Danmark.

Kunden – repræsenteret ved ledelsen eller projektejeren – opstiller krav til nytte i samarbejde med brugere og andre interessenter.

Nytte måles ved at undersøge, om systemet kan udføre de krævede arbejdsopgaver, som er af direkte relevans for brugere.

Krav til nytte angiver ikke, hvem der skal være i stand til at udføre en arbejdsopgave, hvor lang tid det må tage, eller hvor behageligt det skal være. Sådanne krav hører under effektivitet, som er beskrevet i næste afsnit. Sat på spidsen kan krav til nytte altså være opfyldt, selv om f.eks. kun den udvikler, der har lavet systemet, kan finde ud af at udføre en arbejdsopgave.



5.2. Krav til effektivitet Krav til effektivitet fastlægger, hvor hurtigt brugere skal kunne løse opgaver korrekt med systemet.

Eksempel på et krav til effektivitet:

Udvælg tilfældigt 40 testdeltagere, som er over 18 år, jævnligt rejser med S-tog og ikke har et rejsekort. Bed hver af disse testdeltagere om at bestille et rejsekort på internettet, som passer til deres behov. 95% af testdeltagerne skal kunne løse opgaven på mindre end 10 minutter.

Krav til effektivitet følger ofte denne skabelon:

Udvælg tilfældigt <antal> testdeltagere, som opfylder følgende forudsætninger <beskrivelse af testdeltagernes forudsætninger>. Bed hver af disse testdeltagere om at <beskrivelse af opgave>. <Procentsats> af testdeltagerne skal kunne løse opgaven på mindre end <tid>.

Testdeltagernes forudsætninger, som indgår i skabelonen, bør opdeles i

Generelle forudsætninger, f.eks. alder, uddannelse, interesse for teknologi og viden om it.

Specifikke forudsætninger med hensyn til det system, som skal vurderes. I det konkrete eksempel drejer det sig om viden om Rejsekort og praktisk erfaring med Rejsekorts komponenter.

Den opgave, som indgår i skabelonen, skal være relevant for et væsentligt antal brugere. Opgaven skal være præcist beskrevet uden morsomheder.

Den procentsats og tid, som indgår i et krav, skal være acceptabel både for kunde og leverandør. Der vil ofte være en sammenhæng mellem procentsats, tid til at løse opgaven og pris for systemet.

Procentsats og tid fastlægges gennem interview og observationer af typiske brugere, der udfører sammenlignelige opgaver på tidligere versioner, konkurrerende produkter eller manuelt. Kravene fastlægges ofte af projektledelse og marketing. Kravene skal som minimum være så ambitiøse, at de sikrer, at produktet er betydeligt bedre end de eksisterende muligheder.

En opgaveløsning tæller som en succes, hvis testdeltageren løser opgaven inden for det angivne tidsrum uden nogen form for menneskelig hjælp. Testdeltageren må gerne få hjælp fra systemet, f.eks. ved at benytte hjælpesystemet eller evt. dokumentation. Hvis testdeltageren giver op eller overskrider tidsgrænsen eller når frem til en løsning, som ikke er tilfredsstillende, er opgaveløsningen fejlet.

I nogle tilfælde kan det være relevant med følgende tilføjelse til ovenstående skabelon: De resterende testdeltagere skal kunne løse opgaven på <tid 2>. Her vil tid 2 typisk være 2-5 gange tid.



5.3. Krav til tilfredshed Tilfredshed måles typisk med et spørgeskema, hvor typiske brugere angiver, hvor enige eller uenige de er i en række påstande, f.eks. Rejsekort er nemt at bruge.

Krav til tilfredshed følger som oftest denne skabelon:

Udvælg tilfældigt <antal> testdeltagere, som opfylder følgende forudsætninger <beskrivelse af deltagernes forudsætninger>. Bed hver af disse deltagere om at udfylde et spørgeskema med følgende påstande <liste med 5-15 påstande om systemet>. For hver påstand skal deltageren angive, hvor enig han er i påstanden på en skala fra 1 til 5: 1 - meget uenig, 2 - uenig, 3 - neutral, 4 - enig, 5 - meget enig Deltageren skal desuden have mulighed for at angive "ved ikke" eller "ønsker ikke at svare". Den gennemsnitlige vurdering af hver påstand skal være mindst <målværdi>.

Målværdien for en positivt formuleret påstand skal typisk ligge lidt over middel, dvs. 3,5 til 4, da erfaringen viser, at brugere ofte har en positiv grundholdning til et produkt.

Der findes standardiserede spørgeskemaer til måling af tilfredshed, f.eks. SUS og SUMI. Se henvisningerne i afsnit 7.

Du kan finde yderligere konkrete eksempler på påstande i afsnit B.3.

5.4. Gode råd 1. Begræns dig

Usability kravene bør fylde 5-8 sider. Den samlede kravspecifikation er meget længere, fordi den indeholder krav til mange andre områder. Usability kravene til Rejsekort i appendiks B er bevidst begrænset til 7 sider, selv om der kunne opstilles flere krav.

2. Nummerér alle krav entydigt Nummereringen gør det nemmere at henvise til et bestemt krav. Eksemplet i appendiks B viser hvordan det kan gøres.

3. Medtag det rigtige svar på en testopgave i kravspecifikationen Testdeltagerne må naturligvis ikke se svaret.

4. Vedligeholdelse Kravspecifikationen bør indeholde oplysninger som letter vedligeholdelse og forbedring af kravene. Disse oplysninger omfatter

Kravspecifikationen bør have et versionsnummer, dato for aktuel udgave og navn på ansvarlig for aktuel udgave. Angiv gerne hvem læseren kan kontakte hvis der er tvivlsspørgsmål eller fejl.

Ændringsoplysninger: Dato for ændring, beskrivelse af ændring, navn på ansvarlig for ændring, navn på person som har godkendt ændring.



5.5. Klassiske fejl

5.5.1. Uvæsentlige krav Krav skal handle om mål, som er væsentlige for brugere.

Undgå krav som ikke sikrer usability. Undgå også unødvendigt detaljerede designforskrifter, fordi de kan forhindre designeren i at lave en innovativ og brugervenlig løsning som den der stiller kravene, ikke har tænkt på.

Eksempler på uvæsentlige krav:

Bed 30 testdeltagere om at indsætte 100 kr. på deres rejsekort ved hjælp af rejsekortautomaten. Mindst 90% af testdeltagerne skal foretage deres første handling på automaten inden for 8 sekunder fra de kommer hen til automaten. [Det er ligegyldigt hvor lang tid det tager brugere at komme i gang. Afgørende for effektivitet er, hvor lang tid det tager brugere at nå et korrekt resultat. Hvis en bruger løser en opgave hurtigere end designeren havde forestillet sig, men synes, at det tager for lang tid, vil det afspejle sig i måling af tilfredshed.]

Bed 30 testdeltagere om at indsætte 100 kr. på deres rejsekort ved hjælp af rejsekortautomaten. Mindst 90% af testdeltagerne må højst gå i stå én gang under brugen af rejsekortautomaten. [Afgørende for effektivitet er udelukkende den tid det tager at løse opgaven korrekt. Det er i denne sammenhæng ligegyldigt om en bruger går i stå f.eks. 10 gange, bare han løser opgaven hurtigt og korrekt. I øvrigt mangler kravet en beskrivelse af hvad det præcis vil sige at "gå i stå".]

Rejsekortautomaten skal have en rød "Annuller" knap [Dette krav sikrer ikke, at brugere kan anvende Annuller knappen hensigtsmæssigt.]

Det skal tage højst 30 sekunder at læse brugsvejledningen igennem [Dette krav er værdiløst, for enhver tekst, som kan læses på under 25 sekunder, opfylder kravet. Kravet sikrer, at brugsvejledningen er kort, men hverken at den er nem at få øje på, relevant eller forståelig.]

Der skal være en Hjælp knap på hver side på webstedet. [Dette krav sikrer ikke, at brugere kan få øje på hjælp knappen, og det sikrer ikke, at hjælpen er relevant og forståelig.]

5.5.2. Upræcise krav Hvert krav skal indeholde en præcis måleforskrift, som ikke kan give anledning til rimelig diskussion om hvordan man objektivt afgør, om kravet er opfyldt.

Eksempler på upræcise krav:

Systemet skal være grafikbaseret, intuitivt og brugervenligt [Dette krav og de to efterfølgende krav er generelle hensigtserklæringer, ikke præcise, målelige krav. Det hjælper ikke at skrive "Systemet SKAL være brugervenligt!".]

Alle skal kunne bruge systemet

Alle brugergrænsefladeelementer, f.eks. menuer, skal være nemme at forstå

Standeren skal give information ved nedbrud [Tilsvarende, præcise krav findes i B.2.2.5.g og B.2.2.6.g.]

Forskellen mellem standerens lyd for ”Tjek ind OK” og ”Tjek ind afvist” skal være tydelig [Tilsvarende, præcise krav findes i B.2.2.5.e og B.2.2.6.e.]



Det skal være muligt at få hjælp til betjening af automaten [Dette kan være et gyldigt krav til nytte. Det er uegnet som effektivitetsmål for hjælp. Kvaliteten af hjælp kan kun måles indirekte. Vi kan måle, om testdeltagere kan overholde de aftalte tidsfrister for arbejdsopgaver, fordi de får effektiv hjælp i situationer, hvor de ikke umiddelbart kan løse arbejdsopgaven.]

5.5.3. Urealistiske krav Krav skal være realistiske, dvs. hverken for stramme eller for løse.

Eksempler på urealistiske krav:

Bed 30 testdeltagere, som ikke tidligere har anvendt rejsekortautomaten, om at indsætte 100 kr. på deres rejsekort ved hjælp af rejsekortautomaten. Mindst 90% af testdeltagerne må højst være 30 sekunder om at indsætte pengene. [Dette krav er for stramt. 3 minutter er her et mere realistisk krav end 30 sekunder.]

Bed 30 testdeltagere om at tjekke ind. Mindst 90% af testdeltagerne må højst være 30 sekunder om at tjekke ind. [Dette krav er ikke tilstrækkelig stramt. Et tjek ind, som tager f.eks. 20 sekunder, er uacceptabelt langsomt. 5 sekunder er her et mere realistisk krav end 30 sekunder.]

Bed 30 testdeltagere om at indsætte 100 kr. på deres rejsekort ved hjælp af rejsekortautomaten. Ingen testdeltagere må være mere end 5 minutter om at indsætte pengene. [Undgå krav om at 100% eller alle testdeltagere skal kunne løse en bestemt opgave. Sådanne krav betyder, at blot en enkelt uheldig eller atypisk testdeltager gør, at kravet ikke er opfyldt.]

5.5.4. Forkert procentangivelse Undgå procentangivelser, som ikke harmonerer med antallet af testdeltagere.

Eksempler på forkert procentangivelse:

Bed 10 testdeltagere om at indsætte 100 kr. på deres rejsekort ved hjælp af rejsekortautomaten. Mindst 95% af testdeltagerne må højst være 3 minutter om at indsætte pengene. [Krav om, at 95% af testdeltagere skal kunne gøre noget, betyder, at målingen skal gennemføres med mindst 20 testdeltagere, fordi hver testdeltager svarer til 5 procentpoint. Med 10 testdeltagere skal kravet være enten 90% eller 100% (et krav om 100% er uheldigt af de grunde, som blev omtalt i foregående afsnit).]

5.5.5. Tvetydige påstande Undgå påstande som omtaler "mine forventninger".

Eksempel på tvetydig påstand i spørgeskema:

Systemet lever op til mine forventninger. [Meningen med denne påstand er vel noget i retning af "Systemet er godt". Men svaret afhænger af brugerens forventninger, som vi ikke kender. Hvis brugeren har høje forventninger, kan han svare "uenig", selv om han faktisk synes at systemet er ganske godt – det lever bare ikke helt op til hans høje forventninger. Hvis brugeren har lave forventninger, kan han svare "Enig", hvilket her betyder "Jeg forventede at det ville være ubrugeligt, og det viste sig at være tilfældet."]



En computer lader dig begå flere fejl hurtigere

end nogen anden opfindelse i menneskehedens historie,

måske med undtagelse af håndvåben og tequila

-- Mitch Ratcliffe



6. Krav til usability kompetence I nogle situationer er det relevant at vurdere leverandørens generelle kompetence på usability området, f.eks. inden der indgås en udviklingsaftale.

Til dette formål kan du f.eks. stille følgende 5 spørgsmål til din leverandør. Spørgsmålene henviser til et system xyz, som leverandøren tidligere har udviklet, og som leverandøren henviser til i sine referencer:

1. Forklar, hvilke forholdsregler I har taget i udviklingsprocessen for at sikre xyz systemets nytte og effektivitet. Vedlæg passende dokumentation for de brugerrettede aktiviteter, som I har udført, f.eks. interviewrapporter og rapport for ekspertreview.

2. Hvis I har udført en eller flere usability test af xyz systemet, så vedlæg jeres usability testprocedure beskrivelse som bilag til jeres tilbud.

3. Hvis I har udført en eller flere usability test af xyz systemet, så vedlæg en video af en af de nyeste testsessioner, som I har udført, som bilag til jeres tilbud. Videoen må ikke være redigeret, og den skal vise, hvad der skete fra det øjeblik, hvor testdeltageren kom ind i testlokalet, til han/hun igen forlod det. Vedlæg også den tilsvarende usability testrapport

4. Beskriv de 5 vigtigste usability forbedringer, som I har implementeret i xyz systemet i det seneste år, og jeres begrundelse for at udføre netop disse forbedringer.

5. Hvis I har en GUI standard (dialogstandard) for xyz systemet, så vedlæg den som et bilag til jeres tilbud. Beskriv også kort, hvor godt xyz systemet overholder denne standard..

Du bør vurdere leverandørernes svar og bilag i samarbejde med en usability specialist.



Brugere: Dem, der gør det muligt for os at betale din løn

-- Matthew Oliphant



7. Yderligere information Søren Lauesen har udgivet Kravskabelon SL07 - Fra behov til løsning, som er en eksemplarisk kravspecifikation på ca. 30 sider. Sørens kravspecifikation er komplet, dvs. den indeholder eksempler på samtlige krav man kan stille til et it-system og ikke kun krav til usability.

Du kan læse om usability i almindelighed i min bog Brugervenligt webdesign fra 2003. Bogen er på knap 200 sider og koster ca. 300 kr.

Det amerikanske NIST – National Institute of Standards and Technology – har i juni 2007 udgivet Common Industry Specification for Usability - Requirements. Dokumentet, som er på 61 sider, kan fås gratis på http://zing.ncsl.nist.gov/iusr/documents/CISU-R-IR7432.pdf

Måling af tilfredshed kan ske med et spørgeskema, som du selv udvikler. Du kan også anvende de nogenlunde standardiserede spørgeskemaer SUS og SUMI.

Jeff Sauro har beskrevet SUS på http://www.measuringusability.com/sus.php.

Jurek Kirakowski har beskrevet SUMI på http://sumi.ucc.ie/whatis.html. Et eksempel på et engelsk SUMI spørgeskema finder du på http://sumi.ucc.ie/uksample.pdf



Rejsekort: God idé men dårligt system

-- Brugere på Trustpilot



8. Eksempler Appendikserne indeholder konkrete eksempler på usability krav til Rejsekort for rejsende. Appendiks A indeholder krav til udviklingsprocessen, jf. afsnit 4. Appendiks B indeholder krav til produktet, jf. afsnit 5.

Rejsekort har mange målgrupper, f.eks. rejsende, togførere, togrevisorer, billetsælgere og Rejsekort support. De fleste af kravene i appendiks vedrører målgruppen rejsende. Afsnit B.2.9 viser eksempler på usability krav til Rejsekort for en anden målgruppe, togrevisorer.

Jeg har valgt Rejsekort som udgangspunkt for eksemplerne, da Rejsekort har en kompleks brugergrænseflade. Rejsekorts brugergrænseflade til rejsende omfatter primært internettet, standere til ind- og udtjekning på stationer og i busser, automater til optankning og indstilling af rejsekortet på stationerne samt support.

Kravene i appendikserne er udarbejdet efter Rejsekort er sat i drift. Normalt ville man udarbejde kravene inden kontraktindgåelse. Det er min opfattelse, at en erfaren usability specialist ville have været i stand til at udarbejde hovedparten disse krav tidligt i forløbet, f.eks. inden kontraktindgåelse.

Jeg har udarbejdet opgaverne på grundlag af min erfaring med opstilling af usability krav.

Jeg har ikke afprøvet i praksis, hvor godt Rejsekort overholder kravene, da formålet med eksemplerne udelukkende er at vise, hvordan usability krav konkret kan udformes.

Hverken Rejsekort eller Rejsekorts leverandører har medvirket ved udarbejdelsen af kravene.

8.1. Grundlæggende model for brug af Rejsekort Forudsætningen for eksemplerne er følgende model for hvordan Rejsekort fungerer:

Rejsekortet er et fysisk kort, der ligner et betalingskort. Rejsekortet indeholder bl.a. oplysninger om det beløb, som brugeren aktuelt har til sin rådighed til at rejse for.

Når en bruger påbegynder en rejse, skal han bruge sit rejsekort til at tjekke ind på en stander på afgangsstationen eller ved bussens indgangsdør. Når en bruger afslutter en rejse, skal han bruge sit rejsekort til at tjekke ud på en stander på ankomststationen eller ved bussens udgangsdør. Rejsekort systemet beregner automatisk betalingen for rejsen. Betalingen for rejsen hæves på brugerens rejsekort.

På hver station står en rejsekortautomat, som er tilsluttet Rejsekort systemet. Rejsekort-automaten kan bl.a. anvendes til at overføre penge til brugerens rejsekort. Den kan også anvendes til at meddele Rejsekort systemet, at den næste rejse er speciel, f.eks. fordi den omfatter medrejsende, cykel eller hund, som indehaveren af rejsekortet skal betale for.

Rejsekort systemet omfatter selve rejsekortet, standere til ind- og udtjekning, rejsekortautomat, websted, support, brochurer, reklamer mv.

8.2. Anvendte konventioner Kommentarer til krav er angivet som [Tekst til kommentar ...] . Kommentarerne er ikke en del af selve kravspecifikationen.

Usability kravspecifikation Eksempler på krav til brugervenlighed


Appendiks A. Eksempler på krav til udviklingsproces Dette appendiks skitserer, hvordan konkrete usability krav til en udviklingsproces kan se ud. Skitsen fastlægger processen indirekte gennem krav til milepæle, dvs. delleverancer. Leverandøren afgør selv, hvilke metoder han vil anvende til at nå frem til delleverancerne.

Skitsen er en konkretisering af afsnit 4, specielt den sort/grønne oversigt i afsnit 4.0. Eksemplet er udvikling af Rejsekort. Eksemplet er konstrueret.

Beskrivelserne af de enkelte milepæle er ikke komplette. Der mangler detaljerede indholds- og formkrav til usability leverancerne som f.eks. personas og arbejdsopgaver. Disse krav kan være ret kortfattede – cirka en A4-side pr. leverancetype. Du kan få dem hos en usability specialist.

A.1. Planlægning Opstil plan for brugercentreret design i udviklingsprojektet.

Milepæl 1. Oversigt over milepæle. Kort, præcis beskrivelse af alle usability milepæle i udviklingsprocessen med leveringsdato. Indholdet af afsnit A.1 til A.5 kan tjene som forbillede, bortset fra at der mangler leveringsdatoer.

A.2. Analyse Forstå og beskriv de situationer, hvor systemet skal bruges: Brugere, arbejdsopgaver, kontekst og teknologi.

Milepæl 2. Oversigt over samtlige målgrupper. En målgruppe er en samling personer, som har sammenfaldende interesser i forhold til systemet. For hver gruppe af brugere og interessenter skal der være en beskrivelse på 5-20 linier af gruppens hovedkarakteristika og væsentligste forventninger i forhold til systemet.

Milepæl 3. Personas. En persona er en konkret men fiktiv beskrivelse af en typisk bruger. Der skal være mindst 4 personas for hver målgruppe.

Milepæl 4. Arbejdsopgaver. Beskrivelser af samtlige arbejdsopgaver, som systemet skal kunne håndtere

Milepæl 5. Kerneopgaver. Kerneopgaverne er en liste med de 10-20 vigtigste arbejdsopgaver for passagerer i Rejsekort. Se eksemplet i afsnit C.1.

Milepæl 6. Brugsscenarie. Et brugsscenarie beskriver et fiktivt men realistisk scenarie hvor en persona udfører en eller flere kerneopgaver i en relevant sammenhæng. Der skal være mindst ét brugsscenarie for hver kerneopgave. Flere kerneopgaver kan være omfattet af samme brugsscenarie. Eksempel på brugsscenarie: Niels Andersen rejser sammen med sin kone fra Farum til Kastrup Lufthavn. Han ønsker at betale for dem begge med sit rejsekort. På Farum Station fortæller Niels Rejsekort systemet, at 2 personer



skal rejse på hans rejsekort på denne rejse. På Nørreport Station tjekker Niels ud. Derefter tjekker han ind igen på Nørreport Metrostation. På Kastrup Lufthavn metrostation tjekker han ud.

A.3. Brugerkrav Specificér brugerkrav.

Milepæl 7. Usability kravspecifikation. Se eksempel på konkrete krav til produkt i appendiks B.

A.4. Design Design systemet i overensstemmelse med brugerkravene.

Milepæl 8. Kravspecifikation for usability test af prototype 1. Usability testen skal have fokus på standere. Den skal omfatte alle opgaver i afsnit B.2.2. Testen skal gennemføres med mindst 5 testdeltagere. Kravspecifikationen skal opfylde kravene i Regler for standardtest af brugervenlighed, som er omtalt i afsnit 4.

Milepæl 9. Prototype 1. Leverandøren skal til brug for testen konstruere en realistisk udseende prototype på en stander. Standeren skal opstilles på en S-togsstation i overensstemmelse med evt. retningslinier, som er aftalt mellem kunden og leverandøren. Standeren skal understøtte de funktioner, som kræves i de valgte opgaver, evt. under anvendelse af Wizard of Oz teknikken. Leverandøren må først påbegynde usability testen, når kunden har godkendt prototypen.

Milepæl 10. Usability test af prototype 1. Udfør usability testen af prototype 1 i overensstemmelse med kravspecifikationen fra milepæl 8. Usability testen skal udføres som beskrevet i Regler for standardtest af brugervenlighed, som er omtalt i afsnit 4. Leverancen er testrapport og videooptagelser. Leverancen skal opfylde indholds- og formkrav i Regler for standardtest af brugervenlighed, som er omtalt i afsnit 4.

Hvis testen af prototypen viser, at alle testdeltagerne kan løse alle opgaverne inden for de angivne tidsfrister, så kan udviklingen fortsætte. Ved denne test erstattes krav om "mindst xx% af testdeltagerne ..." altså med "alle testdeltagerne ...".

Hvis et eller flere af kravene ikke er opfyldt, skal kunden og leverandøren diskutere passende forholdsregler. Forholdsreglerne kan være:

Udviklingen kan fortsætte på grundlag af en afhjælpningsplan, som leverandøren fremlægger.

Leverandøren skal forbedre usability af standeren og derefter gentage usability testen i milepæl 8-10.

Kravene lempes.



Milepæl 11-13: Usability test af prototype 2. Samme som milepæl 8-10, men med fokus på rejsekortautomaten. Usability testen skal omfatte alle opgaver i afsnit B.2.3.

Milepæl 14-16: Usability test af prototype 3. Samme som milepæl 8-10, men med fokus på Rejsekorts websted. Usability testen skal omfatte alle opgaver i afsnit B.2.4.

Milepæl 17. Designstandard og wireframes

Milepæl 18. Designspecifikation Detaljeret beskrivelse af systemets brugergrænseflader, herunder skærmbilleder, skærmbilledforløb for arbejdsopgaver, navigation, søgning og brugerstøtte, dvs. fejlmeddelelser og hjælp.

Milepæl 19-21: Usability test af systemet mens det udvikles. Samme som milepæl 8-10, men omfatter hele Rejsekort systemet. Mens leverandøren implementerer designet, skal der jævnligt afholdes usability test af mere og mere færdige versioner af det implementerede system. De anvendte testopgaver skal tages fra appendiks B. En usability test hver måned vil være passende. Milepæl 19-21 består altså af en række usability test cirka hver måned.

Milepæl 22. Kontrol af design. Mens leverandøren implementerer designet, skal kunden månedligt stikprøvevis kontrollere, at designet overholder den aftalte designspecifikation med evt. senere aftalte ændringer. Denne milepæl består altså af en række månedlige kontroller.

A.5. Vurdering Vurdér designet i forhold til usability kravspecifikationen.

Milepæl 23. Kravspecifikation for usability test af færdigt system. Usability testen styres af usability kravspecifikationen fra milepæl 7. Kravspecifikationen skal opfylde kravene i Regler for standardtest af brugervenlighed, som er omtalt i afsnit 4.

Milepæl 24. Usability test af færdigt system. Testrapport og videooptagelser fra usability test af det færdige system. Usability testen skal udføres som beskrevet i Regler for standardtest af brugervenlighed, som er omtalt i afsnit 4. Leverancen skal opfylde indholds- og formkrav i Regler for standardtest af brugervenlighed, som er omtalt i afsnit 4.



Appendiks B. Eksempler på krav til produkt Dette appendiks indeholder et konkret eksempel på usability krav til et produkt, Rejsekort.

Eksemplet er en konkretisering af afsnit 5.

Eksemplet omfatter et realistisk antal krav – ikke samtlige mulige krav.

B.1. Eksempler på krav til nytte Krav til nytte er omtalt i afsnit 5.1. Her er nogle eksempler på krav til nytte for Rejsekort:

1. Rejsekortet skal være et kort på størrelse med et almindeligt betalingskort.

2. Det skal være muligt at rejse sammen med andre personer, en hund eller en cykel på ét rejsekort.

3. Rejsekortindehavere skal kunne se saldo og transaktioner på deres rejsekort via internettet og rejsekortautomater på stationer.

4. Rejsekortindehavere skal kunne indsætte penge på deres rejsekort via internettet og rejsekortautomater på stationer.

5. Det skal være muligt at få hjælp til brug af Rejsekorts websted og rejsekortautomaterne.

B.2. Eksempler på krav til effektivitet Krav til effektivitet er omtalt i afsnit 5.2. De følgende afsnit indeholder eksempler på krav til effektivitet for Rejsekort:

B.2.1. Generelle oplysninger på internettet om rejse Opfyldelsen af følgende krav afgøres ved en usability test med mindst 20 testdeltagere der ikke har et rejsekort. De detaljerede krav til testdeltagerne står i afsnit C.2.

Hvert spørgsmål skal kunne besvares korrekt af mindst 90% af testdeltagerne på under 3 minutter. Testdeltagerne må gerne anvende internettet til at finde svaret.

1. Find Rejsekorts websted. [Udgangspunkt: Forsiden på Googles websted.]

2. Du skal rejse fra København H til Nørreport med S-tog. Hvordan skal du konkret bruge rejsekortet? [Forventet svar: Tjek ind på København H. Tjek ud på Nørreport.]

3. Du skal rejse fra København H til Flintholm Station med S-tog og derefter med et andet S-tog fra Flintholm Station til Nørrebro Station. Hvor skal du tjekke ind og ud? [Forventet svar: Tjek ind på København H. Tjek ind igen på Flintholm Station. Tjek ud på Nørrebro Station. Tilføjelse: Tjek ud på Flintholm Station er overflødigt men anses ikke for en fejl.]

4. Du skal rejse fra København H til Nørreport med S-tog og derefter med metro fra Nørreport til Lufthavnen. Hvor skal du tjekke ind og ud? [Forventet svar: Tjek ind på København H. Tjek ind igen ved metro på Nørreport. Tjek ud i Lufthavnen. Tilføjelse: Tjek ud på Nørreport er overflødigt men anses ikke for en fejl.] [Kravet adskiller sig fra det foregående, fordi den rejsende skifter fra S-tog til metro.]



5. Du skal rejse med tog fra København H til Roskilde og derefter med bus fra Roskilde Station til Vikingemuseet. Hvor skal du tjekke ind og ud? [Forventet svar: Tjek ind på København H. Tjek ind igen i bus på Roskilde Station. Tjek ud i bus ved Vikingemuseet. Tilføjelse: Tjek ud på Roskilde Station er overflødigt men anses ikke for en fejl.] [Kravet adskiller sig fra de foregående, fordi indtjekning til bus er anderledes end indtjekning til tog.]

6. Du skal rejse fra København H til Nørreport med S-tog og derefter med metro fra Nørreport til Lufthavnen. Hvad koster denne rejse med rejsekortet? [Forventet svar: Brug "Beregn din pris" på Rejsekorts websted. Prisen er 19 kr., 3 zoner.]

7. Du skal rejse fra København H til Århus H med et gennemgående Intercitytog. Hvor skal du tjekke ind og ud? [Forventet svar: Tjek ind på København H. Tjek ud på Århus Station.]

B.2.2. Almindelig rejse Opfyldelsen af følgende krav afgøres ved en usability test med mindst 24 testdeltagere der har et rejsekort. De detaljerede krav til testdeltagerne står i afsnit C.2.

1. Bed testdeltageren om at rejse fra Valby Station til København H med S-tog. Betaling skal ske ved brug af rejsekortet.

Procedure: Stil testdeltageren ved en p-plads, et cykelstativ eller en busholdeplads, som naturligt hører til Valby S-tog station.

a. Bed testdeltageren bevæge sig mod den korrekte perron og se efter en Rejsekort stander. Start tidsmålingen. Mindst 95% af testdeltagerne skal inden for højst 30 sekunder kunne udpege en Rejsekort stander.

b. Bed testdeltageren tjekke ind. Mindst 95% af testdeltagerne skal inden for højst 15 sekunder efter at de er nået frem til Rejsekort standeren, tjekke korrekt ind.

2. Inden testdeltageren forlader toget, stiller testlederen følgende spørgsmål:

a. Hvad koster rejsen?

b. Hvor stort et beløb har du efter denne rejse til rådighed på rejsekortet?

Mindst 75% af testdeltagerne skal vide, at disse spørgsmål kan besvares i forbindelse med udtjekning.

3. Mindst 90% af testdeltagerne skal inden for højst 30 sekunder fra de er steget ud af toget, tjekke korrekt ud på ankomststationen (København H).

4. Mindst 75% af testdeltagerne skal kunne svare korrekt på spørgsmål B.2.2.2.a og b efter udtjekning.

5. Bed herefter testdeltagerne rejse tilbage til Valby Station fra København H.

Sørg for, at alle indtjekninger mislykkes. Mindst 90% af testdeltagerne skal opfatte, at indtjekning mislykkes, og de skal forstå årsagen inden for højst 60 sekunder.

Hver testdeltager skal gennemføre denne test i én af følgende situationer:

a. Tjek ind mens det er overskyet dagslys (8 testdeltagere)

b. Tjek ind mens det er stærkt sollys (8 testdeltagere)

c. Tjek ind mens det er mørkt (8 testdeltagere)



Alle indtjekninger skal mislykkes af en af følgende årsager:

d. Utilstrækkelige betalingsmidler på rejsekortet (6 testdeltagere)

e. Forsøger at tjekke ind på en stander, der ifølge sin placering burde håndtere indtjekning, men som fejlagtigt er indstillet til udtjekning (6 testdeltagere)

f. Rejsekort spærret (6 testdeltagere)

g. Stander ude af drift (6 testdeltagere)

Alle kombinationer af lysforhold og fejlårsager skal testes 2 gange.

6. Når testdeltagerne ankommer til Valby Station skal de tjekke ud.

Sørg for at alle udtjekninger mislykkes. Mindst 90% af testdeltagerne skal opfatte, at udtjekning mislykkes, og de skal forstå årsagen inden for højst 60 sekunder.

Hver testdeltager skal gennemføre denne test i én af følgende situationer:

a. Tjek ud mens det er overskyet dagslys

b. Tjek ud mens det er stærkt sollys

c. Tjek ud mens det er mørkt

Alle udtjekninger skal mislykkes af en af følgende årsager:

d. Rejsekort ikke tjekket ind

e. Forsøger at tjekke ud på en stander, der ifølge sin placering burde håndtere udtjekning, men som fejlagtigt er indstillet til indtjekning

f. Rejsekort spærret

g. Stander ude af drift

Alle kombinationer af lysforhold og fejlårsager skal testes 2 gange.

7. Efter at have løst testopgave B.2.2.1 - B.2.2.6, skal mindst 50% af testdeltagerne kunne svare korrekt på følgende spørgsmål: "Du kommer hjem efter en rejse, hvor du har brugt rejsekortet. Da du kommer hjem, opdager du, at du har glemt at tjekke ud. Hvad kan du gøre?" [Denne opgave skal være let at løse i et brugervenligt, fejltolerant system. Det eneste, der for tiden kan gøres i Rejsekort, er at finde en stander og tjekke ud. Hvis det ikke er muligt, må man acceptere at rejsen koster 50 kr. Det er ikke muligt at tjekke ud via internettet.]

8. Lad 24 testdeltagere ankomme med samme S-tog og i samme vogn til Valby Station. Bed testdeltagerne tjekke ud og forlade stationen ad samme udgang. Alle skal være tjekket ud på mindre end 2 minutter. [I dette krav skal standerne fungere korrekt, hvilket er modsat krav B.2.2.6]

Ideelt burde opgave B.2.2.1, 3, 5, 6 og 8 udføres på samtlige 84 S-togsstationer. Omkostningerne ved at gennemføre alle disse test står imidlertid næppe i et rimeligt forhold til udbyttet. Såfremt kunden og leverandøren har opstillet retningslinier for opstilling af standere på stationerne, og disse retningslinier er overholdt, er det nærliggende at antage, at målinger gennemført på én eller nogle få repræsentative stationer afspejler standernes generelle usability.



B.2.3. Særlige rejseformer Opfyldelsen af følgende krav afgøres ved en usability test med mindst 20 testdeltagere der har et rejsekort. De detaljerede krav til testdeltagerne står i afsnit C.2.

Udgangspunktet er, at testdeltagerne står på København H på en perron ved en tjek ind stander. Det er en væsentlig del af denne test at undersøge, om testdeltagerne af sig selv finder ud af, at opgaverne kan løses på en rejsekortautomat, og derefter finder frem til en rejsekortautomat.

1. Du skal rejse til Holte med S-tog. Du skal have en stor hund med. Vis mig hvad du vil gøre for at bruge dit rejsekort til denne rejse.

Mindst 80% af testdeltagerne skal kunne løse denne opgave inden for højst 5 minutter.

2. Du skal rejse til Ballerup med S-tog. Du skal have en cykel med. Vis mig hvad du vil gøre for at bruge dit rejsekort til denne rejse.


3. Du skal rejse til Hellerup med S-tog sammen med 3 andre voksne, som ikke har rejsekort, og som du skal betale for med dit rejsekort. Vis mig hvad du vil gøre for at bruge dit rejsekort til denne rejse for jer alle 4.


4. Du skal rejse fra Svanemøllen til Nørreport med S-tog og derefter med metro fra Nørreport til Lufthavnen. Du skal rejse sammen med 3 andre voksne, som ikke har rejsekort, og som du skal betale for med dit rejsekort. Hvad skal du gøre for at bruge dit rejsekort til denne rejse for jer alle 4? [Forventet svar: Indstil ved hjælp af en rejsekortautomat på Svanemøllen Station rejsekortet til at omfatte 3 ekstra voksne. Tjek ind. Tjek ind igen ved metro på Nørreport. Tjek ud i Lufthavnen.]

5. Dit rejsekort er netop blevet stjålet af en lommetyv. Spær det.

Mindst 95% af testdeltagerne skal kunne løse denne opgave inden for højst 5 minutter på Nørreport Station. [Forventet svar: Gå til nærmeste rejsekortautomat. Aflæs nummeret som man skal kontakte for at få spærret sit rejsekort. Ring til nummeret ved hjælp af en mobiltelefon.]

6. I forbindelse med testene i dette afsnit må ingen testdeltagere forlade rejsekortautomaten uden at tage deres rejsekort med sig.

B.2.4. Administration af rejsekortet Opfyldelsen af følgende krav afgøres ved en usability test med mindst 20 testdeltagere der har et rejsekort. De detaljerede krav til testdeltagerne står i afsnit C.2.

Hver opgave skal kunne løses korrekt af mindst 90% af testdeltagerne inden for det antal minutter, som er angivet i opgaven. Testdeltagerne må gerne anvende internettet til at finde svaret. Udgangspunktet for testen er at testdeltagerens browser viser forsiden på Rejsekorts websted.

1. Køb et rejsekort. Rejsekortet skal passe bedst muligt til dit behov (10 minutter).

2. Overfør 200 kr. til dit rejsekort via internettet (5 minutter)



3. Dit rejsekort er blevet stjålet. Spær det. (3 minutter)

4. Lad os antage, at du har spærret dit rejsekort, fordi det var blevet væk. Nu har du imidlertid fundet det igen. Ophæv spærringen (5 minutter).

5. Find telefonnummer for kundeservice. (1 minut)

6. Find e-mail adresse for kundeservice. (1 minut)

7. Find ud af hvad en rejse, som du foretog i går fra København H til Valby, kostede.

8. Find ud af hvad en rejse, som du foretog for ca. 3 måneder siden fra København H til Valby, kostede. [Forudsætning for denne opgave: Der er foretaget ca. 50 rejser i mellemtiden på testdeltagerens rejsekort. Den rejse, som opgaven handler om, er foretaget for 3 måneder og 10 dage siden.]

B.2.5. Kundeservice (support) - Telefon Opfyldelsen af følgende krav afgøres med mindst 20 testdeltagere der har et rejsekort. De detaljerede krav til testdeltagerne står i afsnit C.2.

Hver testdeltager skal foretage én opringning til Rejsekorts kundeservice og stille et relevant spørgsmål. Testleverandøren udvælger spørgsmålene blandt de spørgsmål, som ifølge Rejsekorts telefonsupport forekommer hyppigt. Testdeltageren må ikke kende svaret på spørgsmålet på forhånd. Alle valgte spørgsmål skal kunne besvares på under 1 minut, dvs. de må ikke kræve en længere forklaring.

Testleverandøren sørger for, at opringningerne bliver jævnt fordelt over åbningstiden for kundeservice.

1. Den gennemsnitlige tid inden testdeltageren opnår kontakt til en medarbejder i kundeservice, må højst være 2 minutter. Denne tid måles fra testdeltageren har indtastet telefonnummeret til den medarbejder, som besvarer spørgsmålet, er i røret. Tiden omfatter altså evt. valg i et telefonmenusystem, evt. orienterende meddelelser og evt. omstilling til andre medarbejdere.

2. Den gennemsnitlige tid fra telefonen bliver taget til spørgsmålet er besvaret må højst være 3 minutter.

3. Alle spørgsmål skal besvares tilfredsstillende. I tvivlstilfælde afgør testdeltageren om spørgsmålet er besvaret tilfredsstillende.

B.2.6. Kundeservice (support) - E-mail Nedenstående krav testes ved at testleverandøren afsender 25 e-mail til Rejsekorts kundeservice jævnt fordelt over mindst én uge. E-mail skal sendes fra neutralt udseende e-mail adresser.

Testleverandøren udvælger spørgsmålene blandt de spørgsmål, som ifølge Rejsekorts webside er hyppigt forekommende.

1. Den gennemsnitlige tid inden spørgsmålet bliver besvaret må højst være 2 arbejdsdage.

2. Rejsekort skal inden for gennemsnitligt højst 5 minutter kvittere for forespørgslen med en svar e-mail, som gentager spørgsmålet og indeholder den forventede svarfrist.

3. Hvis svarfristen ikke kan overholdes, skal Rejsekort udsende yderligere e-mail med den reviderede svarfrist.



4. Alle spørgsmål skal besvares tilfredsstillende. I tvivlstilfælde afgør kunden om spørgsmålet er besvaret tilfredsstillende.

B.2.7. Fejlhåndtering Opfyldelsen af følgende krav afgøres med mindst 20 testdeltagere der har et rejsekort. De detaljerede krav til testdeltagerne står i afsnit C.2.

1. Bed hver testdeltager om at tjekke ud ved en stander som er i stykker. Standeren skal lyse normalt, men der må ikke komme nogen reaktion fra standeren, ligegyldigt hvad testdeltageren gør. Testdeltageren må ikke på forhånd vide, at standeren er i stykker. Mindst 90% af testdeltagerne skal erkende at standeren er i stykker inden for højst 60 sekunder. Tiden måles fra testdeltageren ankommer til standeren for tjekke ind.

2. I fortsættelse af foregående opgave skal mindst 90% af testdeltagerne være klar over hvad de så skal gøre inden for højst 60 sekunder. Tiden måles fra testdeltageren har erkendt at standeren er i stykker.

3. Bed hver testdeltager om at indsætte 200 kr. på sit rejsekort ved en rejsekort-automat, som er i stykker. Rejsekortautomaten skal se ud som om den fungerer, dvs. den skal vise det sædvanlige startbillede, men der må ikke komme nogen reaktion fra automaten, ligegyldigt hvad testdeltageren gør. Testdeltageren må ikke på forhånd vide, at rejsekortautomaten er i stykker. Mindst 90% af testdeltagerne skal erkende, at rejsekortautomaten er i stykker, inden for højst 60 sekunder. Tiden måles fra testdeltageren ankommer til rejsekortautomaten for at løse sin opgave.

B.2.8. Anvendelighed for handicappede Opfyldelsen af følgende krav afgøres ved en usability test med mindst 10 deltagere, som alle bruger kørestol. Testdeltagerne skal opfylde forudsætningerne i afsnit C.2 for testdeltagere, der ikke har et rejsekort.

1. Bed hver testdeltager tjekke ind. Mindst 80% af testdeltagerne skal inden for højst 15 sekunder efter at de er nået frem til en Rejsekort stander, tjekke korrekt ind.

B.2.9. Krav til nytte for togrevisorer Opfyldelsen af følgende krav afgøres ved en usability test med mindst 10 togrevisorer. Halvdelen af togrevisorerne skal have 2-4 ugers erfaring. De øvrige togrevisorer skal have mindst ½ års erfaring. Alle skal have gennemført den interne uddannelse i brug af Rejsekort kontrolenheden.

1. Testen starter på Vanløse Metrostation. Ved testens begyndelse skal hver togrevisors Rejsekort kontrolenhed være slukket. Bed hver togrevisor om at tænde sin Rejsekort kontrolenhed og sige til, når han/hun mener, at kontrolenheden er klar til den første kontrol af en rejsendes rejsekort. Tiden skal omfatte evt. log ind. Mindst 80% af togrevisorerne skal korrekt melde klar inden for 1 minut. De øvrige må bruge op til 4 minutter og må undervejs fejlagtigt melde klar højst 2 gange.

2. Bed hver togrevisor kontrollere 20 rejsende på et metrotog, som kører fra Vanløse til Frederiksberg. Hver rejsende har et rejsekort. 15 af rejsekortene skal være gyldige. De øvrige skal være ugyldige af én af følgende grunde:

a. Kortet er ikke tjekket ind



b. Kortet er tjekket ind, men sidste indtjekning er sket på Ballerup Station, dvs. den rejsende har glemt at tjekke ind igen da han skiftede befordringsmiddel på Vanløse Station.

c. Kortet er korrekt tjekket ind på Vanløse Station men for ca. 4 timer og 20 minutter siden, dvs. tidsgrænsen på 4 timer er overskredet.

d. To rejsende rejser på samme rejsekort, men rejsekortet er kun tjekket ind til én rejsende.

e. Den rejsende har en hund med, men rejsekortet er kun tjekket ind til en rejsende.

Mindst 80% af togrevisorerne skal kunne gennemføre kontrollerne fejlfrit på mindre end 5 minutter. De øvrige togrevisorer må højst lave 2 fejl og skal kunne gennemføre kontrollen på mindre end 12 minutter. Hvis en togrevisor mener, at et rejsekort er ugyldigt, skal togrevisoren blot mundtligt konstatere dette og derefter straks gå videre til næste rejsende. Under testforløbet skal de rejsende diskret bytte rejsekort, så togrevisorerne ikke på forhånd kan vide, hvem der har gyldige og hvem der har ugyldige rejsekort.

B.3. Eksempler på krav til tilfredshed Krav til tilfredshed er omtalt i afsnit 5.3. Her er nogle eksempler på krav til tilfredshed for Rejsekort:

Testleverandøren måler tilfredshed med et spørgeskema. Målingen gennemføres med mindst 50 testdeltagere, der har et rejsekort. De detaljerede krav til testdeltagerne står i afsnit C.2.

Deltagerne skal vurdere hver af nedenstående påstande på en skala fra 1 til 5, hvor 1 betyder "Meget uenig", 3 er neutral, og 5 betyder "Meget enig".

Den gennemsnitlige vurdering for hvert spørgsmål skal være mindst 3,7.

1. Rejsekort er nemt at bruge

2. Jeg føler mig tryg ved at bruge Rejsekort

3. Det er nemt at få hjælp til Rejsekort

4. Rejsekort er fejltolerant

5. Standeren ser pæn ud

6. Standeren er nem at få øje på

7. Det er nemt at tjekke ind

8. Det er nemt at tjekke ud

9. Rejsekortautomaten ser pæn ud

10. Rejsekortautomaten er nem at få øje på

11. Rejsekortautomaten er nem at bruge

12. Rejsekorts websted ser pænt ud

13. Rejsekorts websted er nemt at bruge

14. Sproget på Rejsekorts websted er nemt at forstå



For spørgsmål, hvor den gennemsnitlige vurdering er under 3,7, skal testleverandøren oplyse årsagen til den lave vurdering på grundlag af interview af deltagere i undersøgelsen.



Appendiks C. Supplerende oplysninger

C.1. Kerneopgaver Kerneopgaverne er en liste over de vigtigste arbejdsopgaver for passagerer i Rejsekort. Kerneopgaver og deres anvendelse er omtalt i afsnit 4 og A.2.5.

Kerneopgaverne for Rejsekort er:

1. Køb et rejsekort

2. Indsæt penge på konto for rejsekort via internettet

3. Indsæt penge på konto for rejsekort via rejsekortautomat på station

4. Spær rejsekort

5. Tjek ind, start på rejse

6. Tjek ind, fortsat rejse

7. Tjek ud

8. Find Rejsekorts websted

9. Find pris på konkret rejse

10. Se saldo og bevægelser på konto for rejsekort

Delopgaver som Log ind på websted, Log ud fra websted, Find svar på spørgsmål via hjælpesystem og Find svar på spørgsmål via support er ikke kerneopgaver, da brugere ikke opfatter dem som nyttige. Set fra brugeres synspunkt er disse opgaver irriterende men nødvendige dele af kerneopgaver.

C.2. Testdeltagere til usability test I krav til effektivitet (afsnit 5.2 og B.2) indgår usability test som et vigtigt måleværktøj. Usability testene udføres af testdeltagere. Hvor intet andet er anført, gælder følgende krav til testdeltagerne:

1. Testdeltagerne skal være danske statsborgere. De skal være mindst 18 år gamle. De skal repræsentere et typisk udsnit af den danske befolkning hvad angår alder, uddannelse, interesse for teknologi og viden om it.

2. Alle testdeltagerne skal forstå dansk svarende til at de kan bestå "Prøve i dansk 1".

3. Testdeltagere der ikke har et rejsekort: Testdeltagerne må ikke have et rejsekort i forvejen, men de må gerne have hørt eller læst om Rejsekort.

Disse testdeltagere skal have foretaget mindst 4 enkeltrejser med S-tog eller bus inden for de seneste 3 måneder, hvor de har benyttet klippekort eller billet.

4. Testdeltagere der har et rejsekort: Testdeltagerne skal have et rejsekort, som de har benyttet mindst 5 gange inden for de seneste 3 måneder.

Antallet af testdeltagere, som deltager i måling af et krav, er anført under kravet.

sådan skriver du krav til brugervenlighed - · pdf filesådan skriver du krav til...

Documents