Usecase

Een usecase in software engineering en systems engineering is een beschrijving van een gedrag van een systeem, dat reageert op een verzoek dat stamt van buiten het systeem. Met andere woorden, de usecase beschrijft "wie" met het betreffende systeem "wat" kan doen. De usecasetechniek wordt gebruikt bij de bepaling van de requirements van het gedrag van een bepaald systeem.

Een usecase beschrijft een systeem vanuit het gebruikersperspectief. Het beschrijft de actor, de initiator van de interactie, en het systeem zelf als een opeenvolging van eenvoudige stappen. Actoren kunnen iets of iemand zijn, die bestaat buiten het te bestuderen systeem, en die deelneemt in de opeenvolgende activiteiten in een dialoog met het systeem om een bepaald doel te bereiken. Actoren kunnen eindgebruikers, andere systemen of hardware (apparatuur) zijn. Elke usecase is een complete serie van zogenaamde "events", beschreven vanuit het standpunt van de actor.^[1]

Volgens Bittner en Spence (2002) zijn usecases eenvoudigweg een beschrijving van een reeks gebeurtenissen, die met elkaar het systeem in staat stellen iets bruikbaars te doen.^[2] Elke usecase beschrijft hoe de actor zich zal gedragen ten opzichte van het systeem om een doel te bereiken. Van een enkele usecase kunnen meerdere scenario's worden gegenereerd, corresponderend met elke weg om een doel te bereiken. Bij het opstellen van usecases wordt doorgaans technisch jargon gemeden, en wordt aangesloten bij de taal van de eindgebruiker. Ze worden vaak opgesteld in samenwerking tussen een systeemanalist en de eindgebruiker. In de Unified Modeling Language kunnen usecasediagrammen gebruikt worden om de usecases van een gegeven systeem grafisch weer te geven.

In systems engineering worden usecases veelal op een hoger abstractieniveau gedefinieerd dan binnen software engineering, om de missies van een systeem of de doelen van een stakeholder weer te geven. Gedetailleerde requirements kunnen hierbij worden weergegeven in SysML requirement-diagrammen of vergelijkbare schematechnieken.

Het begrip "usecase" werd halverwege de jaren 1980 bedacht door Ivar Jacobson en stamt af van het oudere begrip "usage scenario", ofwel gebruiksscenario. Jacobson begon in 1967 bij Ericsson met het schrijven van gebruiksscenario's bij de beschrijving van de architectuur van Ericssons AXE-systeem. In de jaren 1980 ging Jacobson nadenken over zijn werkwijze en kwam met het Zweedse begrip "anvendningsfall", wat ongeveer staat voor "situatie van gebruik". Direct vertaald naar het Engels zou dit "usage case" worden, maar hij vond dat deze beide termen niet natuurlijk klonken. Uiteindelijk was hij wel tevreden met het begrip "usecase". In 1986 formuleerde Jacobson ook de eerste visuele modelleertechniek voor de specificatie van usecases.^[3]

Sinds Jacobson het usecasemodel ontwikkelde hebben velen bijgedragen aan de verbetering van deze techniek, waaronder Kurt Bittner, Alistair Cockburn, Gunnar Overgaard en Geri Schneider. Tijdens de jaren 1990 werd de usecase een van de gebruikelijke methoden om functionele requirements vast te leggen. Dit was vooral het geval in de objectgeoriënteerde gemeenschap, maar de toepasbaarheid van de methode is niet beperkt tot objectgeoriënteerde systemen, daar usecases zelf niet objectgeoriënteerd van aard zijn.

Elke usecase focust op de beschrijving hoe een doel kan worden bereikt, of een taak kan worden uitgevoerd. Voor de meeste softwareprojecten betekent dit dat verschillende, soms tientallen, usecases benodigd zijn voor de definitie van de scope van een nieuw systeem. De mate van formalisering van een bepaald softwareproject en het stadium van ontwikkeling is bepalend voor de vereiste gedetailleerdheid van elke usecase. Usecases moeten niet worden verward met de eigenschappen van het te ontwikkelen systeem. Een usecase als gebruikt scenario kan gerelateerd zijn aan een of meerdere eigenschappen, en een eigenschap aan een of meerdere usecases.

Een usecase definieert de interactie tussen externe actoren en een bepaald systeem om een doel te bereiken. Een actor specificeert een rol, die gespeeld wordt door een persoon of ding, in wisselwerking met het systeem.^[4] Dezelfde persoon, die het systeem gebruikt, kan worden weergegeven met verschillende actoren indien de persoon meerdere rollen vervult. Bijvoorbeeld, een persoon "Jan" kan de rol spelen van klant als hij geld aan een geldautomaat onttrekt, en kan de rol vervullen van bankmedewerker, die de geldautomaat bijvult.

Usecases behandelen het systeem als een zwarte doos, en interacties met het systeem inclusief de systeemrespons, worden opgevat als komende van buiten het systeem. Dit is een bewuste keuze, om de analist zich te laten concentreren op wat het systeem moet doen, en niet hoe het gedaan wordt. Hiermee kan men voorkomen, dat men aannamen gaat maken over de functionaliteit van het systeem om zijn taken te vervullen. Usecases kunnen beschreven worden op een abstract niveau, ook wel een "businessusecase" of een "essentiële usecase" genoemd, en op systeemniveau, een "systeemusecase". Het verschil zit hierbij in de scope:

• De businessusecase wordt beschreven in een niet-technische terminologie, waarbij systemen worden beschouwd als zwarte dozen, en beschrijft het bedrijfsproces dat gebruikt wordt door zijn bedrijfsactoren (mensen of systemen buiten het proces) om hun doel te bereiken (bijvoorbeeld handmatige betalingsbewerking, uitgave rapportage goedkeuring, beheer van onroerend goed van het bedrijf). De businessusecase beschrijft een proces dat waarde toevoegt aan de bedrijfsactor, en beschrijft wat het proces doet. Een andere methode van bedrijfsbeschrijving op dit niveau is bijvoorbeeld Business Process Modeling Notation (BPMN)

• De systeemusecase beschrijft een systeem dat een businessusecase of proces automatiseert op een niveau van systeemfunctionaliteit (bijvoorbeeld 'creëer toegangskaart') en specificeert de functie of dienst, die het systeem biedt voor de eindgebruiker. Een systeemusecase beschrijft wat het systeem doet als reactie op de actor. Om deze reden wordt aanbevolen om de specificatie van deze usecase met een werkwoord te beginnen (bijvoorbeeld creëer toegangskaart, selecteer betaling, voer betaling uit, blokkeer toegangskaart).

In het algemeen moet een usecase:

• beschrijven wat een systeem moet doen voor een actor om een bepaald doel te bereiken.
• opgesteld zijn in een implementatie onafhankelijke specificatie taal
• een toepasselijke mate van gedetailleerdheid hebben
• Geen details bevatten omtrent user interfaces of beeldopbouw. Dit gebeurt pas bij het user interface ontwerp.

Cockburn (2001) heeft drie niveaus geïdentificeerd voor de mate van gedetailleerdheid in het schrijven van usecases:^[5]

• Korte usecase (Brief Use Case): bestaat uit een paar zinnen, die de usecase samenvatten. Dit zou in een spreadsheet cel passen, waarbij in de andere kolommen zaken worden aangegeven als prioriteit, technische complexiteit, nummer, en zo voort.
• Gewone usecase (Casual Use Case): bestaat uit enige paragrafen tekst, die de usecase samenvatten.
• Volledig ingevulde usecase (Fully dressed use case): dit is een formeel document gebaseerd op een gedetailleerd model met velden voor verschillende secties. Dit is de meest gebruikelijke betekenis van het usecaseidee.

Sommige softwareontwikkelingsprocessen behoeven niet meer dan enkele eenvoudige usecases om de requirements te definiëren. Echter, andere ontwikkelingsprocessen vereisen gedetailleerde usecases om deze requirements te definiëren. Hoe groter en complexer het project, hoe aannemelijker dat hier gedetailleerde usecases benodigd zijn.

