Requirements Engineering/het werk/werkstuk/2010-11/Groep 01 (Controlegroep)

 

Groep 01

Werkstuk Requirements Engineering

Joeri Arendsen, Patrick Schileffski, Liset Meijerman, Christiaan Hillen, Stan Philipsen

Onderwijsinstituut voor Informatica en Informatiekunde

Radboud Universiteit Nijmegen

---

version 18 februari 2022

---

Subpagina's interviews presentatie to do UC7 voortgang

Patrick Schileffski Liset Meijerman Christiaan Hillen Joeri Arendsen

Introduction

Doelstelling voor deze fase: Preliminary version --> Complete

Aanwijzing

There is not much I say here about the Introduction. The main point I want to make is that the introduction of a report like the one you are producing has a clear functionality: to set the scene and provide a clear context for what follows. This means that it matters what the audience for the report is, what they want, and what they already know or do not know. Be relevant. To be blunt about it: actual bla bla will not be tolerated. An introduction is not just a header with some semi-random entertaining text underneath it. But on the other hand do not leave out essential stuff that belongs in a requirements document even if everybody involves already knows it. So be both relevant and complete. This is sometimes hard, but nobody ever told you it was going to be easy.

Close act is een theatergroep die reist van festival tot festival en van land tot land. Hierbij is een goede planning essentieel. De artiesten moeten op de juiste plaats en tijd aankomen, daarnaast moeten de rekwisieten soms weken van te voren verzonden worden als Close Act wordt gevraagd om in het buitenland op te treden.

Tot op heden gebruikt Close act als planning een agenda in Outlook, meerdere overzichten in Excel (creatief omgetovert naar Gantt-diagrammen) en het geheugen van de kantoormedewerkers. Door de planning op deze manier vorm te geven is de foutgevoeligheid hoog en het hele proces erg tijdrovend. Met het systeem zoals hieronder is beschreven willen we de foutgevoeligheid verminderen en het maken van (en het werken met) de planning minder tijdrovend maken.

We willen de agenda en de planning voor zowel acteurs als rekwisieten makkelijk bereikbaar maken in het systeem. Hiervoor bestaat het systeem uit meerdere onderelen, waardoor alles voor medewerkers makkelijk te vinden is. Hiervoor moet er wel een accesscontrol voor worden geimplementeerd, zodanig dat medewerkers die niets te zoeken hebben in een onderdeel van het systeem hier ook niet bij kunnen.

Problem statement

Doelstelling voor deze fase: As good as possible --> Complete

Aanwijzing

This is the WHY bit of the case project, put in a somewhat negative form: what is "wrong"? What should change? As holds for all items: do not hesitate or forget to update this section as the project progresses. Wat is het probleem dat opgelost wordt? 4 á 5 zinnen Wat is de aanleiding voor het nieuwe systeem? bv. wat kan met het nieuwe systeem worden bezuinigd Wat als het systeem niet wordt ontwikkeld? (Waarom is überhaupt een computersysteem nodig?) Patrick Schileffski → Requirements Engineering Remove this comment when resolved!

1. Wat is het probleem dat opgelost wordt?
   • De administratie is te arbeidsintensief.
   • De administratie is te foutgevoelig.
2. Welke factor maakt dit systeem nodig?
   • De aanleiding: De foutgevoeligheid en arbeidsintensiviteit van de processen. Verder de afhankelijkheid van de kennis van bepaalde administratiemedewerkers.
3. Wat als het systeem niet wordt ontwikkeld?
   • Dan gaat men door op de huidige manier.

Case analysis

Stakeholder list/analysis

Doelstelling voor deze fase: As good as possible --> Complete

Aanwijzing

