Requirements Engineering/het werk/werkstuk/2010-11/Groep 08

 

RE Case Study Groep 8

Werkstuk Requirements Engineering

Michiel van Lierop, Jan Schmidt, Aziz Arig, Turan Kulaksizoglu

Onderwijsinstituut voor Informatica en Informatiekunde

Radboud Universiteit Nijmegen

---

version 18 februari 2022

---

Ga naar de Voortgangspagina.

Subpagina's Requirements Engineering/het werk/werkstuk/2010-11/Groep 08/Voortgang

Michiel van Lierop Jan Schmidt Aziz Arig Turan Kulaksizoglu

De inhoud is opgebouwd als volgt.

Introduction

Current Goal: Preliminary version
Current Status: AGAP

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 Theatre is een professioneel gezelschap met steltlopers, dansers, muzikanten, vuurspelers en acrobaten, die allen regelmatig samen trainen en repeteren. Close-Act geeft overal ter wereld voorstellingen. Close-Act heeft tientallen spelers in dienst die volgens planning spelen bij voorstellingen. Door de vele voorstellingen is een goede planning van essentieel belang. De planningen worden steeds door dezelfde mensen op kantoor uitgevoerd, omdat alleen zij over bepaalde informatie beschikken. Om er voor te zorgen dat alles goed verloopt worden meerdere checks uitgevoerd door de medewerkers.

Deze webpagina gaat over de ontwikkeling van een ondersteunende computersysteem voor Close-Act. De systeemontwikkeling wordt uitgevoerd met behulp van Use Cases zoals zij gedefinieerd zijn in het gelijknamige boek van Daryl Kulak en Eamonn Guiney.

Problem statement

Current Goal: As good as possible
Current Status: AGAP

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.

De Problem statement van dit project is als volgt:

• Het staat niet vast welke spelers welke acts kunnen uitvoeren.

• Het staat niet vast welke spelers in welke kostuum passen.

• De beschikbaarheidcontrole van kostuums vraag veel tijd en aandacht.

• (Spelers)informatie staat in digitale bestanden en in het hoofd van de planners.

De scope van het project wordt de Kostuumplanner, Spelersinformatie en Spelersplanner. De overige systemen zoals Agenda, Informatie over opdrachtgevers en Opdrachtinformatie vallen buiten de scope.

Case analysis

Stakeholder analysis

Current Goal: As good as possible
Current Status: AGAP

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!).

Medewerkers: De contactpersonen van de klanten en spelers als het om shows gaat. Zij verzorgen de volledige planning van de shows. Tijdens het plannen van de shows zijn er (dubbele) controles die uitgevoerd worden.

Spelers: De acteurs/actrices die voor de shows zorgen. Zij kunnen op een overzicht zien wanneer ze voor welke show zijn ingepland.

Mission and vision statement

Current Goal: Complete
Current Status: Nonexistant

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".

Mission

Missie van het project is om tijdwinst te boeken en fouten te vermijden in het huidige proces. Tijdwinst en fouten vermijden kan gerealiseerd worden door een deel van het proces te automatiseren.

Vision

Visie van het project is om een deel van het proces te automatiseren. Het deel dat geautomatiseerd gaat worden is het huidige Kostuumplanner systeem dat wordt bijgehouden in Microsoft Excel. Het nieuwe Kostuumplanner systeem wordt een Microsoft Access database met een gebruikersvriendelijke interface om makkelijker en sneller de kostuums te kunnen inplannen. De gebruiker van het nieuwe systeem kiest eerst het kostuum die ingepland moet worden en vervolgens de tijdsperiode en opdracht waarvoor het ingepland moet worden. Uiteindelijk kan de gebruiker een overzicht creëren met de ingeplande kostuums per opdracht of per tijdsperiode.

Statement of work

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.

In de Statement of Work wordt een verklaring van de werkzaamheden en een algemeen beeld van hoe het werk moet uitgevoerd worden gegeven, met een algemeen werkplan en het personeelsbezetting. De startdatum van het project is vrijdag 4 maart 2011 en de deadline is vrijdag 10 juni 2011. De presentatie van het project vindt plaats op de donderdagen of vrijdagen van week 24 en 25.

