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

Groep 6

Werkstuk Requirements Engineering

Thomas Nägele, Mathijs Vos, Nicky van Rijsbergen, Marvin Barron, Koen van Ingen

Onderwijsinstituut voor Informatica en Informatiekunde

Radboud Universiteit Nijmegen

version 18 februari 2022

Page Break

Introduction

CloseAct is een toneelgroep die over de hele wereld voorstellingen geeft. Het plannen van deze voorstellingen kan behoorlijk lastig zijn en het huidige systeem ondersteunt dit niet voldoende. Dit komt doordat er met de huidige manier van werken veel dingen handmatig gedaan moeten worden. Bovendien zitten veel gegevens op verschillende plaatsen in het systeem. Als gegevens moeten worden toegevoegd of aangepast, moet dat op al deze plaatsen gebeuren. Dit werkt inconsistenties in de hand.

Om de werkzaamheden makkelijker en minder foutgevoelig te maken, wil CloseAct graag een nieuw systeem, dat een aantal onderdelen van de huidige manier van werken combineert tot één overzichtelijk geheel. De requirements voor dit nieuw te bouwen systeem zullen door ons worden opgesteld.

Problem statement

De huidige manier van werken heeft een aantal problemen:

Het plannen van de voorstellingen gaat erg inefficiënt.
- Dit komt doordat alle informatie verspreid staat over verschillende programma's en/of documenten. Hierdoor moet nieuwe informatie op verschillende plaatsen worden toegevoegd of bijgewerkt, waardoor snel inconsistenties ontstaan.
Er onstaan snel fouten die de voorstellingen in gevaar kunnen brengen.
- Spelers worden bijvoorbeeld ingepland terwijl ze eigenlijk niet beschikbaar zijn. Dit kan gebeuren doordat de informatie onoverzichtelijk wordt weergegeven en op meerdere plaatsen staat.
Spelers moeten altijd de spelersplanner kunnen inzien. Niet alleen om te weten wanneer ze zelf zijn ingepland, maar ook om te zien hoeveel werk hun medespelers krijgen.
- Op dit moment is de spelersplanner een simpel excel-document. Dit document wordt nu bij een wijziging steeds per e-mail naar de spelers gestuurd. Het gevolg is dat er veel verschillende versies van de spelersplanner in omloop zijn, wat problematisch is (bijvoorbeeld spelers die denken dat ze niet ingepland zijn, terwijl dit in een nieuwere versie wel het geval is).

Case analysis

Stakeholder analysis

Er zijn twee stakeholdertypen die te maken krijgen met het nieuwe systeem. Dit zijn de spelers en de kantoormedewerkers. Verder is Niels Braakensiek als hoofdcontactpersoon van CloseAct een stakeholder.

Een speler is een eindgebruiker van het nieuwe systeem. Een speler moet zelf dingen kunnen regelen (beschikbaarheid opgeven, persoonlijke gegevens aanpassen) en informatie kunnen raadplegen (spelersplanner).
Een kantoormedewerker treedt op als beheerder van het systeem, in die zin dat zij de meeste informatie kunnen invoeren. Dit omvat de planningsinformatie voor de spelers, gegevens over opdrachten, logistieke planning, etcetera.

De opdrachtgevers sturen de informatie voor de opdracht naar de kantoormedewerkers, waarna zij deze informatie in het systeem invoeren. De opdrachtgevers behandelen wij dus niet als stakeholders voor het systeem.

Mission and vision statement

Mission

Het project gaat de problemen die CloseAct ervaart met het oude systeem oplossen, door (de requirements voor) een nieuw systeem op te leveren.
Een van de problemen die zal worden opgelost is het probleem met de planning. Het nieuwe plansysteem moet voor alle spelers en kantoormedewerkers makkelijk te gebruiken zijn.

Vision

Een systeem waarmee CloseAct gemakkelijk kan plannen en niet zoveel tijd verliest als met het oude systeem.
Ook kunnen de planfouten die voorkwamen bij het oude systeem niet meer voorkomen.

Statement of work

Deliverable	Façade (17-04-2012)	Filled (29-05-2012)	Focused (22-06-2012)
Introduction	Voorlopige versie	Voorlopige versie	Compleet
Problem statement	Zo goed mogelijk	Zo goed mogelijk	Compleet
Stakeholder list/analysis	Zo goed mogelijk	Zo goed mogelijk	Compleet
Mission-Vision(-Values)	Compleet	Compleet	Compleet
Statement of Work	Compleet en up-to-date	Compleet en up-to-date	Compleet en up-to-date
Risk Analysis	Compleet en up-to-date	Compleet en up-to-date	Compleet en up-to-date
Use Case Survey	Zo goed mogelijk	Bijna compleet	Compleet
Integrated UC Diagram	Compleet	Compleet	Compleet
Use Cases	Nog niet	"Filled" niveau	Compleet
Scenarios	Nog niet	Enkelen per UC	Compleet
Domein Models	Nog niet	Deels compleet	Compleet
Business rules per UC	Nog niet	Deels compleet	Compleet
Integrated Domein Model	Nog niet	Eerste schets	Compleet
Business Rules Catalogue	Nog niet	Deels compleet	Compleet
Non-functional Requirements	Notities	Deels compleet	Compleet
Terminological Definitions	Notities	Deels compleet	Compleet

Legenda
Voltooid
Niet voltooid
Mee bezig

Risk analysis

#	Category	Risk	Solution needed by	Status	Days lost	Expectancy factor	Risk factor
01	Personeel	Iemand wordt ziek	De rest van de groep		3	1%	3
02	Personeel	Ruzie in de groep	Hopelijk kan iemand bemiddelen	Niks aan de hand	4	2%	8
03	Opdrachtgever	CloseAct gaat failliet (bezuinigingen in de cultuursector)	n.v.t.		Project afgelopen	3%	100
04	Opdrachtgever	Opdrachtgever weet niet duidelijk wat hij wil. Er komen geen duidelijke requirements boven water.	Requirements engineers		20	20%	10

Requirements

Use cases

Use case survey

