· Web viewEndelig interviewede vi en intern usability testperson fra NSI-projektet og en fra...

Rapport fra forbedringsaktivitet:

Kravspecifikationer

Division : S&V og CMSArkiv : SPI, j:\8459\spi\document\Emne : KravspecifikationerGruppe : DokumentDokument type : DokumentDokument nr. : 2Revision nr : 005Status : FRIGIVETGodkendt af :

Revisionshistorie:Nr Dato Init Indhold Godkendt af001 1999-05-17 JPH/OtV Første sammenskrivning002 1999-10-05 JPH/OtV Anden sammenskrivning003 1999-11-02 OtV Opdatering med teknikker og scenarieskabelon004 1999-11-10 JPH/OtV Konklusion tilføjet. Udsendt til kommentering005 1999-11-26 OtV Frigivet efter opdatering med kommentarer

Distributionsliste:OtV/89, JPH(DELTA), JoJ(DELTA), JN(DTU-CTI), PAN(AU), LBN/89, PHo/89, FKN/89, KKHN/89, JF/96, JB/96

B&K/document.doc 99-11-26 19.33 of 34

Indholdsfortegnelse1. Introduktion................................................................................................................................32. Metode........................................................................................................................................33. Første del af projektet.................................................................................................................4

3.1 Workshop i januar 1997..............................................................................................54. Evalueringer af første del af projektet........................................................................................6

4.1 Første evaluering, midt i kravspecifikationsfasen........................................................74.2 Anden evaluering, efter kravspecifikationsfasen.........................................................84.3 Tredje og sidste evaluering, efter projektafslutning.....................................................94.4 Analyse og konklusion på første del af projektet.......................................................104.5 Eftertanker om første del af projektet........................................................................12

5. Anden del af projektet..............................................................................................................125.1 Workshop i maj 1998.................................................................................................12

6. Evalueringer af anden del af projektet.....................................................................................136.1 Første møde med projekterne, den 16. juni 1998.......................................................136.2 Andet møde med projekterne, den 3. august 1998.....................................................146.3 Tredje møde med projekterne, den 1. september 1998..............................................146.4 Fjerde møde med projekterne, den 17. september 1998............................................156.5 Femte møde med projekterne, den 19. oktober 1998.................................................156.6 Det videre forløb på projekterne indtil afslutningen af kravspecifikationsfaserne....166.7 Forløbet på Gyro-projektet.........................................................................................176.8 Det videre forløb af projekterne.................................................................................176.9 Spredning og optagelse af teknikkerne......................................................................186.10 Analyse og konklusion på anden del af projektet......................................................19

7. Resultater med scenarier og usability tests..............................................................................207.1 Identificere de rigtige behov......................................................................................20

7.1.1 Udviklerne kommer i forbindelse med kunder og brugere..........................207.1.2 Nedskrivning af brugssituationer dokumenterer behovene.........................207.1.3 Behovene valideres gennem usability tests på tidlige prototyper................207.1.4 Valideringen gennem usability tests giver en bedre prioritering af behovene20

7.2 Bedre videnoverførsel fra kunde/bruger til projekt....................................................217.2.1 Udviklerne skal selv skrive scenarier og gennemføre usability tests..........217.2.2 ”Tænke højt” princippet under usability tests afslører det brede spektrum af domæneviden.............................................................................................................21

7.3 Bedre samspil i udviklingsprojektet internt...............................................................217.3.1 Fælles sprog og fælles forståelse.................................................................217.3.2 Bedre udnyttelse af interne eksperter..........................................................227.3.3 Oplæring af nye medarbejdere.....................................................................227.3.4 Forbedret salgs/markedsføringsdokumentation og test...............................22

7.4 Teknikkerne er effektive............................................................................................227.4.1 Teknikkerne medfører ikke flere krav kun en øget detaljering...................227.4.2 Teknikkerne koster ikke mere tid totalt på projektet, kun fordelingen ændres 237.4.3 Effekten opnås kun gennem hård projektstyring og processtøtte................23

7.5 Teknikkerne giver bedre produkter............................................................................247.5.1 Bedre understøttelse af brugerens reelle behov...........................................247.5.2 Forbedret brugerinteraktion.........................................................................247.5.3 Færre fejl......................................................................................................24

8. Sammenligning med andre undersøgelser...............................................................................249. Konklusion...............................................................................................................................2610. Referencer................................................................................................................................27Bilag 1. Scenarie-skabelon.....................................................................................................................28Bilag 2. Listen over kravspecifikationsteknikker...................................................................................29Bilag 3. Scenarie og Usability test teknikkerne.....................................................................................32


1. Introduktion

I denne rapport beskrives forløbet af forbedringsaktiviteten kravspecifikationer hos Brüel & Kjær. Forbedringsaktiviteterne falder i to delprojekter. Første del fra januar 1996 til februar 1998. Anden del fra maj 1998 til januar 1999.

Første del af projektet blev – under navnet PRIDE (A Methodology for Preventing Requirements Issues from Becoming Defects) [Vinter, Lauesen & Pries-Heje, 1999] – finansieret under EU Kommissionens ESSI-program (European System and Software Initiative). Fra Brüel & Kjær deltog Otto Vinter, Per Michael Poulsen, Kai Ormstrup Jensen, samt to udviklingsprojekter. Handelshøjskolen i København var underleverandør til projektet og herfra deltog Søren Lauesen og Jan Pries-Heje. Målet for PRIDE-projektet var at:

1. Få viden om hyppigt forekommende problemer i kravspecifikations-processen2. Ændre udviklingsprocessen ved at definere et sæt optimale teknikker, der kunne forebygge at de fundne

problemer opstod3. Måle virkningen af ændringen i et konkret udviklingsprojekt

Anden del af projektet er foregået indenfor rammerne af ”Center for softwareprocesforbedring” (Centre for Software Process Improvement - CSPI) [Mathiassen, 1996], som B&K er deltager i. CSPI er et dansk projekt til fremme af forbedringsinitiativer i firmaer, der udvikler software.

Centerkontrakten løber over tre år (1997-1999), hvor halvdelen er finansieret af den danske stat, dels gennem Erhvervsfremmestyrelsen, dels gennem Center for IT forskning (CIT). Den anden halvdel finansierer de deltagende firmaer selv. Deltagerne i centret er: Brüel & Kjær A/S, Danske Data A/S, L. M. Ericsson Danmark A/S og Systematic Software Engineering A/S, samt DELTA, Aalborg Universitet og Danmarks Tekniske Universitet.

I hvert af de fire firmaer er der etableret en central software procesforbedringsgruppe med deltagelse af forskere fra DELTA og universiteterne, og firmaets procesforbedringsansvarlige.

Arbejdet i anden del af projektet er udført i samarbejde mellem en støttegruppe udpeget af den centrale software-procesforbedringsgruppe og tre udviklingsprojekter hos B&K S&V, og et i CMS. Støttegruppen har bestået af: Otto Vinter (S&V) og Jan Pries-Heje (DELTA).

Formålet med anden del af projektet var at sprede teknikkerne fra PRIDE projektet til en række andre udviklingsprojekter på Brüel & Kjær, hvorved erfaringer med teknikkerne kunne opnås i stor skala, samt hvordan spredning og optagelse i organisationen gennemføres.

2. Metode

Den forskningsmetode vi har anvendt er aktionsforskning (”action research”). Bob Galliers [1992] beskriver aktionsforskning som en måde, hvor man samtidig forsøger at skabe ny teoretisk viden og at skabe noget af praktisk værdi for den organisation, der forskes i. Fremgangsmåden vi har fulgt i vores aktionsforskning har været inspireret af de fem faser anbefalet af Susman & Evered [1995]: (1) Specifikation af infrastrukturen for vores projekt. (2) Diagnose af problemet. (3) Planlæg vores handlinger. (4) Udfør handlingerne, og (5) Evaluer det der kom ud af handlingerne. Gentag evt. fase (2) til (5).

Projektets infrastruktur blev dels defineret af rammerne for PRIDE-projektet (første del af forbedrings-aktiviteten), dels af rammerne for Centerkontrakten (anden del af aktiviteten).


Vores første diagnose startede med at analysere fejlrapporter fra et Brüel & Kjær produkt der allerede var på markedet. Til at analysere fejlrapporterene brugte vi en taksonomi for fejltyper [Beizer, 1990]. Sideløbende med at vi studerede det konkrete produkt læste vi, hvad andre havde skrevet om kravspecifikationer. Vi havde f.eks. fat i [Davis, 1990], i [Thayer & Dorfman, 1997] og i [Sommerville & Sawyer, 1997], der alle giver en række teknikker til bedre kravspecifikationer.

For at finde de teknikker, der ville have forebygget flest fejl, vurderede vi med hvilken sandsynlighed en given teknik ville have forebygget et problem i en fejlrapport. Diagnosen blev først lavet individuelt og derpå diskuteret i gruppen af involverede, indtil vi nåede til enighed om en sandsynlighed. Derpå foretog vi en cost/benefit vurdering af teknikkerne og nåede derigennem frem til en liste med potentielt meget lovende kravspecifikationsteknikker.

Vi gik herefter videre med at finde to projekter der var interesseret i at indgå i et samarbejde om at forbedre kravspecifikationsprocessen. Vi involverede projekterne selv i valget af konkrete teknikker, for derved at sikre motivationen i projekterne. Vi gennemførte herefter en workshop for de to projekter for at lære dem at anvende de valgte teknikker. Derpå gennemførte projekterne kravspecifikationsfasen, mens vi både støttede projekterne i anvendelsen af teknikkerne, og interviewede dem om deres erfaringer.

Alle interview blev gennemført af to personer. Otto Vinter stillede spørgsmål og Jan Pries-Heje skrev referat. Så kort tid som muligt efter interviewet blev referatet skrevet rent. Efter at have gennemført tre interviewrunder analyserede vi de mange interviewreferater. Detaljerne i denne første del af projektet, samt vores konklusioner, findes neden for i afsnit 3 og 4.

Første del af projektet var så succesfuld, at flere projekter hos Bruël & Kjær var interesserede i at komme til at anvende teknikkerne. Vi uddannede deltagerne i fire projekter, og vi fulgte de fire projekter gennem deres kravspecifikationsforløb. Vi holdt regelmæssige statusmøder med hvert af projekterne og foretog en enkelt interviewrunde. Endelig kunne vi igen konkludere, at teknikkerne scenarier og usability test af tidlige prototyper fører til en meget succesfuld forbedring af kravspecifikationsprocessen. Detaljerne i den anden del af projektet, samt vores konklusioner, findes neden for i afsnit 5 og 6.

Efter afslutningen af kravspecifikationsfaserne gennemgik vi alt materialet fra både første og anden del af projektet. Det skete ved at hvert interview og referat blev læst igennem og de vigtigste observationer noteret. Notaterne blev herefter grupperet og hver gruppe af observationer fik en samlende beskrivelse hæftet på sig. At grupperne var konsistente blev checket ved at sammenligne med interviewnoter og referater endnu en gang. Forskningsmetodemæssigt anvendte vi det der kaldes sekventiel analyse af en case [Miles & Huberman, 1994].

Til sidst evaluerede vi hele forløbet, fremhævede resultaterne af teknikkerne og konkluderede. Detaljerne findes neden for i afsnit 7 til 9.

3. Første del af projektet

Efter vores analyse af fejlrapporter m.v. havde vi en liste med potentielt meget lovende kravspecifikations-teknikker. To projekter – 2260 Sound Intensity og PULSE Sound Power – der stod lige foran at skulle påbegyndes, og som var interesserede i at forbedre deres kravspecifikationsproces blev den 18. december 1996 præsenteret for de 13 mest lovende teknikker1:

1 Engelske betegnelser og tekster er bevaret her som andre steder i rapporten aht. kompatibilitet med tidligere præsentationer og dokumenter (feks. PRIDE Final Report [Vinter, Lauesen & Pries-Heje, 1999]), samt en planlagt udsendelse af (dele af) nærværende rapport på engelsk


101 Scenarios210 Paper mockup, daily tasks212 Paper mockup, stress cases230 Functional prototype, daily tasks232 Functional prototype, stress cases270 Check with B&K style guide280 Let product experts review screens301 External software stress test702 Formal inspection of mockup710 Improved check of object model721 Orthogonality check730 Initial value check820 Performance specifications

Numrene ovenfor udfor teknikkerne refererer til den identifikation vi tildelte teknikkerne under den forudgående undersøgelse. Den komplette liste over teknikker kan findes i Bilag 2 med en kort beskrivelse til hver.

Alle deltagerne fra de to projekter evaluerede de 13 teknikker, dels ud fra en kort gennemgang, dels ud fra en kortfattet tekst. Til evalueringen anvendtes nedenstående spørgsmål, der blev stillet for hver teknik:

1. I hvilket omfang vil denne teknik ændre den måde du normalt arbejder? Mulige svar: (1) Større ændring. (2) Mindre ændring. (3) Ingen ændring.

2. I hvilket omfang vil denne teknik ændre den måde andre hos Brüel & Kjær arbejder på? Mulige svar: (1) Større ændring. (2) Mindre ændring. (3) Ingen ændring.

3. Evaluer følgende påstand: Denne teknik er effektiv og brugbar. Mulige svar: (1) Ja, jeg er helt enig. (2) Ja, jeg er delvis enig. (3) Ja, men ikke ret meget. (4) Nej, det vil være spild af tid. (5) Nej, jeg tror det vil føre til flere fejl.