Contactgegevens

Naam	Radboud e-mail	Privé e-mail	Functie
Turan A. Kulaksizoglu	t.a.kulaksizoglu@student.ru.nl	turan.kulaksizoglu@gmail.com	Projectleider en contactpersoon
Aziz Arig	a.arig@student.ru.nl	azizarig@gmail.com	-
Jan-Andre Schmidt	-	jan-andre.schmidt@hotmail.de	-
Michiel van Lierop	michielvanlierop@student.ru.nl	michielvanlierop@gmail.com	-
Niels Braakensiek	n.braakensiek@student.ru.nl	info@allezkan.nl	Opdrachtgever

Werkplan

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

Legenda

 : Voldaan.

 : Niet voldaan / Niet van toepassing.

 : Gestart / Wordt momenteel aan gewerkt binnen Wiki.

Risk analysis

Current Goal: Complete and up-to-date
Current Status: Nonexistant

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.

#	Category	Risk	Solution needed by	Status	Days lost	Expectancy factor	Risk factor
01	Planning	Tijdnood door ziekteverzuim	Als het gebeurt	n.v.t.	14	20%	2,8
02	Planning	Tijdnood door te optimistische tijdplanning	Meteen	Klaar	7	35%	2,45
03	Communicatie	Misverstanden tussen team en stakeholders	Meteen	Klaar	10	15%	1,5
04	Communicatie	Misverstanden tussen teamleden	meteen	Klaar	10	5%	0,5
05	Data-bestand	Verlies van data op de Wiki	Als het gebeurt	n.v.t.	14	1%	0,14

Requirements

Use cases

Use case survey

Current Goal: As good as possible
Current Status: As good as possible

#	Name	Description	Initiating actor
01	Kostuum Invoeren/Wijzigen/Verwijderen	Er kunnen kostuums toegevoegd, gewijzigd, of verwijderd worden.	Medewerker
02	Kostuum Zoeken	Zoekt kostuums die aan bepaalde criteria voldoen.	Medewerker
03	Speler Invoeren/Wijzigen/Verwijderen	Een acteur kan toegevoegd, gewijzigd of verwijderd worden.	Medewerker
04	Speler zoeken	Zoekt spelers die aan bepaalde criteria voldoen.	Medewerker
05	Boeking kostuum Invoeren/Wijzigen/Verwijderen	Maak een boeking voor een kostuum aan, of wijzig of verwijder die.	Medewerker
06	Boeking speler Invoeren/Wijzigen/Verwijderen	Maak een boeking voor een speler aan, of wijzig of verwijder die.	Medewerker
07	Agenda Inzien	Bekijk de persoonlijke agenda van de acteur	Speler
08	N.B. Opgeven	Speler geeft door niet beschikbaar te zijn	Speler

Integrated use case diagram

Individual use cases

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

Use Case:	Name
Use case diagram
Description
Source
Version
Basic course of events
Alternate paths
Preconditions
Postconditions
Related business rules

Kostuums Invoeren/Wijzigen/Verwijderen

Use Case:	UC01
Description	Er kunnen kostuums toegevoegd, gewijzigd, of verwijderd worden.
Source	Stakeholder
Version	1.0
Basic course of events	De medewerker selecteert de kostuums. Het systeem toont een overzicht van alle kostuums. De medewerker selecteert een kostuum. Het systeem toont de gegevens van dit kostuum. De medewerker geeft aan dat dit kostuum bewerkt moet worden. Het systeem toont de gegevens, die nu verandert kunnen worden. De medewerker verandert de gegevens. De medewerker geeft aan dat de verandering klaar is. Het systeem toont die veranderden gegevens. Het systeem vraagt de medewerker om die verandering te bevestigen. De medewerk bevestigt de verandering.
Alternate paths	2a) De medewerker geeft aan dat er een nieuwe kostuum bestaat. Het systeem vraagt naar de gegevens van het nieuwe kostuum. De medewerker geeft de gegevens van het kostuum aan. De medewerker bevestigt de invoer. Het systeem slaagt het nieuwe kostuum op. 5a) De medewerker geeft aan dit kostuum te verwijderen. Het systeem vraagt naar een bevestiging. De medewerker bevestigt de opheffing. Het systeem verwijdert het kostuum uit de database. 10a) De medewerker annuleert. De veranderingen worden niet bijgehouden.
Preconditions	de medewerker is ingelogd
Postconditions	de kostuum gegevens zijn bewerkt door de medewerkers
Related business rules	Alleen medewerkers mogen data bestanden in het systeem veranderen.

