Et brukstilfelle beskriver hva en aktør skal få gjort i systemet — for eksempel «registrer nytt medlem».
Brukstilfellet beskriver et mål aktøren vil oppnå, og stegene dit — inkludert hva som skjer når noe går galt. Det er formulert utenfra, fra brukerens side, ikke innenfra fra systemets. En nyttig regel: et brukstilfelle er alltid en aktør som gjør noe med en entitet. «Saksbehandler registrerer medlem.» Klarer du ikke å formulere det slik, er enten aktøren eller entiteten uklar — og da er specen ikke ferdig. Brukstilfelle eller brukerhistorie? Begge deler — de svarer på hvert sitt spørsmål. Brukerhistorien er en samtaleåpner med et hvorfor («som saksbehandler vil jeg søke opp et medlem, slik at jeg raskt finner kontaktinfo»), og er med vilje ufullstendig: detaljene skal komme fram i dialogen underveis. Brukstilfellet handler om dekning — det lister aktør, funksjon og entitet uttømmende, inkludert avvikene. Hva om medlemmet ikke finnes? Hva om to har samme navn? Der bor overraskelsene i et prosjekt. Du kan ikke estimere fra brukerhistorier; de er designet for ikke å være komplette. Du estimerer fra brukstilfeller og prioriterer med brukerhistorier. AI har gjort dette skillet viktigere, ikke mindre viktig. Det smidige svaret på «vi kan ikke vite alt på forhånd» var: la være å prøve, oppdag det underveis. Det var riktig da bygging tok måneder. Når AI bygger det på en dag, er ikke byggingen flaskehalsen lenger — det er å vite hva som skal bygges. Og AI har ingen samtale å oppdage detaljene i. Den trenger dem oppgitt.
Relaterte begreper: Aktør · Brukerhistorie · Entitet · Funksjonelt krav