Een case voor de usecase

In de context van agile development wordt voor de specificatie van functionaliteit vaak rechtstreeks gegrepen naar user stories, waardoor een agile team vaak binnen zeer korte tijd aankijkt tegen een enorme stapel van user stories, die stuk voor stuk een promise for a future conversation inhouden. Moeten we dan niet die gesprekken maar eens gaan voeren? Wat doen we met de uitkomst van die gesprekken? Hoe voorkomen we dat we dezelfde gesprekken steeds weer opnieuw gaan voeren? Vanuit die gedachtegang werpen Jim Coplien en Gertrud Bjørnvig, in hun boek Lean Architecture for Agile Software Development, een case op voor de usecase.

Usecases beschrijven wat het systeem voor de gebruikers doet, c.q. wat gebruikers met het systeem doen. Het voornaamste doel is dat je op een hanteerbare manier vastgelegd krijgt wat je met alle betrokken sleutelfiguren hebt besproken over de functionaliteit en welke beslissingen daarover zijn genomen, zodat je een basis hebt om het systeem mee op te bouwen en te testen, maar ook om het systeem mee te onderhouden/aan te passen/uit te breiden.

Een usecase gaat over een doel dat een gebruiker met het systeem wil bereiken. Om te beginnen is daarom inzicht nodig in de verschillende soorten gebruikers van het systeem. Leg voor elk type gebruiker een naam en een eenduidige omschrijving vast waar alle stakeholders zich in hebben kunnen vinden.

Naast de namen en omschrijvingen van de gebruikers is het ook goed om een treffende naam voor het systeem te kiezen en liefst ook een korte, maar heldere probleemdefinitie. De probleemdefinitie geeft heel expliciet aan wat het gat is tussen de huidige situatie en de gewenste situatie, dat het systeem moet gaan opvullen. Zo’n uitgeschreven en zichtbaar gedeelde probleemdefinitie geeft steeds veel focus voor alle betrokkenen.

Vanuit deze context (systeemnaam, probleemdefinitie, naam en omschrijving per gebruikerstype) kan je snel tot een helicopterview van het systeem komen, door voor elke type gebruiker z’n voornaamste doelen op te sommen. De genoemde doelen vormen dan de namen van usecases, want een usecase gaan over een doel dat een gebruiker met het systeem wil bereiken.

Bijvoorbeeld in het geval van de Groenland Bank, een nieuw onlinesysteem voor een fictieve bank, zou een eerste helicopterview er zo uit kunnen zien:

Rekeninghouder
Recente transacties bekijken
Geld overschrijven
Rekeningafschriften afdrukken
Terugkerende betaling toevoegen
Nota betalen

Niet alleen in dit voorbeeld, maar ook in de werkelijke praktijk is het nadrukkelijk de bedoeling om de helicopterview simpel en compact te houden. Het aantal doelen per gebruiker blijft ook bij complexe systemen beperkt, omdat de complexiteit niet zozeer zit in het aantal usecases, maar in de variatie binnen de verschillende usecases. Per usecase beschrijven we namelijk om te beginnen als basis een mooiweerscenario dat later wordt aangevuld met losstaande beschrijvingen van anomalieënafwijkingen van het mooiweerscenario. Het systeem wordt complexer naarmate er meer anomalieën geïmplementeerd worden.

Voordat het mooiweerscenario wordt uitgewerkt, leggen we van een nieuwe usecase eerst de volgende zaken vast (zoals ze met alle sleutelfiguren samen besproken zijn):

  • Businessmotivatie
  • Gebruikersintentie
  • Preconditie
  • Postconditie

Bijvoorbeeld voor de Geld overschrijven usecase van de Groenland Bank:

Businessmotivatie
Als onderdeel van onze strategie Stel de klant in staat z’n bankzaken thuis te regelen zien we het overschrijven van geld als een belangrijke dienst. De Rekeninghouder kan z’n rekeningen in de gaten houden en geld overschrijven naar een rekening waar het saldo te laag van wordt of waarvan de Rekeninghouder dat binnenkort verwacht. Het kan ons (de bank) de tijd besparen om brieven te sturen over te lage saldo’s en het kan ook voorkómen dat we rekeningen moeten sluiten en ze later weer heropenen. Als aanvulling zouden we ook graag zien dat de Rekeninghouder geld kan overschrijven naar rekeningen van andere Rekeninghouders – zowel binnen onze eigen bank als van en naar andere banken. Onze concurrenten bieden die diensten al aan en we kunnen daar zelf niet veel langer mee wachten.
Gebruikersintentie
Als Rekeninghouder wil ik geld kunnen overschrijven tussen mijn rekeningen, zodat ik ervoor kan zorgen dat ik nergens roodsta en mijn betaalpas wordt geblokkeerd.
Preconditie
De Rekeninghouder is ingelogd bij de Groenland Bank en een overzicht van z’n rekeningen wordt getoond op het scherm.
Postconditie
Het bedrag dat de Rekeninghouder heeft ingevoerd is verplaatst van de bronrekening naar de bestemmingsrekening. De twee rekeningen zijn in balans en de transactielogs zijn bijgewerkt.

Het mooiweerscenario wordt nu als volgt beschreven:

  • In een tabel met kolommen voor Stapnummers, voor de Gebruikersintentie, voor de Systeemverantwoordelijkheid, en voor Commentaar.
  • Elke stapbeschrijving begint met de gebruikersnaam/de systeemnaam.
  • De gebruikte terminologie is weloverwogen gekozen en wordt consistent toegepast. Het is aan te bevelen om een begrippenlijst bij te houden waarin de gebruikte termen worden gedefinieerd. Deze begrippen vormen feitelijk bouwstenen voor de architectuur van het systeem.
  • Eventuele toelichtingen, besluiten, open discussiepunten en nieuwe vragen worden genoteerd in de kolom Commentaar.

Bijvoorbeeld weer voor de Geld overschrijven usecase van de Groenland Bank zou het mooiweerscenario er als volgt uit kunnen zien:

Stap Gebruikersintentie Systeemverantwoordelijkheid Commentaar
1 De Rekeninghouder selecteert een bronrekening en kiest voor Overschrijven. De Groenland Bank toont de bronrekening, een lijst van bestemmingsrekeningen en een veld om het bedrag in te voeren. Moet de Rekeninghouder eerst voor Overschrijven kiezen en dan de bestemmingsrekening, of omgekeerd?

De lijst van bestemmingsrekeningen is standaard: de eigen rekeningen van de Rekeninghouder, met uitzondering van de bronrekening

2 De Rekeninghouder kiest een bestemmingsrekening, voert het bedrag in en accordeert. De Groenland Bank toont de overschrijvingsgegevens (bronrekening, bestemmingsrekening, datum, bedrag) en vraagt een wachtwoord om de overschrijving te bekrachtigen. De standaarddatum is de huidige datum.
3 De Rekeninghouder voert het wachtwoord in en accordeert de overschrijving. De Groenland Bank verplaatst geld, werkt de boeken bij en toont een transactiebewijs. Routine: Geld verplaatsen en boeken bijwerken.

Is transactiebewijs de juiste term?

Is een transactiebewijs wel nodig als de transactie tussen twee eigen rekeningen is?

Moet de Rekeninghouder het transactiebewijs kunnen printen?

In stap 3 wordt verwezen naar een routine; dat is een opeenvolging van systeemacties, die in verschillende usecases op dezelfde manier gebruikt kan worden. Voor een routine worden geen businessmotivatie of gebruikersintentie beschreven, want die volgen uit de betreffende usecase (en die verschillen dus ook voor de verschillende usecases die de routine gebruiken). Routines kennen ook geen anomalieën; het zijn eenduidige stukjes lopendebandwerk. Van elke routine worden vastgelegd:

  • Naam
  • Preconditie
  • Stappen
  • Postconditie

De definitie van de routine Geld verplaatsen en boeken bijwerken in de Groenland Bank is bijvoorbeeld als volgt:

Preconditie
Een geldige bronrekening en bestemmingsrekening zijn bekend, evenals het bedrag dat moet worden overgeschreven.
Stappen
  1. Groenland Bank verifieert voldoende saldo;
  2. Groenland Bank werkt de rekeningen bij;
  3. Groenland Bank werkt de gegevens voor de rekeningafschriften bij.
Postconditie
De periodieke rekeningafschriften geven de precieze aard van de transactie weer (een overschrijving is een overschrijving – niet een combinatie van een opname en een storting)

Zoals gezegd zullen in verdere discussies over de usecase allerlei afwijkingen van het mooiweerscenario naar boven komen – de anomalieën. Het aardige is nu dat je in de beschrijving van elke anomalie kan verwijzen naar een specifieke stap in het mooiweerscenario.

De lijst van anomalieën binnen de Geld overschrijven usecase van de Groenland Bank zou er op een bepaald moment bijvoorbeeld als volgt uit kunnen zien:

Stap Ref Afsplitsende actie Commentaar
1a De Rekeninghouder voegt een tekst toe aan de transactie op de bronrekening. Hoort dit niet in het mooiweerscenario?

Wat is de standaardtekst als de Rekeninghouder geen tekst toevoegt?

1b De Rekeninghouder wil overschrijven naar een rekening van een andere klant. De Rekeninghouder moet de naam en het rekeningnummer invoeren.
1c De Rekeninghouder wil een andere rekening van de Rekeninghouder toevoegen aan de bestemmingenlijst. De Rekeninghouder kan de rekening een naam geven (verplicht?)
2a Er staat niet genoeg geld op de bronrekening om de overschrijving te doen. Toon een foutmelding en draai de transactie terug. (Wie gaat er over meldingen aan de Rekeninghouder? Definieer minimaal saldo?)
2b De Rekeninghouder voegt een tekst toe aan de transactie op de bestemmingsrekening. Hoort dit niet in het mooiweerscenario?

Wat is de standaardtekst als de Rekeninghouder geen tekst toevoegt?

2c Het bedrag voldoet niet aan de validatieregels. Validatieregels?
2d De Rekeninghouder voert een toekomstige datum in voor de overschrijving. De Groenland Bank biedt de mogelijkheid om een toekomstige datum in te voeren. De overschrijving zal plaatsvinden op die dag, volgens bankdagen. (Hoe ver in de toekomst mag de datum liggen?)
3a Incorrect wachtwoord. Blokkeren?
3b De transactie is langer bezig dan de maximaal geoorloofde tijdsduur. Mogelijke oorzaken voor langere tijd? Welke acties als dit gebeurt? Wat is de maximaal geoorloofde tijdsduur?
3c De transactie faalt Mogelijke oorzaken voor falen? Welke herstelacties? Toepasselijke meldingsteksten?
Alle De Rekeninghouder zoekt online hulp. Wie is verantwoordelijk voor online hulp?

Wanneer tijdens discussie over een usecase een anomalie boven komt drijven, is het aan te bevelen om die meteen te noteren, zodat die discussie later niet opnieuw gevoerd hoeft te worden. Niet alle beschreven anomalieën moeten per se geïmplementeerd worden – per release bepaal je welke mooiweerscenario’s van nieuwe usecases en welke anomalieën van bestaande usecases je wil toevoegen (dit is een businessbeslissing). Van elke usecase is het mooiweerscenario het eerste dat wordt geïmplementeerd, als basis voor verdere uitbreidingen. Een enkele anomalie zal in de eerste release al meteen meekomen, andere volgen in latere releases, sommige blijven steeds weer op de plank liggen, terwijl ondertussen alweer nieuwe gevallen worden toegevoegd – het aantal anomalieën per usecase is in principe onbegrensd.

Met het stabiele mooiweerscenario en de variatie in de anomalieën, focus je met de usecase de verdere discussie steeds richting geïnformeerde, weloverwogen beslissingen over altijd weer nieuwe functies en features, uitbreidingen, uitzonderingen, alternatieven, foutafhandeling en nonfunctional requirements.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s