Kostuum zoeken

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

Use Case:	UC02
Use case diagram
Description	Zoekt kostuums die aan bepaalde criteria voldoen.
Source	Stakeholder
Version	1.0
Basic course of events	Medewerker geeft aan een kostuum te zoeken. Het systeem vraagt naar welke criteria het moet zoeken. De medewerker geeft een criteria aan. Het systeem vraagt naar welk waarde hij moet zoeken. De medewerker vult een waarde in. De medewerker geeft aan dat hij klaar is met de invoer. Het systeem toont alle kostuums, die aan de aangegeven criteria en de ingevoerde waarde voldoen.
Alternate paths	3a) De medewerker annuleert. Terug naar stap 2.
Preconditions	De medewerker is ingelogd
Postconditions	Het systeem toont alle kostums, die aan de aangegeven criteria voldoen.
Related business rules

Speler Invoeren/Wijzigen/Verwijderen

Use Case:	UC03
Description	Medewerker kan gegevens van een speler invoeren, wijzigen of verwijderen uit het systeem.
Source	Medewerker
Version	1.0
Basic course of events	Speler gegevens wijzigen: Medewerker voert een gegeven van een speler in, in het systeem. Het systeem toont de gegevens van de speler. Medewerker wijzigt de gegevens van de speler. Medewerker slaat de wijziging op in het systeem. Het systeem geeft een melding dat de wijziging opgeslagen is.
Alternate paths	Nieuwe speler invoeren: Medewerker voert de gegevens van de speler in het systeem. Medewerker krijgt een bevestiging van het systeem dat de ingevoerde gegevens zijn opgeslagen. Speler verwijderen: 1a Medewerker moet bevestigen dat hij/zij de gegevens van de speler wil verwijderen. Medewerker krijgt een bevestiging van het systeem dat de spelergegevens zijn verwijderd.
Preconditions	Medewerker heeft toegang tot het systeem van Close-act.
Postconditions	Medewerker heeft een nieuwe speler toegevoegd, de gegevens van een bestaande speler gewijzigd of en speller verwijderd uit het systeem.
Related business rules	Alleen Medewerker mag nieuwe spelergegevens aanmaken, wijzigen of verwijderen. Speler heeft geen bevoegdheid om zijn/haar eigen gegevens te benaderen.

Speler zoeken

Use Case:	UC04
Description	Medewerker kan aan de hand van criteria zoeken naar een speler.
Source	Medewerker
Version	1.0
Basic course of events	Speler gegevens inzien: Medewerker geeft aan een Speler te zoeken Het systeem vraagt naar welke criteria het moet zoeken De medewerker geeft een criteria aan Het systeem vraagt naar welk waarde hij moet zoeken De medewerker vult een waarde in De medewerker geeft aan dat hij klaar is met de invoer Het systeem toont alle spelers, die aan de aangegeven criteria en de ingevoerde waarde voldoen
Alternate paths	Andere Speler gegevens inzien: 3a) De medewerker annuleert Terug naar stap 2
Preconditions	Medewerker heeft toegang tot het systeem van Close-act.
Postconditions	Medewerker heeft één of meerdere Spelers gevonden die ingepland kunnen worden voor een show.
Related business rules	Alleen Medewerker mag spelergegevens zoeken. Speler heeft geen bevoegdheid om zijn/haar eigen gegevens te benaderen.

Boeking kostuum Invoeren/Wijzigen/Verwijderen

