de opzet
- doelen
- literatuur
  - 2008-9
  - 2009-10
  - 2010-11
  - 2011-12
  - 2012-13
  - 2014-15
- planning
  - 2008-9
  - 2009-10
  - 2010-11
  - 2011-12
het verhaal
het werk
- aankondigingen
  - 2008-9
  - 2009-10
  - 2010-11
  - 2011-12
  - 2012-13
  - 2013-14
  - 2014-15
- werkstuk
supplement
- 2008-9
  - casusvnmr
  - sheets
- 2009-10

Analyse voor Claus international

Werkstuk Requirements Engineering

Thomas de Bel, Ronnie Swanink, Bart van de Put, Tom Nikken

Onderwijsinstituut voor Informatica en Informatiekunde

Radboud Universiteit Nijmegen

version 18 februari 2022

Page Break

Introduction

Claus International is een non-profit organisatie die in de decembermaand cadeaus verspreidt naar kinderen over de hele wereld. De werkwijze van Claus International is echter redelijk verouderd, en is hard aan vernieuwing toe om de werkdruk te verlagen en om het bedrijf te redden van een financiële ondergang door een steeds verder krimpend publiek. In dit document wordt een aantal wijzigingen beschreven die de systemen die Claus International nu gebruikt moeten versnellen, en het mogelijk moeten maken om meer klanten aan te trekken in de toekomst.

Wij hebben de vraag van Claus International om een nieuw informatiesysteem geanalyseerd en hebben een ontwerp gemaakt voor een informatiesysteem dat deze problemen oplost. In dit document wordt beschreven:

Een analyse van de stand van zaken en de problemen die spelen bij Claus International.
Een analyse van de functionaliteiten die in het informatiesysteem nodig zijn.

Voor de beschrijving van de analyse van de functionaliteiten wordt gebruik gemaakt van Use Cases. Een Use Case is een document dat één van de functionaliteiten van een systeem stap-voor-stap beschrijft. Per Use Case worden er vervolgens voorbeelden gegeven voor een mogelijke invulling van die Use Case aan de hand van zogenaamde Scenario's. Ook is er per use case een datamodel gemaakt, beschreven met ORM.

Er zal worden ingegaan op de eisen waar een dergelijk systeem aan zou moeten voldoen. Er wordt gekeken naar wat de basisfunctionaliteit is, welke mensen hier een rol in spelen en hoe de interactie tussen gebruikers en het systeem verloopt. Verder wordt er gekeken naar of er eisen zijn waar aan moeten worden voldaan.

Problem statement

In de huidige situatie verloopt alle communicatie tussen lokale distributiecentra en het administratieve hoofdkantoor geheel via post. Dit is een langzame en arbeidsintensieve manier van communicatie. Door deze langzame communicatie loopt de centrale administratie eigenlijk altijd achter, en kan het bedrijf niet goed zijn werk doen. Iedereen die gegevens wil veranderen, zich wil inschrijven of een donatie wil doen moet op het moment nog naar een van de lokale distributiecentra om dit te regelen. Een groot nadeel hiervan is dat hierdoor een kleiner publiek kan worden bereikt. Klanten moeten dus een hoop moeite doen om de diensten van Claus International te gebruiken. Hierdoor blijven donaties en nieuwe klanten weg. Op dit moment is het ook nog zo dat er bij inschrijven gecommuniceerd moet worden om te controleren of een kind wel daadwerkelijk bij een ouder hoort. Dit is een omslachtig en arbeidsintensief proces, en draagt ook bij aan de administratieve achterstand.

Case analysis

Stakeholder analysis

Hieronder staan een aantal stakeholders beschreven. Stakeholders zijn (fictieve) gebruikers die een distinctieve rol hebben in het huidige systeem, en welke ook een rol gaan spelen in het nieuwe systeem.

