Introduktion til brugsmønstre ("use-cases") Morten Lehrmann

Introduktion til brugsmønstre ("use-cases") Morten Lehrmann

Introduktion til brugsmønstre ("use-cases") af Morten Lehrmann Ophavsret 2002-2003 af Morten Lehrmann, Forbundet af Offentlig Ansatte.

Indholdsfortegnelse 1. Baggrund...1 2. Generel introduktion...2 2.1. Fordele ved brugsmønsterteknikken...2 2.2. Begreber: System, domæneeksperter, aktører og roller...2 2.2.1. Primære aktører...2 2.2.2. Sekundære aktører...3 2.2.3. Interessenter...3 2.2.4. Roller...3 2.3. Afgrænsning af systemet...4 2.4. Brugsmønstrenes formål...4 2.5. Brugsmønsterniveauer...5 2.6. Brugsmønsterkarakteristika...6 2.7. Brugsmønsterskabelon med eksempel...6 2.8. Hvordan kommer man i gang med at skrive brugsmønstre?...11 2.9. Varm op med en dagligdags fortælling...11 2.10. Hvornår er man færdig med at skrive brugsmønstre?...12 2.11. Typiske fejl i brugsmønstre...12 2.12. Huskeregler ved skrivning af brugsmønstre...13 2.13. Checkliste for brugsmønstre...14 3. Uddybninger...16 3.1. Primære aktører...16 3.2. Successcenarie...16 3.3. Afvigelser...18 A. Engelske termer...20 B. Ressourcer...21 iii

Liste over alle tabeller 2-1. Brugsmønsterniveauer...5 2-2. Karakteristika...6 2-3. Brugsmønsterskabelon...7 A-1. Engelske termer...20 Liste over alle eksempler 2-1. Primære aktører...3 2-2. Sekundære aktører...3 2-3. Interessenter...3 2-4. Roller...4 2-5. Fortælling...12 3-1. Forskel på validering og "Hvis-så"-check...17 3-2. Dårligt successcenarie...17 3-3. Forbedret successcenarie...18 3-4. Afvigelser...19 iv