Use Case:	UC05
Description	Maak een boeking voor een kostuum aan, of wijzig of verwijder die.
Source	Medewerker
Version	1.0
Basic course of events	Nieuwe Kostuum boeking invoeren: Medewerker voert de datum in. Medewerker selecteert de rol waar een Kostuum voor geboekt moet worden Medewerker koppelt Kostuum aan de datum. Medewerker krijgt een overzicht te zien met alle gekoppelde Kostuums op die datum.
Alternate paths	Kostuum boeking wijzigen: 1a. Het systeem toont de Kostuums die zijn ingeboekt op die datum. Medewerker selecteert de desbetreffende Kostuum. Medewerker wijzigt de geselecteerde Kostuum. Medewerker krijgt een overzicht te zien met alle ingeboekte Kostuums op die datum. Kostuum boeking verwijderen: 1a Het systeem toont de Kostuums die zijn ingeboekt op die datum. Medewerker selecteert de desbetreffende Kostuum. Medewerker verwijdert de geselecteerde Kostuum. Medewerker krijgt een overzicht te zien met alle ingeboekte Kostuums op die datum.
Preconditions	Medewerker heeft toegang tot het systeem van Close-act.
Postconditions	Medewerker heeft een nieuwe Kostuum boeking toegevoegd, de gegevens van een bestaande Kostuum boeking gewijzigd in het systeem of verwijderd uit het systeem.
Related business rules	Alleen Medewerker mag nieuwe Kostuum boeking aanmaken, wijzigen of verwijderen. Speler heeft geen bevoegdheid om zijn/haar eigen gegevens te benaderen.

Boeking speler Invoeren/Wijzigen/Verwijderen

Use Case:	UC06
Description	Maak een boeking voor een speler aan, of wijzig of verwijder die.
Source	Medewerker
Version	1.0
Basic course of events	Nieuwe Speler boeking invoeren: Medewerker voert de datum in. Medewerker selecteert de rol waar een Speler voor geboekt moet worden. Medewerker krijgt een overzicht van Spelers te zien die geschikt zijn om die rol te spelen. Medewerker koppelt Speler aan de datum. Medewerker krijgt een overzicht te zien met alle gekoppelde Spelers op die datum.
Alternate paths	Speler boeking wijzigen: 1a Het systeem toont de Spelers die zijn ingeboekt op die datum. Medewerker selecteert een Speler. Medewerker wijzigt de geselecteerde Speler. Medewerker krijgt een overzicht te zien met alle ingeboekte Spelers op die datum. Speler boeking verwijderen: 1a Het systeem toont de Spelers die zijn ingeboekt op die datum. Medewerker selecteert een Speler. Medewerker verwijdert de geselecteerde Speler. Medewerker krijgt een overzicht te zien met alle ingeboekte Spelers op die datum.
Preconditions	Medewerker heeft toegang tot het systeem van Close-act.
Postconditions	Medewerker heeft een nieuwe Speler boeking toegevoegd, de gegevens van een bestaande Speler boeking gewijzigd in het systeem of verwijderd uit het systeem.
Related business rules	Alleen Medewerker mag nieuwe Speler boeking aanmaken, wijzigen of verwijderen. Speler heeft geen bevoegdheid om zijn/haar eigen gegevens te benaderen.

Agenda Inzien

Use Case:	UC07
Description	Een speler kan zijn persoonlijke agenda zoals die in het systeem staat inzien.
Source	Speler
Version	1.0
Basic course of events	Speler vraagt aan het systeem zijn agenda te tonen. Het systeem toont de agenda van de speler. Speler kiest een andere maand om te tonen en het systeem doet dit.
Alternate paths	2a. Speler kiest een andere maand. Het systeem toont de agenda van de speler voor de nieuw geselecteerde maand.
Preconditions	de Speler heeft toegang tot het systeem. de agenda van Speler is bekend in het systeem.
Postconditions	de Speler kent zijn agenda zoals die bekend is bij Close-Act.
Related business rules	de Speler kan zijn eigen persoonlijke agenda en van zijn collega's bekijken, dus niet die van het bedrijf.

N.B. Opgeven