#	Name	Description	Initiating actor
01	Beschikbaarheid opgeven	Een speler geeft op wanneer hij/zij kan spelen. Hier kan om gevraagd worden door een kantoormedewerker of dit kan op eigen initiatief worden ingevuld. Deze beschikbaarheid wordt ingevuld in een schema waar de beschikbaarheid van alle spelers in staat.	Speler, kantoormedewerker
02	Planning inzien	Een speler of kantoormedeweker kijkt naar de planning. Hierin staat wanneer alle spelers zijn ingepland.	Speler
03	Speler inplannen	Aan de hand van de aangegeven beschikbaarheid worden spelers ingepland.	Kantoormedewerker
04	Optie plaatsen	Kantoormedewerker krijgt een opdracht binnen en zet deze in het systeem.	Kantoormedewerker
05	Opdrachtgeverinformatie ingeven	Close Act werkt met contracten met hun opdrachtgevers. Opdrachtgevers hebben vaste gegevens zoals telefoonnummers die nu nog in de agenda worden bijgehouden. Met deze use case kunnen deze gegevens in het systeem worden gezet.	Kantoormedewerker
06	Opdrachtgegevens invoeren	Kantoormedewerker voert gegevens over de opdracht in. Deze gegevens zijn: Welke voorstelling moet er gegeven worden? Waar vindt de voorstelling plaats? Wanneer vindt de voorstelling plaats? Hoeveel gaat de voorstelling kosten? Hoeveel mensen zijn er nodig?	Kantoormedewerker
07	Spelersinformatie invoeren	Een kantoormedewerker voert gegevens over een speler in in het systeem. Dit omvat bijvoorbeeld de NAW-gegevens van de speler, maar ook gegevens als 'heeft de speler een rijbewijs of niet' en 'is de speler vegetariër of niet'.	Kantoormedewerker
08	Kostuumgebruik plannen	De kostuums die nodig zijn voor de betreffende show worden toegevoegd aan de optie voor deze show.	Kantoormedewerker
09	Kostuumvoorraad beheren	Wijzigingen aan de totale voorraad van de kostuums van CloseAct kunnen worden ingevoerd en opgeslagen. De voorraad wordt bijgehouden in de vorm van een lijst met daarin het soort kostuum en het aantal hiervan. Mogelijke wijzigingen zijn: Er is van een bepaald type kostuum een wijziging in de hoeveelheid waarin deze voorkomt. Er komt een nieuw type kostuum bij.	Kantoormedewerker

N.B. de use cases 4, 5 en 6 lijken in eerste instantie wat overlap te vertonen. Wij zien het invoeren van een opdracht echter als volgt:

Een opdracht komt binnen

Een kantoormedewerker plaatst als het ware een "lege template" voor een opdracht in het systeem (use case 4).

Informatie over de opdrachtgever wordt ingevoerd (use case 5).

De rest van de gegevens (soort opdracht, welke voorstelling, locatie, etc) over de opdracht worden toegevoegd (use case 6).

Planning wordt gemaakt (spelers, kostuums) (use cases 3 en 8).

Integrated use case diagram

Individual use cases

Use case: Beschikbaarheid opgeven

Use Case:	01 Beschikbaarheid opgeven
Description	Een speler geeft op wanneer hij/zij kan spelen. Hier kan om gevraagd worden door een kantoormedewerker of dit kan op eigen initiatief worden ingevuld. Deze beschikbaarheid wordt ingevuld in een schema waar de beschikbaarheid van alle spelers in staat.
Source/Actor?	Speler
Version	1.1
Basic course of events	Speler geeft aan beschikbaarheid te willen opgeven. Systeem geeft mogelijkheid om beschikbaarheid op te geven. Speler geeft zijn of haar beschikbaarheid op. Systeem toont overzicht van door speler opgegeven beschikbaarheid. Speler gaat akkoord met door het systeem getoonde overzicht.
Alternative paths	Alternative path 1: 3.1 Speler geeft aan zijn of haar actie te willen annuleren. 3.2 De use case stopt. Alternative path 2: 5.1 Speler gaat niet akkoord met het getoonde overzicht. 5.2 Het systeem springt terug naar stap 2 en toont hierbij de al ingevulde gegevens van de speler.
Preconditions	Speler is lid van de organisatie CloseAct.
Postconditions	Beschikbaarheid van de speler staat in het schema.
Related business rules	Een speler mag zijn beschikbaarheid voor een bepaalde datum wijzigen zolang hij niet ingepland is voor die datum. Als een speler aangeeft op een bepaalde datum beschikbaar te zijn, kan hij worden ingepland voor een voorstelling op die datum. Alle spelers die voor Close Act werken moeten hun beschikbaarheid opgeven.

Use case: Planning inzien

Use Case:	02 Planning inzien
Description	Een speler of kantoormedeweker kijkt naar de planning. Hierin staat wanneer alle spelers zijn ingepland.
Source/Actor?	Kantoormedewerker, speler.
Version	1.1
Basic course of events	Speler/kantoormedewerker geeft aan planning te willen openen. Systeem geeft de planning weer.
Alternative paths	Geen
Preconditions	Speler werkt voor CloseAct.
Postconditions
Related business rules	Spelers moeten ook van elkaar kunnen zien hoeveel ze werken.

Use case: Speler inplannen

Use Case:	03 Speler inplannen
Description	Aan de hand van de aangegeven beschikbaarheid worden spelers ingepland.
Source/Actor?	Kantoormedewerker
Version	1.1
Basic course of events	Kantoormedewerker geeft aan speler in te willen plannen. Systeem geeft een overzicht van openstaande opdrachten. Kantoormedewerker kiest een opdracht. Systeem geeft een overzicht van beschikbare spelers weer. Kantoormedewerker kiest een speler om in te plannen. Systeem vraagt om bevestiging voor het inplannen van de speler. Kantoormedewerker bevestigt de aanpassing.
Alternative paths	Alternative path 1: 5.1 Kantoormedewerker heeft de mogelijkheid om te annuleren, bijvoorbeeld als de gewenste speler niet beschikbaar is op het gekozen tijdstip. 5.2. De use case stopt. Alternative path 2: 7.1 Kantoormedewerker geeft aan de speler toch niet te willen inplannen. 7.2 Systeem geeft overzicht van beschikbare spelers weer. Het systeem gaat dus verder bij stap 4.
Assumptions	De opdracht waarvoor een speler ingepland dient te worden, is reeds ingevoerd in het systeem.
Preconditions	Speler is lid van CloseAct
Postconditions	Speler(s) is/zijn ingepland voor de gekozen opdracht en zijn daarvan op de hoogte gesteld.
Related business rules	Als een speler ingepland is kan hij zichzelf niet zomaar uitschrijven. Een kantoormedewerker kan een ingeplande speler alleen uitschrijven met een goede reden.

Use case: Optie plaatsen

Use Case:	04 Optie plaatsen
Description	Kantoormedewerker krijgt een opdracht binnen en zet deze in het systeem.
Source/Actor?	Kantoormedewerker
Version	1.1
Basic course of events	Kantoormedewerker geeft aan optie (opdracht) te willen plaatsen. Systeem geeft het opdrachtensjabloon voor nieuwe opdracht weer. Kantoormedewerker vult het opdrachtensjabloon (deels) in. Systeem geeft overzicht van nieuwe opdracht weer. Kantoormedewerker bevestigt nieuwe opdracht.
Alternative paths	Alternative path 1: 3.1 Kantoormedewerker heeft mogelijkheid om invoeren te annuleren. 3.2 De use case stopt. Alternative path 2: 5.1 De Kantoormedewerker gaat niet akkoord met de gegevens. 5.2 De use case springt terug naar stap 2, waarin de eerder ingevulde gegevens al ingevuld zijn.
Preconditions
Postconditions	Nieuwe opdracht is geplaatst en eventueel (deels) ingevuld.
Related business rules	Opdrachten die binnenkomen worden door kantoormedewerkers in het systeem gezet.

