Encyclopedie
Begrippenlijst

Inleiding technisch gedeelte externe verantwoording

Uit Triple A Encyclopedie
Ga naar: navigatie, zoeken

In dit technische gedeelte van het functioneel ontwerp van de externe verantwoording vindt u de gedetailleerde uitwerking van de use cases, werkopdrachten, activiteitendiagrammen en functies, zoals opgesteld in de werkbijeenkomsten met de deskundigen van de instellingen.

Onderstaand figuur geeft de samenhang van de use cases voor de externe verantwoording weer.

Usecase Externe verantwoording.png

Een use case beschrijft het van buitenaf zichtbare gedrag van het systeem, vanuit het perspectief van de gebruiker. Een use case heeft een concrete aanleiding en een concreet resultaat, en beschrijft de processtappen van gebruikers van het systeem die moeten leiden tot dit concrete resultaat. De use cases zijn daarmee de eenheden van functionaliteit vanuit de gebruiker gezien. Het totaal aan use cases geeft antwoord op de vraag ‘wat moet het systeem ondersteunen?’.

Voor de beschrijving van een use case is een standaardformaat gebruikt dat is afgeleid van de binnen UML (Unified Modeling Language) gangbare manier van beschrijven. dit format wordt hieronder weergegeven.

Onderdeel Beschrijving
Naam Naam van de use case
Aanleiding De concrete aanleiding, voorwaarde of omstandigheid waarin deze use case start
Actoren De actoren (rollen) die betrokken zijn in de uitvoering van deze use case
Doel Het doel (van de actoren) met deze use case
Beschrijving van de acties Beschrijving van de achtereenvolgende acties/stappen die worden uitgevoerd om te komen van de aanleiding naar het resultaat
Resultaat Het concrete resultaat van deze use case voor de gebruiker
Frequentie Het aantal keer dat deze use case naar verwachting wordt doorlopen

Een use case staat niet op zichzelf. Er liggen vaak verbanden tussen de verschillende use cases, omdat het resultaat van de ene use case vaak de aanleiding is voor een andere. Deze verbanden noemen we werkopdrachten. Een werkopdrachtEen relatie tussen twee use cases waarbij het resultaat van de ene use case het startpunt is voor een andere use case. De relatie behelst niet het overdragen van gegevens. behelst niet het overdragen van gegevens, maar meer het initiëren van een andere use case. In bovenstaand procesmodel zijn de use cases in samenhang gebracht door werkopdrachten tussen de use cases te tekenen door middel van pijlen.

Vervolgens zijn de use cases nog een stap dieper uitgewerkt in een activiteitendiagram. In een activiteitendiagram wordt de beschrijving van de acties gemodelleerd zodat de logica van het proces preciezer is gedefinieerd en duidelijk is onder verantwoordelijkheid van welke actorGebruiker van het systeem in een specifieke rol of een ander systeem of technische voorziening die met het systeem communiceert. De actoren maken dus geen deel uit van het systeem maar interacteren met het systeem. Actoren zijn diegenen die gegevens met het systeem uitwisselen of diensten van het systeem betrekken. een activiteit wordt uitgevoerd. Er is per use case één activiteitendiagram gemaakt.

Onder de activiteitendiagrammen is per use case een opsomming van functies gemaakt. Dit zijn de functies die het systeem moet bieden om het beschreven proces te kunnen ondersteunen. Onder functies worden hier concrete onderdelen van een ICT-systeem verstaan, zoals schermen of rekenfuncties.

De laatste paragraaf van dit technisch gedeelte geeft een meer gedetailleerde beschrijving van de geïnventariseerde functies. Om tot deze functies te komen wordt uitgegaan van de activiteiten in de activiteitendiagrammen. Voor elke activiteit (of enkele opeenvolgende activiteiten) wordt vastgesteld welke ICT-functies nodig zijn om de betreffende activiteit uit te voeren. Zo ontstaat een verzameling functies die nodig is om de use case te ondersteunen. Sommige functies zijn voor meerdere activiteiten, in verschillende use cases toepasbaar.