b'\n_START_ARTICLE_\nUsecase\n_START_PARAGRAPH_\nEen 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.\n_START_SECTION_\nOverzicht\n_START_PARAGRAPH_\nEen 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._NEWLINE_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. 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._NEWLINE_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.\n_START_SECTION_\nOntstaan\n_START_PARAGRAPH_\nHet 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._NEWLINE_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\xc3\xabnteerde gemeenschap, maar de toepasbaarheid van de methode is niet beperkt tot objectgeori\xc3\xabnteerde systemen, daar usecases zelf niet objectgeori\xc3\xabnteerd van aard zijn.\n_START_SECTION_\nToepasselijke gedetailleerdheid\n_START_PARAGRAPH_\nSommige softwareontwikkelingsprocessen behoeven niet meer dan enkele eenvoudige usecases om de requirements te defini\xc3\xabren. Echter, andere ontwikkelingsprocessen vereisen gedetailleerde usecases om deze requirements te defini\xc3\xabren. Hoe groter en complexer het project, hoe aannemelijker dat hier gedetailleerde usecases benodigd zijn._NEWLINE_De mate van details in een usecase zal vaak veranderen met de voortgang van het project. De initi\xc3\xable 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._NEWLINE_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.\n_START_SECTION_\nUsecasenotatie\n_START_PARAGRAPH_\nIn 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.\n_START_SECTION_\nUsecases en het ontwikkelingsproces\n_START_PARAGRAPH_\nDe 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.'