Use case: Opdrachtgeverinformatie ingeven

Use Case:	05 Opdrachtgeverinformatie ingeven
Description	Close Act werkt met contracten met hun opdrachtgevers. Opdrachtgevers hebben vaste gegevens zoals telefoonnummers die nu nog in de agenda worden bijgehouden. Met deze use case kunnen deze gegevens in het systeem worden gezet.
Source/Actor?	Kantoormedewerker
Version	1.1
Basic course of events	Kantoormedewerker geeft aan Opdrachtgeverinformatie te willen plaatsen. Systeem toont leeg opdrachtgeversjabloon voor opdrachtgeverinformatie. Kantoormedewerker vult opdrachtgeversjabloon in Systeem toont ingevoerde gegevens en vraagt om bevestiging. Kantoormedewerker controleert en bevestigt gegevens.
Alternative paths	Alternative path 1: 3.1 De kantoormedewerker kan ervoor kiezen te stoppen met invoeren van gegevens. 3.2 Use Case wordt afgebroken. Alternative path 2: 5.1 De kantoormedewerker kan een fout zien in de ingevoerde gegevens en geeft aan dit te willen corrigeren. 5.2 De use case springt terug naar stap 3.
Assumptions	We nemen hierbij aan dat de medewerker die de opdracht in wil voeren, bevoegd is dit te doen.
Preconditions
Postconditions	De ingevoerde opdrachtgeverinformatie is opgeslagen op het systeem.
Related business rules	De opdrachtgeverinformatie moet bekend zijn alvorens een opdracht geaccepteerd kan worden.

Use case: Opdrachtgegevens invoeren

Use Case:	06 Opdrachtgegevens invoeren
Description	Kantoormedewerker voert gegevens over de opdracht in. Deze gegevens zijn: welke voorstelling moet er gegeven worden waar vindt de voorstelling plaats wanneer vindt de voorstelling plaats hoeveel gaat de voorstelling kosten hoeveel mensen zijn er nodig Let er op dat deze gegevens als deels in use case 4 ingevuld kunnen zijn. Dat ligt eraan hoeveel informatie er toen al beschikbaar was over de opdracht.
Source/Actor?	Kantoormedewerker
Version	1.1
Basic course of events	Kantoormedewerker geeft aan opdrachtgegevens in te willen vullen. Systeem toont mogelijkheid om plaats in te voeren. Kantwoormederwerker vult plaats in. Systeem toont mogelijkheid om de tijd van de voorstelling in te voeren. Kantwoormedewerker vult deze in. Systeem toont mogelijkheid om de kosten van de voorstelling in te voeren. Kantoormedewerker vult deze in. Systeem toont mogelijkheid om de benodigde mensen voor de voorstelling in te voeren. Kantoormedewerker vult deze in. Systeem toont ingevoerde gegevens en vraagt om bevestiging. Kantoormedewerker controleert en bevestigt gegevens.
Alternative paths	Alternative path 1: 4.1 Plaats wordt niet als geldige plaats herkend door het systeem, waardoor het systeem een foutmelding toont. 4.2 Kantwoormedewerker moet opnieuw plaats invullen. Alternative path 2: 6.1 Tijd is geen geldige tijd, waardoor het systeem een foutmelding toont. 6.2 Kantoormedewerker moet opnieuw tijd invullen. Alternative path 3: 11.1 Kantoormedewerker gaat niet akkoord met de gegevens. 11.2 Use case springt terug naar stap 2.
Assumptions	We nemen hierbij aan dat de medewerker die de opdracht in wil voeren, bevoegd is dit te doen.
Preconditions	De opdracht staat al in het systeem.
Postconditions	Er staat meer informatie over de opdracht in het systeem.
Related business rules	Voorstellingen mogen niet later dan 12 uur snachts worden gepland. Dit in verband met arbeidsvoorwaarden. Tijd is gebaseerd op de tijd in het land waar de voorstelling is.

Use case: Spelersinformatie invoeren

Use Case:	07 Spelersinformatie invoeren
Description	Een kantoormedewerker voert gegevens over een speler in in het systeem. Dit omvat bijvoorbeeld de NAW-gegevens van de speler, maar ook gegevens als 'heeft de speler een rijbewijs of niet' en 'is de speler vegetariër of niet'.
Source/Actor?	Kantoormedewerker
Version	1.1
Basic course of events	Kantoormedewerker geeft aan informatie over een nieuwe speler te willen invoeren. Systeem geeft een leeg spelerssjabloon voor een nieuwe speler. Kantoormedewerker vult het spelerssjabloon in met informatie over de speler. Systeem toont overzicht van ingevulde gegevens over de speler. Kantoormedewerker controleert en bevestigt de gegevens.
Alternative paths	Alternative path 1: 1.1 De kantoormedewerker geeft aan eerder ingevoerde informatie over een speler te willen aanpassen. 1.2 Het systeem toont het spelerssjabloon, ingevuld waar mogelijk met eerder ingevoerde gegevens. 1.3 De uitvoering van de use case gaat verder bij stap 3. Alternative path 2: 3.1 De kantoormedewerker wil stoppen met invoeren van gegevens en geeft dit aan. 3.2 De use case stopt. Alternative path 3: 5.1 De kantoormedewerker ziet een onjuistheid en geeft aan de gegevens te willen aanpassen. 5.2 De use case springt terug naar stap 2.
Assumptions	We nemen hierbij aan dat de medewerker die de opdracht in wil voeren, bevoegd is dit te doen.
Preconditions
Postconditions	De nieuwe speler of nieuwe informatie over een eerder ingevoerde speler is opgeslagen.
Related business rules	Spelers moeten met hun NAW-gegevens geregristeerd staan. Ook moet er bekend zijn of ze een rijbewijs hebben en of ze vegetariër zijn.

Use case: Kostuumgebruik plannen

