'

Werkstuk Requirements Engineering

Martijn Liebrand, Bas Elbers, Pieter Laatum, Gijs Mooren en Ahmed Taha

Onderwijsinstituut voor Informatica en Informatiekunde

Radboud Universiteit Nijmegen

version 18 februari 2022

Page Break

De inhoud is opgebouwd als volgt.

Inhoud

1 Introduction
- 1.1 Close Act Requirements Document ^[1]
- 1.2 Problem statement
2 Case analysis
3 Requirements
4 Addendum
5 Bronnen

Introduction

Close Act Requirements Document ^[1]

Close Act is een professionele theatergroep die over de gehele wereld voorstellingen opvoert. De acts lopen zeer uiteen en het gebruik van hun eigen gemaakte kostuums en materiaal zorgen voor een uniek geheel. Het aantal artiesten dat onderdeel is van een show, kan variëren tussen de 1 en een totaal van 35 mannen en vrouwen. Er zijn uiteraard meer artiesten, maar de contracten zijn op basis van oproep. De selectie van de artiesten gebeurt door het management zelf, daarbij geldt dat de voorkeur uitgaat voor de beste artiest die de betreffende act kan doen. Behoud van artiesten is ook van belang, maar de show staat voorop.

Het unieke aspect is wat Close Act tot een succes maakt, maar tegelijkertijd ook veel vergt van de mensen binnen de organisatie. Er is geen standaard protocol wat bij elke voorstelling hetzelfde is. Alleen al het feit dat er op allerlei verschillende locaties optredens worden gegeven, zorgt voor de noodzaak tot een dynamische vorm van voorbereiden. Daarbij is de kennis van de planner(s) van cruciaal belang.

Het plannen van voorstellingen is lastig, tijdrovend en arbeidsintensief werk. De gebruiker dient zelf rekening te houden met alle werknemers, de huidige planning, kostuums, logistiek en alle geschreven en ongeschreven regels van de locatie. Bij dit laatste moet je denken aan de wet, maar ook aan de cultuur of religie. Hierbij moet ruim van tevoren al aan alles worden gedacht, van het afstemmen van het geluid vanwege mogelijk geluidsoverlast tot het regelen van een vergunning voor het afsteken van vuurwerk.

Het enige waar momenteel van gebruik wordt gemaakt om dit alles voor elkaar te krijgen, is de kennis en ervaring van het personeel. Een ondersteunend systeem die de enorme stress zou kunnen reduceren, ontbreekt volledig. Er wordt voornamelijk gebruik gemaakt van Outlook en Excel, hetzelfde als een groot kladblok waar je alles in gooit. Er bestaan templates voor o.a. een contract of speelinfo en ook is er gedacht aan de legenda voor de gebruikte labels. De templates zijn alleen geen formulieren, maar vakjes in Word. Over de labels is door het personeel al eens het volgende gezegd: "agenda labels: die liggen nu 'vast' maar eigenlijk willen we ze aanpassen maar ik ben er nog niet achter hoe ik dat kan doen in outlook".

Dit document zal de requirements bevatten voor het te maken systeem voor Close Act. Het te ontwikkelen systeem zal alle huidige functionaliteiten samenvoegen in één geheel. Hierbij is het de bedoeling dat de aparte onderdelen zodanig gelinkt worden dat het een invloed heeft op het ander. Een artiest kan nou eenmaal niet op twee plekken tegelijk zijn, dan moet het systeem dit ook niet toelaten.

Problem statement

Het huidige informatiesysteem van Close Act is dermate niet gebruiksvriendelijk dat ermee werken erg tijdrovend is. Bovendien is het een foutgevoelig systeem. Daarom wil Close Act in de toekomst een systeem dat minder tijdrovend en foutgevoelig is. Ook is Close Act niet helemaal content met de huidige werkwijze van het planner systeem. Hoewel dit systeem tot op zekere hoogte naar behoren werkt, is Close Act ervan overtuigd dat dit beter kan. Zowel voor de planners als voor de spelers die worden ingepland. Hieronder is een overzicht gemaakt.

Om deze problemen te verhelpen, dient er een geïntegreerd systeem te worden opgeleverd die tevens dezelfde functionaliteiten biedt als het huidige systeem.

De drie primaire doelen van de integratie zijn:

Tijdsbesparing
Foutreductie
Verbetering planner systeem

Case analysis

Stakeholder analysis

Stakeholder Analysis
Stakeholder	Role	Description	Contact
Niels Braakensiek	Kantoormedewerker/Administratie	Vaak Part-Time medewerkers voor planning van voorstellingen en logistiek	Niels Braakensiek
Niels Braakensiek	Spelers	Alle spelers van alle voorstellingen	Niels Braakensiek
Niels Braakensiek	Ateliermedewerker	Werknemers die werken aan kostuums	Niels Braakensiek

Mission and vision statement

Mission

De primaire missie van het project zal zijn om het huidige systeem zodanig te verbeteren dat al de betrokken gebruikers efficiënter en effectiever te werk kunnen gaan. Hierbij zal voornamelijk het plannen (spelers, kostuum, agenda) centraal staan, aangezien dit momenteel nog allemaal handmatig aan elkaar gekoppeld wordt.

Vision

Het eindproduct zal een geïntegreerd systeem worden die de nu nog afzonderlijke deelsystemen aan elkaar koppelt. Daarbij is het streven om zoveel mogelijk werk uit de handen te nemen van de gebruikers als het gaat om planning en orderbewaking.

Value

De gebruikers moeten met het systeem kunnen én willen werken. Daarbij is het de bedoeling dat het systeem rust biedt door een eenvoudige en overzichtelijke werkwijze. Daarnaast zal (waarschijnlijk) de huidige flexibiliteit gewaarborgd moeten worden vanwege de complexe structuur van het geheel.

Statement of work

Deliverable	Facade iteratie	Filled iteratie	Focused iteratie
Introduction	Preliminary version	Preliminary version	Complete
Problem statement	As good as possible	As good as possible	Complete
Stakeholder list/analysis	As good as possible	As good as possible	Complete
Mission-vision-(values)	Complete	Complete	Complete
Statement of work	Complete, and up-to-date	Complete, and up-to-date	Complete, and up-to-date
Risk analysis	Complete, and up-to-date	Complete, and up-to-date	Complete, and up-to-date
Use case survey	As good as possible	Nearly complete	Complete
Integrated UC diagram	Complete (though preliminary)	Complete	Complete
Use cases	Not yet!	"Filled" level	Complete
Scenarios	Not yet!	Several for each UC	Complete ("focused" level)
Domain models	Not yet!	Partially complete	Complete
Business Rules per Use Case	Not yet!	Partially complete	Complete
Integrated domain model	Not yet!	Partially complete	Complete
Business rules catalogue	Not yet!	Partially complete	Complete
Non-functional requirements	Notes	Partially complete	Complete
Terminological definitions	Notes	Partially complete	Complete
Executive sponsor viewpoint	Complete (integrated in M-V-V!)	Complete (integrated in M-V-V!)	Complete (integrated in M-V-V!)
Use case tests	Notes	As good as possible	Complete
Business process definitions	If available / relevant	If relevant	If relevant
GUI metaphors / storyboards	If relevant	If relevant	If relevant

Legenda:
: Nog niet nodig of N.V.T.
: Voor nu af.
: Moet nog naar gekeken worden.
: Moet nog worden gedaan!

Logboek

28-03-2012 Interview stakeholder Niels
17-04-2012 Facade Deadline
19-04-2012 Mondelinge feedback Niels (12:40-13:10)
29-05-2012 Filled Deadline
22-06-2012 Focused Deadline

Risk analysis

#	Category	Risk	Solution needed by	Status	Days lost	Expectancy factor	Risk factor
01	Groepsleden	Ziekte	Vanaf start project	Close	10	70%	7
02	Groepsleden	Afspraken niet na komen	Vanaf start project	Open	6	50%	3
03	Groepsleden	Verlaten Cursus	Vanaf start project	Close	20	10%	2
04	Planning	Missen Deadlines	Direct na de deadline	Open	10	30%	3
05	Data	Data verloren (bv door tegelijk werken in wiki)	Vanaf start project	Afspraken worden gemaakt	4	50%	2
06	Opdrachtgever	Faillissement Close Act	Vanaf start project	Onderzoek gevolgen belastingverhoging	100	<1%	1

