Requirements Engineering/het werk/werkstuk/2012-13/Groep 03

Uit Werkplaats
Ga naar: navigatie, zoeken

 






Modehuis Walraven   |   Requirements Engineering



Werkstuk Requirements Engineering


Jip Dekker, Matthijs Hendriks, Demian Janssen, Tim Janssen, Paul van Poecke



Onderwijsinstituut voor Informatica en Informatiekunde

Radboud Universiteit Nijmegen






version 18 februari 2022

Page Break




Introduction

Modehuis Walraven is een dames-, heren-, en kinderkledingzaak opgericht door meneer en mevrouw Walraven in 1900. Het bedrijf verkoopt niet alleen kleren maar kan kleren ook laten bijstellen. Modehuis Walraven is gevestigd te Wijchen en heeft vier werknemers die allemaal als medewerker in dit filiaal werken. De administratie en de voorraad worden momenteel bijgehouden op papier en verzameld in mappen. Modehuis Walraven is van plan om twee nieuwe filialen te openen, ieder met weer vier medewerkers. Om het overzicht over de voorraad, financiën en de bijstelaanvragen te behouden bij de uitbreiding (naar in totaal 3 filialen) hebben Meneer en Mevrouw besloten om gebruik te gaan maken van een computersysteem.

In dit document zullen we allereerst de huidige knelpunten en problemen beschrijven. Vervolgens zullen we in de 'Case analysis' een analyse van de stakeholders uiteenzetten, de stakeholders zijn de partijen voor wie het nieuwe systeem relevant is. Ook zullen we de 'Mission Vision' (MV) formuleren en een risico-analyse maken. Daarna zullen we in de sectie 'Requirements' de non-functional requirements - eisen die niet van invloed zijn op de functionaliteit van het systeem - geven. Ook zullen we de Use Cases beschrijven en voor elke Use Case een mogelijk scenario geven. Use cases zijn alle mogelijke actie-reeksen die het systeem moet kunnen ondersteunen, bijvoorbeeld een bijstelaanvraag doen. Tot slot hebben we een 'Appendum' bijgevoegd waarin het domeinmodel, de 'business Rule Catalog' en de terminologische definities gevonden kunnen worden.

Problem statement

Alle administratie gebeurt op dit moment handmatig, in enkele mappen. Dit werkte altijd prima, maar omdat het modehuis gaat uitbreiden van één filiaal naar drie filialen zal dit systeem niet meer voldoen, want dan:

  • is er geen totaaloverzicht van de voorraden van alle filialen;
  • moet er tussen de filialen heen en weer gereisd worden voor controle op de gang van zaken;
  • is er geen overzicht m.b.t. de verantwoordelijke voor de bijstelaanvragen.

Verder is het mogelijk om een bijstelaanvraag in een ander filiaal op te halen dan waar je deze aangevraagd hebt. Hiervoor is ook een goede communicatie tussen de filialen onderling nodig, anders gaat het al snel fout.

Om het overzicht van de financiën, bijstelaanvragen en voorraden te behouden wil Modehuis Walraven overschakelen naar een computersysteem.

Case analysis

Stakeholder analysis

Stakeholder Omschrijving
Mevrouw Walraven & Meneer Walraven

Zij zijn de opdrachtgevers en eigenaars van Modehuis Walraven en daarmee dus de belangrijkste stakeholders. Zij moeten alle functionaliteiten van het systeem kunnen gebruiken.

Het personeel

Het personeel is verantwoordelijk voor het afhandelen van verkopen en bijstelaanvragen. Zij houden zich voornamelijk bezig met de interactie met de klant.

Mission and vision statement

In dit onderdeel zal uitgewerkt worden wat volgens meneer en mevrouw Walraven het project zal moeten gaan doen (Mission), wat het eindproduct zal zijn (Vision).

Mission

Het systeem dat ontwikkeld zal worden bij dit project zal ervoor zorgen dan dhr. en mevr. Walraven de huidige functionaliteit en overzicht behouden bij een uitbreiding naar meerdere filialen. Zonder dat dit systeem van grote invloed zal zijn op de werkwijze van meneer en mevrouw Walraven en hun werknemers.

Vision

Het eindproduct is een systeem dat Modehuis Walraven het door hen gewenste overzicht en functionaliteit kan bieden over alle filialen. Het systeem biedt de mogelijkheid om de voorraad te beheren, een overzicht van de financiën te krijgen, het assortiment te beheren en bijstelaanvragen te beheren. Dit systeem moet zodanig zijn dat de overstap van het huidige systeem naar het nieuwe vlekkeloos verloopt. Verder zal het systeem het gebruiksgemak verbeteren ten opzichte van het huidige systeem omdat het eenvoudig en intuïtief werkt en meer mogelijkheden biedt. We willen een systeem maken dat naar tevredenheid in alle filialen gebruikt wordt voor inkoop, verkoop, beheer en overzicht.

Statement of work

Deadlines

  • Facade iteratie: 19 april
  • Filled iteratie: 24 mei
  • Focused iteratie: 21 juni

Statussen

Code Betekenis Uitleg
V Voltooid Deliverable is nagekeken door minstens 1 teamlid en is klaar om ingeleverd te worden.
C Controleren Deliverable is gemaakt door de verantwoordelijk en dient te worden gecontroleerd/verbeterd door een groepslid.
B Bezig Deliverable is in de maak op de wiki.
NG Niet gestart Het maken van deze deliverable is nog niet (op de wiki, voor deze facade) gestart.
NV Niet vereist Deliverable is (in deze iteratie) niet vereist.

Status deliverables