Use Case:	08 Kostuumgebruik inplannen
Description	De kostuums die nodig zijn voor de betreffende show worden toegevoegd aan de optie voor deze show.
Source/Actor?	Kantoormedewerker.
Version	1.1
Basic course of events	Kantoormedewerker geeft aan kostuums te willen plannen voor een voorstelling. Systeem geeft de kostuumplanner van die show weer. Kantoormedewerker geeft aan welke kostuums gebruikt zullen worden bij de voorstelling. Systeem vraagt of de kantoormedewerker zeker is van deze beslissing. Kantoormedewerker geeft aan het hiermee eens te zijn. Systeem bericht kantoormedewerker dat de gegevens zijn veranderd. Systeem vraagt of de kantoormedewerker nog meer kostuums wil plannen voor deze voorstelling. Kantoormedewerker wil geen kostuums meer plannen.
Alternative paths	Alternative path 1: 5.1 Kantoormedewerker geeft aan het hier niet mee eens te zijn. 5.2 De use case gaat weer terug naar stap 2 zodat de kantoormedewerker de juiste gegevens in kan voeren. Alternative path 2: 8.1 Kantoormedewerker geeft aan nog meer kostuums te willen plannen. 8.2 De use case gaat weer terug naar stap 2.
Preconditions	De betreffende voorstelling is gepland. Kostuums zijn in bezit van CloseAct.
Postconditions	Kostuums zijn bij de optie geplaatst.
Related business rules	Kostuums mogen alleen ingepland zijn als ze beschikbaar zijn. Dat wil zeggen: kostuums mogen niet twee keer voor dezelfde voorstelling worden ingepland. Kostuums mogen alleen worden ingepland als er minstens 2 dagen tussen de geplande voorstelling zit waarvoor zij nodig zijn. Dit in verband met het vervoeren van de kostuums.

Use case: Kostuumvoorraad beheren

Use Case:	09 Kostuumvoorraad beheren
Description	Wijzigingen aan de totale voorraad van de kostuums van CloseAct kunnen worden ingevoerd en opgeslagen. De voorraad wordt bijgehouden in de vorm van een lijst met daarin het soort kostuum en het aantal hiervan. Mogelijke wijzigingen zijn: Er is van een bepaald type kostuum een wijziging in de hoeveelheid waarin deze voorkomt. Er komt een nieuw type kostuum bij.
Source/Actor?	Kantoormedewerker
Version	1.1
Basic course of events	Kantoormedewerker geeft aan dat hij wijzigingen in de voorraad in wil vullen. Systeem geeft lijst met kostuums weer. Kantoormedewerker kiest het te wijzigen kostuum. Systeem vraagt naar de hoeveelheid in voorraad. Kantoormedewerker voert hoeveelheid in. Systeem vraagt of er nog een wijziging is. Kantoormedewerker geeft aan dat er geen wijzigingen meer zijn.
Alternative paths	Alternative path 1: 3.1 Kantoormedewerker geeft aan een nieuw kostuum in te willen voeren. 3.2 Systeem vraagt naam van nieuw kostuum. 3.3. Kantoormedewerker vult naam in. 3.4. De use case springt naar stap 4. Alternative path 2: 4.1 Kantoormedewerker geeft aan het verkeerde kostuum te hebben gekozen. 4.2 De use case gaat terug naar stap 2. Alternative path 3: 7.1 Kantoormedewerker geeft aan nog een kostuum te willen wijzigen. 7.2 De use case gaat terug naar stap 2.
Preconditions	Er is een lijst voor de kostuums
Postconditions	De wijzigingen in de kostuumvoorraad zijn opgeslagen en de kostuumvoorraad is aangepast.
Related business rules	Geen.

Domain Model per Use Case

Hieronder volgen de Domeinmodellen per Use Case.

Beschikbaarheid opgeven
Planning inzien
Speler inplannen
Optie plaatsen
Opdrachtgever informatie ingeven
Opdrachtgegevens invoeren
Spelersinformatie invoeren
Kostuumgebruik plannen
Kostuumvoorraad beheren

Scenarios

Om de scenario's overzichtelijker te houden, volgt hieronder tabel met de namen van de personen die een rol spelen in de scenario's en wat voor een functie ze hebben. Verder hebben wij de alternative path stappen in de scenario's expliciet aangegeven. In de scenario's zonder alternative paths komt de nummering precies overeen met die van de Basic Course of Events van de use cases. Bij de scenario's met alternative paths komen er extra stappen bij, waardoor de nummering niet meer overeenkomt. De stappen komen natuurlijk nog wel overeen. Vaak wordt er in de alternative paths weer terug gesprongen naar de Basic Course of Events. Hierdoor krijgt een scenario erg veel stappen, maar dit komt nog wel steeds overeen met de use cases waar het scenario voor is gemaakt.

Rolverdeling
Naam	Rol
Piet	Acteur
Kim	Actrice
Jan	Acteur
Mirjam	Kantoormedewerkster
Johan	Kantoormedewerker
Maartje	Kantoormedewerkster
Jopie	Kantoormedewerker
Kees	Kantoormedewerker
Barend	Kantoormedewerker

De scenario's zijn gegroepeerd op Use Case. Elke Use Case krijgt zijn eigen Scenario's.

01 - Beschikbaarheid opgeven

Piet wil zijn beschikbaarheid opgeven

Piet geeft aan het systeem aan dat hij zijn beschikbaarheid wil opgeven.
Het systeem geeft hem de mogelijkheid zijn beschikbaarheid op te geven.
Piet geeft aan dat hij in 2012 in week 20 t/m 30 doordeweeks (ma-vrij) beschikbaar is en dat hij in week 34 en 35 alleen in het weekend beschikbaar is.
Het systeem toont dat Piet in week 20 t/m 30 doordeweeks beschikbaar is en dat hij in week 34 en 35 in het weekend beschikbaar is.
Piet gaat akkoord met dit overzicht.

Kim wil haar beschikbaarheid opgeven

Kim geeft aan het systeem aan dat zij haar beschikbaarheid wil opgeven.
Het systeem geeft haar de mogelijkheid haar beschikbaarheid op te geven.
Kim vult in dat ze in week 20 beschikbaar is, maar moet ineens plotseling weg.
Kim annuleert het proces (alternative path stap 3.1).
De use case stopt (alternative path stap 3.2).

Jan wil zijn beschikbaarheid opgeven

Jan geeft aan het systeem aan dat hij zijn beschikbaarheid wil opgeven.
Het systeem geeft hem de mogelijkheid zijn beschikbaarheid op te geven.
Jan is het gehele jaar door ieder weekend beschikbaar, en vult zodoende in dat hij ieder weekend beschikbaar is.
Het systeem toont een overzicht waarin Jan ziet dat hij ieder weekend beschikbaar is.
Bij nader inzien wilde Jan ergens nog wel twee weken op vakantie, waardoor hij het weekend in week 30 niet beschikbaar is. Jan gaat dus niet akkoord met het overzicht (alternative path stap 5.1).
Het systeem geeft hem opnieuw de mogelijkheid zijn beschikbaar op te geven, met alle weekenden al ingevuld (alternative path stap 5.2).
Jan past het overzicht aan, zodanig dat hij in week 30 niet beschikbaar is.
Het systeem toont een overzicht waarin Jan ziet dat hij ieder weekend behalve in week 30 beschikbaar is.
Jan gaat akkoord met dit overzicht.

