Requirements Engineering/het werk/werkstuk/2010-11/Groep 03 REact

 

Close Act

Werkstuk Requirements Engineering

REact - Maarten Bovy, Joël Cox, Elmar Dongelmans, Ramon van Os, Joep Top

Onderwijsinstituut voor Informatica en Informatiekunde

Radboud Universiteit Nijmegen

---

version 18 februari 2022

---

Introduction

Het theatergezelschap Close Act voert voorstellingen en acts op over de hele wereld. Jammer genoeg gaat er af en toe nog wel eens wat mis qua planning. De huidige systemen zijn niet met elkaar geïntegreerd en dit maakt het moeilijk om klantenrelaties te onderhouden, spelers in te plannen en attributen over verschillende plekken op de wereld te verzenden. Daarnaast is het werken met dit systeem niet erg efficiënt, voornamelijk omdat er steeds gegevens van het ene systeem naar het andere systemen moet worden gekopieerd. In dit document stellen wij de requirements op voor één geïntegreerd systeem dat dit allemaal mogelijk moet maken.

Problem statement

De grootste problemen met het huidige systeem ontstaan bij het maken van de planningen. Omdat het huidige systeem geen mogelijkheid biedt om de planningen op elkaar af te stemmen, moet al dit werk met de hand gedaan worden. Hierdoor ontstaan onduidelijkheden. Naast de onduidelijkheden levert het handwerk ook meer werkuren op. Er wordt veel tijd verloren met het uittekenen van de uren met de hand. Eveneens is de kennis van spelers en kostuums gelimiteerd bereikbaar. Het is de bedoeling dat deze informatie in het systeem terug te vinden is, en te koppelen is aan de verschillende optredens.

Scope

We willen ons binnen dit project richten op het organiseren van een show. We verwerken de gegevens van de opdrachtgevers, spelers en de shows in ons ontwerp. Hierbij abstraheren wij van de informatie over kostuums. Puntsgewijs kijken we naar de volgende specifieke onderdelen:

• Het verzamelen van gegevens over de opdracht (locatie, datum, show enz.).
• Een overzicht voor de spelers in de vorm van een spelersplanner (read only voor de spelers). Kantoormedewerkers kunnen deze planner wijzigen.
• Historie van contactmomenten met opdrachtgever bijhouden.

Case analysis

Stakeholder analysis

De stakeholders, zoals bedoeld in dit project, zijn de mensen die direct betrokken zullen zijn met het te maken informatiesysteem. Klanten, partners en andere eventueel belanghebbenden van buiten Close Act zullen tijdens dit project niet als stakeholder worden aangemerkt.

User demography

Binnen Close Act zijn twee type stakeholders te onderscheiden:

Type	Beschrijving
Kantoormedewerkers	De mensen die op kantoor werken en zich bezighouden met de organisatie en planning van Close Act
Spelers en andere uitvoerende medewerkers	De acteurs, materiaalmensen en eventueel andere medewerkers die geen kantoormedewerker zijn.

De kantoormedewerkers zijn de stakeholders die het meest met het informatiesysteem zullen gaan werken. Zij zijn dan ook de belangrijkste groep stakeholders voor ons project. De kantoormedewerkers zullen alle gegevens invoeren in het systeem. Zij zullen zorgen voor de correctheid van de gegevens in het systeem, dat de gegevens op de juiste plaats komen te staan en het up-to-date houden van de gegevens.

De spelers en andere uitvoerende medewerkers zullen op basis van alleen-lezen toegang krijgen tot het systeem. Voor hen is het belangrijkste onderdeel van het systeem de spelersplanner met alle speeldata en gegevens. De spelers en andere uitvoerende medewerkers zullen geen wijzigingen in het systeem aanbrengen.

Stakeholder list

De kantoormedewerkers zijn: Hester, Tonnie, Vivian, Ida en Marja.

Alle spelers, materiaalmensen en andere uitvoerende medewerkers worden als groep gezien en zullen niet als individu genoemd worden.

Mission and vision statement

Mission

Het eindproduct bestaat uit de requirements voor een informatiesysteem, dat in het huidige, chaotische werkproces orde en overzichtelijkheid moeten brengen. Het werk dat op kantoor plaatsvindt is te complex geworden om op de huidige werkwijze voort te zetten. Alle informatie moet bij elkaar worden gebracht en geordend. Zo moet het voor de eindgebruikers eenvoudiger worden om gegevens over optredens terug te vinden en te verwerken.

Vision

Het eindproduct zullen de requirements zijn voor een informatiesysteem waarin alle gegevens, die nodig zijn voor het organiseren van optredens, op een gestructureerde manier zijn opgeslagen. Een databank die alle gegevens bevat die nu verspreid over het hele kantoor worden verzameld en bijgehouden.

Values

Wij hebben er als groep voor gekozen om de onderdelen die iedere iteratie bevat te verdelen onder de groepsleden. Iedereen heeft dus een stukje verantwoordelijkheid. Wel plannen we regelmatig bijeenkomsten om deze onderdelen te bespreken en elkaar op weg te helpen, aan te vullen of te verbeteren. Controle vanuit de groep is dus nadrukkelijk aanwezig.

Executive Sponsor Viewpoint

Wat is het probleem waar men op dit moment tegenaan loopt?

De kern van het het probleem zit hem in het feit dat bijna alle kantoorwerk handmatig wordt gedaan, met hulp van enkele los van elkaar staande gedigitaliseerde planningen en overzichten. Problemen die hierdoor ontstaan zijn onder andere:

