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

Uit Werkplaats
Ga naar: navigatie, zoeken

Introduction

Bal Gehakt BV is gevestigd in een kleine fabriekshal en levert mensen door het hele land voedsel in de vorm van ballen gehakt. Het is een relatief klein bedrijf met één eigenaar en 12 medewerkers. Recentelijk is het productieproces geautomatiseerd en om deze capaciteit volledig te benutten wil Bal Gehakt BV graag een geautomatiseerd bestelsysteem in werking stellen.

De structuur van dit document is gebaseerd op de methode van Kulak & Guiney, dit zorgt voor een duidelijke beschrijving van de requirements die het nieuwe bestelsysteem oplevert. De nadruk in deze beschrijvingen ligt bij de interactie tussen de gebruiker en het systeem. Het probleem wat er momenteel is wordt beschreven in de 'Problem Statement', de belanghebbenden in de 'Stakeholder Analysis' en de bedoeling van het systeem in 'Mission and Vision Statement'. Om de voortgang van het project bij te houden is er een tabel met de 'Statement of Work' en de risico's van dit project worden uitgewerkt in de 'Risk Analysis'. Uiteindelijk worden de echte requirements beschreven aan de hand van Use Case, de samenhang tussen de belanghebbenden en de Use Cases wordt duidelijk weergegeven in een Use Case Diagram. Voor een lezer van dit document zijn de Scenarios het meest concreet, er worden duidelijke voorbeelden gegeven van hoe de Use Case precies verloopt.

Problem statement

Op het moment worden alle bestellingen nog per telefoon behandeld, dit is een erg inefficiënt proces dat constante mankracht vraagt voor het bemannen van de telefoon. Doordat het bedrijf niet makkelijk bereikbaar is wordt de capaciteit niet volledig benut.

Het aanbod wordt ook nog met de hand bijgehouden en kan gevoelig zijn voor veranderingen in de toekomst wat ook het nodige werk met zich mee zal brengen.

  • Capaciteit wordt niet volledig benut.
  • Voorraad wordt met de hand bijgehouden en is gevoelig voor fouten.
  • Er is geen handige methode om te bestellen voor de klant.

Case analysis

Stakeholder analysis

Naam Rol Beschrijving
Bart van de Put Leidinggevende - Leiding geven aan het bedrijf.
Medewerker "Naam" Financiën - Bijhouden van de financiën.
Medewerker 2 "Naam 2" Management - Regelen personeelsmanagement.
Medewerker 3 "Naam 3" Orders - Orders opnemen.

Mission and vision statement

Mission

  • Particulieren en restaurants de mogelijkheid bieden om online bestellingen te plaatsen.
  • Beperkingen opleggen aan de bestellingen die geplaatst kunnen worden.

Vision

  • Een website gelinkt aan een database van het systeem waarop klanten bestellingen kunnen plaatsen d.m.v. een formulier waarbij er geen mogelijkheid is om incorrecte combinaties in te voeren en een controle doet.
  • Deze database bevat informatie over het magazijn en is ook de plek waar de orders opgeslagen worden.
  • Het bedrijf kan de orders zien vanuit deze database en ze verwerken.

Statement of work

Statussen

Code Betekenis Uitleg
V Voltooid Deliverable is nagekeken door minstens 1 teamlid en is klaar om ingeleverd te worden.
C Controleren Deliverable is gemaakt 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 Facade iteratie Status Filled iteratie Status Focused iteratie Status Verantwoordelijke groepsleden
Introduction Voorlopige versie V Voorlopige versie V Compleet V Rick Lukassen
Problem statement Zo goed mogelijk V Zo goed mogelijk V Compleet V Rick Lukassen
Stakeholder analysis Zo goed mogelijk V Zo goed mogelijk V Compleet V Rick Lukassen
Mission-vision statement Compleet V Compleet V Compleet V Rick Lukassen
Statement of work Compleet en up-to-date V Compleet en up-to-date V Compleet en up-to-date V Rick Lukassen
Risk analysis Compleet en up-to-date V Compleet en up-to-date V Compleet en up-to-date V Rick Lukassen
Use case survey Zo goed mogelijk V Bijna compleet V Compleet V Rick Lukassen
Integrated UC diagram Compleet V Compleet V Compleet V Rick Lukassen
Use cases Compleet V Compleet V Compleet V Rick Lukassen, An Ha, Guy Versteeg
Scenarios Compleet V Compleet V Compleet V An Ha
Domain models Compleet V Compleet V Compleet V An Ha
Integrated domain model Compleet V Compleet V Compleet V An Ha
Business rules catalogue Compleet V Compleet V Compleet V Guy Versteeg, Rick Lukassen
Non-functional requirements Compleet V Compleet V Compleet V Guy Versteeg, Rick Lukassen
Terminological definitions Compleet V Compleet V Compleet V An Ha, Rick Lukassen

Risk analysis