Naam	Rol	Beschrijving
Meneer S. Claus	Management	Meneer S. Claus wil dat de administratie op orde is zodat er geen cadeautjes op verkeerde plekken terecht komen.
Medewerker A	Medewerker administratief hoofdkantoor	Deze medewerkers zijn verantwoordelijk voor het verwerken van de binnenkomende post van de distributiecentra. Zij werken de administratieve database bij. Deze medewerkers regelen ook de distributie van de cadeaus naar de lokale distributiecentra.
Medewerker B	Medewerker distrubutiecentrum	De medewerkers in de distributiecentra zijn het gezicht naar de klanten toe. Zij nemen nieuwe registraties en wijzigingen aan. Deze sturen zij per post op naar het administratieve hoofdkantoor. Ook zijn zij verantwoordelijk voor het ontvangen van de hoeveelheden cadeaus en het verspreiden van deze cadeaus over het lokale publiek.
Peter Hendriks	Ouder	Ouders zijn de gebruikers van het systeem. Zij melden hun kinderen aan en zorgen ervoor dat Claus International op de hoogte is van hun wensen.

Mission and vision statement

Mission: Ons doel is om de communicatie binnen het bedrijf makkelijker te maken. We willen de interne en externe communicatie van Claus International versnellen en vereenvoudigen.

Vision: Wij denken dit doel te bereiken door alle berichtgeving via een centraal systeem te laten verlopen. Hiermee hoeft de klant niet meer naar een van de lokale distributiecentra om zijn/haar gegevens door te geven aan Claus International of om donaties te maken. De communicatie tussen lokale distributiecentra en het administratieve hoofdkantoor hoeft niet meer per post, waardoor de administratie veel meer up-to-date is.

Values: We vinden het belangrijk dat het proces doorzichtig is voor onze klant en dat de klant een goed idee heeft van wat het uiteindelijke product gaat worden.

Statement of work

Deliverable	DeliverbleType	Façade	Filled	Focused	Comment
Introduction	Contextual	Preliminary version	Preliminary version	Complete	Keep it short at first, only a sketch; nice, clear and complete at the end.
Status:	Contextual	100%	100%	100%	-
Problem statement	Key deliverable	As good as possible	As good as possible	Complete
Status:	Key deliverable	100%	100%	100%	-
Stakeholder list/analysis	Contextual	As good as possible	As good as possible	Complete
Status:	Contextual	100%	100%	100%	-
Mission-Vision-(Values)	Contextual	Complete	Complete	Complete
Status:	Contextual	100%	100%	100%	-
Statement of Work	Contextual	Complete, and up-to-date	Complete, and up-to-date	Complete, and up-to-date
Status:	Contextual	100%	100%	100%	-
Risk Analysis	Contextual	Complete, and up-to-date	Complete, and up-to-date	Complete, and up-to-date
Status:	Contextual	100%	100%	100%	-
Use Case Survey	Key deliverable	As good as possible	Nearly complete	Complete
Status:	Key deliverable	100%	100%	100%	-
Integrated UC Diagram	Key deliverable	Complete (though preliminary)	Complete	Complete	One for whole project
Status:	Key deliverable	100%	100%	100%	-
Use Cases	Key deliverable	Not yet!	"Filled" level	Complete
Status:	Key deliverable	Not yet!	100%	100%	-
Scenarios	Key deliverable	Not yet!	Several for each UC	Complete ("focused" level)
Status:	Key deliverable	Not yet!	100%	100%	-
Domain Models	Key deliverable	Not yet!	Partially complete	Complete	One for each UC
Status:	Key deliverable	Not yet!	100%	100%	-
Business rules per UC	Key Deliverable	Not yet!	Partially complete	Complete
Status:	Key Deliverable	Not yet!	100%	100%	-
Integrated Domain Model	Key deliverable	Not yet!	First draft	Complete	One for whole project
Status:	Key deliverable	Not yet!	100%	100%	-
Busines Rules Catalogue	Key deliverable	Not yet!	Partially complete	Complete
Status:	Key deliverable	Not yet!	100%	100%	-
Non-functional Requirements	Key deliverable	Not yet!	Partially complete	Complete
Status:	Key deliverable	Not yet!	100%	100%	-
Terminological Definitions	Key deliverable	Notes	Partially complete	Complete
Status:	Key deliverable	100%	100%	100%	-
Executive sponsor viewpoint	Implicit deliverable	Complete	Complete	Complete	Integrated in M-V-(V)!
Status:	Implicit deliverable	100%	100%	100%	-
Use case tests	Implicit deliverable	Not yet!	As good as possible	Complete	Integrated in scenarios; to be done, but not written down explicitly as a separate item
Status:	Implicit deliverable	Not yet!	100%	100%	-

