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

 

'

Werkstuk Requirements Engineering

Jeroen Bakker, Harm de Wit, Sjoerd van Oostenbrugge, Laurens Dijk

Onderwijsinstituut voor Informatica en Informatiekunde

Radboud Universiteit Nijmegen

---

version 18 februari 2022

---

Introduction

Close-Act Theatre is een professioneel gezelschap met steltlopers, dansers, muzikanten, vuurspelers en acrobaten, die allen regelmatig samen trainen en repeteren. Daarnaast beschikt Close-Act over een atelier met kostuumontwerpers, beeldend kunstenaars en grafisch en industrieel ontwerpers. Het gezelschap van Close-act treedt op in de hele wereld en speelt vaak op (straat)theaterfestivals en grootschalige evenementen. Door de vele optredens verspreid over de wereld en de strakke tijdsplanning is het van groot belang dat de (spelers)planning en de logistieke bijkomstigheden goed worden gecoördineerd.

Momenteel wordt dit alles geregeld door het managementteam van Close-Act, vanuit het kantoor in Tilburg. Het management gebruikt hiervoor meerdere informatiesystemen, waaronder een (Outlook)agenda, een spelersplanner en een kostuumplanner. Het probleem met de huidige informatiesystemen is dat er erg veel informatie omslachtig en op meerdere plaatsen wordt verwerkt en opgeslagen. Een bijkomend probleem is dat de spelersplanning niet naar behoren functioneert en waardoor het erg veel tijd kost om spelers bij een optreden te plannen en waardoor er onnodig veel fouten worden gemaakt.

Het doel van dit document is het beschrijven en vastleggen van de gewenste functionaliteiten van het nieuwe systeem. Deze functionaliteiten zullen worden beschreven aan de hand van use cases. Het document wordt ingeleid met een beschrijving van de huidige problemen binnen Close-Act. Vervolgens worden de doelstellingen voor het nieuwe systeem beschreven en uiteindelijk worden de gewenste functionaliteiten in de detail uitgewerkt.

Problem Statement

Close-Act gebruikt momenteel een aantal verschillende tools voor het beheren van alle informatie rond het organiseren van voorstellingen. De belangrijkste applicaties zijn:

Product	Tool
Agenda	Outlook
Spelersplanner	Excel
Kostuumplanner	Excel
Informatie Opdrachtgevers	Excel
Opdracht informatie	Outlook + andere bestanden
Spelers informatie	Excel + geheugen werknemers

Het probleem is dat er momenteel geen voldoende geïntegreerd systeem bestaat waarmee alle organisatorische taken kunnen worden uitgevoerd. Hierdoor is het plannen van spelers omslachtig en de kans op fouten tijdens het proces groot. Daarnaast kent het huidige systeem hierdoor veel dubbel ingevoerde gegevens. Doordat in het huidige systeem de de business rules van Close-Act onvoldoende geïmplementeerd zijn, worden er veel onnodige fouten gemaakt.

Er zijn nu maar weinig kantoormedewerkers verantwoordelijk voor de management en het beheren van alle informatie. Voor nieuwe kantoormedewerkers is het erg lastig om al deze informatie te overzien. Dit kost erg veel tijd en zorgt ook weer voor fouten.

Als laatste weten de spelers niet van elkaar hoe vaak en wanneer zij optreden. Dit geeft de spelers een vertekend beeld van elkaars inzet voor Close-Act. De enige die deze informatie weet zijn degene die verantwoordelijk zijn voor de planning, de kantoormedewerkers.

Het doel van het project is het verder automatiseren en integreren van de huidige systemen in een holistische planningsapplicatie. De kern van het project zal liggen rondom de agenda en de spelersplanner.

Case analysis

Stakeholder analysis

Nummer	Naam	Functie	Omschrijving
1.	Niels Braakensiek	Speler & opdrachtgever	Niels Braakensiek is een speler bij Close-Act. In deze casus vertegenwoordigt hij als contactpersoon alle partijen binnen Close-Act.
2.	Kantoormedewerkers	Administratie, management en verkoop	De kantoormedewerkers zijn de voornaamste gebruikers van het systeem. Zij houden alle administratieve taken bij, onderhouden relaties en managen de rest van het personeel.
3.	Spelers	Uitvoeren voorstellingen	De artiesten voeren uitendelijk de voorstellingen uit. Zij zijn afhankelijk van het systeem vanwege de informatie die zij moeten krijgen.
4.	Ateliermedewerkers	Onderhouden en maken kostuums	Close-act maakt gebruik van zeer veel en uiteenlopende kostuums. De ateliermedewerkers zijn verantwoordelijk voor het onderhouden en maken van deze kostuums
5.	Hesther Melief en Tonny Aerts	Leiders en financiëel directeur	Melief en Aerts zijn de leiders en financieel directeurs van Close-Act. Zij moeten als eindverantwoordelijken toestemming geven voor het systeem. In dit project zal Niels Braakensiek echter als sponsor optreden