Deliverable Verantwoordelijke Facade iteratie Status Filled iteratie Status Focused iteratie Status
Introduction Tim Preliminary version V Preliminary version V Complete V
Problem statement Matthijs As good as possible V As good as possible V Complete V
Stakeholder analysis Matthijs As good as possible V As good as possible V Complete V
Mission-vision statement Matthijs Complete V Complete V Complete V
Statement of work Tim Complete, and up-to-date V Complete, and up-to-date V Complete, and up-to-date V
Risk analysis Matthijs Complete, and up-to-date V Complete, and up-to-date V Complete, and up-to-date V
Use case survey Démian As good as possible V Nearly complete V Complete, and up-to-date V
Integrated UC diagram Démian Complete (though preliminary) V Complete V Complete V
Use cases Groep Not yet! NV "Filled" level V Complete V
Scenarios Groep Not yet! NV Several for each UC V Complete ("focused" level) V
Domain models Jip Not yet! NV Partially complete V Complete V
Integrated domain model Groep Not yet! NV Partially complete V Complete V
Business rules catalogue Groep Not yet! NV Partially complete V Complete V
Non-functional requirements Jip Notes V Partially complete V Complete V
Terminological definitions Jip Notes V Partially complete V Complete V
Executive sponsor viewpoint Tim Complete (integrated in M-V-V!) V Complete (integrated in M-V-V!) V Complete (integrated in M-V-V!) V
Use case tests Jip Notes V As good as possible V Complete V
Business process definitions Groep If available / relevant NV If relevant NV If relevant NV
GUI metaphors / storyboards Groep If relevant NV If relevant NV If relevant NV

Risk analysis

# Categorie Risico Oplossing vereist voor Status Dagen kwijt Verwachtingsfactor Risicofactor
1 Team Een teamlid wordt ziek De deadline 4 20% 4
2 Team Een teamlid stop met RE2 De deadline 40 1% 8
3 Team Een teamlid verzet te weinig werk De deadline 10 10% 6
4 Planning Het is meer werk dan geschat De deadline 1+ 20% 6
5 Communicatie De interne communicatie verloopt moeizaam De deadline 2 30% 5
6 Communicatie De communicatie met de stakeholder verloopt moeizaam De deadline 4 30% 5
7 Communicatie Benodigde informatie van de stakeholder ontbreekt De deadline 2 70% 2
8 Techniek Gemaakt werk gaat verloren door technisch falen De deadline 1 10% 3
9 Juridisch Delen van het systeem moeten opnieuw worden ontworpen i.v.m. gebruik propriëtair materiaal De deadline 1 3% 4

Requirements

Use cases

Use case survey

# Name Description Initiating actor
01 Bekijk artikeloverzicht De medewerker kan het overzicht bekijken van alle artikelen per filiaal. Medewerker
02 Beheer artikeloverzicht De eigenaar kan een artikel invoeren, verwijderen of wijzigen in het overzicht van alle artikelen. Eigenaar
03 Bekijk verkoopoverzicht De eigenaar kan het overzicht bekijken van alle verkochte producten per filiaal. Eigenaar
04 Verkoop artikel De medewerker kan een verkocht artikel invoeren in het overzicht van verkochte producten van het filiaal waar deze medewerker werkt. Medewerker
05 Retourneer artikel De medewerker kan teruggebracht artikel invoeren in het overzicht van verkochte producten van het filiaal waar deze medewerker werkt. Medewerker
06 Bekijk bijstelopdrachten De medewerker kan de bijstelopdrachten van alle filialen bekijken. Medewerker
07 Invoer bijstelopdracht De medewerker kan bijstelopdrachten invoeren in het overzicht van de bijstelopdrachten van het filiaal waar deze medewerker werkt. Medewerker
08 Beheer bijstelopdrachten De medewerker kan bijstelopdrachten wijzigen. Medewerker
09 Bijstelopdracht afrekenen De medewerker kan bijstelopdrachten afrekenen. Medewerker
10 Bekijk financiën De eigenaar kan zijn/haar financiën bekijken, zowel de inkomsten als de uitgaven. Eigenaar

Integrated use case diagram

Integrated use case diagram.png

Individual use cases

Bekijk artikeloverzicht

Use Case Bekijk artikeloverzicht
Use Case Number 01
Description De Medewerker kan het overzicht bekijken van alle Artikelen per filiaal.
Version 1.1
Actors Medewerker
Triggers De Medewerker geeft aan het Artikeloverzicht te willen zien.
Basic course of events

Toon Artikeloverzicht lokaal Filiaal

  1. De Medewerker vraagt het Artikeloverzicht op.
  2. Het systeem laat het Artikeloverzicht zien van het Filiaal waar de Medewerker is.
Alternate paths

Toon Artikeloverzicht ander Filiaal

  1. De Medewerker vraagt het Artikeloverzicht op.
  2. Het systeem laat het Artikeloverzicht zien van het Filiaal waar de Medewerker is.
  3. De Medewerker geeft aan het Artikeloverzicht van een ander Filiaal te laten zien.
  4. Het systeem laat het Artikeloverzicht van het aangegeven Filiaal zien.
Exception paths

Er zijn geen Artikelen

  1. Het systeem geeft aan dat er geen Artikelen zijn.
Assumptions -
Preconditions Medewerker is geïdentificeerd
Postconditions Het Artikeloverzicht is getoond.
Related business rules -
Author P.H.J. van Poecke
Date 13-6-2013

Domainmodel 2013-Groep03-artikeloverzicht.png

Beheer artikeloverzicht

Use Case Beheer artikeloverzicht
Use case number 02
Description De Eigenaar kan een Artikel invoeren, verwijderen of wijzigen in het overzicht van alle artikelen.
Version 1.1
Actors Eigenaar
Triggers De Eigenaar geeft aan het Artikeloverzicht te willen beheren.
Basic course of events

Artikel invoeren

  1. De Eigenaar geeft aan het Artikeloverzicht te willen beheren.
  2. Het systeem toont het Artikeloverzicht.
  3. De Eigenaar geeft aan een Artikel te willen invoeren.
  4. Het systeem vraagt de Eigenaar om Artikelgegevens.
  5. De Eigenaar voert de gegevens in en bevestigt de invoer.
Alternate paths

Artikel verwijderen

  1. De Eigenaar geeft aan het Artikeloverzicht te willen beheren.
  2. Het systeem toont het Artikeloverzicht.
  3. De Eigenaar geeft aan een bepaald Artikel te willen verwijderen.
  4. Het systeem vraagt om bevestiging van het te verwijderen Artikel.
  5. De Eigenaar bevestigt dat het Artikel verwijderd moet worden.

Artikel wijzigen

  1. De Eigenaar geeft aan het Artikeloverzicht te willen beheren.
  2. Het systeem toont het Artikeloverzicht.
  3. De Eigenaar geeft aan een bepaald Artikel te willen wijzigen.
  4. Het systeem toont het te wijzigen Artikel op een manier dat het gewijzigd kan worden.
  5. De Eigenaar wijzigt het artikel en bevestigt de invoer.
Exception paths