Requirements

Use cases

UC01 Aanvraag Opstellen
UC02 Spelers Inplannen
UC03 Kostuums Inplannen
UC04 Optie Bevestigen
UC05 Spelers Beheren
UC06 Kostuums Beheren
UC07 Beschikbaarheid Bewerken
UC08 Acts beheren (facade maar final)

Use case survey

#	Name	Initiating actor	Description	Completeness	Maturity	Source	Comments
01	Aanvraag Opstellen	Kantoormedewerker	Het opstellen / wijzigen / beheren van een (nieuwe) aanvraag. Hier wordt gekeken of de eisen van de klant kunnen worden nageleefd.	Focused	preliminary	Interview, ^[2]
02	Spelers inplannen	Kantoormedewerker	Het inplannen van speler voor een bepaalde optie op basis van beschikbaarheid van spelers	Focused	preliminary	Interview, ^[2]
03	Kostuums inplannen	Kantoormedewerker	Het inplannen van kostuums voor een bepaalde optie op basis van beschikbaarheid van spelers	Focused	preliminary	Interview, ^[2]	De vraag is of in welke stadium deze use case zal worden aangeroep. Wellicht bij het plaatsen van een optie, maar misschien wel tijdens het inplannen van een speler?
04	Optie bevestigen	Kantoormedewerker	Het bevestigen van een optie.	Focused	preliminary	Interview, ^[2]
05	Spelers Beheren	Kantoormedewerker	Het toevoegen of bewerken van een speler van Close Act.	Focused	preliminary	Interview, ^[2]
06	Kostuums Beheren	Ateliermedewerker/ Kantoormedewerker	Het toevoegen van een kostuum aan set van kostuums	Focused	preliminary	Interview, ^[2]
07	Beschikbaarheid Bewerken	Speler	Bekijken van rooster en daarin de eigen beschikbaarheid aangeven	Focused	preliminary	Interview, ^[2]
08	Acts beheren	Kantoormedewerker	Hier worden alle acts aangemaakt en bijgehouden. De informatie die hierbij hoort zijn welke kostuums ervoor nodig zijn en hoeveel, hoeveel spelers (optioneel), welke spelers de act kunnen uitvoeren (eventueel met een aanduiding van hoe goed) en hoe duur het is (binnen Nederland, EU en buiten de EU).	Facade	Preliminary (final)	Interview, ^[2]	Deze UC is niet uitgewerkt, omdat het vrij weinig toevoegt. Het moet er wel zijn om het geheel te laten werken, maar de invulling is straight-forward en arbeidsintensief.

Integrated use case diagram

Individual use cases

UC01 Aanvraag Opstellen