4. Hvor sikkert er det, at brugen af denne teknik vil føre til den forventede forebyggelse af fejl ifm. kravspecifikation? Mulige svar: (1) Meget sikkert. (2) Sikkert. (3) Ikke særlig sikkert. (4) Usikkert. (5) Meget usikkert.

På basis af svarene fra evalueringen udvalgtes følgende sæt teknikker, som vi derpå indarbejdede i et egentligt træningsmateriale til den efterfølgende workshop.

101 Scenarios230 Functional prototype, daily tasks280 Let product experts review screens (kun 2260 Sound Intensity)301 External software stress test (kun Sound Power)721 Orthogonality check730 Initial value check820 Performance specifications (kun Sound Power)

3.1 Workshop i januar 1997

Baseret på de valgte teknikker afholdtes en workshop den 7. og 10. januar 1997. Formålet med workshoppen var, at give medarbejderne i de to projekter den fornødne træning så de kunne bruge teknikkerne. Indholdet af workshoppen var følgende, idet punkterne 1-5 blev afviklet den første dag:


1. Scenarios and tasks (technique 101)2. Exercise in two-person groups to define a scenario and extract some tasks 3. Introduction to usability (technique 230 starts here and is finished in session 10) and examination of a

concrete case about user-friendly design4. Step-wise modelling of a prototype5. Excercise in groups on creating a user-friendly design. From user data model to logical design.6. Usability testing, focusing on thinking-aloud sessions (”discount” usability test)7. Initial value check (technique 730)8. Excercise in groups on creating a user-friendly design. From dialog design to physical design on paper9. Excercise in groups performing a thinking-aloud session (Usability test)10. Prototyping. What, when, and how to prototype? Advantages and disadvantages11. Let product experts review screens (technique 280)12. External software stress test (technique 301)13. Orthogonality check (technique 721)14. Performance specifications (technique 820)

Den pædagogiske idé i de to dages workshop var, at deltagerne selv skulle prøve de centrale teknikker, så de faktisk var i stand til at anvende dem i deres eget projekt bagefter. Derfor havde vi indlagt øvelser både i at skrive scenarier, i at lave et brugervenligt design, og i at gennemføre en usability test ved hjælp af tænke-højt forsøg. I øvelsen havde vi også indarbejdet check af initialværdier (Initial value check - technique 730).

Med hensyn til prototyping så fokuserede vi meget på, at en funktionel prototype ikke måtte glide over og blive et færdigt system. Prototypen skulle smides væk når man havde lært af den. Konkret sagde vi at man skulle undgå fælder som illustreret af følgende citater:

“Kunne jeg ikke få prototypen i Beta-test?” “Jeg har allerede solgt systemet. Hvorfor gør I det ikke lige færdigt?” “Planen er ændret. Vi har ikke råd til at lave det hele om!” “Jeg skal lige have det hele med” “Se den smarte løsning jeg her har fundet på” “Slow prototyping”

Vi sluttede to-dages workshoppen med at gennemgå de fire sidste teknikker, som kan bruges når man har skrevet en kravspecifikation. Vi viste eksempler på teknikkerne baseret på konkrete fejlrapporter, men der var ikke tid til at deltagerne selv prøvede disse teknikker.

4. Evalueringer af første del af projektet

En eksakt måling af effekten af brugen af de valgte teknikker kunne ikke finde sted før projekterne var færdige og fejlrapporter var begyndt at komme ind. For ikke blot at sidde med hænderne i skødet så længe valgte vi at gennemføre en række interviews undervejs, der skulle belyse hvordan projektdeltagerne oplevede brugen og effekten af teknikkerne mens de brugte dem.

For hver teknik stillede vi en række spørgsmål som vist i spørgeguiden neden for. Spørgeguide til evalueringerHar du brugt denne teknik?Hvis NEJ: Hvorfor ikke?Hvis JA: 1. Hvordan var det at anvende teknikken?

2. Kunne du give os et eksempel på succesfuld brug af denne teknik?3. Anser du fortsat denne teknik for at være effektiv og brugbar?4. Synes du workshoppen gav dig nok viden til at du kunne bruge teknikken?5. Hvor meget ekstra tid har anvendelsen af denne teknik taget (sammenlignet

med hvad du/I har brugt i tidligere projekter)?


4.1 Første evaluering, midt i kravspecifikationsfasen

To personer fra PULSE Sound Power projektet og fire personer fra 2260 Sound Intensity projektet blev interviewet den 25. februar. Hvert interview varede ca. 30 minutter. Neden for er givet nogle eksempler fra interview-referaterne.

En af projektmedlemmerne, der tidligere havde arbejdet på et projekt kaldet NSL (Noise Source Location), sammenlignede den gamle type Bruel & Kjær kravspecifikationer med den der blev skrevet i PULSE Sound Power projektet:

“En normal kravspecifikationen er ret kedelig: DUNG, DUNG, DUNG kommer kravene efter hinanden. Hvis du f.eks. ser på den gamle NSL kravspecifikation, så er der et antal krav som jeg slet ikke forstår i dag! Men i dette projekt, hvor vi inkluderer scenarierne i kravspecifikationen, og giver en kort forklarende hvorfor?-tekst til hvert krav, der er det meget nemmere at forstå specifikationen.”

I de syv uger der var gået fra workshoppen til interviewet havde begge projekter anvendt scenarieteknikken. Scenarierne i PULSE Sound Power var kommet frem gennem brainstorm, hvor to projektdeltagere prøvede at sætte sig selv i kundens sted. Der var blevet skrevet fire scenarier og lavet en første skitse til kravspecifikationen, hvori scenarierne var inkluderet. Projektet henvendte sig til os for at få læst den igennem. Vi pegede først og fremmest på projektets manglende brug af Performance Specification teknikken (820) og satte fokus på kvantificering af hvad det egentlig var brugeren forventede. Ved interviewet mente projektdeltagerne at denne gennemlæsning havde været værdifuld.

Scenarie-teknikken i 2260 Sound Intensity projektet

Projektet havde brugt en del energi på at bruge scenarier. Først havde man lavet en scenarie-skabelon, inspireret af et forslag til scenarie-skabelon2 som Jan Pries-Heje havde lagt frem på workshoppen i januar. Dernæst havde man skrevet 15 scenarier. Scenarierne var fremkommet ved et møde hvor man prøvet at lave en liste over typiske fremtidige brugssituationer. Situationerne var så blevet distribueret til fem projektmedlemmer som hver især havde skrevet nogle scenarier. Hvert scenarie var 1-2 sider langt og endte med en liste af essentielle arbejdsopgaver. Da scenarierne var skrevet blev de reviewet og revideret indtil man var sikker på, at alle projektdeltagerne forstod alle scenarier.

På spørgsmålet om brugen af scenarier havde været en succes i 2260 Sound Intensity projektet fik vi bl.a. følgende svar:

”Ja, det er meget inspirerende at skrive scenarier. Meget sjovere end den traditionelle kravspecifikationsfase. Men jeg er bekymret for om vi har alle vigtige krav med?”

”Scenarierne har fået os til at tænke over en række ting som vi ellers ville have overset. Sammenligning af målinger for eksempel.”

”Når jeg læser alle disse scenarier så er jeg i stand til at lave brugergrænsefladen til systemet lynhurtigt.” ”Brugen af scenarier gør, at idéer til nye krav kan blive evalueret med det samme.” “Vi identificerede en brugssituation, vi aldrig har tænkt på før, og den gav anledning til et nyt scenarie.”

Med hensyn til workshoppen så var meningerne delte med hensyn til scenarier. Nogen mente at der havde været tid nok til at lære at anvende scenarier. Andre fandt at der skulle have været mere tid til at prøve det. Vi fik også at vide at tiden til at gennemgå de fire sidste teknikker (i slutningen af workshoppen) havde været alt for kort.

2 Dette forslag til scenarie-skabelon er gennem hele forløbet blevet justeret og forbedret af projektholdene. Den seneste version kan findes i Bilag 1.


4.2 Anden evaluering, efter kravspecifikationsfasen

To personer fra PULSE Sound Power projektet blev interviewet den 9. juli, og tre personer fra 2260 Sound Intensity projektet blev interviewet den 7. august 1997. Hvert interview varede i gennemsnit ca. 40 minutter.

Begge projekter havde anvendt både scenarier og usability test af prototyper. Og begge dele med gode resultater. Neden for er givet nogle eksempler fra interview-referaterne. Bemærk at referaterne blev renskrevet på engelsk, selv om interviewet foregik på dansk.

Usability tests with a navigational prototype of the Sound Power project

A navigational3 prototype was made in Visual Basic, and a Usability test was carried out on the west coast of U.S. in March 1997. Three persons from B&K travelled to U.S. with the purpose of carrying out the usability test with three different potential customers. The three people had dedicated roles during the usability test. One person was acting as test leader closely following what the customer did, encouraging thinking-aloud, and guiding the user when necessary. The other person was acting as log keeper. The third person took care of recording the test on cassette tapes while keeping a process-oriented log, helping the test leader to follow up on important issues, and giving feedback on the process after the test. After coming back to Denmark the developers listened to the tapes and made a report with the conlusions from the tests.

The response to the usability test technique was very positive. “It was just really good” and “I learned a lot from having direct contact with customers” were two typical reactions.

The customers also responded quite positively to the usability test technique. They were “very friendly and positive”. And they felt that “they were allowed to contribute to the design and to decide the flow in the product”, and that satisfied them. One of the three customers was not so fond of having three people look at him when using the prototype. But for the others it did not matter.

PULSE Sound Power projektet havde skiftet projektleder i april 1997, efter at scenarierne var skrevet og de første usability tests gennemført. Den nye projektleder var blevet præsenteret for teknikkerne og de hidtil opnåede resultater, men gennemgik ikke et egentligt træningsforløb. Han fandt umiddelbart kravspecifikationsteknikkerne interessante, men ønskede selv at bestemme omfanget af brugen af teknikkerne.

Vi spurgte projektlederen og projektdeltagerne fra Sound Power projektet om de havde lært noget af at anvende Usability test på en prototype. De svarede blandt andet:

“Vi opdagede, at du er nødt til nemt at kunne identificere det enkelte diskdrev, når du skal måle på det.” “Kundens idé om hvordan data skulle præsenteres var meget forskellig fra vores idé.” “Vi fandt ud af, at vores koncept for multi-pass måling var fortænkt. Hvis kunden har råd til at købe vores

produkt, så har de også råd til at købe mikrofoner nok.”

Projektdeltagerne var også kritiske overfor teknikken, især i forhold til deres egen optræden. Projektdeltageren der fungerede som forsøgsleder var f.eks. blevet træt af at høre, at prototypen ikke virkede et givent sted, så han afbrød brugeren og gik videre, uden at lade brugeren tale færdig. ”Vi blev træt af at høre om vores egne fejl igen og igen” var der en anden der sagde.

Alt i alt mente projektdeltagerne i PULSE Sound Power projektet dog, at usability test af prototyper var en meget værdifuld teknik.

I 2260 Sound Intensity projektet havde man lavet to prototyper. Først havde man udviklet en navigerbar prototype med skærmbilleder lavet ved hjælp af Microsoft Word, hvor man kunne bruge bogmærkefunktionen til at hoppe 3 At en prototype er navigerbar vil sige at prototypen består af statiske (faste) skærmbilleder, hvorimod alle skift

af (navigering mellem) skærmbillederne er implementeret. Denne form for prototyper anvendes i teknik 22x.


rundt mellem skærmbillederne. Denne prototype blev usability testet med interne brugere. ”Vi fik utroligt meget ud af denne test”, fortalte projektlederen. Rigtig mange ting blev gjort simplere som resultat af denne test. De interne brugere kunne ”simpelt hen ikke finde ud af, at bruge alle vores kreative tanker.”

Den anden prototype derimod, som var en fuld funktionel prototype, var en mere blandet oplevelse som det fremgår af nedenstående referat.

Usability tests with a functional prototype of the 2260 Sound Intensity project

Second a full functional prototype was developed and tested with customers in UK and Germany in the beginning of July 1997. The results were not as good as expected. “We could not cope with the task of getting the customers lined up to a usability test as we wanted it” told the project leader. The reason for this was partly due to the sales people he told: “Brüel & Kjær sales people had quite another interest than we had. Therefore the discussion often was derailed.”. The project member that also participated in the test with external people supported this statement: “Our test persons came in many cases totally unprepared for a test, and the sales people interrupted our usability test frequently. They did not like to see their customers sweating a lot over a problem.”. And he continues: “The sales people combined our usability test with a lot of other things. They were not aware that we aimed at a very clinical test situation."

Another reason was that some of the users were not capable of showing how they would use the equipment for a task: “The next one we visited was not interested at all to run a usability test. He was much more interested in talking about all the B&K equipment he had on beforehand.”.

In order to counteract some of these problems, the format of the meetings were changed. The projects leader said: “In the morning we had invited two customers, and in the afternoon three. When they arrived we started by giving them a slide show as introduction to the rationale behind the functional prototype. Then each of them got a hand held instrument with the prototype running on it.” In the morning the visitors were two people from industry “they had a lot of practical problems, so we got suggestions for a new way of numbering, and we got some good comments for our auto-save function”. But in the afternoon the results were sparse again.

Som konklusion og sammenligning af de to usability testforløb sagde projektlederen: “Der er stor forskel mellem intern og ekstern usability test. Interne folk kommer med et åbent sind og er motiverede for at hjælpe os. Eksterne folk er interesseret i at lære noget nyt om vores produkt, og i at løse deres problem. Men de er ikke rigtigt motiverede for at hjælpe os.”

