Requirements Engineering/het werk/werkstuk/2013-14/Groep 09

Uit Werkplaats
< Requirements Engineering‎ | het werk‎ | werkstuk‎ | 2013-14
Versie door Thijs Werrij (overleg | bijdragen) op 4 apr 2014 om 14:47 (Integrated use case diagram)
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)
Ga naar: navigatie, zoeken

Requirements Engineering


 © comments



 






'



Werkstuk Requirements Engineering


Thijs Werrij, Lars Kuijpers, Toon Lenaerts en Flip van Spaendonck



Onderwijsinstituut voor Informatica en Informatiekunde

Radboud Universiteit Nijmegen







version 18 februari 2022



Page Break




Introduction

A2B Taxi Services is een bedrijf dat taxiservices aanbiedt in Noord- en Zuid-Holland. Hun huidige manier van werken is redelijk onhandig en daarom willen zij een nieuw systeem dat hun taxiservices beter te gebruiken maakt voor zowel klanten als interne medewerkers. Met name willen ze de klanten een alternatieve en makkelijkere manier van bestellingen plaatsen en betalen aanbieden en ook de werkdruk op de roostermaker, die in het huidige systeem nog alle bestellingen handmatig moet verwerken, verminderen.

Dit document is als volgt opgebouwd: we beginnen met het "Problem statement", wat een beschrijving is van de huidige situatie bij A2B Taxi Services en de problemen die daarin voorkomen. Daarna komt een "Stakeholder analysis", wat een beschrijving is van alle personen die belang hebben bij het nieuwe systeem. Het doel van het project en ons beeld van het nieuwe systeem worden gegeven in het "Mission and vision statement". In het "Statement of Work" wordt de voortgang van het project bijgehouden en in "Risk Analysis" houden we de mogelijke risico's voor ons project bij en hoe deze het project beinvloeden. Bij de "Use Cases" worden de daadwerkelijke requirements voor de functionaliteit van het systeem opgesteld. Dit begint met de "Use Case Survey", waar elke Use Case kort wordt aangeduid en in de "Integrated Use Case Diagram" wordt duidelijk gemaakt tussen welke actoren deze plaatsvinden. Bij de "Individual Use Cases" wordt echt duidelijk stap voor stap verteld hoe de use cases plaatsvinden in het systeem. In het "Domain Model per Use Case" wordt bij elke use case verteld welke gegevens er gebruikt worden bij die use case. Bij "Scenarios" worden deze use cases concreter gemaakt met duidelijke voorbeelden die in het echt zouden kunnen voorkomen. In de "Non-functional Requirements" worden de onderliggende eisen aan het systeem die niet direct met de functionaliteit te maken hebben beschreven, zoals bijvoorbeeld de beschikbaarheid van het systeem. Het Addendum bevat ten eerste het "Integrated Domainmodel" waar het domeinmodel van het gehele systeem wordt getoond. Verder hebben we hier de "Business Rules Catalogue" die alle business rules van het bedrijf opsomt. Tot slot hebben we hier ook een aantal "Terminological Definitions" waarin we precies beschrijven wat we met enkele termen in ons document bedoelen.

Problem statement

Op het moment werkt A2B alleen met telefonische taxibestellingen, maar ze merken dat mensen dit een redelijk onhandige manier vinden en daarom krijgen ze steeds minder klanten. Daarnaast wordt alle informatie, bijvoorbeeld roosters en betaalinformatie, op papier bijgehouden. In het huidige systeem moet de roostermaker hierdoor zelf zoeken naar de dichtstbijzijnde vrije taxichauffeur als er een bestelling wordt geplaatst en is financieel werk, zoals belasting-aangiften, erg onoverzichtelijk.

Case analysis

Stakeholder analysis

Naam Rol Beschrijving
Rayonmanager Noord-Holland Rayonmanager De Rayonmanager is verantwoordelijk voor de services van A2B in een bepaald gebied (rayon).
Taxichauffeur A Taxichauffeur De Taxichauffeur krijgt opdrachten van de centrale om mensen van A naar B te brengen.
Roostermaker A Roostermaker De Roostermaker maakt de roosters van de chauffeurs en behandelt de bestellingen van de klanten.
Systeembeheerder A Systeembeheerder De Systeembeheerder zorgt dat het systeem goed blijft werken en probeert mogelijke fouten zo snel mogelijk te verhelpen.
Testgebruiker A Testgebruiker De Testgebruiker is een potentiële klant van A2B die het nieuwe systeem zal testen.

Mission and vision statement

  • Mission - We willen een makkelijkere manier creëren voor de klanten om gebruik te maken van de services die Taxi Service A2B aanbiedt. Ook willen wij de interne communicatie tussen centrale en chauffeurs automatiseren.
  • Vision - Er komt een app waarin klanten een account kunnen aanmaken waardoor ze makkelijker gebruik kunnen maken van de services van Taxi Service A2B. Met deze app kunnen de klanten een taxi bestellen, die, als dit is ingesteld, automatisch via GPS de positie van de klant binnenkrijgt. Verder kunnen klanten op drie manieren betalen: via een saldo dat ze op hun account zetten, met een externe, digitale betaalmogelijkheid of nog gewoon contant zoals in het oude systeem. Ook worden in het nieuwe systeem de bestellingen automatisch doorgevoerd naar de dichtstbijzijnde, vrije chauffeur die via een eigen speciaal account de opdracht kan accepteren of weigeren. Ook kunnen chauffeurs met dit account hun rooster inzien. Dit nieuwe systeem komt bovenop het al bestaande telefonische systeem, dus klanten kunnen de telefonische manier van bestellen blijven gebruiken.