Mission and vision statement

Mission Doordat de organisatie Close-Act in de loop van de jaren steeds groter is geworden en steeds meer optredens verzorgt, voldoet het huidige informatiesysteem niet meer aan de wensen. Om de dagelijkse werkzaamheden beter te kunnen ondersteunen en de huidige processen beter te stroomlijnen, is het van essentieel belang dat het huidige informatiesysteem wordt vervangen door een nieuw (toekomst bestendig) informatiesysteem.

Vision Het doel is om uiteindelijk een systeem te realiseren waarin alle informatie met betrekking tot de planning, spelers en optredens kan worden beheerd. Het systeem moet eenvoudig in gebruik zijn voor zowel de mensen op kantoor als voor de spelers

Values Het is erg belangrijk dat het nieuwe informatiesysteem niet alleen verbetering voor het kantoorpersoon met zich meebrengt maar het nieuwe systeem moet ook duidelijk een toegevoegde waarde hebben voor de overige partijen, zoals de spelers. Het is dus belangrijk dat men tijdens de analyse naar alle soorten gebruikers binnen Close-Act kijkt.

Scope

In dit onderdeel worden de delen aangegeven die niet onderdeel zijn van het project:

- Het resultaat wordt niet gerealiseerd
- Geen technisch ontwerp (netwerkstructuur, datastructuur)

Statement of work

Contactgegevens

Naam	E-mail	Functie
Jeroen Bakker	jeroen.bakker@student.ru.nl	Projectleider en contactpersoon
Sjoerd van Oostenbrugge	svan.oostenbrugge@student.ru.nl	-
Harm de Wit	harmdewit@gmail.com	-
Laurens van Dijk	LaurensvanDijk@student.ru.nl	-
Niels Braakensiek	n.braakensiek@student.ru.nl	Opdrachtgever

Werkplan

Deliverable	Verantwoordelijke	Facade iteratie (014-04-2012)	Status	Filled iteratie	Status	Focused iteratie	Status
Introduction	Sjoerd	Voorlopige versie		Voorlopige versie		Compleet
Problem statement	Jeroen	Zo goed mogelijk		Zo goed mogelijk		Compleet
Stakeholder analysis	Sjoerd	Zo goed mogelijk		Zo goed mogelijk		Compleet
Mission-vision-values	Sjoerd	Compleet		Compleet		Compleet
Statement of work	Groep	Compleet, en up-to-date		Compleet, en up-to-date		Compleet, en up-to-date
Risk analysis	Jeroen/Groep	Compleet, en up-to-date		Compleet, en up-to-date		Compleet, en up-to-date
Use case survery	Jeroen	Zo goed mogelijk		Bijna Compleet		Compleet
Integrated UC diagram	Jeroen	Compleet (of voorlopig)		Compleet		Compleet
Use cases	Groep	Nog niet!		Filled level		Compleet
Scenarios	Groep	Nog niet!		Meerdere per UC		Compleet
Domain models	Groep	Nog niet!		Gedeeltelijk compleet		Compleet
Integrated domain model	Groep	Nog niet!		Gedeeltelijk compleet		Compleet
Business rules catalogue	Groep	Nog niet!		Gedeeltelijk compleet		Compleet
Non-functional requirements	Groep	Notities		Gedeeltelijk compleet		Compleet
Terminological definitions	Groep	Notities		Gedeeltelijk compleet		Compleet
Executive sponsor viewpoint	Groep	Niet nodig		Niet nodig		Niet nodig
Use case tests	-	Notities		Zo goed mogelijk		Compleet
Business process definitions	-	Indien relevant		Indien relevant		Indien relevant
GUI metaphors / storyboards	-	Indien relevant		Indien relevant		Indien relevant

Legenda

 : Voldaan.

 : Niet voldaan / Niet van toepassing.

 : Gestart / Wordt momenteel aan gewerkt binnen Wiki.

Risk analysis

#	Category	Risk	Solution needed by	Status	Days lost	Expectancy factor	Risk factor(1-10)
01	Groepsleden/planning	Groepslid stopt of langdurige ziekte	Groep	Gesloten	-	10%	3
02	Groepsleden/planning	Onvoldoende inzet één of meerdere groepsleden	Groep	Gesloten	-	15%	3
03	Opdrachtgever/stakeholder	De stakeholder is niet tevreden met de opgeleverde stukken gedurende het project	Groep	Gesloten	-	10%	8
04	Opdrachtgever/stakeholder	Faillisement opdrachtgever	RU	Gesloten	-	1%	10
05	Dataverlies	Dataverlies bijvoorbeeld veroorzaakt door een crash van de wiki server of systeem van groepslid	Groep/RU	Gesloten	-	5%	7
06	Opdrachtgever/stakeholder	Communicatieproblemen tussen groep en stakeholder	Groep/Stakeholder	Gesloten	-	10%	5