02 - Planning inzien

Jan wil zijn spelersplanning inzien.

Jan geeft aan het systeem aan dat hij zijn planning in wil zien.
Het systeem toont van alle spelers de planning en van Jan dat hij in het weekend van week 25, 26, 27 en week 40,41,42 is ingepland.

Mirjam wil zien wanneer iedereen moet optreden.

Mirjam geeft aan het systeem aan dat hij zijn planning in wil zien.
Het systeem toont een overzicht van wanneer iedereen is ingepland (is een beetje te veel om hier allemaal op te sommen).

03 - Speler inplannen

Mirjam wil Jan inplannen voor de opdracht van zaterdag 2 juni.

Mirjam geeft aan het systeem aan een speler in te willen plannen.
Het systeem geeft een overzicht van alle openstaande opdrachten (is een beetje te veel om hier allemaal op te sommen).
Mirjam kiest de opdracht van zaterdag 2 juni.
Het systeem toont de beschikbare spelers op die datum: Jan en Piet.
Mirjam kiest Jan om in te plannen.
Het systeem vraagt om een bevestiging om Jan in te plannen.
Mirjam bevestigt haar keuze.

Mirjam wil Jan inplannen voor de opdracht van zaterdag 28 juli.

Mirjam geeft aan het systeem aan een speler in te willen plannen.
Het systeem geeft een lijst van alle openstaande opdrachten (is een beetje te veel om hier allemaal op te sommen).
Mirjam selecteert de opdracht van zaterdag 28 juli.
Het systeem toont de beschikbare spelers op die datum: Alleen Piet.
Mirjam wilde echter Jan inplannen, maar die staat er niet tussen. (alternative path stap 5.1).
De use case stopt (alternative path stap 5.2).

Mirjam wil Jan inplannen voor de opdracht van zaterdag 2 juni.

Mirjam geeft aan het systeem aan een speler in te willen plannen.
Het systeem geeft een overzicht van alle openstaande opdrachten (is een beetje te veel om hier allemaal op te sommen).
Mirjam kiest de opdracht van zaterdag 2 juni.
Het systeem toont de beschikbare spelers op die datum: Jan en Piet.
Mirjam kiest Jan om in te plannen.
Het systeem vraagt om een bevestiging om Jan in te plannen.
Mirjam besluit hem toch nog niet in te plannen (alternative path stap 7.1).
Het systeem geeft weer het overzicht van de spelers weer (alternative path stap 7.2) en gaat dus terug naar stap 4 in de use case.
Mirjam kiest hier nu Piet om in te plannen.
Het systeem vraagt om een bevestiging om Piet in te plannen.
Mirjam bevestigt haar keuze.

04 - Optie plaatsen

Kantoormedewerker Johan krijgt van Theater BV een opdracht binnen om op maandag 30 juli op het Goffertpark in Nijmegen een voorstelling te geven.

Johan geeft aan het systeem aan een nieuwe opdracht te willen plaatsen.
Het systeem opent een sjabloon waarin Johan de nu al bekende gevens in kan vullen.
Johan vult de datum in (Maandag 30 juli), de plaats (Goffertpark Nijmegen) en de klant (Theater BV). Verder zijn er nog geen gegevens bekend en deze vult Johan dus ook niet in. Vervolgens bevestigt Johan zijn keuze.
Het systeem toont Johan de zojuist ingevulde gegevens.
Johan bevestigt dat de gegevens juist zijn.

Kantoormedewerker Maartje krijgt van een ambigue bedrijf een opdracht binnen over een voorstelling die ergens dit jaar plaats zal gaan vinden op een nog onbekende plek.

Maartje geeft aan het systeem aan een nieuwe opdracht te willen plaatsen.
Het systeem opent een sjabloon waarin Maartje nu al bekende gevens in kan vullen.
Maartje beseft dat ze praktisch nog niets weet over de opdracht en dus nog geen zinnige dingen in kan vullen. Daarom annuleert ze het invullen. (alternative path stap 3.1).
De use case stopt. (alternative path stap 3.2).

Kantoormedewerker Mirjam krijgt van Toneel BV een opdracht binnen om op maandag 23 juli op het Goffertpark in Nijmegen een voorstelling te geven.

Mirjam geeft aan het systeem aan een nieuwe opdracht te willen plaatsen.
Het systeem opent een sjabloon waarin Johan de nu al bekende gevens in kan vullen.
Mirjam vult de datum in (Maandag 22 juli), de plaats (Goffertpark Nijmegen) en de klant (Toneel BV). Verder zijn er nog geen gegevens bekend en deze vult Mirjam dus ook niet in. Vervolgens bevestigt Mirjam haar keuze.
Het systeem toont Mirjam de zojuist ingevulde gegevens.
Mirjam gaat niet akkoord, want ze ziet dat ze een foutje bij de datum heeft gemaakt. (alternative path stap 5.1).
Het systeem opent het sjabloon weer met de al ingevulde gegvens.(alternative path stap 5.2).
Mirjam wijzigt de datum van 22 juli naar 23 juli. Vervolgens bevestigt Mirjam haar keuze.
Het systeem toont Mirjam de zojuist ingevulde gegevens.
Mirjam bevestigt dat de gegevens juist zijn.

05 - Opdrachtgeverinformatie invoeren

Kantoormedewerker Johan wil de gegevens over Theater BV in het systeem invoeren.

Johan geeft aan het systeem aan opdrachtgeverinformatie te willen invoeren.
Het systeem toont leeg sjabloon voor opdrachtgeverinformatie.
Johan vult alle gegevens in het sjabloon in die hem bekend zijn, namelijk het telefoonnummer 0657841274. adresgegevens: Groene straat 84 Nijmegen, naam: Theater BV.
Het systeem toont een overzicht van de ingevoerde gegevens en vraagt om bevestiging.
Johan bevestigt de gegevens.

Kantoormedewerker Maartje wil de gegevens van het ambigue bedrijf in het systeem invoeren.

Maartje geeft aan het systeem aan opdrachtgeverinformatie te willen invoeren.
Het systeem toont leeg sjabloon voor opdrachtgeverinformatie.
Maartje wil de gegevens invoeren, maar beseft dat er totaal geen informatie over het bedrijf / opdrachtgever beschikbaar is. Daardoor annuleert ze de invoer. (alternative path stap 3.1).
De use case stopt. (alternative path stap 3.2).

Kantoormedewerker Mirjam wil de gegevens over de opdrachtgever Toneel & Co in het systeem invoeren.