Statement of work

Deliverable DeliverbleType Façade Filled Focused Comment
Introduction Contextual Preliminary version Preliminary version Complete Keep it short at first, only a sketch; nice, clear and complete at the end.
Status: 100% 100% 100% -
Problem statement Key deliverable As good as possible As good as possible Complete
Status: 100% 100% 100% -
Stakeholder list/analysis Contextual As good as possible As good as possible Complete
Status: 100% 100% 100% -
Mission-Vision-(Values) Contextual Complete Complete Complete
Status: 100% 100% 100% -
Statement of Work Contextual Complete, and up-to-date Complete, and up-to-date Complete, and up-to-date
Status: 100% 100% 100% -
Risk Analysis Contextual Complete, and up-to-date Complete, and up-to-date Complete, and up-to-date
Status: 100% 100% 100% -
Use Case Survey Key deliverable As good as possible Nearly complete Complete
Status: 100% 100% 100% -
Integrated UC Diagram Key deliverable Complete (though preliminary) Complete Complete One for whole project
Status: 100% 100% 100% -
Use Cases Key deliverable Not yet! "Filled" level Complete
Status: 100% 100% -
Scenarios Key deliverable Not yet! Several for each UC Complete ("focused" level)
Status: 100% 100% -
Domain Models Key deliverable Not yet! Partially complete Complete One for each UC
Status: 100% 100% -
Business rules per UC Key Deliverable Not yet! Partially complete Complete
Status: 100% 100% -
Integrated Domain Model Key deliverable Not yet! First draft Complete One for whole project
Status: 100% 100% -
Business Rules Catalogue Key deliverable Not yet! Partially complete Complete
Status: 100% 100% -
Non-functional Requirements Key deliverable Notes Partially complete Complete
Status: 100% 100% 100% -
Terminological Definitions Key deliverable Notes Partially complete Complete
Status: 100% 100% 100% -
Executive sponsor viewpoint Implicit deliverable Complete Complete Complete Integrated in M-V-(V)!
Status: n.v.t. n.v.t. n.v.t. -
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: n.v.t. n.v.t. n.v.t. -
Business process definitions Optional appendix If available / relevant If relevant If relevant Use existing definitions/models or make them yourself: optional!
Status: n.v.t. n.v.t. n.v.t. -
GUI metaphors / storyboards Optional appendix If relevant If relevant If relevant
Status: n.v.t. n.v.t. n.v.t. -

Risk analysis

# Category Risk Solution needed by Status Days lost Expectancy factor Risk factor
01 Team Permanent uitvallen teamlid 7 dagen n.v.t. 0 5% 9
02 Team Tijdelijk uitvallen teamlid 1 dag n.v.t. 0 20% 7
03 Team Interne miscommunicatie Per direct n.v.t. 0 80% 3
04 Team Een teamlid houdt zich niet aan de planning Per direct n.v.t. 0 80% 3
05 Communicatie Miscommunicatie met klant 3 dagen n.v.t. 0 35% 6
06 Project Dataverlies Per direct n.v.t. 0 10% 6

Requirements

Use cases

Use case survey

# Name Description Initiating actor
01 Taxi Bestellen De klant bestelt een taxi Klant
02 Account aanmaken De klant maakt een account aan Klant
03 Saldo verhogen De klant voegt geld toe aan zijn accountsaldo Klant
04 Opdracht accepteren De chauffeur accepteert een opdracht Centrale
05 Rooster inzien De chauffeur bekijkt zijn rooster Chauffeur
06 Inloggen De klant logt in op zijn/haar account Klant

Integrated use case diagram

UC Diagram A2B Taxi Services.jpg

Individual use cases

Use Case: Taxi Bestellen
Use case diagram
Description De klant bestelt een taxi.
Source Hele team
Version 3
Actor De klant
Basic course of events 1. (trigger) De klant geeft aan dat hij een bestelling wil maken.

2. Het systeem vraagt wat voor soort taxi.

3. De klant geeft de taxi van zijn keuze aan.

4. Het systeem vraagt om de manier van locatie bepalen.

5. De klant kiest de GPS-optie.

6. Het systeem vraagt wanneer de taxi aanwezig moet zijn.

7. De klant geeft aan wanneer de taxi aanwezig moet zijn.

8. Het systeem laat de klant alle gegevens van de bestelling zien en vraagt om een bevestiging.

9. De klant bevestigt de bestelling.

10. Het systeem vraagt hoe de klant wil betalen.

11. De klant kiest de saldo-optie.

12. Het syteem geeft aan dat het aanvragen en bestellen van een taxi gelukt is.

Alternate paths Handmatige locatie

5a1. De klant kiest de handmatige optie.