Requirements

Use cases

Use case survey

#	Name	Description	Initiating actor
01	Toevoegen opdrachten	De kantoormedewerker voegt opdrachten toe aan de agenda.	Kantoormedewerker
02	Beheren medewerkers	De kantoormedewerker voegt medewerkers toe/verwijderd spelers en koppelt mits van toepassing rollen/kostuums aan medewerkers.	Kantoormedewerker
03	Beheren kostuums	De kantoormedewerker of ateliermedewerker voegt nieuwe kostuums toe/verwijderd kostuums of past kostuums aan.	Kantoormedewerker/Ateliermedewerker
04	Beheren agenda	Inzien van de agenda met alle aanwezige opdrachten, opdrachten verwijderen/aanpassen.	Kantoormedewerker
05	Beheren beschikbaarheid	De beschikbaarheid van een speler aanpassen door speler zelf of kantoormedewerker.	Speler/Kantoormedewerker
06	Beheren relaties	De kantoormedewerker kan de informatie over een opdrachtgever inzien/aanpassen.	Kantoormedewerker
07	Beheren producties	De kantoormedewerker of ateliermedewerker kan de informatie van een productie inzien/aanpassen.	Kantoormedewerker/Ateliermedewerker

Integrated use case diagram

Individual use cases

Beheren Medewerkers

Use Case:	Beheren medewerkers
Use case diagram
Description	Medewerkers toevoegen, verwijderen of bewerken.
Source	Interview
Version	1.0
Basic course of events	1. De kantoormedewerker opent het medewerkersbeheer scherm. 2. Het systeem vraagt om de benodigde gegevens om een nieuwe medewerker toe te voegen. 3. De medewerker voert de benodigde gegevens in. 4. De medewerker kiest voor opslaan van de gegevens. 5. Het systeem bevestigt de toevoeging van de nieuwe medewerker.
Alternate paths	1a. De kantoormedewerker opent de gegevens van de betreffende medewerker. 2a. Het systeem toont de gegevens van de geselecteerde medewerker. 3a. De kantoormedewerker wijzigt een of meerdere gegevens van de medewerker. 4a. De kantoormedewerker kiest voor opslaan van de gegevens. 5a. Het systeem bevestigt de wijziging van de gegevens. 1b. De kantoormedewerker opent de gegevens van de betreffende medewerker. 2b. Het systeem toont de gegevens van de geselecteerde medewerker. 3b. De kantoormedewerker kiest voor verwijderen van medewerker. 4b. Het systeem bevestigt het verwijderen van de medewerker.
Exception paths	5. De medewerker is al aanwezig in het systeem, het systeem geeft een foutmelding.
Preconditions	De kantoormedewerker is ingelogd in het systeem
Postconditions	De eventuele wijzigingen zijn in het systeem aangebracht
Related business rules	BM:01. Van een medewerker moet minimaal de voornaam, achternaam en geboortedatum bekend zijn.

Domain Model

Scenarios

Use Case: Beheren medewerkers

Kantoormedewerker Jan Janssen navigeert naar 'Medewerkersbeheer' Het systeem toont een overzicht van aanwezige medewerkers en mogelijke acties - Niels - Robin - Paul - Irene Jan Janssen kiest voor toevoegen van nieuwe medewerker Het systeem vraagt om de benodigde informatie Jan Janssen vult in: Voornaam : Jeroen Achternaam : Bakker Geboortedatum : 03-02-1989 Functie : Speler Straatnaam : Juno Huisnummer : 46 Postcode : 6661JD Woonplaats : Elst Email : jbakker@mail.nl Telefoon : 0612345678 Jan Janssen kiest voor opslaan Het systeem bevestigt de toevoeging van een nieuwe medewerker

Use Case:Beheren medewerkers (Alternative path 1)

Kantoormedewerker Jan Janssen navigeert naar 'Medewerkersbeheer' Het systeem toont een overzicht van aanwezige medewerkers en mogelijke acties - Niels - Robin - Paul - Irene Jan Janssen kiest de medewerker die aangepast dient te worden Het systeem toont de gegevens van de betreffende medewerker Voornaam : Jeroen Achternaam : Bakker Geboortedatum : 03-02-1989 Functie : Speler Straatnaam : Juno Huisnummer : 46 Postcode : 6661JD Woonplaats : Elst Email : jbakker@mail.nl Telefoon : 0612345678 Jan Janssen wijzigt het telefoonnummer in 0609876543 en bevestigt de nieuwe gegevens Het systeem bevestigt de wijziging van de gegevens