Use Case:	UC01 Aanvraag Opstellen
Description	Het opstellen / wijzigen / beheren van een (nieuwe) aanvraag. Hier wordt met behulp van het systeem gekeken of de wensen van de klant kunnen worden nageleefd (dit kan samen met de klant of achteraf). Als de wensen duidelijk zijn kan er eventueel een (automatische) offerte worden gestuurd. Beide partijen kunnen echter ook zonder offerte tot een overeenkomst komen. Als beide partijen (onofficieel) akkoord zijn, dan kan een medewerker de aanvraag veranderen in een optie. Op dat moment zal alle overige informatie verzameld worden en wordt het definitieve contract opgesteld en opgestuurd.
Source	Interview Niels Braakensiek
Version	Focused
Trigger	Medewerker wilt een aanvraag invoeren / wijzigen.
Basic course of events	1. De medewerker kiest in programma voor optie: 'Nieuwe aanvraag klant'. 2. Het systeem vraagt de gebruiker op welke data en waar het evenement plaats zal vinden. 3. De medewerker vult de data en locatie in. 4. Het systeem vraagt de gebruiker om welke act(s) het gaat. 5. De medewerker selecteert de betreffende act(s) en geeft aan dat de (getoonde) standaard kostuums van toepassing zijn. 6. Het systeem triggert 'Spelers Inplannen' (van UC: Spelers inplannen). 7. Het systeem komt terug uit 'Spelers Inplannen' (van UC: Spelers inplannen), geeft een overzicht van de nieuwe aanvraag en vraagt de gebruiker of deze door wilt gaan. 8. De medewerker wil doorgaan naar het invoeren van de klantgegevens. 9. Het systeem vraagt de gebruiker naar klantgegevens. 10. De medewerker vult klantgegevens in. 11. Het systeem geeft een overzicht en vraagt de gebruiker of alle gegevens juist zijn. 12. De medewerker bevestigt de aanvraag en sluit af.
Alternate paths	Optie plaatsen 1. De medewerker kiest in het programma voor de optie: 'Optie plaatsen'. 2. Het systeem geeft de lijst weer met alle aanvragen. 3. De medewerker kiest de aanvraag die als optie geplaatst moet worden. 4. Het systeem geeft een overzicht van de aanvraag en vraagt of beide partijen (onofficieel) akkoord zijn. 5. De medewerker gaat akkoord. 6. Het systeem opent de nieuwe optie met de standaard template 'speelinfo' voor een evenement. 7. De medewerker vult eventueel in wat deze al kan invullen en sluit af. Optie aanvullen of bewerken 1. De medewerker kiest in programma voor optie: 'Optie aanvullen'. 2. Het systeem geeft een overzicht, met daarbij de huidige speelinfo. 3. De medewerker kiest het onderdeel (of onderdelen) en wijzigt deze / vult deze aan. 5. De medewerker bevestigt de gewijzigde speelinfo en sluit af. Aanvraag bewerken 1. De medewerker kiest in programma voor optie: 'Wijzigen aanvraag klant'. 2. Het systeem geeft een lijst weer van alle mogelijke onderdelen die gewijzigd kunnen worden. 3. De medewerker kiest het onderdeel (of onderdelen) en wijzigt deze. 4. Het systeem vraagt of de wijziging correct is, het oude overzicht kan worden gearchiveerd en het huidige overzicht dus het nieuwe overzicht wordt. 5. De medewerker bevestigt de gewijzigde aanvraag en sluit af. Offerte maken 1. De medewerker kiest in programma voor optie: 'Offerte maken'. 2. Het systeem geeft een lijst weer van alle huidige aanvragen. 3. De medewerker kiest de juiste aanvraag. 4. Het systeem laat een overzicht van de offerte zien en vraagt hoe de offerte moet worden uitgevoerd (mail, print, .doc, .pdf). 5. De medewerker selecteert een of meerdere opties. 6. Het systeem voert het uit en sluit af. Nieuwe act of andere kostuums (4 mogelijke opties) 5. De medewerker geeft aan dat het niet gaat om de standaard kostuums of een standaard act. 6. Het systeem vraagt of het een nieuwe act is, de standaard kostuums wilt wijzigen, of dat deze volledig handmatig kostuums wilt toevoegen. 7.1 Medewerker wilt een nieuwe act toevoegen. 8. Het systeem triggert 'Nieuwe act toevoegen' (van UC: Acts toevoegen / beheren). 9. Het systeem komt terug uit 'Nieuwe act toevoegen' (van UC: Acts toevoegen / beheren) Terug naar BcOE 5. 5. De medewerker geeft aan dat het niet gaat om de standaard kostuums of een standaard act. 6. Het systeem vraagt of het een nieuwe act is, de standaard kostuums wilt wijzigen, of dat deze volledig handmatig kostuums wilt toevoegen. 7.2 Medewerker wilt van de standaard kostuums nog eventueel kostuums toevoegen of verwijderen. 8. Het systeem geeft de standaard kostuums bij de act weer. 9. De medewerker wijzigt de lijst van kostuums voor deze act en bevestigt deze. Terug naar BcOE 6. 5. De medewerker geeft aan dat het niet gaat om de standaard kostuums of een standaard act. 6. Het systeem vraagt of het een nieuwe act is, de standaard kostuums wilt wijzigen, of dat deze volledig handmatig kostuums wilt toevoegen. 7.3 Medewerker wilt voor de act handmatig de kostuums toevoegen. 8. Het systeem geeft de lijst met mogelijke kostuums. 9. De medewerker wijzigt de lijst van kostuums voor deze act en bevestigt deze. Terug naar BcOE 6. 5. De medewerker geeft aan dat het niet gaat om de standaard kostuums of een standaard act. 6. Het systeem vraagt of het een nieuwe act is, de standaard kostuums wilt wijzigen, of dat deze volledig handmatig kostuums wilt toevoegen. 7.4 Medewerker wilt bestaande act definitief wijzigen. 8. Het systeem triggert 'Act beheren' (van UC: Acts toevoegen / beheren). 9. Het systeem komt terug uit 'Act beheren' (van UC: Acts toevoegen / beheren). Terug naar BcOE 5. Bestaande klant invoeren 10.1 De medewerker wil een bestaande klant invoeren. 11. Systeem vraagt naar naam of toont lijst van alle klanten. 12. Medewerker kiest klant. Terug naar BCoE 11. Snelle controle beschikbaarheid 1. De medewerker kiest in het programma voor "Snelle controle beschikbaarheid". 2. Het systeem vraagt de gebruiker op welke data en waar het evenement plaats zal vinden, binnen Nederland, EU of buiten de EU. 3. De medewerker vult de data en locatie in. 4. Het systeem vraagt de gebruiker om een lijst op basis van beschikbaarheid (of op basis van bezetting). 5. De medewerker vult in op basis van beschikbaarheid (of op basis van bezetting). 6. Het systeem geeft aan welke acts / kostuums / spelers er wel (of niet) beschikbaar zijn. 7. Medewerker slaat de lijst op / print de lijst af / mailt de lijst, en sluit af.
Exception paths	Data en/of locatie onbekend 3.1 Medewerker geeft aan dat deze de datum/locatie/beide niet in kan voeren. 4. Het systeem vraagt de medewerker om expliciet te bevestigen dat de betreffende datum/locatie niet kan worden ingevoerd. 5. Medewerker geeft aan dat deze zich bewust is van de gevolgen voor het systeem en dat de aanvraag niet (volledig) in de agenda kan worden verwerkt. Terug naar BcOE 4 Conflict acts 5.1 Het systeem geeft aan dat er een conflict is met een ander evenement. 6. Het systeem laat zien welk evenement een conflict geeft, inclusief act en tijdstip. 7.1 Medewerker wil het huidige evenement aanpassen Terug naar BCoE 4 7.2 Medewerker wil het conflict (voor nu) negeren en doorgaan. Terug naar BCoE 6 7.3 Medewerker wil het andere evenement aanpassen. 8. Het systeem selecteert het andere evenement. Terug naar Alternate Path: "Aanvraag bewerken" 1. 7.4 Medewerker moet het onderzoeken. 8. Het systeem zet het huidige evenement in concepten. 9. Sluit af.
Assumptions	Er bestaat iets als een 'standaard' act, waarbij het geheel wel kan afwijken, maar binnen bepaalde grenzen (bijv. 2 Aliens i.p.v. 3). Alle acts en kostuums zijn bekend en hebben een naam.
Preconditions	Er is een klant die (mogelijk) een evenement bij Close Act wil boeken.
Postconditions	Er is een evenement aangemaakt waar zowel Close Act als de opdrachtgever het mee eens zijn en hier kan eventueel een offerte van worden gemaakt.
Related business rules	Een evenement kan maximaal 2 jaar van tevoren worden ingepland. Een evenement moet minimaal 1 week (7 kalenderdagen) van tevoren definitief worden. De prijs voor een offerte wordt gebaseerd op de lengte van de tijd waarop de specifieke spelers en kostuums weg zijn van huis, met daarnaast de prijs van de act (en eventueel de overige verwachte kosten voor vervoer en technici). Wanneer een speler al is ingepland voor een definitief optreden, dient deze niet te worden ingepland bij een andere evenement met overlappende data (inclusief vervoer heen en terug). Wanneer een kostuum al is ingepland voor een definitief optreden, dient deze niet te worden ingepland bij een andere evenement met overlappende data (inclusief vervoer heen en terug). Wanneer er geen alternatieven zijn voor botsende evenementen (d.w.z. een speler is niet te vervangen door andere speler(s), zodanig dat er geen conflicten meer optreden), zal het management hierover beslissen. Wanneer een speler / kostuum al is ingepland voor een mogelijk optreden (dus nog niet definitief), dient deze niet te worden ingepland bij een ander evenement met overlappende data, tenzij dit niet anders kan (d.w.z. er zijn geen alternatieve spelers / kostuums inzetbaar voor dit evenement, of het botsende evenement / de botsende evenementen). Een speler / kostuum kan alleen met toestemming van het management op een ander evenement worden ingepland als deze al voor een mogelijk optreden staat ingepland. Bij bevestiging van een aanvraag (stap 12 BCoE, stap 5 Alt Path: 'Aanvraag bewerken'), worden (wanneer mogelijk) de statussen van de spelers, kostuums en de agenda gewijzigd in een mogelijk evenement (let op, dit is nog géén optie!). Spelers / ateliermedewerkers / kantoormedewerkers / klanten worden, bij élke wijziging dat direct op hun van invloed is, schriftelijk op de hoogte gesteld (mail is schriftelijk). Als er geen datum bekend is voor een evenement, terwijl de aanvraag wel is bevestigd, zullen de statussen pas worden veranderd bij invoering. Wanneer er geen locatie bekend is, zal het de agenda binnen Nederland 5 transportdagen rekenen, buiten Nederland 28 transportdagen, zowel voor heen- als terugreis. Een act hoeft niet per se een kostuum te bevatten en we spreken al van een act bij een optreden van één persoon. Als er meerdere kostuums beschikbaar zijn met verschillende maten, wordt de juiste maat pas geselecteerd op het moment dat de daarbij behorende speler wordt geselecteerd in de planning. Als een kostuum tegelijkertijd door meerdere spelers moet worden gedragen, moeten de spelers dezelfde maten hebben als het kostuum. Alle combinaties van spelers moeten daarbij te selecteren zijn. Wijzigingen moeten te allen tijde kunnen worden teruggedraaid, de gegevens mogen nooit verloren gaan en er moet kunnen worden achterhaald wie wat heeft gewijzigd en wanneer. Een template 'speelinfo' bij een optie, haalt de standaard informatie (d.d., plaats, act etc.) uit de originele aanvraag. Als deze standaard informatie wordt gewijzigd (dit kan alleen na een extra handeling), moet er (door het systeem) worden nagegaan of er geen conflicten optreden.
Author	Bas
Date	17-05-12, 19-06-12
Additional comments	De volgorde is 'Evenement -> Act -> Kostuums -> Spelers'. Spelers kunnen meerdere kostuums hebben, maar kostuums kunnen ook meerdere spelers hebben.
ORM Model

UC02 Spelers Inplannen

Use Case:	UC02 Spelers Inplannen
Use case diagram	Spelers inplannen
Description	Het inplannen van een speler voor een aanvraag op basis van beschikbaarheid en de kwalificaties van de spelers.
Source	Interview met Niels Braakensiek
Version	Focused
Triggers	Deze UC wordt aangestuurd door UC01 'Aanvraag Opstellen'. Bij het opstellen van een aanvraag selecteert de medewerker hier de spelers.
Basic course of events	1. Het systeem geeft een overzicht van de beschikbare spelers voor de acts van het specifieke evenement. 2. De medewerker kiest bij elke act één of meerdere spelers. 3. De medewerker kiest na de selectie van spelers voor opslaan. 4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd. 5. Het systeem bevestigt de geselecteerde spelers voor het evenement. 6. De medewerker gaat terug naar het overzicht (BCoE 1) of sluit af.
Alternate paths	Planning wijzigen 1. De medewerker kiest in programma voor optie: Spelers Plannen. 2. Het systeem geeft een overzicht van geplande evenementen. 3. De medewerker kiest één van de getoonde evenementen. 4. Het systeem geeft een overzicht van de geselecteerde spelers voor het evenement. 5. De medewerker selecteert één of meerdere spelers die gepland staan. 6. De medewerker kiest voor verwijderen van de geselecteerde spelers. 7. Het systeem bevestigt de verwijderde speler(s). 8. Het systeem vraagt om het toevoegen van nieuwe spelers. 9. De medewerker kiest voor het toevoegen van nieuwe spelers aan evenement. 10. Het systeem bevestigt de toegevoegde spelers. 11. De medewerker sluit af.
Exception paths	1.1. Het systeem kan geen beschikbare spelers tonen. 2. De medewerker sluit af.
Preconditions	Er is minimaal één act toegevoegd aan een aanvraag.
Postconditions	De geselecteerde spelers zijn verbonden aan een act en het evenement.
Related business rules	Een speler kan niet worden ingepland als hij of zij al op een andere optie is ingepland. Een speler kan niet worden ingepland als hij of zij niet geschikt is voor de specifieke act. *Wanneer het minimum aantal spelers voor een act niet is bereikt, kan een aanvraag geen optie worden.
Author	Martijn, (20-06-12 Bas, sync met UC01)
Date	14-05-12
ORM Model