Exception Path: Artikel wijzigen of invoeren - Actie annuleren

  1. Eigenaar geeft aan dat hij/zij de actie wil annuleren

Use case gaat terug naar 2.

Exception Path: Artikel wijzigen of invoeren - Foutieve gegevens invoer

  1. Het systeem geeft aan dat een van de ingevoerde of gewijzigde gegevens niet zo in het systeem kan worden opgeslagen.

Use case gaat terug naar 4.

Exception Path: Artikel verwijderen - Artikel niet verwijderen

  1. Eigenaar geeft aan het Artikel niet te willen verwijderen.

Use case gaat terug naar 2.

Assumptions -
Preconditions Medewerker is geïdentificeerd.
Postconditions

Het systeem heeft het Artikeloverzicht bijgewerkt en het vernieuwde Artikeloverzicht weergegeven.

Related business rules -
Author P.H.J. van Poecke
Date 13-6-2013

Domainmodel 2013-Groep03-beheerartikeloverzicht.png

Bekijk verkoopoverzicht

Use Case Bekijk verkoopoverzicht
Use case number 03
Description De Eigenaar kan het overzicht bekijken van alle verkochte producten per filiaal
Version 1.1
Actors Eigenaar
Triggers De Eigenaar geeft aan het Verkoopoverzicht te willen zien.
Basic course of events

Toon Verkoopoverzicht lokaal filiaal

  1. De Eigenaar geeft aan het Verkoopoverzicht te willen zien.
  2. Het systeem laat het Verkoopoverzicht zien van het Filiaal waar de Eigenaar is.
Alternate paths

Toon Verkoopoverzicht ander filiaal

  1. De Eigenaar geeft aan het Verkoopoverzicht te willen zien.
  2. Het systeem laat het Verkoopoverzicht zien van het Filiaal waar de Eigenaar is.
  3. De Eigenaar geeft aan het Verkoopoverzicht van een ander Filiaal te laten zien.
  4. Het systeem laat het Verkoopoverzicht van het aangegeven Filiaal zien.
Exception paths

Het Verkoopoverzicht is leeg

  1. Het systeem geeft aan dat het Verkoopoverzicht leeg is.
Assumptions -
Preconditions Medewerker is geïdentificeerd.
Postconditions Het Verkoopoverzicht is getoond.
Related business rules -
Author P.H.J. van Poecke
Date 13-6-2013

Domainmodel 2013-Groep03-verkoopoverzicht.png

Verkoop artikel

Use Case Verkoop artikel
Use case number 04
Description De Medewerker kan een verkocht Artikel invoeren in het overzicht van verkochte producten van het Filiaal waar deze Medewerker werkt.
Version 1.4
Actors Medewerker
Triggers De Medewerker geeft aan een artikel te willen verkopen
Basic course of events

Verkoop artikel

  1. De Medewerker identificeert het Artikel
  2. Het systeem toont de Artikelgegevens en geeft het totaalbedrag van de Aankoop weer
  3. De Medewerker geeft aan de betaling te willen doen
  4. Het systeem meldt dat de betaling is afgerond
Alternate paths

Meerdere artikelen per verkoop

  1. De Medewerker geeft aan nog een Artikel te willen retourneren
  2. Het systeem vraag om het Artikel te identificeren
  3. De Medewerker identificeert het Artikel
  4. Het systeem geeft van de tot nu toe geïdentificeerde Artikelen de Artikelgegevens weer. Tevens geeft het systeem de totaalprijs weer

Use case gaat terug naar 3

Artikel toch niet kopen

  1. De Medewerker geeft aan een Artikel toch niet te willen verkopen
  2. Het systeem vraagt om welk Artikel het gaat.
  3. De Medewerker geeft aan om welk Artikel het gaat.
  4. Het systeem verwijdert het Artikel uit de tot nu toe geïdentificeerde artikelen en laat per Artikel de Artikelgegevens zien. Tevens zal het systeem het totaalbedrag van de Aankoop weergeven.

Use case gaat terug naar 3

Exception paths

Betaling mislukt

  1. Het systeem geeft aan dat de betaling is mislukt

Use case gaat terug naar 3

Het Artikel is niet bekend in het systeem

  1. Het systeem geeft aan dat het Artikel niet bekend is in het systeem

Use case gaat terug naar 1

Assumptions -
Preconditions
  • Medewerker is geïdentificeerd
Postconditions
  • Systeem heeft de huidige Voorraad bijgewerkt
  • Systeem heeft het Artikel verwerkt in de Verkopen
Related business rules B02, B03, B05
Author Tim Janssen
Date 21-6-2013

Domainmodel 2013-Groep03-verkoopartikel.png

Retourneer artikel

Use Case Retourneer artikel
Use case number 05
Description De Medewerker kan een teruggebracht Artikel invoeren in het overzicht van verkochte producten van het filiaal waar deze Medewerker werkt.
Version 1.3
Actors Medewerker
Triggers De Medewerker geeft aan een Artikel te willen retourneren.
Basic course of events

Retourneer artikel

  1. Het systeem vraagt om identificatie van het Artikel.
  2. De Medewerker identificeert het Artikel.
  3. Het systeem laat van het Artikel de Artikelgegevens en de totale teruggaveprijs zien.
  4. De Medewerker bevestigt het retourneren.
  5. Het systeem bevestigt het verwerken van de retourneeropdracht.
Alternate paths

Retourneer meerdere artikelen

  1. De Medewerker geeft aan nog een artikel te willen retourneren.
  2. Systeem vraag om het Artikel te identificeren.
  3. De Medewerker identificeert het Artikel.
  4. Het systeem laat de Artikelgegevens zien van alle, in deze use case aangegeven, Artikelen.

Use case gaat verder bij 4.

Exception paths Het Artikel kan niet geïdentificeerd worden
  1. Het systeem geeft aan dat het Artikel niet geïdentificeerd kan worden.

Use case gaat verder bij 1.

Assumptions -
Preconditions
  • Medewerker is geïdentificeerd.
Postconditions
  1. Systeem heeft het geretourneerde Artikel in de huidige Voorraad toegevoegd.
  2. Systeem heeft het geretourneerde Artikel in het Verkoopoverzicht verwerkt met een negatieve prijs.
Related business rules B01
Author Tim Janssen
Date 21-6-2013

Domainmodel 2013-Groep03-retourneer.png

