Om användningsfall

Nedan är ett utdrag från en mailkonversation om användningsfall som jag haft med en kund.

Ang. aktörer:
Ett tips är att börja varje punkt med orden ”aktören … ” eller ”systemet …”. Då blir ansvaret tydligt. Upptäcker man då att aktören inte finns med någonstans så är det ingen aktör (om det inte är den som triggar användningsfallet).

Ang. initiering/trigger:

Triggern är den händelse som initierar exekvering av användningsfallet.

Ang. startvillkor:
Startvillkoren är förutsättningar för att triggern ska ge effekt. Ett exempel på skillnaden mellan trigger och startvillkor.

  • Trigger: ”någon trycker på hissens öppna-knapp”
  • Startvillkor: ”Hissen har stannat på den aktuella våningen”

Ovanstående innebär att man kan trycka på öppna-knappen hur ofta man vill, men inget kommer att hända förräns hissen har stannat på rätt våning, och i detta fall så medför ovanstående också att inget händer bara för att hissen har stannat på rätt våning. Det är först när man trycker på ”öppna-knappen” som dörrarna går upp.

Ett annat exempel:

  • Trigger: ”Produktsystemet skickar ett bokföringsunderlag”
  • Startvillkor: ”Kund är registrerad i systemet”

Poängen av att använda sig av startvillkor är att man slipper en massa logik och kontroller i själva användningsfallet vilket gör det kortare, enklare och mer lättläst. I ovanstående exempel så behöver man till exempel aldrig beskriva kontroll och hantering av bokföringsunderlag med kunder som inte är registrerade i systemet eftersom dessa aldrig kommer att förekomma i användningsfallet. Observera att ovanstående dock inte innebär att man slipper speca kraven för hur dessa skall hanteras, det innebär bara att man inte behöver beskriva det i just detta användningsfall. Ett bra sätt att identifiera vad som är en trigger är genom att börja med ”användningsfallet startar när…”

Ang. slutvillkor:
Slutvillkor är inte alltid samma sak som önskat resultat. Jag tycker det är bra att ha med både och. Slutvillkor kallas ibland också ”minimal success guarantee” och beskriver villkor som alltid skall vara uppfyllda för att användningsfallet skall kunna avslutas.

Exempel:
Slutvillkor: ”systemet är redo att ta emot en ny transaktion”, ”kundreskontrans integritet är intakt”, ”transaktionen är avslutad”, ”produktsystemet är informerat om transaktionens resultat”.

Fördelen med att beskriva slutvillkor är de på ett verksamhetsnära sätt beskriver en massa tekniska regler och annan mumbo jumbo som utvecklaren måste ta höjd för innan han avslutar användningsfallet.

Andra åsikter:

En bra grundprincip för ett användningsfall är att det skall kunna utföras av en person vid ett tillfälle. Jag såg att det var något användningsfall som väntade in en återrapportering från bgc. Står systemet och väntar på denna återrapportering? I annat fall kanske man kan dela upp det i två användningsfall.

En bra rubrik som jag brukar ha på slutet är ”scenarios” där har jag en tabell som listar alla möjliga varianter av användningsfallet. Ex:

  • Scenario 1 = Huvudflödet
  • Scenario 2 = Huvudflöde + Alternativflöde 1
  • Scenario 3 = Huvudflöde + Alternativflöde 1 + Alternativflöde 2
  • Scenario 4 = Huvudflöde + Alternativföde 2

Poängen med detta är att man på ett enkelt sätt kunna komplettera användningsfallet med information om frekvens och prioritet, dvs
Scenario 1 exekveras 100.000 gånger per natt och har prioritet 1
Scenario 2 exekveras 5 gånger per natt men har också prioritet 1
Scenario 3 exekveras 10.000 gånger per natt men har pioritet 2.

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *

Följande HTML-taggar och attribut är tillåtna: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>