Use Case:	UC08
Description	Een speler kan zijn persoonlijke agenda aanpassen door aan te geven wanneer hij niet beschikbaar is.
Source	Speler
Version	1.0
Basic course of events	Speler vraagt aan het systeem zijn agenda te tonen en het Systeem doet dit. Speler geeft een begindatum en een begintijd, en een einddatum en eindtijd. Speler geeft aan niet beschikbaar te zijn in deze periode. Systeem vraagt om een bevestiging van de periode waarin Speler niet beschikbaar is, en Speler bevestigt dit. Herhaal vanaf stap 2.
Alternate paths	1a. Speler kiest een andere maand om te tonen. Het systeem laat een andere maand zien. 2a. Speler sluit de applicatie. 4a. Speler annuleert. Terug naar stap 3.
Preconditions	de Speler heeft toegang tot het systeem de agenda van Speler is bekend in het systeem.
Postconditions	de Speler heeft zijn beschikbaarheid in de agenda van Close-Act aangepast.
Related business rules	de Speler kan alleen zijn eigen persoonlijke agenda aanpassen, dus niet die van het bedrijf (waar de toneelstukken ingepland staan) of die van andere spelers. Als een speler voor een tijd geboekt is, kan die speler zichzelf niet op niet beschikbaar zetten voor die tijd. Als een speler voor een tijd niet beschikbaar is, kan de speler niet voor die tijd geboekt worden.

Scenarios

Individual scenarios

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.

Voor de scenario's zijn de meest voorkomende praktijkvoorbeelden gebruikt. Voordat het systeem ingevoerd wordt, zal het getest worden. Het testen zal gebeuren door oa. de hieronder beschreven, scenario's uit te voeren. Nadat een scenario is uitgevoerd wordt getest of het systeem de juiste gegevens bevat.

Use Case (01) Kostuum Invoeren/Wijzigen/Verwijderen

Medewerker: Jan

Kostuum: Clown

Nieuwe rol: Pipo

Kostuum wijzigen (basic):

1. Nieuwe rol: "Pipo" moet toegevoegd worden aan kostuum:"clown"
2. Jan logt zich in op het systeem
3. Jan selecteert de kostuums
4. Jan selecteert het kostuum:"clown"
5. Het systeem toont de gegevens van het kostuum
6. Jan geeft aan dat het kostuum "clown" bewerkt moet worden
7. Het systeem maakt de gegevens veranderlijk
8. Jan voegt de rol "Pipo" aan de gegevens van het kostuum toe
9. Jan geeft aan dat de verandering klaar is
10. Het systeem toont de verandering
11. Het systeem vraag naar een bevestiging
12. Jan bevestigt die verandering
13. Het kostuum met de naam "clown" heeft nu de rol "Pipo"

Nieuwe kostuum (alternate):

1. Een heel nieuwe kostuum moet ingevoerd worden
2. Jan logt zich in op het systeem
3. Jan selecteert de kostuums
4. Jan geeft aan dat er een nieuwe kostuum is
5. Het systeem vraagt naar de gegevens van het kostuum
6. Jan tikt de gegevens in: kostuum naam: "clown"; maat: 45; rol:"Pipo"
7. Jan bevestigt de invoer
8. Het systeem slaagt het kostuum "clown" op met maat en rol

Kostuum verwijdern (alternate):

1. Het kostuum met naam "clown" moet verwijderd worden
2. Jan logt zich in op het systeem
3. Jan selecteert de kostuums
4. Jan selecteert het kostuum:"clown"
5. Het systeem toont de gegevens van het kostuum
6. Jan geeft aan dat dit kostuum verwijderd moet worden
7. Het systeem verwijdert het kostuum "clown" uit de database

Use Case (02) Kostuum zoeken

Medewerker: Jan

Kostuum: Clown

Kostuum zoeken (basic):

1. Jan zoekt het kostuum "clown" in de database
2. Jan logt zich in op het systeem
3. Jan geeft aan dat hij een kostuum zoekt
4. Het systeem vraagt naar welke criteria het moet zoeken
5. Jan geeft als criteria: "naam" aan
6. Jan geeft als naam: "clown" aan
7. Het systeem toont het kosuum met de naam "clown"

Use Case (03) Speler Invoeren/Wijzigen/Verwijderen

Medewerker: Jan

Speler: Piet

Speler wijzigen:

1. Jan voert de geboortedatum van Piet in.
2. Het systeem laat alle spelers zien die de ingevoerde geboortedatum hebben.
3. Jan kiest uit de mogelijkheden voor Piet.
4. Het systeem laat de gegevens van Piet zien.
5. Jan voegt 'Alien' toe in de lijst van rollen, wat Piet kan spelen en slaat de gegevens op.

Nieuwe speler invoeren:

1. Jan gaat naar de startpagina.
2. Het systeem toont Jan een aantal mogelijkheden.
3. Jan klikt op nieuw speler invoeren.
4. Het systeem laat het venster zien waarin Jan de nieuwe speler in kan voeren.
5. Jan voert de gegevens van Piet in, in het systeem.
6. Jan slaat de gegevens op.
7. Het systeem geeft een melding dat de gegevens opgeslagen zijn.

Speler verwijderen/op non-actief zetten:

1. Het systeem toont Jan een aantal mogelijkheden.
2. Jan kies voor: ‘Speler verwijderen/speler non-actief’.
3. Jan voert de geboortedatum in van Piet.
4. Het systeem toont alle spelers met de ingevoerde geboortedatum.
5. Jan kiest in het getoonde venster voor Piet en krijgt de gegevens van Piet te zien.
6. Jan kiest voor ‘Speler verwijderen/speler non-actief’ en slaat degegevens op.
7. Het systeem geeft een melding dat de gegevens opgeslagen zijn.

Use Case (04) Speler Zoeken

Medewerker: Jan

Speler: Piet

Speler 2: Hans

Standaard scenario

1. Jan voert criteria in aan de hand van de show en de vastgestelde kostuums.
2. Jan krijgt een overzicht te zien van de spelers die beschikbaar zijn en in die kostuum kunnen spelen.
3. Jan kiest Piet als speler voor die show.
4. Piet kan nou in zijn agenda zien dat hij tijdens de show moet spelen.

Alternatief scenario 1

1. Jan voert de nieuwe criteria in aan de hand van de show en de gewijzigde kostuums.
2. Jan krijgt een overzicht te zien van de spelers die beschikbaar zijn en in de gewijzigde kostuum kunnen spelen. Jan kiest Hans voor de nieuwe kostuum.
3. Hans kan in zijn agenda zien dat hij tijdens de show moet spelen.

Use Case (05) Boeking Kostuum

Medewerker: Jan

Speler: Piet

Standaard scenario

1. Jan voert criteria in van de nieuwe opdracht.
2. Jan krijgt een overzicht te zien van de rollen waar een Kostuum voor geboekt moet worden.
3. Jan kiest Taurus 1 als Kostuum en krijgt een overzicht te zien van Spelers die dat Kostuum kunnen dragen.
4. Jan kiest Piet als Speler en koppelt hem aan de Kostuum.
5. Jan krijgt een overzicht te zien met alle Kostuums die zijn ingeboekt.
6. Piet kan in zijn agenda zien welke Kostuum hij moet dragen tijdens de show.

Alternatief scenario 1

1. Jan voert de zoek criteria in van de opdracht.
2. Jan krijgt een overzicht te zien van de rollen waar een Kostuum voor is ingeboekt.
3. Jan kiest de Kostuum Taurus 1 en verandert de Kostuum naar Taurus 2.
4. Jan krijgt een overzicht te zien met alle Kostuums die zijn ingeboekt.
5. Piet krijgt de wijziging te zien in zijn agenda en weet welke Kostuum hij moet dragen tijdens de show.

Alternatief scenario 2

1. Jan voert de zoek criteria in van de opdracht.
2. Jan krijgt een overzicht te zien van de rollen waar een Kostuum voor is ingeboekt.
3. Jan kiest de Kostuum Taurus 1 en krijgt als Speler Piet te zien die aan die Kostuum is gekoppeld.
4. Jan klikt op verwijderen om de Kostuum reservering te verwijderen.
5. Jan krijgt een overzicht te zien met alle Kostuums die zijn ingeboekt.

Use Case (06) Boeking Speler

Medewerker: Jan

Speler: Piet

Speler: Hans

Standaard scenario