Så alt i alt en meget positiv konklusion på den interne usability test med en simpel prototype, og en noget mere skeptisk konklusion om anvendeligheden af ekstern usability test af en fuldt funktionel prototype. For den sidstes vedkommende stod indsatsen næppe mål med udbyttet.

4.3 Tredje og sidste evaluering, efter projektafslutning

Den nye projektleder på PULSE Sound Power projektet havde fra et tidligere projekt sine egne ideer om, hvad produktet skulle kunne, og hvorledes brugerinteraktionen burde udformes. Pgra. dette og de stramme tidsplaner besluttede han at gennemføre projektet på ”traditionel” vis.

Der blev derfor ikke, på trods af adskillige opfordringer, gennemført flere usability tests eller arbejdet med de andre kravspecifikationsteknikker. Projektet fulgte siden det sædvanlige udviklingsforløb for projekter på B&K. Det sluttede væsentligt senere end planlagt, hvilket dog primært skyldtes mangel på ressourcer. Der blev ikke gennemført en tredje og sidste evaluering for dette projekt.

2260 Sound Intensity projektet blev frigivet i december 1997. Fra et salgssynspunkt var projektet en umiddelbar succes, som sælger dobbelt så godt som et sammenligneligt produkt fra Brüel & Kjær.


Den 26. januar og den 3. februar 1998 gennemførte vi interviews med projektlederen og fire projektmedlemmer fra 2260 Sound Intensity projektet. Hvert interview varede i gennemsnit ca. 45 minutter.

Af de mange valgte teknikker viste det sig i praksis at kun scenarier og usability test af prototyper var blevet anvendt seriøst. Der havde været sporadiske forsøg med de andre teknikker, men ikke i et omfang så vi kunne analysere og konkludere noget.

Alle projektdeltagerne udtrykte stor tilfredshed med teknikkerne. Godt nok havde det taget lang tid at bruge teknikkerne og kravspecifikationsfasen var blevet væsentlig længere end planlagt. Men det var holdets opfattelse, at det ikke havde været muligt at få færdiggjort projektet inden udgangen af 1997 uden anvendelse af teknikkerne. Udfra de beskrevne scenarier og de gennemførte usability tests var alle deltagerne klar over hvad produktet skulle kunne og hvordan det skulle laves. Der havde derfor været langt færre diskussioner og spildt arbejde.

Det var også holdningen at produktet selv var blevet radikalt forbedret ift. de oprindelige intentioner og langt mere brugervenligt end tilsvarende andre B&K produkter.

4.4 Analyse og konklusion på første del af projektet

Umiddelbart efter den tredje og sidste evaluering gennemførte vi en sekventiel analyse som beskrevet i metode-afsnittet (se afsnit 2). Vores konklusioner er gengivet neden for.

Anvendelse af scenarie-teknikken

Scenarie-teknikken blev brugt i begge projekter med følgende observationer til følge: På et tidligt tidspunkt blev det muligt at se flowet igennem systemet på en meget konkret måde. Selve kravspecifikations-dokumentet blev lettere at læse og forstå når scenarierne blev inkluderet Scenarierne kunne bruges som udgangspunkt for at vurdere forskellige design-alternativer og vælge en

løsning Scenarierne kom til at fungere som en fælles referenceramme for projektets deltagere Scenarierne viste sig at være meget effektive til at få softwareudviklerne til at blive fortrolige med

applikationsdomænet Alle projektdeltagere var enige om, at brugen af scenarier havde forebygget mange fejl som man ellers ville

have lavet i kravspecifikationsfasen og taget med videre i projektet.

Der var dog også et par dråber malurt i bægeret: Der blev brugt længere tid i kravspecifikationsfasen end i et typisk Brüel & Kjær projekt. Sound Intensity

projektdeltagerne vurderede det til at være mindst en måned længere. Der var behov for bedre retningslinier for hvor mange scenarier der skulle laves og hvor detaljerede de

skulle være Der var også behov for bedre retningslinier for hvordan man kom fra arbejdsopgaver (udledt af scenarier) til

krav.

Alt i alt konkluderede vi, at scenarier var en meget anvendelig teknik som vi klart kunne anbefale andre projekter at tage i brug. Vi besluttede også at vi til en anden gang ville bruge mere tid til at undervise i brugen af scenarier, og især lægge mere vægt på, at man ikke skriver for mange, samt på hvordan man kommer hele vejen fra scenarier, over udledte arbejdsopgaver, til krav.


Usability test af prototype

I begge projekter blev der gennemført et antal usability tests af prototyper med følgende observationer til følge:

En papirbaseret prototype viste sig at være en meget effektiv teknik, forstået på den måde at man lærte utroligt meget for en lille investering (to manduger blev der brugt på at lave prototypen).

Det at teste med rigtige kunder gav en masse læring for udviklerne i projektet. Usability test ændrede hele brugergrænsefladen på 2260 Sound Intensity projektet. Den ny

brugergrænseflade imponerede en række udviklere fra andre projekter hos Brüel & Kjær. En masse ting blev simplere i det produkt der var udviklet ved hjælp af denne teknik. Den første usability test ændrede hele produktet. Den anden usability test var ikke nær så imponerende, men

bekræftede de beslutninger der var blevet truffet på baggrund af den første test. En funktionel prototype virkede rigtig godt ved et møde for Brüel & Kjær sælgere.

Der var også en række mere negative observationer: Funktionelle prototyper tager for lang tid at udvikle i forhold til udbyttet. Det er svært at skulle være forsøgsleder for en usability test af et produkt som du selv har udviklet Det er svært at koordinere og få accept fra salgsfolk til at gennemføre en usability test. Det er svært at få det fulde udbytte af usability test med rigtige brugere.

Generelt var konklusionen med hensyn til usability test af prototyper en fuldstændig enig anbefaling af teknikken fra alle interviewede for så vidt angår en hurtig papirbaseret eller navigerbar prototype. Der var også en enig anbefaling af, at bruge teknikken med interne brugere, mens de var mere forbeholdne over for usability test med rigtige potentielle brugere.

Med hensyn til de andre udvalgte tekniker var vores konklusioner:

Initial value check (teknik 730)Denne teknik blev ikke brugt systematisk i nogen af projekterne. Vi kunne derfor ikke konkludere noget endeligt. Vi besluttede at vi en anden gang ville forsøge at integrere teknikken med usability test i en evt. fremtidig workshop, hvilket vi dog ikke fik lejlighed til i anden del af projektet

Let product experts review screens (teknik 280)Denne teknik blev kun anvendt i det omfang produkteksperter blev involveret i en usability test. Resultatet heraf var meget overbevisende som det er fremgået oven for, selvom nogle af eksperterne havde svært ved at indstille sig på en væsentlig anderledes brugerinteraktion. Vi kunne ikke konkludere noget endeligt om denne teknik separat.

Orthogonality check (teknik 721)Denne teknik blev ikke brugt systematisk, men kun indirekte, for eksempel ved diskussionen af løsningsalternativer og scenarier. I en fremtidig workshop besluttede vi, at teknikken skal have mere tid, og at der skal indgå et eksempel der illustrerer teknikkens fordele klart og tydeligt for deltagerne. Vi kunne heller ikke konkludere noget endeligt om denne teknik.

Performance specification (teknik 820)Denne teknik blev ikke brugt systematisk i nogen af projekterne. Vi kunne derfor heller ikke konkludere noget endeligt om denne teknik. En af forfatterne til nærværende rapport blev bedt om at kommentere det sidste udkast til kravspecifikationen før det officielle review. I sin gennemgang brugte han denne teknik kraftigt, hvilket gav anledning til en del ændringer.


4.5 Eftertanker om første del af projektet

Der synes at være en grænse for hvor mange teknikker et projekt kan tage til sig. Begge projekter lykkedes med at tage 2-3 teknikker succesfuldt i anvendelse – og droppede resten, selv om de selv havde valgt teknikkerne før projektet startede.Årsagen synes at være, at projektholdene begyndte at bruge scenarie og usability test teknikkerne umiddelbart efter workshoppen i januar. Da de følte, at de fik stor succes med disse teknikker, syntes de, at de havde opnået tilstrækkelig viden til at udvikle det rigtige produkt. Der var derfor ikke længere interesse for at påbegynde de resterende teknikker i slutningen af kravspecifikationsfasen. Tilliden til, at disse teknikker også ville kunne give resultater, var uforandret. Blot var lysten til at bruge mere tid på kravspecifikationerne forsvundet.

I vores oprindelige analyse af fejlrapporter havde vi regnet med at de fire sidstnævnte teknikker – dem som ikke rigtig blev brugt – ville forebygge en række fejl. En analyse af fejlrapporterne fra 2260 Sound Intensity projektet har vist, at netop de typer fejl som disse fire teknikker skulle have forebygget, fortsat optræder meget hyppigt, mens de typer af fejl som scenarier og usability test skulle have forebygget ikke synes at optræde længere.

Analysen af fejlrapporterne tyder altså på, at de anvendte teknikker er effektive, og at der kan opnås yderligere forbedringer ved at indføre de resterende teknikker.

5. Anden del af projektet

Efter afslutningen af første del af projektet opstod der interesse og behov for spredning af de samme teknikker til andre projekter hos Brüel & Kjær. Samtidig var Jan Pries-Heje startet hos DELTA, således at det var muligt at fortsætte projektet som en del af ”Center for softwareprocesforbedring” (se kapitel 1), som både DELTA og Brüel & Kjær deltager i.

Konkret kom fire projekter til at deltage i anden del af projektet:1. Noise Source Identification projektet (NSI), der skulle udvikle en applikation til PULSE-platformen, som

viser lydudstrålingen fra en overflade. Version 1 af NSI var planlagt at skulle udvikles i Korea, mens version 2 (som dette projekt skulle følge) skulle udvikles hos B&K i Nærum.

2. NEXUS-projektet, der skulle udvikle remote software til styring af en signal-konditionerings-forstærker, f.eks. til brug i fly- og bil-industrien.

3. MODAL-projektet, der også skulle udvikle en applikation til PULSE-platformen, som foretager måling og beregning af vibrationsmønstre.

4. GYRO-projektet, der skulle udvikle et system til post mortem analyser på maskinovervågningssystemer. Dette projekt var ikke med i den oprindelige plan for spredning af kravspecifikationsaktiviteterne, men udtrykte undervejs stærkt behov for at bruge teknikkerne som et led i deres forbedringsprojekt om udviklingsmodeller [Vinter og Nørbjerg 1999].

I denne del af projektet fungerede vi som støttegruppe for projekterne. Vi stod for træning, indførelse, hjælp (mentoring) og opfølgning på anvendelsen af teknikkerne.

5.1 Workshop i maj 1998

Som start på de tre første projekters arbejde afholdtes en workshop den 19. maj om formiddagen og den 20. maj hele dagen. I forhold til den første afholdelse af en workshop under PRIDE projektet, var flere teknikker skåret fra, så fokus alene var på scenarier, prototyping og usability test. Ydermere havde vi nærmest fjernet muligheden for at lave funktionelle prototyper, dels ved at fokusere meget på de simplere tidlige prototyper, dels ved at fortælle – med udgangspunkt i 2260 Sound Intensity projektet – hvor lidt ekstra man kunne opnå med denne type prototype.


På basis af evalueringerne fra første del af projektet havde vi også gjort en del mere ud af scenarier. Vi gik i detaljer med flowet fra scenarier, over arbejdsopgaver til krav. Og vi havde en række konkrete eksempler med fra projektets første del. Endelig havde vi afsat mere tid til at deltagerne kunne skrive et scenarie og få feedback.

Formålet med workshoppen var at give medarbejderne i de tre projekter – NSI, NEXUS og MODAL - den fornødne træning så de kunne bruge teknikkerne. Indholdet af kursusmappen, der blev gennemgået på workshoppen, er vist neden for, idet punkterne 1-3 gennemførtes den første (halve) dag.

1. Hvad er Usability (brugervenlighed): Logisk og fysisk design2. Protototyping3. Designøvelse: Lav en papirmodel af jeres produkt4. Afprøvningsmetoder (usability test)5. Øvelse i Usability test6. Erfaringer med Usability Test hos Brüel & Kjær7. Eksempler fra Usability Test hos Brüel & Kjær8. Scenarier og arbejdsopgaver9. Øvelse i scenarier og arbejdsopgaver10. Erfaringer med scenarier hos Brüel & Kjær11. Eksempler på scenarier fra Brüel & Kjær

6. Evalueringer af anden del af projektet

En eksakt (kvantitativ) måling af effekten af brugen af de valgte teknikker kan ikke finde sted før projekterne er færdige og tilbagemeldinger fra markedet er begyndt at komme ind. På basis af de gode erfaringer fra første del af projektet besluttede vi derfor at mødes med projekterne regelmæssigt under kravspecifikationsprocessen. Vi tilbød ikke blot at høre om, hvad de kunne berette om brugen af teknikkerne, men også at hjælpe med at anvende teknikkerne bedst muligt – altså som støttegruppe (mentor).

Den agenda vi anvendte på alle møderne så således ud:

1. Status på udviklingsprojektet og planlagte aktiviteter i den nærmeste tid2. Erfaringer, problemer og succes’er med teknikkerne3. Områder eller emner hvor der er brug for støtte4. Planlægning af næste møde