Use Case: Beheren medewerkers (Alternative path 2)
Jan Janssen navigeert naar 'Medewerkersbeheer' Het systeem toont een overzicht van aanwezige medewerkers en mogelijke acties - Niels - Robin - Paul - Irene Jan Janssen kiest de medewerker die verwijderd dient te worden Het systeem vraagt of de speler daadwerkelijk verwijderd dient te worden Jan Janssen kiest voor 'ja' Het systeem bevestigt het verwijderen van de speler

Toevoegen Opdrachten

Use Case:	Toevoegen opdrachten
Use case diagram
Description	Opdrachten toevoegen aan de agenda.
Source	Interview
Version	1.0
Basic course of events	1. De medewerker opent het toevoegen opdracht scherm. 2. Het systeem toont de opdrachtplanner en mogelijkheden. 3. De medewerker kiest voor het toevoegen van een opdracht. 4. Het systeem vraagt om de benodigde gegevens voor het toevoegen van een nieuwe opdracht. 5. De medewerker voert de benodigde gegevens in. 6. Het systeem bevestigt de aanpassing en toont de planner.
Alternate paths	7a. De medewerker voegt nog een opdracht toe. Terug naar BCoE stap 2
Exception paths	6a. Er bestaat al een identieke opdracht, het systeem geeft een foutmelding. Terug naar BCoE stap 2
Preconditions	De medewerker is ingelogd in het systeem.
Postconditions	Eventuele wijzigingen zijn opgeslagen.
Related business rules	BO:01. Aan een opdracht kan te allen tijden informatie worden toegevoegd.

Domain Model

Scenarios

Use Case: Toevoegen opdrachten, BCOE

De kantoormedewerker Niels Braakensiek opent het opdrachten toevoegen scherm. Het systeem toont de beschikbare opties aan de kantoormedewerker. De kantoormedewerker kiest de optie 'Opdracht toevoegen'. Het systeem vraagt om de benodigde informatie. De kantoormedewerker vult in: - Datum: 09-08-2012 - Opdracht: Saurus - Spelerslijst: Jos Bruiningen, [..] - Materiaallijst: Saurus - Locatie: Nijmegen - Optie/Definitief : Optie De kantoormedewerker bevestigt zijn keuze. Het systeem bevestigt de wijziging en toont de planner. De kantoormedewerker sluit het systeem.

Beheren Agenda

Use Case:	Beheren agenda
Use case diagram
Description	Overzicht van aanwezige opdrachten bekijken/aanpassen/verwijderen.
Source	Interview
Version	1.0
Basic course of events	1. De medewerker opent de agenda. 2. Het systeem toont de opdrachtplanner. 3. De medewerker filtert de resultaten. 4. De medewerker kiest een opdracht. 5. Het systeem toont de opdrachtinformatie.
Alternate paths	1a. De medewerker opent de agenda. 2a. Het systeem toont de opdrachtplanner. 3a. De medewerker filtert de resultaten. 4a. De medewerker kiest een opdracht. 5a. Het systeem toont de opdrachtinformatie. 6a. De medewerker kiest voor aanpassen opdracht. 7a. Het systeem toont de opdrachtinformatie 8a. De medewerker past de gegevens aan en kiest voor opslaan 9a. Het systeem bevestigt de wijziging van de opdracht 6b. De medewerker kiest voor het verwijderen van een opdracht. 7b. Het systeem vraagt om een bevestiging. 8b. De medewerker bevestigt de keuze. 9b. Het systeem bevestigt het verwijderen van de opdracht en keert terug naar de agenda.
Exception paths	7b. De te verwijderen opdracht is al verwijderd, het systeem geeft een foutmelding Terug naar BCoE stap 2 9a. Niet alle gegevens zijn ingevuld, het systeem geeft een foutmelding. Terug naar BCoE stap 5
Preconditions	De medewerker is ingelogd in het systeem.
Postconditions	De eventuele wijzigingen zijn in het systeem aangebracht
Related business rules	BA:01. Alleen kantoormedewerkers mogen opdrachtgegevens aanpassen.

Domain Model

Scenarios

Use Case: Beheren Agenda, BCOE
De kantoormedewerker Jan Janssen opent de agenda. Het systeem toont de opdrachtplanner. Jan Janssen filtert de resultaten op 16 juni t/m 20 juni. Jan Janssen kiest de opdracht 'Saurus'. Het systeem toont getdetailleerde informatie over de opdracht 'Saurus'.

Use Case: Beheren Agenda opdracht wijzigen

De kantoormedewerker Niels Braakensiek opent de agenda. Het systeem toont de opdrachtplanner Niels Braakensiek filtert de resultaten op 16 juni t/m 20 juni. Niels Braakensiek kiest de opdracht 'Saurus' Het systeem toont getdetailleerde informatie over de opdracht 'Saurus'. Niels Braakensiek kiest voor de optie 'aanpassen opdracht' Niels Braakensiek voegt informatie toe aan de opdracht 'Saurus'. Het systeem bevestigt de wijziging van de opdracht en toont de opdrachtplanner.