# Category Risk Solution needed by Status Days lost Expectancy factor Risk factor (1-5)
01 Team Tijdelijk uitvallen teamlid 3 dagen n.v.t. 3 10% 3
02 Team Projectgenoot stopt met vak/studie 3 dagen 20 0 5% 5
03 Project Verlies van data Direct n.v.t. 0 1% 5
04 Project Problemen met de werkplaats 1 dag n.v.t. 1 20% 3
05 Project Problemen met tijd 1 dag n.v.t. 1 10% 4

x - Afhankelijk van de staat van het project.

Daar wij enige problemen hadden met de samenwerking met één groepslid is in overleg met een studentassistent besloten deze uit de groep te verwijderen, dit heeft ons een grotere werklast gegeven. Daarnaast is 1 van onze groepsgenoten gestopt met de studie, wat wederom een hogere werklast op heeft geleverd.

Requirements

Use cases

Use case survey

# Name Description Initiating actor
01 Clientorder Client plaatst een order voor een aantal producten. Client
02 Order verwerking De order wordt verwerkt en doorgegeven aan het productie-systeem. Medewerker
03 Order Leverancier Medewerker geeft aan een order te willen verzenden. Medewerker
04 Product verzending Het product wordt verzonden. Medewerker

Integrated use case diagram

UCDiagram.png

Individual use cases

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

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

Clientorder

Use Case: Clientorder
Use case diagram
Description Client plaatst een order voor een aantal producten.
Trigger Client geeft aan een order te willen plaatsen.
Version 2.0
Basic course of events
  1. Client geeft aan order te willen plaatsen.(Trigger)
  2. Systeem vraagt client om order.
  3. Client geeft order.
  4. Systeem controleert order, systeem vraag om aflevergegevens. (De aflevergegevens bevatten ook het gewenste tijdstip)
  5. Client geeft aflevergegevens.
  6. Systeem controleert de aflevergegevens en slaat alle informatie op.
Alternate paths
Exception Paths

4.1.0 Er is iets mis met de order.
4.1.1 Het systeem geeft een foutmelding en de BcOE gaat verder bij 2.

6.1.0 Er is iets mis met de aflevergegevens.
6.1.1 Het systeem geeft een foutmelding en de BcOE gaat verder bij 4.

Preconditions Het bedrijf moet op dat moment nieuwe orders accepteren.
Postconditions De order is ontvangen en opgeslagen.
Related business rules
  1. Het opgegeven adres moet een bestaand adres zijn
  2. Het opgegeven tijd om af te leveren moet bestaand zijn.

Order Verwerking

Use Case: Order verwerking
Use case diagram
Description De order wordt verwerkt en doorgegeven aan het productie-systeem.
Trigger Medewerker geeft aan een order te willen verwerken.
Version 1
Basic course of events
  1. Na afronding van een client order wordt deze verwerkt door het systeem. (Trigger)
  2. Medewerker bevestigt de verwerking.
  3. Systeem controleert voorraad en geeft de order door aan het productie-systeem.
  4. De medewerker sluit de orderverwerking af.
Alternate paths
Exception Paths.

3.1.0 De voorraad is niet toereikend.
3.1.1 Het systeem geeft een foutmelding en vraagt de medewerker hoe hij dit moet behandelen.
3.1.2.1.1 De medewerker geeft aan de order te annuleren en de client te notificeren.
3.1.2.2.1 De medewerker geeft aan de voorraad bij te willen vullen.
3.1.2.1.2 Het systeem annuleert de order en notificeert de client.
3.1.2.2.2 Het systeem slaat de order op voor een later tijdstip.

Preconditions Het systeem heeft toegang tot de voorraad en de orders.
Postconditions De order is verwerkt en de voorraad is bijgewerkt.
Related business rules
  1. Zowel verwerkte orders als orders die nog verwerkt moeten worden, moeten zijn opgeslagen.

Product verzending

Use Case: Product verzending
Use case diagram
Description Het product wordt verzonden.
Trigger Werknemer geeft aan een product te willen verzenden
Version 1
Basic course of events
  1. Medewerker opent het scherm met de lijst van de te verzenden producten.
  2. Systeem laat de te verzenden product zien.
  3. Medewerker pakt het product en bevestigt dat hij verzonden is.
  4. Systeem update de database.
Exception path

3.1 De medewerker kan het product niet vinden en geeft dit aan in het systeem.

3.2 Systeem notificeert de leiding hiervan en verwijdert het product uit de lijst van te verzenden orders.

3.3 BCoE gaat verder bij punt 2.

Preconditions De order is verzendklaar.
Postconditions Order is verzonden.
Related business rules Nog toe te voegen.

Domain Model per Use Case

Scenarios

Client Order

Scenario: Client Order
Use Case 01
Basic course of events

Order plaatsen.

  1. Henk klikt op het linkje om een order te plaatsen.
  2. Systeem laat het formulier zien.
  3. Henk vult het volgende in:
Rundvlees | Ui | Hartig | Mosterd
  1. Systeem bevestigt de voorkeuren en vraagt om de aflevergegevens.
  2. Henk voert de volgende data in:
Hongerige Klant B.V. | P.C. Hooftstraat 1 | 1071 BX | Amsterdam
  1. Systeem geeft een bevestiging dat de data is binnengekomen en de order geplaatst is.