Der blev sat 1½ time af til mødet med hvert projekt, men det viste sig undervejs, at 2 timer var nødvendigt. Møderne med alle tre projekter blev afholdt på samme dag.

Vi har valgt at referere forløbet detaljeret for at give indtryk af hvilke situationer der opstår i forbindelse med kravspecifikationsarbejdet på et projekt – både i relation til anvendelsen af de nye teknikkerne som andre generelle faktorer.

6.1 Første møde med projekterne, den 16. juni 1998

NSI De var ikke rigtig kommet i gang med at bruge teknikkerne. De ventede på at en første demo-prototype af version 1 kom fra Korea.

NEXUSDe var godt i gang med at bruge teknikkerne. De planlagde at lave tre prototyper, og de arbejdede med fire kategorier af scenarier.


MODALDe havde besluttet sig for at anvende S&Vs nye cykliske udviklingsmodel [Vinter, 1999] med fire iterationer, hvor der i den første iteration indgik både scenarier og usability test af en papir mock-up model af brugergrænsefladen. De savnede materiale om hvordan man gennemfører interviews, idet de ikke følt de kunne skrive scenarier uden at have haft direkte kontakt med potentielle brugere.

6.2 Andet møde med projekterne, den 3. august 1998

NSIMødet blev aflyst, idet NSI fortsat ikke var kommet i gang.

NEXUSDe havde delt arbejdet op. To havde arbejdet på en prototype, lavet på en PC så al navigering virkede. Denne prototype var blevet usability testet med en intern bruger (B&K udvikler). På basis af testen var en del blevet lavet om. Prototypen var ikke blevet valideret med scenarier. De blev kraftigt opfordret til at dette skete.To andre i NEXUS-projektet havde arbejdet med scenarier. De havde defineret 5 scenarier, hvor de går lidt mere i dybden. De to første scenarier var blevet lavet før prototypen. De andre scenarier var blevet lavet parallelt med udviklingen af prototypen.

MODALStatus var at tre scenarier var (næsten) færdige, og to scenarier navngivet, som der skal arbejdes på. Scenarie templaten fra workshoppen er justeret og vejledning indlagt (se Bilag 1). For at skabe overblik har de lavet en ”scenarie-matrix”, med 5 markedsområder på den ene akse, og seks typer funktionalitet (”application”) på den anden. Scenarierne blev plottet ind i denne matrix for at give overblik over hvad projektet har dækket. Lige nu mangler et punkt på markedssiden, samt to punkter på den anden led. De forventer 2-3 scenarier mere, så der bliver noget i alle rækker og kolonner i matricen. Task listen for de 5 scenarier er vokset kraftigt, der var nu 50 tasks tilsammen (baseret på antal verber i scenarierne).Der er gennemført en række interviews af konsulenter (2) og kunder (1).Papirmodellen som blev initieret på workshoppen blev stadig videreudviklet. Status er nu, at der findes en mappe med konkrete men generelle skærmbilleder. Scenarierne er prøvet af på papirmodellen og der er fundet en hel del mangler. Papirprototypen menes ikke at være konkret nok til en usability test, hvor man skal løse en konkret opgave. Det vil kræve nogle skærmbilleder med konkrete data.Alt i alt er der fire bolde i luften: Scenarier, Task list, besøg hos kunder, samt papirmodel. Gruppen har delt sig op i to der starter programmering på navigations-prototypen, og to der fortsætter med papir-prototypen.

6.3 Tredje møde med projekterne, den 1. september 1998

NSIDe havde modtaget noget fra Korea, men det var ikke særligt godt. To projektdeltagere var derefter taget derover for at gennemgå applikationen. Det viste sig, at samarbejdet kom meget bedre igang, da man begyndte at lave en papirmodel sammen. Der blev også lavet to scenarier. Papirprototypen blev testet af to interne B&K personer (udviklere) i Danmark. Resultaterne blev returneret til koreanerne, men det var åbenbart ikke muligt at videregive usability test resultater skriftligt til dem. Ideen med at få version 1 ud hurtigt vhja. koreanerne er nu opgivet. I stedet inviteres nogle af dem til Danmark for at gennemføre en regulær kravspecifikationsproces med scenarier og udability tests. Samtidig vurderes om det er muligt at ”portere” et tidligere produkt (7681 – NSL) som erstatning.Der er nu skitseret 6 scenarier. Vi anbefalede projektet at gå ud og interviewe kunder der har købt det tidligere produkt.

NEXUS Scenarier er skrevet, men mangler stadig at blive reviewet internt. Der var ikke udført flere usability tests i perioden. Det var som om det stod lidt stille for tiden. Prototypen er opdateret efter den første test. Der synes også at være visse uoverensstemmelser mellem scenarierne og prototypen, fordi de to ting har været kørt parallelt. Vi anbefalede, at man laver en intern gennemgang af scenarierne vhja. prototypen.


MODALScenarierne er nu kategoriseret i 3 typer. Der er lavet papirmodel for en del af dem. Der er lavet 3 usability tests; den første blev dog ikke gennemført formelt. En af nærværende rapports forfattere deltog i den tredje, som proceskonsulent (mentor), og gav bagefter feed-back til testlederen. Der blev fundet mange problemer og ca. 5 ”katastrofer” (forstået som situationer hvor testbrugeren måtte opgive at komme videre). Der har nu været arbejdet på papirmodellen i ca. 1 måned. Der arbejdes også på en mere omfattende funktionel prototype.Der har været brugt megen tid på at diskutere med andre projektgrupper om standardisering af brugergrænsefladekomponenter. I forbindelse hermed har det været en fordel at kunne referere til de gennemførte usability tests. Skærmbilleder har været hængt op på væggen, så man kunne sammenligne. Et fælles design er nu på vej.

6.4 Fjerde møde med projekterne, den 17. september 1998

NSIMødet med NSI-projektet blev aflyst da der intet nyt var at berette. Koreanerne er kommet til Nærum. Der bliver holdt workshop (på engelsk) for dem i næste uge.

NEXUSStatus var, at der er gennemført to interne usability tests. De blev ikke gennemført formelt, men der blev fundet mange ting alligevel. Prototypen er herefter blevet opdateret.En ekstern usability test er blevet gennemført med delopgaver fra scenarier. Kunden vurderede prototypen som meget gennemtænkt og professionelt udført. Megen værdifuld information til scenarierne blev fundet gennem testen og snakken med kunden. Der blev ikke fundet ”katastrofer” under testen hos kunden.De opererer med en ny kategori af ”fejl” under usability tests: Positiv reaktion (dvs. noget som skal bevares).Krav, status m.v. skal diskuteres, og der skal ses på scenarierne igen. Noget af den funktionalitet der kræves af scenarierne er ikke implementeret i prototypen.

MODALDer var lidt utilfredshed med, at vi holdt møde med dem igen så hurtigt. Det meste af tiden var gået med at understøtte det internationale salgsmøde (PA98). Kun to emner er endnu ikke blevet usability testet internt. Der arbejdes videre på den funktionelle prototype til brug for de eksterne usability tests.

6.5 Femte møde med projekterne, den 19. oktober 1998

NSIAlle personer fra NSI-projektet deltog, også koreanere. To af de oprindelige projektdeltagere er nu sat på at forsøge en portning af det tidligere produkt (NSL), så der kan frigive noget hurtigt. Den 24. - 25. september 1998 gennemførte den ene af nærværende rapports forfattere en to-dages workshop på engelsk for koreanerne og de projektdeltagere som ikke havde deltaget i workshoppen i maj. Denne to-dages workshop syntes at have den rette længde. Workshoppens indhold var følgende, idet punkterne 1-5 gennemførtes den første dag:

1. The PRIDE background2. Scenarios and tasks3. Group work on scenarios and tasks4. Prototyping5. Group work: Design a paper mock-up6. Usability testing techniques7. Group work: Perform a usability test8. Experiences from practical use of the techniques

Der er nu skrevet 12 scenarier, heraf 3 kun i skitse form. De skal reviewes af gruppen. Der arbejdes på nedbrydning i opgaver (tasks).En navigerbar prototype blev lavet på en uge af 4 personer. Den blev bygget i Delphi. Der vil blive afholdt 3 interne usability tests. I november/december vil der blive gennemført 3 usability test med kunder.


NEXUSScenarierne er nu samlet i et dokument. Task nedbrydningen er påbegyndt, systemafgrænsningen skitseret og der bygges videre via UML til design. De har udvidet templaten for scenarier med et afsnit om: Errors and Exceptions (se Bilag 1). Prototypen gøres færdig i en aktivitet fra slutningen af november. Scenarierne er checket op mod kravspecifikationen.Der er planlagt 2 runder usability tests internt á 2 personer og endnu 1 eksternt. Disse finder sted i midten af december og evt. starten af januar.Accepttest planlægges på scenarieniveau.

MODALHele projektholdet har været på studietur hos en kunde, hvor en konsulent demonstrerede, hvordan målingerne blev sat op og gennemført. Masser af viden om opgaven set fra brugerens situation blev derved opnået. Feks. stod det efter turen klart at 98% af arbejdet består i opsætning og kontrol af måleopstillingen. Målingen selv er en ”detalje”. Projektholdet vil derfor flytte vægten fra målestituationen til opsætningen, hvilket er en helt ny vinkel for projektet (og B&K).Der er blevet afholdt 1 usability tests hos en kunde, men da dele af den funktionelle prototype ikke var stabil nok, blev det en meget ”håndholdt” test. Alligevel bekræftede testen, at de var på rette vej. Kunden viste stor begejstring for det produkt, de var ved at lave.Der er blevet afholdt en anden usability test med en ekstern konsulent, hvor en blanding af papir og funktionel prototype blev anvendt. Det fungerede tilsyneladende udmærket.Der har ikke været tid til at dokumentere resultaterne af usability testen. De er blevet kommunikeret direkte til udviklerne mundtligt, som så medtager dem i prototypen. Der har været så mange ændringer, at det har været svært at følge med i udviklingen af prototypen. De fleste er også ved at tabe overblikket over prototypen.Der er planlagt endnu en intern usability test, og en usability test med en kunde om en 2 ugers tid. De afventer, at prototypen bliver tilstrækkelig stabil.Skrivning af kravspecifikationsdokumentet er påbegyndt. B&Ks standard for dokumentet følges.

6.6 Det videre forløb på projekterne indtil afslutningen af kravspecifikationsfaserne

Der blev ikke afholdt flere formelle statusmøder med projekterne i perioden november 1998 til januar 1999, så forløbet nedenfor er refereret på basis af uformelle samtaler.

NSIStor succes med usability tests med 3 kunder i Nordamerika og 3 i Tyskland. Det var en bekræftelse på, at de var på rette vej. En kunde som havde returneres det tidligere produkt (NSL) som ubrugeligt, erklærede, at denne prototype dækkede hans behov fuldstændigt. Kravspecifikationen blev udsendt til review i januar 1999. Scenarierne inkl. markeds/applikationsmatrix var inkluderet i et appendix. Produktet blev opdelt i 2 versioner. Portning af NSL blev opgivet som umuligt. I stedet var det planen at lade koreanerne lave version 1 af produktet i Nærum.

NEXUSPgra. opsigelse, fratræden og langtidssygdom blev det ikke muligt at afholde de planlagte usability tests. I stedet koncentrerede de sig om at arbejde med skrivning af kravspecifikations- og designdokumenter. Prototypen blev dog opdateret og har siden tjent som referenceramme for betjeningsprincipperne. Kravspecifikationen blev udsendt til review i december 1998. De to vigtigste scenarier er inkluderet i et separat kapitel. Projektet blev opdelt i 2 versioner. Situationen om gennemførelsen af projektet var imidlertid meget uafklaret pgra. bemandingsproblemerne. Selv version 1 kunne ikke bemandes rimeligt.

MODALFlere interne usability tests og den planlagte usability test med en kunde blev gennemført på den funktionelle prototype, uden at det gav anledning til særlige bemærkninger. Kravspecifikationen blev udsendt til review i december. Scenarierne var inkluderet i separate kapitler. En demonstrationsprototype jf. S&Vs udviklingsmodel [Vinter, 1999] planlægges til februar 1999 til fremvisning på en international udstilling.


6.7 Forløbet på Gyro-projektet

I forbindelse med en anden forbedringsaktivitet om udarbejdelse af en ny udviklingsmodel for Brüel & Kjær CMS [Vinter og Nørbjerg 1999] gennemførte den ene af forfatterne til denne rapport træning af en del af udviklerne på GYRO-projektet i kravspecifikationsteknikkerne fulgt op af støtte i den første brug af teknikkerne.

GYRO-projektet havde egentlig allerede en udarbejdet og godkendt kravspecifikation, men som led i udviklingen af en prototype af brugergrænsefladen i en 7 ugers timebox4 ønskede gruppen at inddrage scenarier og usability tests. Workshoppen blev afholdt på 1 dag (18. september), med en variant af workshop indholdet fra maj, idet gruppen allerede havde lavet en navigerbar prototype:

1. PRIDE baggrunden 2. Scenarier og tasks3. Gruppearbejde om GYRO scenarier og tasks4. Usability tests5. Gruppearbejde: Gennemfør en usability test6. Erfaringer fra praktisk brug af teknikkerne

Reaktionen på workshoppen var endnu endnu en gang, at tiden var for kort, selv om der forelå en prototype, der kunne bruges. Herefter optrådte den ene af forfatterne til denne rapport som proceskonsulent (mentor) under de første 2 interne og 2 eksterne usability tests. Dvs. observerede, hvorledes testleder og logfører gennemførte deres opgave, og gav dem umiddelbar feed-back efter testene. Denne støtte blev opfattet som særdeles værdifuld af gruppen.

