Requirements Engineering/het werk/werkstuk/2010-11/Groep 05
RE Project Groep 5 2011
Werkstuk Requirements Engineering
Idzard Stoker, Sanne Derckx, Patrick Verleg, Jasper van Duijnhoven, Feike Geerts
Onderwijsinstituut voor Informatica en Informatiekunde
Radboud Universiteit Nijmegen
version 18 februari 2022
De inhoud is opgebouwd als volgt.
Inhoud
Introduction
In dit requirements document zullen we ingaan op het huidige systeem waarmee evenementen van theatergroep Close-act haar evenementen plant en de problemen daarmee.
Close-act is een in 1991 opgerichte theatergroep die straattheater over de hele wereld opvoert. De groep bestaat uit steltlopers, dansers, muzikanten, vuurspuwers/pyrotechnici en acrobaten, en heeft haar management in Tilburg. Zowel de spelers als het management maakt gebruik van een informatiesysteem waarmee het logistieke gedeelte van de optreden wordt geregeld. Denk hierbij aan het plannen van evenementen en het regelen van transport voor kostuums.
Het huidige systeem kent een aantal problemen. Denk hierbij bijvoorbeeld aan fouten bij de planning van vervoer van kostuums en materialen. In het 'Problem Statement' zullen deze problemen verder uitgewerkt worden. Het doel is een systeem uit te werken dat deze zwakheden wegneemt. Het resultaat zal een geïntegreerd informatiesysteem zijn, waar alle gebruikers mee overweg kunnen.
In dit document zal het nieuwe systeem worden gespecificeerd aan de hand van Use Cases. Use Cases zijn stukjes tekst waarin, door middel van het weergeven van interacties, wordt aangegeven waartoe het systeem in staat moet zijn. In het Use Case diagram staat wie aan welke Use Cases deelneemt en wie ze aansturen.
Na een korte introductie, beginnen we dit document met een analyse van het informatiesysteem van Close-act. Hierbij kijken we onder andere naar de groepen die betrokken zijn bij een nieuw informatiesysteem, de waarden en normen van de groep Close-act en de risico's die komen kijken bij het implementeren van een nieuw informatiesysteem. Vervolgens komen we bij het belangrijkste onderdeel: het specificeren van het nieuwe informatiesysteem. Dit doen we aan de hand van Use Cases en Scenarios. Ook de non-functional requirements komen aan bod. We sluiten af met een lijst van bussiness rules en definities.
Problem statement
Momenteel maakt Close-act gebruik van Outlook en Excel om hun evenementen te plannen. Bij het plannen van evenementen met het huidige systeem loopt er soms het een en ander niet goed.
- Vervoer van kostuums gaat soms fout Onder andere: kostuums worden geboekt op een dag terwijl ze zich op die dag nog in het vervoersproces bevinden.
- Speler past kostuum niet Kostuums hebben geen standaardmaten. Per speler moet bijgehouden worden of hij een bepaald kostuum wel of niet past.
Een aantal zaken werken wel, maar kunnen waarschijnlijk wel beter:
- Plannen van evenementen Momenteel worden alle planningen naast elkaar gelegd. Men kijkt handmatig of deze niet conflicteren. Dit is een foutgevoelig en tijdrovend proces.
- Invoeren van data Niet iedereen maakt gebruik van het afgesproken formaat bij het invoeren van data in Outlook.
- Het contactpersoon is niet aanwezig op locatie Dit levert geen grote problemen op, maar is wel lastig voor de organisatie.
- Gebrek aan overzicht afspraken Afspraken zijn niet altijd eenvoudig te vinden. Er is bijvoorbeeld niet te zoeken op bedrijfsnaam. Dit levert vertraging op wanneer klanten bellen om iets door te geven over een bepaalde afspraak.
Analyse
Het merendeel van deze problemen komt voor omdat de systemen gebrekkig op elkaar afgestemd zijn of omdat er voor die taak geen informatiesysteem bestaat. Het wegnemen van handmatig werk zou deze problemen kunnen oplossen. Daarbij moet worden gewaakt voor het te strikt regelen van alle taken. Close-act heeft aangegeven dat enige vrijheid wel wordt verlangd.
Onze focus zal liggen op het maken van een geïntegreerd systeem waarmee de medewerkers overweg kunnen. Een deel van de taken die nu handmatig gedaan worden zullen we opnemen in het informatiesysteem. Een voorbeeld hiervan is de kostuumplanner: in ons informatiesysteem zal opgenomen worden welke spelers welke kostuums plannen. Sommige delen hebben we bewust buiten onze scope gehouden, om het project haalbaar te houden. Deze taken zullen dus, net zoals in de huidige situatie het geval is, handmatig gedaan moeten worden. Een voorbeeld hiervan is het plannen van transport van de kostuums.
Case analysis
Stakeholder analysis
User Demography:
- Medewerkers
- Spelers
Stakeholder List
- Niels Braakensiek
- Speler
- Niels Braakensiek is een speler bij Close-Act. Hij vertegenwoordigd alle spelers en hun belangen in het systeem. Niels heeft veel verstand van het reilen en zeilen binnen Close Act en is een belangrijke bron van informatie. Naast dat hij veel verstand heeft van het spelersgedeelte van Close Act weet hij ook veel over het huidige systeem en de huidige procedures van Close Act. Niels is onze enige contactpersoon vanuit Close Act tijdens dit project. We zullen vanuit hem dus alle informatie over de requirements moeten verkrijgen.
- Marja Theeuwes
- Kantoormedewerker/Medeoprichter
- Marja Theeuwes is een van de kantoormedewerkers van Close Act. Daarnaast is ze medeoprichten van Close Act. Marja is een bron van requirements op het gebied van het systeem zoals hij gebruikt wordt op het kantoor. Helaas krijgen we haar naar alle waarschijnlijkheid niet te spreken tijdens dit project.
- Vivian, Yda, Tonny
- "Kantoormedewerker"
- Vivian, Yda en Tonny zijn kantoormedewerkers bij Close Act. Zij werken samen met Marja het meest met het systeem en zijn dus een belangrijke bron van informatie. Helaas krijgen we ook deze mensen naar alle waarschijnlijkheid niet te spreken tijdens dit project.
- Hesther Melief
- Directie/Medeoprichter
- Hesther Melief is een van de oprichters van Close Act. Nu functioneert ze als directie. Omdat de directie geen andere rechten in het systeem heeft dan de medewerkers is de directie geen aparte stakeholder.
Mission and vision statement
Mission
Close-Act heeft een systeem nodig dat hen kan ondersteunen in het plannen van evenementen. Op het moment gebruikt Close-Act verschillende systemen zoals Excel en Outlook om hun evenementen te plannen. Hierbij gaan er zo nu en dan een aantal dingen fout zoals bijvoorbeeld kostuums die niet beschikbaar zijn op een moment dat ze nodig zijn. Deze fouten zijn niet structureel, maar op de momenten dat ze voorkomen zijn ze erg problematisch voor Close-Act. De fouten komen vooral voor doordat de planning voor verschillende evenementen met de hand moet worden nagekeken op overlap. Hierbij worden soms dubbele boekingen en dergelijke over het hoofd gezien. Daarom heeft Close-Act een systeem nodig dat hen kan ondersteunen in het plannen van evenementen. Het systeem moet ervoor zorgen dat fouten zoals beschreven in de Problem Statement niet meer voor komen en dat optredens efficient kunnen worden gepland.
Vision
Dit project heeft als eindproduct de requirements voor het systeem dat Close-Act gaat ondersteunen in het plannen van evenementen. De requirements worden opgeschreven in de vorm van Use Cases en zijn een startpunt voor het daadwerkelijk ontwikkelen van het systeem. Bij een juiste en complete uitwerking van de requirements is het mogelijk om aan de hand daarvan een systeem te bouwen dat alle functionaliteiten heeft die de klant nodig heeft. Het systeem waarvoor in dit project de requirements worden opgesteld zal de volgende onderdelen bevatten:
- een agenda
De agenda wordt gebruikt voor het inplannen van evenementen en de data waarop spelers/kostuums op transport zijn.
- een spelersplanner
De spelersplanner wordt gebruikt om te kijken welke speler op welk evenement kan spelen. Ook wordt hier door de medewerker aangegeven wanneer een speler moet spelen.
- een kostuumplanner
De kostuumplanner wordt gebruikt om te kijken welk kostuum op welk evenement kan zijn. Ook wordt hier door de medewerker aangegeven wanneer een kostuum op transport/een evenement is.
De meeste van deze onderdelen zullen voornamelijk gebruikt worden door de medewerkers op het kantoor van Close Act. De spelers kunnen alleen de spelersplanner van het systeem bekijken. Daar kunnen ze zien wanneer ze zijn ingepland om te spelen. Dit moet ook buiten het kantoor van Close-Act mogelijk zijn.
Values
Het systeem moet een ondersteuning zijn voor Close-Act en geen extra hindernis. De gebruikers van het systeem moeten dus zonder extra moeite te doen gebruik kunnen maken van het systeem en niet om het systeem heen gaan werken.
Statement of work
Planning deliverables
Façade: 1 april 2011
Filled: 13 mei 2011
Focused: 10 juni 2011
Voortgang
De voortgang wordt hier bijgehouden.
Risk analysis
| # | Category | Risk | Solution needed by | Status | Days lost | Expectancy factor | Risk factor |
|---|---|---|---|---|---|---|---|
| 01 | Beschikbaarheid van stakeholders | We hebben meer informatie nodig om goede requirements op te stellen en verder te kunnen met het project, maar de stakeholder(Niels) heeft geen tijd om hier met ons over te spreken | n/a | Onopgelost | 14 | 50 | 7 |
| 02 | Beschikbaarheid van stakeholders | We hebben meer informatie nodig van de stakeholder(Niels), maar die is op weg naar een optreden waar hij meerdere dagen voor weg is. | n/a | Onopgelost | 20 | 5 | 1 |
| 03 | Te weinig info | We hebben de verkeerde vragen gesteld, waardoor we de goede informatie niet hebben | n/a | Onopgelost | 8 | 75 | 6 |
| 04 | Uitval | Iemand van de groep stopt met het vak en het project. Daardoor komt er meer druk op de andere groepsleden. | ASAP | Onopgelost | 30 | 25 | 7.5 |
| 05 | Fouten | Er blijkt een fout in onze uitwerkingen te zitten waardoor we een stuk van het project opnieuw moeten doen. | ASAP | Onopgelost | 2 | 75 | 1,5 |
| 06 | Fouten | Het blijkt dat we een deel van het systeem vergeten zijn. Daardoor moeten we die later nog toevoegen aan de requirements | ASAP | Onopgelost | 10 | 20 | 2 |
Requirements
Use cases
Use case survey
| # | Name | Description | Initiating actor |
|---|---|---|---|
| 01 | Evenement beheren | De medewerker maakt een nieuw evenement, bewerkt een evenement of verwijdert een evenement in de agenda | Medewerker |
| 02 | Evenement bevestigen | De medewerker bevestigd het evenement door hem definitief te maken | Medewerker |
| 03 | Spelers reserveren | De medewerker geeft aan welke speler wanneer moet werken of verandert dit in de spelersplanner (werken = reizen + optreden) | Medewerker |
| 04 | Kostuums reserveren | De medewerker geeft aan welk kostuum wanneer waar moet zijn voor een optreden en geeft ook aan wanneer deze op transport moet of verandert dit in de kostuumplanner | Medewerker |
| 05 | Spelersplanner inzien | De speler kijkt in de spelersplanner wanneer hij/zij moet werken | Speler |
| 06 | Beschikbaarheid aangeven | De speler geeft aan wanneer hij zou kunnen werken | Speler |
Integrated use case diagram
Evenement beheren
| Use Case: | Evenement beheren |
|---|---|
| Use case diagram | |
| Description |
Er wordt een nieuw evenement in de agenda gezet. Dit evenement is nog niet bevestigd. Men kan een 'niet bevestigd' evenement zien als een soort optie. Ook kunnen bestaande evenementen worden bewerkt of verwijdert. |
| Source |
Interview met Niels Braakensiek |
| Version |
3.0 |
| Basic course of events |
Evenement aanmaken
|
| Alternate paths |
Evenement bewerken (met aanpassen spelers/kostuums)
Evenement bewerken (zonder aanpassen spelers/kostuums)
Evenement verwijderen
Evenement Bewerken annuleren
Evenement Verwijderen annuleren
|
| Exception Path | |
| Preconditions |
De medewerker zit in de agenda view. De einddatum ligt niet vóór de begindatum. |
| Postconditions |
De medewerker is teruggekeerd naar de agenda view. |
| Related business rules |
|
Evenement bevestigen
| Use Case: | Evenement bevestigen |
|---|---|
| Use case diagram | |
| Description |
Het evenement gaat definitief door en wordt bevestigd. |
| Source |
Interview met Niels Braakensiek |
| Version |
3.0 |
| Basic course of events |
|
| Alternate paths | |
| Exception Path | |
| Preconditions |
|
| Postconditions |
De medewerker is teruggekeerd naar de agenda view. |
| Related business rules |
|
Spelers inplannen
| Use Case: | Spelers inplannen |
|---|---|
| Use case diagram | |
| Description | Een medewerker plant spelers in voor een bepaalde voorstelling op een bepaalde datum. |
| Source | Interview met Niels Braakensiek |
| Version | 3.0 |
| Basic course of events |
|
| Alternate paths |
Speler verwijderen
|
| Preconditions | |
| Postconditions | Er zijn spelers ingepland voor een voorstelling die deze voorstelling kunnen spelen en beschikbaar zijn. |
| Related business rules | Als er een speler op het laatste moment verhinderd is dan moet een medewerker een vervanger zoeken. |
Kostuums reserveren
| Use Case: | Kostuums reserveren |
|---|---|
| Use case diagram | |
| Description | Een medewerker plant kostuums in voor een bepaald evenement. |
| Source | Interview met Niels Braakensiek |
| Version | 3.0 |
| Basic course of events |
|
| Alternate paths |
Kostuumreservering verwijderen
|
| Preconditions | |
| Postconditions | Het systeem heeft de veranderingen aangebracht door de medewerker opgeslagen. |
| Related business rules |
Spelersplanner inzien
| Use Case: | Spelersplanner inzien |
|---|---|
| Use case diagram | |
| Description | Een speler wil weten of (en waar, hoe laat) hij op een bepaalde dag moet werken. Hij kijkt daartoe in de spelersplanner. |
| Source | Interview met Niels Braakensiek |
| Version | 2 |
| Basic course of events |
|
| Alternate paths | (geen) |
| Exeption path |
Nog geen tijd en/of locatie bekend:
|
| Preconditions | De speler heeft de spelersplanner geopend. |
| Postconditions | De speler weet wanneer hij moet spelen. |
| Related business rules |
Beschikbaarheid aangeven
| Use Case: | Beschikbaarheid aangeven |
|---|---|
| Use case diagram | |
| Description | Een speler geeft aan het management door wanneer hij in staat is te werken. |
| Source | Interview met Niels Braakensiek |
| Version | 3.0 |
| Basic course of events |
|
| Alternate paths |
Beschikbaarheid verwijderen
|
| Exception Path |
Beschikbaarheid verwijderen
|
| Preconditions | |
| Postconditions |
|
| Related business rules | Als een speler zich wil afmelden voor een evenement moet hij dit doen via een medewerker. |
Scenarios
Individual scenarios
Evenement beheren
- Medewerker Pientje kiest voor de actie "Nieuw evenement".
- Het systeem laat een invulscherm zien voor een nieuw evenement.
- Medewerker Pientje selecteert als begindatum 1 augustus 2012 en einddatum 3 augustus 2012 en voert de overige gegevens in.
- Medewerker Pientje kiest voor "spelers reserveren".
- Het systeem laat de Spelersplanner zien op het scherm.
- Medewerker Pientje kiest voor "kostuums reserveren".
- Het systeem laat de Kostuumplanner zien op het scherm.
- Medewerker Pientje kiest voor "opslaan" .
- Het systeem laat meteen het evenement zien in de agenda op het scherm.
Evenement bevestigen
BcoE
- Medewerker Jantje selecteert het evenement 'Lowlands'.
- Medewerker Jantje vinkt het vakje 'bevestigd' aan en slaat het evenement op.
- Speler Piet krijgt in zijn mailbox een mail met informatie over het evenement 'Lowlands' waar hij moet spelen.
- Medewerker Jantje ziet het evenement weer in de agenda staan en ziet dat het een andere status heeft gekregen.
Spelers inplannen
BCoE
- Jantje ziet op het scherm welke spelers nog beschikbaar zijn voor de act van 16-6-2011 tot 22-6-2011 in Rome.
- Jantje ziet ook op het scherm welke spelers er al ingepland staan voor dit evenement.
- Jantje selecteert vijf spelers die hij wil inplannen voor deze act.
- Jantje kiest voor 'reserveren'.
- Het systeem sluit het venster van de Spelersplanner en keert terug naar het evenement in de Evenementenplanner.
Speler verwijderen:
- Jantje ziet op het scherm welke spelers nog beschikbaar zijn voor de act van 16-6-2011 tot 22-6-2011 in Rome.
- Jantje ziet ook op het scherm welke spelers er al ingepland staan voor dit evenement.
- Jantje selecteert speler Saartje.
- Jantje kiest voor 'verwijderen'.
- Het systeem sluit het venster van de Spelersplanner en keert terug naar het evenement in de Evenementenplanner.
Kostuums reserveren
BCoE
- Medewerker Flip ziet op het scherm dat er nog 2 kostuums vrij zijn voor de eerste act voor speler 'Jaap'.
- Medewerker Flip ziet op het scherm dat er al 5 kostuums zijn ingepland voor de eerste act.
- Medewerker Flip selecteert het apenkostuum voor speler Jaap en kiest voor reserveren.
- Het systeem sluit het venster met de kostuumplanner en medewerker Flip ziet weer de evenementenplanner op het scherm.
"Kostuum verwijderen"
- Medewerker Flip ziet op het scherm dat er nog 1 kostuums vrij zijn voor de eerste act voor speler 'Jaap'.
- Medewerker Flip ziet op het scherm dat er al 5 kostuums zijn ingepland voor de eerste act.
- Medewerker Flip selecteert het apenkostuum voor speler Jaap en kiest voor verwijderen.
- Het systeem sluit het venster met de kostuumplanner en medewerker Flip ziet weer de evenementenplanner op het scherm.
Spelersplanner inzien
BCoE
- Het systeem toont een overzicht van data waarop Maria moet werken.
- Maria selecteert 1 juni.
- Het systeem toont Maria dat ze om 12:00 uur in Nijmegen moet spelen.
Beschikbaarheid aangeven
BCoE
- Het systeem toont Maria dat ze van 1 juni tot 6 juni moet spelen en dat ze beschikbaar is van 5 augustus tot 10 augustus.
- Maria kiest een begindatum en einddatum van de tijdsspanne waarop hij kan werken en geeft aan dat deze data opgeslagen moeten worden.
- Het systeem geeft aan dat de data opgeslagen zijn.
Beschikbaarheid verwijderen
- Het systeem toont Maria dat ze van 1 juni tot 6 juni moet spelen en dat ze beschikbaar is van 5 augustus tot 10 augustus.
- Maria kiest tijdsspanne 5-10 augustus waarop ze aangegeven heeft te kunnen werken en kiest voor verwijderen.
- Het systeem vraagt om een bevestiging.
- Maria bevestigt de verwijdering.
- Het systeem geeft aan dat deze tijdsspanne verwijderd is.
Integrated Domainmodel
Non-functional Requirements
- Availlability: Het is belangrijk dat het systeem onder werktijden zoveel mogelijk 'online' is. De harde eis hiervoor is dat een uitval niet langer dan 24 uur mag duren.
- Archival: Er moet kunnen worden teruggekeken naar oude optredens, omdat Close-Act evalueren een belangrijke zaak vindt.
- Operability: Het systeem moet makkelijk zijn om te gebruiken. Dit is belangrijk omdat het systeem vooruitgang moet brengen. Dit lukt niet als werknemers liever met de oude losse componenten werken.
- Usability: Het systeem moet overzichtelijk zijn. Spelers moeten in één oogopslag kunnen zien wanneer ze moeten werken in een week of maand.
Addendum
Business Rules Catalogue
- Contractueel afgesproken zaken mogen alleen nog veranderd worden in een bevestigd evenement als er een nieuw contract wordt ondertekend door beide partijen.
- Als een bevestigd evenement wordt geannuleerd door de opdrachtgever blijft de betalingsverplichting bestaan.
- Bij een gepland evenement zijn de volgende data verplicht: begin- en einddatum, opdrachtgever, contactpersoon.
- Een evenement kan niet doorgaan wanneer er niet genoeg spelers of kostuums beschikbaar zijn.
- Het contract is pas valide als het door beide partijen is ondertekend.
- Als er een vooruitbetaling vereist is, dan moet deze binnen zijn voorafgaand aan het bevestigen van het evenement.
- Bevestigde evenementen moeten minimaal het aantal spelers hebben dat benodigd is voor het evenement.
- Als er een speler op het laatste moment verhinderd is dan moet een medewerker een vervanger zoeken.
- Als een speler zich wil afmelden voor een evenement moet hij dit doen via een medewerker.
- Een medewerker heeft recht op het wettelijk aantal vakantiedagen plus 10.
- Een speler kan maximaal tot een week voor een bepaalde datum de beschikbaarheid van die datum nog aanpassen.
- Als er al een opdracht staat op een dag dat een speler vrij wil, kan de beschikbaarheid voor die datum niet worden veranderd.
- Kostuums dienen minimaal 1 dag van tevoren op de locatie van het evenement te zijn.
- Een speler moet minimaal in één act kunnen spelen.
Terminological Definitions
- Agenda
De agenda is een programma dat gebruikt wordt voor het bijhouden van evenementen. In de agenda staan alle dagen in elk jaar.
- Spelersplanner
De spelersplanner is een programma dat gebruikt wordt om spelers in te plannen voor evenementen.
- Kostuumplanner
De kostuumplanner is een programma dat gebruikt wordt om bij te houden welke kostuum op welke evenementen zijn.
- Speelinfo
De speelinfo is een document waarin de informatie staat die een speler nodig heeft voor het spelen op een evenement.
- Medewerker
Een persoon die op het kantoor van Close-Act werkt. (afdeling management?)
- Speler
Een persoon die voorstellingen opvoert voor Close-Act.
- Voorstelling
Het totale geheel van informatie voor een bepaald evenement.
- Opdrachtgever
Een particulier of bedrijf waarvoor Close-Act een evenement verzorgt. Hierbij is niet van belang of het evenement als vast staat of niet.
- Begindatum
Een datum waarop een bepaald evenement begint.
- Einddatum
Een datum waarop een bepaald evenement eindigt.
- Act
Een vaststaand optreden dat Close-Act kan verzorgen voor een opdrachtgever.
- Kostuum
Kleding waarin een speler een act kan spelen.
- Datum
Dag, maand, jaar.
- Contactpersoon
Persoon van de opdrachtgever waarmee contact kan worden opgenomen over de voor hun verzorgde voorstelling.
- Adres
De locatie van een bepaalde voorstelling.
- Soort betaling
De manier waarop betaald wordt.
- Soort optreden
De gelegenheid waarvoor de voorstelling is (bijv. bruiloft).
