Use case, user story eller atomisk krav?

Et godt utgangspunkt er å se på f. eks. use cases og user stories (alternativt use cases og atomiske krav) som gjensidig utfyllende tilnærminger hverandre, og ikke som alternativer. Jeg hadde den sistnevnte oppfatningen inntil jeg deltok på et tredagers kurs i utforming av kravspesifikasjoner tidligere i år.

Kurset ble holdt av den velrenommerte og inspirerende Suzanne Robertson. Suzanne har sammen med James Robertson utviklet Volere kravspesifikasjonsmodell. Dette kurset ga noen tips til å velge form på krav som jeg har lyst til å dele.

Forstå forretningsområdet

Først en liten introduksjon til Volere-prosessen. Prosessen fokuserer på viktigheten av å forstå arbeidet som skal løses før man dykker ned i løsningsområdet.

For å oppnå dette anbefales det å identifisere forretningshendelser og deretter finne ut hvordan forretningen responderer på hendelsene, dvs. Business Use Case.

Definer hva produktet skal løse

Når man har fått en god forståelse for forretningsområdet og behovene som skal løses kan man bestemme hva som skal løses i produktet. Da utledes Product Use Case ut fra Business Use Case. Volere advarer mot å starte med Product Use Case før man har en god forståelse av forretningsprosessen.

A use case is a list of steps, typically defining interactions between a role and a system, to achieve a goal.

Wikipedia

Use Cases, User Stories eller atomiske krav

Jeg har vært med i prosjekt der vi har brukt use cases uten å skrive atomiske krav eller user stories i tillegg, men da med andre kravdokumenter som f. eks. skjermbildebeskrivelser i tillegg.

A user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function

Wikipedia

Jeg har også vært med i prosjekt hvor vi har brukt use case og atomiske krav i kombinasjon. En av utfordringene jeg opplevde med å bruke atomiske krav i tillegg til use cases var å bestemme hva skulle beskrives hvor, f.eks hvilke deler av use caset skulle uttrykkes som krav.

When you have a requirement that is measurable, testable, traceable and detailed enough to define all aspects of a need without further breakdown then you have an atomic requirement.

Volere

Jeg har ikke noe særlig erfaring med user stories, og min oppfatning har vært at user stories er et alternativ til use cases. Volere anbefaler imidlertid å bruke user stories eller atomiske krav i tillegg til use case, der ett steg i et use case omdannes til ett eller flere user stories eller atomiske krav.

User stories og atomiske krav er begge en måte å bryte opp use cases til enkeltkrav, altså ikke en erstatning til use cases men et supplement.

Hvilken form skal man velge?

Trenger vi både use cases og atomiske krav, og skal vi bruke user stories i stedet for atomiske krav, eller kanskje en kombinasjon av user stories og atomiske krav?

Jeg har erfart at atomiske krav er lettere å kommunisere med interessentene enn use case-beskrivelser. Ved å bruke atomiske krav (eller user stories) kommer hvert krav eksplisitt fram og er bl.a lettere å prioritere. Use casene vil være en hjelp til å finne kravene, samt til å gi et større overblikk over funksjonaliteten i systemet. Use casene vil også være nyttig når det er større scenarier som skal uttrykkes.

Og hva med User stories eller atomiske krav? Begge formene uttrykker krav, hvem som har behov for det, hvorfor samt godkjenningskriteria.

Det viktigste er tross alt at man finner de riktige kravene og at man kommuniserer dem på en måte som gir alle interessentene i prosjektet den samme forståelsen.