Use Case: Beheren Agenda, verwijderen opdracht.

De kantoormedewerker Niels Braakensiek opent de agenda. Niels Braakensiek filtert de resultaten op 16 juni t/m 20 juni. Niels Braakensiek kiest de opdracht 'Saurus'. Het systeem toont getdetailleerde informatie over de opdracht 'Saurus'. Niels Braakensiek verwijderd de opdracht 'Saurus'. Het systeem vraagt of de opdracht daadwerkelijk verwijderd dient te worden. Niels Braakensiek kiest voor 'ja' . Het systeem bevestigt het verwijderen van de opdracht en toont de agenda.

Beheren beschikbaarheid

Use Case:	Beheren beschikbaarheid
Use case diagram
Description	Beschikbaarheid van de speler opgeven of wijzigen.
Source	Interview
Version	1.0
Basic course of events	1. De Speler opent het beschikbaarheidsbeheer scherm. 2. Het systeem toont een kalenderoverzicht inclusief de geplande opdrachten. 3. De speler selecteert de data waarop hij/zij beschikbaar is. 4. Het systeem controleert de ingevoerde data en geeft een bevestiging. 5. Het systeem toont de informatie over de geplande optredens.
Alternate paths	3a. De speler wijzigt de data waarop hij/zij beschikbaar is. Terug naar BCoE stap 4 1b. De kantoormedewerker wilt de beschikbaarheid van een speler aanpassen. 2b. Het systeem toont een kalenderoverzicht inclusief de geplande opdrachten. 3b. De kantoormedewerker selecteert de gewenste speler. 4b. De kantoormedewerker past de beschikbaarheid van de speler aan. Terug naar BCoE stap 4.
Exception paths	4. Het wijzigen van de beschikbaarheid is buiten de termijn van 3 weken en dus niet meer mogelijk.
Preconditions	De medewerker is ingelogd in het systeem
Postconditions	De eventuele wijzigingen zijn in de beschikbaarheidsplanning aangebracht
Related business rules	BBS:01. Spelers mogen zich altijd 'automatisch' (1 week voor de speeldatum) aanmelden voor een act. BBS:02. Spelers mogen hun beschikbaarheid binnen een termijn van 3 weken voor het optreden, niet meer 'automatisch' wijzigen. Het wijzigen binnen dit termijn kan alleen gedaan worden door kantoormedewerkers van Close-Act. BBS:03 .Spelers mogen hun beschikbaarheid in het verleden niet wijzigen.

Domain Model

Scenarios

Use Case: Beheren beschikbaarheid

De speler Jos Bruiningen opent op 23 mei 2012 het 'beschikbaarheidsbeheer' Het systeem toont een agenda van het huidige kwartaal met hierbij de geplande optredens: - 26 juni: festival Zeeland - 27 t/m 30 juni: straatfeest Barcelona - 1 augustus: Appelpop Tiel Jos Bruiningen schrijft zich in voor het festival in Zeeland op 26 juni. Het systeem controleert de ingevulde beschikbaarheid en geeft een notificatie dat het opgeven van de beschikbaarheid is gelukt. Het systeem toont (gedetailleerde) informatie over de geplande opdracht.

Use Case: Beheren beschikbaarheid (Alternative path 1)

De speler Peter Vermeer opent op 10 juni 2012 het 'beschikbaarheidsbeheer' Het systeem toont een agenda van het huidige kwartaal met hierbij de geplande optredens: - 26 juni: festival Zeeland (Peter Vermeer is hier al ingepland door Close-Act) - 27 t/m 30 juni: straatfeest Barcelona - 1 augustus: Appelpop Tiel Jos Bruiningen is helaas verhinderd op 26 juni en wilt zijn beschikbaarheid wijzigen. Het systeem controleert de ingevulde beschikbaarheid en geeft een notificatie dat het wijzigen van de beschikbaarheid, binnen een termijn van 3 weken voor het optreden niet meer 'automatisch' mogelijk is. Het systeem toont weer het kwartaaloverzicht.

Use Case: Beheren beschikbaarheid (Alternative path 2)

De kantoormedewerker Adri van Houwelingen opent op 22 juni 2012 het 'beschikbaarheidsbeheer' Het systeem toont een agenda van het huidige kwartaal met hierbij de geplande optredens: - 26 juni: festival Zeeland (Peter Vermeer is hier al ingepland door Close-Act) - 27 t/m 30 juni: straatfeest Barcelona - 1 augustus: Appelpop Tiel Via de telefoon heeft Adri van Houwelingen te horen gekregen dat Jos Bruiningen is verhinderd op 26 juni en wilt zijn beschikbaarheid wijzigen. Adri van Houwelingen past de beschikbaarheid van Peter Vermeer aan. Het systeem controleert de ingevulde beschikbaarheid en geeft toont een bevestiging. Het systeem toont (gedetailleerde) informatie over de geplande opdracht.