1. Jan voert criteria in van de nieuwe opdracht.
2. Jan krijgt een overzicht te zien van de rollen waar een Speler voor geboekt moet worden.
3. Jan kiest Piet een rol voor een show en krijgt een overzicht te zien van Spelers die de rol kunnen spelen.
4. Jan kiest Piet als Speler en koppelt de rol aan de Speler.
5. Jan krijgt een overzicht te zien met alle Spelers die zijn ingeboekt.
6. Piet kan in zijn agenda zien welke rol hij moet spelen tijdens de show.

Alternatief scenario 1

1. Jan voert de zoek criteria in van de opdracht.
2. Jan krijgt een overzicht te zien van de rollen waar een Speler voor is ingeboekt.
3. Jan kiest de Speler Piet en verandert de Speler naar Hans.
4. Jan krijgt een overzicht te zien met alle Spelers die zijn ingeboekt.
5. Piet krijgt de wijziging te zien in zijn agenda en weet welke rol hij moet spelen tijdens de show.

Alternatief scenario 2

1. Jan voert de zoek criteria in van de opdracht.
2. Jan krijgt een overzicht te zien van de rollen waar een Speler voor is ingeboekt.
3. Jan kiest een rol en krijgt als Speler Hans te zien die aan die rol is gekoppeld.
4. Jan klikt op verwijderen om de Boeking Speler ongedaan te maken.
5. Jan krijgt een overzicht te zien met alle Splers die zijn ingeboekt.

Use Case (07) Agenda Inzien

Speler: Jan

Standaard scenario

1. Jan logt in op het systeem via de website van Close-Act
2. Jan bekijkt zijn agenda
3. Jan logt uit

Alternatief scenario 1

1. Jan logt in op het systeem via de website van Close-Act
2. Jan selecteert een ander deel van zijn agenda
3. Jan bekijkt zijn agenda voor deze periode
4. Jan selecteert eventueel nog een andere periode en bekijkt die
5. Jan logt uit

Use Case (08) N.B. Opgeven

Speler: Jan

Standaard scenario

1. Jan logt in op het systeem via de website van Close-Act
2. Jan bekijkt zijn agenda
3. Jan selecteert een tijdsperiode (begindatum, begintijd, einddatum, eindtijd)
4. Jan geeft aan Niet Beschikbaar te zijn in deze periode
5. Jan bevestigd dit nogmaals, voor de zekerheid
6. Jan logt uit

Alternatief scenario 1

1. Jan logt in op het systeem via de website van Close-Act
2. Jan selecteert een ander deel van zijn agenda en bekijkt die
3. Jan selecteert een tijdsperiode (begindatum, begintijd, einddatum, eindtijd)
4. Jan geeft aan Niet Beschikbaar te zijn in deze periode
5. Jan bevestigd dit nogmaals, voor de zekerheid
6. Jan logt uit

Alternatief scenario 2

1. Jan logt in op het systeem via de website van Close-Act
2. Jan bekijkt zijn agenda
3. Jan selecteert een tijdsperiode (begindatum, begintijd, einddatum, eindtijd)
4. Jan geeft aan Niet Beschikbaar te zijn in deze periode
5. Jan annuleert
6. Jan selecteert eventueel opnieuw een tijdsperiode (begindatum, begintijd, einddatum, eindtijd)
7. Jan geeft eventueel opnieuw aan N.B. te zijn
8. Jan bevestigd of annuleert opnieuw
9. Jan logt uit

Integrated Domainmodel

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.

Non-functional Requirements