I løbet af de følgende 5 uger udarbejdedes 3 scenarier (1 dog kun på skitseform), og ialt 15 usability tests (heraf 6 med kunder og 6 med agenter/sælgere) blev gennemført! Årsagen til at det lykkedes at gennemføre så mange usability tests endog med kunder, var at projektlederen fastlagde testdatoerne med kunderne fra en start med ”is i maven” mht. færdiggørelsesgraden af den prototype man kunne nå at lave.

Det var klart holdets vurdering at teknikkerne burde have være anvendt før kravspecifikationen blev skrevet. De mente, at projektets mål og prioriteringen af de enkelte krav kom til at stå meget klarere for alle, uden at der kom nye krav til kravspecifikationsdokumentet. Dem der var blev blot præciseret og prioriteret. Resultatet af timeboxen fik umiddelbar betydning for planlægningen af det efterfølgende projektforløb (timeboxe).

6.8 Det videre forløb af projekterne

Der er ikke blevet holdt formelle statusmøder med projekterne efter kravspecifikationsfasens afslutning. Det følgende forløb er refereret på basis af uformelle samtaler. Da de resterende projekter afsluttes nogenlunde samtidigt med Centerkontrakten, vil der heller ikke blive mulighed for at afholde afsluttende interviews med projektdeltagerne om teknikkernes indflydelse på forløbet og kvaliteten af de resulterende produkter.

NSIProjektet blev udskudt umiddelbart efter kravspecifikationsfasen og ressourcerne overført til NEXUS-projektet for at klare bemandingsproblemerne der. Koreanerne blev sendt hjem. En version af NSI dækkende den vigtigste del (ca. 1/5) af funktionaliteten blev i løbet af foråret 1999 gennemført som et ”skuffeprojekt” af den tilknyttede marketing person. Han fandt et produkt (Matlab) som gav ham mulighed for at lave de nødvendige beregninger og opbygge en brugergrænseflade med simple midler. Hans projekt blev gjort officielt, og ved frigivelsen i starten af september, erklærede han, at det ikke havde været muligt for ham at lave produktet så gennemtænkt uden det forudgående arbejde med scenarier og usability tests.

4 I [Vinter og Nørbjerg 1999] defineres timeboxe som afgrænsede tidsforløb på ca. 6 uger, hvor en gruppe på op til 5 udviklere frembringer et resultat iht. en prioriteret opgaveliste og et succeskriterie.


NEXUSUmiddelbart efter godkendelsen af kravspecifikationen blev det besluttet at udskyde NSI-projektet og overføre bemandingen til NEXUS-projektet. Version 1 påbegyndtes, men der opstod hurtigt spændinger mellem de to projektkulturer. Endnu en person fratrådte, og en anden af de oprindelige NEXUS-medarbejdere flyttede til et andet projekt. Det er således NSI-personer, som idag bemander NEXUS-projektet. Ingen af disse har et personligt forhold til (erfaring med) de oprindelige scenarier og prototypen, men er naturligvis trænet i teknikkerne fra deres tid på NSI. De to hovedscenarier og prototypen fungerer stadig som reference for det arbejde, der udføres under implementeringen af produktet. Frigivelsen er planlagt til slutningen af 1999. Årsagen til forsinkelsen er ikke projektkompleksiteten, men den permanente udskiftning af ressourcer.

MODALDemonstrationsprototypen på udstillingen i februar var en stor succes hos kunder og sælgere. Scenarierne havde givet den rette fokusering/prioritering på opsætningssituationen frem for måling. Selve prototypen var meget primitivt opbygget (“hacket sammen”), men det blev ikke bemærket. Siden er der arbejdet på at udvikle produktet på regulær vis. Det havde bla. den effekt, at en udgave af produktet til en udstilling i juni umiddelbart var en skuffelse for sælgerne, fordi “der jo ingenting var sket”. Imidlertid var produktets brugervenlighed så tydelig, at de kunne betjene det uden forudgående træning. Kundereaktionerne var stadig meget positive.Produktet har i dag stadig en forbløffende lighed med det, der blev arbejdet med under kravspecifikationsfasen. Ændringerne er sket på detailniveauet, som ikke var dækket af de første prototyper (og netop ikke skal dækkes). Kravlisten fra kravspecifikationen er så stabil, at den bruges som checkliste for fremdriften på projektet, hvilket ikke er normalt på B&K. Demoprototyperne undervejs har naturligvis været fulde af nødløsninger, men når den endelige implementation blev udviklet, vendes tilbage til de oprindelige tanker fra scenarierne og de tidlige prototyper.Produktet var efter kravspecifikationsfasens godkendelse planlagt til frigivelse i september 1999. Pgra. omprioriteringer mellem projekterne på B&K er frigivelsen nu sat til december 1999.

GYRO Som beskrevet i forbedringsrapporten [Vinter og Nørbjerg 1999] blev projektet lukket i løbet af foråret 1999, fordi ledelsen i CMS ønskede en samling af produktudviklingen omkring en enkelt platform udviklet af den tyske partner. Kravspecifikationsteknikkerne vil dog indgå i fremtidige produkter, som udvikles af CMS i Nærum.

6.9 Spredning og optagelse af teknikkerne

I løbet af vinteren og foråret 1999 indgik den ene af forfatterne til denne rapport i et samarbejde med B&Ks centrale kvalitetsafdeling for at få den software udviklingsmodel [Vinter, 1999], der blev arbejdet med i tre projekter (herunder MODAL og NEXUS), dokumenteret iht. B&Ks ISO 9001 kvalitetsstyringssystem.

De kravspecifikationsteknikker, der er arbejdet med i nærværende forbedringsaktivitet, indgår centralt i software udviklingsmodellens specifikationsfase, hvor kravene fastlægges. Teknikkerne og deres korrekte brug er blevet beskrevet på ISO procedureform og indgår fremover som den måde, alle software projekter skal udføre specifikationsfasen på i Brüel & Kjær S&V. Erfaringerne fra nærværende aktivitet er naturligvis indgået i beskrivelsen.

Den mest effektive form for spredning af brugen af teknikkerne er dog den konstante reklame, som de projekter der har anvendt teknikkerne giver. Projektlederne undlader ikke nogen lejlighed til at fremhæve de positive erfaringer, de har haft med teknikkerne. Dette har vi fået dokumenteret gennem de interviews forskergruppen har gennemført med projektlederne, som afslutningsevaluering af Centerkontrakten. Da netværket mellem projektlederne er meget tæt, betyder det at teknikkerne automatisk efterspørges ved opstart af nye projekter. Dog udtrykte alle bekymring over at det tog så langt tid at anvende teknikkkerne.

Kravspecifikationsteknikkerne scenarier og usability tests er ikke begrænset til anvendelse på software projekter.


Derfor er der i forlængelse af dokumentationen af kravspecifikationsteknikkernes brug på software projekter arbejde igang med at gøre denne måde at lave specifikationer på til et krav for alle projekter i S&V (elektronik, mekanik, transducere), dvs. at opdatere den generelle udviklingsmodel i kvalitetsstyringssystemet med en lignende beskrivelse.

Et eksempel på at teknikkerne allerede tidligt spredtes til denne gruppe af projekter har vi set på et mekanikprojekt: 4606 Handset Positioner for HATS (Head and Torso Simulator). Projektgruppen havde i foråret 1998 hørt en præsentation om resultaterne af PRIDE. Projektgruppen følte at det væsentligste succeskriterie for produktet var, at det opfyldte brugerne behov meget nøje, herunder at det var særdeles brugervenligt. Det skulle kunne bruges at almindelige teknikere, og samtidig være så præcist at det kunne bruges til certificering af telefoner (handsets).

I oktober 1998 gennemførte projektgruppen selvstændigt 7 usability tests af en prototype, opbygget på basis af sparsomt brugerinput samt projektgruppens egen forestilling om hvordan produktet skulle udformes. Fire af testene var med udvalgte interne B&K personer, 1 med en sælger og 2 med potentielle kunder. Testene foregik på B&K over to dage. Hver test varede ca. en halv time, og gik ud på (scenariet) at forsøgspersonen skulle montere en mobiltelefon (handset) korrekt i en holder (cradle) og derefter montere og positionere holderen med telefon i en fikstur på HATS, så den var klar til måling/afprøvning. Testene blev optaget på video. En person fra projektgruppen agerede forsøgsleder, to andre holdt sig i baggrunden som logfører og observatør.

Projektholdet gennemgik videoen og registrerede hvilke ting der var ”gået galt” for forsøgspersonerne. Vi fik lejlighed til at låne videoen, gennemgik den, og kom med såvel produktmæssige som procesmæssige observationer. Projektholdet fremstillede derpå en ny prototype, som de tog med til fornyet usability test hos andre kundeemner. Disse tests bekræftede at projektholdet var på rette vej med produktet.

Produktet blev frigivet i september 1999, og der var på det tidspunkt allerede en meget større ordrebeholdning end planlagt. Ydermere har produktets præcise opbygning gjort det til udgangspunkt for fremtidig standardisering af telefonmålinger. Det vil uden tvivl øge interessen og dermed salget af produktet til et niveau, der slet ikke var planlagt med oprindeligt.

6.10 Analyse og konklusion på anden del af projektet

I slutningen af november 1998 – samtidig med afslutningen af kravspecifikationsfaserne for de tre oprindelige projekter - gennemførtes en runde interviews i lighed med den evalueringsrunde, der fandt sted efter første del af forbedringsprojektet. Den samme spørgeguide blev anvendt.

Vi interviewede to af udviklerne fra NEXUS-projektet, én af udviklerne fra MODAL-projektet. Endvidere interviewede vi en applikationsekspert der havde været usability testperson på MODAL-projektet. Endelig interviewede vi en intern usability testperson fra NSI-projektet og en fra NEXUS-projektet.

I starten af januar 1999 interviewede vi tillige fire personer fra Gyro-projektet.

Otto Vinter var igen interviewer mens Jan Pries-Heje tog notater og skrev referat. Hvert interview varede i gennemsnit ca. 45 minutter.

Vi besluttede derefter ikke at lave en separat analyse og konklusion på andel del af forbedringsprojektet. Vi ønskede i stedet at udarbejde en samlet konklusion på anvendelsen af kravspecifikationsteknikkerne.

I foråret 1999 samlede vi de mange møde- og interviewreferater fra begge dele af projektet og analyserede dem i sammenhæng. Alt blev læst igennem og de vigtigste observationer noteret. Notaterne blev herefter grupperet og hver gruppe af observationer fik en samlende beskrivelse hæftet på sig. At grupperne var konsistente blev checket ved at gå referaterne igennem endnu en gang. Forskningsmetodemæssigt anvendte vi med andre ord igen det der kaldes sekventiel analyse af en case [Miles & Huberman 1994].

Vores resultater af denne samlede analyse, og de konklusioner vi kan drage fra anvendelsen af scenarier og usability tests på meget tidlige prototyper, er beskrevet i kapitel 7.


7. Resultater med scenarier og usability tests

Erfaringerne med anvendelse af Scenarie og Usability test teknikkerne på tidlige prototyper fører til følgende hovedpointe:

Scenarier og usability tests er effektive teknikker til at skabe bedre produkter, dels fordi de identificerer de rigtige behov, dels fordi de muliggør bedre videnoverførsel fra kunden til udviklingsprojektet, og endelig fordi de skaber bedre samspil internt i udviklingsprojektet under udviklingsforløbet.

Scenarie og Usability test teknikkerne er beskrevet i bilag 3. Som tidligere nævnt anvender vi ordet brugssituationer synonymt med scenarier. I det følgende vil vi underbygge de understregede udsagn i hovedpointen.

7.1 Identificere de rigtige behov

Mange projekthold bliver bedt om at lave produkter baseret på en behovsopfattelse andre har udtænkt på forhånd. Disse behov er ikke nødvendigvis kundens eller dennes slutbrugers behov; eller muligvis er deres egentlige behov ikke blevet udtrykt tydeligt nok. Det kan være udtryk for en helt anden opfattelse af, hvad der er vigtigt i den praktiske brugssituation. Teknikkerne har vist sig at afhjælpe dette problem, som beskrevet nedenfor.

7.1.1 Udviklerne kommer i forbindelse med kunder og brugere

Anvendelsen af Scenarie teknikken på et projekt betyder at flere af udviklerne kommer i forbindelse med rigtige (potentielle) kunder og lærer derigennem ved direkte observation, hvad brugerens reelle og øjeblikkelige behov er. Herfra kan udviklerne mere kvalificeret forudsige løsninger og fremtidige behov.

7.1.2 Nedskrivning af brugssituationer dokumenterer behovene

Når brugernes behov indhentes, dokumenteres de ofte på huskesedler eller i mødenoter, som andre kan have svært ved at forholde sig til på et senere tidspunkt. Ved i stedet at skrive dem som levende brugssituationer skaber de billeder i hovedet hos læseren, som ideelt kommer tæt på at føle at være tilstede selv. Beskrivelserne af brugssituationerne rejser nye spørgsmål (hvorfor), skaber associationer (hvorfor ikke), og er dermed hele tiden en levende dokumentation af behovene.

7.1.3 Behovene valideres gennem usability tests på tidlige prototyper