Beheren Kostuums

Use Case:	Beheren kostuums
Use case diagram
Description	Kostuums toevoegen, bewerken en verwijderen
Source	Interview
Version	1.0
Basic course of events	1. De medewerker opent het kostuumbeheer scherm 2. Het systeem toont een overzicht van de kostuums 3. De medewerker kiest voor het toevoegen van een nieuw kostuum 4. Het systeem vraagt om de benodigde informatie 5. De medewerker voert de nieuwe informatie in 6. De medewerker slaat het nieuwe kostuum op 7. Het systeem geeft een notificatie dat het kostuum is opgeslagen 8. Het systeem toont een overzicht van de kostuums
Alternate paths	3a. De medewerker geeft aan een kostuum te willen bewerken 4a. Het systeem toont de gegevens van het kostuum 5a. De medewerker bewerkt de gegevens 6a. De medewerker slaat het gewijzigde kostuum op 7a. Het systeem geeft een notificatie dat het kostuum is aangepast 8a. Het systeem toont het kostuum 3b. De medewerker geeft aan het kostuum te willen verwijderen 4b. Het systeem vraagt om een bevestiging 5b. De medewerker bevestigt 6b. Het systeem geeft een notificatie dat het kostuum is verwijderd 7b. Het systeem toont een overzicht van kostuums
Exception Paths	6, 6a. Het kostuum bestaat reeds, het systeem geeft een foutmelding Terug naar stap 5, 5a 6, 6a. Er ontbreken gegevens, het systeem geeft een foutmelding Terug naar stap 5, 5a
Preconditions	De medewerker is ingelogd in het systeem
Postconditions	De eventuele wijzigingen in het systeem zijn aangebracht
Related business rules	BK:01. Identieke kostuums mogen niet bestaan bestaan maar moeten worden vermeld in het aantal BK:02. Een kostuum moet minimaal de volgende informatie bevatten: naam, beschrijving, thema en aantal

Domain Model

Scenarios

Use Case: Beheren Kostuums

Ateliermedewerker Diana Buren navigeert naar de kostuumbeheer pagina Diana Buren drukt op de knop nieuw kostuum Er wordt een leeg formulier voor het toevoegen van een kostuum getoond Diana Buren vult het formulier in met de onderstaande gegevens: Naam: Sirene Beschrijving: Half-vrouw, half-vis op stelten Aantal: 2 Maat: M Het systeem toont de volgende mogelijke thema's Malayan Greek Myths Aliens Xo Diana Buren kiest "Greek Myths" Diana Buren drukt op opslaan Het systeem bevestigt de actie met de melding "Het kostuum is opgeslagen." Het systeem toont een nieuwe pagina met de details van het kostuum

Use Case: Beheren Kostuums (Alternative path wijzigen kostuum)

Ateliermedewerker Diana Buren Stuum navigeert naar de kostuumbeheerpagina Het systeem toont een overzicht van aanwezige kostuums en mogelijke acties White wings Saurus Duivel Rebel Diana Buren kiest voor Rebel Het systeem toont een overzicht van de kostuumgegevens Naam: Rebel Maat: M Aantal: 1 Diana Buren wijzigt het aantal in 4 Diana Buren klikt op opslaan Het systeem bevestigt de wijziging van het kostuum Het systeem toont de pagina van het kostuum

Use Case: Beheren kostuums (Alternative path verwijderen kostuum)
Diana Buren navigeert naar 'kostuumbeheer' Het systeem toont een overzicht van aanwezige kostuums en mogelijke acties White wings Saurus Duivel Rebel Diana Buren kiest het kostuum dat verwijderd dient te worden Het systeem vraagt of het kostuum daadwerkelijk verwijderd dient te worden Diana Buren kiest voor 'ja' Het systeem bevestigt het verwijderen van het kostuum

Beheren relaties