Bekijk bijstelopdrachten

Use Case Bekijk Bijstelopdrachten
Use case number 06
Description De medewerker kan de Bijstelopdrachten van alle Filialen bekijken.
Version 1.1
Actors Medewerker
Triggers Medewerker geeft aan de Bijstelopdrachten te willen zien.
Basic course of events

Toon Bijstelopdrachten lokaal Filiaal

  1. Medewerker geeft aan de Bijstelopdrachten te willen zien.
  2. Het systeem toont de Bijstelopdrachten van het Filiaal waar de Medewerker is.
Alternate paths

Toon Bijstelopdrachten ander Filiaal

  1. Medewerker geeft aan enkel de Bijstelopdrachten van een ander Filiaal te willen zien.
  2. Het systeem toont de Bijstelopdrachten van het desbetreffende Filiaal.
Exception paths Er zijn geen Bijstelopdrachen
  1. Systeem meldt dat er geen Bijstelopdrachten zijn in dit filiaal

Use case gaat naar 1

Assumptions -
Preconditions
  • Er is een lijst van Bijstelopdrachten in het systeem
  • Medewerker is geïdentificeerd
Postconditions
  • De Medewerker heeft inzicht in de Bijstelopdrachten van het opgevraagde filiaal.
Related business rules -
Author Démian Janssen
Date 13-6-2013

Domainmodel 2013-Groep03-bijstelopdrachten.png

Invoer Bijstelaanvraag

Use Case Invoer Bijstelopdrachten
Use case number 07
Description De Medewerker kan een nieuwe Bijstelaanvraag invoeren in het systeem.
Version 1.3
Actors Medewerker
Triggers De Medewerker geeft aan een Bijstelaanvraag in te willen voeren.
Basic course of events

Invoer Bijstelaanvraag

  1. Het Systeem vraagt om de Bijstelgegevens van de nieuwe Bijstelaanvraag.
  2. De Medewerker geeft de Bijstelgegevens van de nieuwe Bijstelaanvraag en bevestigt de aanvraag.
  3. Het systeem bevestigt dat de Bijstelaanvraag is voltooid.
Alternate paths

Annuleer invoer Bijstelaanvraag

  1. De Medewerker geeft aan dat de Bijstelaanvraag geannuleerd moet worden.
  2. Het systeem meldt dat de Bijstelaanvraag is geannuleerd.
Exception paths

Verkeerde invoer

  1. Het systeem meldt dat er verkeerde Bijstelgegevens zijn gegeven.

Use case gaat terug naar 1.

Assumptions -
Preconditions
  • De Medewerker is geïdentificeerd.
Postconditions
  • De gegevens van de Bijstelaanvraag zijn opgeslagen.
Related business rules B09, B10
Author Tim Janssen
Date 21-6-2013

Domainmodel 2013-Groep03-bijstelopdrachten.png

Beheer bijstelopdrachten

Use Case Beheer Bijstelopdrachten
Use case number 08
Description De Medewerker kan Bijstelopdrachten beheren.
Version 1.0
Actors Medewerker
Triggers De Medewerker geeft aan een Bijstelopdracht te willen beheren.
Basic course of events
  1. De Medewerker geeft aan zijn Bijstelopdrachten te willen beheren.
  2. Het systeem laat zijn Bijstelopdrachten zien.
  3. De Medewerker kiest de te beheren Bijstelopdracht.
  4. Het systeem toont de Bijstelgegevens van de Bijstelopdracht.
  5. De Medewerker geeft aan de Bijstelopdracht te willen bewerken.
  6. Het systeem vraagt de nieuwe Bijstelgegevens van de Bijstelopdracht.
  7. De Medewerker specificeert de nieuwe Bijstelgegevens en bevestigt ze.
  8. Het systeem bevestigt de wijziging.
Alternate paths

Verantwoordelijke wijzigen

  1. De Eigenaar geeft aan de Bijstelopdrachten te willen beheren.
  2. Het systeem laat de Bijstelopdrachten zien.
  3. De Eigenaar kiest de te beheren Bijstelopdracht.
  4. Het systeem toont de gekozen Bijstelopdracht.
  5. De Eigenaar geeft aan dat hij de verantwoordelijke wil wijzigen.
  6. Het systeem vraagt de nieuwe verantwoordelijke Medewerker.
  7. De Eigenaar specificeert de nieuwe verantwoordelijke en bevestigt dit.
  8. Het systeem bevestigt de wijziging.
Exception paths Ongeldige gegevens ingevoerd
  1. De ingevoerde gegevens zijn ongeldig.

De use case gaat verder bij 7.

Assumptions -
Preconditions
  • Medewerker is geïdentificeerd.
Postconditions
  • De Bijstelopdracht is gewijzigd.
Related business rules B09, B10, B13
Author Matthijs Hendriks
Date 19-6-2013

Domainmodel 2013-Groep03-beheerbijstelopdrachten.png

Bijstelopdracht afrekenen

Use Case Bijstelopdrachten afrekenen
Use case number 09
Description De Medewerker kan Bijstelopdrachten afrekenen.
Version 1.0
Actors Medewerker
Triggers De Medewerker geeft aan een Bijstelopdracht te willen afrekenen.
Basic course of events
  1. De Medewerker geeft aan de Bijstelopdrachten te willen zien.
  2. Het systeem toont de Bijstelopdrachten van het Filiaal waar de Medewerker is.
  3. De Medewerker kiest de af te rekenen Bijstelopdracht.
  4. Het systeem toont de gekozen Bijstelopdracht en laat de totale kosten zien.
  5. De Medewerker geeft aan de betaling te willen doen.
  6. Het Systeem meldt dat de betaling is afgerond.
Alternate paths

Bijstelopdracht annuleren

  1. Medewerker geeft aan een Bijstelopdracht te willen annuleren.
  2. Het systeem toont de Bijstelopdrachten van het Filiaal waar de Medewerker is.
  3. De Medewerker kiest de te annuleren Bijstelopdracht.
  4. Het systeem toont de gekozen Bijstelopdracht en laat de tot nu gemaakte kosten zien.
  5. De Medewerker geeft aan de betaling te willen doen.
  6. Het Systeem meldt dat de betaling is afgerond.
Exception paths

Betaling is mislukt

  1. Het systeem geeft aan dat de betaling is mislukt.

Use case gaat terug naar 4.