Beskrivelser af brugsituationer er per definition ikke udtømmende, de skal jo netop være korte og skabe mange billeder. For at sikre at de behov der kommer til udtryk gennem disse beskrivelser ikke blot er andre slags fantasier om brugerens behov, udarbejdes meget tidlige prototyper, og der gennemføres usability tests på disse.

Erfaringen viser, at der er behov for flere iterationer på scenarier og prototyper som resultat af usability tests. De første iterationer foretages med interne personer (udviklere, applikationsspecialister og marketing). I disse iterationer bliver store dele af prototypen skrottet, fordi den gengiver brugssituationen alt for ”teoretisk”. Når prototyperne har stabiliseret sig internt, kan man begynde den første iteration med rigtige brugere. Der bør gennemføres 3 iterationer med 3 usability tests i hver, dvs. at der må planlægges med at involvere 9 brugere.

7.1.4 Valideringen gennem usability tests giver en bedre prioritering af behovene

Kravspecifikationer udformet efter de sædvanlige retningslinjer har vist sig at resultere i en dårlig/uklar prioritering af kravene. Gennem skrivningen af scenarier og gennemførelsen af usability tests opnår alle en klar


og ensartet opfattelse af hvilke behov der er vigtigere end andre. Denne fælles opfattelse fører til at de mindst betydende krav kan fravælges, hvis (når) tidsplanen strammer til.

7.2 Bedre videnoverførsel fra kunde/bruger til projekt

Mange projekthold besidder en alt for ringe viden om anvendelsesdomænet for det produkt der udvikles. Især for nye udviklere er det et problem at de med deres tekniske baggrund skal forsøge at forstå en anvendelsesproblemstilling der er dem ukendt. Den manglende domæneviden fører til mange misforståelser mellem kunde/bruger og udvikler; og får ikke fremprovokeret den tavse (underforståede) viden. Teknikkerne har vist sig effektive til at afhjælpe dette problem.

7.2.1 Udviklerne skal selv skrive scenarier og gennemføre usability tests

Den manglende domæneviden hos udviklerne kan ikke afhjælpes ved blot at lave mere papirdokumentation. Dette gælder også, hvis en kunde/bruger sættes til at skrive scenarier. Alt for megen tavs viden vil forblive tavs og indforstået. Udviklerne må selv lære kundernes/brugernes verden at kende. Ved at lade udviklerne skrive scenariene, sikrer man sig, at de er vidende om kundens/brugerens behov. Ikke alle udviklere er lige gode til at skrive denne type dokumenter, men alle skal som minimum involveres i den videnindsamling der foregår inden scenarierne kan skrives.

Med en tilsvarende argumentation er det klart, at udviklerne selv må gennemføre usability tests. Normalt anbefaler Usability test teknikken, at der bruges professionelle personer (psykologer) som testledere. Da vi imidlertid kun er interesseret i at finde bekræftelse/afkræftelse af vores opfattelse af brugerens behov, betyder det videnmæssige samspil mellem bruger og testleder mere end det adfærdsmæssige. En testleder, som har nogen viden inden for brugssituationens domæne, kan i højere grad fremprovokere ny (tavs) viden fra brugeren under en usability test.

Rollen som testleder er dog så kritisk, at udvælgelsen af denne blandt udviklerne skal overvejes (afprøves) meget nøje. Alle øvrige udviklere skal mindst en gang deltage som logfører i en usability test for at sikre, at de får tilstrækkelig indsigt i de problemer en bruger løber ind i undervejs med prototypen, og derfor bliver i stand til at forstå (acceptere) problemer, der rapporteres i usability tests, de ikke selv har deltaget i.

7.2.2 ”Tænke højt” princippet under usability tests afslører det brede spektrum af domæneviden

Der er meget stor forskel på at lade brugeren gennemføre en vejledt demonstration af prototypen, og en egentlig usability test. Kun ved at sikre at brugeren kan komme til at udtrykke sine overvejelser, problemer og beslutninger under løsningen af den stillede opgave, kan udviklerne lære de bagvedliggende årsager til brugerens behov. Derved opnår de den tilstrækkelige viden til at kunne løse opgaven.

Scenarie og Usability test teknikkerne er velegnede til at gøre brugerens skjulte (tavse) viden synlig og få brugeren tll at erkende sine behov.

7.3 Bedre samspil i udviklingsprojektet internt

Som beskrevet ovenfor sikrer Scenarie og Usability test teknikkerne, at vi får overført viden til projektholdet. Men brugen af teknikkerne viser sig også at have effekt senere i udviklingsforløbet som en fælles referenceramme for implementeringsarbejdet.

7.3.1 Fælles sprog og fælles forståelse

Netop fordi det er udviklerne selv, der har stået for udformningen af scenarier og usability tests, er der opstået en fælles videnbasis om opgaven. Det skaber en højere grad af fælles forståelse, når problemer under udviklingen skal løses. Diskussioner om brugerbehov og deres løsning finder meget hurtigere en afklaring, fordi der kan henvises til konkrete brugssituationer enten i et scenarie eller under en usability test.


7.3.2 Bedre udnyttelse af interne eksperter

De domæneeksperter, som findes i organisationen, kan udnyttes mere effektivt. Det drejer sig om applikationseksperter, marketingfolk og sælgere. Dels er de en kilde til initiel forståelse af området. Dels vil det ofte være dem, der har kontakterne til konkrete kunder/brugere, som kan bruges til videnindsamling og usability tests. Endelig vil de være de bedste til at gennemføre de første usability tests på en ny prototype. På denne måde inddrages de, før der bliver taget egentlige og potentielt "katastrofale" løsningsbeslutninger.

7.3.3 Oplæring af nye medarbejdere

Alle projekter forudser øget bemanding undervejs. Nye projektdeltagere har normalt svært ved at trænge ind i opgaven og bliver derfor ikke så effektive som dem, der er startet tidligere. Ved at lade dem læse scenarierne og agere ”bruger i en usability test” på prototypen opnår de en meget hurtigere og sikrere indføring i domænet og det produkt, de skal lave. Det er dog klart, at den dybe indsigt i opgaven kun kan opnås ved at være med fra starten. Derfor bør man planlægge udviklingsprojektets bemanding så flest mulige af udviklerne er med fra starten. Denne ressourcestrategi kan lade sig gøre uden omkostninger (spild), fordi der er behov for flere implementationsressourcer allerede i kravspecifikationsfasen til at bygge prototyper til usability tests.

7.3.4 Forbedret salgs/markedsføringsdokumentation og test

Den viden der opnås gennem skrivning af scenarier kan ikke blot udnyttes til at sikre, at de rette krav til projektet bliver fundet og dokumenteret. Brugsbeskrivelserne afslører samtidig alle de væsentlige ”selling points” for produktet, som derfor direkte kan anvendes i planlægning og skrivning af salgs- og markedsføringslitteraturen. I modsætning til mange andre projekter, hvor kravene flytter sig undervejs, fordi de ikke er rodfæstet i de egentlige behov, kan litteraturfolkene kobles på projektet tidligere, og markedsføringen derfor påbegyndes før normalt.

Tilsvarende er scenarierne udgangspunkt for en bedre planlægning af tests. Kunden/brugeren kan lave accepttests direkte baseret på sine brugssituationer. Da Scenarie teknikken bygger på, at beskrivelserne skal skabe levende billeder hos læseren, bliver det lettere for testplanlæggerne at finde på relevante testsituationer (data). Tilsvarende kan scenarier understøtte udarbejdelsen af andre typer tests i projektet. Feks. når den enkelte projektdeltager skal teste et modul, kan scenarierne danne udgangspunkt for realistiske testsituationer for modulets ”white-box” tests.

7.4 Teknikkerne er effektive

Det er velkendt, at de dyreste problemer, er dem der opstår tidligst i udviklingsforløbet. Derfor findes der mange metoder/teknikker, som hævder, at de er effektive til at understøtte udviklingsprocessen i netop de tidlige faser. Scenarie og Usability test teknikkerne på tidlige prototyper har vist, at de kan leve op til forventningerne i praksis. Men der er også rejst en række kritikpunkter mod teknikkerne. Vi vil præcisere dette i det følgende.

7.4.1 Teknikkerne medfører ikke flere krav kun en øget detaljering

Vi har ofte mødt det argument, at anvendelse af Scenarie og Usability test teknikkerne giver udviklerne et så bredt kendskab til den totale verden brugeren befinder sig i, så de kommer til at inkludere for mange (ekstra) krav, hvorved produktet fordyres og forsinkes.

Praksis viser imidlertid, at det ikke er tilfældet. Der sker ikke en udvidelse af de basale krav, som var udgangspunktet for at starte arbejdet. Der sker derimod en kraftig øgning af viden om konsekvenserne af kravene, hvilket kommer til udtryk i en øget detaljering af kravene. Dette koblet med den øgede viden om prioriteringen af kravene gør det lettere at beslutte en målretning af udviklingsindsatsen allerede på specifikationstidspunktet. Endelig medfører den fælles forståelse omkring prioritering af kravene, at det også bliver lettere at foretage valg under selve udviklingen, så både pris og tid kan holdes.


7.4.2 Teknikkerne koster ikke mere tid totalt på projektet, kun fordelingen ændresDen største kritik, der har været rettet mod teknikkerne er, at de tager for lang tid. Vi har set kravspecifikationsfaser på op mod halvdelen af et projekts tidsforløb. Noget af dette kan skyldes usikkerhed hos projektledere og udviklere mht. hvordan teknikkerne skal anvendes, og hvormeget man skal gøre ud af dem (se feks. kapitel 7.4.3). En anden årsag til de lange forløb kan ligge i, at de fleste projekter har bygget både en papir/navigerbar prototype og en funktionel prototype. De har alle konstateret bagefter, at de ikke fik særligt meget ekstra ud af den funktionelle prototype i forhold til den tid, der gik med at udvikle den (typisk 2-3 måneder). Alle vil de fremover holde sig til kun at lave en papir/navigerbar prototype.

Uanset ovenstående forklaringer er det klart, at det koster megen tid at udarbejde scenarier, lave prototyper og gennemføre usability tests med en række personer. Den ekstra tid viser sig imidlertid at blive hentet ind igen senere.

Der er flere grunde til, at tiden hentes ind igen senere i udviklingsforløbet. Det viser sig, at den prototype der udarbejdes mhp. at afklare behov i meget høj grad kommer til at afspejle et designprincip for opgavens løsning. Løsningsprincippet bliver ikke kastet væk, kun den ”kode” der er brugt til at fremstille prototypen hurtigt. Prototypen kommer til at fungere som en ”løsningsmodel” for projektholdet. Nye ideer kan hele tiden holdes op mod prototypen og relateres til informationer, der blev indhentet under usability tests, så implementeringen lettes. På tilsvarende vis fungerer scenariebeskrivelserne, prototyper og usability test resultaterne som ”uafhængige” referencer (opmænd) i tilfælde af konflikter mellem udviklerne om løsningsforslag, hvorved megen spildtid (rework) undgås.

Forskydningen af tidsforbruget overstiger iøvrigt ikke den fordeling, som en moderne udviklingsmodel som feks. Microsoft Solutions Framework (MSF) [Microsoft, 1996] omtaler, hvor 40-50% af projekttiden anvendes i specifikations- og planlægningsfaserne.

7.4.3 Effekten opnås kun gennem hård projektstyring og processtøtte

Teknikker som anvendes tidligt i udviklingforløbet har en tendens til at bruge mere tid end nødvendigt, fordi projektholdet endnu ikke føler tidspresset, fordi der er langt til enden af projektet. Scenarie og Usability test teknikkerne på tidlige prototyper er ikke anderledes end andre teknikker på dette punkt. Man skal derfor være opmærksom på, at der også er nogle faldgruber når disse anvendes.

Normalt vil udviklerne forsøge at lave prototypen alt for ”færdig” før de ”tør” vise den frem, og da de fleste usability tests medfører væsentlige ændringer i prototypen, bruger projektholdet uforholdsmæssig megen tid på bygning af prototyper.

Projektlederen vil tilsvarende være nervøs for at planlægge de mange kundebesøg uden at have vished for at have en brugbar prototype. Derfor venter projektlederen med at aftale usability tests med disse til sent, med den virkning at kunderne/brugerne ikke har tid når det passer projektholdet. Kalendertiden går så med ventetid, der udnyttes af udviklerne til at ”forbedre” prototypen. Rejseomkostninger og -tidsforbrug vokser også. Det værste ved denne mangel på planlægning er imidlertid, at projektlederen i stedet vælger at skære ned i antallet af usability tests med det resultat, at det senere udviklingsforløb ikke opnår de fordele teknikkerne ellers ville have leveret.

Vi har set, at det faktisk kan lade sig gøre at gennemføre mange usability tests over en kort periode ved benhård planlægning af disse tidligt i forløbet, og når så dagen oprinder, fremvise det man har lavet, uanset om dele af usability testen må foregå med skitser på papir. Effekten af testen er den samme.

En effektiv måde at holde projektlederen og udviklerne ”på sporet” er at anvende en erfaren sparringpartner, som kan yde støtte og inspiration (mentoring) til processen. Mentoren vil gennem jævnlige besøg i projektgruppen bevirke, at ”uhensigtsmæssig” anvendelse af teknikkerne fanges, korrekt anvendelse indlæres, og gode ideer til fremdrift støttes.

7.5 Teknikkerne giver bedre produkter


Vi har konstateret at Scenarie og Usability test teknikkerne på tidlige prototyper har givet vore produkter en bedre kvalitet set fra et kunde/brugersynspunkt.