Exception path 1
  1. Henk klikt op het linkje om een order te plaatsen.
  2. Systeem laat het formulier zien.
  3. Henk vult het volgende in:
Rundvlees | Iu | Hartig | Mosterd
  1. Systeem zegt dat de voorkeuren niet kloppen.
  2. Henk vult het volgende in:
Rundvlees | Ui | Hartig | Mosterd
  1. Systeem bevestigt de voorkeuren en vraagt om de aflevergegevens.
  2. Henk voert de volgende data in:
Hongerige Klant B.V. | P.C. Hooftstraat 1 | 1071 BX | Amsterdam
  1. Systeem geeft een bevestiging dat de data is binnengekomen en de order geplaatst is.
Exception path 2


  1. Henk klikt op het linkje om een order te plaatsen.
  2. Systeem laat het formulier zien.
  3. Henk vult het volgende in:
Rundvlees | Ui | Hartig | Mosterd
  1. Systeem bevestigt de voorkeuren en vraagt om de aflevergegevens.
  2. Henk voert de volgende data in:
Hongerige Klant B.V. | P.C. Hooft | 1071 BX | Amsterdam
  1. Systeem geeft aan dat de data niet kloppen.
  2. Henk voert de volgende data in:
Hongerige Klant B.V. | P.C. Hooftstraat 1 | 1071 BX | Amsterdam
  1. Systeem geeft een bevestiging dat de data is binnengekomen en de order geplaatst is.

Order Verwerking

Scenario: Order Verwerking
Number 02
Basic course of events

Order Verwerking.

  1. Henk checkt de lijst van de nog niet verwerkte orders op het systeem.
  2. Systeem laat een lijstje van de nog niet verwerkte orders zien.
  3. Henk geeft aan dat de order 102 verwerkt moet worden.
  4. Systeem verwijdert deze order uit de lijst en verwerkt de order.
  5. Medewerker begint weer op punt 3.
Exception path
  1. Henk checkt de lijst van de nog niet verwerkte orders op het systeem.
  2. Systeem laat een lijstje van de nog niet verwerkte orders zien.
  3. Henk geeft aan dat de order 102 verwerkt moet worden.
  4. Systeem geeft aan dat de order niet verwerkt kan worden omdat de voorraad niet toereikend is.
Voorraad UI: 3  Nodig voor order: 5 
Maak een keuze uit:
Order annuleren | Bijvullen
  1. Henk kiest 'Order annuleren'.
  2. Systeem annuleert de order en notificeert de client.
  3. Henk gaat door met punt 3 totdat alles verwerkt is.

Product Verzending

Scenario: Product Verzending
Number 01
Basic course of events

Product Verzending.

  1. Systeem laat het laatste product zien dat nog verzonden moet worden.
  2. Henk pakt het product uit de schappen
  3. Systeem update de database.
Alternative paths
  1. Systeem laat het laatste product zien dat nog verzonden moet worden.
  2. Henk kan het product niet vinden en geeft dit aan in het systeem.
  3. Systeem verstuurt een email naar Paul (de leidinggevende) en het scenario begint opnieuw.

Non-functional Requirements

  • Gebruiksvriendelijk

De applicatie moet een vaste stijl aanhouden, zodat clienten makkelijker met de site overweg kunnen.

  • Toegankelijkheid

Het systeem dient zoveel mogelijk online te zijn.
Onderhoud mag alleen 's nachts uitgevoerd worden (23.00 - 05.00), zodat er zo min mogelijk clienten hinder ondervinden.

  • Privacy

Bezoekers van de website kunnen niet de orders van clienten bekijken.

Addendum

Integrated Domainmodel

Orm gehaktbal.png

Business Rules Catalogue

  • Elke order wordt geidentificeerd aan de hand van contactgegevens van de klant, order datum en afleverdatum.
  • Het opgegeven adres moet een bestaand adres zijn.
  • Het opgegeven tijdstip om af te leveren moet bestaand zijn.
  • Zowel verwerkte orders als orders die nog verwerkt moeten worden, moet zijn opgeslagen.

Terminological Definitions

Voorraad

Onderdeel van het systeem, met deze informatie kan het systeem een duidelijke weergave van het magazijn geven.

Accounts

Er zijn 3 accounttypes bij het systeem:

  • Administrator

De administrator heeft toegang tot alle gegevens en log files, ook heeft hij de mogelijkheid tot het handmatig aanpassen van gegevens.

  • Medewerker

De medewerker heeft toegang tot alle orders die geplaatst zijn en heeft de mogelijkheid deze te verwerken.

  • Client

De client heeft alleen toegang tot zijn (geplaatste) orders.
De client kan orders aanmaken en zijn orders wijzigen.

Client

De klanten van Bal Gehakt BV.

Medewerker

Iemand in dienst bij het bedrijf Bal Gehakt BV.

Order

Een specifieke bestelling.

Overgenomen van "https://lab.cs.ru.nl/algemeen/index.php?title=Requirements_Engineering/het_werk/werkstuk/2013-14/Groep_13&oldid=267600"