Use Cases

Denne beskrivelse er baseret på Craig Larman’s klassifikation af use cases.

En use case er en kort beskrivelse af, hvordan en bruger (en aktør) interagerer med et system for at opnå et mål.

Det hjælper os med at forstå:

• Hvem bruger systemet
• Hvorfor de bruger det
• Hvad de ønsker at opnå
• Hvordan interaktionen overordnet foregår (på et højt niveau)

💡 En use case handler ikke om, hvordan systemet er bygget, men om hvad det skal gøre set fra brugerens perspektiv.

Eksempler:

• “Log in”
• “Buy a ticket”
• “Create a new account”

Ofte vil man tegne et use case diagram for at illustrere de forskellige aktører og deres interaktioner med systemet. Dette gøres for at identificere systemets funktionalitet og brugsscenarier. Altså for at finde ud af hvilke use cases systemet skal understøtte.

Craig Larman beskriver tre overordnede detaljeringsniveauer:

En kort beskrivelse på én sætning.

Eksempel
“Customer buys a ticket using the app.”

✅ God til hurtigt overblik
✅ Oftest listet samlet i en oversigtstabel

Et kort afsnit, som giver lidt mere forklaring.
Uformelle trin, der beskriver flowet.

Eksempel
Kunden vælger en film og et tidspunkt. Systemet viser ledige sæder. Kunden vælger sæder og betaler. Systemet bekræfter købet.

✅ Mere detaljeret end Brief
✅ God til tidlig planlægning
✅ Stadig ikke særligt formel

En komplet og formel beskrivelse.
Indeholder strukturerede sektioner såsom:

• Name
• Goal
• Actors
• Preconditions
• Postconditions
• Main success scenario
• Extensions (alternative paths)
• Special requirements

Eksempelsektioner (kort version)
Name: Buy ticket
Primary Actor: Customer
Goal: Purchase a movie ticket
Precondition: User is logged in
Main Success Scenario:

1. User selects movie
2. System shows times
3. User selects time
4. System shows seats
5. User selects seats
6. System processes payment
7. System issues ticket

Extensions:
1a. Payment fails → Show error

✅ Bedst til detaljeret systemdesign
✅ Nyttigt når udviklere skal implementere funktionaliteten

De hjælper med at:

• Forstå brugerbehov
• Planlægge funktionalitet
• Kommunikere mellem forretning + udvikling
• Danne grundlag for tests
• Guide UI + systemdesign

De hjælper os med at fokusere på hvad brugerne har brug for, fremfor hvordan vi ønsker at bygge systemet.

Dette bruges ofte som et lettere alternativ til Fully Dressed-use cases. Formålet er at beskrive det vigtigste happy path (Sunny Day) og et par vigtige alternative/fejlscenarier (Rainy Day).

Typisk beskriver man:

• Sunny Day → 1 klart hovedforløb
• Rainy Day → 1–3 almindelige (ikke udtømmende) undtagelser

Det gør use casen mere overskuelig, men stadig nyttig.

Use Case Navn:
  Goal:
  Actor(s):

Sunny Day Scenario:
  1. ...
  2. ...
  3. ...

Rainy Day Scenarios:
  A) ...
  B) ...

Use Case: Buy Ticket

Use Case: Buy Ticket
Goal: Customer køber en biografbillet
Actor: Customer

Sunny Day Scenario (Happy Path):
  1. Customer vælger film
  2. Systemet viser ledige tider
  3. Customer vælger tid
  4. Systemet viser sæder
  5. Customer vælger sæder
  6. Customer betaler
  7. Systemet udsteder billet

Rainy Day Scenarios:
  R1: Systemet viser ikke ledige tider → Fortæl at forestillingen er udsolgt
  R2: Betaling fejler → Giv fejlbesked og bed om ny betalingsmetode
  R3: Brugeren annullerer efter sædevalg → Gå tilbage til filmvalget

Fordele:

• Let og hurtigt at skrive
• Godt i tidlig analysefase
• Giver udviklere + product owner en fælles forståelse
• Understøtter dialog uden detaljeret formalismes

Ulemper:

• Ikke komplet (få alternativer)
• Kan være for overfladisk til detaljeret design

Ofte ses dette niveau i undervisning, tidligt i projekter eller agile teams, som ikke ønsker fuld “Fully Dressed”.

“Sunny/Rainy” ligger typisk mellem Casual og Fully Dressed i detaljeringsgrad.

Per use case:

1. Definér ét Sunny Day flow
2. Tilføj 2–3 Rainy Day scenarier
3. Prioritér vigtigste forretningsmæssige afvigelser
4. Hold det kort! 6–10 trin er fint.

De behøver ikke beskrive alle edge cases — kun dem, der reelt påvirker design eller brugeroplevelse.

• Sunny Day: Den forventede succesoplevelse
• Rainy Day: De vigtigste alternative/fejl-scenarier
• Lettere end Fully Dressed
• Godt i tidlig fase / agile arbejde
• Giver fælles forståelse uden tung dokumentation

Her får du en simpel Markdown-skabelon til uformelle use cases med Sunny Day / Rainy Day. Den er klar til at sætte ind i Hugo eller lignende.

## Use Case: <Navn>

**Goal:**  
<Kort målbeskrivelse>

**Actor(s):**  
<Primære aktør(er)>

---

### ✅ Sunny Day (Happy Path)

1. ...
2. ...
3. ...
4. ...
5. ...

---

### 🌧️ Rainy Day (Alternative / Failure Scenarios)

**R1 — <titel>**  
Beskrivelse...

**R2 — <titel>**  
Beskrivelse...

**R3 — <titel>**  
Beskrivelse...

---

### ✅ Notes (valgfrit)

- Forretningsregler
- Edge cases
- Ikke-mål

## Use Case: Buy Ticket

**Goal:**  
Customer køber en biografbillet

**Actor(s):**  
Customer

---

### ✅ Sunny Day (Happy Path)

1. Customer vælger film
2. Systemet viser ledige tider
3. Customer vælger tid
4. Systemet viser sæder
5. Customer vælger sæder
6. Customer betaler
7. Systemet udsteder billet

---

### 🌧️ Rainy Day (Alternative / Failure Scenarios)

**R1 — Sold Out**  
Forestillingen er udsolgt → systemet informerer bruger

**R2 — Payment Failure**  
Betaling afvises → systemet beder om ny betalingsmetode

**R3 — User Cancels**  
Bruger annullerer → systemet går tilbage til filmvalget

---

### ✅ Notes
- Ingen billet → ingen reservation
- Kun kreditkortbetaling