Fully dressed

## Skabelon til en fully dressed use case

**En fully dressed use case indeholder:**

* Use Case Name
	+ Starter med et ID med formen <Systemforkortelse>-<fortløbende nummer> og efterfølges af et udsagnsord i bydeform
		- fx VUS-1: Lej videofilm, VUS-2: Aflever videofilm
* Scope (afgrænsing)
	+ Typisk det system som use casen berører
		- fx NextGen POS application, Videofilmsudlejningssystem
* Level (niveau)
	+ Use casens placering i use case hierarkiet, enten "brugermål" eller "underfunktion"
* Primary Actor (primær aktør)
	+ Den der interagerer med systemet (kan også være på vegne af andre). Rollen skal angives så præcist som muligt
* Stakeholders and Interests (Interessenter og interesser)
	+ Alle med interesse i use casens funktion og deres konkrete interesser i systemet. Hvis et visionsdokument er udformet, kan der hentes inspiration til interessenter i dette
* Preconditions (Forudsætninger)
	+ Betingelser der skal være opfyldte før use casen kan påbegyndes
		- fx brugeren er autentificeret, andre use cases der skal være afviklet først
		- dog skal trivielle forudsætninger som "maskinen er tændt" undlades
* Succes Guarantee, Post Conditions (Succesgaranti)
	+ Angiver forhold, som skal være opfyldte ved use casens afslutning - især for hovedscenariet, men også evt. for alternative scenarier, og bør desuden imødekomme/opfylde alle interessenternes interesser
		- fx salget er gemt, afgifter er korrekt beregnet, lagerstatus opdateret, kvittering laves
* Main Succes Scenario, Happy Path (Hovedscenarie)
	+ Beskriver det scenarie, som oftest forekommer
	+ Tilfredsstiller som hovedregel alle interessenters interesser
	+ Beskrives uden variation
	+ Kan evt. beskrive et trin helt generelt mhp. at trinnet specificeres som en række variationer
	+ Kan sammenlignes med en brief use case
* Extensions (Variationer, Alternative scenarier)
	+ Beskriver alle variationer ift. hovedscenariet (fx alternative successcenarier og fejlhåndteringsscenarier)
	+ Består af to dele:
		- Betingelsen, beskrives inklusiv hvordan, den opdages
		- Håndteringen, antages at fortsætte med hovedscenariet, hvor det blev afbrudt
		- Kan specificeres til at terminere use casen eller fortsætte fra et specifik tring i hovedscenariet
			* fx hvis to forskellige variationer skal ske inden for hovedscenariets punkt 3-6, da kan det skrives som 3-6a og 3-6b
* Special Requirements (Ikke-funktionelle krav)
	+ Beskriver relaterede ikke-funktionelle krav
		- fx brugervenlighed, sikkerhed, ydeevne, pålidelighed
	+ Kan/bør senere flyttes til den supplerende kravspecifikation
* Technology and Data Variations List (Teknologier og dataformater)
	+ Specielle krav (teknologi, dataformater) fra interessenterne
		- fx sprogindstillinger, flere skærme, underskrift på bon i papirform, flere muligheder for forskellige indscanningskoder
	+ Typisk af hensyn til eksisterende forhold som andre systemer og eksisterende hardware
	+ Bør begrænses mest muligt for at undgå at fastlåse projektet fra start
* Frequency of Occurence (Hyppighed)
	+ Hvor ofte use casen forekommer, bør være så præcist som muligt
		- fx 5 gange i timer, 10 gange om dagen
* Miscellaneous (Diverse)
	+ Alt der ikke passer i de øvrige sektioner
	+ Kendte og (u)løste problemstillinger
	+ "skraldespanden"

*Information fundet i powerpoint w03\_1 Formelle use cases, og UML-bogen side 67-72*