7.5.1 Bedre understøttelse af brugerens reelle behov

Scenarier og usability tests giver udviklerne en langt dybere forståelse af, hvad der virkelig tæller for brugerens arbejdsituation. Denne forståelse opnås på så tidligt et tidspunkt i projektet, at der endnu ikke er foretaget væsentlige, kritiske og måske potentielt ”katastrofale” beslutninger. Det er derfor næsten omkostningsfrit at tilpasse produktet til disse behov.

Scenariebeskrivelser har den fordel, at de ikke går ud fra en bestemt opfattelse af systemafgrænsningen, dvs. hvad der ligger inden for hhv. uden for systemet. Under udarbejdelsen af scenarierne og gennem de senere usability tests bliver det meget tydeligt, hvor en fornuftig afgrænsning kan lægges. Specielt opdager projektholdet meget tidligt, hvilke hjælpeprodukter og andre serviceydelser, der kan komplettere produktet.

Som konsekvens af dette har vi set, at der opnås et væsentligt øget salg af produkterne.

7.5.2 Forbedret brugerinteraktion

Det er klart, at udarbejdelse af prototyper medfører, at udviklerne på et meget tidligt tidspunkt i projektet må tage stilling til væsentlige brugergrænsefladeprincipper. Mange betragter dette som en designopgave, men det viser sig, at det er en fordel at bruge tid på at lave en fornuftigt opbygget prototype, fordi brugeren ikke skelner mellem hvad produktet kan (indholdet) og brugerens anvendelse (brug) af produktet.

Udviklere er teknikere, og de skaber normalt ”tekniske” løsninger (feks. dybe menu træstrukturer). Når disse løsninger først er implementeret, udviser udviklerne stor modstand mod at ændre dem. Usability tests er en effektiv måde til at afsløre alvorlige fejl i samspillet mellem brugeren og produktet på et tidligt tidspunkt. Usability tests på tidlige prototyper skaber derfor de rigtige forudsætninger for beslutninger om principperne i brugerinteraktionen, før de ”tekniske” løsninger gror fast.

7.5.3 Færre fejl

Den største enkeltgruppe af fejl under udvikling af et produkt kan henføres til mangler eller fejl under kravspecifikationsprocessen. Ved at gribe ind her med Scenarie og Usability test teknikkerne har vi konstateret, at mange af disse fejl kan forebygges. Ved at bruge disse teknikker opnår vi imidlertid også en reduktion i øvrige typer fejl i udviklingsprocessen. Dette sker, fordi vi lader udviklerne selv skrive scenarierne og gennemføre usability tests. Den dybe viden de herigennem opnår om domænet bevirker, at de i de efterfølgende udviklingsfaser i højere grad vil vælge de rigtige design- og kodeløsninger, samt gennemføre mere realistiske tests på deres delprodukter.

8. Sammenligning med andre undersøgelser