- De kans op fouten in de planning is aanwezig. Het blijft immers mensenwerk.

- Het kost heel veel tijd om alle informatie overal terug te vinden

Waarom is een (nieuw) systeem nodig?

Het huidige systeem is in de loop der jaren te complex geworden. Wanneer men nu op een overzichtelijke manier alle data bij elkaar brengt, zal het werkproces in de toekomst veel eenvoudiger verlopen. Verder is het, ook kijkend naar de toekomst, goed om werkwijzen te standaardiseren. Nu is het bedrijf te afhankelijk van de domeinkennis van de kantoormedewerkers.

Waarom is een (nieuw) computersysteem nodig?

Een computersysteem kan een goede basis leggen voor de hierboven beschreven noodzakelijke veranderingen. Het grote voordeel van werken met een computersysteem is de mogelijkheid om alle data gestructureerd bij elkaar te brengen. Vervolgens kun je als gebruiker heel eenvoudig bepaalde specifieke informatie opvragen zonder daarvoor zélf te moeten zoeken. Het systeem doet dit voor je en wel zo dat je alleen de informatie krijgt die je ook daadwerkelijk nodig hebt.

Wie raken er betrokken bij het nieuwe systeem?

De zojuist gespecificeerde stakeholders, te weten: de kantoormedewerkers en de groep van spelers en ander uitvoerend personeel.

Statement of Work

Deadlines

• Facade iteratie: 1 april
• Filled iteratie: 13 mei
• Focused iteratie: 10 juni

Statussen

Code	Betekenis	Uitleg
V	Voltooid	Deliverable is nagekeken door minstens 1 teamlid en is klaar om ingeleverd te worden.
C	Controleren	Deliverable is gemaakt door de verantwoordelijk en dient te worden gecontroleerd/verbeterd door een groepslid.
B	Bezig	Deliverable is in de maak op de wiki.
NG	Niet gestart	Het maken van deze deliverable is nog niet (op de wiki) gestart.
NV	Niet vereist	Deliverable is (in deze iteratie) niet vereist.

Status deliverables

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

Risk analysis

#	Category	Risk	Solution needed by	Status	Days lost	Expectancy factor	Risk factor
01	Personeel	Ziekte van groepslid	-	-	2	1%	10
02	Informatie	Verkeerde interpretatie van gekregen informatie	-	-	3	20%	80
03	Informatie	Niet alle benodigde informatie in het systeem verwerkt	-	-	3	35%	70
04	Informatie	Informatie over spelers die nu in het hoofd van de kantoormedewerkers zit wordt door ons verkeerd geformuleerd	-	-	4	10%	80

Requirements

Use cases

Use case survey

#	Name	Description	Initiating actor
01	Nieuwe opdracht toevoegen	Gegevens van een nieuwe opdracht invoeren	Kantoormedewerkers
02	Opdracht inzien/wijzigen	Informatie over bestaande opdrachten inzien/toevoegen/verwijderen	Kantoormedewerkers
03	Spelersplanner inzien	Het bekijken van de spelersplanner	Spelers
04	Spelers plannen	De kantoormedewerker planned een speler in voor een specifieke performance.	Kantoormedewerkers
05	Nieuwe medewerker toevoegen	Medewerkergegevens toevoegen	Kantoormedewerkers
06	Contacthistorie inzien/wijzigen	Het inzien/wijzigen van de contacthistorie per opdrachtgever	Kantoormedewerkers
07	Mogelijke performances inzien/wijzigen	Het inzien van bestaande performances en/of het samenstellen van een performance.	Kantoormedewerkers
08	Medewerkergegevens inzien/wijzigen	De lijst met alle medewerkers inzien en informatie per medewerker kunnen bekijken	Kantoormedewerkers

Integrated use case diagram

Individual use cases

Nieuwe opdracht toevoegen

Create a Use Case for all of the ones identified in the survey, include relevant business rule(s) and a Use case Diagram.

Use Case:	01 Nieuwe opdracht toevoegen
Use case diagram
Domain Model
Description	Gegevens van een nieuwe opdracht invoeren
Actor	Kantoormedewerker
Preconditions	-
Postconditions	Er is een nieuwe opdracht toegevoegd.
Trigger	Kantoormedewerker geeft aan systeem aan dat hij nieuwe opdracht wilt toevoegen.
Basic course of events	1. Systeem vraagt om show. (ga naar Use Case 07, stap 2). 2. Systeem vraagt of de kantoormedewerker de opdracht nu in wil plannen. 3. Kantoormedewerker kiest ervoor om de opdracht in te plannen. 4. Systeem toont agenda en geeft hierin aan wanneer het mogelijk is om de opdracht in te plannen. 5. Kantoormedewerker kiest datum en bevestigt. 6. Systeem toont overzicht van de opdracht. 7. Kantoormedewerker sluit af.
Alternate paths	3.1 Kantoormedewerker kiest ervoor om de opdracht niet in te plannen. Hier eindigt de Use Case. 5.1 Kantoormedewerker annuleert. Terug naar stap 3.
Related business rules	#9

Opdracht inzien/wijzigen