Bijstelopdracht onbekend

  1. Het systeem geeft aan dat de Bijstelopdracht onbekend is voor het huidige Filiaal.

Use case gaat terug naar 2.

Assumptions -
Preconditions
  • De Medewerker is geïdentificeerd.
Postconditions
  • Het telefoonnummer van de Klant is verwijderd.
Related business rules B04, B11
Author Matthijs Hendriks
Date 19-6-2013

Domainmodel 2013-Groep03-bijstelafrekenen.png

Bekijk financiën

Use Case Bekijk Financieel overzicht
Use case number 10
Description De Eigenaar kan het Financieel overzicht bekijken, zowel de inkomsten als de uitgaven.
Version 1.4
Actors Eigenaar
Triggers Eigenaar geeft aan het Financiëel overzicht te willen zien.
Basic course of events
  1. Eigenaar geeft aan het Financiëel overzicht te willen zien.
  2. Het systeem geeft een overzicht van de financiën van de huidige maand.
Alternate paths

Specifieke Maandweergave

  1. Eigenaar geeft aan het Financiëel overzicht te willen zien.
  2. Het systeem geeft een overzicht van de financiën van de huidige maand.
  3. Eigenaar geeft aan welke maand hij/zij wil zien.
  4. Het systeem geeft een overzicht van de financiën van de gewenste maand.

Dagweergave

  1. Eigenaar geeft aan het Financiëel overzicht te willen zien.
  2. Het systeem geeft een overzicht van de financiën van de huidige maand.
  3. Eigenaar geeft aan een dagweergave van de financiën te willen zien.
  4. Het systeem geeft een overzicht van de financiën van de vorige dag.

Specifieke Dagweergave

  1. Eigenaar geeft aan het Financiëel overzicht te willen zien.
  2. Het systeem geeft een overzicht van de financiën van de huidige maand.
  3. Eigenaar geeft aan een dagweergave van de financiën te willen zien.
  4. Het systeem geeft een overzicht van de financiën van de vorige dag.
  5. Eigenaar geeft aan welke dag hij/zij wil zien.
  6. Het systeem geeft een overzicht van de financiën van de gewenste dag.

Jaarweergave

  1. Eigenaar geeft aan het Financiëel overzicht te willen zien.
  2. Het systeem geeft een overzicht van de financiën van de huidige maand.
  3. Eigenaar geeft aan een jaarweergave van de financiën te willen zien.
  4. Het systeem geeft een overzicht van de financiën van het huidige jaar.

Specifieke Jaarweergave

  1. Eigenaar geeft aan het Financiëel overzicht te willen zien.
  2. Het systeem geeft een overzicht van de financiën van de huidige maand.
  3. Eigenaar geeft aan een jaarweergave van de financiën te willen zien.
  4. Het systeem geeft een overzicht van de financiën van het huidige jaar.
  5. Eigenaar geeft aan welk jaar hij/zij wil zien.
  6. Het systeem geeft een overzicht van de financiën van het gewenste jaar.
Exception paths

Nog geen financiële gegevens van gevraagde periode

  1. Het systeem geeft aan nog geen financiële gegevens te hebben van de gevraagde periode.

Use case gaat terug naar 1. Dit exception path is ook van toepassing op de alternate paths, waar het systeem een overzicht zou geven van de financiën , maar er nog geen gegevens in deze periode bekend zijn.

Assumptions -
Preconditions
  • Eigenaar is geïdentificeerd
Postconditions
  • Het Financieel overzicht van de gevraagde periode is getoond.
Related business rules B12
Author Jip J. Dekker
Date 23-05-2013

Domainmodel 2013-Groep03-financien.png

Scenarios

Bekijk artikeloverzicht

Scenario 1 - Basic Course of Events

  1. Hubert-Klaas vraagt het Artikeloverzicht op.
  2. Het systeem laat het Artikeloverzicht zien van Filiaal Wijchen waar Hubert-Klaas zich bevindt.

Scenario 2 - Alternate Path: Toon Artikeloverzicht lokaal filiaal

  1. Shaniqua vraagt het Artikeloverzicht op.
  2. Het systeem laat het Artikeloverzicht zien van Filiaal Arnhem waar Shaniqua zich bevindt.
  3. Shaniqua geeft aan het Artikeloverzicht van Filiaal Detroit te willen zien.
  4. Het systeem laat het Artikeloverzicht van Filiaal Detroit zien.

Scenario 3 - Exception Path: Er zijn geen Artikelen

  1. Sjonnie vraagt het Artikeloverzicht op.
  2. Het systeem geeft aan dat het Artikeloverzicht leeg is.

Beheer artikeloverzicht

Scenario 1 - Basic Course of Events

  1. Anita geeft aan het Artikeloverzicht te willen beheren.
  2. Het systeem toont het Artikeloverzicht.
  3. Anita geeft aan een witte onderbroek te willen invoeren.
  4. Het systeem vraagt de Anita om Artikelgegevens.
  5. Anita voert een witte onderbroek in van maat XXXL van prijs 5.95 van merk Fabulicious met de omschrijving Tighty whities in categorie ondergoed met inkoopprijs 2.95 waarvan er 5 aanwezig zijn in Filiaal Malden, en bevestigd naderhand de invoer.

Scenario 2 - Alternate Path: Artikel verwijderen

  1. Sjaak geeft aan het Artikeloverzicht te willen beheren.
  2. Het systeem toont het Artikeloverzicht.
  3. Sjaak geeft aan het Luipaardprint spandex broekje te willen verwijderen.
  4. Het systeem vraagt om bevestiging om het Luipaardprint spandex broekje te verwijderen.
  5. Sjaak bevestigt dat hij het Luipaardprint spandex broekje echt wil verwijderen.

Scenario 3 - Alternate Path: Artikel wijzigen

  1. Alejandro geeft aan het Artikeloverzicht te willen beheren.
  2. Het systeem toont het Artikeloverzicht.
  3. Alejandro geeft aan dat hij Paarse gevederde hoed wilt wijzigen.
  4. Het systeem toont Paarse hoed op een manier dat het gewijzigd kan worden.
  5. Alejandro verandert de omschrijving Paarse gevederde hoed naar Lila gevederde hoed en bevestigt de invoer.