Weidenhaupt et al. (1998) studerede 15 virksomheder i forbindelse med Esprit-projektet CREWS (http://sunsite.informatik.rwth-aachen.de/CREWS). I alle 15 virksomheder anvendtes scenarier, men i meget varierende former. Weidenhaupt har ni konklusioner der minder meget om en del af vores konklusioner:

1. At scenarier især er anvendelige når abstrakt modellering fejler, dvs. til at konkretisere – ”Customers and users prefer to talk about concrete scenarios rather than abstract models” (p. 38)

2. At scenarier styrker og fremmer tværdisciplinær læring, f.eks. mellem kunder og udviklere, eller mellem domæne-eksperter og andre i projektet

3. At fordelene ved scenarier i mange tilfælde først trådte rigtigt frem, når man kombinerede scenarier med prototyper – ”Combining both approaches yielded symbiotic effects” (p. 39). Initielle scenarier tjente ofte til at validere prototyper, og indirekte også kravspecifikationer.


http://www.sunsite.informatik.rwth-aachen.de/CREWS

4. Scenarier er gode til at reducere kompleksitet. Ved kun at fokusere på en forretningsgang ad gangen bliver tingene nemmere at forholde sig for interessenterne.

5. Scenarier er gode som udgangspunkt for diskussion mellem interessenter6. Ved at koble scenarier sammen med ord-definitioner (”glossaries”) kan man opnå et fælles begrebsapparat i

projektet7. Selv om scenarier skulle være gode især til dynamiske aspekter, så anvendes scenarier mange steder også til

at kontrollere statiske modeller8. Scenarier udvikler sig undervejs i projektet på tre måder. For det første top-down. For det andet fra black-

box til white-box. Og for det tredje fra uformelle til formelle. 9. Scenarier er gode til at bygge broer (”bridges”) mellem systemer og forretningsgange, mellem kunder og

udviklere, mellem arkitektur design og komponenter, mellem udviklere, mellem udviklingsfaser, samt mellem systemstruktur og systemadfærd (”behaviour”).

Weidenhaupt et al. (1998) slutter med at pege på fire udfordringer til fremtidens forskning:1. Hvordan kobler man scenarier sammen med andre teknikker?2. Hvordan styrer man udviklingen af scenarier henover et projekt?3. Hvordan sikrer man sporbarhed mellem scenarier og andre artefakter i projektet?4. Hvornår udvikler man hvilken type scenarie, på hvilket abstraktionsniveau, og hvornår stopper man?

For så vidt angår flere af disse udfordringer har vi, i hvert fald foreløbige, svar derpå:1a. Scenarier kobles sammen med prototyper via en usability test hvor scenarierne bruges til at skrive de

opgaver der skal udføres under testen.1b. Scenarier kobles sammen med kravspecifikationsdokumentet, dels ved at scenarierne indgår i selve

dokumentet, dels ved at man ved udledning af arbejdsopgaverne når frem til nogle krav der skal indgå i specifikationen

2. Ved at scenarierne indgår i kravspecifikationsdokumentet styres scenarierne på nøjagtig samme måde som styringen af krav foregår.

3. Sporbarheden sikres fundamentalt med en nummerering og navngivning, men også ved at man anvender scenarierne undervejs som projektets fælles viden om brugssituationerne for produktet. F.eks. bruges scenarierne til at vurdere løsningsalternativer og til at lave test-cases.

4. Vores gode erfaringer stammer fra den type scenarier, der er fortællende med nogle få billeder og skitser. Vi kan ikke sige noget om struktureret tekst, notation i diagrammer, animation og simulation, for det har vi ikke prøvet.

Von Hippel (1986) har påvist, at mange af de bedste idéer til nye produkter kommer fra kunder. Med dette som udgangspunkt har Keil & Carmel (1995) undersøgt 17 virksomheder, der dels lavede kundespecifikke projekter, dels lavede IT-produkter til et marked. Undersøgelsen fokuserede på hvilke typer relationer mellem kunder/brugere og udviklere, der fandtes i de 17 virksomheder. Konkret identificerede Keil & Carmel femten forskellige typer relationer. Studiet i de 17 virksomheder ledte til to konklusioner. Først og fremmest skal man have flere relationer – jo flere jo bedre indtil et vist punkt. De mest succesfulde virksomheder havde gennemsnitligt mellem 5 og 6 relationer. For det andet bør man reducere afhængigheden af indirekte relationer, f.eks. via mellemmænd.

For producenter af produkter til et marked, så som Brüel & Kjær, var vurderingen at de mest anvendelige af de femten relationer var følgende:1. En supportfunktion der hjælper brugerne med dag-til-dag problemer.2. Interviews 3. Prototyping af brugergrænseflade4. Grupper af kunder samles regelmæssigt i organiserede brugergrupper5. Prototyping for at afdække brugerkrav6. Nye krav og feedback fra brugertest7. Salg/marketing-repræsentanter fra virksomheden mødes med kunder8. Kunder møder (demoer af) produkter på messer og udstillinger

Af disse relationer svarer vores usability test af prototyper til relationerne 3, 5 og 6. Vores scenarier afspejles indirekte i 1 (fejlrapporter), 2 (interview af kunder), 7 (udviklere mødes med kunder) og 8 (deltagelse i messer og demonstrationer).


9. Konklusion

Ovenfor har vi beskrevet det forløb over tre et halvt år, som forbedringsaktiviteten om kravspecifikationer har gennemløbet.

Vores konklusion er, at der har været tale om en meget positiv forbedring, der både har givet sig udslag i tilfredse udviklere, bedre produkter og bedre salg. Det er derfor vores opfattelse, at der er belæg i de data, vi har indsamlet og analyseret for vores hovedpointe:

Scenarier og usability tests er effektive teknikker til at skabe bedre produkter, dels fordi de identificerer de rigtige behov, dels fordi de muliggør bedre videnoverførsel fra kunden til udviklingsprojektet, og endelig fordi de skaber bedre samspil internt i udviklingsprojektet under udviklingsforløbet.

Selv om det var vores oprindelige mål at afprøve flere teknikker, endte vi med at koncentrere os om scenarier og usability tests på tidlige prototyper. Disse teknikker viste sig til gengæld at være meget effektive. Dels kunne man på to dage lære et hold udviklere at anvende teknikkerne, dels krævede det ikke nogen ekspertviden at få udbytte af at anvende teknikkerne, og sidst men ikke mindst var udviklerne ekstremt tilfredse med de resultater der kom ud af at anvende teknikkerne.

At teknikkerne førte til bedre produkter har vi både direkte og indirekte belæg for. Direkte har det vist sig ved bedre salg af det produkt, der blev udviklet i første del af projektet. Indirekte har det vist sig ved, at projekter selv er kommet og har ønsket at lære at bruge teknikkerne. Det har ikke på noget tidspunkt været nødvendigt at lave et større salgsarbejde internt hos B&K for at få nye projekter til at anvende teknikkerne. Hvorvidt vore teknikker har ført til identifikation af de rigtige behov, kan vi selvfølgelig aldrig med sikkerhed afgøre. Det er dog vores opfattelse, at stærke indicier peger i den retning. Her tænker vi dels på opfattelsen af, at produkterne fra de projekter vi har været involveret i er blevet bedre og mere brugervenlige, dels på at det var udviklernes egen opfattelse i projekterne, at de havde fået en langt bedre forståelse af hvad potentielle kunder og brugere egentlig havde brug for.

At teknikkerne har ledt til bedre videnoverførsel bygger vi dels på de interviews, vi har holdt med udviklerne, hvor de begejstret har fortalt om al den applikationsviden de har fået ved nærkontakt med potentielle kunder og brugere, dels på opfattelsen af, at der kommer bedre og mere brugervenlige produkter ud af projekter, hvor teknikkerne scenarier og usabiliy tests har været anvendt.

Det bedre samspil i projekterne er selvfølgelig også svært at måle. Vi kunne have lavet en tilfredshedsundersøgelse blandt udviklerne, men med det relativt lille antal udviklere, der har været involveret (ca. 30), havde det under alle omstændigheder været svært at sige noget sikkert. Vi bygger derfor i stedet vores konklusion på, at udviklerne selv, både uopfordret og forespurgt, har peget på det bedre samspil som en overraskende men positiv gevinst. Især er det bedre samspil kommet til udtryk ved færre trættende diskussioner om forskellige opfattelser af brugernes behov og krav, idet den konkrete viden - evt. udtrykt i scenarier - har afsluttet de fleste diskussioner ret hurtigt. Tilsvarende har diskussioner om mulige løsninger kunne afsluttes hurtigt, enten ved henvisning til et scenarie, eller ved konkret afprøvning af en løsningsidé i en prototype, der blev usability testet.

Set i lyset af andres arbejde med scenarier og usability tests har vi ikke revolutioneret verden. Vi har genfundet en række konklusioner som andre også har fundet, hvilket i sig selv er interessant, og øger validiteten af og generaliserbarheden af "lessons learnt". Hvad der derimod er nyt, er den unikke kombination af teknikker, som vi har afprøvet, med udviklere der aldrig tidligere havde arbejdet med usability. Langt hovedparten af artikler og bøger om usability anbefaler brug af usability eksperter. Det er vores erfaring, at det lader sig gøre uden.

En mere overordnet konklusion på forbedringsprojektet er, at man ved software procesforbedring ikke behøver sætte et stort ambitiøst metrikprogram i værk. Man kan udmærket tage udgangspunkt i noget simplere som f.eks. fejlrapporter for et eksisterende produkt. I B&Ks tilfælde ledte denne simple tilgang, via en dybtgående analyse af fejlrapporterne, til et fokuseret og meget succesfuldt forbedringsprogram.


10. Referencer

Beizer, Boris (1990). Software Testing Techniques, 2nd edition, Van Nostrand Reinhold.Davis, Alan M. (1990). Software Requirements: Analysis & Specification. Prentice-Hall, New Jersey.Galliers, Bob. (1992). Choosing Information Systems Research Approaches. In: Galliers, R. (Ed.). Information

Systems research: Issues, Methods and Practical Guidelines. Blackwell scientific Publications. Oxford, England.

Keil, Mark & Erran Carmel (1995). Customer-Developer Links in Software development. Communications of the ACM, May 1995, vol. 38, no. 5, page 33-44.

Mathiassen, Lars (1996). Beskrivelse af forskningsprojekt om: Softwareprocesforbedring, Aalborg Universitet.Microsoft (1996). Microsoft Solutions Framework Reference Guide. Microsoft Press.

http://www.microsoft.com/msf Miles, Matthew B. & A. Michael Huberman (1994): Qualitative Data Analysis: An Expanded Sourcebook. 2nd

Edition. Sage Publications.Sommerville, Ian & Pete Sawyer (1997). Requirements Engineering: A good practice guide. Wiley.Susman, G. and Evered, R. (1978). An assessment of the scientific merits of action research. Administrative

Science Quarterly 23 (4): 582-603.Thayer, Richar H. & Merlin Dorfman (eds.). Software Requirements Engineering. 2nd Edition. IEEE Computer

Society Press, Los alamitos, California.Weidenhaupt, Klaus, Klaus Pohl, Matthias Jarke & Peter Haumer (1998). Scenarios in System Development:

Current Practice. IEEE Software, March/April 1998, Page 34-45.Vinter, Otto, Søren Lauesen & Jan Pries-Heje (1999). A Methodology for Preventing Requirements Issues from

Becoming Defects (PRIDE). ESSI Project No. 21167. Final Report. http://www.esi.es/ESSI/Reports/All/21167

Vinter, Otto & Jacob Nørbjerg (1999). Rapport fra forbedringsaktivitet: Software udviklingsmodel, Brüel & Kjær CMS, B&K rapport.

Vinter, Otto (1999). Rapport fra forbedringsaktivitet: Software udviklingsmodel, Brüel & Kjær S&V, B&K rapport.

Von Hippel, Eric (1986). Lead-users: A source of novel product concepts. Management Science vol. 32, no. 7, page 781-805.


http://www.microsoft.com/msf

Bilag 1. Scenarie-skabelon

Scenario: <Replace with Title>

1. User:Describe the person that will be conducting this scenario. Provide a little background on her experience and tasks that she generally performs. Describe the role that she will play in this scenario. If there are more than one participant, describe each person’s background and role in this scenario and how different members will interact. Only describe things that are relevant to this scenario. This section should only be 2 or 3 lines of text.2. Time and Place:Describe the setting in which the scenario will take place. If there are environmental considerations, moving vehicles, loud background noises, large distances, cramped spaces or the like, describe those here. Special time consideration should also be described. These are the background things that the user will have to put up with and generally complicate the issue. This section will set the scene and assist in usability issues. Pictures of the scene are enormously useful. Again, only relevant things and keep it short, 2 to 4 lines. Save most of the description for the narration .3. Purpose:Describe what is intended to be accomplished in this scenario. Describe what the problem is and what results need to be obtained to solve the problem. If there is not a clear goal, it’s not going to be very useful. The goal may be accomplished long after ‘our’ proposed system finishes. If there are interim goals, describe those also. 4. Narration:Describe, in story form, what takes place to accomplish the stated goals. The story should describe one complete path to completing the goals. If there are multiple possibilities, these should be described in separate scenarios. It should describe normal situation, not special cases and exceptions. If it helps, actual results can be described. It should not necessarily start or end where we think 'our' system's responsibilities lay.

The narration should be an 'open' description without complete details. It should paint a picture in the reader's mind. It should be a story of what is happening. It should not describe what or how 'our' system should do something, but rather what is being done.

Like all good stories, the narration should show that the goals were met and what the results were. Limit the narrative to 1-1 1/2 pages of text. 5. Exceptions:The description in the narration section should only cover the “sunny day scenario”, i.e. where everything works as intended. This section contains a list of situations or things that can go wrong during the scenario, and how we should react in these cases. Keeping exceptions separate from the “main line” of the scenario helps keep the description simple and to the point.

Each exception should be described in a subsection and carry a title. The description should identify the exact place in the scenario narrative where it happens.6. Tasks:From the description, extract out the task that need to be accomplished to complete the scenario. No particular order is required, however it is usually convenient to list in order that the tasks occur. Tasks that are completed more than once should only be listed once. This is a post processing function and should not be done until the scenario description is completed, reviewed, and corrected.

Use bullet points with some additional text, if necessary.7. Our System:Only after completing the scenario description and extracted out the relevant tasks should you consider how our system will handle the scenario. Describe what the user will get by using our system to solve the scenario. However, do not get trapped into describing the solution too early. Quick solutions can be incomplete or difficult to expand.


Bilag 2. Listen over kravspecifikationsteknikker

Dette bilag indeholder den komplette liste af teknikker der blev undersøgt ifm. PRIDE projektet. Det er en kopi af Annex D i PRIDE Final Report [Vinter, Lauesen & Pries-Heje, 1999] og derfor på engelsk.

While we classified the errors, we tried to imagine what could have prevented each error. We started out with a list of known techniques and added to it when no technique seemed to be able to prevent the error in question. When we later discussed hit-rates for each technique, we improved and specified each technique further. We ended up grouping the techniques according to their type as follows:

- 1xx Demand analysis (including scenarios)- 2xx Usability techniques (including prototypes)- 3xx Validation and testing of external software- 4xx Requirements tracing- 5xx Risk analysis- 6xx Improved specification techniques (e.g. formal/mathematical)- 7xx Checking techniques (including formal inspections)- 8xx Other techniques (including performance specifications)

The prevention techniques considered are listed below.

1xx Demand Analysis

100 Focus groups with users: To gather ideas and latent demands.101 Scenarios: Relate demands to use situations. A scenario comprises several tasks. See Annex E1.102 Scenarios per market segment: Relate demands in each market segment to use situations.

A scenario comprises several tasks.103 Educate developers in product area: They should know about similar products.104 Educate developers in task domain: They should understand the use situations, visit users, etc.105 QFD: Define high-level demands and trace them to requirements in the form of a matrix.

Used for prioritising requirements.106 GQM: The GQM paradigm is a mechanism used in the planning phase of the Quality

Improvement Paradigm for defining and evaluating a set of operational goals using measurement. Covers some of the same ideas as QFD, but from a goal-driven (strategic) angle.

2xx Usability Techniques

200 User data model: Define screen-like pictures of all data in the system. Make realistic examples. Test understandability with users.

210 Paper mockup, usability test, daily tasks: Tasks planned by domain experts. Tests with users.211 Paper mockup, usability test, rare tasks: Tasks planned by domain experts and designers to cover all system

functionality not covered by daily tasks, e.g. configuration. Tests with users.212 Paper mockup, stress cases: Cases selected to stress the system. Tests with developers only.220 Screen mockup, usability test, daily tasks: Primarily navigational functionality, e.g. static screen

contents. Tasks planned by domain experts. Tests with users. See Annex E2.221 Screen mockup, usability test, rare tasks: Primarily navigational functionality, e.g. static screen

contents. Tasks planned by domain experts and designers to cover all system functionality not covered by daily tasks, e.g. configuration. Tests with users.

222 Screen mockup, stress cases: Not meaningful without functionality - Dropped.

230 Functional prototype, usability test, daily tasks: Some functionality, e.g. dynamic screen contents, create/delete. Tasks planned by domain experts. Tests with users.


231 Functional prototype, usability test, rare tasks: Some functionality, e.g. dynamic screen contents, create/delete. Tasks planned by domain experts and designers to cover all system functionality not covered by daily tasks, e.g. configuration. Tests with users.

232 Functional prototype, stress cases: Unknown or risky functionality, extreme values (Typically other prototypes than 230 and 231). Tests with developers only.

250 CRUD check: Check that all data can be Created, Read, Updated, and Deleted through the user interface.

260 Check with public style guide: E.g. check against Windows style guide, other standards.270 Check with B&K style guide: E.g. check against a company specific style guide. Must be defined through

experiences from other products.280 Let product expert review screens: The product expert would note deviations from earlier

product styles. See Annex E3.

3xx External Software

300 External software conceptual model: Model the external software as objects, aggregations, operations, etc.301 External software stress test: Test the external software with realistic data from requirements

focusing on extreme cases. See Annex E4.302 External software expert review: Have an expert in the external software review the

specification and design.

4xx Tracing techniques

400 Trace scenarios to requirements specification: Look at each scenario and check whether it is supported by requirements. - Included in 101, dropped.

401 Trace requirements specification to design: Look at each requirement and check that the design supports it.

5xx Risk analysis techniques

500 Risk analysis: Identify unknown or critical areas and analyse or test them further.

6xx Formal specification techniques

600 Formal specification: Mathematical description of relation between input and output. E.g. VDM, Z etc.610 Completeness model: An automated verbal analysis of the specification text.

7xx Inspection / Checking techniques

700 Formal inspection of specification: Fagan or Gilb/Graham inspection to find any kind of problems in the requirements specification. Other documents used as sources.

701 Formal inspection of object model: Fagan or Gilb/Graham inspection to find any kind of problems in the object model. Other documents used as sources.

702 Formal inspection of screens: Fagan or Gilb/Graham inspection to find any kind of problems in the screen contents. This is to be a technical inspection - formal version of 280.

710 Improved check of object model: Generic technique to check object model for good modelling practices.

711 Object model with external objects: Check that external objects and their operations are modelled. E.g: External files that are deleted, computed pictures that appear as objects to the user.

720 Consistency review: Broad review of specification and object model to find inconsistencies of any kind.721 Orthogonality check: Specific check of requirements specification to see whether an operation or feature

can be applied whenever it is useful. See Annex E5.722 Uniformity check: Specific check of requirements specification to see whether an operation looks the same

and works the same way whenever it is used.


730 Initial value check: Specific check to see whether created objects have meaningful default attributes, whether screens have meaningful initial contents, etc.

740 Special value check: Specific check to see that special values are shown and handled properly. E.g. missing data, overload.

750 Clean up/reset check: Specific check to see that clean up is performed at reset, cancel, disconnect etc.

8xx Other techniques

820 Performance specifications: Specific check of requirements specification to see whether it contains performance goals for the requirements, e.g. ranges, accuracy, space, response times. See Annex E6.

830 Robustness specifications: Specify handling of unexpected input. E.g. external files with meaningless contents, failing external hardware. - Same as 740, dropped.

840 Interoperability specifications: Consider all kinds of interactions with other systems. E.g. spreadsheets, robot systems. Consider both slave and master roles.

850 Change control: Ensure that changes in cooperating products are considered in due time.


Bilag 3. Scenarie og Usability test teknikkerne

Dette bilag indeholder en uddybet beskrivelse af de teknikker (Scenarier og Usability tests), der er blevet anvendt i praksis ifm. forbedringsprojektet. Det er et uddrag af Annex E i PRIDE Final Report [Vinter, Lauesen & Pries-Heje, 1999] og derfor på engelsk. Den fulde liste af teknikker, der er blevet undersøgt ifm. PRIDE, findes i bilag 2.

Scenarios

Technique: 101

Purpose: Relate demands to use situations. Describe the essential tasks for each scenario.

ProcedureWrite down short descriptions (app. 1 page) of each known use situation. A report from focus groups is a good source. Otherwise interview product and domain experts.

The scenario description explains the work environment, the overall purpose of the work, and the type of users working. The purpose of a scenario description is to give the developers some intuitive understanding of the settings, so that they guess tacit requirements more correctly. The scenario description will also be useful in setting up the environment for a usability test and for selecting test users.

List the essential tasks for each use situation. A task is a specific job with a goal, a beginning, and a termination. Tasks are carried out by people, probably using machinery and computers. A task is often triggered by an external event, for instance that a customer calls. The task terminates when the goal has been reached, or when the task is cancelled. Termination has a strong psychological aspect: the user should feel that now he has accomplished something, he deserves a break (the closure concept). Termination is related to a goal that is meaningful to the user.

The purpose of describing tasks is to list what the system should be able to support seen from the users perspective. Tasks can also serve as test cases in usability tests.

The use situations (scenarios) and task lists should be included in the requirement specification. Later, check that all tasks are covered by the requirements. Checking to be done by a domain expert and a developer.

References: Greenbaum, Joan & Morten Kyng (1991). Design at Work, Lawrence Erlbaum Associates.Potts, Colin, Kenji Takahashi & Annie I. Antón (1994). Inquiry-Based Requirements Analysis, IEEE Software,

March 1994, pp. 21 – 31.

Usability test, screen mockup, daily tasks

Technique: 220

Purpose: Check that the users are able to learn and use the system for daily tasks based on a navigational prototype of the user interface.

ProcedureThis technique uses a navigational prototype (screen mockup) of the user interface, tests it with users simulating daily tasks, revises the design, tests it again, and so on until the result is acceptable.


A set of tasks is selected to reflect daily use. The tasks are defined by domain experts, or taken from the use situations (scenarios) if they have been made. The task is only defined at a high level. The users have to find a proper sequence of actions to complete the tasks, and users may do it differently.

The next step is to make a usability test with users. Each user is asked to carry out the tasks one by one. The user fills in fields, says which mouse actions or menu choices he would make, etc. The prototype allows navigation among screens with static contents. The test manager encourages the user to explain why he does what he does, what he believes the system will do, etc. During the test, an assistant writes down the problems that the user encounters (the session should also be recorded on tape to allow verification of the problems).

Based on the feedback the design is modified and tested again.

It is suggested to make a pilot test with one user, and then repair the most obvious problems. Next a test is made with two more users, and the design is modified again. The new version is tested with three more users and the design is modified once more. The test and design could be continued, but in practice we believe that developers would not have the patience or time to do it.

References: Molich, Rolf (1994). Brugervenlige edb-systemer (“User friendly computer systems”), Teknisk Forlag

Copenhagen.Nielsen, Jakob & Robert L. Mack, Eds. (1994). Usability Inspection Methods, John Wiley & Sons.


· Web viewEndelig interviewede vi en intern usability testperson fra NSI-projektet og en fra...

Documents

Transcript of · Web viewEndelig interviewede vi en intern usability testperson fra NSI-projektet og en fra...