De mate van details in een usecase zal vaak veranderen met de voortgang van het project. De initiële usecases kunnen kort zijn, maar worden gedetailleerder naarmate het ontwikkelingsproces verder uitpakt. Dit weerspiegelt zich ook in de veranderende requirements van de usecase. In het begin hoeven zij alleen kort te zijn om de bedrijfs requirements vanuit het gebruikersperspectief samen te vatten. Verderop in het proces hebben ontwikkelaars meer specifieke en gedetailleerde richtlijnen nodig.

In het Rational Unified Process worden ontwikkelaars uitgenodigd om korte usecases in usecasediagrammen te beschrijven, met een gewone beschrijving als commentaar, en een gedetailleerde beschrijving van de stroom van events in een tekstuele analyse. Dit alles kan meestal ingevoerd worden in een usecasetool (bijvoorbeeld een UML Tool of SysML tool), of kan uitgewerkt worden op een aparte tekstverwerker.

In de Unified Modeling Language wordt de relatie tussen alle usecases en actoren weergegeven in usecasediagrammen, of in diagrammen die zijn gebaseerd op Ivar Jacobson's Objectory notatie. SysML, een UML profiel, gebruikt dezelfde notatie op het systeemusecaseniveau.

De specifieke wijze waarop usecases in een ontwikkelingsproces gebruikt worden, hangt ook af van de gebruikte ontwikkelingsmethodologie. In bepaalde methodieken is alleen een korte usecaseverkenning voorgeschreven. In andere methodieken veranderen usecases mee met het karakter van het ontwikkelingstraject. En in weer andere methodieken kan de usecasebeschrijving eenvoudig beginnen en uitmonden in een zeer gedetailleerde beschrijving van de benodigde testprocedures.

Er zijn geen standaard sjablonen voor de documentatie van gedetailleerde usecases. Er is een aantal concurrerende schema's. Individuen worden aangemoedigd om usecasesjablonen te gebruiken die voor henzelf of het project goed werken. Standaardisatie binnen een project is belangrijker dan de details van een specifiek sjabloon. Er is echter wel aanzienlijke overeenstemming over de centrale secties. Naast de uiteenlopende terminologie en ordeningsprincipes zijn er basale overeenkomsten tussen de meeste usecases. Verschillende sjablonen gebruiken vaak toegevoegde secties, bijvoorbeeld aannamen, uitzonderingen, aanbevelingen, technische requirements. Er zijn ook vaak industrie specifieke secties. Gemeenschappelijke bouwstenen in usecases zijn:

• Usecasenaam: Een usecasenaam levert een unieke identificatie voor de usecase.
• Versie: Een versie is van belang om de lezer inzicht te geven in het stadium dat de usecase heeft bereikt.
• Doel: Een doel beschrijft in het kort, wat de gebruiker met de usecase wenst te bereiken
• Samenvatting: Deze sectie bevat de essentie van de usecase, en geeft een overzicht.
• Actoren: Een actor is iemand of iets buiten het systeem, dat een interactie aangaat met het systeem.
• Precondities: Een sectie die alle condities definieert, die waar dienen te zijn.
• Triggers: Een sectie beschrijft de gebeurtenissen (events), waardoor de usecase geïnitieerd wordt
• Basis verloop van de events: een primair scenario, of verloop van de gebeurtenissen
• Alternatieve wegen: Secundaire wegen of alternatieve scenario's
• Post condities: Beschrijving van de eindtoestand van het systeem na het verloop van de usecase.
• Business rules: Geschreven of ongeschreven regels of beleid, die bepalen hoe een organisatie dient te reageren op een bepaalde usecase.
• Notes: Belangrijke aantekeningen, die niet in de vooropgezette format passen.
• Auteur en datum

• User story
• Activiteitendiagram
• Applicatie-architectuur
• Functional size measurement methoden
• Rational Unified Process
• Requirements analyse
• Unified Modeling Language

• Hoe use cases houvast kunnen geven door Rozalinde Kriens, 10 april 2008.