Scenario 4 - Exception bij Artikel wijzigen of invoeren: actie annuleren

  1. Sjaak geeft aan het Artikeloverzicht te willen beheren.
  2. Het systeem toont het Artikeloverzicht.
  3. Sjaak geeft aan een rode tanktop te willen invoeren.
  4. Het systeem vraagt de Sjaak om Artikelgegevens.
  5. Sjaak geeft aan het invoeren te willen annuleren.
  6. Het systeem geeft het Artikeloverzicht weer.

Scenario 5 - Exception bij Artikel wijzigen of invoeren: foutieve gegevens invoer

  1. Hannah geeft aan het Artikeloverzicht te willen beheren.
  2. Het systeem toont het Artikeloverzicht.
  3. Hannah geeft aan een fluoriserende handschoen te willen invoeren.
  4. Het systeem vraagt de Hannah om Artikelgegevens.
  5. Anita voert een fluoriserende handschoen in van maat S van prijs 15,95 van merk Glowalicious met de omschrijving Raver handschoen in categorie overig met inkoopprijs 10.95 waarvan er 2 aanwezig zijn in Filiaal Wijchen, en bevestigd naderhand de invoer.
  6. Het systeem geeft aan dat de prijs geen komma mag bevatten en gaat terug naar punt 4.
  7. Hannah verandert de prijs naar 15.95 en bevestigt de invoer.

Scenario 6 - Exception bij Artikel verwijderen: artikel niet verwijderen

  1. Chewbacca geeft aan het Artikeloverzicht te willen beheren.
  2. Het systeem toont het Artikeloverzicht.
  3. Chewbacca geeft aan het glittertopje te willen verwijderen.
  4. Het systeem vraagt om bevestiging om het glittertopje te verwijderen.
  5. Chewbacca geeft aan het glittertopje niet te willen verwijderen.
  6. Het systeem geeft het Artikeloverzicht weer.

Bekijk verkoopoverzicht

Scenario 1 - Basic Course of Events

  1. Mevrouw Walraven geeft aan het Verkoopoverzicht te willen zien.
  2. Het systeem laat het Verkoopoverzicht zien van het filiaal waar mevrouw Walraven is.

Scenario 2 - Alternate Path: Toon Verkoopoverzicht ander filiaal

  1. Meneer Walraven geeft aan het Verkoopoverzicht te willen zien.
  2. Het systeem laat het Verkoopoverzicht zien van het filiaal Wijchen, waar meneer Walraven zich bevindt.
  3. Meneer Walraven geeft aan het Verkoopoverzicht van het filiaal Arnhem te willen zien.
  4. Het systeem laat het Verkoopoverzicht zien van het filiaal in Arnhem.

Scenario 3 - Exception Path: Het Verkoopoverzicht is leeg

  1. Het systeem geeft aan dat het Verkoopoverzicht leeg is.

Verkoop artikel

Scenario 1 - Basic Course of Events

  1. Peter identificeert een bloemetjesjurk
  2. Het systeem toont "Bloemetjesjurk: €15,00" en "Totaal: €15,00"
  3. Peter handelt de betaling af
  4. Het systeem bevestigt dat de betaling is afgerond

Scenario 2 - Alternate Path: Meerdere artikelen per verkoop

  1. Peter identificeert een bloemetjesjurk
  2. Het systeem toont "Bloemetjesjurk: €15,00" en "Totaal: €15,00"
  3. Peter geeft aan nog een Artikel te willen identificeren
  4. Het systeem vraagt om het te identificeren Artikel
  5. Peter identificeert een blauwe polo
  6. Het systeem toont "Bloemetjesjurk: €15,00", "Blauwe Polo: €20,00" en "Totaal: €35,00"
  7. Peter handelt de betaling af
  8. Het systeem bevestigt dat de betaling is afgerond

Scenario 3 - Alternate Path: Artikel toch niet kopen

  1. Peter identificeert een bloemetjesjurk
  2. Het systeem toont "Bloemetjesjurk: €15,00" en "Totaal: €15,00"
  3. Peter geeft aan een Artikel toch niet te willen verkopen
  4. Het systeem vraagt om welk Artikel het gaat
  5. Peter geeft aan dat het de bloemetjesjurk betreft
  6. Het systeem verwijdert de bloemetjesjurk uit de tot nu toe geïdentificeerde artikelen en toont "Totaal: €0,00"

Scenario 4 - Exception Path: Betaling mislukt

  1. Peter identificeert een bloemetjesjurk
  2. Het systeem toont "Bloemetjesjurk: €15,00" en "Totaal: €15,00"
  3. Peter kan de betaling niet afhandelen

Scenario 5 - Exception Path: Het artikel is niet bekend in het systeem

  1. Peter identificeert een pandamuts
  2. Het systeem geeft aan dat de pandamuts niet bekend is in het systeem
  3. Peter identificeert een bloemetjesjurk
  4. Het systeem toont "Bloemetjesjurk: €15,00" en "Totaal: €15,00"
  5. Peter handelt de betaling af
  6. Het systeem bevestigt dat de betaling is afgerond

Retourneer artikel

Scenario 1 - Basic Course of Events

  1. Truus geeft aan een Artikel te willen retourneren.
  2. Artikel wordt geïdentificeerd.
  3. Het systeem laat polo (blauw) en €20,- zien
  4. Het Systeem laat de totale teruggaveprijs van €20,- zien
  5. Truus bevestigt het retourneren
  6. Systeem voegt de geretourneerde polo (blauw) in de huidige voorraad toe.
  7. Systeem verwerkt het retourneren van polo(blauw) voor een prijs van -€20,- in de verkopen.

Scenario 2 - Alternate Path: Retourneer meerdere Artikelen

  1. Truus geeft aan nog een Artikel te willen retourneren
  2. Artikel wordt geïdentificeerd
  3. Het systeem laat zien:
    • polo (blauw) en €20,-
    • ondergoedset A en €20,-
  4. Use case gaat verder bij 4 (Het systeem laat de totale teruggaveprijs van €40,- zien)

Scenario 3 - Exception Path: Het Artikel kan niet geïdentificeerd worden

  1. Systeem geeft foutmelding dat polo (blauw) niet meer geretourneerd mag worden.
  2. #Use case gaat verder bij 4 (Het systeem laat de totale teruggaveprijs van €0,- zien)

Bekijk Bijstelopdrachten