Use Case:	Beheren relaties
Use case diagram
Description	Relaties toevoegen, bewerken en verwijderen
Source	Interview
Version	1.0
Basic course of events	1. De medewerker opent het relatiebeheer scherm 2. Het systeem toont een een overzicht van de aanwezige relaties 3. De medewerker kiest voor het toevoegen van een nieuwe relatie 4. Het systeem vraagt om de benodigde informatie om een relatie toe te voegen 5. De medewerker voert de benodigde gegevens in 6. De medewerker slaat de nieuwe relatie op 7. Het systeem geeft een notificatie dat de relatie is opgeslagen 8. Het systeem toont de relatie
Alternate paths	3a. De medewerker geeft aan een relatie te willen bewerken 4a. Het systeem toont de gegevens van de relatie 5a. De medewerker bewerkt de informatie 6a. De medewerker slaat de gewijzigde relatie op 7a. Het systeem geeft een notificatie dat de relatie is bewerkt 8a. Het systeem toont de relatie 3b. De medewerker geeft aan de relatie te willen verwijderen 4b. Het systeem vraagt om een bevestiging 5b. De medewerker geeft een bevestiging 6b. Het systeem geeft een notificatie dat de relatie is verwijderd 7b. Het systeem toont een overzicht van relaties
Exception Paths	6, 6a. De relatie bestaat reeds, het systeem geeft een foutmelding Terug naar stap 5, 5a 6, 6a. Er ontbreken gegevens, het systeem geeft een foutmelding Terug naar stap 5, 5a
Preconditions	De medewerker is ingelogd in het systeem
Postconditions	De eventuele wijzigingen in het systeem zijn aangebracht
Related business rules	BR:01. Identieke relaties mogen niet bestaan

Domain Model

Scenarios

Use Case: Beheren Relaties

Een medewerker navigeert naar de relatiebeheer pagina De medewerker drukt op de knop nieuwe relatie Er wordt een leeg formulier voor een relatie getoond De medewerker vult het formulier in met de onderstaande details: Voornaam: Harm Achternaam: de Wit Bedrijf: City Events B.V. Telefoon nr.: 06 221 43776 Email: harmdewit@gmail.com Adres: Pater Tulpstraat 11A Ysselsteyn Postcode: 5813 CD De medewerker drukt op opslaan Het systeem geeft een bevestiging met de melding "De relatie is opgeslagen" Het syteem toont een nieuwe pagina met de bovenstaande details

Use Case: Beheren Relaties (Alternative path wijzigen relatie)

Een medewerker navigeert naar de relatiebeheer pagina De medewerker drukt op de relatie met de naam "Harm de Wit" Het systeem toont de relatie met de onderstaande details: Voornaam: Harm Achternaam: de Wit Bedrijf: City Events B.V. Telefoon nr.: 06 221 43776 Email: harmdewit@gmail.com Adres: Pater Tulpstraat 11A Ysselsteyn Postcode: 5813 CD De medewerker drukt op wijzigen De medewerker verandert in het formulier de waarde van email adres naar "Veenmos 3 Ysstelsteyn" De medewerker drukt op opslaan Het systeem geeft een bevestiging met de melding "De relatie is opgeslagen" Het syteem toont de relatie met de bovenstaande details

Use Case: Beheren relaties (Alternative path verwijderen relatie)
Marja navigeert naar 'relatiebeheer' Het systeem toont een overzicht van aanwezige relaties en mogelijke acties City Events Stichting Muziekstad Stichting vrienden van Elst Gemeente Arnhem Marja kiest de relatie die verwijderd dient te worden Het systeem vraagt of de relatie daadwerkelijk verwijderd dient te worden Marja kiest voor 'ja' Het systeem bevestigt het verwijderen van de relatie

Beheren Producties

Use Case:	Beheren producties
Use case diagram
Description	Producties toevoegen, bewerken en verwijderen
Source	Interview
Version	1.0
Basic course of events	1. De medewerker opent het productiebeheer scherm 2. Het systeem toont een overzicht van de producties 3. De medewerker kiest voor het toevoegen van een nieuwe productie 4. Het systeem vraagt om de benodigde informatie 5. De medewerker voert de nieuwe informatie in 6. De medewerker slaat de nieuwe productie op 7. Het systeem geeft een notificatie dat de productie is opgeslagen 8. Het systeem toont een overzicht van de producties
Alternate paths	3a. De medewerker geeft aan een productie te willen bewerken 4a. Het systeem toont de gegevens van de productie 5a. De medewerker bewerkt de gegevens 6a. De medewerker slaat de gewijzigde productie op 7a. Het systeem geeft een notificatie dat de productie is aangepast 8a. Het systeem toont de productie 3b. De medewerker geeft aan een productie te willen verwijderen 4b. Het systeem vraagt om een bevestiging 5b. De medewerker geeft een bevestiging 6b. Het systeem geeft een notificatie dat de productie is verwijderd 7b. Het systeem toont een overzicht van de producties
Exception Paths	6, 6a. De kostuum bestaat reeds, het systeem geeft een foutmelding Terug naar stap 5, 5a 6, 6a. Er ontbreken gegevens, het systeem geeft een foutmelding Terug naar stap 5, 5a
Preconditions	De medewerker is ingelogd in het systeem
Postconditions	De eventuele wijzigingen in het systeem zijn aangebracht
Related business rules	BP:01. Een productie heeft ten minste één rol

Domain Model

Scenarios

Use Case: Beheren Producties