5a2. Het syteem vraagt de klant om zijn locatie in te voeren.

5a3. De klant voert zijn locatiegegevens in.

Ga verder bij 6.


Externe betaalmethode

11a1. De klant kiest een externe betaalmethode-optie.

11a2. Het systeem stuurt de klant door naar de gekozen externe betaalmethode.

11a3. De klant betaalt via de gekozen methode.

Ga verder bij 12.


Contante betaling

11b1. De klant kiest de contant-optie.

Ga verder bij 12.

Exception Paths Geen beschikbare chauffeur

8a1. Het systeem geeft aan dat er op de aangegeven tijd geen beschikbare chauffeur is en vraagt de klant een nieuwe tijd aan te geven.

Ga verder bij 7.


Klant annuleert bestelling

9c1. De klant geeft aan dat hij de bestelling wil annuleren.

9c2. Het systeem stuurt de klant terug naar het hoofdscherm.


Saldo te laag

12a1. Het systeem geeft aan dat het saldo van de klant te laag is en stuurt de klant terug naar het hoofdscherm.


Externe betaalmethode mislukt (alleen bij Alternate path Externe betaalmethode)

11a4. Het systeem geeft aan dat het betalen via de externe betaalmethode mislukt is en stuurt de klant terug naar het hoofdscherm.

Preconditions De klant is ingelogd op zijn/haar account.
Postconditions De bestelling wordt doorgegeven aan de betreffende taxichauffeur en de betaling is verwerkt en opgeslagen in de log.
Related business rules De klant kan geen taxi bestellen als hij al een taxi besteld heeft.
Use Case: Account aanmaken
Use case diagram
Description De klant maakt een account aan
Source Lars
Version 2
Actor De klant
Basic course of events 1. (trigger) De klant geeft aan dat hij een account wil aanmaken.

2. Het systeem vraagt om een inlognaam en wachtwoord.

3. De klant vult zijn gewenste inlognaam en wachtwoord in.

4. Het systeem vraagt of de klant standaard GPS aan wil hebben.

5. De klant geeft aan dat hij standaard GPS wil gebruiken.

6. Het systeem laat de klant alle tot nu toe gekozen gegevens van het account zien en vraagt de klant om een bevestiging.

7. De klant bevestigt het aanmaken van het account.

8. Het systeem geeft aan dat het aanmaken van een account gelukt is.

Alternate paths Geen standaard GPS

5a1. De klant geeft aan dat hij standaard GPS uit wil hebben.

Ga verder bij 6.

Exception paths Inlognaam bestaat al

4a1. Het systeem geeft aan dat die inlognaam al gebruikt wordt en vraagt de klant een andere in te vullen.

Ga verder bij 3.


De klant annuleert het aanmaken van een account

7a1. De klant annuleert het aanmaken van het account.

7a2. Het systeem stuurt de klant terug naar het hoofdscherm.

Preconditions n.v.t.
Postconditions Er is een account voor de klant met de gewenste inlognaam, wachtwoord en standaardinstellingen aangemaakt.
Related business rules Elke inlognaam mag maar door één persoon gebruikt worden.
Use Case: Saldo Verhogen
Use case diagram
Description De klant voegt geld toe aan zijn accountsaldo.
Source Toon
Version 4
Actor De klant
Basic course of events 1. (trigger) De klant geeft aan dat hij zijn saldo wil verhogen.

2. Het systeem vraagt de klant om het gewenste bedrag.

3. De klant voert het gewenste bedrag in.

4. Het systeem laat het gekozen bedrag zien en vraagt de klant dit te bevestigen.

5. De klant bevestigt de betaling.

6. Het systeem vraagt de klant naar een gewenste betaalmethode.

7. De klant geeft zijn gewenste betaalmethode door.

8. Het systeem stuurt de klant door naar de gewenste externe betaalmethode.

9. De klant betaalt via de gewenste methode.

10. Het systeem geeft aan dat de betaling gelukt is.

Alternate paths n.v.t.
Exception paths De externe betaling gaat fout.

10a1. Het systeem geeft aan dat de betaling mislukt is, zegt de klant dat hij het opnieuw moet proberen en vraagt de klant naar de gewenste betaalmethode.

Ga verder bij 7.


De klant kiest een te hoog bedrag.

4a1. Het systeem geeft aan dat het gekozen bedrag te hoog is, geeft het limiet van geaccepteerde bedragen aan en vraagt de klant naar het gewenste bedrag.

Ga verder bij 3.


De klant kiest een bedrag waardoor zijn saldo het maximum zal overschrijden.

4b1. Het systeem geeft aan dat het gekozen bedrag het maximum saldo zal overschrijden, geeft het hoogste bedrag mogelijk zonder het saldo te overschrijden en vraagt de klant naar het gewenste bedrag.

Ga verder bij 3.


De klant annuleert de bestelling.

5a1. De klant annuleert het verhogen van het saldo.

5a2. Het systeem laat zien dat de bestelling geannuleerd is en stuurt de klant terug naar het hoofdscherm.

Preconditions De klant is ingelogd in het systeem.
Postconditions Het saldo van de account van de klant is met het gewenste bedrag verhoogd.
Related business rules De klant mag zijn saldo niet met meer dan 200 euro in één transactie verhogen.