Risk analysis

#	Category	Risk	Solution needed by	Status	Days lost	Expectancy factor	Risk factor
01	Team	Uitvallen teamlid	2 dagen	n.v.t.	3	3%	0.09
02	Opdrachtgever	Uitvallen opdrachtgever	5 dagen	n.v.t.	6	10%	0.6
03	Communicatie	Miscommunicatie opdrachtgever	3 dagen	n.v.t.	5	50%	1.5
04	Project	Toevoeging eisen	3 dagen	n.v.t.	5	2%	0.1
05	Communicatie	Miscommunicatie team	1 dag	n.v.t.	1	75%	0.75

Requirements

Use cases

In dit onderdeel worden de use cases beschreven. Als eerste is er een overzicht te zien van welke use cases er allemaal zijn opgesteld voor dit project. Vervolgens is er een diagram opgesteld waarop te zien is hoe deze use cases uiteindelijk worden gebruikt door de eindgebruikers van het systeem. Als laatste zijn de volledige uitwerkingen van de use cases gegeven.

De use cases zijn een belangrijk deel van de eisen. Niet alleen geven de use cases de basis aan van hoe het nieuwe systeem zou moeten werken, maar daarnaast geven ze ook mogelijkheden om uiteindelijk te testen of een gebouwd systeem ook voldoet aan de aanvankelijk opgestelde eisen. Binnen het project voor Claus International is er conform aan de opdracht gefocust op het verwerken van de gegevens van de verzorgers en hun kinderen. Er zijn dan ook alleen use cases opgesteld voor het management van de klantgegevens.

Use case survey

#	Name	Description	Initiating actor
01	Verzorger toevoegen	Een verzorger moeten zichzelf kunnen toevoegen of laten toevoegen door een medewerker.	Verzorger/Medewerker
02	Gegevens verzorger wijzigen	Een verzorger moet zijn gegevens kunnen wijzigen of een medewerker moet de gegevens van een verzorger kunnen wijzigen.	Verzorger/Medewerker
03	Kind toevoegen	Een verzorger moet een kind kunnen toevoegen of kunnen laten toevoegen door een medewerker.	Verzorger/Medewerker
04	Gegevens kind wijzigen	Een verzorger moet de gegevens van een kind kunnen wijzigen of kunnen laten wijzigen door een medewerker.	Verzorger/Medewerker
05	Doneren	Een donatie aan Claus International doen.	Donateur
06	Gegevens kind opvragen	Bekijken van gegevens en cadeauwensen per kind.	Medewerker

Integrated use case diagram

Individual use cases

UC1 Verzorger toevoegen

UC1:

Verzorger toevoegen

Use case diagram

Description

Het toevoegen van een verzorger aan het systeem d.m.v. een account.

Source

Client case en gesprekken met de opdrachtgever.

Version

1.5

Actor

Verzorger of Medewerker

Trigger

Verzorger wilt zichzelf aanmelden als verzorger.

Basic course of events

Verzorger/Medewerker geeft aan dat er een verzorger ingeschreven moet worden.
Systeem laat formulier zien waarin contactgegevens moeten worden ingevuld.
Verzorger geeft contactgegevens in.
Systeem geeft aan dat de gegevens zijn opgeslagen.

Alternate paths

Exception paths

Incorrecte gegevens

4. Het systeem stelt vast dat de NAW gegevens incorrect zijn ingevuld en geeft een foutmelding.
5. De usecase gaat verder bij 2.

Assumptions

De site is online
De database is online

Preconditions

Postconditions

De verzorger is ingeschreven in het systeem

Related business rules

#	Rule Definition
001	Het adres van een persoon moet bestaan.

Author

Ronnie Swanink

Date

5-3-2014

UC2 Gegevens verzorger wijzigen

UC2:

Gegevens verzorger wijzigen

Use case diagram

Description

Een verzorger moet zijn gegevens kunnen wijzigen of een medewerker moet de gegevens van een verzorger kunnen wijzigen.

Version

1.0

Actor

Verzorger of Medewerker

Trigger

Een verzorger wil zijn gegevens wijzigen of laten wijzigen door een medewerker bij een distributiecentrum of een medewerker wil de gegevens van een verzorger wijzigen.

Basic course of events