Use Case:	02 Opdracht inzien/wijzigen
Use case diagram
Domain Model
Description	Opdrachtgegevens inzien/toevoegen/verwijderen
Actor	Kantoormedewerker
Preconditions	-
Postconditions	Opdrachtgegevens zijn gewijzigd/ ingezien.
Trigger	Kantoormedewerker navigeert naar overzicht van opdrachten. Kantoormedewerker selecteert opdracht uit agenda, begin met stap 3.
Basic course of events	1. Systeem toont overzicht van opdrachten. 2. Kantoormedewerker kiest opdracht. 3. Systeem toont opdrachtgegevens. 4. Kantoormedewerker past gegevens aan en bevestigt. 5. Systeem toont opdrachtgevens. 6. Kantoormedewerker sluit opdrachtgegevens af. 7. Systeem toont overzicht van opdrachten. 8. Kantoormedewerker sluit opdrachtoverzicht af.
Alternate paths	4.1 Kantoormedewerker heeft gegevens ingezien, maar past ze niet aan. Ga naar stap 6. 8.1 Kantoormedewerker kiest opdracht. Ga naar stap 3.
Related business rules	-

Spelersplanner inzien

Use Case:	03 Spelersplanner inzien
Use case diagram
Domain Model
Description	Het bekijken van de spelersplanner.
Actor	Speler
Preconditions	Planning gemaakt door kantoormedewerker
Postconditions	Speler heeft de planning ingezien en weet wanneer hij moet optreden
Trigger	Speler navigeert naar spelersplanner
Basic course of events	1. Systeem toont spelersplanner. 2. Speler sluit spelersplanner af.
Alternate paths	-
Related business rules	#10

Spelers plannen

Use Case:	04 Spelers plannen
Use case diagram
Domain Model
Description	De kantoormedewerker planned een speler in voor een specifieke performance.
Actor	Kantoormedewerker
Preconditions	Er is minstens een opdracht.
Postconditions	Planning gemaakt door kantoormedewerker
Trigger	Kantoormedewerker navigeert naar spelersplanner
Basic course of events	1. Systeem toont spelersplanner. 2. Kantoormedewerker geeft aan een speler in te willen plannen. 3. Systeem vraagt om welke specifieke performance het gaat. 4. Kantoormedewerker geeft aan om welke specifieke performance het gaat. 5. Systeem toont overzicht van spelers en vraagt welke speler ingeplanned moet worden. 6. Kantoormedewerker geeft aan om welke speler het gaat en bevestigt. 7. Systeem toont de spelersplanner met nieuwe gegevens. 8. Kantoormedewerker sluit spelersplanner af.
Alternate paths	4.1 Kantoormedewerker annuleert. Einde use case. 6.1 Kantoormedewerker annuleert. Einde use case.
Related business rules	#2 #5

Nieuwe medewerker toevoegen

Use Case:	05 Nieuwe medewerker toevoegen
Use case diagram
Domain Model
Description	Medewerkergegevens toevoegen.
Actor	Kantoormedewerker
Preconditions	-
Postconditions	Speler/kantoormedewerker is toegevoegd aan het systeem.
Trigger	Kantoormedewerker navigeert naar locatie waar een nieuwe medewerker kan worden toegevoegd aan het systeem.
Basic course of events	1. Kantoormedewerker geeft aan een nieuwe medewerker te willen toevoegen. 2. Systeem vraagt om functie(kantoormedewerker/speler). 3. Kantoormedewerker vult in: "kantoormedewerker". 4. Systeem vraagt om persoonsgegevens(voornaam, achternaam, geboortedatum, e-mailadres, adres, telefoonnummer). 5. Kantoormedewerker vult persoonsgegevens in en bevestigt. 6. Systeem geeft aan dat de persoongegevens zijn toegevoegd. 7. Kantoormedewerker stuurt een bevestigingmail naar nieuwe medewerker en sluit af.
Alternate paths	3.1. Kantoormedewerker vult in: "speler".
Related business rules	#5

Contacthistorie inzien/wijzigen

Use Case:	06 Contacthistorie inzien/wijzigen
Use case diagram
Domain Model
Description	Het wijzigen van de contacthistorie per opdrachtgever.
Actor	Kantoormedewerker
Preconditions	-
Postconditions	Contacthistorie is aangepast
Trigger	Kantoormedewerker navigeert naar het overzichtsscherm van de opdrachtgever.
Basic course of events	1. Systeem toont overzichtsscherm van de opdrachtgever. 2. Kantoormedewerker geeft aan dat hij de contacthistorie wil aanpassen. 3. Systeem geeft invoerveld weer. 4. Kantoormedewerker voert nieuwe contacthistorie in en bevestigt. 5. Systeem geeft het overzichtsscherm van de opdrachtgever weer (met de nieuwe contacthistorie). 6. Kantoormedewerker sluit systeem af.
Alternate paths	2.1 Kantoormedewerker heeft de contacthistorie bekeken. Hier eindigt de use case. 4.1 Kantoormedewerker wijzigt eerder ingevoerde contacthistorie en bevestigt.
Related business rules	#6

Mogelijke performances inzien/wijzigen