Scenario 1 - Basic Course of Events

  1. Petra geeft aan de Bijstelopdrachten te willen zien.
  2. Het systeem toont alle Bijstelopdrachten.

Scenario 2 - Alternate Path: Toon Bijstelopdrachten ander Filiaal

  1. Petra geeft aan de Bijstelopdrachten te willen zien.
  2. Het systeem toont alle Bijstelopdrachten.
  3. Petra geeft aan dat ze alleen de Bijstelopdrachten die bij het Filiaal in Wijchen horen te willen zien.
  4. Het systeem toont de Bijstelopdrachten die bij het Filiaal in Wijchen horen.

Scenario 3 - Exception Path: Er zijn geen Bijstelopdrachten

  1. Systeem meldt dat er geen Bijstelopdrachten zijn in Wijchen

Use case gaat naar 1

Invoer Bijstelopdracht

Scenario 1 - Basic Course of Events

  1. Het Systeem vraagt om de Bijstelgegevens van de nieuwe Bijstelaanvraag.
  2. Loes geeft de volgende gegevens: 
*Bijstelopdracht ophalen in Wijchen
*Ophalen vanaf 24 juni 2013
*Kosten voor bijstelopdracht zijn €12,00
*Bijstelaanvraag: Mouw verstellen
  1. Loes bevestigt de aanvraag.
  2. Het systeem bevestigt dat de Bijstelaanvraag is voltooid.

Scenario 2 - Alternate Path: Annuleer invoer Bijstelaanvraag

  1. Loes geeft aan dat de Bijstelaanvraag geannuleerd moet worden.
  2. Het systeem meldt dat de Bijstelaanvraag is geannuleerd.

Scenario 3 - Exception Path: Verkeerde invoer

  1. Het systeem meldt dat er fouten gegevens zijn: de kosten zijn -€3,00.

Beheer Bijstelopdracht

Scenario 1 - Basic Course of Events

  1. Truus geeft aan haar Bijstelopdracht "Broek korter maken" te willen beheren.
  2. Het systeem toont de Bijstelopdrachten die bij het Filiaal in Wijchen horen: "Broek korter maken", "Knoop blouse bijzetten".
  3. Truus kiest de Bijstelopdracht "Broek korter maken".
  4. Het systeem laat deze Bijstelopdracht zien.
  5. Truus geeft aan de Bijstelopdracht te willen bewerken.
  6. Het systeem vraagt om de gewijzigde gegevens.
  7. Truus wijzigt het Filiaal van de Bijstelopdracht in "Nijmegen".

Scenario 2 - Alternate Path: Verantwoordelijke wijzigen

  1. Mvr. Walraven geeft aan de Bijstelopdracht "Broek korter maken" te willen beheren.
  2. Het systeem toont alle Bijstelopdrachten: "Broek korter maken", "Knoop blouse bijzetten".
  3. Mvr. Walraven kiest de Bijstelopdracht "Broek korter maken".
  4. Het systeem laat deze Bijstelopdracht zien.
  5. Mvr. Walraven geeft aan de Bijstelopdracht te willen bewerken.
  6. Het systeem vraagt om de gewijzigde gegevens.
  7. Mvr. Walraven wijzigt de verantwoordelijke van de Bijstelopdracht van "Truus" naar "Tom".

Scenario X - Exception Path: Ongeldige gegevens ingevoerd

  1. Het systeem zegt dat de medewerker Tom niet bestaat.

Het scenario gaat verder bij 7.

Bijstelopdracht afrekenen

Scenario 1 - Basic Course of Events

  1. Thomas geeft aan zijn Bijstelopdrachten te willen zien.
  2. Het systeem toont zijn Bijstelopdrachten: "Broek korter maken", "Knoop blouse bijzetten".
  3. Thomas kiest de Bijstelopdracht "Broek korter maken" en geeft aan deze te willen afrekenen.
  4. Het systeem toont de kosten van de Bijstelopdracht: €20,00.
  5. Thomas handelt de betaling van €20,00 van klant Lisa af en geeft in het systeem aan dat de betaling is voltooid.
  6. Het systeem verwijdert het telefoonnummer van Janneke.

Scenario 2 - Alternate Path: Bijstelopdracht annuleren

  1. Thomas geeft aan zijn Bijstelopdrachten te willen zien.
  2. Het systeem toont zijn Bijstelopdrachten: "Broek korter maken", "Knoop blouse bijzetten".
  3. Thomas kiest de Bijstelopdracht "Broek korter maken" en geeft aan deze te willen annuleren.
  4. Het systeem toont de tot dan toe gemaakte kosten: €7,00.
  5. Thomas handelt de betaling van €7,00 van klant Janneke af en geeft in het systeem aan dat de betaling is voltooid.
  6. Het systeem verwijdert het telefoonnummer van Janneke en annuleert de Bijstelopdracht.

Scenario 3 - Exception Path: Betaling is mislukt

  1. Het systeem geeft aan dat de Bijstelopdracht "Broek korter maken" onbekend is.
  2. De use case gaat verder bij 3.

Scenario 4 - Exception Path: Bijstelopdracht onbekend

  1. Het banksaldo van de klant was ontoereikend.

Het scenario gaat verder bij 5.

Bekijk Financieel overzicht

Scenario 1 - Basic course of events

  1. Meneer Walraven geeft op 21-06-2013 aan het Financieel overzicht te willen zien.
  2. Het systeem geeft een overzicht van de financiën van de maand juni 2013.

Scenario 2 - Specifieke Maandweergave

  1. Meneer Walraven geeft op 21-06-2013 aan het Financieel overzicht te willen zien.
  2. Het systeem geeft een overzicht van de financiën van de maand juni 2013.
  3. Meneer Walraven geeft aan een Financieel overzicht juni van 2012 te willen zien.
  4. Het systeem geeft een overzicht van de financiën van de maand juni 2012.

Scenario 3 - Dagweergave

  1. Meneer Walraven geeft op 21-06-2013 aan het Financieel overzicht te willen zien.
  2. Het systeem geeft een overzicht van de financiën van de maand juni 2013.
  3. Meneer Walraven geeft aan een dagweergave van de financiën te willen zien.
  4. Het systeem geeft een overzicht van de financiën van de dag 20-06-2013.