Mirjam geeft aan het systeem aan opdrachtgeverinformatie te willen invoeren.
Het systeem toont leeg sjabloon voor opdrachtgeverinformatie.
Mirjam vult alle gegevens in het sjabloon in die haar bekend zijn, namelijk het telefoonnummer 020-2147548. adresgegevens: Nassaulaan 12 Amsterdam, naam: Toneel & Co.
Het systeem toont een overzicht van de ingevoerde gegevens en vraagt om bevestiging.
Mirjam ziet dat ze nog een typefout in het telefoonnummer heeft gemaakt en wilt dit corrigeren. Ze gaat daarom niet akkoord (alternative path stap 5.1).
Het systeem toont weer het ingevulde sjabloon dat Mirjam eerder ingevuld had, met haar gegevens al ingevuld (alternative path stap 4.2).
Mirjam verandert de laatste 8 van het telefoonnummer in een 7.
Het systeem toont een overzicht van de ingevoerde gegevens en vraagt om bevestiging.
Dit keer vindt Mirjam de gegevens in orde en gaat ermee akkoord.

06 - Opdrachtgegevens invoeren

Kantoormedewerker Johan krijgt van Theater BV meer informatie over de voorstelling van 30 juli in Nijmegen. Er is bekend dat er 50 spelers nodig zijn en de totale kosten op EUR 2000 geraamd zijn.

Johan geeft aan opdrachtgegevens in te willen vullen.
Systeem toont invoerveld voor de plaats. Hier staat al Goffertpark Nijmegen ingevuld, omdat Johan dit eerder al had ingevuld.
Johan gaat hiermee akkoord.
Systeem toont invoerveld voor de tijd van de voorstelling.
Johan vult 20.00 uur 's avonds in.
Systeem toont invoerveld voor de kosten van de voorstelling.
Johan vult EUR 2000 in.
Systeem toont invoerveld voor benodigde mensen.
Johan vult 50 in.
Systeem toont een overzicht van de ingevulde gegevens.
Johan gaat hiermee akkoord.

Kantoormedewerker Johan krijgt van Theater BV meer informatie over de voorstelling van 30 juli in Nijmegen. Er is bekend dat er 50 spelers nodig zijn en de totale kosten op EUR 2000 geraamd zijn.

Johan geeft aan opdrachtgegevens in te willen vullen.
Systeem toont invoerveld voor de plaats.
Johan vult Nijmegenn in.
Het systeem herkent deze plaats niet (alternative path stap 4.1).
Johan verandert de plaatsnaam in Nijmegen (alternative path stap 4.2).
Systeem toont invoerveld voor de tijd van de voorstelling.
Johan vult 20.00 uur 's avonds in.
Systeem toont invoerveld voor de kosten van de voorstelling.
Johan vult EUR 2000 in.
Systeem toont invoerveld voor benodigde mensen.
Johan vult 50 in.
Systeem toont een overzicht van de ingevulde gegevens.
Johan gaat hiermee akkoord.

Kantoormedewerker Johan krijgt van Theater BV meer informatie over de voorstelling van 30 juli in Nijmegen. Er is bekend dat er 50 spelers nodig zijn en de totale kosten op EUR 2000 geraamd zijn.

Johan geeft aan opdrachtgegevens in te willen vullen.
Systeem toont invoerveld voor de plaats. Hier staat al Goffertpark Nijmegen ingevuld, omdat Johan dit eerder al had ingevuld.
Johan gaat hiermee akkoord.
Systeem toont invoerveld voor de tijd van de voorstelling.
Johan vult 25.00 uur 's avonds in.
Het systeem herkent deze tijd niet (alternative path stap 6.1).
Johan moet de tijd verbeteren, zodoende vult hij 20.00 uur in (alternative path stap 6.2).
Systeem toont invoerveld voor de kosten van de voorstelling.
Johan vult EUR 2000 in.
Systeem toont invoerveld voor benodigde mensen.
Johan vult 50 in.
Systeem toont een overzicht van de ingevulde gegevens.
Johan gaat hiermee akkoord.

Kantoormedewerker Johan krijgt van Theater BV meer informatie over de voorstelling van 30 juli in Nijmegen. Er is bekend dat er 50 spelers nodig zijn en de totale kosten op EUR 2000 geraamd zijn.

Johan geeft aan opdrachtgegevens in te willen vullen.
Systeem toont invoerveld voor de plaats. Hier staat al Goffertpark Nijmegen ingevuld, omdat Johan dit eerder al had ingevuld.
Johan gaat hiermee akkoord.
Systeem toont invoerveld voor de tijd van de voorstelling.
Johan vult 20.00 uur 's avonds in.
Systeem toont invoerveld voor de kosten van de voorstelling.
Johan vult EUR 20000 in.
Systeem toont invoerveld voor benodigde mensen.
Johan vult 50 in.
Systeem toont een overzicht van de ingevulde gegevens.
Johan ziet dat hij een 0 teveel heeft ingevoerd bij de kosten en gaat niet akkoord (alternative path stap 11.1).
Het systeem springt terug naar stap 2, waar alle gegevens die Johan eerder invulde al ingevuld zijn. (alternative path stap 11.2).
Johan vult de gegevens opnieuw in.
Systeem toont een overzicht van de ingevulde gegevens.
Dit keer gaat Johan wel akkoord.

07 - Spelersinformatie invoeren

Kantoormedewerker Maartje heeft zojuist een overeenkomst gesloten met de nieuwe speler Piet, en wil informatie over Piet in het systeem zetten.

Maartje geeft aan informatie over een speler toe te willen toevoegen.
Het systeem toont een leeg sjabloon waar spelersinformatie ingevoerd kan worden.
Maartje vult de gegevens van Piet in.
Het systeem toont in een overzicht de gegevens die Maartje zojuist over Piet heeft ingevoerd.
Maartje ziet dat de gegevens juist zijn ingevuld, en bevestigt dat alles klopt.

Kantoormedewerker Johan heeft van speler Kim het bericht gekregen dat ze vegetariër is geworden. Johan wil dit gegeven toevoegen aan de gegevens die al over Kim in het systeem bekend zijn, zodat er bij het volgende optreden rekening mee gehouden kan worden dat Kim vegetariër is.

Johan geeft aan de gegevens over Kim te willen aanpassen (alternative path stap 1.1).
Het systeem toont de tot nu toe bekende gegevens over Kim en biedt de mogelijkheid om deze gegevens aan te passen (alternative path stap 1.2).
Johan geeft aan dat Kim vegetariër is. De rest van de gegevens hoefde niet te worden aangepast.
Het systeem toont een overzicht van de gegevens van Kim, met de zojuist door Johan gemaakte aanpassing.
Johan ziet dat alles klopt en bevestigt dat de ingevoerde informatie juist is.

Kantoormedewerker Maartje heeft zojuist een overeenkomst gesloten met de nieuwe speler Piet, en wil informatie over Piet in het systeem zetten.

