Commit b26ca7da authored by Michael Alrøe, Associate Professor, M.Sc.E.E.'s avatar Michael Alrøe, Associate Professor, M.Sc.E.E.
Browse files

Update Use Case notes.md

parent a56f1870
1.1 Kravspecifikation
• I forbindelse med udarbejdelse af kravspecifikation foregår der typisk et antal aktiviteter:
Figur 1, Eksempel på specifikationsaktiviteter
• Ved specifikation af de funktionelle krav kan use case teknikken anvendes. En ”use case” kan oversættes til en brugssituation.
• En use case baseret kravspecifikation kan opbygges efter nedenstående model:
Figur 2, Eksempel på opdeling af kravspecifikation.
• Udarbejd accepttestspecifikation sideløbende med kravspecifikation, hvilket sikrer testbarhed af kravspecifikationen.
• Alle krav skal være testbare!
• Use cases kan beskrives i flere detaljeringsgrader, man definerer typisk:
Brief
– Typisk en sætning der beskriver hovedscenariet.
– Hvornår: Ved tidlig Requirement Analysis
Casual
– Typisk flere sætninger der beskriver hovedscenariet samt væsentlige alternativer/undtagelser.
– Hvornår: Ved tidlig Requirement Analysis
Fully Dressed
– Komplet og detaljeret beskrivelse af alle scenarier og undtagelser.
– Hvornår: Inden udarbejdelse af testspecifikation og design. Start med at udvælge de mest betydningsfulde Use Cases.
En kravspecifikation kan godt bestå af use case beskrivelser med forskellige detaljeringsgrader. Vigtigt er det at den/de use cases der skal anvendes i den aktuelle iteration er ”Fully Dressed”.
• Ved use case beskrivelser er det vigtigt at gøre sig helt klar hvem der gør hvad:
1. Systemet …
2. Aktør1….
3. Systemet…
• Den funktionelle beskrivelse skal være set fra aktørens/kundens side, og ikke fra udviklers!
• Brug gerne punktform for use case beskrivelserne.
• Brug gerne punktform for beskrivelse af undtagelser, og hvor går systemet hen efter udførelse af en undtagelse.
• Det kan være en fordel at beskrive brugergrænsefladen med nogle skitser/skabeloner for hvordan det endelige system kommer til at se ud. Brugergrænseflade skal ikke være en integreret del af UC beskrivelserne, men kan evt. refereres til i et andet afsnit. Det endelige system må ikke afvige væsentligt fra denne beskrivelse!
• Begrebet ”Who has the ball” definerer en interaktion mellem aktører og system, således at man som læser ikke er i tvivl om hvem der skal udføre den givne aktion.
1. ”Der indtastes en parameter der valideres”
Er det aktør eller system der validerer den konkrete indtastning.
Bedre:
1. Systemet udskriver prompt for parameter X(se fig.xx, afsnit yy).
2. Aktør1 indtaster parameter X.
3. Systemet validerer parameter X.
Undtagelse: Ugyldig parameter X
4. Aktør1 …..
Undtagelser:
Ugyldig parameter X
1. Systemet udskiver ….
2. Aktør1 ….
3. Use case fortsætter i pkt. 1.
Det er vigtigt at få beskrevet hvad der sker efter en undtagelse. Det kan være at use casen fortsætter i et punkt i normalforløbet, men det kan også være at use casen afsluttes.
3. Use case afsluttes.
• Det kan for nogle scenarier være en fordel at beskrive alternativer som en del af normalforløbet. Dette kan f.eks. gøres ved at bruge indeksering A. B. C. …. for et givent punkt i normalforløbet.
1. Systemet udskriver menu X(se fig.xx, afsnit yy).
2.A.
1. Aktør1 vælger a.
2. Systemet ….
3. Aktør1 ….
2.B.
1. Aktør1 vælger b.
2. Systemet ….
3. Aktør1 ….
2.C.
1. Aktør1 vælger c.
2. Systemet ….
3. Systemet ....
Fra pkt. 3 i ovenstående er der fælles forløb for alle alternativer.
• Udformningen af en use case er ikke standardiseret, men som udgangspunkt bør hver use case som minimum indeholde følgende:
Mål:
Her gives selve målet med use casen. Beskrivelsen skal supplerer og uddybe den information der ligger i selve navnet (typisk 1-3 linjer tekst).
Normal scenarie:
Normalforløbet beskriver solskinsscenariet, hvor alt går efter planen og målet med use casen opfyldes. De øvrige scenarier beskrives som undtagelser til normalforløbet
Hver ny funktionalitet beskrives som et trin på en ny linje, der nummereres med et fortløbende nummer. Det angives i hvert trin om det er aktøren eller om det er systemet der har initiativet. Hver trin (sætning) beskrives i nutid og skal føre et trin frem mod slutmålet.
Undtagelser:
Her angives hvad der skal ske for de forskellige undtagelser, der er angivet under normalforløbet.
Yderligere information omkring use case teknikken kan findes i [UMLLIGHT], [SPUUML], og endelig har Alistair Cockburn skrevet en bog [Cockburn2000] udelukkende om at skrive use cases.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment