Formål
Dette trin tjener til at beskrive hvem der skal kunne løse hvilke opgaver, præcisere funktionalitet og forankre det videre arkitektur-arbejde hos brugerne, ved at sikre at de bliver hørt og giver accept til at ”sådan vil vi gerne arbejde”.
Input
Interview/workshop med forretningssiden, herunder ikke mindst de der dagligt udfører de relevante arbejdsopgaver.
Input fra aktiviteterne Forretningsobjekter, Organisation/lokationer, Forretningsservices, Forretningsprocesser.
Output
Output er:
Use cases. Disse beskriver hvilke opgaver som aktører – mennesker og systemer – i samspil skal kunne løse. Use casene beskriver hvad der løses – ikke i nogen videre detalje hvordan dette foregår.
Metode
Use case teknikken hidrører fra UML metoden, og UML Use case notationsformen anvendes ofte her.
Metoden består typisk i at de ansvarlige arkitekter først laver udkast til de enkelte Use cases, og så gennem grundige workshops sikrer at brugerne forstår Use casene, og får afleveret deres input til disse: Hvordan de ser deres fremtidige arbejdssituation. Det er vigtigt at få opsamlet alle de ideer og forlag, der fremkommer, og at få disse dokumenteret, således at brugerne kan se, hvordan disse imødekommes i det videre forløb, hvor arkitekturen konkretiserer ønskerne i løsningsdesigns til applikationer og infrastruktur.
Det er vigtigt at Use casene afspejler et ønsket forløb, og at man ikke blot dokumenterer, hvad man kan i dag.
Man skal overveje detailniveauet i Use casene – det kan spænde fra meget overordnet til så detaljeret, at man nærmest kan designe et system efter det. Man kan med fordel oprette højniveau Use cases, og så nedbryde de kritiske af dem, ved at tilføje sub-Use cases.
Use cases og workflows er en dialogmekanismer, hvor aktørerne udtrykker sig i brugertermer, der så ”oversættes” til teknologikrav – ikke mindst til applikationsarkitekturen. Dette stiller store krav til den faciliterende arkitekt, at vedkommende skal kunne forstå begge verdener. Udviklingen af navnlig workflows vil ofte foregå i parallel med applikations- og informations-arkitektur designet.
Use cases er ofte et nyttigt værktøj til kravstyring. Man kan med fordel holde Use casene op imod den fremtidige løsning som arkitekturen foreslår, (specielt applikationsarkitekturen, for at sikre at brugernes ønsker rent faktisk mødes.
Gode råd
Det er essentielt, at de arkitekter der faciliterer opgaven, er i stand til at sætte sig i brugernes sted, og ikke tænke i teknologi, men i behov. Som ansvarlig for en Use case leverance bør man kun til en vis grad bruge sin teknologiske viden til at komme med forslag, men derimod i høj grad lytte til brugernes behov og ideer.
Et godt værktøj, når man skal sætte sig i brugernes sted er personas. Her er et par eksempler:
- Borger.dk har udviklet 12 generelle personas, dvs. arketyper, der beskriver den danske befolkning i forhold til at udvikle nye selvbetjeningsløsninger og informationsservices. De 12 personas kan anvendes frit og gratis til videreudvikling af lokale eller centrale selvbetjeningsløsninger.
- Virk.dk har udviklet nogle specialiserede personas målrettet processen virksomhedsregistrering (baseret på virk’s tilsvarendegenerelle personas).
Tænk-højt-test er et andet værktøj som kan tages i brug. Det er et brugervenlighedsværktøj, der går ud på at brugerne tester en (analog eller digital) prototype, mens de taler højt om deres oplevelser og tanker. Læs mere om tænk-højt test og download standardtest her.
Man kan med fordel navngive Use cases så de intuitivt og i aktivt sprog udsiger hvad Use cases forårsager: ”registrer borger”, ”arkiver sag”, osv.
Eksempel