Use Case:	07 Mogelijke performances inzien/wijzigen
Use case diagram
Domain Model
Description	Het inzien van bestaande performances en/of het samenstellen van een performance.
Actor	Kantoormedewerker
Preconditions	-
Postconditions	performance is ingezien. performance is aangepast. performance is aangemaakt.
Trigger	Kantoormedewerker navigeert naar overzicht van performances.
Basic course of events	1. Systeem toont overzicht van performances. 2. Kantoormedewerker geeft aan welke performance hij wil inzien. 3. Systeem geeft overzicht van performance weer. 4. Kantoormedewerker sluit overzicht af.
Alternate paths	2.1.1. Kantoormedewerker geeft aan welke performance hij wil aanpassen. 2.1.2. Systeem geeft overzicht van performance weer. 2.1.3. Kantoormedewerker past performance aan en bevestigt. 2.1.3.1. Kantoormedewerker annuleert. 2.2.1. Kantoormedewerker geeft aan dat hij een performance wil aanmaken. 2.2.2. Systeem vraagt om performancegegevens. 2.2.3. Kantoormedewerker voert gegevens in en bevestigt. 2.2.3.1. Kantoormedewerker annuleert. 2.3.1. Kantoormedewerker geeft aan dat hij een bestaande performance wil aanpassen voor een specifieke opdracht. 2.3.2. Systeem geeft overzicht van performance weer. 2.3.3. Kantoormedewerker past performance aan, koppelt de specifieke performance aan een opdracht en bevestigt. 2.3.3.1. Kantoormedewerker annuleert.
Related business rules	#2 #7 #8

Medewerkergegevens inzien/wijzigen

Use Case:	08 Medewerkergegevens inzien/wijzigen
Use case diagram
Domain Model
Description	De lijst met alle medewerkers inzien/wijzigen en informatie per medewerker kunnen bekijken/wijzigen.
Actor	Kantoormedewerker
Preconditions	Er moeten medewerkers ingevoerd zijn in het systeem als er iets gewijzigd moet worden.
Postconditions	Kantoormedewerker heeft gegevens over medewerkers bekeken/gewijzigd.
Trigger	Kantoormedewerker navigeert naar overzicht van alle medewerkers.
Basic course of events	1. Systeem toont overzicht van medewerkers. 2. Kantoormedewerker kiest medewerker die hij wil aanpassen. 3. Systeem toont gegevens van de geselecteerde medewerker. 4. Kantoormedewerker past gegevens van medewerker aan en bevestigt. 5. Systeem toont bijgewerkte gegevens van medewerker. 6. Kantoormedewerker sluit overzicht af.
Alternate paths	4.1 Kantoormedewerker heeft de gegevens van de medewerker ingezien. Hier eindigt de use case.
Related business rules	#5

Use case tests

Opdrachtgever geeft een datum aan de kantoormedewerker, waarna het systeem de beschikbare shows weergeeft (aan de hand van beschikbare kostuums e.d.).

De opdrachtgever kan ook een show opgeven, waarna beschikbare data weergegeven worden. Dit geeft de eerste indicatie van eventuele data/shows.

Er moet tot slot gecontroleerd worden of de spelers beschikbaar zijn

Scenarios

Individual scenarios

Scenario: Nieuw Opdracht Toevoegen

Use Case: 01 Nieuwe opdracht toevoegen

Henry navigeert naar: Nieuw Opdracht Het systeem vraagt Henry om een show te kiezen en geeft de keuzemogelijkheden: Malaya, Pi Leau, Xo Henry kiest voor Pi Leau Het systeem vraagt of Henry de opdracht nu wilt inplannen in de agenda Henry geeft aan de opdracht nu in de agenda te willen zetten Het systeem opent de agenda en toont data waarop deze opdracht ingepland kan worden Henry kiest voor 15 mei 2012 en bevestigd deze datum Het systeem geeft een overzicht: Opdracht datum: 15 mei 2012 Opdrachtgever: DansValleiBV Contactpersoon: Beau ter Ham Telefoon: 077 - 1234567 E-mail: BeauterHam@gmail.nl Voorstelling: Pi Leau Henry sluit het overzicht af

Use Case: 01 Nieuwe opdracht toevoegen (Alternative path 1)

Henry navigeert naar: Nieuw Opdracht Het systeem vraagt Henry om een show te kiezen en geeft de keuzemogelijkheden: Malaya, Pi Leau, Xo Henry kiest voor Pi Leau Het systeem vraagt of Henry de opdracht nu wilt inplannen in de agenda Henry geeft aan de opdracht nu niet in de agenda te willen zetten Het systeem geeft een overzicht: Opdracht datum: - Opdrachtgever: DansValleiBV Contactpersoon: Beau ter Ham Telefoon: 077 - 1234567 E-mail: BeauterHam@gmail.nl Voorstelling: Pi Leau Henry sluit het overzicht af

Use Case: 01 Nieuwe opdracht toevoegen (Alternative path 2)

Henry navigeert naar: Nieuw Opdracht Het systeem vraagt Henry om een show te kiezen en geeft de keuzemogelijkheden: Malaya, Pi Leau, Xo Henry kiest voor Pi Leau Het systeem vraagt of Henry de opdracht nu wilt inplannen in de agenda Henry geeft aan de opdracht nu in de agenda te willen zetten Het systeem opent de agenda en toont data waarop deze opdracht ingepland kan worden Henry kiest voor 15 mei 2012. Henry realiseert zich dat hij een foutieve datum heeft ingevoerd en annuleert de invoer. Het systeem vraagt of Henry de opdracht nu wilt inplannen in de agenda Henry geeft aan de opdracht nu in de agenda te willen zetten Het systeem opent de agenda en toont data waarop deze opdracht ingepland kan worden Henry kiest voor 18 mei 2012 en bevestigd deze datum Het systeem geeft een overzicht: Opdracht datum: 18 mei 2012 Opdrachtgever: DansValleiBV Contactpersoon: Beau ter Ham Telefoon: 077 - 1234567 E-mail: BeauterHam@gmail.nl Voorstelling: Pi Leau Henry sluit het overzicht af