De klant heeft een maximaal saldo van 500 euro.

Use Case: Opdracht accepteren
Use case diagram
Description De chauffeur accepteert een opdracht.
Source Flip
Version 2
Actor De centrale/het systeem
Basic course of events 1. (trigger) Het systeem toont een opdracht aan de chauffeur.

2. De chauffeur accepteert de opdracht.

Alternate paths 2a1. De chauffeur wijst de opdracht af.
Exception paths n.v.t.
Preconditions De chauffeur is op het moment niet bezig met een opdracht.
Postconditions De opdracht is geaccepteerd of is doorgestuurd naar een andere chauffeur.
Related business rules De chauffeur mag maar met een opdracht tegelijk bezig zijn.
Use Case: Rooster inzien
Use case diagram
Description De chauffeur bekijkt zijn rooster.
Source Flip
Version 2
Actor De chauffeur
Basic course of events 1. (trigger) De chauffeur vraagt zijn rooster op.

2. Het systeem vraagt van welke dag de chauffeur het rooster wilt.

3. De chauffeur geeft de dag door.

4. Het systeem geeft het rooster van die dag en vraagt of de chauffeur nog iets wil doen.

5. De chauffeur zegt nee.

Alternate paths 5a1. De chauffeur zegt ja.

Ga verder bij 2.

Exception paths n.v.t.
Preconditions n.v.t.
Postconditions De chauffeur ziet zijn rooster.
Related business rules n.v.t.
Use Case: Inloggen
Use case diagram
Description De klant logt in op zijn/haar account.
Source Thijs
Version 3
Actor De klant
Basic course of events 1. (trigger) De klant geeft aan dat hij wil inloggen.

2. Het systeem vraagt om een inlognaam en wachtwoord.

3. De klant voert zijn inlognaam en wachtwoord in.

4. Het systeem geeft aan dat het inloggen gelukt is.

Alternate paths Wachtwoord vergeten

3a1. De klant geeft aan dat hij zijn wachtwoord vergeten is en voert zijn inlognaam in.

3a2. Het systeem vraagt om de verificatiecode die de klant via de mail gekregen heeft.

3a3. De klant voert de verificatiecode in.

3a4. Het systeem geeft aan dat de verificatie gelukt is en vraagt of de klant een nieuw wachtwoord kan invoeren.

3a5. De klant voert een nieuw wachtwoord in.

3a6. Het systeem geeft aan dat het aanpassen van het wachtwoord gelukt is en vraagt om een inlognaam en wachtwoord.

Ga verder bij 3.


Nieuwe verificatiecode

3a3a1. De klant geeft aan dat hij een nieuwe verificatiecode wil ontvangen.

3a3a2. Het systeem geeft aan een nieuwe code verzonden te hebben en vraagt om deze verificatiecode.

Ga verder bij 3a3.

Exception Paths Verkeerde combinatie van inlognaam en wachtwoord ingevoerd

4a1. Het systeem geeft aan dat het inloggen mislukt is en vraagt om een inlognaam en wachtwoord.

Ga verder bij 3.


Verkeerde verificatiecode ingevoerd

3a4a1. Het systeem geeft aan dat de verificatie mislukt is en vraagt opnieuw om de verificatiecode die de klant via de mail gekregen heeft.

Ga verder bij 3a3.


Klant is al ingelogd

2a1. Het systeem geeft aan dat de klant al is ingelogd en stuurt de klant terug naar het hoofdscherm.

Preconditions De klant heeft een account.
Postconditions De klant is ingelogd.
Related business rules De klant kan niet inloggen als hij al ingelogd is.

De klant moet een account geregistreerd hebben om te kunnen inloggen.

Domain Model per Use Case

Taxi bestellen

Use Case Taxi Bestellen A2B Taxi Services.jpg


Account aanmaken

Use Case Account Aanmaken A2B Taxi Services.jpg


Saldo verhogen

Use Case Saldo Verhogen A2B Taxi Services.png


Opdracht accepteren

Use Case A2B Taxi Services Bestelling Accepteren.png

Rooster inzien

Use Case A2B Taxi Services Rooster Inzien.png

Inloggen

Use Case A2B Taxi Services Inloggen.png

Scenarios

Scenarios bij Use Case "Taxi bestellen"

Basic Course of Events & Alternate Path "Contante betaling"

1. Jojo geeft aan dat hij een bestelling wil maken.

2. Het systeem vraagt wat voor soort taxi.

3. Jojo geeft aan dat hij de standaard taxi wil bestellen.

4. Het systeem vraagt om de manier van locatie bepalen.

5. Jojo kiest de GPS-optie.

6. Het systeem vraagt wanneer de taxi aanwezig moet zijn.

7. Jojo geeft aan dat de taxi zo snel mogelijk aanwezig moet zijn.

8. Het systeem laat Jojo alle gegevens van de bestelling zien en vraagt om een bevestiging.

9. Jojo bevestigt de bestelling.

10. Het systeem vraagt hoe Jojo wil betalen.

11/11b1. Jojo kiest de saldo-optie of de contant-optie.