UC03 Kostuums Inplannen

Use Case:	UC03 Kostuums Inplannen
Use case diagram	Kostuums Inplannen
Description	Het naderhand inplannen van kostuums voor een bepaalde aanvraag.
Source	Interview met Niels Braakensiek
Version	Focused
Triggers	Medewerker wil de kostuums van een aanvraag inzien / bewerken.
Basic course of events	1. De medewerker kiest in programma voor optie: Kostuum Plannen. 2. Het systeem geeft een overzicht van alle aanvragen. 3. De medewerker kiest één van de getoonde aanvragen. 4. Het systeem geeft een overzicht van de gereserveerde kostuums voor de aanvraag, per act en het totaal. 5. De medewerker kiest één of meerdere kostuums die gepland staan, of wilt doorgaan naar BCoE 9. 6. De medewerker kiest voor verwijderen van de geselecteerde kostuums. 7. Het systeem bevestigt de verwijderde kostuums. 8. Het systeem vraagt om toevoegen van nieuwe kostuums. 9. De medewerker kiest voor het toevoegen van één of meerdere nieuwe kostuums aan de act(s), of sluit af. 10. Het systeem bevestigt de toegevoegde kostuums. 11. De medewerker sluit af.
Alternate paths	1. De medewerker kiest in programma voor optie: Kostuums Inzien. 2. Het systeem geeft een overzicht van alle aanvragen. 3. De medewerker kiest één van de getoonde aanvragen. 4. Het systeem geeft een overzicht van de gereserveerde kostuums voor de aanvraag, per act en het totaal. 5. Het systeem vraagt of het overzicht moet worden uitgevoerd (mail, print, .doc, .pdf). 6. De medewerker selecteert een of meerdere opties. 7. Het systeem voert uit en sluit af.
Exception paths
Preconditions	Een aanvraag is aangemaakt in UC01 'Aanvraag Opstellen'.
Postconditions	Er zijn kostuums toegevoegd of verwijderd.
Related business rules	Een kostuum kan niet ingepland worden als het defect is. Een kostuum kan niet ingepland worden als het al gepland staat op een ander evenement. *..
Author	Martijn, (21-06-12, Bas sync UC01)
Date	16-05-12
ORM Model

UC04 Optie Bevestigen

Use Case:	UC04 Optie Bevestigen
Use case diagram	Optie Bevestigen
Description	Het bevestigen van optie. Vanaf dit moment is er geen weg meer terug, voor beide partijen niet. Betrokkenen zullen geïnformeerd worden.
Source	Interview met Niels Braakensiek
Version	Focused
Trigger	Het contract is door de klant getekend en retour.
Basic course of events	1. De medewerker kiest in programma voor optie: Optie Bevestigen 2. Het systeem geeft een overzicht van alle lopende opties. 3. De medewerker kiest uit het overzicht één optie. 4. Het systeem laat de optie van het evenement zien, inclusief alle cruciale elementen. 5. De medewerker kiest voor bevestigen en vastleggen van de optie. 6. Het systeem bevestigt dat de optie geplaatst is.
Alternate paths
Preconditions	De planning rond het evenement is (zo goed als) compleet en er is een contract getekend door beide partijen.
Postconditions	Een compleet en definitief evenement. Alle betrokkenen zijn geïnformeerd.
Related business rules	Ieder definitief evenement heeft alle cruciale elementen van de planning geregeld. Spelers / ateliermedewerkers / kantoormedewerkers / klanten worden, bij élke wijziging dat direct op hun van invloed is, schriftelijk op de hoogte gesteld. *..
Author	Martijn, (21-06-12, Bas sync UC01)
Date	16-05-12
ORM Model

UC05 Spelers Beheren

Use Case:	UC05 Spelers Beheren
Use case diagram	Spelers Beheren
Description	Het toevoegen of bewerken van een speler van Close Act.
Source	Interview met Niels Braakensiek
Version	Focused
Basic course of events	1. De medewerker kiest in programma voor optie: Speler Toevoegen. 2. Het systeem vraagt wie er toegevoegd moet worden. 3. De medewerker voert voor- en achternaam in. 4. Het systeem vraagt in welke acts de toe te voegen speler betrokken is. 5. De medewerker selecteert minimaal één act waaraan de nieuwe speler gebonden is. 6. De medewerker bevestigt de gebonden act(s). 7. Het systeem vraagt aan welke kostuums de speler gebonden moet worden. 8. De medewerker selecteert één of meerdere kostuums en bevestigt. 9. Het systeem vraagt naar de volgende gegevens: (Volledige: NAW, geboortedatum, e-mailadres en telefoonnummer) 10. De medewerker vult de gevraagde gegevens in en bevestigt. 11. Het systeem vraagt om de default beschikbaarheid van de speler. 12. De medewerker vult de default beschikbaarheid in van de speler. 13. Het systeem geeft aan dat een speler is toegevoegd.
Alternate paths	Bewerken van bestaande speler: 4.1. Het systeem geeft aan dat de speler al bestaat. 5. Het systeem vraagt of de bestaande speler moet worden aangepast. 6. De medewerker geeft aan de speler te willen aanpassen. 7. Het systeem geeft de aan te passen gegevens weer. 8. De medewerker selecteert het aan te passen gegeven. 9. Het systeem geeft mogelijkheid tot aanpassen. 10. De medewerker past gegevens aan en bevestigt. 11. Het systeem controleert en sluit af. Missen van informatie: 2.1. Het systeem vraagt wie er toegevoegd moet worden. 3. De medewerker voert voor- en/of achternaam in. 4. Terug naar BCoE 4 4.2. Het systeem vraagt in welke acts de toe te voegen speler betrokken is. 5. De medewerker selecteert overslaan. 6. Terug naar BCoE 7 7.1. Het systeem vraagt aan welke kostuums de speler gebonden moet worden. 8. De medewerker selecteert overslaan. 9. Terug naar BCoE 9 9.1. Het systeem vraagt naar de volgende gegevens: (Volledige: NAW, geboortedatum, e-mailadres en telefoonnummer) 10. De medewerker vult zo veel mogelijk in en bevestigt. 11. Terug naar BCoE 11
Exception paths	-
Preconditions	Er is een nieuwe speler of er is een speler om de gegevens van te bewerken.
Postconditions	Speler is toegevoegd of een speler is aangepast.
Related business rules	Iedere speler heeft als gegevens minimaal een naam. ..
Author	Martijn
Date	14-05-12
ORM Model

UC06 Kostuums Beheren

Use Case:	UC06 Kostuums Beheren
Use case diagram	Kostuums Beheren
Description	Het toevoegen of bewerken van een kostuum.
Source	Interview Niels Braakensiek
Version	Focused
Basic course of events	1. De medewerker kiest in programma voor optie: Kostuum Toevoegen. 2. Het systeem vraagt aan welke act een kostuum wordt toegevoegd. 3. De medewerker selecteert één act en bevestigt haar keuze. 4. Het systeem laat een overzicht van alle kostuums van de act zien. 5. De medewerker kiest voor Toevoegen Kostuum. 6. Het systeem vraagt om de volgende gegevens: Maatrichtlijn (S/M/L) Status van Kostuum (Goed/Slecht/Defect) *Gebonden personen (Onbeperkt aantal geschikte mensen) 7. De medewerker geeft de gegevens en bevestigt. 8. Het systeem vraagt of het kostuums gebonden moet zijn aan meerdere acts. 9. De medewerker selecteert 0 of meerdere acts en bevestigt. 10. Het systeem bevestigt een nieuwe toegevoegd kostuum.
Alternate paths	Kostuum Aanpassen: 5.1. De medewerker kiest voor één van de kostuums uit het overzicht. Terug naar BCoE 6.
Preconditions	Er zijn acts aanwezig.
Postconditions	Een nieuw kostuum is gebonden aan een act of een kostuum is aangepast.
Related business rules	*Het standaard aantal personen dat in één kostuum past is 1, tenzij anders aangegeven.
Author	Martijn
Date	15-05-12
ORM Model