Scenario: Opdracht Wijzigen/Inzien

Use Case: 02 Opdracht wijzigen/inzien

Henry navigeert naar het overzicht van de opdrachten Het systeem toont een lijst met opdrachten en bijbehorende data: 1 april 2012 - Malaya 5 april 2012 - Pi Leau 5 juni 2012 - Malaya 19 juni 2012 - Pi Leau 16 augustus 2012 - Xo Henry kiest de opdracht Pi Leau op 19-06-2012 Het systeem toont: Opdracht: 19 juni 2012 Opdrachtgever: DansValleiBV Contactpersoon: Beau ter Ham Telefoon: 077 - 1234567 E-mail: BeauterHam@gmail.nl Henry wijzigt de opdrachtdatum naar 21 juni 2012 en slaat deze wijziging op Het systeem toont: Opdracht: 21 juni 2012 Opdrachtgever: DansValleiBV Contactpersoon: Beau ter Ham Telefoon: 077 - 1234567 E-mail: BeauterHam@gmail.nl Henry sluit het overzicht van 21 juni 2012 Het systeem toont een lijst met opdrachten en bijbehorende data: 1 april 2012 - Malaya 5 april 2012 - Pi Leau 5 juni 2012 - Malaya 21 juni 2012 - Pi Leau 16 augustus 2012 - Xo Henry sluit het opdracht overzicht af

Use Case: 02 Opdracht wijzigen/inzien (Alternative path 1)

Henry navigeert naar het overzicht van de opdrachten Het systeem toont een lijst met opdrachten en bijbehorende data: 1 april 2012 - Malaya 5 april 2012 - Pi Leau 5 juni 2012 - Malaya 19 juni 2012 - Pi Leau 16 augustus 2012 - Xo Henry kiest de opdracht Pi Leau op 19-06-2012 Het systeem toont: Opdracht: 19 juni 2012 Opdrachtgever: DansValleiBV Contactpersoon: Beau ter Ham Telefoon: 077 - 1234567 E-mail: BeauterHam@gmail.nl Henry bekijkt de gegevens Henry sluit het overzicht van 19 juni 2012 Het systeem toont een lijst met opdrachten en bijbehorende data: 1 april 2012 - Malaya 5 april 2012 - Pi Leau 5 juni 2012 - Malaya 21 juni 2012 - Pi Leau 16 augustus 2012 - Xo Henry sluit het opdracht overzicht af

Use Case: 02 Opdracht wijzigen/inzien (Alternative path 2)

Henry navigeert naar het overzicht van de opdrachten Het systeem toont een lijst met opdrachten en bijbehorende data: 1 april 2012 - Malaya 5 april 2012 - Pi Leau 5 juni 2012 - Malaya 19 juni 2012 - Pi Leau 16 augustus 2012 - Xo Henry kiest de opdracht Pi Leau op 19-06-2012 Het systeem toont: Opdracht: 19 juni 2012 Opdrachtgever: DansValleiBV Contactpersoon: Beau ter Ham Telefoon: 077 - 1234567 E-mail: BeauterHam@gmail.nl Henry wijzigt de opdrachtdatum naar 21 juni 2012 en slaat deze wijziging op Het systeem toont: Opdracht: 21 juni 2012 Opdrachtgever: DansValleiBV Contactpersoon: Beau ter Ham Telefoon: 077 - 1234567 E-mail: BeauterHam@gmail.nl Henry sluit het overzicht van deze opdracht Het systeem geeft het overzicht van alle opdrachten weer 1 april 2012 - Malaya 5 april 2012 - Pi Leau 5 juni 2012 - Malaya 21 juni 2012 - Pi Leau 16 augustus 2012 - Xo Henry kiest de opdracht op 16-08-2012 Het systeem toont: Opdracht: 16 augustus 2012 Opdrachtgever: BeweegMaarBV Contactpersoon: Stanley Mes Telefoon: 077 - 0123456 E-mail: Stanley_Mes@gmail.nl Henry bekijkt de gegevens Henry sluit het overzicht van 16 augustus 2012 Het systeem toont een lijst met opdrachten en bijbehorende data: 1 april 2012 - Malaya 5 april 2012 - Pi Leau 5 juni 2012 - Malaya 21 juni 2012 - Pi Leau 16 augustus 2012 - Xo Henry kiest 5 april Het systeem toont: Opdracht: 5 april 2012 Opdrachtgever: DansValleiBV Contactpersoon: Beau ter Ham Telefoon: 077 - 1234567 E-mail: BeauterHam@gmail.nl Henry bekijkt de gegevens Henry sluit opdracht overzicht af Het systeem toont een lijst met opdrachten en bijbehorende data: 1 april 2012 - Malaya 5 april 2012 - Pi Leau 5 juni 2012 - Malaya 21 juni 2012 - Pi Leau 16 augustus 2012 - Xo Henry sluit de lijst met opdrachten

Scenario: Spelersplanner Inzien

Use Case: 03 Spelersplanner inzien
Niels opent de Spelersplanner Het systeem toont de spelersagenda: Speler Datum Niels 15-05-2012 Mary 18-06-2012 Bram 19-06-2012 Suzy 01-08-2012 Niels sluit de spelersagenda

Scenario: Spelers Plannen

Use Case: 04 Spelers plannen