Maartje geeft aan informatie over een speler toe te willen toevoegen.
Het systeem toont een leeg sjabloon waar spelersinformatie ingevoerd kan worden.
Maartje vult de gegevens van Piet in. Dan merkt ze dat ze het blaadje waarop Piet's NAW-gegevens stonden kwijt is geraakt. Ze kan daarom nu nog niet veel informatie invoeren, en geeft aan te willen stoppen (alternative path stap 3.1).
De use case stopt (alternative path stap 3.2).

Kantoormedewerker Maartje heeft zojuist een overeenkomst gesloten met de nieuwe speler Piet, en wil informatie over Piet in het systeem zetten.

Maartje geeft aan informatie over een speler toe te willen toevoegen.
Het systeem toont een leeg sjabloon waar spelersinformatie ingevoerd kan worden.
Maartje vult de gegevens van Piet in.
Het systeem toont in een overzicht de gegevens die Maartje zojuist over Piet heeft ingevoerd.
Maartje ziet dat ze is vergeten de informatie over het rijbewijs van Piet toe te voegen, en geeft aan dat ze de ingevoerde gegevens nog wil aanpassen (alternative path stap 5.1).
Het systeem toont opnieuw het spelersinformatiesjabloon, met daarin alle gegevens van Piet die Maartje had ingevoerd, zodat Maartje die niet opnieuw hoeft in te typen (alternative path stap 5.2).
Maartje voegt de informatie over het rijbewijs van Piet toe.
Het systeem toont een overzicht van de bijgewerkte gegevens.
Nu ziet Maartje dat alles volledig is, en geeft aan dat de informatie klopt.

08 - Kostuumgebruik plannen

Kees de kantoormedewerker geeft aan het kostuumgebruik van een voorstelling te willen aanpassen.

Kees geeft aan kostuums te willen plannen.
Systeem geeft de kostuumplanner van de voorstelling weer.
Kees geeft aan dat er twee saurus en drie insect kostuums nodig zijn voor deze voorstelling.
Systeem geeft de aanpassing weer en vraagt of Kees zeker is van deze aanpassing.
Kees bevestigt dat hij deze aanpassing wilt doorvoeren.
Systeem bericht Kees dat het aanpassen gelukt is.
Systeem vraagt of Kees het kostuumgebruik van deze voorstelling nog meer wilt aanpassen.
Kees geeft aan het kostuumgebruik niet verder te willen aanpassen.

Jopie de kantoormedewerker geeft aan het kostuumgebruik van een voorstelling te willen aanpassen.

Jopie geeft aan kostuums te willen plannen.
Systeem geeft de kostuumplanner van de voorstelling weer.
Jopie geeft aan dat er 100 engel en 2 insectkostuums nodig zijn voor deze voorstelling.
Systeem geeft de aanpassing weer en vraagt of Jopie zeker is van deze aanpassing.
Jopie ziet dat 100 engel kostuums een typ fout is en geeft aan dat hij het niet eens is met de aanpassing (alternative path stap 5.1).
Systeem geeft de kostuumplanner weer met de eerder ingevulde aanpassing (alternative path stap 5.2).
Jopie verandert de 100 engel kostuums in 10 engel kostuums.
Systeem geeft de aanpassing weer en vraagt of Jopie zeker is van deze aanpassing.
Jopie bevestigt dat hij deze aanpassing wilt doorvoeren.
Systeem bericht Jopie dat het aanpassen gelukt is.
Systeem vraagt of Jopie het kostuumgebruik van deze voorstelling nog meer wilt aanpassen.
Jopie geeft aan het kostuumgebruik niet verder te willen aanpassen.

Klaas de kantoormedewerker geeft aan het kostuumgebruik van een voorstelling te willen aanpassen.

Systeem geeft de kostuumplanner van de voorstelling weer.
Klaas geeft aan dat er een saurus en twee alien kostuums nodig zijn voor deze voorstelling.
Systeem geeft de aanpassing weer en vraagt of Klaas zeker is van deze aanpassing.
Klaas bevestigt dat hij deze aanpassing wilt doorvoeren.
Systeem bericht klaas dat het aanpassen gelukt is.
Systeem vraagt of Klaas het kostuumgebruik van deze voorstelling nog meer wilt aanpassen.
Klaas geeft aan het kostuumgebruik verder te willen aanpassen (alternative path stap 8.1).
Systeem geeft de kostuumplanner van de voorstelling weer. (alternative path stap 8.2).
Klaas geeft aan dat er ook nog 2 insect kostuums nodig zijn voor deze voorstelling.
Systeem geeft de aanpassing weer en vraagt of Klaas zeker is van deze aanpassing.
Klaas bevestigt dat hij deze aanpassing wilt doorvoeren.
Systeem bericht klaas dat het aanpassen gelukt is.
Systeem vraagt of Klaas het kostuumgebruik van deze voorstelling nog meer wilt aanpassen.
Klaas geeft aan het kostuumgebruik niet verder te willen aanpassen.

09 - Kostuumvoorraad beheren

Johan de kantoormedewerker geeft aan de voorraadlijst van de kostuums aan te willen passen.

Johan geeft aan de dat hij wijzigingen in de voorraad in wil vullen.
Systeem geeft lijst met kostuums weer.
Johan geeft aan dat hij het kostuum met de naam "kablam" wil aanpassen.
Systeem vraagt naar hoeveelheid in voorraad.
Johan voert "10" in.
Systeem vraagt of er nog een wijziging is.
Johan geeft aan dat er geen wijzigingen meer zijn.

Johan de kantoormedewerker geeft aan de voorraadlijst van de kostuums aan te willen passen.

Johan geeft aan de dat hij wijzigingen in de voorraad in wil vullen.
Systeem geeft lijst met kostuums weer.
Johan geeft aan dat hij een nieuw kostuum wil invoegen. (alternative path stap 3.1)
Systeem vraagt naar de naam van het kostuum. (alternative path stap 3.2)
Johan voert de naam "alien kostuum" in. (alternative path stap 3.3)
Systeem springt terug naar stap 4 en vraagt naar hoeveelheid in voorraad. (alternative path stap 3.4)
Johan voert "3" in.
Systeem vraagt of er nog een wijziging is.
Johan geeft aan dat er geen wijzigingen meer zijn.

Johan de kantoormedewerker geeft aan de voorraadlijst van de kostuums aan te willen passen.