[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.

• Het systeem is in principe offline
  • Enkel de agenda's van de spelers zijn online in te zien. Dit kan via een website waar de spelers met een gebruikersnaam en wachtwoord kunnen inloggen.

Archival: Het systeem moet gegevens bevatten van opdrachten die maximaal 2 jaar oud zijn. De gegevens die ouder zijn moeten digitaal gearchiveerd worden.

Authenticatie: Gebruikersaccounts moeten beveiligd worden door middel van wachtwoorden, zodat alleen de gebruiker bij zijn persoonlijke gegevens kan komen

Authorisation: Gebruikers mogen alleen de gegevens zien die voor de uitvoer van hun taak nodig is.

Availability: Het system moet een beschikbaarheidspercentage hebben van 99,9% gedurende 1 jaar. Hierbij bedraagt de mogelijke downtime 1,5 dagen.

Data integrity: Tolerantie wat betreft verlies, corruptive of duplicatie van data. Het mag niet zo zijn dat gegevens op verschillende plekken gewijzigd moeten worden. Elke dag wordt een back-up gemaakt van de data, zodat altijd terug kan worden gegrepen op een vorige versie.

Installability: Het systeem moet tenminste gebruikt kunnen worden op Windows. Een variant voor MacOS of Linux is optioneel.

Maintainability: Het system moet zoveel mogelijk onderhoudsvrij zijn. Het systeem zal enkel geüpdatet moeten worden als het systeem wordt uitgebouwd.

Operability: Het system moet eenvoudig in gebruik zijn voor de medewerkers. Een korte uitleg/cursus moet voldoende zijn om het systeem te kunnen gebruiken.

Performance: Het systeem moet zo werken dat de gebruikers niet langer dan 2 seconden hoeven te wachten tot ze een volgend actie kunnen uitvoeren. Het systeem moet erg soepel werken.

Privacy: Privé gegevens van medewerkers zijn afgeschermd voor andere medewerkers.

Reliability: Het systeem moet betrouwbaar zijn, de gegevens moeten juist zijn en opgeslagen worden in het systeem. Er wordt dagelijks om 23:59 een back-up gemaakt.

Security: Het systeem moet beveiligd worden tegen interventie van buitenaf. Er moet een wekelijkse back-up gemaakt worden waardoor er in geval het crashen van het systeem er doorgewerkt kan worden met een minimale achterstand.

Stability: Het systeem moet stabiel blijven tijdens normaal gebruik. Het systeem wordt stabiel bevonden zolang het zich aan de eisen van ´Performance´ houdt.

Addendum

Business Rules Catalogue

Current Goal: Not yet
Current Status: Nonexistant

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.

• Een speler moet op een datum beschikbaar danwel onbeschikbaar zijn.
• Een speler moet minimaal één kostuum passen.
• Een speler moet minimaal één rol kunnen spelen.
• Een speler moet een unieke naam hebben.
• Een rol moet vertolkt kunnen worden door minimaal één kostuum.
• Een rol moet gespeeld kunnen worden door minimaal één speler.
• Een rol moet een unieke naam hebben.
• Een kostuum moet gedragen kunnen worden door minimaal één speler
• Een kostuum moet een unieke naam hebben.
• Als een kostuum voor een tijd geboekt is, kan dat kostuum niet nogmaals voor dezelfde tijd geboekt worden.
• Als een speler voor een tijd geboekt is, kan die speler niet nogmaals voor dezelfde tijd geboekt worden.
• Als een speler voor een tijd niet beschikbaar is, kan de speler niet voor die tijd geboekt worden.
• Als een speler voor een tijd geboekt is, kan die speler zichzelf niet op niet beschikbaar zetten voor die tijd.

Volgens mij zijn vooral door de tweede regel alle business rules van belang aangegeven.
Jan Schmidt → Requirements Engineering	Remove this comment when resolved!

Terminological Definitions

Current Goal: Notes
Current Status: Nonexistant

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.

Definiens	Genus	Differentiae
Term	Supertype van de term	Wat zijn de verschillen met andere subtypen?
Agenda	Persoonlijke administratie	In een agenda staan alle afspraken van diens eigenaar (of eigenaren) op chronologische volgorde genoteerd.
Database	Dataopslag	Een database is een gestructureerde vorm van digitale dataopslag.
Kostuum	Kleding	Een kostuum is een set van kleding voor één persoon, die een specifieke rol vertegenwoordigt in een toneelspel.
Medewerker	Mens	Een werknemer van een bedrijf.
Rol	Taken binnen een toneelspel	Een rol is een consequente manier van doen die geässocieerd wordt met een fictief personage.
Speler	Mens	Een speler, ookwel acteur, voert podiumkunsten, zoals toneel, uit als beroep.
Systeem	Digitaal hulpmiddel	Overkoepelende term voor alle digitale artefacten binnen een domein.