Requirements Engineering/het werk/werkstuk/2011-12/Groep 05
Close-Act Case
Werkstuk Requirements Engineering
Jean-Paul Veenendaal, Luuk Scholten, Thom Wiggers
Onderwijsinstituut voor Informatica en Informatiekunde
Radboud Universiteit Nijmegen
version 18 februari 2022
Inhoud
- 1 Introduction
- 2 Case analysis
- 3 Requirements
- 3.1 Use cases
- 3.2 Scenarios
- 3.3 Non-functional Requirements
- 4 Addendum
- 5 Appendix
Introduction
Close-Act is opgericht in 1991, het is een professioneel theatergezelschap die door heel de wereld reist om optredens uit te voeren. Dit theatergezelschap bestaat uit Nederlanders en Belgen en alle spelers zijn freelancers. De daadwerkelijke organisatie zit op het kantoor en bestaat hoofdzakelijk uit administratiemedewerkers. Zij regelen alle dingen rond optredens, van boekingen tot hotels, vervoer en kostuums. Het repertoire van Close-Act is vrij groot en elk repertoire heeft zo zijn eigen kostuums. Klanten van Close-Act kunnen zelf bepalen hoe uitgebreid de show moet worden en waar de locatie van de show is.
Om dit goed te laten verlopen maken ze gebruik van verschillende planners zoals een spelerplanner en kostuumplanner, helaas werkt hun huidige systeem niet optimaal. Het kost erg veel tijd om de consistentie van de gegevens in de systemen te controleren, en hierdoor ontstaan soms problemen. Er is ook veel informatie die alleen bij de medewerkers bekend is en mondeling overgedragen wordt, omdat er geen mogelijkheid is dit te noteren.
In dit verslag zullen er een aantal werkprocessen onder loep genomen worden, met als doel het werkproces van Close-Act verbeteren. Dit wordt gedaan doormiddel van een uitgebreide case analyse van Close-Act. Allereerst wordt het probleem binnen Cose-Act beschreven in de 'Problem statement'. In de 'Case analysis' staan alle stakeholders beschreven met elk hun eigen belangen. Bij de 'Risk analysis' staan de verschillende use cases, waar we de verschillende interacties met het nieuwe systeem en de actor, de betreffende gebruiker van de use case, beschrijven. In de individual use cases wordt de interactie van de desbetreffende use case per stap beschreven tussen het systeem en de gebruiker. Tevens heeft elke use case een eigen domeinmodel waar beschreven staat hoe de gegevens in het systeem met elkaar gekoppeld zijn. Deze use cases testen we vervolgens aan de hand van 'scenario's'. Aan het eind van dit document zijn de 'Business Rules' in een lijst opgestald, welke beperkende regens zijn binnen het systeem. Deze Business Rules zijn ook te terug te vinden in de use cases.
Problem statement
Close-Act maakt momenteel gebruik van verschillende losse planners voor het plannen van kleding en spelers. De communicatie tussen de spelers en administratie loopt nog niet vlekkeloos. Als er gevraagd wordt naar spelers voor een optreden wordt er gemaild of gebeld naar de spelers of ze kunnen optreden. Het duurt lange tijd voordat alle spelers gereageerd hebben. Dit zou verbeterd kunnen worden door de spelers zelf van te voren aan te laten geven wanneer ze beschikbaar zijn, om zo tijd te besparen.
De informatie over de spelers staat niet opgeslagen in de planner, als iemand bijvoorbeeld een bepaald kostuum niet wil dragen of als een bepaalde bus al is uitgeleend, dan is dit niet opgeslagen in de planner maar weet de administratie dit als ze dingen gaan inplannen. Het komt soms toch voor dat er wel eens dingen vergeten worden en er een fout wordt gemaakt.
In het kort:
- Het nalopen van beschikbaarheid van spelers is erg arbeidsintensief
- De verschillende, aparte, planners kosten te veel tijd
- Er is veel kennis slechts bij de individuele kantoormedewerkers bekend
Dit willen wij oplossen door:
- Spelers zelf de beschikbaarheid te laten aangeven
- De planners in elkaar te integreren
- Informatie over spelers bij te houden.
Case analysis
Stakeholder analysis
| # | Instantie | Type | Belang |
|---|---|---|---|
| 01 | Dhr. Braakensiek | Speler | De spelers willen eerder op de hoogte zijn en meer duidelijkheid over hun tijd |
| 02 | Dhr. Braakensiek | Klant | De klant wil snel antwoord en veel duideiljkheid. Ook zitten ze niet te wachten op tegenslagen door administratieve fouten. |
| 03 | Dhr. Braakensiek | Vertegenwoordiger Close-Act | Dhr. Braakensiek is de opdrachtgever, en contactpersoon voor de bovenstaande partijen. Als het project geslaagd is, heeft hij zijn doelstelling volbracht om ons RE bij te brengen. |
| 04 | Dhr. Braakensiek | Administratiemedewerker | De Administratie wil tijd besparen door minder dubbel werk te doen en minder fouten maken. |
Mission and vision statement
- Mission: Verbeteren van de planning en communicatie tussen Closeact en de spelers.
- Vision: Een nieuw systeem met een planning waar spelers kunnen aangeven wanneer ze kunnen spelen. Evenals een automatisch systeem die de spelers laat weten als een optreden niet door gaat.
Statement of work
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 en dient nog gecontroleerd te worden. |
| 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. |
Voortgang
| Deliverable | DeliverbleType | Façade | Filled | Focused |
| Introduction | Contextual | V Preliminary version | V Preliminary version | VComplete |
| Problem statement | Key deliverable | V As good as possible | V As good as possible | V Complete |
| Stakeholder list/analysis | Contextual | V As good as possible | V As good as possible | V Complete |
| Mission-Vision-(Values) | Contextual | V Complete | V Complete | V Complete |
| Statement of Work | Contextual | V Complete, and up-to-date | V Complete, and up-to-date | V Complete, and up-to-date |
| Risk Analysis | Contextual | V Complete, and up-to-date | V Complete, and up-to-date | V Complete, and up-to-date |
| Use Case Survey | Key deliverable | V As good as possible | V Nearly complete | V Complete |
| Integrated UC Diagram | Key deliverable | V Complete (though preliminary) | V Complete | V Complete |
| Use Cases | Key deliverable | NV Not yet! | V "Filled" level | V Complete |
| Scenarios | Key deliverable | NV Not yet! | V Preliminary version | V Complete ("focused" level) |
| Domain Models | Key deliverable | NV Not yet! | V Partially complete | V Complete |
| Business rules per UC | Key Deliverable | NV Not yet! | V Partially complete | V Complete |
| Integrated Domain Model | Key deliverable | NV Not yet! | V First draft | V Complete |
| Busines Rules Catalogue | Key deliverable | NV Not yet! | V Partially complete | V Complete |
| Non-functional Requirements | Key deliverable | V Notes | V Partially complete | VComplete |
| Terminological Definitions | Key deliverable | V Notes | V Partially complete | VComplete |
| Executive sponsor viewpoint (MVV) | Implicit deliverable | V Complete | VComplete | VComplete |
| Use case tests(via scenarios) | Implicit deliverable | V Notes | V As good as possible | V Complete |
| Business process definitions | Optional appendix | NV If available / relevant | NV If relevant | NV If relevant |
| GUI metaphors / storyboards | Optional appendix | NV If relevant | NV If relevant | NV If relevant |
Bron van formaat: https://lab.cs.ru.nl/algemeen/Requirements_Engineering/het_werk/werkstuk/2010-11/Groep_03_REact#Statement_of_Work
Risk analysis
| # | Category | Risk | Solution needed by | Status | Days lost | Expectancy factor | Risk factor |
|---|---|---|---|---|---|---|---|
| 01 | Project Time | De deelnemers aan het project hebben net een tentamenperiode achter de rug en hebben weinig tijd gehad om tijd te vinden voor dit project, hierdoor kan het zijn dat de eerste deadline niet gehaald gaat worden. | 17-04-2012 | Deadline gehaald | 2 | 30% | 60 |
| 02 | Project Time | Een tweede deadline komt er aan, en het wegens allerlei redenen kan er vertraging komen | 29-05-2012 | Deadline gehaald | 2 | 35% | 70 |
| 03 | Project Time | Derde deadline staat achter de deur, ook hier kan vertraging komen door verschillende redenen. | 22-06-2012 | Mee bezig | 2 | 60% | 120 |
| 04 | Member Illness | Ziekte in het team kan voorkomen, dit kost tijd en zal moeten worden gecompenseerd. | Deadline Focused Iteration | Nog niet opgelost | 3 | 5% | 15 |
| 05 | Information | Misinterpretatie van informatie verkregen door dhr Braakensiek | Elke deadline | Mee bezig | 5 | 25% | 125 |
| 06 | Communication | Miscommunicatie tussen teamleden informatie verloren gaat of verkeerd begrepen wordt | Elke deadline | Mee bezig | 3 | 20% | 60 |
| 07 | Technisch | Problemen met de wikisyntax kunnen voorkomen, scholing van participanten kost tijd | Elke deadline | Mee bezig | 2 | 80% | 160 |
Requirements
Use cases
Use case survey
| # | Name | Description | Initiating actor | Owner |
|---|---|---|---|---|
| 01 | Beschikbaarheid Bewerken | Aangeven van beschikbaarheid door de speler in het systeem | Administratiemedewerker, Speler | Jean-Paul Veenendaal |
| 02 | Spelersinformatie Bewerken | Invoeren en bijwerken van informatie over spelers in het systeem | Administratiemedewerker, Speler | Luuk Scholten |
| 03 | Agenda Bekijken | Het bekijken van de agenda en details van optredens | Administratiemedewerker, Speler | Luuk Scholten |
| 04 | Optreden Bewerken | Het aanpassen van de optredeninformatie in het systeem of een nieuw optreden aanmaken | Administratiemedewerker | Thom Wiggers |
| 05 | Optreden annuleren | Een optreden annuleren | Administratiemedewerker | Jean-Paul Veenendaal |
| 06 | Offerte maken | Offerte opstellen bij de aanvraag voor een optreden en het bewerken van een offerte | Administratiemedewerker | Thom Wiggers |
Integrated use case diagram
Individual use cases
Beschikbaarheid bewerken
| Use Case #1: | Beschikbaarheid bewerken |
|---|---|
| Description | Bijwerken van de de beschikbaarheid van een speler in het systeem. |
| Source | Interview Niels Braakensiek |
| Version | 2.1 |
| Basic course of events |
|
| Alternate paths |
|
| Preconditions | De gebruiker heeft voldoende toegangsrechten. |
| Postconditions | Beschikbaarheid van een speler is bijgewerkt in het systeem. |
| Related business rules |
|
| Opmerkingen |
De spelerplanner hanteert een opt-in systeem, dat houdt in dat spelers standaard niet beschikbaar tenzij ze aangeven dat ze wel beschikbaar zijn. |
Spelersinformatie bewerken
| Use Case #2: | Spelersinformatie bewerken |
|---|---|
| Description | Invoeren en bijwerken van informatie over spelers in het systeem |
| Source | Interview Niels Braakensiek |
| Version | 2.3 |
| Basic course of events |
|
| Alternate paths |
|
| Preconditions | De huidige gebruiker heeft voldoende toegangsrechten tot het systeem |
| Postconditions | Spelers informatie van de gewenste speler zijn gewijzigd |
| Related business rules |
|
Agenda bekijken
| Use Case #3: | Agenda Bekijken |
|---|---|
| Description | Het bekijken van de agenda en details van optredens. |
| Source | Interview Dhr. Braakensiek, documenten Close-act |
| Version | 2.4 |
| Basic course of events |
|
| Alternate paths |
ACoE 1)
ACoE 2)
ACoE 3)
ACoE 4)
|
| Preconditions |
|
| Postconditions | |
| Related business rules |
|
| Opmerkingen | Na het starten van Optreden bewerken in ACoE 1 en 4 komt men niet meer terug in deze use case. |
Optreden Bewerken
| Use Case #4: | Optreden Bewerken |
|---|---|
| Description | Het aanpassen van de optredeninformatie in het systeem |
| Source | Interview, formulieren close-act |
| Version | 1.1 |
| Basic course of events |
|
| Alternate paths |
|
| Preconditions |
|
| Postconditions |
|
| Related business rules |
|
Optreden annuleren
| Use Case #5: | Optreden Annuleren |
|---|---|
| Description | Het optreden annuleren |
| Source | Interview |
| Version | 1.1 |
| Basic course of events |
|
| Alternate paths |
|
| Preconditions |
|
| Postconditions |
|
| Related business rules |
|
Offerte Maken
| Use Case #6: | Offerte Maken |
|---|---|
| Description | Maken van de offerte |
| Source | Interview Niels Braakensiek |
| Version | 1.3 |
| Basic course of events |
|
| Alternate paths |
|
| Preconditions |
|
| Postconditions |
|
| Related business rules |
|
| Opmerkingen | Niet alle optredens hebben een offerte. |
Domain Model per Use Case
#1 Beschikbaarheid bewerken
#2 Spelersinformatie bewerken
#3 Agenda bekijken
#4 Optreden bewerken
#5 Optreden annuleren
#6 Offerte maken
Scenarios
Johan is een speler
Paul is een van de administratiemedewerkers
#1 Beschikbaarheid bewerken
Scenario 1 (BCoE):
Johan wilt aangeven dat hij van 1 maart tot 7 maart beschikbaar is en opent de spelersplanner
- - -
- Het systeem laat de spelersplanner zien
- Johan selecteert 1 tot en met 7 maart en geeft aan dat hij dan beschikbaar is
- Johan slaat de verandering op
- Systeem vraagt bevestiging voor de wijzingen
- Johan bevestigt de verandering
- Het systeem geeft een bevestiging van de wijzigingen
Scenario 2 (ACoE 1):
Paul wilt aangeven dat Betty van 1 tot en met 7 beschikbaar is en opent de spelersplanner
- - -
- Het systeem laat de spelersplanner zien.
- Paul kiest Betty
- Het systeem laat de beschikbaarheid van Betty zien:
1 t/m 4 augustus , ... , ... , 1 t/m 16 december - Paul selecteert 1 tot en met 7 maart en geeft aan dat zij dan beschikbaar is
- Paul slaat de verandering op
- Het systeem vraagt om een bevestiging voor de wijzingen
- Paul bevestigt de verandering
- Het systeem geeft een bevestig van de wijzigingen
#2 Spelersinformatie bewerken
Scenario 1 (BCoE):
Johan wilt aangeven dat hij vegetariër is en opent zijn spelersinformatie
- - -
- Het systeem toont zijn spelerinformatie:
Tel.nr : 0485-415123
Geslacht: M
Adres, woonplaats: Nijmegen
Adres, Postcode: 6525 RP
...
...
Voorletters: LKA
Achternaam: Papadopoulos - Johan geeft aan zijn informatie te willen bewerken
- Het systeem toont de aanpasmogelijkheden voor Johan:
Tel.nr, Geslacht, Rekeningnummer ... Roepnaam, Dieet - Johan past de gegevens van 'Dieet' aan
- Johan geeft aan de aanpassingen op te willen slaan
- Systeem vraagt bevestiging van de ingevoerde gegevens
- Johan bevestigt de ingevoerde gegevens
Scenario 2 (ACoE 1):
Paul wil Fafner in het systeem invoeren en opent de spelerinformatie
- - -
- Het systeem toont het speleroverzicht
- Paul geeft aan een speler te willen aanmaken
- Het systeem toont de invulmogelijkheden:
Achternaam, Tel.nr, Geslacht, Rekeningnummer ... Roepnaam, Dieet - Paul vult gegevens in:
Roepnaam: "Fafner"
Achternaam: "van Gielen"
Voorletters: "F"
...
Geslacht: "M"
Emailadres: "fafner@spammail.nl" - Paul geeft aan de gegevens te willen opslaan
- Het systeem vraagt om bevestiging van de ingevoerde gegevens
- Paul bevestigt de ingevoerde gegevens
Scenario 3 (ACoE 2):
Paul wil ervoor zorgen dat er in het systeem staat dat Piet vegetariër is en opent de spelersplanner
- - -
- Het systeem toont het speleroverzicht
- Paul kiest Piet in het systeem
- Het systeem toont de huidige spelerinformatie over Piet: zijn naam "Piet Patat", zijn adresgegevens, zijn rekeningnummer 1234567890, dat hij een rijbewijs heeft ...
- Paul geeft aan dat hij de gegevens van Piet wil bewerken
- Het systeem toont de aanpasmogelijkheden voor Piet:
Achternaam, Tel.nr, Geslacht, Rekeningnummer ... Roepnaam, Dieet - Paul past gegevens aan:
Dieet: Vegetariër - Paul geeft aan de gegevens te willen opslaan
- Systeem vraagt bevestiging van de ingevoerde gegevens
- Paul bevestigt de ingevoerde gegevens
#3 Agenda bekijken
Scenario 1 (BCoE):
Johan wilt zien voor welk optreden hij 4 juli staat ingepland en opent de agenda
- - -
- Systeem toont maandoverzicht van Johan voor juli: op 4 juli het optreden in Rotterdam en het optreden in New York, het optreden in New York van 12 juli en het optreden in Amsterdam op 19 juli.
- Johan kiest 4 juli
- Systeem toont daginformatie van 4 juli:
het optreden in Rotterdam en het optreden in New York. - Johan kiest het optreden in New York dat gepland staat op 4 juli met id 523346
- Systeem toont dat de opdrachtgever "Donald Trump" is, de locatie "Trump Tower", dat het hotel "The Hotel" is ...
Scenario 2 (ACoE 1):
Paul wilt het optreden van 9 mei inzien en mogelijk ook aanpassen en opent de agenda
- - -
- Systeem toont de maandoverzicht voor mei: Op 3 mei optredens in Vancouver, Tokyo en Milsbeek, het optreden in Rotterdam van 22 mei en het optreden in New York van 23 mei.
- Paul kiest 9 mei
- Het systeem toont daginformatie, 3 geplande optredens, van 9 mei, 1 in Vancouver, 1 in Tokyo en 1 in Milsbeek.
- Paul kiest het optreden in Milsbeek dat op 9 mei gepland is met id 33445
- Het systeem start use case “Optreden bewerken”
Scenario 3 (ACoE 2):
Het is mei. Paul wil het optreden van een aygustus en opent de agenda
- - -
- Systeem toont het maandoverzicht voor juli: Het optreden in New York van 12 juli en het optreden in Amsterdam op 19 juli.
- Paul kiest de maand augustus
- Een van de andere course of events vanaf start
Scenario 4 (ACoE 3):
Paul wil kijken welke kostuums van 1 januari tot 5 januari 2012 nog beschikbaar zijn en opent de agenda
- - -
- Systeem toont maandoverzicht voor de januari: het optreden op het Winterfestival in Vaticaanstad van 1 t/m 5 januari.
- Paul geeft aan dat hij het kostuumoverzicht wil bekijken
- Systeem toont datumkeuzeopties
- Paul kiest datumspanne 1 t/m 5 januari 2012
- Systeem toont kostuumoverzicht van de gekozen datumspanne: de alien-pakken zijn dan in Vaticaanstad en de Dinos zijn nog beschikbaar.
Scenario 5 (ACoE 4):
Paul wil het optreden, voor opdrachtgever Jeroen Achterstraat, in Amsterdam op 6 juli in voeren in de agenda en opent de agenda
- - -
- Systeem toont maandoverzicht voor juli: Het optreden in New York van 12 juli en het optreden in Amsterdam op 19 juli.
- Paul selecteert 6 juli om een optreden in te voegen
- Systeem vraagt om gegevens van het optreden
- De administratiemedewerker voert de opdrachtgever met naam 'Jeroen Achterstraat' en het evenement in Amsterdam in.
- Use case "Optreden bewerken" start.
#4 Optreden Bewerken
Scenario 1: (BCoE)
Paul wil de locatie van het optreden op 9 december met id '325' aanpassen naar Millingen en opent de agenda
Door de use case “Agenda bekijken” selecteert Paul het optreden van 9 december met id '325'
- - -
- Het systeem laat de optredeninformatie van het optreden op 9 december met id '325', opdrachtgever "Donald Trump", ...
- Paul bekijkt de gegevens en selecteert de locatie, Amsterdam
- Het systeem toont een invoerveld om de locatie aan te passen
- Paul voert 'Millingen' in
- Paul geeft aan de gegevens te willen opslaan
- Het systeem geeft de gegevens weer voor controle
- Paul bevestigt deze gegevens
- Het systeem laat de bijgewerkte optredeninformatie zien
Scenario 2: (ACoE 1)
Paul wil de datum van het optreden het optreden van 1 april met id '218' wijzigen naar 2 april, maar besluit de wijzingen achteraf toch te verwerpen, hij opent de agenda
Door de use case “Agenda bekijken” selecteert Paul het optreden van 1 april met id '218'
- - -
- Het systeem laat de optredeninformatie zien, de datum: 1 april, de locatie "New York", het hotel "The York Hotel", opdrachtgever "Kees Meerbeek"...
- Paul bekijkt de gegevens en selecteert de datum 1 april
- Het systeem toont een invoerveld om de datum aan te passen
- Paul voert 2 april in
- Paul geeft aan de gegevens te willen opslaan
- Het systeem geeft de gegevens weer voor controle
- Paul kiest ervoor de wijzigingen te verwerpen
Scenario 3: (ACoE 2)
Paul wil het optreden van 5 augustus met id '418' definitief maken en opent de agenda
Door de use case “Agenda bekijken” selecteert Paul het optreden van 5 augustus met id '418'
- - -
- Het systeem laat de optredeninformatie zien, met datum 5 augustus, id '418', opdrachtgever "Joep Versteeg", locatie "New Orleans" ...
- Paul maakt het optreden definitief
- Het systeem vraagt om bevestiging definitief maken
- Paul bevestigt het definitief maken
Scenario 4: (ACoE 3)
Paul wilt het contract voor het optreden van 27 augustus met id '519' versturen en opent de agenda
Door de use case “Agenda bekijken” selecteert Paul het optreden van 27 augustus met id '519'
- - -
- Het systeem laat optredeninformatie, met datum 27 augustus, met id '519', opdrachtgever "Johan Achterstraat", locatie "Cupertino" ...
- Paul kiest voor contract versturen
- Systeem vraagt om bevestiging
- Paul bevestigt
Scenario 5: (AcoE 4)
Paul wilt het optreden van van 11 september met id '789' annuleren en opent de agenda
Door de use case "Agenda bekijken" selecteert Paul het optreden van 11 september met id '789'
- - -
- Het systeem laat optredeninformatie zien, met datum 11 september, id '789', locatie "New York", Hotel "The York Hotel" ...
- Paul kiest voor optreden annuleren
- Systeem start use case 'Optreden Annuleren'
- Paul keert terug naar deze Use Case
#5 Optreden annuleren
Scenario 1 (BCoE):
Paul wil het optreden in Kiev op 28 juli annuleren en opent de agenda
- - -
- Paul selecteert het optreden in Kiev op 28 juli
- Het systeem geeft de details van het optreden weer: de datum 28 juli, de locatie "Kiev" ...
- Paul kiest om het optreden te annuleren
- Het systeem vraagt om bevestiging van annulering van het optreden op 28 juli
- Paul bevestigt het annuleren
- Het systeem zet het optreden van 28 juli met locatie 'Kiev' op 'geannuleerd'
- Het systeem stuurt een bericht naar de betrokken spelers: 'Johan Papadopoulos'
Scenario 2 (ACoE 1):
Paul wil het optreden in Amsterdam op 4 augustus annuleren en opent de agenda
- - -
- Paul selecteert het optreden in Amsterdam van 4 augustus
- Het systeem toont dat de opdrachtgever "Jan Jansen" is, de locatie "Amsterdam", dat het hotel "The Hotel" is, ...
- Paul kiest om het optreden te annuleren
- Het systeem vraagt om bevestiging van annulering van het optreden op 4 augustus
- Paul breekt het proces af
#6 Offerte maken
Scenario 1 (BCoE):
Paul wil een offerte maken voor de aanvraag van Piet Dufour van het optreden in Amsterdam op 5 juli
- - -
- Paul kiest ervoor een nieuw optreden te maken
- Paul voert de gegevens van de opdrachtgever Piet Dufour in met id 343 en telefoonnummer 06-34568345, ...
- Paul voert de gegevens van het optreden van 5 juli in met id 532489, evenementnaam 'De grote vijf' vertrektijd 3 juli en opdrachtgever 'Piet Dufour', ...
- Het systeem toont een overzicht van de ingevoerde informatie voor het optreden op 5 juli met id 532489:
Opdrachtgever: 'Piet Dufour'
...
Evenement: 'De grote vijf' - Paul bevestigt de ingevoerde gegevens
- Paul kiest ervoor de offerte te versturen
- Het systeem verstuurt de offerte naar Piet Dufour
Scenario 2 (ACoE 1):
Paul wil een offerte voor Piet Dufour maken en printen voor het optreden van 6 januari in New York
- - -
- Paul kiest ervoor een nieuw optreden te maken
- Paul vult de gegevens van opdrachtgever Piet Dufour in met id 343 en telefoonnummer 06-34568345, ...
- Paul vult de gegevens van het optreden in New York in, met evenementnaam 'The great disaster' met id 4333875, ...
- Het systeem toont een overzicht van de ingevulde informatie van het optreden in New York:
Opdrachtgever: 'Piet Dufour'
...
Evenement: 'The great disaster' - Paul bevestigt de ingevoerde informatie
- Paul kiest ervoor de offerte te printen
- Het systeem print de offerte
Non-functional Requirements
- Authenticatie: het systeem moet gebruikers kunnen authenticeren.
- Authorisatie: Niet alle gebruikers mogen toegang hebben tot bepaalde dingen.
- Integriteit: De gegevens in het systeem mogen niet verloren gaan.
- Veiligheid: Het systeem moet veilig zijn en geen gegevens lekken.
Addendum
Integrated Domainmodel
Business Rules Catalogue
- Spelers kunnen alleen ingepland worden als ze beschikbaar zijn.
- Spelers kunnen alleen van henzelf de beschikbaarheid aangeven.
- Administratiemedewerkers kunnen van iedereen de beschikbaarheid aangeven.
- Alleen administratiemedewerkers mogen optredeninformatie bewerken en aanmaken.
- Alleen administratiemedewerkers kunnen optredeninformatie bewerken.
- Alleen administratiemedewerkers mogen optredens annuleren.
- Bij optredens die na een week voor aanvang worden geannuleerd worden de spelers alsnog betaald.
- Alleen administratiemedewerkers mogen offertes maken.
- Spelers kunnen na ingepland te zijn alleen door de administratie op 'niet beschikbaar' gezet worden.
- Een speler kan alleen zijn eigen spelerinformatie bewerken.
- Een administratiemedewerker kan de spelerinformatie van alle spelers bewerken.
- Optredens hebben een begindatum, een einddatum, een reisdag heen en een reisdag terug.
- Een optreden heeft altijd een opdrachtgever en wordt gegeven op een evenement.
Terminological Definitions
- Act: Vaststaande performance die gegeven wordt op een optreden.
- Administratiemedewerker: Medewerker die op het kantoor van Close-Act werkt.
- Agenda: De agenda is het systeem waar de planning van de kostuums zijn opgeslagen, de informatie over de spelers en de informatie over de optredens.
- Betalingsinformatie: Informatie over het afrekenen van het optreden.
- Beschikbaar: Een speler is beschikbaar op een bepaalde dag als hij op die dag in staat is een act te doen bij een optreden.
- Bijzonderheden: Bijkomende informatie bij optredens.
- Contactpersoon: De persoon van de organisatie van de evenement waarmee tijdens het evenement gecommuniceerd wordt.
- Daginformatie: Informatie over welke optredens zijn ingepland op een bepaalde dag en de spelers die beschikbaar zijn op die dag.
- Etensinformatie: De informatie over catering, maaltijdvoorkeuren en dieëten van de spelers die bij een optreden aanwezig zijn.
- Evenement: Een gelegenheid van een opdrachtgever waar een optreden gegeven word.
- Gebruiker: Een alias voor zowel administratiemedewerker en gebruiker, dit om overbodige overbodige copy paste van use case paths te voorkomen.
- Honorarium: De vergoeding voor de spelers bij een optreden. Het honorarium is geclassificeerd in codes.
- Hotelinformatie: De informatie over overnachtingen op locatie bij optredens.
- Kantoormedewerker: De kantoormedewerkers van Close-Act vormen de kern van het bedrijf. Zij nemen de opdrachten aan en coördineren deze.
- Kostuumoverzicht: Een overzicht van de kostuums en de evenementen waaroop ze zijn ingepland.
- Maandoverzicht: Een overzicht van de dagen en data van een maand, waar ook optredens ook per dag staan aangegeven.
- Opdrachtgever: De partij welke een evenement organiseert waar
- Optie: Een Optie is een optreden waarvoor wel een offerte is uitgegaan, maar die nog niet bevestigd is.
- Optreden: Een optreden in het systeem is een definitief optreden dan wel een optie.
- Optreden informatie: Informatie over het optreden zoals de speldatum, reisdatum en hotel informatie
- Speler: De spelers zijn ZZP'ers die door Close-Act per optreden worden ingehuurd. Zij zijn de mensen die daadwerkelijk de klus uitvoeren.
- Spelerinformatie: Informatie over een speler zoals zijn naam, rekeningnummer e-mailadres en rol
- Spelerplanner: Het overzicht van spelers die beschikbaar zijn op bepaalde dagen.
- Systeem: Het te bouwen systeem dat de informatie van Close-Act gaat bevatten.
- Transportinformatie: Hoe de materialen en kostuums bij een optreden bezorgd worden.
- Vertrekinformatie: De informatie over de reis naar de locatie waar het optreden gegeven wordt, en hoe men daar moet komen.
Appendix
Business Process Models
Het huidige proces van een optreden aanvraag wordt gemodelleerd door het volgende procesmodel.
Een textuele beschrijving van het proces is als volgt:
Een opdracht komt binnen, daarna wordt er een offerte gemaakt en een optie geplaatst, nu bevindt het bolletje zich in de place "optie geplaatst".
Hier kun je vervolgens kiezen tussen 3 dingen: kostuums plannen, spelers plannen of overige dingen aanpassen. Na een keuze gemaakt te hebben heb je voor elke mogelijkheid de nieuwe keuze om verder te gaan met aanpassingen te maken of om het contract op te sturen. Als je door gaat met aanpassingen maken ben je weer terug op place "optie geplaatst".
Na het contract verstuurd is kan het geaccepteerd en geweigerd worden, als het contract geweigerd is kan worden gekozen om de samenwerking te beëindigen of om de optie verder te wijzigen. Als het contract geaccepteerd is wordt de definitieve speelinformatie verstuurd en de optie afgehandeld.
Syntax: http://woped.org/index.php?id=7