Kantoormedewerker Diana Buren navigeert naar de productiebeheer pagina Diana Buren drukt op de knop nieuwe productie Er wordt een leeg formulier voor het toevoegen van een nieuwe productie getoond Diana Buren vult het formulier in met de onderstaande gegevens: Naam: Malayan Aliens Beschrijving: Het nieuwe spektakel van close-act Malayan Aliens Spelerslijst: - Materiaallijst: Ufo Diana Buren drukt op opslaan Het systeem bevestigt de actie met de melding "De productie is opgeslagen." Het systeem toont een nieuwe pagina met de details de productie

Use Case: Beheren producties (Alternative path 1)

Kantoormedewerker Diana Buren navigeert naar 'productiebeheer' Het systeem toont een overzicht van aanwezige producties en mogelijke acties Malaya XO Greek Myths Aliens Diana Buren kiest de productie die aangepast dient te worden Het systeem toont de gegevens van de betreffende productie Naam : Malaya Omschrijving : Bakker Spelerslijst : Niels Braakensiek, x, y Materiaallijst : Diana Buren wijzigt de spelerslijst in Niels Braakensiek, Jeroen Bakker, Sjoerd van Oostenbrugge en bevestigt de nieuwe gegevens Het systeem bevestigt de wijziging van de gegevens

Use Case: 01 Beheren producties (Alternative path 2)
Kantoormedewerker Diana Buren navigeert naar 'Productiebeheer' Het systeem toont een overzicht van aanwezige producties en mogelijke acties Malaya XO Greek Myths Aliens Diana Buren kiest de productie die verwijderd dient te worden Het systeem vraagt of de productie daadwerkelijk verwijderd dient te worden Diana Buren kiest voor 'ja' Het systeem bevestigt het verwijderen van de productie

Non-functional Requirements

Availlability

Het belangrijkste is dat het systeem tijdens de kantooruren beschikbaar is. Close-Act hecht niet zozeer waarde aan een 99% uptime garantie als hier veel hogere kosten tegenover staan. Onderhoud en updates zullen dus wel zoveel mogelijk buiten reguliere kantooruren moeten plaatsvinden.

Integrity

Omdat er persoonsgegevens van medewerkers in het systeem worden opgeslagen moet hier zorgvuldig mee om worden gegaan. Voor de opslag van persoonsgegevens van de medewerkers zijn verschillende wetten van belang waaraan het systeem moet voldoen. Het gaat hier met name om de wet bescherming persoonsgegevens/telecommunicatiewet.

Security / Accessibility

Omdat het voor spelers mogelijk is het systeem van buitenaf te benaderen is het van belang dat er verschillende 'lagen' in het systeem zitten. Het moet niet mogelijk zijn om bijvoorbeeld NAW-gegevens van medewerkers van buitenaf te benaderen. Dit kan leiden tot verlies, diefstal of manipulatie van de data.

Addendum

Integrated Domainmodel

Business Rules Catalogue

Beheren Medewerkers

• BM:01. Van een medewerker moet minimaal de voornaam, achternaam en geboortedatum bekend zijn.

Beheren opties

• BO:01. Aan een optie kan te allen tijden informatie worden toegevoegd.

Beheren Agenda

• BA:01. Alleen kantoormedewerkers mogen opdrachtgegevens aanpassen.

Beheren Beschikbaarheid

• BBS:01. Spelers mogen zich altijd 'automatisch' (1 week voor de speeldatum) aanmelden voor een act.
• BBS:02. Spelers mogen hun beschikbaarheid binnen een termijn van 3 weken voor het optreden, niet meer 'automatisch' wijzigen. Het wijzigen binnen dit termijn kan alleen gedaan worden door * kantoormedewerkers van Close-Act.
• BBS:03 .Spelers mogen hun beschikbaarheid in het verleden niet wijzigen.

Beheren Kostuums

• BK:01. Identieke kostuums mogen niet bestaan bestaan maar moeten worden vermeld in het aantal.
• BK:02. Een kostuum moet minimaal de volgende informatie bevatten: naam, beschrijving, thema en aantal.

Beheren relaties

• BR:01. Identieke relaties mogen niet bestaan.

Beheren producties

• BP:01. Een productie heeft ten minste één rol.

Terminological Definitions

• Productie: Een themavoorstelling van Close Act zoals bijvoorbeeld Malaya.
• Opdracht: Een opdracht is een ingeplande productie in de agenda, een opdracht kan definitief zijn of niet.
• Opdrachtgever: Een bedrijf dat de opdracht geeft voor een voorstelling.
• Kostuum: Kledingset die toebehoort aan een rol.
• Medewerker: Een persoon die werkzaam is bij Close-Act.
• Ateliermedewerker: Een persoon die kostuums en rekwisieten beheert.
• Speler: Een acteur die één of meerdere rollen speelt.
• Kantoormedewerker: Een medewerker die werkzaam is op het kantoor van Close-Act.
• Rekwisieten: Onderdelen van een act welke niet onder het kostuum vallen.