Formen
Et use case har en fast struktur. Den er kjedelig, og det er meningen: den tvinger fram spørsmål som ellers hoppes over.
UC-04 Registrere innkommet søknad
Aktør: Saksbehandler
Forutsetning: Søknaden er mottatt digitalt og ikke tidligere registrert.
Resultat: Søknaden er registrert som sak, med saksnummer og beregnet frist.
Hovedflyt:
1. Saksbehandler åpner listen over ubehandlede innsendinger.
2. Systemet viser innsendingene sortert etter mottakstidspunkt.
3. Saksbehandler velger en innsending.
4. Systemet henter eiendomsopplysninger fra matrikkelen.
5. Saksbehandler bekrefter opplysningene og oppretter sak.
6. Systemet tildeler saksnummer og beregner lovpålagt frist.
Avvik 4a: Matrikkelen svarer ikke. Systemet lar saken opprettes med manuelt registrert adresse, og merker saken for senere oppdatering.
Avvik 5a: Eiendommen har allerede en åpen sak. Systemet varsler, og saksbehandler velger å knytte innsendingen til eksisterende sak eller opprette ny.
Legg merke til at hovedflyten er triviell. Verdien ligger i 4a og 5a — to spørsmål ingen hadde stilt, og som begge ville dukket opp under testing hvis de ikke sto her.
Når metoden passer
- Når arbeidsflyten er sammensatt. Flere steg, flere aktører, flere måter det kan gå galt på.
- Når grensetilfellene er dyre. Saksbehandling, økonomi, regelstyrte prosesser.
- Når systemet skal erstatte noe folk kan godt. De vet avvikene; formen henter dem fram.
Når den ikke er verdt bryet
- Til en anskaffelse av et standardsystem. Da kjøper du en ferdig arbeidsflyt. Detaljerte use case blir da en beskrivelse av dagens løsning, og utelukker leverandører som gjør det samme på en annen måte. Se for detaljert for tidlig.
- Når prosessen er enkel. Tre steg uten avvik trenger ikke et skjema.
- Når ingen skal vedlikeholde dem. Use case som ikke oppdateres blir villedende, og villedende er verre enn fraværende.
Skriv fem til ti use case for de mest kritiske arbeidsflytene, og bruk vanlige krav for resten. Du får det viktigste av verdien til en brøkdel av arbeidet — og de fem fungerer i tillegg utmerket som grunnlag for akseptansetesten.
Use case er ikke krav
Et use case beskriver samspill; et krav er en bindende setning. De to har ulik funksjon i en kontrakt, og bør ikke blandes. Vanlig praksis er å legge use case ved som vedlegg, og skrive de bindende kravene med referanse til dem: «K-212 Systemet skal støtte arbeidsflyten beskrevet i UC-04, inkludert avvikene 4a og 5a.»
Da får du fordelen av begge deler: forståelsen fra fortellingen, og etterprøvbarheten fra kravet. Se kravtekst som tåler å bli kontrakt.
Vanlige feil
- Skjermbilder beskrives. «Saksbehandler klikker på den blå knappen» er design, ikke oppførsel. Beskriv hva som oppnås, ikke hvordan det klikkes.
- Bare lykkelig utfall. Uten avvik er et use case en salgstekst.
- For mange. Førti use case leses av ingen. Ti gode leses av alle.
- Skrevet av prosjektgruppen alene. Avvikene kjenner bare de som gjør jobben. Se observasjon.