Henry navigeert naar: Spelersplanner Het systeem toont de spelers agenda met ingeplande uren Henry geeft aan een speler in te willen plannen Het systeem om welke specifieke performance het gaat: Xo 21 juni 2012 25 augustus 2012 13 oktober 2012 Pi Leau 16 juli 2012 8 augustus 2012 1 september 2012 Malaya 6 april 2012 16 mei 2012 4 juli 2012 Henry kiest voor Malaya op 6 april 2012 Het systeem geeft een overzicht van de spelers die mee kunnen spelen aan Malaya op 6 april 2012 Niels Marieke Pjetr Andrey Nienke Petra Henry kiest Niels Het systeem toont de spelers agenda van 6 april met bijbehorende details Niels Imke Jennifer Pjótr Sam  !Deze voorstelling heeft nog 3 spelers nodig! Henry sluit de spelersplanner

Use Case: 04 Spelers plannen (Alternative Path 1)
Henry navigeert naar: Spelersplanner Het systeem toont de spelers agenda met ingeplande uren Henry geeft aan een speler in te willen plannen Het systeem om welke specifieke performance het gaat: Xo 21 juni 2012 25 augustus 2012 13 oktober 2012 Pi Leau 16 juli 2012 8 augustus 2012 1 september 2012 Malaya 6 april 2012 16 mei 2012 4 juli 2012 Henry annuleert de bezigheid en sluit de spelersplanner

Use Case: 04 Spelers plannen (Alternative Path 2)

Henry navigeert naar: Spelersplanner Het systeem toont de spelers agenda met ingeplande uren Henry geeft aan een speler in te willen plannen Het systeem om welke specifieke performance het gaat: Xo 21 juni 2012 25 augustus 2012 13 oktober 2012 Pi Leau 16 juli 2012 8 augustus 2012 1 september 2012 Malaya 6 april 2012 16 mei 2012 4 juli 2012 Henry kiest voor Malaya op 6 april 2012 Het systeem geeft een overzicht van de spelers die mee kunnen spelen aan Malaya op 6 april 2012 Niels Marieke Pjetr Andrey Nienke Petra Henry annuleert zijn bezigheid en sluit de spelersplanner

Scenario: Nieuw Medewerker Toevoegen

Use Case: 05 Nieuwe medewerker toevoegen

Henry navigeert naar: Nieuwe Medewerker Het systeem vraagt naar de functie van de nieuwe medewerker Henry vult in: Kantoormedewerker en bevestigt Het systeem vraagt naar de persoonsgegevens van de nieuwe kantoormederwerker Henry voert in (en bevestigt): Daan Jans 23-08-1989 Daan_Jans@hotmail.com Droomstraat 234 06-12345678 Het systeem stuurt een bevestiging naar Daan_Jans@hotmail.com met daarbij de geheimhoudingsverklaring Henry sluit het systeem af

Use Case: 05 Nieuwe medewerker toevoegen (Alternative Path 1)

Henry navigeert naar: Nieuwe Medewerker Het systeem vraagt naar de functie van de nieuwe medewerker Henry vult in: Speler en bevestigt Het systeem vraagt naar de persoonsgegevens van de nieuwe speler Henry voert in (en bevestigt): Anna Nas Vrouw 1.63 meter 16-02-1976 Anna_Nas_Sap@live.com Fruitlaan 16 06-02345679 Het systeem stuurt een bevestiging naar Anna_Nas_Sap@live.com Henry sluit het systeem af

Scenario: Contacthistorie Aanpassen

Use Case: 06 Contacthistorie aanpassen

Henry navigeert naar: Opdrachtgevers Het systeem geeft een overzichtslijst van de opdrachtgevers en vraagt naar de naam van de opdrachtgever die gezocht wordt DansValleiBV BeweegMaarBV SpraakWatervalBV Henry geeft aan de contacthistorie van DansValleiBV te willen zien Het systeem toont alle voorafgaande contacten met DansValleiBV Henry voegt het laatste contact toe aan het systeem en bevestigd: 21-05-2011 \ Getelefoneerd met H. Mens. Opdracht 17-01-2012 bevestigd (Malaya). Het systeem toont een overzicht met alle contactmomenten van DansValleiBV 16 mei 2011 \ Getelefoneerd met H. Mens over een opdracht op 17-01-2012 19 mei 2011 \ Getelefoneerd met H. Mens over de mogelijkheden op 17-01-2012. Malaya aangeraden. 22 mei 2011 \ Getelefoneerd met H. Mens. Opdracht 17-01-2012 bevestigd (Malaya). Henry sluit het systeem af

Use Case: 06 Contacthistorie aanpassen (Alternative Path 1)

Henry navigeert naar: Opdrachtgevers Het systeem geeft een overzichtslijst van de opdrachtgevers en vraagt naar de naam van de opdrachtgever die gezocht wordt DansValleiBV BeweegMaarBV SpraakWatervalBV Henry geeft aan de contacthistorie van DansValleiBV te willen zien Het systeem toont alle voorafgaande contacten met DansValleiBV Henry bekijkt de contacthistorie met DansValleiBV en sluit het systeem af

Use Case: 06 Contacthistorie aanpassen (Alternative Path 2)