UC07 Beschikbaarheid Bewerken

Use Case:	UC07 Beschikbaarheid Bewerken
Use case diagram	Beschikbaarheid Bewerken
Description	Bekijken van rooster en daarin de eigen beschikbaarheid aangeven.
Source	Interview met Niels Braakensiek
Version	Focused
Basic course of events	1. De medewerker kiest in programma voor optie: Beschikbaarheid Aanpassen 2. Het systeem vraagt voor welke speler de beschikbaarheid moet worden aangepast. 3. De medewerker voert in om welke speler het gaat. 4. Het systeem geeft een overzicht van de huidige beschikbaarheid. 5. De medewerker kan de beschikbaarheid van de speler aanpassen. 6. Het systeem keurt de aanpassing goed. 7. De medewerker sluit af of keert terug naar BCoE 4.
Alternate paths	Speler Log-In: 1. De speler logt in met een eigen account. 2. Het systeem toont een overzicht van de beschikbaarheid. 3. De speler kan de beschikbaarheid van zijn agenda aanpassen. 4. Het systeem keurt de aanpassing goed. 5. Speler sluit af of keert terug naar Alternate Path 2.
Exception paths:	Fout medewerker: 6.1. Het systeem keurt de aanpassing af. 7. Het systeem geeft aan met welke regel de aanpassing in conflict is. 8. De medewerker sluit af of keert terug naar BCoE 4. Fout Speler: 4.1. Het systeem keurt de aanpassing af. 5. Het systeem geeft aan met welke regel de aanpassing in conflict is. 6. De speler sluit af of keert terug naar Alternate Path 2.
Preconditions	De betreffende speler staat in het systeem
Postconditions	De beschikbaarheid van de speler is up to date.
Related business rules	* Iedere speler kan zichzelf niet vrij gegeven voor een geplande opdracht. * Iedere speler kan zijn eigen beschikbaarheid niet veranderen voor een datum binnen x dagen/weken. * ..
Author	Martijn
Date	15-05-12
ORM Model

Domain Model per Use Case

Scenarios

Aanvraag Opstellen

1.  Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3.  Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4.  Het systeem vraagt Steven om welke act(s) het gaat.
5.  Steven selecteert de Alien act en geeft aan dat de standaardkostuums van toepassing zijn.
6.  Het systeem triggert 'Spelers Inplannen'.
	1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
	2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
	3. Steven kiest na de selectie van spelers voor opslaan.
	4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
	5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
	6. Steven gaat terug naar het overzicht.
7.  Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
8.  Steven wil doorgaan naar het invoeren van de klantgegevens.
9.  Het systeem vraagt Steven naar klantgegevens.
10. Steven vult de gegevens van park Sonsbeek in.
11. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
12. Steven bevestigt de aanvraag en sluit af.

1. Steven kiest in het programma voor de optie: 'Optie plaatsen'.
2. Het systeem geeft de lijst weer met alle aanvragen.
3. Steven kiest de aanvraag van Park Sonsbeek, om hiervan een optie te maken.
4. Het systeem geeft een overzicht van de aanvraag en vraagt of beide partijen (onofficieel) akkoord zijn.
5. Steven gaat akkoord.
6. Het systeem opent de nieuwe optie met de standaard template 'speelinfo' voor een evenement.
7. Steven vult in wat hij al weet, dat zijn de data, acts en speciale verzoeken.

1. Steven kiest in het programma voor de optie: 'Optie aanvullen'.
2. Het systeem geeft een overzicht, met daarbij de huidige speelinfo.
3. Steven kiest voor het onderdeel Speciale verzoeken en vult in dat er maar beperkte ruimte beschikbaar is
4. Steven bevestigt de gewijzigde speelinfo en sluit af.

1. Steven kiest in programma voor optie: 'Wijzigen aanvraag klant'.
2. Het systeem geeft een lijst weer van alle mogelijke onderdelen die gewijzigd kunnen worden.
3. Steven kiest de datum van het evenement en veranderd deze vaan 25 en 26 April.
4. Het systeem vraagt of de wijziging correct is, het oude overzicht kan worden gearchiveerd
   en het huidige overzicht dus het nieuwe overzicht wordt.
5. Steven bevestigt de gewijzigde aanvraag en sluit af.

1. Steven kiest in het programma voor de optie: 'Offerte maken'.
2. Het systeem geeft een lijst weer van alle huidige aanvragen.
3. Steven kiest de aanvraga van Park Sonsbeek.
4. Het systeem laat een overzicht van de offerte zien en vraagt hoe de offerte moet worden uitgevoerd (mail, print, .doc, .pdf).
5. Steven selecteert de opties mail en .pdf.
6. Het systeem voert het uit en sluit af.

1.  Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3.  Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4.  Het systeem vraagt Steven om welke act(s) het gaat.
5.  Steven geeft aan dat het niet gaat om de standaard kostuums of een standaard act.
6.  Het systeem vraagt of het een nieuwe act is, de standaard kostuums wil wijzigen, of dat deze volledig handmatig kostuums wil toevoegen.
7.  Steven wil een nieuwe act toevoegen.
8.  Het systeem triggert 'Nieuwe act toevoegen' (van UC: Acts toevoegen / beheren).
	1. ?????
9.  Het systeem komt terug uit 'Nieuwe act toevoegen' (van UC: Acts toevoegen / beheren)
10. Steven wil doorgaan naar het invoeren van de klantgegevens.
11. Het systeem vraagt Steven naar klantgegevens.
12. Steven vult de gegevens van park Sonsbeek in.
13. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
14. Steven bevestigt de aanvraag en sluit af.

1. Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2. Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3. Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4. Het systeem vraagt Steven om welke act(s) het gaat.
5. Steven geeft aan dat het niet gaat om de standaard kostuums of een standaard act.
6. Het systeem vraagt of het een nieuwe act is, Steven de standaard kostuums wil wijzigen,
of dat hij volledig handmatig kostuums wil toevoegen.
7 Steven wil een nieuwe act toevoegen.
8. Het systeem triggert 'Nieuwe act toevoegen' (van UC: Acts toevoegen / beheren).
1. ???
9. Het systeem komt terug uit 'Nieuwe act toevoegen' (van UC: Acts toevoegen / beheren)
10. Het systeem triggert 'Spelers Inplannen'.
1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
3. Steven kiest na de selectie van spelers voor opslaan.
4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
6. Steven gaat terug naar het overzicht.
11. Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
12. Steven wil doorgaan naar het invoeren van de klantgegevens.
13. Het systeem vraagt Steven naar klantgegevens.
14. Steven vult de gegevens van park Sonsbeek in.
15. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
16. Steven bevestigt de aanvraag en sluit af.

1. Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2. Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3. Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4. Het systeem vraagt Steven om welke act(s) het gaat.
5. Steven geeft aan dat het niet gaat om de standaard kostuums of een standaard act.
6. Het systeem vraagt of het een nieuwe act is, Steven de standaard kostuums wil wijzigen,
of dat hij volledig handmatig kostuums wil toevoegen.
7. Steven wil bij de standaard kostuums van de alienact een kostuum toevoegen.
8. Het systeem geeft de standaard kostuums bij de act weer.
9. Steven voegt een kostuum toe aan de lijst met standaardkostuums.
10. Het systeem triggert 'Spelers Inplannen'.
1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
3. Steven kiest na de selectie van spelers voor opslaan.
4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
6. Steven gaat terug naar het overzicht.
11. Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
12. Steven wil doorgaan naar het invoeren van de klantgegevens.
13. Het systeem vraagt Steven naar klantgegevens.
14. Steven vult de gegevens van park Sonsbeek in.
15. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
16. Steven bevestigt de aanvraag en sluit af.

1. Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2. Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3. Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4. Het systeem vraagt Steven om welke act(s) het gaat.
5. Steven geeft aan dat het niet gaat om de standaard kostuums of een standaard act.
6. Het systeem vraagt of het een nieuwe act is, Steven de standaard kostuums wil wijzigen,
of dat hij volledig handmatig kostuums wil toevoegen.
7. Steven wil voor de act handmatig de kostuums toevoegen.
8. Het systeem geeft de lijst met mogelijke kostuums.
9. Steven geeft aan dat bij de act twee alienkostuums en een insectenkostuum horen..
10. Het systeem triggert 'Spelers Inplannen'.
1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
3. Steven kiest na de selectie van spelers voor opslaan.
4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
6. Steven gaat terug naar het overzicht.
11. Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
12. Steven wil doorgaan naar het invoeren van de klantgegevens.
13. Het systeem vraagt Steven naar klantgegevens.
14. Steven vult de gegevens van park Sonsbeek in.
15. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
16. Steven bevestigt de aanvraag en sluit af.

1. Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2. Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3. Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4. Het systeem vraagt Steven om welke act(s) het gaat.
5. Steven geeft aan dat het niet gaat om de standaard kostuums of een standaard act.
6. Het systeem vraagt of het een nieuwe act is, Steven de standaard kostuums wil wijzigen,
of dat hij volledig handmatig kostuums wil toevoegen.
7 Steven wil de bestaande alienact definitief wijzigen.
8. Het systeem triggert 'Act beheren' (van UC: Acts toevoegen / beheren).
1. ??????
9. Het systeem komt terug uit 'Act beheren' (van UC: Acts toevoegen / beheren).
10. Het systeem triggert 'Spelers Inplannen'.
1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
3. Steven kiest na de selectie van spelers voor opslaan.
4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
6. Steven gaat terug naar het overzicht.
11. Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
12. Steven wil doorgaan naar het invoeren van de klantgegevens.
13. Het systeem vraagt Steven naar klantgegevens.
14. Steven vult de gegevens van park Sonsbeek in.
15. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
16. Steven bevestigt de aanvraag en sluit af.

1.  Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3.  Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4.  Het systeem vraagt Steven om welke act(s) het gaat.
5.  Steven selecteert de Alien act en geeft aan dat de standaardkostuums van toepassing zijn.
6.  Het systeem triggert 'Spelers Inplannen'.
	1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
	2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
	3. Steven kiest na de selectie van spelers voor opslaan.
	4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
	5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
	6. Steven gaat terug naar het overzicht.
7.  Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
8.  Steven wil doorgaan naar het invoeren van de klantgegevens.
9.  Het systeem vraagt Steven naar klantgegevens.
10. Steven wil een bestaande klant invoeren.
11. Systeem vraagt naar naam en toont lijst van alle klanten.
12. Steven zoekt naar "Sonsbeek" en klikt dit in de lijst aan.
13. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
14. Steven bevestigt de aanvraag en sluit af.

1. Steven kiest in het programma voor "Snelle controle beschikbaarheid".
2. Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden, binnen Nederland, EU of buiten de EU.
3. Steven vult in dat het om 10 t/m 17 September gaat, in een land buiten Nederland, maar binnen de EU.
4. Het systeem vraagt Steven om een lijst op basis van beschikbaarheid (of op basis van bezetting).
5. Steven vult een lijst op basis van beschikbaarheid in.
6. Het systeem geeft aan welke acts / kostuums / spelers er wel (of niet) beschikbaar zijn.
7. Steven slaat de lijst op, print de lijst uit en sluit af.

1. Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2. Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3. Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4. Steven selecteert de Alien act en geeft aan dat de standaardkostuums van toepassing zijn.
5. Het systeem geeft aan dat er een conflict is met een ander evenement.
6. Het systeem laat zien welk evenement een conflict geeft, inclusief act en tijdstip.
7. Steven wil het huidige evenement aanpassen.
8. Het systeem vraagt Steven om welke act(s) het gaat.
9. Steven selecteert de insectenact en geeft aan dat de standaardkostuums van toepassing zijn.
10. Het systeem triggert 'Spelers Inplannen'.
1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
3. Steven kiest na de selectie van spelers voor opslaan.
4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
6. Steven gaat terug naar het overzicht.
11. Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
12. Steven wil doorgaan naar het invoeren van de klantgegevens.
13. Het systeem vraagt Steven naar klantgegevens.
14. Steven vult de gegevens van park Sonsbeek in.
15. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
16. Steven bevestigt de aanvraag en sluit af.

1.  Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3.  Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4.  Steven selecteert de Alien act en geeft aan dat de standaardkostuums van toepassing zijn.
5.  Het systeem geeft aan dat er een conflict is met een ander evenement.
6.  Het systeem laat zien welk evenement een conflict geeft, inclusief act en tijdstip.
7   Steven wil het conflict (voor nu) negeren en doorgaan.
8.  Het systeem triggert 'Spelers Inplannen'.
	1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
	2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
	3. Steven kiest na de selectie van spelers voor opslaan.
	4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
	5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
	6. Steven gaat terug naar het overzicht.
9.  Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
10. Steven wil doorgaan naar het invoeren van de klantgegevens.
11. Het systeem vraagt Steven naar klantgegevens.
12. Steven vult de gegevens van park Sonsbeek in.
13. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
14. Steven bevestigt de aanvraag en sluit af.

1. Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2. Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3. Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4. Steven selecteert de Alien act en geeft aan dat de standaardkostuums van toepassing zijn.
5. Het systeem geeft aan dat er een conflict is met een ander evenement.
6. Het systeem laat zien welk evenement een conflict geeft, inclusief act en tijdstip.
7 Steven wil het andere evenement aanpassen.
8. Het systeem selecteert het andere evenement.
9. Het systeem geeft een lijst weer van alle mogelijke onderdelen die gewijzigd kunnen worden.
10. Steven kiest de datum van het evenement en veranderd deze vaan 25 en 26 April.
11. Het systeem vraagt of de wijziging correct is, het oude overzicht kan worden gearchiveerd
en het huidige overzicht dus het nieuwe overzicht wordt.
12. Steven bevestigt de gewijzigde aanvraag en sluit af.
13. Het systeem selecteert het eerste evenement.
14. Het systeem triggert 'Spelers Inplannen'.
1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
3. Steven kiest na de selectie van spelers voor opslaan.
4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
6. Steven gaat terug naar het overzicht.
15. Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
16. Steven wil doorgaan naar het invoeren van de klantgegevens.
17. Het systeem vraagt Steven naar klantgegevens.
18. Steven vult de gegevens van park Sonsbeek in.
19. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
14. Steven bevestigt de aanvraag en sluit af.

1.  Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3.  Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
5.  Steven selecteert de Alien act en geeft aan dat de standaardkostuums van toepassing zijn.
6.  Het systeem geeft aan dat er een conflict is met een ander evenement.
7.  Het systeem laat zien welk evenement een conflict geeft, inclusief act en tijdstip.
8   Steven moet het onderzoeken.
9.  Het systeem zet het huidige evenement in concepten.
10. Steven sluit af.

spelers inplannen

1.  Steven kiest in het programma voor de optie: Spelers Plannen.
2.  Het systeem geeft een overzicht van geplande evenementen.
3.  Steven kiest het evenement in park Sonsbeek.
4.  Het systeem geeft een overzicht van de geselecteerde spelers voor het evenement.
5.  Steven selecteert Maurits, die gepland staan.
6.  Steven kiest voor verwijderen van de geselecteerde speler.
7.  Het systeem bevestigt de verwijderde speler(s).
8.  Het systeem vraagt om het toevoegen van nieuwe spelers.
9.  Steven kiest ervoor om Nico aan het evenement toe te voegen.
10. Het systeem bevestigt de toegevoegde spelers.
11. Steven sluit af.

Kostuums inplannen

1. Steven kiest in programma voor optie: Kostuums Inzien.
2. Het systeem geeft een overzicht van alle aanvragen.
3. Steven kiest de aanvraag van Park Sonsbeek.
4. Het systeem geeft een overzicht van de gereserveerde kostuums voor de aanvraag, per act en het totaal.
5. Het systeem vraagt of het overzicht moet worden uitgevoerd (mail, print, .doc, .pdf).
6. Steven selecteert email en .pdf.
7. Het systeem voert uit en sluit af.

Optie bevestigen