Scenario 4 - Specifieke Dagweergave

  1. Meneer Walraven geeft op 21-06-2013 aan het Financieel overzicht te willen zien.
  2. Het systeem geeft een overzicht van de financiën van de maand juni 2013.
  3. Meneer Walraven geeft aan een dagweergave van de financiën te willen zien.
  4. Het systeem geeft een overzicht van de financiën van de dag 20-06-2013.
  5. Meneer Walraven geeft aan een Financieel overzicht van de dag 01-01-2000 te willen zien.
  6. Het systeem geeft een overzicht van de financiën van de dag 01-01-2000.

Scenario 5 - Jaarweergave

  1. Meneer Walraven geeft op 21-06-2013 aan het Financieel overzicht te willen zien.
  2. Het systeem geeft een overzicht van de financiën van de maand juni 2013.
  3. Meneer Walraven geeft aan een jaarweergave van de financiën te willen zien.
  4. Het systeem geeft een overzicht van de financiën van het jaar 2013.

Scenario 6 - Specifieke Jaarweergave

  1. Meneer Walraven geeft op 21-06-2013 aan het Financieel overzicht te willen zien.
  2. Het systeem geeft een overzicht van de financiën van de maand juni 2013.
  3. Meneer Walraven geeft aan een jaarweergave van de financiën te willen zien.
  4. Het systeem geeft een overzicht van de financiën van het jaar 2013.
  5. Meneer Walraven geeft aan een Financieel overzicht van het jaar 2012 te willen zien.
  6. Het systeem geeft een overzicht van de financiën van het jaar 2012.

Scenario 7 - Nog geen financiële gegevens van gevraagde periode

  1. Meneer Walraven geeft op 21-06-2013 aan het Financieel overzicht te willen zien.
  2. Het systeem geeft aan nog geen financiële gegevens te hebben van de dag 20-06-2013.

Non-functional Requirements

Beschikbaarheid 1: Het systeem moet praktisch altijd beschikbaar zijn.

Beschikbaarheid 2: Het systeem hoeft slechts beschikbaar te zijn binnen de filialen.

Verbondenheid: Vanaf ieder filiaal moeten voor alle filialen de voorraad, bijstelaanvragen en financiën inzichtelijk zijn.

Levensloop: Het systeem moet minstens tien jaar meegaan.

Beveiliging 1: Binnen het systeem moet traceerbaar zijn wie welke actie heeft ondernomen.

Beveiliging 2: Er zijn verschillen in welke personen welke acties mogen ondernemen.

Addendum

Integrated Domainmodel

2013Gr3DM.png

Business Rules Catalogue

# Rule Definition Type of Rule Static/Dynamic Source
01 Artikelen met bonnetje en aangehecht kaartje mogen binnen twee weken teruggebracht worden, mits in goede staat verkerende. Action Restricting Dynamisch (2 weken)

Management policy

02 Cadeaubonnen blijven een jaar geldig. Action Restricting Dynamisch (1 jaar) Management policy
03 Cadeaubonnen mogen in elk filiaal voor elk artikel gebruikt worden. Action Restricting Static Management policy
04 Bijstelaanvragen mogen geannuleerd worden, maar alle tot dan gemaakte kosten moeten wel betaald worden. Action Restricting Static Management policy
05 Pinnen is altijd kostenloos mogelijk. Action Restricting Static Management policy
06 De voorraad mag alleen door de eigenaars worden aangepast. Action Restricting Static Management Policy
07 Medewerkers zijn verantwoordelijk voor hun eigen bijstelaanvraag. Action Restricting Static Management Policy
08 Persoonsgegevens van klanten worden alleen bijgehouden zolang de bijstelaanvraag loopt. Structural Effect Static Management Policy
09 Bijstelaanvragen mogen op elk filiaal worden aangevraagd. Structural Effect Static Management Policy
10 Bijstelaanvragen mogen op elk filiaal worden opgehaald. Structural Effect Static Management Policy
11 Het telefoonnummer van een klant wordt verwijderd zodra een bijstelopdracht is afgerond. Structural Effect Static Management Policy
12 De financiën mogen alleen door de eigenaars worden ingezien. Action Restricting Static Management Policy
13 De verantwoordelijke van een Bijstelopdracht mag alleen door een Eigenaar worden aangepast Action Restricting Static Management Policy

Terminological Definitions

  • Aankoop: Meerdere Artikelen die tijdens het afrekenen geïdentificeerd zijn.
  • Artikel: Een object dat door het modehuis wordt of werd doorverkocht.
  • Artikelgegevens: Omschrijving, categorie, merk, maat en de prijs van een Artikel
  • Assortiment: Artikelen die in het bezit zijn van, of besteld zijn door het modehuis.
  • Artikeloverzicht: Een overzicht van de artikelen die op enig moment in het assortiment hebben gezeten, met de attributen: omschrijving, prijs, categorie, merk, maat, korting, kwantiteit en inkoopprijs.
  • Bijstelaanvraag: Een aanvraag van een Klant om een Kledingsstuk bij te stellen.
  • Bijstelgegevens: De gegevens van een Bijstelopdracht, exclusief de verantwoordelijke.
  • Bijstellen: Het zo aanpassen van een Kledingstuk naar de wens van de Klant.
  • Bijstelopdracht: Een aangenomen Bijstelaanvraag.
  • Eigenaars: De personen verantwoordelijk voor inkoop en de financiën/De bezitters van het modehuis/Mr.&Mvw. Walraven
  • Filiaal: Een locatie waar Artikelen worden verkocht, Bijstelaanvragen kunnen worden gedaan en voltooide Bijstelopdrachten kunnen worden opgehaald.
  • Financieel overzicht: Een overzicht van inkomsten, uitgaven en gerelateerde resultaatgegevens.
  • Klant: Een persoon die iets bij het modehuis koopt, wil kopen, heeft gekocht of een bijstelaanvraag doet, wil doen of heeft gedaan.
  • Kledingstuk: Een specifiek soort Artikel, waarbij het doel van het Artikel is om een lichaam te bedekken of te versieren.
  • Medewerker: Een persoon werkende bij het modehuis.
  • Personeel: De Medewerkers werkende bij het modehuis, exclusief de Eigenaars.
  • Voorraad:
  • Verkoopoverzicht: Een overzicht van de verkopen van het modehuis.
Overgenomen van "https://lab.cs.ru.nl/algemeen/index.php?title=Requirements_Engineering/het_werk/werkstuk/2012-13/Groep_03&oldid=235397"