Henry navigeert naar: Opdrachtgevers Het systeem geeft een overzichtslijst van de opdrachtgevers en vraagt naar de naam van de opdrachtgever die gezocht wordt DansValleiBV BeweegMaarBV SpraakWatervalBV Henry geeft aan de contacthistorie van DansValleiBV te willen zien Het systeem toont alle voorafgaande contacten met DansValleiBV Henry kiest het laatste contactmoment met DansValleiBV van 16 mei 2011 Getelefoneerd met H. Mens over een opdracht op 17-01-2012 Henry voegt de voorstelling toe aan het contactmoment Getelefoneerd met H. Mens over de voorstelling Xo op 17-01-2012 Henry bevestigd de wijziging Het systeem toont een overzicht van de contacthistorie met DansValleiBV 16 mei 2011 \ Getelefoneerd met H. Mens over de voorstelling Xo op 17-01-2012 (gewijzigd op 17 mei 2011 om 14.24) 19 mei 2011 \ Getelefoneerd met H. Mens over de mogelijkheden op 17-01-2012. Malaya aangeraden. 22 mei 2011 \ Getelefoneerd met H. Mens. Opdracht 17-01-2012 bevestigd (Malaya). Henry sluit het systeem af

Scenario: Mogelijk Performances Inzien/Aanpassen

Use Case: 07 Mogelijke performances inzien/aanpassen
Henry navigeert naar: Performances Het systeem toont een overzicht van de performances: Malaya Pi Leau Xo Henry kiest voor Malaya Het systeem geeft de performancedetails Malaya Spektakel voorstelling 60 min Schemer of later Tussen het publiek 32 medewerkers 22 spelers 10 crewleden 8 uur opbouwtijd 2,5 uur afbreektijd Licht/geluid door Close Act ... Henry sluit het systeem

Use Case: 07 Mogelijke performances inzien/aanpassen (Alternative Path 1)

Henry navigeert naar: Performances Het systeem toont een overzicht van de performances: Malaya Pi Leau Xo Henry kiest voor Malaya Het systeem geeft de performancedetails Malaya Spektakel voorstelling 60 min Schemer of later Tussen het publiek 32 medewerkers 22 spelers 10 crewleden 8 uur opbouwtijd 2,5 uur afbreektijd Licht/geluid door Close Act ... Henry geeft aan de performance te willen aanpassen Het systeem geeft het aanpasvenster weer Henry wijzigt de naam van Malaya naar MalaXo, veranderd de volgende onderdelen en bevestigd 140 min 45 medewerkers 32 spelers 12 crewleden 10 uur opbouwtijd 4 uur afbreektijd Het systeem geeft een overzicht van de performance MalaXo weer: MalaXo Spektakel voorstelling 140 min Schemer of later Tussen het publiek 45 medewerkers 32 spelers 12 crewleden 10 uur opbouwtijd 4 uur afbreektijd Licht/geluid door Close Act Henry sluit het systeem af

Use Case: 07 Mogelijke performances inzien/aanpassen (Alternative Path 2)

Henry navigeert naar: Performances Het systeem toont een overzicht van de performances: Malaya Pi Leau Xo Henry kiest voor Malaya Het systeem geeft de performancedetails Malaya Spektakel voorstelling 60 min Schemer of later Tussen het publiek 32 medewerkers 22 spelers 10 crewleden 8 uur opbouwtijd 2,5 uur afbreektijd Licht/geluid door Close Act ... Henry geeft aan de performance te willen aanpassen Het systeem geeft het aanpasvenster weer Henry wijzigt de naam van Malaya naar MalaXo en veranderd de volgende onderdelen 140 min 45 medewerkers 32 spelers 12 crewleden 10 uur opbouwtijd 4 uur afbreektijd Het systeem geeft een overzicht van de performance MalaXo weer: MalaXo Spektakel voorstelling 140 min Schemer of later Tussen het publiek 45 medewerkers 32 spelers 12 crewleden 10 uur opbouwtijd 4 uur afbreektijd Licht/geluid door Close Act Henry annuleert zijn wijzigingen en sluit het systeem af

Use Case: 07 Mogelijke performances inzien/aanpassen (Alternative Path 3)

Henry navigeert naar: Performances Het systeem toont een overzicht van de performances: Malaya Pi Leau Xo Henry geeft aan een nieuwe performance te willen toevoegen Het systeem vraagt naar de performancedetails W2P Spektakel voorstelling 120 min Ochtend Tussen het publiek 16 medewerkers 10 spelers 6 crewleden 3 uur opbouwtijd 2 uur afbreektijd Licht/geluid door Close Act ... Henry bevestigd de performance details Het systeem geeft een overzicht van de ingevoerde performance W2P Spektakel voorstelling 120 Ochtend Tussen het publiek 16 medewerkers 10 spelers 6 crewleden 3 uur opbouwtijd 2 uur afbreektijd Licht/geluid door Close Act Henry geeft aan een performance te willen veranderen voor een specifieke opdracht Het systeem geeft een overzicht van de bestaande performances Henry kiest voor W2P Het systeem geeft de performance details van W2P in een overzicht weer W2P Spektakel voorstelling 120 min Ochtend Tussen het publiek 16 medewerkers 10 spelers 6 crewleden 3 uur opbouwtijd 2 uur afbreektijd Licht/geluid door Close Act Henry wijzigt de performance en koppelt deze aan de opdracht voor DansValleiBV op 06-06-2012 W2P Spektakel voorstelling 80 min Middag Tussen het publiek 16 medewerkers 10 spelers 6 crewleden 2 uur opbouwtijd 1,5 uur afbreektijd Geluid door Close Act Licht door DansValleiBV Het systeem geeft een overzicht van de performance voor DansVallei op 06-06-2012 W2P Spektakel voorstelling 80 min Middag Tussen het publiek 16 medewerkers 10 spelers 6 crewleden 2 uur opbouwtijd 1,5 uur afbreektijd Geluid door Close Act Licht door DansValleiBV Henry sluit het systeem af