1. Steven kiest in programma voor optie: Optie Bevestigen
2. Het systeem geeft een overzicht van alle lopende opties.
3. Steven kiest uit het overzicht de optie van park Sonsbeek.
4. Het systeem laat de optie van het evenement zien, inclusief alle cruciale elementen.
5. Steven kiest voor bevestigen en vastleggen van de optie.
6. Het systeem bevestigt dat de optie geplaatst is.
7. Het systeem stuurt een e-mail naar alle betrokkenen bij het evenement.

Spelers beheren

1.  Steven kiest in programma voor optie: Speler Toevoegen.
2.  Het systeem vraagt wie er toegevoegd moet worden.
3.  Steven voert "Wouter de Vries" in.
4.  Het systeem vraagt in welke acts de toe te voegen speler betrokken is.
5.  Steven selecteert de alien en insectenact.
6.  Steven bevestigt de gebonden act(s).
7.  Het systeem vraagt aan welke kostuums de speler gebonden moet worden.
8.  Steven selecteert een insectenpak en een alienpak in maat L.
9.  Het systeem vraagt naar de volgende gegevens:
    (Volledige: NAW, geboortedatum, e-mailadres en telefoonnummer)
10. Steven vult in:
	21-10-1982, devries_wouter@example.net, 012-3456789.
11. Het systeem vraagt om de default beschikbaarheid van de speler.
12. Steven vult de default beschikbaarheid in van de speler.
13. Het systeem geeft aan dat een speler is toegevoegd.

1.  Steven kiest in programma voor optie: Speler Toevoegen.
2.  Het systeem vraagt wie er toegevoegd moet worden.
3.  Steven voert "Maurits de Jonge" in.
4.  Het systeem geeft aan dat de speler al bestaat.
5.  Het systeem vraagt of de bestaande speler moet worden aangepast.
6.  Steven geeft aan de speler te willen aanpassen.
7.  Het systeem geeft de aan te passen gegevens weer.
8.  Steven selecteert het emailadres.
9.  Het systeem geeft mogelijkheid tot aanpassen.
10. Steven voert in: "mauritsdejonge@example.net" en bevestigt.
11. Het systeem controleert en sluit af.

Kostuums beheren

1.  Steven kiest in programma voor optie: Kostuum Toevoegen.
2.  Het systeem vraagt aan welke act een kostuum wordt toegevoegd.
3.  Steven selecteert de alienact.
4.  Het systeem laat een overzicht van alle kostuums van de act zien.
5.  Steven kiest voor Toevoegen Kostuum.
6.  Het systeem vraagt om de volgende gegevens:
    	*Maatrichtlijn (S/M/L)
    	*Status van Kostuum (Goed/Slecht/Defect)
    	*Gebonden personen (Onbeperkt aantal geschikte mensen)
7.  Steven geeft de gegevens: 
	*Maatrichtlijn: L
	*status van kostuum: Goed
	*Gebonden personen: Maurits, Wouter, Miranda
8.  Het systeem vraagt of het kostuums gebonden moet zijn aan meerdere acts.
9.  Steven selecteert de alienact.
10. Het systeem bevestigt een nieuw toegevoegd kostuum.

1.  Steven kiest in programma voor optie: Kostuum Toevoegen.
2.  Het systeem vraagt aan welke act een kostuum wordt toegevoegd.
3.  Steven selecteert de alienact.
4.  Het systeem laat een overzicht van alle kostuums van de act zien.
5.  Steven kiest voor het maat L alienpak.
6.  Het systeem vraagt om de volgende gegevens:
    	*Maatrichtlijn (S/M/L)
    	*Status van Kostuum (Goed/Slecht/Defect)
    	*Gebonden personen (Onbeperkt aantal geschikte mensen)
7.  Steven geeft de gegevens: 
	*Maatrichtlijn: L
	*status van kostuum: Defect
	*Gebonden personen: Maurits, Wouter, Miranda
8.  Het systeem vraagt of het kostuums gebonden moet zijn aan meerdere acts.
9.  Steven selecteert de alienact.
10. Het systeem bevestigt een veranderd kostuum.

Beschikbaarheid bewerken

1. Steven kiest in programma voor optie: Beschikbaarheid Aanpassen
2. Het systeem vraagt voor welke speler de beschikbaarheid moet worden aangepast.
3. Steven voert in dat het om Annika gaat.
4. Het systeem geeft een overzicht van de huidige beschikbaarheid.
5. Steven geeft aan dat Annika de tweede week van maart 2013 niet beschikbaar is.
6. Het systeem keurt de aanpassing goed.
7. Steven sluit af of kiest nog een speler om te bewerken.

1. Nico logt in met een eigen account.
2. Het systeem toont een overzicht van de beschikbaarheid.
3. De speler geeft aan dat hij de komende vier weken nit op vrijdag beschikbaar is.
4. Het systeem keurt de aanpassing goed.
5. Speler sluit af.

1. Steven kiest in programma voor optie: Beschikbaarheid Aanpassen
2. Het systeem vraagt voor welke speler de beschikbaarheid moet worden aangepast.
3. Steven voert in dat het om Annika gaat.
4. Het systeem geeft een overzicht van de huidige beschikbaarheid.
5. Steven geeft aan dat Annika komkende vrijdag niet beschikbaar is.
6. Het systeem keurt de aanpassing af. 
7. Het systeem geeft aan dat de beschikbaarheid niet aangepast mag worden voor een al geplanned evenement in de komende 7 dagen.
8. Steven sluit af.

1. Nico logt in met een eigen account.
2. Het systeem toont een overzicht van de beschikbaarheid.
3. De speler geeft aan dat hij de komende vier weken niet op vrijdag beschikbaar is.
4. Het systeem keurt de aanpassing af.
5. Het systeem geeft aan dat hij zijn beschikbaarheid niet mag veranderen voor de komende vrijdag, omdat  dat over 3 dagen is.
6. Nico sluit af.

Non-functional Requirements

Hieronder zijn de non functional requirements opgesomd die worden verwacht bij het nieuwe systeem. Bij elke requirement is beknopt toegelicht waarom deze voor het nieuwe systeem van Close Act van toegevoegde waarde is.

Authorization:
Middels een gebruikersnaam en wachtwoord krijgt bevoegd personeel toegang tot het systeem.

Authentication:
Alleen medewerkers van Close Act en externe personen die hier voorafgaand permissie voor hebben gekregen, mogen toegang hebben tot het systeem. Voorts dient het systeem beperkte toegang te kunnen bieden aan de verschillende betrokken partijen. Denk hierbij aan de mogelijkheden om als speler het profiel van een medespeler te kunnen inzien.

Availability: Het is van belang dat het systeem zoveel mogelijk up and running is.
Het systeem dient een zeer beperkte down time period te kennen. Met name tijdens werktijden van Close Act dient het systeem zelden een down time te kennen.

Data integrity:
Persoonlijke profielinformatie mag niet gewijzigd kunnen worden door derden of verloren gaan.

Operability:
Voor de planners dient de mogelijkheid te bestaan om eventuele beperkingsregels in te stellen. Denk aan een act waarbij de planner zo spoedig mogelijk dient te weten wie er zeker beschikbaar is voor deelname. Zo kan de planner een deadline opgeven waarbinnen de spelers dienen te reageren.

Privacy:
De spelers dienen de mogelijkheid te hebben om verschillende onderdelen van hun profiel te kunnen verbergen. Dit zodat deze onderdelen bijvoorbeeld niet kunnen worden bekeken door medespelers. Echter, personeel die verantwoordelijk is voor het onderhouden van het systeem mag dit ook niet inzien. De planner dient relevante data uiteraard wel te kunnen zien.

Reliability:
Een gebrek aan betrouwbaarheid is één van de problemen van het voorgaande systeem geweest door foutgevoeligheid. Data kon door een fout verloren gaan. Dit moet in het vervolg niet meer mogelijk zijn doordat iedere veld wordt bewaard zodra het is bijgewerkt en de gebruiker het betreffende veld heeft verlaten.

Security:
Medewerkers kunnen verborgen gegevens niet benaderen. Dit dient dusdanig te worden beveiligd dat het kopiëren van een link naar de betreffende gegevens, niet resulteert in het inzien van die gegevens.

Addendum

Integrated Domainmodel

Business Rules Catalogue