Kapitel 1. Baggrund Denne introduktion til brugsmønstre ("use-cases") er skrevet af Morten Lehrmann. Du er velkommen til at sende kritik til <mle000@foa.dk>. Min inspiration kommer primært fra Alistair Cockburn (se Appendiks B). Brugsmønstre er en modelleringsteknik til at beskrive dele af kravene til et system. Teknikken stammer fra 1994 og anvendes primært ved udvikling af objektorienterede IT-systemer (http://www.cetus-links.org/), men det er ingen begrænsning. Brugsmønstre anvendes som en del af UML modelleringsteknikken (http://www.cetus-links.org/oo_uml.html) Dette er ikke en generel beskrivelse af brugsmønsterteknikken, men en kort beskrivelse af udvalgte dele af teknikken. Detaljer er udeladt; ting er forsimplede mv. Udeladelser omfatter fx diagrammer (http://www2.awl.com/cseng/titles/0-201-89542-0/techniques/usecase.htm) og brugsmønstre på forretnings/virksomhedsniveau. Der anvendes overalt danske betegnelser. De tilsvarende originale engelske udtryk findes i Appendiks A. Introduktionen består af to dele: En generel introduktion i Kapitel 2 og en uddybning af enkelte emner i Kapitel 3. Meningen er, at man skal kunne læse den generelle introduktion alene. 1

2.1. Fordele ved brugsmønsterteknikken Brugsmønsterteknikken er god: som kravfremfindingsteknik fx ved en workshop. som dokumentationsteknik. til at beskrive et system ud fra behovene til systemet. til at opdele specifikationsarbejdet. til at adskille specifikationen til brug både for overblik og til detaljer. til at styre et iterativt udviklingsforløb. til at specificere brugertest. 2.2. Begreber: System, domæneeksperter, aktører og roller I det følgende anvendes system om det, som skal designes. Det kan være et IT-system, en vaskemaskine, en telefon e.l. Domæneeksperter er personer, der kender til det område (domæne), som systemet skal omhandle. For et A-kassesystem kan det være A-kassesagsbehandlere. Der skal typisk mange brugsmønstre til at beskrive et system. Der findes tre typer aktører: Primære, sekundære og interessenter. Alle aktører kan være enten personer eller andre systemer. 2.2.1. Primære aktører En primær aktør er karakteriseret ved: Bruger systemet. Udfører brugsmønsteret. Har ønsker om at systemet skal opfylde et mål. Kan være en person eller et andet system. 2

Er ikke en del af systemet. Eksempel 2-1. Primære aktører Hvis systemet er et A-kassesystem, kan sagsbehandlere og AMANDA (Arbejdsmarkedsstyrelsens IT-system) være eksempler på primære aktører. A-kasse udbetalingsprogrammet er ikke en aktør, da det er en del af A-kassesystemet Se eventuelt Afsnit 3.1 for uddybning om primære aktører. 2.2.2. Sekundære aktører En sekundær aktør er karakteriseret ved kun at anvende sekundære dele af systemet. Sekundære aktører initierer og udfører ikke brugsmønstre, men hjælper systemet med at opfylde den primære aktørs og interessenters mål. Eksempel 2-2. Sekundære aktører Hvis systemet er et A-kassesystem, kan følgende være sekundære aktører: Operatører, der efterbehandler udskrifter, driftafviklingssystemer (fx CA-Unicenter), Pengeinstitutternes Betalingsservice. 2.2.3. Interessenter En interessent er en aktør karakteriseret ved at have interesse i et brugsmønster, men uden at interessenten direkte bruger systemet. Interessenter er vigtige, fordi systemet skal tage hensyn til dem. Eksempel 2-3. Interessenter Hvis systemet er et A-kassesystem, kan følgende være interessenter: Direktoratet for Arbejdsløshedsforsikring, IT-sikkerhedsafdelingen, revisionen. 2.2.4. Roller 3

Bemærk, at aktørere er karakteriseret ved deres rolle (eller "arbejdsopgave"). En aktør vil typisk have forskellige roller i forskellige brugsmønstre. Eksempel 2-4. Roller Hvis systemet er et A-kassesystem, kan sagsbehandleren Dorte i afdelingen i Vejle, være primær aktør med rollen "A-kassesagsbehandler" i ét brugsmønster og sekundær aktør med rollen "håndterer af udskrifter" i samme eller et andet brugsmønster. For brugsmønstre er det personernes roller, ikke personerne selv, der er vigtige. 2.3. Afgrænsning af systemet Ofte vil man komme ud for at hver enkelt deltager i et projekt er ret sikker på, hvordan projektet er afgrænset, men at de forskellige deltagere ikke har samme opfattelse af denne afgrænsning. Fx mener både Hans og Grete at systemet skal kunne udskrive breve på sagsbehandlerens lokale printer, men Hans mener den del hører til i Printprojektet, mens Grete mener opgaven er en del af Hans og Gretes projekt. Det er vigtigt tidligt at få afgrænset projektet (så Printprojektet enten accepterer opgaven, eller Hans og Grete accepterer, at det er deres). En simpel teknik til at foretage afgrænsningen er en Inde/ude-liste. Det er en liste med tre kolonner: "Opgave", "Inde" og "Ude". For hver opgave markeres om opgaven er en del af projektet eller ej ved at sætte kryds i enten "Inde" eller "Ude". Det kan være vanskeligere end man umiddelbart skulle tro - og undertiden må ledelsen inddrages for at afgøre afgrænsningen. 2.4. Brugsmønstrenes formål Formålene med brugsmønstre er, at: Få beskrevet funktionelle krav til systemet, dvs. "Hvad skal systemet kunne?" Få en konsistent beskrivelse af systemet til kommunikation mellem domæneeksperter og systemudviklere. Få basis for at verificere (fx i forbindelse med test) om systemet opfylder kravene. 4

Skabe basis for et objektorienteret design. Altså helt kort: funktionelle krav, kommunikation, verifikation og design. Bemærk: Der er mange krav, som brugsmønstre ikke beskriver, fx grænseflader (bl.a.brugerdialogen), ydeevnekrav og dataformater. Typisk vil brugsmønstre omfatte ca. en tredjedel af kravspecifikationen. Se eksempel på en komplet kravspecifikation. (http://members.aol.com/acockburn/papers/prts_req.htm) 2.5. Brugsmønsterniveauer Brugsmønstre kan skrives i - i hvert fald - tre niveauer, som vist i Tabel 2-1. Tabel 2-1. Brugsmønsterniveauer Niveau Symbol Beskrivelse Eksempel Oversigt Drage En række aktiviteter Kontrollere en liste som foregår over mere end 20 minutter typisk ved over medlemmer, som skal rykkes, for fejl. forskellige interaktioner med systemet evt. afbrudt af andre aktiviteter. Brugermål Havoverflade Tager 2-20 minutter at gennemføre; oftest på samme sted. "Når en menneskelig aktør har gennemført et brugsmønster, har aktøren fortjent en kop kaffe". Delfunktion Fisk Del af funktionaliteten i brugermål. Behandle dagpengekort Finde et medlems cpr.nummer givet medlemmets navn. Brugermål er de vigtigste og i mange tilfælde kan man nøjes med dem. Symbolerne 5

kan bruges som ikoner på brugsmønstrene, så man hurtigt kan se, til hvilket niveau brugsmønstret hører. Vigtigt: Brugsmønstre i alle niveauer er brugsmønstre. Altså, selvom et brugsmønster "blot er en fisk", skal den have en primær aktør, en trigger, et mål osv. 2.6. Brugsmønsterkarakteristika Et brugsmønsters karakteristika er beskrevet i Tabel 2-2. Tabel 2-2. Karakteristika Karakteristika Eksempel Modeksempel Den beskriver en komplet funktionalitet for systemet fra start til slut. Funktionaliteten er selvstændig - dvs. den beskriver en samlet aktivitet. Funktionaliteten har værdi for en aktør. Initieres altid af en aktør. Indtastning af et dagpengekort. Indmeld medlem. Udmeldelse af medlem Behandle medlemsindbetalinger via betalingsservice. Sagsbehandleren indtaster et cpr.nr. (er ikke komplet, da den ikke isoleret opfylder et mål). Udfylde de første fem felter på indmeldelsesskærmbilledet Sagsbehandleren trykker retur. Det at trykke retur kan ikke være et mål i sig selv. Sagsbehandleren læser en fejlmeddelelse på skærmen (initieres af systemet). 2.7. Brugsmønsterskabelon med eksempel I tabellen nedenfor er vist en skabelon for brugsmønstre inspireret af Basic Use Case Template, Alistair Cockburn, 1998 (http://members.aol.com/acockburn/papers/uctempla.htm) og Instructions for writing a Use Case, Alistair Cockburn, 1999. (http://members.aol.com/acockburn/index.html) 6

Tabellen indeholder i tredje kolonne et sammenhængende eksempel på et brugsmønster. Tabel 2-3. Brugsmønsterskabelon Felt Indhold Eksempel Nr. Navn Primær aktør Mål Afgrænsning Niveau Forudsætninger Minimale garantier. Succes garantier Brugsmønstets nummer. Bruges som en hurtig reference. Brugsmønsterets navn. En aktiv vending som udtrykker mål for den primære aktør (ikke for systemet). Hvis mål skal dette brugsmønster opfylde? Primær aktør kan aldrig være en del af systemet. Målet for den primære aktør; samt en beskrivelse af omgivelserne Helt kort afgrænsning af hvad dette brugsmønster omfatter Oversigt, brugermål, delfunktion? 45 Indmeld medlem. Sagsbehandler. Få registreret en person som medlem i Forbundets IT-system. Forbundets IT-system. Brugermål. Opremsning af de Sagsbehandleren er logget forudsætninger, som på Forbundets IT-system. brugsmønsteret kan tage for givet. Hvad er opfyldt, når brugsmønsteret er gennemført, selv hvis der opstår fejl undervejs. Ofte kan man intet garantere. Hvilke mål og interesser er opfyldt, hvis brugsmønsteret er gennemført uden fejl? Personen er enten registreret med navne- og adresseoplysninger eller slet ikke oprettet som medlem. 1.Personen er korrekt registreret som medlem. 2.Personen kan opkræves kontingent. 7

Felt Indhold Eksempel Interessenter Hvilke interessenter (personer såvel som systemer) har interesser i dette brugsmønster? Og hvad er deres interesser? 1.IT-sikkerhed: At kun sagsbehandlere med de rigtige privilegier har adgang til at indmelde personer. At det er logget, af hvem og hvornår medlemmet blev indmeldt. 2.Medlemmet: At oplysninger vedr. indmeldelsen er korrekte (fx adresse, kontonummer, anciennitet). 3.Direktoratet for arbejdsløshedsforsikring: At alle lovkrav er overholdt. Trigger Hvilken Sagsbehandleren behandler situation/begivenhed starter en indmeldelsesblanket. dette brugsmønster? 8

Felt Indhold Eksempel Successcenarie Et eksempel på en 1.Sagsbehandleren sandsynlig, almindelig eller validerer at interessent gennemgang af indmeldelsesblanketten brugsmønsteret uden fejl. indeholder de fornødne Hvad sker der? Skrives somoplysninger. nummererede punkter på 2.Sagsbehandleren opretter følgende måde: "Aktøren": medlemmet i forbundets "Målet som aktøren får IT-system. 3. Forbundets opfyldt". "System": IT-system bekræfter "Reaktionen". Man kan oprettelsen. bruge kolonerne (:) eller lade være. Det afgørende er at det er klart, hvem eller hvad, der gør hvad. Ofte beskrives en overførsel af information mellem aktøren og en anden aktør eller systemet. Den nøjagtige beskrivelse (datafelter mv.) henlægges til bilag, hvortil der hyperlinkes. Der skal som regel være mellem tre og elleve trin i et successcenarie. Se i øvrigt Afsnit 3.2. 9

Felt Indhold Eksempel Afvigelser Beskrivelse af de ting, som 1a. Sagsbehandleren kan gå galt eller på anden måde afvige fra successcenariet. Der henvises til numrene i successcenariet så fx 1a, 1b, 1c er de ting der kan opdager at der mangler oplysninger på indmeldelsesblanketten. 1a1. Sagsbehandleren indsamler oplysningerne og påfører dem på blanketten. afvige ved successcenariets 2a. Medlemmet findes punkt 1 og så fremdeles. Skriv *a, *b hvis en ting kan afvige på et hvilket som helst tidspunkt. Nævn allerede i Forbundets IT-system. 2a1. Forbundets IT-system afviser oprettelsen med denne kun ting, som systemet har begrundelse. mulighed for at reagere på. 2b.Indmeldelsesblanketten Fx kan systemet ikke reagere på at det selv "går ned". For hver afvigelse skrives desuden, hvad der skal ske ved afvigelsen, Dette skrives i punktform indeholder modstridende oplysninger 2b1. Forbundets IT-system afviser oprettelsen med information til sagsbehandleren om som i successcenariet, men hvordan problemet kan nummereres under afvigelserne, så punkterne til afvigelse 1a bliver 1a1, 1a2 osv. Se i øvrigt Afsnit 3.3. løses. 2c.Medlemmet kan ikke indmeldes pga. svig tidligere. 2c1.Som 2b1. Bemærk at fx: "Sagsbehandleren spilder kaffe i tastaturet under indmeldelsen, så alle A-er registreres "dobbelt"" ikke hører hjemme her, da systemet ikke kan gøre noget ved det. Øvrig information Prioritet Tidsforbrug Frekvens Hvor stor betydning har dette brugsmønster? Hvor lang tid tager det at gennemføre brugsmønsteret? Meget kritisk. 5-20 minutter afhængigt af om oplysningerne haves. Hvor ofte forekommer dette10 gange om dagen. brugsmønster? 10

Felt Indhold Eksempel Uafklarede forhold Hvad mangler at blive afgjort, som har betydning for dette brugsmønster? Hvordan overflyttes efterlønsoplysninger? (brugsmønster #54) Referencer opad Referencer nedad Referencer til brugsmønstre, som dette brugsmønster er en del af. Referencer til brugsmønstre, som dette brugsmønster bruger. Medlemsadministration. Opret skatteoplysninger. Opret pensionsoplysninger. Opret adresseoplysninger Ofte vil brugsmønstre på højere niveauer kalde brugsmønstre på samme eller lavere niveauer. Dette indikeres bedst i det kaldende brugsmønster ved at lave en hyperlink til det kaldte brugsmønster. Da brugsmønstre udvikles ved en iterativ proces, er det ikke nødvendigt (og sjældent muligt) at udfylde samtlige felter fra begyndelsen. Tværtimod kan der være god grund til kun at skitsere indholdet i de sværere punkter og i stedet lade en anden i arbejdsgruppen arbejde videre på det, man har lavet. Tænk på at grupper er gode til brainstorming og koordinering, mens fordybning og formulering udføres bedst alene. Og generelt er indholdet det primære - ikke formen. At kravene til formen er overholdt, gør dog brugsmønstret nemmere at formidle. Eksempler på brugsmønstre (på engelsk) (http://members.aol.com/acockburn/papers/prts_req.htm) 2.8. Hvordan kommer man i gang med at skrive brugsmønstre? Ofte er det nemmest at starte med at finde de aktører, hvis mål systemet skal opfylde. Man kan også prøve at finde hændelser, som systemet skal reagere på. Start altid med brugermål. Vink: Man kan også lægge ud med en dagligdags fortælling: 2.9. Varm op med en dagligdags fortælling Som en blød opstart på opgaven med at definere de enkelte brugsmønstre, kan en fiktiv fortælling om en specifik aktør, være med til at opfange - i kort form - hvad der er vigtigt for netop denne aktør. Hvad vil hun? Hvorfor vil hun det? Eller hvilke 11

motiver driver aktøren til at gøre det, hun gør? Fortællingerne behøver ikke at være særlig lange. Eksempel 2-5. Fortælling Send et brev til et medlem Sagsbehandleren Ingrid ønsker at sende et brev til et medlem, hvori hun udbeder sig oplysninger til behandling af en lønsag, som Ingrid er igang med. Ingrid kender kun medlemmets navn og arbejdsplads - thats all. Hun vælger skærmbillede [Find Medlem] og taster de kendte oplysninger og vælger søg. Systemet returnerer et antal kandidater, hvoraf Ingrid vælger den rigtige. Ved klik på medlemmets navn, åbnes tekstbehandlingsprogrammet og medlemmets navn, adresse og postnummer/by, indsættes i et tekstfelt i et nyt dokument. Ingrid kan herefter begynde at skrive brevet. Fortællingen kræver meget lidt at skrive, fylder ikke meget og bringer os hurtigt over til selve brugsmønstret. Vi bruger fortællingerne til at forstille os, hvordan et system vil virke. Men vi bruger også fortællingerne til at varme op, inden vi går igang med den mere omfattende opgave med at skrive brugsmønstrene. 2.10. Hvornår er man færdig med at skrive brugsmønstre? Man er færdig, når: Alle primære aktører og alle brugermål er behandlet. Systemet kan reagere på alle de hændelser, det skal kunne reagere på. Alle brugsmønstre er skrevet så klart, at: Systemleverandør og -køber senere kan afgøre om "varen er levereret". Brugerne kan acceptere systemet. Udviklerne kan producere systemet. Ét brugsmønster med tilhørende kravspecifikationer tager omkring 2-5 arbejdsuger at gøre færdig. 12

2.11. Typiske fejl i brugsmønstre Typiske fejl inkluderer: Intet system. Successcenariet indeholder kun den primære aktørs handlinger. Der skal næsten altid være en ping-pong mellem den primære aktør og systemet i hvert punkt. Ingen primær aktør. Successcenariet indeholder systemets handlinger, men ikke den primære aktørs. For megen beskrivelse af brugerdialogen. Man skal koncentrere sig om den primære aktørs intensioner - ikke om den faktiske løsning (som nemt kan blive udsat for ændringer). Ved at gøre det, gør man desuden brugsmønstret længere og sværere at læse og tager arbejdet fra folk, som er bedre til at skrive brugerdialoger). Mål på for lavt niveau. Løsninger: Flet ting sammen; spørg hvorfor; ikke hvordan. Se Afsnit 3.2 for en uddybning. 2.12. Huskeregler ved skrivning af brugsmønstre Skriv koncist. Skriv i nutid med udsagnsord i aktiv form. Brugsmønstrets navn skal være en kort sætning centreret omkring et udsagsord, som udtrykker den primære aktørs mål. Start fra triggeren, fortsæt indtil målet er nået eller opgivet. Successcenariet skal altid være fremadskridende mod målet. Her er der jo ingen fejl, man skal tage hensyn til. Successcenariet beskrives fra fugleperspektiv. Man står altså udenfor både systemet og den primære aktør og betragter, hvad der sker. Efter hvert punkt i successcenariet skal det være klart, hvem der har bolden. Alle brugsmønstre har som minimum to mulige afslutninger: succes eller fejl. Når man refererer til brugsmønstre fra andre brugsmønstre, må man kunne håndtere fejl i de kaldte brugsmønstre, hvis de er relevante for det kaldende brugsmønster. 13

Typiske interessenter: Den primære aktør, organisationens ejer og lovgivningsmæssige organer (fx Finanstilsynet, Direktoratet for Arbejdsløshedsforsikring). Kapitel 2. Generel introduktion Typiske interesser: Få noget; at der bliver betalt for en ydelse; at der føres log. Alle interessenter skal også tilfredsstilles ved fejl. 2.13. Checkliste for brugsmønstre Når et brugsmønster gennemgåes, så check: Kan systemet opfylde målet? Behandles systemet som en sort kasse? [OBS! I nogle brugsmønstre tillades at man kigger ind i kassen - disse er dog ikke omfattet af denne introduktion.] Er afgrænsningen korrekt? Skal der kun udvikles indenfor afgrænsningen? Skal alt indenfor afgrænsningen udvikles? Udfører den primære aktør handlinger? Kan forudsætningerne kontrolleres? Kontrolleres de kun ved start af brugsmønstret? Skal de virkeligt være opfyldt? Opfylder de minimale garantier alle interessenternes interesser? Opfylder succesgarantierne interessenternes interesser? Starter successcenariet fra triggeren og fortsætter indtil succes? Har successcenariet 3-11 trin? Beskriver hvert trin i successcenariet et mål som opfyldes? Beskriver hvert trin i successcenariet en fremadskriden? Beskriver hvert trin i successcenariet tydeligt hvem/hvad som udfører handlingen? Beskriver ingen af trinene i successcenariet en brugerdialog? Beskriver hvert trin i successcenariet hvilken information som "sendes". Beskriver hvert trin i successcenariet en validering - modsat et check? Se Afsnit 3.2 for en forklaring. Beskriver alle afvigelser noget systemet kan opdage? Beskriver alle afvigelser noget systemet skal reagere på? Generelt: Beskriver dette, hvad der er behov for? Generelt: Kan det verificeres, at det som leveres opfylder det specificerede? 14

Generelt: Kan dette udvikles? Her afsluttes den generelle introduktion. Næste kapitel er en uddybning af enkelte emner. 15

Kapitel 3. Uddybninger Dette afsnit indeholder uddybning af primære aktører, successcenarier og afvigelser. 3.1. Primære aktører Man kan blive forvirret over hvem der egentlig er primær aktør. Hvis målet fx er behandle dagpengekort, som det sker, når et arbejdsløst A-kasse medlem indsender sit dagpengekort til sin A-kasse, er den primære aktør vel snarere medlemmet end sagbehandleren? Man bruger faktisk udtrykket den ultimative primære aktør om den aktør som faktisk har målet (her: medlemmet). Der er flere måder at behandle dette på: Beskrive den primære aktør som "sagsbehandleren på vegne af medlemmet". Særligt praktisk er det nu ikke i det daglige. Holde sig stringent til at beskrive sagsbehandlerens rolle, så den primære aktør her bliver "dagpengekortbehandler". Heller ikke særligt praktisk og kræver at man laver en tabel over hvilke ansatte, som kan være dagpengekortbehandlere. Giver desuden nogle ikke særligt givtige sætninger som dagpengekortbehandleren behandler dagpengekortet :-) Den tredje mulighed er ikke at behandle problemet, simpelthen fordi det ikke er vigtigt at få beskrevet nøjagtigt hvem, der er primær aktør. Det afgørende er deres mål. At den ultimative primære aktør i eksemplet er medlemmet, har betydning fordi ny teknologi kan gøre den ultimative primære aktør til primær aktør og sagsbehandleren arbejdsløs, fx hvis medlemmet får mulighed for selv at behandle sine dagpengekort over internettet, men deres mål er ikke stort forskellige. Man skal heller ikke blive for filosofisk. Fx er målet for sagsbehandleren måske egentligt ikke at behandle dagpengekort, men snarere tjene penge til at forsørge familien ved at arbejde i denne A-kasse, hvor indtastning af dagpengekort er nødvendigt, for at beholde jobbet. Men disse betragtninger hører ikke hjemme i et brugsmønster! 3.2. Successcenarie Ideen bag successcenariet er at illustrere et eksempel på anvendelse af systemet, hvor alt går godt. I det følgende punkt: afvigelser, anføres de situationer, hvor der er afvigelser fra dette idealeksempel. Når man skriver successcenariet, skal man derfor ikke omtale fejl og andre afvigelser. 16

Kapitel 3. Uddybninger Ved start af successcenariet ved man at forudsætningerne er opfyldt og at triggeren netop er forekommet. Bemærk at "hvis (et eller andet er opfyldt), så..." vendinger ikke bør forekomme i et successcenarie, da man kun skal beskrive én vej til succes. Andre muligheder hører hjemme i afsnittet afvigelser. I stedet for den betingede sætning kan man typisk skrive "validerer". Eksempel 3-1. Forskel på validering og "Hvis-så"-check "Hvis ikke password er korrekt, så..." bør erstattes med: "Systemet validerer at password er korrekt." Typisk er der 3-8 trin i et successcenarie. Hvis man kommer over 11 trin, bør man overveje: Om man begyndt at beskrive brugerdialogen (som ikke hører hjemme i et brugsmønster). At slå trin sammen. Følgende metode kan hjælpe: Til hvert trin spørg: Hvorfor udføres dette trin. Ved at svare på hvorfor-spørgsmålene bevæger man sig opad i abstraktion. Ved at svare på hvordan-spørgsmål bevæger man sig nedad i abstraktion. Eksempel 3-2. Dårligt successcenarie Brugsmønster: Log ind på Forbundets IT-system (version 1)....(andre punkter udeladt)... Successcenarie: 1. Sagsbehandleren klikker på mappen Forbundets IT-system på skrivebordet. 2. Styresystemet åbner mappen. 3. Sagsbehandleren klikker på ikonet Medlem og kontingent i denne mappe. 4. Forbundets IT-system viser en dialogboks. 5. Sagsbehandleren skriver sit brugernavn i dialogboksen. 6. Sagsbehandleren trykker retur. 7. Forbundets IT-system viser en dialogboks. 8. Sagsbehandleren skriver sit kendeord i dialogboksen. 9. Sagsbehandleren trykker retur. 17

10. Forbundets IT-system bekræfter at sagsbehandleren er logget ind. Kapitel 3. Uddybninger Successcenariet i dette brugsmønster beskriver tydeligvis en brugerdialog og kan ved hjælp af hvorfor-spørgsmål og oprydning i brugerdialogen, forkortes til: Eksempel 3-3. Forbedret successcenarie Brugsmønster: Log ind på Forbundets IT-system (version 2)....(andre punkter udeladt)... Successcenarie: 1. Sagsbehandleren aktiverer indlogning på Forbundets IT-system. 2. Forbundets IT-system anmoder om brugernavn og kendeord. 3. Sagsbehandleren opgiver brugernavn og kendeord til Forbundets IT-system. 4. Forbundets IT-system bekræfter at sagsbehandleren er logget ind. 3.3. Afvigelser Dette vil ofte være det største og vigtigste punkt i brugsmønstret. Det vil typisk ikke være oplagt for systemudviklerne, hvordan systemet bør opføre sig, når alt ikke går efter planen. Derfor er det meget vigtigt, at punktet bliver udfyldt, så det er systemudviklere og domæneeksperter i forening der fastlægger kravene og ikke blot noget en programmør beslutter mere eller mindre gennemtænkt. Vigtigt ved afvigelser er, at man skriver hvad systemet detekterer, ikke hvad der faktisk sker. Fx kan systemet ikke vide om grunden til, at der går 30 minutter fra brugernavn er udfyldt indtil kendeordet bliver udfyldt, er at sagsbehandleren er gået til frokost. For systemet detekteres det som et time-out. Hvis afvigelsen ikke kan konstateres af systemet, er der ingen grund til at anføre den. Fx kan systemet typisk ikke detektere at en sagsbehandler anvender en skærm, hvor en anden sagsbehandler er logget ind (selvom det måske var ønskeligt). Hvis systemet ikke skal reagere på afvigelsen er der heller ingen grund til at anføre den. Fx kan det være at fejl i et medlems adresseoplysninger blot skal ignoreres ved medlemmets udmeldelse. Typiske afvigelser er af en af typerne: Alternative veje til succes (eksempel: sagsbehandleren anvender en genvej). 18

Kapitel 3. Uddybninger Den primære aktør laver fejl (eksempel: sagsbehanderen taster forkert kendeord). Den primære aktør gør intet (eksempel: systemet får time-out). Alle steder i succeskriteriet, hvor der står noget i stil med "systemet validerer" (eksempel: systemet validerer at ændringsdatoen er efter indmeldelsesdatoen). En sekundær aktør gør intet (eksempel: operatøren sætter ikke papir i printeren). En sekundær aktør gør noget forkert (eksempel: operatøren sætter forkert papirstørrelse i printeren). Intern fejl i systemet som må detekteres og håndteres (eksempel: systemet mister forhindelse til databasen). Ydeevne fejl, som må detekteres og håndteres (eksempel: systemet har ikke afsluttet en kørsel før kl.0600). Håndteringen af en afvigelse skrives som trinene i successcenariet. Eksempel 3-4. Afvigelser Eksempel: Successcenarie.... 1. Forbundets IT-system validerer at indmeldelsesdatoen er senere end beregningsdatoen. Afvigelser. 1. Indmeldelsesdatoen er før beregningsdatoen: a. Forbundets IT-system advarer sagsbehandleren. Som regel er det ikke nødvendigt at angive, hvad der skal ske efter afvigelseshåndteringen, da det fremgår af sammenhængen. I eksemplet ovenfor er det ret oplagt at fortsætte med successcenariets punkt 2. I nogle tilfælde afbrydes brugsmønstret; det bør man skrive. Der kan opstå nye afvigelser, når man håndterer afvigelser. Som udgangspunkt indrykker man blot tilsvarende. Når man kommer langt ind i en sekvens af afvigelser, bliver det kompliceret at læse og forstå. På det tidspunkt er man nødt til at bide i det sure æble og splitte håndteringen ud i et separat brugsmønster. Husk at afvigelser er meget vigtige, så det er ikke her man skal springe over hvor gærdet er lavest, selvom det bliver kompliceret. 19

Appendiks A. Engelske termer I Tabel A-1 nedenfor findes en liste over de danske termer og de tilsvarende originale engelske. Tabel A-1. Engelske termer Dansk term Afvigelse Afgrænsning Aktør Brugermål Brugsmønster Delfunktion Domæneekspert Drage Fisk Forudsætning Frekvens Inde/ude-liste Interessent Havoverflade Mål Overflade Primær aktør Prioritet Referencer nedad Referencer opad Sekundær aktør Successcenarie System Tidsforbrug Uafklarede forhold Ultimative primære aktør Øvrige forhold Engelsk term Extension (Design) scope Actor User-goal Use-case Subfunction Domain expert Kite Fish Precondition Frequency In/out-list Stakeholder Sea-level Goal in context Summary Primary actor Priority Subordinates Superordinates Supporting actor Main success scenario System under design Performance Open issues Ultimate primary actor Related issues 20

Appendiks B. Ressourcer OO design process: Use cases, an introduction (http://www-106.ibm.com/developerworks/library/co-design5.html) Alistair Cockburns hjemmeside (http://members.aol.com/acockburn/) 21