12. Het systeem geeft aan dat het aanvragen en bestellen van een taxi gelukt is.


Alternate Path "Handmatige locatie"

1. Jimmy Jayjay geeft aan dat hij een bestelling wil maken.

2. Het systeem vraagt wat voor soort taxi.

3. Jimmy Jayjay geeft aan dat hij de vergrote taxi wil bestellen.

4. Het systeem vraagt om de manier van locatie bepalen.

5a1. Jimmy Jayjay kiest de Handmatige Locatie-optie.

5a2. Het syteem vraagt de klant om zijn locatie in te voeren.

5a3. Jimmy Jayjay voert zijn locatiegegevens in.

6. Het systeem vraagt wanneer de taxi aanwezig moet zijn.

7. Jimmy Jayjay geeft aan dat de taxi om 16:53 aanwezig moet zijn.

8. Het systeem laat Jimmy Jayjay alle gegevens van de bestelling zien en vraagt om een bevestiging.

9. Jimmy Jayjay bevestigt de bestelling.

10. Het systeem vraagt hoe Jimmy Jayjay wil betalen.

11. Jimmy Jayjay kiest de saldo-optie.

12. Het systeem geeft aan dat het aanvragen en bestellen van een taxi gelukt is.


Alternate Path "Externe betaalmethode"

1. Jon S. geeft aan dat hij een bestelling wil maken.

2. Het systeem vraagt wat voor soort taxi.

3. Jon S. geeft aan dat hij de extra luxe taxi wil bestellen.

4. Het systeem vraagt om de manier van locatie bepalen.

5. Jon S. kiest de GPS-optie.

6. Het systeem vraagt wanneer de taxi aanwezig moet zijn.

7. Jon S. geeft aan dat de taxi om 4 uur aanwezig moet zijn.

8. Het systeem laat Jon S. alle gegevens van de bestelling zien en vraagt om een bevestiging.

9. Jon S. bevestigt de bestelling.

10. Het systeem vraagt hoe Jon S. wil betalen.

11a1. Jon S. kiest de externe betaalmethode-optie.

11a2. Het systeem stuurt Jon S. door naar de gekozen externe betaalmethode.

11a3. Jon S. betaalt via de gekozen methode.

12. Het systeem geeft aan dat het aanvragen en bestellen van een taxi gelukt is.


Exception Path "Geen beschikbare chauffeur"

1. Thijs W. geeft aan dat hij een bestelling wil maken.

2. Het systeem vraagt wat voor soort taxi.

3. Thijs W. geeft aan dat hij de extra luxe taxi wil bestellen.

4. Het systeem vraagt om de manier van locatie bepalen.

5. Thijs W. kiest de GPS-optie.

6. Het systeem vraagt wanneer de taxi aanwezig moet zijn.

7. Thijs W. geeft aan dat de taxi om 5 uur aanwezig moet zijn.

8a1. Het systeem geeft aan dat er op de aangegeven tijd geen beschikbare chauffeur is en vraagt de klant een nieuwe tijd aan te geven.

7. Thijs W. geeft aan dat de taxi om 6 uur aanwezig moet zijn.

8. Het systeem laat Thijs W. alle gegevens van de bestelling zien en vraagt om een bevestiging.

9. Thijs W. bevestigt de bestelling.

10. Het systeem vraagt hoe Thijs W. wil betalen.

11. Thijs W. kiest de saldo-optie.

12. Het systeem geeft aan dat het aanvragen en bestellen van een taxi gelukt is.


Exception Path "Klant annuleert bestelling"

1. Flip van S. geeft aan dat hij een bestelling wil maken.

2. Het systeem vraagt wat voor soort taxi.

3. Flip van S. geeft aan dat hij de limousine wil bestellen.

4. Het systeem vraagt om de manier van locatie bepalen.

5. Flip van S. kiest de GPS-optie.

6. Het systeem vraagt wanneer de taxi aanwezig moet zijn.

7. Flip van S. geeft aan dat de taxi zo snel mogelijk aanwezig moet zijn.

8. Het systeem laat Flip van S. alle gegevens van de bestelling zien en vraagt om een bevestiging.

9c1. Flip van S. geeft aan dat hij de bestelling wil annuleren.

9c2. Het systeem stuurt de klant terug naar het hoofdscherm.


Exception Path "Saldo te laag"

1. Toon L. geeft aan dat hij een bestelling wil maken.

2. Het systeem vraagt wat voor soort taxi.

3. Toon L. geeft aan dat hij de standaard taxi wil bestellen.

4. Het systeem vraagt om de manier van locatie bepalen.

5. Toon L. kiest de GPS-optie.

6. Het systeem vraagt wanneer de taxi aanwezig moet zijn.

7. Toon L. geeft aan dat de taxi om half 2 aanwezig moet zijn.

8. Het systeem laat Toon L. alle gegevens van de bestelling zien en vraagt om een bevestiging.

9. Toon L. bevestigt de bestelling.

10. Het systeem vraagt hoe Toon L. wil betalen.

11. Toon L. kiest de saldo-optie.

12a1. Het systeem geeft aan dat het saldo van de klant te laag is en stuurt de klant terug naar het hoofdscherm.


