2021-11-03 10:49:20 +01:00
|
|
|
|
|
|
|
|
Use Case 4: Śledzenie statusu zamówienia
|
|
|
|
|
========================================
|
|
|
|
|
|
|
|
|
|
**Aktor podstawowy:** Kelner
|
|
|
|
|
|
|
|
|
|
Główni odbiorcy i oczekiwania względem systemu:
|
|
|
|
|
-----------------------------------------------
|
|
|
|
|
|
|
|
|
|
- Kelner:
|
|
|
|
|
- chce mieć wgląd w status zamówień, które obsługuje,
|
|
|
|
|
- chce zmieniać status zamówień, by wiedzieć, które czynności już wykonał.
|
|
|
|
|
- Klient:
|
|
|
|
|
- oczekuje szybkiej obsługi.
|
|
|
|
|
- Właściciel restauracji:
|
|
|
|
|
- oczekuje wydajnej obsługi, aby budować reputację i móc obsłużyć jak najwięcej klientów.
|
|
|
|
|
- Kucharz:
|
|
|
|
|
- chce wiedzieć, którymi zamówieniami powinien się zająć - czy nie są już przygotowywane
|
|
|
|
|
przez innych kucharzy albo, czy nie zostały już zaserwowane,
|
|
|
|
|
- chce, żeby zamówienia gotowe były szybko odbierane i serwowane - żeby nie stygły i nie
|
|
|
|
|
zajmowały miejsca w kuchni.
|
|
|
|
|
- Kasjer:
|
|
|
|
|
- chce mieć możliwość zakończania zamówień.
|
|
|
|
|
|
|
|
|
|
Warunki wstępne:
|
|
|
|
|
----------------
|
|
|
|
|
|
|
|
|
|
- Kelner jest zalogowany do systemu.
|
|
|
|
|
|
|
|
|
|
Warunki końcowe:
|
|
|
|
|
----------------
|
|
|
|
|
|
|
|
|
|
- Obsługa zamówień przebiegła bez niepotrzebnego czekania.
|
|
|
|
|
|
|
|
|
|
Scenariusz główny (ścieżka podstawowa):
|
|
|
|
|
---------------------------------------
|
|
|
|
|
|
|
|
|
|
1. Kelner przyjął zamówienie. Zostało dodane do listy zamówień ze statusem 'w kolejce'.
|
|
|
|
|
2. Kucharz zaczął przygotowywać zamówienie. Status zamówienia na liście zmienił się
|
|
|
|
|
na 'w kuchni'. Kelner powinien widzieć ten status na swojej liście.
|
|
|
|
|
3. Kucharz przygotował zamówienie. Zmienił jego status na 'gotowe'. Kelner może je odebrać.
|
|
|
|
|
4. Kelner odebrał i zaserwował zamówienie. Zmienił jego status na 'oddane'.
|
|
|
|
|
5. Klient opłacił zamówienie. Status zmienia się na 'opłacone' (równoznaczne z zakończone).
|
|
|
|
|
|
|
|
|
|
Rozszerzenia (ścieżki alternatywne):
|
|
|
|
|
------------------------------------
|
|
|
|
|
|
|
|
|
|
*a. TK zawiesi się. <br>
|
|
|
|
|
Aby system działał prawidłowo i nie stwarzał niedogodności klientom,
|
|
|
|
|
wszystkie informacje zapisywane są w bazie danych na bieżąco.
|
|
|
|
|
1. Kelner resetuje lub bierze inny terminal. Przechodzi przez proces autoryzacji.
|
|
|
|
|
2. Terminal łączy się z systemem i pobiera dane.
|
|
|
|
|
3. Kelner odzyskuje listę zamówień, którymi się zajmuje. Może także kontynuować ewentualne
|
|
|
|
|
przyjmowanie zamówienia.
|
|
|
|
|
|
|
|
|
|
*b. Kelner albo Kucharz błędnie zmienił stan zamówienia.
|
|
|
|
|
1. Należy cofnąć zmianę stanu zamówienia jak najszybciej.
|
|
|
|
|
|
|
|
|
|
4a. Zamówienie nie zostało zaakceptowane przez klienta.
|
|
|
|
|
1. Kelner może zwrócić zamówienie do kuchni. Wtedy jego status zmienia się na 'w kuchni'.
|
|
|
|
|
2. Po poprawie zamówienia, kucharz zmienia jego stan na 'gotowe'.
|
|
|
|
|
3. Kelner odnosi klientowi zamówienie, zmienia jego stan na 'oddane'.
|
|
|
|
|
|
|
|
|
|
5a. Klient nie opłacił zamówienia i opuścił restaurację.
|
|
|
|
|
1. Można zmienić status zamówienia na 'nieopłacone' (zakończone).
|
|
|
|
|
|
|
|
|
|
Wymagania specjalne:
|
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
|
|
- Zmiany stanów zamówień trwają bardzo krótko.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wymagania technologiczne oraz ograniczenia na wprowadzane dane:
|
|
|
|
|
---------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
- brak
|
|
|
|
|
|
|
|
|
|
Kwestie otwarte:
|
|
|
|
|
----------------
|
|
|
|
|
|
|
|
|
|
- Czy zamówienie może zostać anulowane?
|