No.	Rule definition	Type of Rule	Static/Dynamic
001	Een evenement kan maximaal 2 jaar van tevoren worden ingepland.	Action restricting	Static
002	Een evenement moet minimaal 1 week (7 kalenderdagen) van tevoren definitief worden.	Action restricting	Static
003	Wanneer een speler al is ingepland voor een definitief optreden, dient deze niet te worden ingepland bij een andere evenement met overlappende data (inclusief vervoer heen en terug).	Action triggering	Dynamic
004	Wanneer een kostuum al is ingepland voor een definitief optreden, dient deze niet te worden ingepland bij een andere evenement met overlappende data (inclusief vervoer heen en terug).	Action restricting	Dynamic
005	Wanneer er geen alternatieven zijn voor botsende evenementen (d.w.z. een speler is niet te vervangen door andere speler(s), zodanig dat er geen conflicten meer optreden), zal het management hierover beslissen.	Action restricting	Dynamic
006	Wanneer er geen alternatieven zijn voor botsende evenementen (d.w.z. een speler is niet te vervangen door andere speler(s), zodanig dat er geen conflicten meer optreden), zal het management hierover beslissen.	Action triggering	Dynamic
007	Wanneer een speler / kostuum al is ingepland voor een mogelijk optreden (dus nog niet definitief), dient deze niet te worden ingepland bij een ander evenement met overlappende data, tenzij dit niet anders kan (d.w.z. er zijn geen alternatieve spelers / kostuums inzetbaar voor dit evenement, of het botsende evenement / de botsende evenementen).	Action restricting	Dynamic
008	Een speler / kostuum kan alleen met toestemming van het management op een ander evenement worden ingepland als deze al voor een mogelijk optreden staat ingepland.	Structural facts	Static
009	Bij bevestiging van een aanvraag (stap 12 BCoE, stap 5 Alt Path: 'Aanvraag bewerken'), worden (wanneer mogelijk) de statussen van de spelers, kostuums en de agenda gewijzigd in een mogelijk evenement (let op, dit is nog géén optie!).	Action restricting	Dynamic
010	Spelers / ateliermedewerkers / kantoormedewerkers / klanten worden, bij élke wijziging dat direct op hun van invloed is, schriftelijk op de hoogte gesteld (mail is schriftelijk).	Structural facts	Static
011	Als er geen datum bekend is voor een evenement, terwijl de aanvraag wel is bevestigd, zullen de statussen pas worden veranderd bij invoering.	Structural facts	Static
012	Wanneer er geen locatie bekend is, zal het de agenda binnen Nederland 5 transportdagen rekenen, buiten Nederland 28 transportdagen, zowel voor heen- als terugreis.	Structural facts	Static
013	Een act hoeft niet per se een kostuum te bevatten en we spreken al van een act bij een optreden van één persoon.	Structural facts	Static
014	Als er meerdere kostuums beschikbaar zijn met verschillende maten, wordt de juiste maat pas geselecteerd op het moment dat de daarbij behorende speler wordt geselecteerd in de planning.	Action restricting	Dynamic
015	Als een kostuum tegelijkertijd door meerdere spelers moet worden gedragen, moeten de spelers dezelfde maten hebben als het kostuum. Alle combinaties van spelers moeten daarbij te selecteren zijn.	Action restricting	Static
016	Wijzigingen moeten te allen tijde kunnen worden teruggedraaid, de gegevens mogen nooit verloren gaan en er moet kunnen worden achterhaald wie wat heeft gewijzigd en wanneer.	Structural facts	Static
017	Een template 'speelinfo' bij een optie, haalt de standaard informatie (d.d., plaats, act etc.) uit de originele aanvraag. Als deze standaard informatie wordt gewijzigd (dit kan alleen na een extra handeling), moet er (door het systeem) worden nagegaan of er geen conflicten optreden.	Action restricting	Static
018	Een speler kan niet worden ingepland als hij of zij al op een andere optie is ingepland.	Action restricting	Static
019	Een speler kan niet worden ingepland als hij of zij niet geschikt is voor de specifieke act.	Action restricting	Static
020	Wanneer het minimum aantal spelers voor een act niet is bereikt, kan een aanvraag geen optie worden.	Action restricting	Static
021	Een kostuum kan niet ingepland worden als het defect is.	Action restricting	Static
022	Een kostuum kan niet ingepland worden als het al gepland staat op een ander evenement.	Action restricting	Static
023	Ieder definitief evenement heeft alle cruciale elementen van de planning geregeld.	Action restricting	Static
024	Spelers / ateliermedewerkers / kantoormedewerkers / klanten worden, bij élke wijziging dat direct op hun van invloed is, schriftelijk op de hoogte gesteld.	Structural facts	Dynamic
025	Iedere speler heeft als gegevens minimaal een naam.	Structural facts	Static
026	Het standaard aantal personen dat in één kostuum past is 1, tenzij anders aangegeven.	Structural facts	Static
027	Iedere speler kan zichzelf niet vrij gegeven voor een geplande opdracht	Structural facts	Static
028	Iedere speler kan zijn eigen beschikbaarheid niet veranderen voor een datum binnen x dagen/weken.	Action restricting	Dynamic
029	De prijs voor een offerte wordt gebaseerd op de lengte van de tijd waarop de specifieke spelers en kostuums weg zijn van huis, met daarnaast de prijs van de act (en eventueel de overige verwachte kosten voor vervoer en technici).	Structural facts	Dynamic

Terminological Definitions

Term:	Betekenis:
Speler	Persoon die acts speelt en ingepland kan worden
Medewerker	Elke persoon binnen de gehele organisatie van CloseAct
Kantoormedewerker	Medewerker die de administratie van CloseAct bijhoudt
Ateliermedewerker	Verzorger van al het materiaal van de organisatie (kostuums, toebehoren, etc.)
Kostuum	Kledingstuk van speler voor specifieke act
Offerte	Prijsopgave van evenement
Optie	Niet definitieve boeking van een evenement
Klant	Opdrachtgever van een evenement
Act	Deel van een evenement
Evenement	Voorstelling waarbinnen zich minimaal één act afspeelt
Beschikbaarheid	Vrij plekken binnen de agenda van CloseAct of in die van een Speler
Status	Informatie over de voltooiing van de voorbereiding van een evenement
Redundant	Overbodig / Overtollig
Contract	officieel document met afspraken waaraan betrokkenen zich dienen te houden
Data	Gegevens
Trigger	Uitlokken / doen starten van een gebeurtenis
Template	Een mal / Sjabloon
Archiveren	Volgens bepaalde regels opbergen in een archief
Geïntegreerd Systeem	Op een samenhangende manier opgezet geheel van computers en computerprogramma's zodat het geheel zo efficiënt en effectief mogelijk met elkaar kan samenwerken
Conflict	Toestand waarbij zaken niet met elkaar samengaan
Concepten	Nog niet definitief vastgelegde informatie
Overlap	De mate waarin twee zaken iets gezamenlijk bedekken
Element	Deel waaruit iets is opgebouwd
Default	Standaardwaarde
Inloggen	Je aanmelden (in dit geval in een digitale omgeving)
Account	Persoonlijke toegang tot een digitale omgeving
Gebruikersnaam	Reeks van letters, cijfers en tekens waarmee kan worden aangemeld
Wachtwoord	geheime reeks letters, cijfers en tekens dat na de gebruikersnaam moet worden ingetypt om toegang te krijgen
Toegang	Weg waarlangs men ergens kan komen
Extern (externe speler)	Een persoon van buiten de organisatie
Profiel	Beschrijving van eigenschappen (in het geval van CloseAct nodig voor o.a. plannen)
Up and running	Dat iets volgens plan functioneert
Downtime period	wachttijd doordat het systeem niet (naar behoren) functioneert
Deadline	Datum waarop iets gebeurd moet zijn
Origineel (originele aanvraag)	Oorspronkelijk(Oorspronkelijke aanvraag)

Bronnen

↑ De werkwijze zal verlopen middels richtlijnen van Daryl Kulak en Eamonn Guiney.
↑ ^2,0 ^2,1 ^2,2 ^2,3 ^2,4 ^2,5 ^2,6 ^2,7

[1] De werkwijze zal verlopen middels richtlijnen van Daryl Kulak en Eamonn Guiney.

[nr1-2] 2,0 ^2,1 ^2,2 ^2,3 ^2,4 ^2,5 ^2,6 ^2,7

[1]

[2]

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