Exception Path "Externe betaalmethode mislukt"

1. Larry geeft aan dat hij een bestelling wil maken.

2. Het systeem vraagt wat voor soort taxi.

3. Larry geeft aan dat hij de standaard taxi wil bestellen.

4. Het systeem vraagt om de manier van locatie bepalen.

5. Larry kiest de GPS-optie.

6. Het systeem vraagt wanneer de taxi aanwezig moet zijn.

7. Larry geeft aan dat de taxi om 14:58 aanwezig moet zijn.

8. Het systeem laat Larry alle gegevens van de bestelling zien en vraagt om een bevestiging.

9. Larry bevestigt de bestelling.

10. Het systeem vraagt hoe Larry wil betalen.

11a1. Larry kiest de externe betaalmethode-optie.

11a2. Het systeem stuurt Larry door naar de gekozen externe betaalmethode.

11a3. Larry betaalt via de gekozen methode.

11a4. Het systeem geeft aan dat het betalen via de externe betaalmethode mislukt is en stuurt de klant terug naar het hoofdscherm.

Scenarios bij Use Case "Account aanmaken"

Basic Course of Events & Alternate Path "Geen standaard GPS"

1. Jan Klaassen geeft aan dat hij een account wil aanmaken.

2. Het systeem vraagt Jan Klaassen om een inlognaam en wachtwoord in te voeren.

3. Jan Klaassen geeft aan dat hij als inlognaam "J.Klaassen" en als wachtwoord "1234" wil.

4. Het systeem vraagt of Jan Klaassen standaard GPS aan wil hebben.

5/5a1. Jan Klaassen geeft aan dat hij GPS standaard aan of uit wil hebben.

6. Het systeem laat Jan Klaassen zien dat hij een account wil aanmaken met als inlognaam "J.Klaassen", als wachtwoord "1234" en standaard GPS aan of uit wilt hebben en vraagt Jan Klaassen dit te bevestigen.

7. Jan Klaassen bevestigt deze gegevens.

8. Het systeem geeft aan dat het aanmaken van het account gelukt is.


Exception Path "Inlognaam bestaat al"

1. Kees Janssen geeft aan dat hij een account wil aanmaken.

2. Het systeem vraagt Kees Janssen om een inlognaam en wachtwoord in te voeren.

3. Kees Janssen geeft aan dat hij als inlognaam "K.Janssen" en als wachtwoord "30021973" wil.

4a1. Het systeem geeft aan dat de inlognaam al bestaat en vraagt Kees Janssen een andere in te vullen.

3. Kees Janssen geeft aan dat hij als inlognaam "KeesJanssen" wil.

4. Het systeem vraagt of Kees Janssen standaard GPS aan wil hebben.

5. Kees Janssen geeft aan dat hij GPS standaard aan wil hebben.

6. Het systeem laat Kees Janssen zien dat hij een account wil aanmaken met als inlognaam "KeesJanssen", als wachtwoord "30021973" en standaard GPS aan wilt hebben en vraagt Kees Janssen dit te bevestigen.

7. Kees Janssen bevestigt deze gegevens.

8. Het systeem geeft aan dat het aanmaken van het account gelukt is.


Exception Path "De klant annuleert het aanmaken van een account"

1. Barend Bubbeljaegermanjanssen geeft aan dat hij een account wil aanmaken.

2. Het systeem vraagt Barend Bubbeljaegermanjanssen om een inlognaam en wachtwoord in te voeren.

3. Barend Bubbeljaegermanjanssen geeft aan dat hij als inlognaam "BBjj" en als wachtwoord "nummer1" wil.

4. Het systeem vraagt of Barend Bubbeljaegermanjanssen standaard GPS aan wil hebben.

5. Barend Bubbeljaegermanjanssen geeft aan dat hij GPS standaard aan wil hebben.

6. Het systeem laat Barend Bubbeljaegermanjanssen zien dat hij een account wil aanmaken met als inlognaam "BBjj", als wachtwoord "nummer1" en standaard GPS aan wilt hebben en vraagt Barend Bubbeljaegermanjanssen dit te bevestigen.

7a1. Barend Bubbeljaegermanjanssen annuleert het aanmaken van een account.

7a2. Het systeem stuurt de klant terug naar het hoofdscherm.

Scenarios bij Use Case "Saldo verhogen"

Basic Course of Events & Exception Path "De externe betaling gaat fout"

1. Pietje Puk geeft aan dat hij zijn saldo wilt verhogen.

2. Het systeem vraagt Pietje Puk om het gewenste bedrag.

3. Pietje Puk geeft aan dat zijn gewenste bedrag "€15,00" is.

4. Het systeem laat Pietje Puk het gekozen bedrag: "€15,00" zien en vraagt Pietje Puk het te bevestigen.

5. Pietje Puk bevestigt.

6. Het systeem vraagt Pietje Puk om zijn gewenste betaalmethode.

7. Pietje Puk geeft iDeal als gewenste betaalmethode door.

8. Het systeem stuurt Pietje Puk door naar de gewenste betaalmethode: iDeal.

9. Pietje Puk betaalt €15,00 via iDeal.