Johan geeft aan de dat hij wijzigingen in de voorraad in wil vullen.
Systeem geeft lijst met kostuums weer.
Johan geeft aan dat hij de voorraad van het kostuum met de naam "alien kostuum" wil wijzigen.
Systeem vraagt naar de hoeveelheid in voorraad.
Johan voert "1" in.
Systeem vraagt of er nog een wijziging is.
Johan geeft aan dat hij nog een wijziging wil doen (alternative path stap 7.1).
Systeem gaat terug naar stap 2 en geeft de lijst met kostuums weer (alternative path stap 7.2).
Johan geeft aan dat hij de voorraad van het kostuum met de naam "ruimte kostuum" wil wijzigen.
Systeem vraagt naar de hoeveelheid in voorraad.
Johan voert "3" in.
Systeem vraagt of er nog een wijziging is.
Johan geeft aan dat hij geen wijzigingen meer heeft.

Johan de kantoormedewerker geeft aan de voorraadlijst van de kostuums aan te willen passen.

Johan geeft aan de dat hij wijzigingen in de voorraad in wil vullen.
Systeem geeft lijst met kostuums weer.
Johan geeft aan dat hij het kostuum met de naam "kablam" wil aanpassen.
Systeem vraagt naar hoeveelheid in voorraad.
Johan geeft aan dat hij het verkeerde kostuum heeft gekozen (alternative path stap 4.1).
Systeem springt terug naar stap 2 en geeft lijst met kostuums weer (alternative path stap 4.2).
Johan geeft aan dat hij het kostuum met de naam "kabeljauw" wil aanpassen.
Systeem vraagt wat de hoeveelheid in voorraad is.
Johan voert "10" in.
Systeem vraagt of er nog een wijziging is.
Johan geeft aan dat er geen wijzigingen meer zijn.

Non-functional Requirements

Als we de use cases analyseren komen daar een aantal non-functional requirements uit.

Security

Verschillende soorten gebruikers hebben toegang tot het systeem. Het moet natuurlijk niet mogelijk zijn dat een speler zomaar de planning van iemand aan kan passen. Er moet dus duidelijk een scheiding van rechten zijn tussen de spelers en de kantoormedewerkers. Vanzelfsprekend mag iemand die geen lid is van Close Act geen toegang tot het systeem hebben.

Availability

Een uptime van 100% is erg duur en haast onmogelijk. Het systeem moet wel dag en nacht kunnen draaien, want spelers moeten bijvoorbeeld op iedere gewenst moment hun beschikbaarheid kunnen opgeven. Echter is een korte uitval van het systeem geen ramp: Als kantoormedewerkers en spelers een half uur niet bij hun agenda kunnen is dat geen grote ramp. Het systeem moet dus zo veel als mogelijk is beschikbaar zijn, maar een kleine storing af en toe is geen ramp. Hierdoor kunnen de kosten voor een 100% uptime enigzins gedrukt worden, want pakweg 95% is ook voldoende.

Usability

Het systeem mag de gebruikers niet in de weg zitten en moet duidelijk een verbetering zijn voor het huidige systeem. Dit is misschien een beetje een open deur, maar het moet toch duidelijk vermeld worden. Eén van de eisen die gesteld zijn is dat het systeem duidelijk een meerwaarde moet bieden tegenover wat er nu gebruikt wordt. Vandaar dat hier goed op gelet moet worden.

Addendum

Integrated Domainmodel

Business Rules Catalogue

Uit de ORM-modellen, het informatiepakket en de gesprekken met de stakeholder kunnen we een aantal business rules afleiden.

Een voorstelling kan maximaal een week van te voren geannuleerd worden, zodra dit later is moeten de spelers die in die voorstelling zouden spelen uitbetaald worden.
Spelers moeten ook van elkaar kunnen zien hoeveel ze werken.
Opdrachten die binnenkomen worden door kantoormedewerkers in het systeem gezet.
Een speler mag zijn beschikbaarheid voor een bepaalde datum wijzigen zolang hij niet ingepland is voor die datum.
Als een speler ingepland is kan hij zichzelf niet zomaar uitschrijven.
Een kantoormedewerker kan een ingeplande speler alleen uitschrijven met een goede reden.
Als een speler aangeeft op een bepaalde datum beschikbaar te zijn, kan hij worden ingepland voor een voorstelling op die datum.
Alle spelers die voor Close Act werken moeten hun beschikbaarheid opgeven.
De opdrachtgeverinformatie moet bekend zijn alvorens een opdracht geaccepteerd kan worden.
Spelers moeten met hun NAW-gegevens geregristeerd staan. Ook moet er bekend zijn of ze een rijbewijs hebben en of ze vegetariër zijn.
Kostuums mogen alleen ingepland zijn als ze beschikbaar zijn. Dat wil zeggen: kostuums mogen niet twee keer voor dezelfde voorstelling worden ingepland.
Kostuums mogen alleen worden ingepland als er minstens 2 dagen tussen de geplande voorstelling zit waarvoor zij nodig zijn. Dit in verband met het vervoeren van de kostuums.

Terminological Definitions

Definitie	Betekenis
Close Act	Close Act is een theatergroep die met zelfgemaakte kostuums optreedt op verschillende internationale festivals. Close Act werkt vooral met uitzendkrachten als spelers.
Voorstelling	Een optreden van Close Act. Hierbij zijn spelers en kostuums nodig. Close Act heeft opdrachtgevers waarvoor ze voorstellingen leveren.
Opdracht	Een opdracht is een voorstelling die Close Act op een bepaalde tijd en locatie uitvoert. Een opdracht wordt verkregen door een opdrachtgever.
Opdrachtgever	Een opdrachtgever is een klant van Close Act die werk in de vorm van voorstellingen levert aan Close Act met een contract.
Beschikbaarheid	Spelers moeten bij Close Act aangeven ruim van te voren aangeven wanneer ze willen spelen in voorstellingen (en dus beschikbaar zijn). Op momenten dat een speler beschikbaar is kan hij worden ingepland voor een voorstelling.
Spelersplanner	Een lijst van alle spelers waarin staat wanneer ze beschikbaar zijn en wanneer ze ingepland kunnen worden voor een voorstelling.
Kostuum	Bij een voorstelling hebben spelers meestal kostuums aan. Deze worden door Close Act zelf gemaakt en hebben verschillende maten waar rekening mee gehouden moet worden.
Sjabloon	Als kantoormedewerkers informatie in moeten vullen het systeem, wordt er bij verschillende use cases een sjabloon getoond. In dit sjabloon staan een aantal dingen al standaard ingevuld (hang af van het soort sjabloon) en de kantoormedewerker hoeft hier enkel nog de extra informatie bij in te vullen.
Opdrachtensjabloon	Een sjabloon waarin alle informatie over een opdracht ingevuld kan worden.
Opdrachtgeversjabloon	Een sjabloon waarin alle informatie over een opdrachtgever ingevuld kan worden.
Spelerssjabloon	Een sjabloon waarin alle informatie over een speler ingevuld kan worden.

Terug naar boven

Requirements Engineering/het werk/werkstuk/2011-12/Groep 06