Medewerker geeft aan de gegevens van de verzorger te willen wijzigen.
Systeem vraagt de naam van de verzorger.
Medewerker geeft de naam van de verzorger.
Systeem toont gegevens van de verzorger.
Medewerker wijzigt (deel van) de gegevens.
Systeem controleert gegevens en vraagt om bevestiging.
Medewerker bevestigt de gegevens.
Systeem voert de wijzigingen door en geeft aan dat de gegevens succesvol zijn gewijzigd.

Alternate paths

Verzorger wijzigt gegevens

Verzorger geeft aan zijn gegevens te willen wijzigen.
Systeem toont gegevens van de verzorger.
Verzorger wijzigt (deel van) de gegevens.
Systeem controleert gegevens en vraagt om bevestiging.
Verzorger bevestigt de gegevens.
Systeem voert de wijzigingen door en geeft aan dat de gegevens succesvol zijn gewijzigd.

Verzorger verwijderen

5. Verzorger/medewerker geeft aan de verzorger uit het systeem te willen verwijderen.
6. Systeem vraagt om bevestiging.
7. Verzorger/medewerker bevestigt het verwijderen van de verzorger.
8. Systeem verwijdert de verzorger en geeft aan dat de verzorger is verwijderd.
9. De use case eindigt hier

Actor annuleert wijziging
7. Actor zegt de wijziging te willen annuleren.
8. De use case eindigt hier.

Exception paths

Incorrecte gegevens

6. Het systeem constateert dat (een deel van) de gegevens incorrect zijn.
7. Ga verder bij stap 5.

Assumptions

De site is online
De database is online

Preconditions

De te wijzigen verzorger is in het systeem geregistreerd.

Postconditions

De gegevens van de verzorger zijn gewijzigd.

Related business rules

#	Rule Definition
001	Het adres van een persoon moet bestaan.

Author

Tom Nikken

Date

24-03-2014

UC3 Kind toevoegen

UC3:

Kind toevoegen

Use case diagram

Description

Het toevoegen van een kind aan een verzorger.

Source

Client case en gesprekken met de opdrachtgever.

Version

1.5

Actor

Verzorger of Medewerker

Trigger

Verzorger wilt een kind toevoegen aan het systeem.

Basic course of events

Verzorger/Medewerker geeft aan dat hij/zij een kind wilt inschrijven.
Systeem toont formulier waarin de gegevens van het kind moeten worden ingevuld.
Verzorger/Medewerker geeft gegevens in.
Systeem geeft aan dat de gegevens zijn opgeslagen.

Alternate paths

Verzorger selecteren

Als een medewerker het kind toe wilt voegen moet eerst een verzorger geselecteerd worden om het kind aan toe te voegen.

Systeem toont formulier om een ouder in te zoeken.
Medewerker selecteert ouder.
Usecase gaat verder bij stap 2.

Exception paths

Incorrecte gegevens

4. Het systeem stelt vast dat de gegevens incorrect zijn ingevuld.
5. De usecase gaat verder bij 2.

Assumptions

De site is online
De database is online

Preconditions

De actor is ingelogd in het systeem

Postconditions

Kind is toegevoegd in het systeem bij de bijbehorende verzorger.

Related business rules

#	Rule Definition
001	Het adres van een persoon moet bestaan.
002	Elk kind moet een verzorger hebben.

Author

Ronnie Swanink

Date

5-3-2014

UC4 Gegevens kind wijzigen

UC4:

Gegevens kind wijzigen

Use case diagram

Description

Het wijzigen van de in het systeem opgeslagen gegevens van een kind.

Source

Version

1.2

Actor

Verzorger of Medewerker

Trigger

Een verzorger wil zelf de gegevens van een kind wijzigen of laat dit door een medewerker bij een distributiecentrum doen.

Basic course of events

Verzorger/medewerker geeft aan de gegevens van een kind te willen wijzigen.
Systeem toont huidige gegevens.
Verzorger/medewerker wijzigt (deel van) de gegevens en geeft aan dit te willen doorvoeren.
Systeem controleert gegevens en vraagt om bevestiging.
Verzorger/medewerker bevestigt de gegevens.
Systeem voert de wijzigingen door en geeft aan dat de gegevens succesvol zijn gewijzigd.

Alternate paths

Kind verwijderen