Scenario: Medewerkersgegevens Inzien/Wijzigen

Use Case: 08 Medewerkersgegevens inzien/wijzigen

Henry navigeert naar: Spelersoverzicht Het systeem toont een overzicht van de huidige spelers: Niels Mary Suzy Bram Henry kiest Suzy Het systeem geeft de gegevens van Suzy weer Naam: Suzy Leeftijd: 34 Woonplaats: America Lengte: 1.68 meter Mogelijk speelbare data: - Henry geeft aan dat Suzy kan spelen van 16 juni 2011 - 28 aug 2011 en bevestigd Het systeem geeft de gegevens van Suzy weer Naam: Suzy Leeftijd: 34 Woonplaats: America Lengte: 1.68 meter Mogelijk speelbare data: 16 juni 2011 - 28 aug 2011 Henry sluit het systeem af

Use Case: 08 Medewerkersgegevens inzien/wijzigen (Alternative Path 1)

Henry navigeert naar: Spelersoverzicht Het systeem toont een overzicht van de huidige spelers: Niels Mary Suzy Bram Henry kiest Suzy Het systeem geeft de gegevens van Suzy weer Naam: Suzy Leeftijd: 34 Woonplaats: America Lengte: 1.68 meter Mogelijk speelbare data: - Henry geeft aan dat Suzy kan spelen van 16 juni 2011 - 28 aug 2011 Het systeem geeft de gegevens van Suzy weer Naam: Suzy Leeftijd: 34 Woonplaats: America Lengte: 1.68 meter Mogelijk speelbare data: 16 juni 2011 - 28 aug 2011 Henry annuleert zijn wijzigingen en sluit het systeem af

Integrated Domainmodel

Non-functional Requirements

Beschikbaarheid

Omdat het voorgestelde systeem de kritieke processen van het bedrijf begeleid, is het van belang dat het systeem een hoge beschikbaarheid kent. Eventueel onderhoud aan het systeem moet dan ook buiten kantooruren (of rustige perioden) gebeuren.

Bruikbaarheid

De processen die geautomatiseerd worden zijn erg rijk aan informatie. In het nieuwe systeem moet al deze informatie overzichtelijk te bekijken zijn. De hoeveelheid informatie op één scherm moet dus beperkt zijn. Daarnaast moet het mogelijk zijn om informatie te filteren op bepaalde attributen en over een zoekfunctie beschikken. Op die manier kan specifieke data snel worden terug gevonden.

Integriteit

De data binnen het systeem moet ten alle tijden integer zijn, om zo planningsproblemen te voorkomen. Niet-integere informatie mag nooit worden opgeslagen en de gebruiker moet geïnformeerd worden wanneer zij tegenstrijdige informatie probeert op te slaan.

Veiligheid

De toegang tot het systeem moet beperkt worden tot werknemers van Close Act en eventuele externe personen die voorafgaand permissie hebben gekregen. Ook moet de systeem er voor zorgen dat bepaalde groepen stakeholders beperkte toegangsrechten hebben. Zoals de spelers die alleen de spelersplanner kunnen inzien.

Addendum

Business Rules Catalogue

Business Rules Catalogue

Nr.	Regel definitie
1	Een performance kan alleen gegeven worden wanneer alle rollen door de correcte spelers vervuld zijn.
2	Een performance kan alleen ingepland worden wanneer alle benodigdheden en spelers genoeg tijd hebben om naar de locatie af te reizen.
3	Lunch en parkeergelegenheid worden door opdrachtgever verzorgd.
4	Iedere opdrachtgever is bereikbaar via e-mail én telefoon.
5	Iedere medewerker is bereikbaar via e-mail én telefoon.
6	Van ieder contactmoment wordt het besprokene gedocumenteerd in het systeem.
7	Performances kunnen worden aangepast naar gelang de wensen en eisen van de opdrachtgever.
8	Alle performances zijn onderhevig aan de algemene voorwaarden van Close Act.
9	Een opdracht mag alleen aangenomen worden als de opdrachtgever betrouwbaar is bevonden door de kantoormedewerker.
10	Spelersplanner kan alleen bewerkt worden door kantoormedewerkers.

Terminological Definitions

Term	Definitie
Opdrachtgever	Een persoon of organisatie die in het verleden of op dit moment diensten heeft afgenomen/afneemt van Close Act.
Opdracht	Een door de opdrachtgever en kantoormedewerker opgestelde performance.
Spelersplanner	De uiteindelijke agenda met daarin weergegeven wanneer welke speler voor welke show ingepland staat.
Performance	Een show of een act uitgevoerd door Close Act.
Specifieke performance	Een aan een opdracht aangepaste performance.
Medewerker	Een persoon die voor Close Act werkt.
Speler	Een toneelspeler die voor Close Act werkt.
Kantoormedewerker	Een medewerker die voor Close Act op kantoor werkt.
Rol	Een rol in een performance .
Functie	Een ondersteunende rol in een performance.
Performance variatie	Een standaard performance waarbij bepaalde elementen aangepast zijn aan de wensen van de opdrachtgever, bijvoorbeeld meer spelers bij een act.