10a1. Het systeem geeft aan dat Pietje Puks betaling van €15,00 mislukt is, zegt dat Pietje Puk het opnieuw moet proberen en vraagt Pietje Puk naar zijn gewenste betaalmethode.

7. Pietje Puk geeft iDeal als gewenste betaalmethode door.

8. Het systeem stuurt Pietje Puk door naar de gewenste betaalmethode: iDeal.

9. Pietje Puk betaalt €15,00 via iDeal.

10. Het systeem geeft aan dat Pietje Puks betaling van €15,00 gelukt is.


Exception Path "De klant kiest een te hoog bedrag"

1. Bobo Moon geeft aan dat hij zijn saldo wilt verhogen.

2. Het systeem vraagt Bobo Moon om het gewenste bedrag.

3. Bobo Moon geeft aan dat zijn gewenste bedrag "€987654321,00" is.

4a1. Het systeem geeft Bobo Moon aan dat het gekozen bedrag €987654321,00 te hoog is, geeft het limiet van geaccepteerde bedragen: €200,00 en vraagt Bobo Moon naar het gewenste bedrag.

3. Bobo Moon geeft aan dat zijn gewenste bedrag "€100,00" is.

4. Het systeem laat Bobo Moon het gekozen bedrag: €100,00 zien en vraagt Bobo Moon het te bevestigen.

5. Bobo Moon bevestigt.

6. Het systeem vraagt Bobo Moon om zijn gewenste betaalmethode.

7. Bobo Moon geeft iDeal als gewenste betaalmethode door.

8. Het systeem stuurt Bobo Moon door naar de gewenste betaalmethode: iDeal.

9. Bobo Moon betaalt €100,00 via iDeal.

10. Het systeem geeft aan dat Bobo Moon betaling van €100,00 gelukt is.


Exception Path "De klant kiest een bedrag waardoor zijn saldo het maximum zal overschrijden"

1. Henk P. geeft aan dat hij zijn saldo wilt verhogen.

2. Het systeem vraagt Henk P. om het gewenste bedrag.

3. Henk P. geeft aan dat zijn gewenste bedrag "€70,00" is.

4a1. Het systeem geeft Henk P. aan dat het gekozen bedrag €70,00 het maximum van Henks saldo zal overschrijden, geeft het limiet van geaccepteerde bedragen: €20,00 en vraagt Henk naar het gewenste bedrag.

3. Henk P. geeft aan dat zijn gewenste bedrag "€15,00" is.

4. Het systeem laat Henk P. het gekozen bedrag: €15,00 zien en vraagt Henk het te bevestigen.

5. Henk P. bevestigt.

6. Het systeem vraagt Henk P. om zijn gewenste betaalmethode.

7. Henk P. geeft iDeal als gewenste betaalmethode door.

8. Het systeem stuurt Henk P. door naar de gewenste betaalmethode: iDeal.

9. Henk P. betaalt €15,00 via iDeal.


Exception Path "De klant annuleert het verhogen van het saldo"

1. McFred geeft aan dat hij zijn saldo wilt verhogen.

2. Het systeem vraagt McFred om het gewenste bedrag.

3. McFred geeft aan dat zijn gewenste bedrag "€20,00" is.

4. Het systeem laat McFred het gekozen bedrag: "€20,00" zien en vraagt McFred het te bevestigen.

5a1. McFred annuleert het verhogen van het saldo.

5a2. Het systeem laat zien dat het verhogen van het saldo geannuleerd is en gaat terug naar het hoofdscherm.

Scenarios bij Use Case "Opdracht accepteren"

Basic course of events & Alternate Path "De chauffeur wijst de opdracht af"

1. Het systeem toont een opdracht aan Obamama.

2/2a1. Obamama accepteert de opdracht of wijst hem af.

Scenarios bij Use Case "Rooster inzien"

Basic course of events & Alternate Path "De chauffeur zegt ja"

1. Walter Sobchak vraagt zijn rooster op.

2. Het systeem vraagt van welke dag Walter zijn rooster wilt.

3. Walter geeft zaterdag door.

4. Het systeem geeft door dat Walter niet werkt op zaterdag en vraagt of Walter van een andere dag wilt weten.

5/5a1. Walter geeft of een dag door (ga verder bij 2) of zegt nee.

Scenarios bij Use Case "Inloggen"

Basic Course of Events & Exception Path "Verkeerde combinatie van inlognaam en wachtwoord ingevoerd"

1. Petey B geeft aan dat hij wil inloggen.

2. Het systeem vraagt om een inlognaam en wachtwoord.

3. Petey B voert zijn inlognaam 'Stud_muffin' en wachtwoord 'babycats' in.

4a1. Het systeem geeft aan dat het inloggen mislukt is en vraagt om een inlognaam en wachtwoord.

3. Petey B voert zijn inlognaam 'Stud_muffin' en wachtwoord 'kittens' in.

4. Het systeem geeft aan dat het inloggen gelukt is.


Alternate Path "Wachtwoord vergeten" & Exception Path "Verkeerde verificatiecode ingevoerd"

1. Bobby B geeft aan dat hij wil inloggen.

2. Het systeem vraagt om een inlognaam en wachtwoord.