3. Verzorger/medewerker geeft aan het kind uit het systeem te willen verwijderen.
4. Systeem vraagt om bevestiging.
5. Verzorger/medewerker bevestigt het verwijderen van het kind.
6. Systeem verwijdert het kind en toont aan de verzorger/medewerker dat het verwijderen voltooid is.

Exception paths

Incorrecte gegevens

4. Het systeem constateert dat (een deel van) de gegevens incorrect zijn.
5. Ga verder bij stap 3.

Assumptions

De site is online
De database is online

Preconditions

Postconditions

De gegevens van een kind zijn gewijzigd naar wens van een medewerker/verzorger.

Related business rules

#	Rule Definition
001	Het adres van een persoon moet bestaan.
002	Elk kind moet een verzorger hebben.
003	Een verzorger mag alleen de gegevens van de kinderen die aan zijn/haar account gekoppeld zijn aanpassen.
004	Als een verzorger zijn/haar account verwijdert worden alle kinderen van die ouder uit het systeem verwijderd.

Author

Bart van de Put

Date

11-03-2014

UC5 Een donatie maken

UC5:	Een donatie maken
Use case diagram
Description	Het doneren van geld aan Claus International door een donateur.
Source	De business case en gesprekken met Claus International
Version	1.1
Actor	Donateur
Trigger	Een donateur wil geld overmaken naar Claus International
Basic course of events	De donateur geeft aan het systeem aan een donatie te willen maken. Het systeem laat het donatiescherm zien en deze vraagt de donateur om zijn naam. De donateur voert zijn naam in. Het systeem stuurt de donateur door naar het betalingssysteem. De donateur handelt zijn transactie af met het betalingssysteem. Het systeem geeft aan dat de transactie succesvol is verlopen en bedankt de donateur.
Alternate paths	De donateur wenst anoniem te blijven 3. De donateur laat het veld waar hij zijn naam in moet vullen leeg. 4. De use case gaat verder bij stap vier.
Exception paths	Het betalingssysteem is offline of valt uit 4. Het systeem geeft aan dat de donateur op een later tijdstip een nieuwe poging moet doen. De use case eindigt hier. De rekening van de donateur is leeg 5. Het systeem geeft aan dat de transactie is mislukt. De use case eindigt hier.
Assumptions	De site is online. De rekening van Claus International is beschikbaar.
Preconditions
Postconditions	Er is geld overgemaakt naar de rekening van Claus International.
Related business rules
Author	Thomas de Bel
Date	10-3-2014

UC6 Gegevens kind opvragen

UC6:	Gegevens kind opvragen
Use case diagram
Description	Het opvragen van de wensen van het kind en van het adres van de ouders.
Source	Gesprek met bestuur van Claus International
Version	1.1
Actor	Een medewerker.
Trigger	Een medewerker wil de gegevens van een kind inzien.
Basic course of events	De medewerker geeft aan gegevens van een kind in te willen zien. Het systeem vraagt om de naam van het kind. De medewerker geeft de naam van het kind. Het systeem laat zien: De naam van het kind. De NAW gegevens van het kind. De wensen van het kind. De naam van de ouder. De NAW gegevens van de ouder.
Alternate paths	Geen
Exception paths	De medewerker geeft de naam van een kind dat niet in het systeem geregistreerd is. 4. Het systeem geeft aan dat dit kind niet in de database voorkomt 5. Ga verder bij stap 2.
Assumptions	Geen.
Preconditions	De medewerker weet de naam gegevens van het kind
Postconditions	De medewerker heeft de naam van het kind, de NAW gegevens van het kind, de wensen van het kind, de naam van de ouder van het kind en het adres van de ouder van het kind.
Related business rules	Geen.
Author	Tom Nikken
Date	12-3-2014

Domain Model per Use Case

In dit onderdeel wordt per use case een zogenaamd domeinmodel gegeven. In deze modellen is te zien met wat voor gegevens er eigenlijk wordt gewerkt op de achtergrond. Dit is weergegeven in ORM-schema's welke ook beperkingen op de gegevens weergeven. De domeinmodellen zijn belangrijk om inzicht te krijgen in wat er precies moet worden bijgehouden per use case. Verder geven deze modellen een leidraad op het moment dat onderdelen van het systeem geïmplementeerd gaan worden.