This includes items like "user demography" (what types of stakeholders (roles played) do you encounter in this case, and "stakeholder list" (actual, named stakeholders, i.e. specific people and the role(s) they play.). If there are only few stakeholders, that's fine; just provide a clear-cut and relevant listing and description of the stakeholders (users and other relevant stakeholders!). Simpel lijst met alle belanghebbenden (bv. medewerkers van het bedrijf, klanten, leveranciers, partners, investeerders e.d.) Vuistregel: Wie zou er een week aan besteden om eraan mee te werken, dat het systeem goed werkt? Tweede lijst met alle gebruikers. Patrick Schileffski → Requirements Engineering Remove this comment when resolved!

De belanghebbenden zijn

1. De administratiemedewerkers
2. De artiesten
3. De inpakkers
4. De klanten

Mission-Vision-(Values)

Doelstelling voor deze fase: Complete

Aanwijzing

This is a difficult section. It isn’t even all that important, but I want you to have a serious go at it anyway. The information captured in it mostly comes from what [K&G] call the Chief Executive Sponsor (in the case study, that’s probably me), but you should help him/her formulate it and at the very least you should somehow show you really understand it. As to the (often misunderstood) differences between the three items [K&G p56]: Mission— What the project will do (close to WHY) Vision— What the end product will be (close to WHAT) Value— What principles will guide the project members while they do what they will do and build what will be; the main rules of the game played. In particular the "values" are almost impossible to make sense of in the limited context of our course and case study. I am therefore willing to reduce the item to "Mission and Vision".

1. Mission - What the project will do (close to WHY)
   • Het project zal de wensen en de beperkingen van de organisatie inventariseren en omzetten in een systeemmodel.
   • Het project zal de administratie van Close Act minder foutgevoelig en arbeidsintensief maken.
   • Het project zal de administratie van Close Act voor alle medewerkers overzichtelijk en bruikbaar maken.
2. Vision - What the end product will be (close to WHAT)
   • Een computersysteem dat de bewaking van restricties uit handen neemt en de medewerkers ondersteunt in het plannen en uitvoeren van opdrachten.
3. Value - What principles will guide the project members while they do what
   • Gebruiksvriendelijkheid
     1. Overzichtelijkheid
     2. Meedenkend systeem -> voorstel geven bij veranderingen
     3. Bewaking restricties

Statement of Work

Doelstelling voor deze fase: Complete, and up-to-date

Aanwijzing

This is a tricky bit to include in the final deliverable, because the SoW changes as the project progresses, and is really obsolete once the project finishes. It is, in other words, a project management item. Try to seriously create a work estimation and planning, also for your own sake, but to be honest a Statement of Work is not a very realistic item in our setting and is of limited importance. Waaraan willen wij werken en hoe wordt de werk volbracht? Uit de SoW zou een contract tussen RE en klant kunnen onstaan. In principe is onze >>voortgangstabel<< het SoW. Ik ga ze daarom ook (voorlopig) hier linken. Patrick Schileffski → Requirements Engineering Remove this comment when resolved!

Deliverable	DeliverbleType	Façade	Filled	Focused	Comment
Deadlines:		1 april	13 mei	10 juni
Introduction	Contextual	Preliminary version	Preliminary version	Complete	Keep it short at first, only a sketch; nice, clear and complete at the end.
Status:					-
Problem statement	Key deliverable	As good as possible	As good as possible	Complete
Status:
Stakeholder list/analysis	Contextual	As good as possible	As good as possible	Complete
Status:					-
Mission-Vision-(Values)	Contextual	Complete	Complete	Complete
Status:					-
Statement of Work	Contextual	Complete, and up-to-date	Complete, and up-to-date	Complete, and up-to-date
Status:					-
Risk Analysis	Contextual	Complete, and up-to-date	Complete, and up-to-date	Complete, and up-to-date
Status:					-
Use Case Survey	Key deliverable	As good as possible	Nearly complete	Complete
Status:					-
Integrated UC Diagram	Key deliverable	Complete (though preliminary)	Complete	Complete	One for whole project
Status:					-
Use Cases	Key deliverable	Not yet!	"Filled" level	Complete
Status:					-
Scenarios	Key deliverable	Not yet!	Several for each UC	Complete ("focused" level)
Status:					-
Domain Models	Key deliverable	Not yet!	Partially complete	Complete	One for each UC
Status:					-
Business rules per UC	Key Deliverable	Not yet!	Partially complete	Complete
Status:					-
Integrated Domain Model	Key deliverable	Not yet!	First draft	Complete	One for whole project
Status:					-
Busines Rules Catalogue	Key deliverable	Not yet!	Partially complete	Complete
Status:					-
Non-functional Requirements	Key deliverable	Notes	Partially complete	Complete
Status:					-
Terminological Definitions	Key deliverable	Notes	Partially complete	Complete
Status:					-
Executive sponsor viewpoint	Implicit deliverable	Complete	Complete	Complete	Integrated in M-V-(V)!
Status:					-
Use case tests	Implicit deliverable	Notes	As good as possible	Complete	Integrated in scenarios; to be done, but not written down explicitly as a separate item
Status:		Volgens ons nog n.v.t			-
Busienss process definitions	Optional appendix	If available / relevant	If relevant	If relevant	Use existing definitions/models or make them yourself: optional!
Status:					-
GUI metaphors / storyboards	Optional appendix	If relevant	If relevant	If relevant
Status:					-

Risk Analysis

Doelstelling voor deze fase: Complete, and up-to-date

Aanwijzing

For this, pretty much the same holds as for Statement of Work. Try to seriously describe some risks involved in your project without spending too much time on this. Note that this Risk Analysis is purely about project risks: risks that you do not make my demands within this case project. So it is not about risks inherent in the system that eventually may be delivered. Hier gaat het dus alleen over problemen die tijdens de ontwikkeling kunnen optreden en NIET om problemen die het nieuwe systeem zou kunnen veroorzaken. Patrick Schileffski → Requirements Engineering Remove this comment when resolved!

#	Category	Risk	Solution needed by	Status	Days lost	Expectancy factor	Risk factor
01	Werkwijze	We stellen vanwege de iteratieve werkwijze te veel uit.	on event	actief	7 d.	5%	0,35 d.
02	Werkwijze	We raken verloren in de details	on event	actief	7 d.	20%	1,4 d.
Totaal							1,75 d.

Requirements

Use Case Survey

Doelstelling voor deze fase: As good as possible --> Nearly complete --> Complete

Aanwijzing

oppervlakkige lijst met use-cases niet te gedetaileerd -> iteratief! Naam - Beschrijving met een á twee zinnen - rollennaam van acteur Wat is het verschil tussen role names en user titles? (p. 74, puntje 3) Patrick Schileffski → Requirements Engineering Remove this comment when resolved! Het verschil zit in de verwijzing. Een user title verwijst naar één persoon, het is dus en naam die naar een user verwijst. Een role name hoeft niet verbonden te zijn aan één peresoon, het is meer en rol dat een user kan vervullen. Een user kan dan ook meerdere rollen vervullen, maar heeft maar één titel. Deze onderscheiding moet nog bevestigd worden. Joeri Arendsen → Patrick Schileffski Remove this comment when resolved! Focus op input en output (blackbox) Patrick Schileffski → Requirements Engineering Remove this comment when resolved!

#	Name	Description	Initiating actor
01	Act inplannen	Een act wordt door een administratiemedewerker ingepland.	Administratiemedewerker
01a	Actgegevens veranderen	Een act wordt door een administratiemedewerker veranderd.	Administratiemedewerker
01b	Actgegevens verwijderen	Een act wordt door een administratiemedewerker verwijderd (omdat die niet meer plaats zal vinden).	Administratiemedewerker
02	Beschikbaarheid artiest	Artiesten kunnen hun beschikbaarheid in het systeem wijzigen	Artiest
03	Contract aanmaken	Een administratiemedewerker kan een contract genereren.	Administratiemedewerker
04	Werkschema inzien	Een medewerker kan het werkschema inzien	Medewerker
05	Paklijst aanmaken	Een administratiemedewerker kan een paklijst genereren	Administratiemedewerker
06	Speelinfo inzien	Een medewerker kan de speelinfo van een artiest inzien.	Medewerker

Oude tabel
{

Integrated UC Diagram

Doelstelling voor deze fase: Complete (though preliminary) --> Complete

Aanwijzing
zie p. 84 Patrick Schileffski → Requirements Engineering Remove this comment when resolved!

Voor het geval, dat het diagram in jouw browser niet hier verschijnt, kun je het »hier«  vinden.

Use Cases

Doelstelling voor deze fase: Not yet! -->  "Filled" level --> Complete

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

Legenda Alternative Path

Legenda achter deze klep te vinden

{{ Achterliggende ideeën: Maak onderscheid tussen verschillende typen om later een standaard te kunnen maken. Identificeer gefuseerde typen. Probeer een universele notatie te genereren. Het opnemen van de informatie (door lezer) moet gemakkelijk en bij voorkeur snel gaan. Syntax: Ieder symbool heeft zijn bijbehorende nuances, maar zie hier de standaardvorm: Basic Course of Events Mutaties (Alternate path stappen) Basic Course of Events (loopback) Mutaties kunnen zijn: Natuurlijke taal Notatie Nummer 5. wordt vervangen met a. 5 = a. Regel b. wordt toegevoegd. +b. Nummer 8. van BCoE wordt overgeslagen. -8 * (* Opsommen van resterende BCoE heeft meestal de voorkeur.) Verschillende typen: Toevoegingen: (...) Use Case: VOORBEELD Basic course of events De klant neemt contact op met een administratiemedewerker. De administratiemedewerker vraagt de klant welke productie die wilt boeken en voor wanneer De klant geeft de gewenste productie en de datum De administratiemedewerker vraagt aan het systeem of op de gewenste datum de gewenste productie beschikbaar is en of er voldoende rekwisieten zijn Het systeem geeft aan dat de gewenste productie op de gewenste datum beschikbaar is en dat er voldoende rekwisieten beschikbaar zijn De administratiemedewerker geeft in het systeem aan dat op de betreffende datum de artiesten en rekwisieten voor deze klant moeten worden gereserveerd. Het systeem reserveert de artiesten en rekwisieten voor de gewenste datum. De administratiemedewerker bevestigt naar de klant dat de act gereserveerd is voor deze datum. Alternate paths (Expanded) BCoE: 1 tot en met 4. START Alternate path, Replacement: 5 = a. Het systeem geeft aan dat de datum niet beschikbaar is. START Additions: + b. De administratiemedewerker vraagt de klant naar een andere datum. LOOPBACK BcoE: 3 en verder. Alternate paths (Short) BCoE: 1 tot en met 4. 5 = a. Het systeem geeft aan dat de datum niet beschikbaar is. + b. De administratiemedewerker vraagt de klant naar een andere datum. BcoE: 3 en verder. }}

01

Use Case:	01 Act inplannen
Use case diagram
Description	Een act wordt door een administratiemedewerker ingepland.
Source	Stakeholder
Version	9 juni 2011
Basic course of events	De administratiemedewerker vraagt aan het systeem of op de gewenste tijdsspanne(n) de gewenste productie beschikbaar is en of er voldoende rekwisieten zijn Het systeem geeft aan dat de gewenste productie op de gewenste tijdsspanne(n) beschikbaar is en dat er voldoende rekwisieten beschikbaar zijn De administratiemedewerker geeft in het systeem aan dat op de betreffende tijdsspanne(n) de artiesten en rekwisieten voor act en deze klant moeten worden gereserveerd. Het systeem reserveert de artiesten en rekwisieten voor de gewenste tijdsspanne.
Alternate paths	BCoE: 1. 2 => a. Het systeem geeft aan dat de tijdsspanne niet beschikbaar is. BCoE: 1 tot en met 4.
Preconditions	De administratiemedewerker is ingelogd. Het is het systeem bekend welke artiesten welke producties kunnen uitvoeren. Het is het systeem bekend welke rekwisieten benodigd zijn bij iedere productie.
Postconditions	De tijdsspanne voor de act is gereseveerd. De rekwisieten en artiesten zijn ingepland.
Related business rules	001 Alleen administratiemedewerkers van Close Act kunnen een act beheren 002 Rekwisieten en acteurs kunnen niet in dezelfde tijdspannen voor verschillende acts worden ingepland 003 Alleen medewerkers van Close Act en systeembeheer heben toegang tot het systeem 009 Een act kan slechts worden ingepland in een tijdspanne die minstens 14 dagen in de toekomst ligt

01a

Use Case:	01a Actgegevens veranderen
Use case diagram
Description	Een act wordt door een administratiemedewerker veranderd.
Source	Stakeholder
Version	9 juni 2011
Basic course of events	Administratiemedewerker zoekt in het systeem naar de act. Systeem toont informatie over de act. Administratiemedewerker voert in het systeem veranderingen in. Administratiemedewerker vraagt het systeem te controleren of deze verandering mogelijk is. Systeem bevestigt dat alle wensen realiseerbaar zijn. Administratiemedewerker slaat verandering definitief in het systeem op.
Alternate paths	Beschrijving: act kan niet op nieuw gekozen datum x plaatsvinden. BCoE: 1 tot en met 4. 5 = a. Systeem geeft aan dat de act op die tijdsspanne niet realiseerbaar is. +b. Administratiemedewerker zoekt met behulp van het systeem naar alternatieve tijdsspannen. +c. Het systeem toont de alternatieve tijdsspannen waarop de act zou kunnen plaatsvinden. +d. Administratiemedewerker kiest een alternatief en slaat verandering definitief op in het systeem. Beschrijving: nieuw gekozen productie is niet mogelijk voor de act. BCoE: 1 tot en met 4. 5 = a. Systeem geeft aan dat productie x in de act niet realiseerbaar is. +b. Administratiemedewerker zoekt met behulp van het systeem naar alternatieve producties. +c. Het systeem toont de alternatieve producties die zouden kunnen worden uitgevoerd in de act. +d. Administratiemedewerker kiest een alternatief en slaat verandering definitief op in het systeem. Beschrijving: nieuw gekozen artiest is niet beschikbaar voor de act. BCoE: 1 tot en met 4. 5 = a. Systeem geeft aan dat de act met artiest x niet realiseerbaar is. +b. Administratiemedewerker zoekt met behulp van het systeem naar alternatieve geschikte artiesten. +c. Het systeem toont de alternatieve artiesten die zouden kunnen deelnemen aan de act. +d. Administratiemedewerker kiest een alternatief en slaat verandering definitief op in het systeem.
Preconditions	Klant heeft een reservering voor een act geplaatst Act werd van tevoren in het systeem ingevoerd.
Postconditions	Alle mogelijke veranderingswensen zijn opgeslagen. Alle veranderingen in de spelers- en kostuumplanning zijn uitgevoerd.
Related business rules	001 Alleen administratiemedewerkers van Close Act kunnen een act beheren 003 Alleen medewerkers van Close Act en systeembeheer heben toegang tot het systeem 010 Wijzigingen in acts kunnen alleen gemaakt worden in overleg met de klant 013 Pas als een wijziging door het systeem is geaccepteerd en geregistreerd is deze definitief doorgevoerd

01b

Use Case:	01b Actgegevens verwijderen
Use case diagram
Description	Een act wordt verwijderd
Source	Stakeholder (spoedbetaling verhaal)
Version	10 juni 2011
Basic course of events	Administratiemedewerker zoekt in het systeem naar de act. Systeem toont informatie over de act. Administratiemedewerker geeft in het systeem aan dat de act geannuleerd zal worden en geeft in het systeem de reden voor de annulering aan. Het systeem toont eventuele annuleringskosten en vraagt om bevestiging. Administratiemedewerker bevestigt de annulering in het systeem. Systeem bevestigt annulering en voert alle nodige veranderingen in de spelers-/kostuumplanning door. Systeem deelt financiële afdeling mee dat de betreffende klant de van tevoren besproken annuleringskosten moet betalen.
Alternate paths	Beschrijving: annuleringskosten aanpassen. BCoE: 1 tot en met 4. 5 = a. Administratiemedewerker geeft aan de annuleringskosten te willen wijzigen. +b. Systeem toont berekening van huidige annuleringskosten en maakt dit bewerkbaar. +c. Administratiemedewerker wijzigt de annuleringskosten. BCoE: 4 tot en met 7. (11 stappen)
Preconditions	Act is eerder ingevoerd in het systeem.
Postconditions	Financiele afdeling weet dat er annuleringskosten verwacht worden. Geannuleerde spelers/kostuums staan weer in de planning ter beschikking.
Related business rules	001 Alleen administratiemedewerkers van Close Act kunnen een act beheren 003 Alleen medewerkers van Close Act en systeembeheer heben toegang tot het systeem 004 Bij het annuleren van een act is het mogelijk dat er annuleringskosten in rekening worden gebracht 006 Indien een klant te boek staat als "slechte betaler" vindt vertrek pas plaats indien 100% van het beschuldigde bedrag is voldaan 013 Pas als een wijziging door het systeem is geaccepteerd en geregistreerd is deze definitief doorgevoerd

02

Use Case:	2. Artiestbeschikbaarheid
Use case diagram
Description	Wijziging van beschikbaarheid door een medewerker
Source	Stakeholder
Version	10 juni 2011
Basic course of events	De artiest navigeert naar de beschikbaarheidspagina De artiest geeft aan wanneer hij niet beschikbaar is Het systeem bevestigt de invoer van de artiest De artiest bevestigt de uitvoer van het systeem Het systeem slaat de beschikbaarheid op
Alternate paths	PRECONDITIE: Als er al een act gepland is op datum x: BCoE: 1 tot en met 2. 3 = a. Het systeem geeft aan dat de artiest al is ingepland een tijdsspanne voor een act. +b. Het systeem vraagt de artiest of hij wil doorzetten en het systeem moet kijken of er alternatieve artiesten beschikbaar zijn. +c. De artiest bevestigt zijn keuze +d. Het systeem meldt dat er andere artiest(en) beschikbaar zijn en vraagt of dit als voorstel mag worden verzonden naar de administratiemedewerker. +e. De artiest bevestigt zijn keuze +f. Systeem genereert verslag van event en verwittigt administratiemedewerker. +g. Administratiemedewerker accepteert de voorgestelde wijziging. +h. De artiest wordt ingelicht door het systeem. +i. De alternatieve artiest wordt ingelicht door het systeem. END. (11 stappen) BCoE: 1 tot en met 2. Alternatepath events: a tot en met f. g = A. Administratiemedeweker verwerpt de voorgestelde wijziging en geeft reden aan in systeem. +B. De artiest wordt ingelicht door het systeem dat de wijziging niet is geaccepteerd en geeft de opgegeven reden aan. END. (10 stappen)
Preconditions	De artiest is geauthenticeerd
Postconditions	De beschikbaarheid van de artiest is aangepast in het systeem De artiesten zijn op de hoogte van de nieuwe plannen.
Related business rules	002 Rekwisieten en acteurs kunnen niet in dezelfde tijdspannen voor verschillende acts worden ingepland 003 Alleen medewerkers van Close Act en systeembeheer heben toegang tot het systeem 011 Artiesten moeten hun beschikbaarheid voor een tijdspanne minimaal 1 maand vantevoren aangeven 013 Pas als een wijziging door het systeem is geaccepteerd en geregistreerd is deze definitief doorgevoerd

03

Use Case:	03. Contract aanmaken
Use case diagram
Description	Een administratiemedewerker kan een contract genereren.
Source	Stakeholder
Version	10 juni 2011
Basic course of events	De administratiemedewerker navigeert naar de act waarvoor het contract moet worden aangemaakt. Het systeem vraagt de gegevens die nog niet bekend zijn in te vullen De administratiemedewerker vult de gevraagde gegevens in. Het systeem genereert het contract en vraagt of het opgeslagen moet worden. De administratiemedewerker geeft aan het contract op te slaan.
Alternate paths
Preconditions	De Administratiemedewerker is geauthenticeerd
Postconditions	Het contract is gegenereerd en opgeslagen
Related business rules	003 Alleen medewerkers van Close Act en systeembeheer heben toegang tot het systeem 007 Contracten dienen tot 7 jaar na dagtekening te worden opgeslagen 008 Indien een factuur 14 dagen voorgaande aan de tijdspanne van de act waartoe de factuur behoord nog niet is voldaan geeft het systeem een waarschuwing

04

Use Case:	04. Werkschema inzien
Use case diagram
Description	Een medewerker kan een werkschema inzien.
Source	Stakeholder
Version	10 juni 2011
Basic course of events	De medewerker kiest een werkschema. Het systeem toont het gekozen werkschema.
Alternate paths	BCoE: 1 tot en met 2 + a. De medewerker verzoekt het systeem tot printen van het werkschema. + b. Het systeem drukt het schema af.
Preconditions	Gebruiker is geauthenticeerd.
Related business rules	003 Alleen medewerkers van Close Act en systeembeheer heben toegang tot het systeem 012 Documenten worden voor administratieve doelen opgeslagen

05

Use Case:	05 Paklijst aanmaken
Use case diagram
Description	Het genereren van paklijst voor een act.
Source	Niels
Version	10 juni 2011
Basic course of events	Administratiemedewerker selecteert een act in het systeem. Het systeem vraagt naar de reden van selectie. Administratiemedewerker verzoekt het systeem tot het genereren van een paklijst. Het systeem toont de paklijst en vraagt om bevestiging. Administratiemedewerker bevestigt de paklijst. Administratiemedewerker verzoekt het systeem de paklijst te printen. Het systeem print de paklijst.
Alternate paths	BCoE: 1 tot en met 4. 5 = a. De administratiemedewerker bevestigt de paklijst en exporteert de paklijst als PDF. 6 = b. Het systeem exporteert de paklijst op als PDF.
Preconditions	Act is gepland: locatie, tijdsspanne(n), artiesten en materialen zijn bekend.
Related Business Rules	003 Alleen medewerkers van Close Act en systeembeheer heben toegang tot het systeem 012 Documenten worden voor administratieve doelen opgeslagen 014 Een paklijst kan slechts worden aangemaakt voor een act waarvan de tijdspanne in de toekomst ligt

06

Use Case:	Speelinfo inzien
Use case diagram
Description	De speelinfo van acteurs die meedoen met een act wordt ingezien door een medewerker.
Source	Stakeholder
Version	10 juni 2011
Basic course of events	Medewerker verzoekt het systeem de speelinfo van een act te tonen. Systeem toont de speelinfo van de gewenste act.
Alternate paths	BCoE: 1tot en met 2. +a. Medewerker verzoekt het systeem deze speelinfo te printen +b. Het systeem print deze speelinfo
Preconditions	Act waarvoor de speelinfo worden ingezien is ingepland
Postconditions
Related business rules	003 Alleen medewerkers van Close Act en systeembeheer hebben toegang tot het systeem

Scenarios

Doelstelling voor deze fase: Not yet! --> Several for each UC --> Complete

Aanwijzing

Scenarios are concrete, instance-level descriptions of how a use case works. Scenarios are mostly related to the BCoEs of use cases. A separate scenario has to cover each alternative path and exception path of a BCoE. So there will usually be various scenarios underlying one use case (n:1). Use these to test the various possible paths that a use case may take (tests are not explicit deliverables, but this does not mean you do not have to perform them! They are an important means of guaranteeing the quality of your use cases.) If possible, do try and keep similarities visible between the structure of the BCoE/Alt Paths/Exc Paths and the structure of their matching scenarios. Also keep terminology/concepts consistent across use cases and scenarios. If you use a fact-based approach to requirements engineering (i.e. looking at the instance level first), you may actually get some scenarios before you get use cases. Mostly, however, you will come up with scenarios afterwards. Note that for ORM- style domain models, which you should include for each scenario, their populations should be in line with the scenarios, since these both concern instances.

1 Act inplannen scenario 1:

1. Mevrouw Jansen vraagt aan het systeem of de Saurusproductie op 15-05-2011 tussen 14:00 en 16:00 uur beschikbaar is en of er voldoende rekwisieten beschikbaar zijn.
2. Het systeem bevestigt dat de Saurusproductie op 15-05-2011 tussen 14:00 en 16:00 uur beschikbaar is en dat er voldoende rekwisieten beschikbaar zijn.
3. Mevrouw Jansen geeft aan dat Cornoelje, Piet en Jan en de rekwisieten voor de Saurusact op 15-05-2011 tussen 14:00 en 16:00 uur gereserveerd moeten worden voor meneer Hendriks.
4. Het systeem reserveert de rekwisieten en de artiesten voor de Saurusact op 15-5-2011 tussen 14:00 en 16:00 uur voor Meneer Hendriks.

1 Act inplannen scenario 2:

1. Mevrouw Jansen vraagt aan het systeem of op 15-05-2011 tussen 14:00 en 16:00 uur de Saurusproductie beschikbaar is en of er voldoende rekwisieten beschikbaar zijn.
2. Het systeem geeft aan dat de Saurusproductie op 15-05-2011 tussen 14:00 en 16:00 uur niet beschikbaar is.
3. Mevrouw Jansen vraagt aan het systeem of de Saurusproductie op 21-05-2011 tussen 14:00 en 16:00 uur ingepland kan worden.
4. Het systeem bevestigt dat de Saurusproductie op 21-05-2011 tussen 14:00 en 16:00 uur beschikbaar is.
5. Mevrouw Jansen geeft aan dat Cornoelje, Piet en Jan en de rekwisieten voor de Saurusact op 21-05-2011 tussen 14:00 en 16:00 uur gereserveerd moeten worden voor meneer Hendriks.
6. Het systeem reserveert de rekwisieten en de artiesten voor de Saurusact op 21-5-2011 tussen 14:00 en 16:00 uur voor Meneer Hendriks.

1a Actgegevens veranderen scenario 1:

1. Mevrouw Jansen zoekt in het systeem naar de Saurusact van 15-05-2011 tussen 14:00 en 16:00 uur op de Kerstraat 12 in Eindhoven.
2. Het systeem toon de gegevens van de Saurusact van 15-05-2011 tussen 14:00 en 16:00 uur op de Kerstraat 12 in Eindhoven.
3. Mevrouw Jansen geeft aan dat de Saurusact veranderd moet worden en voert in dat de Saurusact 2 saurussen nodig heeft in plaats van 3 saurussen.
4. Mevrouw Jansen vraagt het systeem deze veranderingen te controleren op correctheid.
5. Het systeem bevestigt de veranderingen en vraagt of de wijzigingen opgeslagen moeten worden.
6. Mevrouw Jansen slaat de veranderingen op in het systeem.

1a Actgegevens veranderen scenario 2:

1. Mevrouw Jansen zoekt in het systeem naar de Saurusact van 15-05-2011 tussen 14:00 en 16:00 uur op de Kerstraat 12 in Eindhoven.
2. Het systeem toont de gegevens van de Saurusact van 15-05-2011 tussen 14:00 en 16:00 uur op de Kerstraat 12 in Eindhoven.
3. Mevrouw Jansen geeft aan dat de Saurusact veranderd moet worden en voert in dat er 4 saurussen nodig zijn in plaats van 3 saurussen.
4. Mevrouw Jansen vraagt aan het systeem om de veranderingen te controleren op correctheid.
5. Het systeem bevestigt de veranderingen niet.
6. Mevrouw Jansen vraagt aan het systeem of er alternatieven zijn.
7. Het systeem geeft het alternatief: de Alienproductie.
8. Mevrouw Jansen bevestigt het alternatief: een Alienact, en slaat de veranderingen op in het systeem.

1a Actgegevens veranderen scenario 3:

1. Mevrouw Jansen zoekt in het systeem naar de Saurusact van 15-05-2011 tussen 14:00 en 16:00 uur op de Kerstraat 12 in Eindhoven.
2. Het systeem toont de gegevens van de Saurusact van 15-05-2011 tussen 14:00 en 16:00 uur op de Kerstraat 12 in Eindhoven.
3. Mevrouw Jansen geeft aan dat de Saurusact veranderd moet worden en voert in dat er 4 saurussen nodig zijn in plaats van 3 saurussen.
4. Mevrouw Jansen vraagt aan het systeem om de veranderingen te controleren op correctheid.
5. Het systeem bevestigt de veranderingen niet.
6. Mevrouw Jansen vraagt aan het systeem of er alternatieven zijn.
7. Het systeem geeft het alternatief: 13-6-2011 tussen 14:00 en 16:00 uur.
8. Mevrouw Jansen bevestigt het alternatief 13-6-2011 tussen 14:00 en 16:00 uur en slaat de wijzigingen op.

1a Actgegevens veranderen scenario 4:

1. Mevrouw Jansen zoekt in het systeem de Saurusact van 15-05-2011 tussen 14:00 en 16:00 uur op de Kerstraat 12 in Eindhoven
2. Het systeem toon de gegevens van de Saurusact van 15-05-2011 tussen 14:00 en 16:00 uur op de Kerstraat 12 in Eindhoven
3. Mevrouw Jansen geeft aan dat de Saurusact veranderd moet worden en voert in dat de Saurusact 2 saurussen nodig heeft in plaats van 3 saurussen.
4. Mevrouw Jansen vraagt het systeem deze veranderingen te controleren op correctheid.
5. Het systeem bevestigt de veranderingen niet.
6. Mevrouw Jansen vraagt aan het systeem of er alternatieven zijn.
7. Het systeem geeft aan dat Cornoelje beschikbaar is.
8. Mevrouw Jansen bevestigt het alternatief Cornoelje en slaat de wijzigingen op.

1b Actgegevens verwijderen scenario 1:

1. Mevrouw Jansen zoekt in het systeem de Saurusact van 15-05-2011 tussen 14:00 en 16:00 uur op de Kerstraat 12 in Eindhoven
2. Het systeem toont de gegevens van de Saurusact van 15-05-2011 tussen 14:00 en 16:00 uur op de Kerstraat 12 in Eindhoven
3. Mevrouw Jansen geeft aan dat deze Saurusact geannuleerd moet worden en geeft de reden van annulering: meneer Grootjens kon niet genoeg sponsors verzamelen.
4. Het systeem toont dat de annuleringskosten 20 euro bedragen en vraagt om bevestiging.
5. Mevrouw Jansen bevestigt de annulering in het systeem.
6. Het systeem voert in de spelersinfo door dat Cornoelje en Piet op 15-05-2011 tussen 14:00 en 16:00 uur beschikbaar zijn en dat de rekwisieten van de Saurusact op 15-05-2011 tussen 14:00 en 16:00 uur beschikbaar zijn.
7. Het systeem deelt de financiële afdeling mee dat meneer Grootjens de annuleringskosten van 20 euro moet betalen.

1b Actgegevens verwijderen scenario 2:

1. Mevrouw Jansen zoekt in het systeem de Saurusact van 15-05-2011 tussen 14:00 en 16:00 uur op de Kerstraat 12 in Eindhoven
2. Het systeem toont de gegevens van de Saurusact van 15-05-2011 tussen 14:00 en 16:00 uur op de Kerstraat 12 in Eindhoven
3. Mevrouw Jansen geeft aan dat de Saurusact op 15-05-2011 tussen 14:00 en 16:00 uur geannuleerd moet worden en geeft als reden dat meneer Grootjens niet genoeg sponsors kon verzamelen.
4. Het systeem toont annuleringskosten van 20 euro en vraagt om bevestiging van de annulering op 15-05-2011 tussen 14:00 en 16:00 uur.
5. Mevrouw Jansen bevestigt de annulering niet en geeft aan dat ze de annuleringskosten wilt wijzigen.
6. Het systeem toont de berekening van de huidige annuleringskosten en maakt dit bewerkbaar.
7. Mevrouw Jansen geeft aan dat de annuleringskosten van 20 euro naar 10 euro veranderd moet worden.
8. Het systeem voert de verandering in en vraagt om bevestiging.
9. Mevrouw Jansen bevestigt de annulering in het systeem.
10. Het systeem voert in de spelersinfo door dat Cornoelje en Piet op 15-05-2011 tussen 14:00 en 16:00 uur beschikbaar zijn en dat de rekwisieten van de Saurusact op 15-05-2011 tussen 14:00 en 16:00 uur beschikbaar zijn.
11. Het systeem deelt de financiële afdeling mee dat meneer Grootjens 10 euro aan annuleringskosten moet betalen.

2 Artiestbeschikbaarheid scenario 1:

1. Cornoelje navigeert in het systeem naar de beschikbaarheidspagina.
2. Cornoelje geeft aan dat hij op 16-06-2011 tussen 14:00 en 16:00 uur niet beschikbaar is.
3. Het systeem bevestigt dat Cornoelje op 16-06-2011 tussen 14:00 en 16:00 uur niet beschikbaar is en verandert de beschikbaarheidspagina.
4. Cornoelje bevestigt de verandering van de beschikbaarheidspagina.
5. Het systeem slaat de beschikbaarheidspagina op.

2 Artiestbeschikbaarheid scenario 2:

1. Cornoelje navigeert in het systeem naar de beschikbaarheidspagina.
2. Cornoelje geeft aan dat hij op 16-06-2011 tussen 14:00 en 16:00 uur niet beschikbaar is.
3. Het systeem geeft aan dat de artiest is ingepland op 16-06-2011 tussen 14:00 en 16:00 uur.
4. Het systeem vraagt of Cornoelje wil doorzetten en het systeem naar alternatieve beschikbare artiesten zal kijken.
5. Cornoelje bevestigt.
6. Het systeem meldt dat Piet beschikbaar is en vraagt of er een mailtje naar mevrouw Jansen verstuurd moet worden met het voorstel dat Piet invalt voor Cornoelje.
7. Cornoelje bevestigt.
8. Het systeem verstuurt een bericht naar mevrouw Jansen met het voorstel.
9. Mevrouw Jansen accepteert de voorgestelde wijziging.
10. Het systeem stuurt een bericht naar Cornoelje dat de wijziging is aangenomen.
11. Het systeem stuurt een bericht naar Piet dat hij 16-06-2011 tussen 14:00 en 16:00 uur moet werken.

2 Artiestbeschikbaarheid scenario 3:

1. Cornoelje navigeert in het systeem naar de beschikbaarheidspagina.
2. Het systeem vraagt naar beschikbaarheid van de artiest.
3. Cornoelje geeft aan dat hij op 16-06-2011 tussen 14:00 en 16:00 uur niet beschikbaar is.
4. Het systeem geeft aan dat de artiest is ingepland op 16-06-2011 tussen 14:00 en 16:00 uur en vraagt of het naar alternatieve beschikbare artiesten zal kijken.
5. Cornoelje bevestigt.
6. Het systeem meldt dat Piet beschikbaar is en vraagt of er een mailtje naar mevrouw Jansen verstuurd moet worden met het voorstel dat Piet invalt voor Cornoelje.
7. Cornoelje bevestigt.
8. Het systeem verstuurt een bericht naar mevrouw Jansen met het voorstel.
9. Mevrouw Jansen verwerpt de voorgestelde wijziging.
10. Het systeem stuurt een bericht naar Cornoelje dat de wijziging is verworpen en adviseert om contact op te nemen met mevrouw Jansen.

3 Contract aanmaken scenario 1:

1. Mevrouw Jansen selecteert in het systeem de Saurusact die op 16-06-2011 zal plaatsvinden.
2. Het systeem toont de gegevens die ingevuld moeten worden: naam adres van de klant, de hoeveelheid artiesten, het adres waar het optreden plaatsvind.
3. Mevrouw Jansen vult de gegevens in.
4. Het systeem genereert het contract en vraagt of het contract moet worden opgeslagen.
5. Mevrouw Jansen bevestigt dat het contract moet worden opgeslagen.

4 Werkschema inzien scenario 1:

1. Cornoelje kiest in het systeem het werkschema van zichzelf.
2. Het systeem toont het gekozen werkschema.

4 Werkschema inzien scenario 2:

1. Cornoelje kiest in het systeem het werkschema van artiest Jan.
2. Het systeem toont het gekozen werkschema.

4 Werkschema inzien scenario 3:

1. Mevrouw Jansen kiest in het systeem het werkschema van Cornoelje.
2. Het systeem toont het gekozen werkschema.

4 Werkschema inzien scenario 4:

1. Cornoelje kiest in het systeem het werkschema van zichzelf.
2. Het systeem toont het gekozen werkschema.
3. Cornoelje verzoekt het systeem tot printen van het werkschema.
4. Het systeem print het werkschema van Cornoelje uit.

4 Werkschema inzien scenario 5:

1. Mevrouw Jansen kiest in het systeem het werkschema van Cornoelje.
2. Het systeem toont het gekozen werkschema.
3. Mevrouw Jansen verzoekt het systeem tot printen van het werkschema.
4. Het systeem print het werkschema van Cornoelje uit.

5 Paklijst aanmaken scenario 1:

1. Mevrouw Jansen navigeert in het systeem naar de gegevens van de Saurusact die op 16-06-2011 zal plaatsvinden.
2. Het systeem vraagt naar de reden van de navigatie.
3. Mevrouw Jansen verzoekt het systeem tot het genereren van een paklijst.
4. Het systeem toont de paklijst en vraagt om bevestiging.
5. Mevrouw Jansen bevestigt de paklijst.
6. Mevrouw Jansen verzoekt tot uitprinten van de Saurusact.
7. Het systeem print de paklijst uit.

5 Paklijst aanmaken scenario 2:

1. Mevrouw Jansen navigeert in het systeem naar de gegevens van de Saurusact die op 16-06-2011 zal plaatsvinden.
2. Het systeem vraagt naar de reden van de navigatie.
3. Mevrouw Jansen verzoekt het systeem tot het genereren van een paklijst.
4. Het systeem vraagt om een datum omdat er meerdere data voor de Saurusproductie zijn gereserveerd.
5. Mevrouw Jansen geeft 15-05-2011 op als datum.
6. Het systeem toont de paklijst en vraagt om bevestiging.
7. Mevrouw Jansen bevestigt de paklijst en verzoekt tot uitprinten.
8. Het systeem print de paklijst uit.

5 Paklijst aanmaken scenario 3:

1. Mevrouw Jansen navigeert in het systeem naar de gegevens van de Saurusact.
2. Het systeem vraagt naar de reden van de navigatie.
3. Mevrouw Jansen verzoekt het systeem tot het genereren van een paklijst.
4. Het systeem toont de paklijst en vraagt om bevestiging.
5. Mevrouw Jansen bevestigt de paklijst en verzoekt tot exporteren naar een PDF-bestand
6. Het systeem exporteert de paklijst naar een PDF-bestand.

6 speelinfo inzien scenario 1:

1. Cornoelje verzoekt het systeem de speelinfo van de Saurusact die op 16-06-2011 zal plaatsvinden, te tonen.
2. Het systeem toont de speelinfo.

6 speelinfo inzien scenario 2:

1. Cornoelje verzoekt het systeem de speelinfo van de Saurusact die op 16-06-2011 zal plaatsvinden, te tonen.
2. Het systeem toont de speelinfo.
3. Cornoelje verzoekt het systeem de speelinfo te printen.
4. Het systeem print de speelinfo uit.

6 speelinfo inzien scenario 5:

1. Mevrouw Jansen verzoekt het systeem de speelinfo van Jan te tonen.
2. Het systeem toont de speelinfo.
3. Mevrouw Jansen verzoekt het systeem de speelinfo te printen.
4. Het systeem print de speelinfo uit.

Legenda

• Cornoelje, Piet en Jan zijn artiesten.
• Meneer Hendriks is een klant.
• Mevrouw Jansen is een administratiemedewerker.
• Meneer Grootjens is een klant.

Domain Models

Doelstelling voor deze fase: Not yet! --> Partially complete --> Complete

Aanwijzing
The complete domain model should contain all concepts and facts that are used in the use cases and scenarios and should be completely consistent with how they are used in them.

DM01

Voor het geval, dat het diagram in jouw browser niet hier verschijnt, kun je het »hier«  vinden.

DM02/04

Voor het geval, dat het diagram in jouw browser niet hier verschijnt, kun je het »hier«  vinden.

DM03

Voor het geval, dat het diagram in jouw browser niet hier verschijnt, kun je het »hier«  vinden.

DM05

Voor het geval, dat het diagram in jouw browser niet hier verschijnt, kun je het »hier«  vinden.

DM06

Voor het geval, dat het diagram in jouw browser niet hier verschijnt, kun je het »hier«  vinden.

Business rules per UC

Doelstelling voor deze fase: Not yet! --> Partially complete --> Complete

Use case number	Associated business rules
01	001, 002, 003, 009
01a	001, 003, 010, 013
01b	001, 003, 004, 006, 013
02	002, 003, 011, 013
03	003, 007, 008
04	003, 012
05	003, 012, 014
06	003

Integrated Domain Model

Doelstelling voor deze fase: Not yet! --> First draft --> Complete

Voor het geval, dat het diagram in jouw browser niet hier verschijnt, kun je het »hier«  vinden.

Busines Rules Catalogue

Doelstelling voor deze fase: Not yet! --> Partially complete --> Complete

Aanwijzing

The business rule catalog as suggested by [K&G] is quite appropriate. You are, however, obliged to semi-formalize the business rules. With your background knowledge, it should be easy to do so, especially if you already have an ORM domain model. Also note that formalizing business rules is often required in other system development and management activities: see the Business Rules Manifesto (placed on the RE website). Interestingly, ORM is now one of the main techniques worldwide used to capture (formal) business rules, or at least the most basic, elementary rules in a domain. In general, our suggestion is you that keep to the type of business rules catalog suggested by [K&G, p60-2], but also Make sure the terms you use when formulating the actual rules are compatible with the relevant ORM domain models. Use clearly structured, unambiguous sentences language with clearly indicated logical or mathematical operators like AND, OR/XOR, IF, THEN, NOT, <,+,- , etc. Always also include a formulation in plain natural language Crucially, you only should include business rules explicitly related to some use case you describe. Also, as indicated, business rules may or may not have been explicitly formulated before your analysis started, but in principle, every organization works according to some rules. It is up to you to find and formulate them! Finally, please do not be confused by the "business" in "business rules". Perhaps a better, more general term would be: "domain rules". They describe in considerable detail what should and should not be done in the organization (the environment in which the system-to-be-built will function, and which it will support). For example, consider a library. A general rule could be: "items borrowed have to be returned within 21 days from the day on which they were lent out, unless within 21 days from being lent out the loan is extended by the person borrowing the extended". Next, there may be rules that define when extension is possible or not, and so on. Note that all meaningful concepts in the rule have to be included in the DM of the use case(s) to which this rule is relevant, and also that for the rule to be properly modeled as a business rule, some semi-formalization will be required. Creating a DM for the rule is a good way of starting semi-formalization.

Alleen regels die van toepassing zijn op het systeem vinden, niet op het gehele bedrijf.

Rule ID	Name	Description	Category	Static/Dynamic	Source
001	Actplanning	Alleen administratiemedewerkers van Close Act kunnen een act beheren	Action restriction	Static	Stakeholder
002	Dubbelboekingswaarborg	Rekwisieten en acteurs kunnen niet in dezelfde tijdspannen voor verschillende acts worden ingepland	Action restriction	Static	Stakeholder
003	Systeemtoegangsbeperking	Alleen medewerkers van Close Act en systeembeheer heben toegang tot het systeem	Action restriction	Static	Stakeholder
004	Annuleringskosten	Bij het annuleren van een act is het mogelijk dat er annuleringskosten in rekening worden gebracht	Action triggering	Static	Stakeholder
005	Annuleringsbeperking	Het is slechts mogelijk een act te annuleren tot 14 dagen voorgaande aan de tijdsspanne van de act.	Action restriction	Static	Stakeholder
006	Vooruitbetaling	Indien een klant te boek staat als "slechte betaler" vindt vertrek pas plaats indien 100% van het beschuldigde bedrag is voldaan	Action triggering	Static	Stakeholder
007	Bewaarverplichting	Contracten dienen tot 7 jaar na afloop van het contract te worden opgeslagen	Structural fact	Static	Overheid
008	Betalingssignalering	Indien een factuur 14 dagen voorgaande aan de tijdspanne van de act waartoe de factuur behoord nog niet is voldaan geeft het systeem een waarschuwing	Action triggering	Dynamic	Requirements Engineers
009	Inplanningsdeadline	Een act kan slechts worden ingepland in een tijdspanne die ten minste 14 dagen in de toekomst ligt	Action restriciton	Dynamic	Requirements Engineers
010	Wijzigingsafstemming	Wijzigingen in acts kunnen alleen gemaakt worden in overleg met de klant	Action restriction	Static	Stakeholder
011	Beschikbaarheidsopgave	Artiesten moeten hun beschikbaarheid voor een tijdspanne minimaal 1 maand vantevoren aangeven	Action restriction	Static	Stakeholder
012	Documentenopslag	Documenten worden voor administratieve doelen opgeslagen	Structural facts	Static	Requirements Engineers
013	Wijzigingsgeldigheid	Pas als een wijziging door het systeem is geaccepteerd en geregistreerd is deze definitief doorgevoerd	Structural facts	Static	Requirements Engineers
014	Paklijstgeneratie	Een paklijst kan slechts worden aangemaakt voor een act waarvan de tijdspanne in de toekomst ligt	Action restriction	Static	Requirements Engineers

Non-functional Requirements

Doelstelling voor deze fase: Notes --> Partially complete --> Complete

Aanwijzing

[K&G] claim that use cases are a good technique for capturing non-functional requirements. I do not agree. It might be possible to use use cases for non-functionals, but it seems to us a bit forced. Indeed, in the examples of non-functionals (the "- illities" etc.), [K&G] do themselves not use use cases. So the main advice here is: keep to the practices recommended in book when it come to non-functionals, but do not formulate them as use cases. You can find much more on non-functionals in the book.

1. Usability.
   • Het systeem moet gemakkelijk in gebruik te nemen en simpel bedienbaar zijn dat wil zeggen dat een onervaren administratiemedewerker binnen een week kan leren om met het systeem om te gaan en een artiest vrijwel direct.
2. Stroomlijning / data integriteit.
   • Als iets in de agenda/spelersplanning/kostuumplanning wordt veranderd/toegevoegd/verwijderd, moet deze wijziging, waar relevant, ook in de rest van het systeem doorgevoerd worden.
   • Waarschuwing geven als er een aanpassing gemaakt wordt. Er moet een waarschuwingsschermpje opkomen om te vertellen dat je gaat beginnen aan een aanpassing en of dat deze doorgevoerd moet worden in het hele systeem of dat de administratiemedewerker in 'alsof-modus' wilt blijven.
3. Authorization.
   • Artiesten kunnen gebruik maken van de voor hen bedoelde delen van het systeem.
   • De administratiemedewerkers kunnen bij alle delen van het systeem.
4. Snelheid om de klant zo goed mogelijk te woord te staan zonder dat er irritatie/wrijving ontstaat.
   • Zoekfunctie zodra de klant aan de lijn is waardoor een pagina opplopt met info over het komende project (waarvoor de klant belt) en een vorig project met ervaring hoe dat ging. Hier hoeft niet het hele klantprofiel op te ploppen omdat bij telefoongesprekken meestal alleen de projectgegevens en de "betalings-moreel" van belang zijn. In dit venster kan een link naar het hele profiel worden toegevoegd om nog meer informatie of klantgegevens te kunnen inzien.
   • Als een klant slecht betaalt, dan moet dit nadrukkelijk op het scherm getoond worden.

Addendum

Terminological Definitions / Domeinwoordenboek

Doelstelling voor deze fase: Notes --> Partially complete --> Complete

Aanwijzing

We expect all important terms in the use cases/domain models to be properly defined. ORM models do not define terms as such: they provide highly contextualized type- level descriptions of which terms occur, for example as "cats hate dogs". ORM diagrams say nothing about what "dog" or "cat" or "hate" mean as independent words. For this, terminological definitions are required. Together, these definitions can be called many things, e.g. dictionary, glossary, lexicon, vocabulary, ontology, terminology, and so on. We stick to the latter word: terminology. Our minimal expectation for the terminology in your requirements document is a list of key terms (preferably, all terms that also occur in your domain models) and clear and useful natural language definitions with them. You can use existing dictionary definitions if you like (please provide source references), but do be careful: standard dictionaries have many limitations and they may not describe the exact meaning of some term that the stakeholder actually means/uses in the UoD. Often, it is much safer to write your own definition that is specially aimed at the specific context you are working in. If necessary, get information form stakeholders. After all, both you and the stakeholders can be expected to know what they mean with a certain word; if not, work on it. Traditional term definitions have a simple format: a definiens (that which is defined), a genus (the "supertype" of what is defined), and one or more differentiae: what distinguishes the definiens from other subtypes of its supertype. So for example, a dog (definiens) is an animal (genus) that can bark (first differentium) and wags its tail a lot (second differentium). Please note that these relations could be expressed in an ORM like manner, but that would go too far since terms like bark, wag, tail etc. probably do not as such occur in the UoD. So simply keep to the traditional definition in natural language. In particular in the field of Business Rules Specification, there is a brand new initiative to find ways to better specify and communicate about the precise meaning of rules and terms. This initiative goes by the name SBVR: Semantics of Business Vocabulary and Rules. You could say it encompasses terminiological definitions, ORM, and rules. For a brief introduction to SBVR, see the SBVR-1 file on the RE website.

• Een act is een productie met een specifieke tijdspanne, een of meerdere acteurs en een volledig adres
• De administratie is het onderdeel van Close Act dat zich bezig houdt met het beheer van de financiële en andere gegevens, en de planning van kostuums, rekwisieten en medewerkers
• Een administratiemedewerker is een medewerker die taken van de administratie uitvoert.
• Alternatieve artiesten zijn potentiële artiesten die bij een betreffend act van een productie nog niet vast ingepland zijn.
• Een artiest is een medewerker die acts uitvoert en via een mailadres of een mobielnummer bereikbaar is.
• Beschikbaarheid is een status van een acteur voor een bepaalde tijdsspanne die zegt of de acteur op dat tijdstip zeker beschikbaar, zeker niet beschikbaar of alvast ingepland is.
• De beschikbaarspagina is een onderdeel van het systeem waar medewerkers de beschikbaarheid van artiesten kunnen inzien en wijzigen.
• Een bestemming is een locatie waar een rekwisietenbundel zal worden geleverd of een vervoer eindigt.
• Een betaling is een bepaald bedrag dat een klant op een bepaalde uiterlijke datum naar Close Act overgemaakt dient te hebben.
• Een contactpersoon is een persoon, die op verschillende manieren bereikt kan worden en óf Close Act óf een klant vertegenwoordigt.
• Contactgegevens zijn gegevens waarmee men contact met een klant kan opnemen. Contactgegevens bevatten minstens NAW-gegevens, een mailadres, een telefoonnummer en bankgegevens en kunnen een tweede telefoonnummer bevatten.
• Een contract is een schriftelijke overeenkomst tussen Close Act en een klant voor de levering van een act. Een contract bevat informatie over een act, en informatie over de mensen die het contract ondertekenen.
• Een dienst is een werkzaamheid uitgevoerd door Close Act
• De financiële afdeling is een onderdeel van de administratie die zich uitsluitend met de financiën van Close Act bezig houd.
• Een hotel is een bedrijf dat slaapplekken voor acteurs aanbiedt, NAW-gegevens heeft en waar men opmerkingen over kan hebben met betrekking tot de geboekte voorzieningen.
• Een inpakker is een medewerker die logistieke werkzaamheden verricht.
• Een klant is een persoon die een dienst afneemt of wenst af te nemen van Close Act
• Een kostuum is een rekwisiet dat tijdens een act door een of meerdere acteurs wordt gedragen
• Een medewerker is een persoon die door middel van een arbeidsovereenkomst aantoonbaar in dienst is van Close Act.
• Een meldadres is een locatie waar een acteur zich voor een act moet melden.
• Een paklijst is een tekstueel overzicht van de goederen die voor een act worden gebruikt en in een zending zitten alsmede het afleveradres en de tijsspanne van verzending en aflevering
• Een potentiële Artiest is een artiest die bij een bepaalde productie mee kan spelen.
• Een potentiële Rekwisiet is een rekwisiet die bij een rekwisietentype behoort waarvan een aantal rekwisieten voor een productie nodig zijn.
• Een productie is een dienst van Close Act met de mogelijkheden voorstelling, parade of mobiel theater.
• speelinfo zijn een overzicht voor de artiesten waarin onder andere staat wanneer ze waar moeten zijn om met een act te kunnen beginnen en hoe ze naar de act komen.
• Een rekwisiet is een goed dat in een act door een of meerdere acteurs wordt gebruikt en door een naam en een beschrijving kan worden beschreven.
• Een rekwisietenbundel is een verzameling van meerdere rekwisieten.
• Een rekwisietentype is een categorie bij die meerdere rekwisieten behoren die iets gemeenschappelijk hebben.
• Een ressource is een benodigdheid die voor een productie nodig is en kan een type kostuum of een potentiële artiest zijn.
• Het systeem is een informatiesysteem dat op Close Act is toegepast.
• Een tijdspanne is een periode die op een bepaald tijdstip op een bepaald datum begint en op een tijdstip, die later is dan het begintijdstip, dus op dezelfde of een later datum eindigt.
• Een transport is het proces van het vervoeren van een rekwisietenbundel tijdens een bepaalde tijdsspanne.
• Een transporteur is een persoon of bedrijf die een transport transporteert.
• Vertrek is het begin van een vervoer en beschrijft het tijdstip en de locatie waar het vervoer begint en kan optioneel nog een aanwezigheidstijd noemen.
• Een vervoer is een verplaatsing van acteurs en optioneel rekwisieten door middel van een vervoermiddel.
• Een vervoermiddel is een transportmiddel waarmee mensen en rekwisieten van de ene naar de andere locatie kunnen worden getransporteerd.
• Een werkschema is een overzicht van de werkzaamheden waaruit blijkt waar en wanneer de verschillende activiteiten uitgevoerd zullen worden door de medewerkers.
• Wijzigingsgegevens zijn gegevens over het wijzigen van een act waaronder de datums van een wijziging en de persoon die iets wijzigde.

Executive sponsor viewpoint

Doelstelling voor deze fase: Complete

1. Waarom is überhaupt een computersysteem nodig?
   • Waarom niet
     • Afhankelijk van de faciliteiten kan ook gewerkt worden met whiteboards, prikborden of andere systemen
   • Waarom wel
     • Omdat het foutgevoelig is om de restricties door medewerkers te laten bewaken, Een computersysteem dat de ristricties bewaakt zal de kans op fouten reduceren.
     • Omdat een verandering sneller (geautomatiseerd) kan worden doorgevoerd. (Handmatig kost dit erg veel tijd.)

1. Wie zal worden beinvloed door de implementatie van het systeem?
   • De administratiemedewerkers
     • Voordeel: Bewaking van restricties.
     • Obstakel: Leercurve in het gebruik van het systeem en vrees voor verlies van baan
   • De artiesten
     • Voordeel: Eenvoudiger beschikbaarheid aan te geven
     • Obstakel: Een korte gewenningsfase door procesverandering en een leercurve vanwege het nieuwe systeem.
   • De inpakkers
     • Voordeel: Een helder overzicht
     • Obstakel: Zie »overleg topic transport«
   • De klanten
     • Voordeel: Sneller een antwoord op de beschikbaarheid van acts. Verborgen: meer garantie dat alles goed verloopt.
     • Obstakel: Afhankelijkheid van het systeem: als het systeem plat ligt kunnen er geen afspraken gemaakt worden.

Use case tests

Doelstelling voor deze fase: Notes --> As good as possible --> Complete

Dit onderwerp wordt niet expliciet behandeld. Het is een controle van use cases tov scenarios.