3a1. Bobby B geeft aan dat hij zijn wachtwoord vergeten is en voert zijn inlognaam 'Bobby_B' in.

3a2. Het systeem vraagt om de verificatiecode die Bobby B via de mail gekregen heeft.

3a3. Bobby B voert verificatiecode 'H83jDH5' in.

3a4a1. Het systeem geeft aan dat de verificatie mislukt is.

3a3. Bobby B voert verificatiecode 'H83JDH5' in.

3a4. Het systeem geeft aan dat de verificatie gelukt is en vraagt of Bobby B een nieuw wachtwoord kan invoeren.

3a5. Bobby B voert nieuw wachtwoord 'powderedsugar' in.

3a6. Het systeem geeft aan dat het aanpassen van het wachtwoord gelukt is en vraagt om een inlognaam en wachtwoord.

3. Bobby B voert zijn inlognaam 'Bobby_B' en wachtwoord 'powderedsugar' in.

4. Het systeem geeft aan dat het inloggen gelukt is.


Alternate Path "Nieuwe verificatiecode"

1. Terry L geeft aan dat hij wil inloggen.

2. Het systeem vraagt om een inlognaam en wachtwoord.

3a1. Terry L geeft aan dat hij zijn wachtwoord vergeten is en voert zijn inlognaam 'TerryL' in.

3a2. Het systeem vraagt om de verificatiecode die Terry L via de mail gekregen heeft.

3a3a1. Terry L geeft aan dat hij een nieuwe verificatiecode wil ontvangen.

3a3a2. Het systeem geeft aan een nieuwe code verzonden te hebben en vraagt om deze verificatiecode.

3a3. Terry L voert verificatiecode 'ADJH736' in.

3a4. Het systeem geeft aan dat de verificatie gelukt is en vraagt of Bobby B een nieuw wachtwoord kan invoeren.

3a5. Terry L voert nieuw wachtwoord 'pikachu' in.

3a6. Het systeem geeft aan dat het aanpassen van het wachtwoord gelukt is en vraagt om een inlognaam en wachtwoord.

3. Terry L voert zijn inlognaam 'TerryL' en wachtwoord 'pikachu' in.

4. Het systeem geeft aan dat het inloggen gelukt is.


Exception Path "Klant is al ingelogd"

1. Jimmy Whisper geeft aan dat hij wil inloggen.

2a1. Het systeem geeft aan dat Jimmy Whisper al is ingelogd en stuurt hem terug naar het hoofdscherm.

Non-functional Requirements

  • Gebruiksvriendelijk - Het systeem moet makkelijk te gebruiken zijn voor zowel de klanten als de chauffeurs. Dit wordt bereikt d.m.v. :
    • Overzichtelijk: Het moet duidelijk zijn voor de gebruiker waar op het hoofdscherm alle functies van het systeem zitten en met welke functie de gebruiker op het moment bezig is.
    • Simpel: De gebruiker moet maar een klein aantal stappen doorgaan tijdens het gebruik van de applicatie.
  • Controleerbaarheid - Over elke rit moet informatie bijgehouden worden. Deze informatie moet bevatten:
    • Klantgegevens: Gegevens van de klant die de bestelling heeft gemaakt. (Accountnaam)
    • Betaalgegevens: Gegevens over de betaling. (Bedrag, Betaalmethode, is wel/niet betaald)
    • Bestellinggegevens: Gegevens over de bestelling. (Tijd, Locatie, soort taxi, taxi-chauffeur)
  • Beschikbaarheid - Het systeem moet altijd werken tijdens werktijden.

Addendum

Integrated Domainmodel

Integrated Domain Model A2B Taxi Services.jpg

Business Rules Catalogue

  • Elke inlognaam mag maar één keer gebruikt worden.
  • Een klant mag zijn saldo niet met meer dan 200 euro per keer verhogen.
  • De klant heeft een maximum saldo van 500 euro.
  • Een chauffeur mag maar met één opdracht tegelijkertijd bezig zijn.
  • De klant kan geen taxi bestellen als die al een taxi besteld heeft.
  • De klant kan niet inloggen als hij al ingelogd is.
  • De klant moet een account geregistreerd hebben om te kunnen inloggen.

Terminological Definitions

  • De klant is een persoon die gebruik wil maken van de services van A2B.
  • De taxichauffeur is een werknemer van A2B die een bepaald rooster heeft en opdrachten behandelt.
  • De centrale is een tussenpersoon die opdrachten overbrengt van een klant naar een individuele taxichauffeur en de roosters bijhoudt.
  • Een verificatiecode is een unieke code die het systeem via e-mail aan de klant verstuurt, zodat de klant na het invoeren van deze code zijn wachtwoord kan aanpassen.
  • De locatiegegevens bevatten het adres (inclusief huisnummer) en stad.
  • De soort taxi is een van de vier soorten taxi's die A2B aanbiedt, namelijk: normale 4-persoons taxi, een vergrote 6-persoons taxi, een extra luxe taxi of een limousine.
  • Een externe betaalmethode is een programma onafhankelijk van A2B waarmee de klant A2B kan betalen voor het bestellen van een taxi, denk hierbij aan dingen zoals PayPal en iDeal.