Merge branch 'master' of https://git.wmi.amu.edu.pl/s452662/Projekt_APO_Restauracja
This commit is contained in:
commit
8722cdcc3f
@ -7,44 +7,47 @@ Use Case 2: Dodawanie potrawy niestandardowej
|
||||
Główni odbiorcy i oczekiwania względem systemu:
|
||||
-----------------------------------------------
|
||||
|
||||
- Odbiorca1: Kelner
|
||||
- Chce mieć zapisaną w zamówieniu potrawę niestandardową, która jest zgodna z oczekiwaniami klienta.
|
||||
- Kelner:
|
||||
- Chce dodawać i edytować potrawy niestandardowe.
|
||||
- Oczekuje, że utworzona potrawa niestandardowa zostanie dopisana do zamówienia.
|
||||
- Chce mieć wgląd w szczegóły potrawy niestandardowej.
|
||||
|
||||
- Odbiorca2: Klient
|
||||
- Klient:
|
||||
- Chce zamówić niestandardową potrawę jako część swojego zamówienia.
|
||||
- Oczekuje sprawnej obsługi i dodania potrawy zgodnej z jego oczekiwaniami.
|
||||
|
||||
- Odbiorca3: Kuchnia
|
||||
- Chce otrzymać w zamówieniu pełny opis potrawy, aby ją przygotować.
|
||||
- Kucharz:
|
||||
- Chce otrzymać w zamówieniu pełny opis potrawy niestandardowej, aby ją przygotować.
|
||||
|
||||
Warunki wstępne:
|
||||
----------------
|
||||
|
||||
Kelner i terminal kelnera są gotowi na przyjęcie zamówienia danego klienta.
|
||||
Kelner zbiera informacje od klienta na temat zamówienia. Terminal kelnera działa poprawnie.
|
||||
|
||||
Warunki końcowe:
|
||||
----------------
|
||||
|
||||
Potrawa jest dodana do listy zamówień. Jest traktowana jak każda inna potrawa. Przechowywane są pełne informacje o składnikach potrawy.
|
||||
Potrawa jest dodana do listy zamówień. Jest traktowana jak każda inna potrawa. Przechowywane są pełne informacje o jej składnikach.
|
||||
|
||||
Scenariusz główny (ścieżka podstawowa):
|
||||
---------------------------------------
|
||||
|
||||
1. Kelner podchodzi do klienta, by przyjąć zamówienie.
|
||||
2. Klient prosi o opcję zamówienia potrawy niestandardowej.
|
||||
3. Klient podaje szczegółowe informacje na temat potrawy - jej składniki i dodatki - a kelner zapisuje te informacje.
|
||||
4. Kelner zatwierdza potrawę.
|
||||
5. Potrawa trafia na listę zamówień. Dostępny jest podgląd szczegółowy potrawy.
|
||||
6. Klient może zamówić kolejną potrawę niestandardową - powtarzane są kroki 2-5.
|
||||
7. Zamówienie jest gotowe, kelner odchodzi od stolika, klient czeka na przygotowanie zamówienia.
|
||||
1. Klient prosi o zamówienie potrawy niestandardowej.
|
||||
2. Kelner wybiera opcje dodania potrawy niestandarowej.
|
||||
3. Klient podaje szczegółowe informacje na temat potrawy - klient wybiera bazową potrawę, którą będzie chciał zmodyfikować lub podaje pełną listę składników i dodatków dania.
|
||||
4. Kelner edytuje składniki i dodatki zgodnie z oczekiwaniami klienta.
|
||||
5. Kelner zatwierdza potrawę.
|
||||
6. System dodaje potrawę do listy zamówienia. Dostępny jest podgląd szczegółowy potrawy.
|
||||
7. Klient może zamówić kolejną potrawę niestandardową - powtarzane są kroki 1-6.
|
||||
|
||||
|
||||
Rozszerzenia (ścieżki alternatywne):
|
||||
------------------------------------
|
||||
|
||||
*a. nazwa rozszerzenia <!-- rozszerzenie *a może wystąpić w dowolnym kroku -->
|
||||
*a. W przypadku zawieszenia się systemu:
|
||||
|
||||
1. krok pierwszy rozszerzenia *a
|
||||
2. krok drugi rozszerzenia *a
|
||||
1. Kelner resetuje system, prosi o odtworzenie stanu przed zawieszeniem.
|
||||
2. System odtwarza stan zamówienia i potraw niestandardowych.
|
||||
|
||||
3a. Brak podanych składników w spiżarni:
|
||||
|
||||
@ -56,33 +59,29 @@ Rozszerzenia (ścieżki alternatywne):
|
||||
1. Kelner anuluje tworzenie niestandardowej potrawy.
|
||||
2. Kelner kontynuuje zbieranie informacji na temat innych potraw zamawianych od klienta.
|
||||
|
||||
2-5a. Klient zmienia zdanie i prosi kelnera o odrzucenie potrawy niestandardowej w trakcie jej tworzenia:
|
||||
1. Kelner wybiera opcję anulowania tworzenia niestandardowej potrawy.
|
||||
2. System nie dodaje do zamówienia anulowanej potrawy niestandardowej.
|
||||
|
||||
2-4a. Klient zmienia zdanie i prosi kelnera o odrzucenie potrawy niestandardowej w trakcie jej tworzenia:
|
||||
1. Kelner anuluje dodawanie niestandardowej potrawy do menu.
|
||||
5a. Potrawa nie jest poprawna (np. jest pusta):
|
||||
1. System informuje o błędzie.
|
||||
2. Kelner informuje klienta o zaistniałej sytuacji.
|
||||
3. System nie zapisuje informacji o niepoprawnej potrafie.
|
||||
4. Kontynuowany jest proces zbierania zamówienia od klienta.
|
||||
|
||||
Wymagania specjalne:
|
||||
--------------------
|
||||
|
||||
- ... <!--np. Interfejs użytkownika musi być dostępny w języku polskim i angielskim. -->
|
||||
|
||||
- ...
|
||||
|
||||
- ...
|
||||
- Terminal kelnera działa na ekranie dotykowym.
|
||||
|
||||
Wymagania technologiczne oraz ograniczenia na wprowadzane dane:
|
||||
---------------------------------------------------------------
|
||||
|
||||
2a. ...
|
||||
5a. Potrawa niestandardowa składa się z conajmniej jednego składnika, dodatki są opcjonalne.
|
||||
|
||||
2b. ...
|
||||
|
||||
3a. ... <!-- np. 3a. Pin składa się z 4 cyfr. -->
|
||||
|
||||
Kwestie otwarte:
|
||||
----------------
|
||||
|
||||
- ... <!-- np. Czy dopuszczamy autoryzację z wykorzystaniem rozpoznawania twarzy?-->
|
||||
|
||||
- ...
|
||||
|
||||
- ...
|
||||
- Czy niestandardowa potrawa może składać się z jakichkolwiek składnikow ze spiżarni?
|
||||
- Jakie są ograniczenia dla klienta w wyborze składników i dodatków?
|
||||
@ -0,0 +1,81 @@
|
||||
|
||||
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?
|
||||
118
use-case-8.md
118
use-case-8.md
@ -1 +1,117 @@
|
||||
# first line
|
||||
Use Case 8: Przyjęcie płatości
|
||||
=====================
|
||||
|
||||
**Aktor podstawowy:** Kasjer
|
||||
|
||||
|
||||
Główni odbiorcy i oczekiwania względem systemu:
|
||||
-----------------------------------------------
|
||||
|
||||
- Klient:
|
||||
- chce poświęcić jak najmniej czasu na opłacanie zamówienia
|
||||
- oczekuje poprawnie działającego, godnego zaufania systemu
|
||||
- oczekuje fizycznego dowodu dokonanej płatności
|
||||
|
||||
- Kasjer:
|
||||
- chce w prosty sposób wprowadzać konieczne dane do systemu
|
||||
- oczekuje sprawnych odpowiedzi od systemu oraz braku błędów, aby nie irytować klienta
|
||||
|
||||
- Urząd skarbowy:
|
||||
- chce otrzymać podatek od każdej dokonanej sprzedaży
|
||||
- oczekuje przejrzystej historii transakcji
|
||||
|
||||
- Właściciel restauracji:
|
||||
- oczekuje maksymalnej niezawodności systemu, aby ograniczyć straty finansowe
|
||||
- zależy mu na satysfakcji Klienta
|
||||
|
||||
- Agencje Autoryzacji Płatności
|
||||
- oczekują komunikacji zgodnej z dokumentacją, aby poprawnie obsługiwać zapytania
|
||||
- oczekują poprawnego działania systemu
|
||||
|
||||
Warunki wstępne:
|
||||
----------------
|
||||
|
||||
Kasjer jest zalogowany do systemu. Klient poprawnie złożył zamówienie, które zostało odpowiednio przygotowane i dostarczone do Klienta. Klient zakończył konsumpcję i podszedł do Kasy, aby zrealizować płatność.
|
||||
|
||||
Warunki końcowe:
|
||||
----------------
|
||||
|
||||
Sprzedaż jest bezpieczna i została zrealizowana na prawidłową kwotę. Sprzedaż została zapisana w systemie, a kwota zaksięgowana. Podatki zostały prawidłowo obliczone. Klient otrzymał fizyczne potwierdzenie dokonanej płatności.
|
||||
|
||||
Scenariusz główny (ścieżka podstawowa):
|
||||
---------------------------------------
|
||||
|
||||
1. Klient przekazuje Kasjerowi informację o numerze stolika, przy którym siedział.
|
||||
2. Kasjer wprowadza numer stolika poprzez terminal.
|
||||
3. System odnajduje odpowiednie zamówienie na podstawie numeru stolika i wyświetla należną kwotę wraz ze szczegółami zamówienia.
|
||||
4. Kasjer upewnia się, że zawartość wyświetlanego zamówienia jest zgodna z doświadczeniem Klienta oraz informuje o należnej kwocie.
|
||||
5. Klient wybiera jeden z dostępnych sposobów płatności.
|
||||
6. Klient dokonuje płatności, którą system przetwarza i weryfikuje, komunikując się w razie potrzeby z odpowiednimi Agencjami Autoryzacji Płatności.
|
||||
7. System zapisuje i księguje dokonaną płatność.
|
||||
8. System drukuje paragon.
|
||||
9. Klient odbiera paragon i odchodzi od Kasy.
|
||||
|
||||
Rozszerzenia (ścieżki alternatywne):
|
||||
------------------------------------
|
||||
|
||||
*a. W dowolnym czasie, system napotyka błąd uniemożliwiający kontynuowanie płatności
|
||||
<br /> System na bieżąco zapisuje aktualny stan transakcji
|
||||
|
||||
1. Kasjer restartuje terminal, autoryzuje się.
|
||||
2. System odtwarza stan sprzed awarii na podstawie zapisanych postępów
|
||||
|
||||
2a. Nieprawidłowy numer stolika
|
||||
|
||||
1. System wyświetla informację o błędzie i umożliwia ponowne wpisanie numeru stolika
|
||||
|
||||
|
||||
4a. Zawartość zamówienia nie jest zgodna z doświadczeniem Klienta
|
||||
|
||||
1. Kasjer pyta Klienta, czy wprowadzony numer stolika jest poprawny
|
||||
2. Klient zwraca uwagę na błąd i podaje inny, poprawny numer stolika
|
||||
|
||||
2a. Wprowadzony numer stolika był poprawny
|
||||
1. Kasjer wzywa managera, aby wyjaśnić nieprawidłowości
|
||||
2. Sytuacja jest rozwiązywana poza systemem w sposób dostosowany do okoliczności
|
||||
|
||||
3. Kasjer anuluje realizację płatności dla błędnego stolika
|
||||
4. Kasjer wprowadza poprzez terminal prawidłowy numer stolika
|
||||
|
||||
6a. Płatość gotówką
|
||||
|
||||
1. Kasjer wprowadza kwotę otrzymaną w gotówce od Klienta
|
||||
2. System informuje o wysokości reszty, którą Kasjer wyjmuje z Kasy i przekazuje Klientowi
|
||||
|
||||
6b. Płatność kartą
|
||||
|
||||
1. Należna kwota wyświelta się na zewnętrznym terminalu płatniczym
|
||||
2. Klient używa karty płatniczej, aby opłacić zamówienie
|
||||
3. System komunikuje się z odpowiednią Agencją Autoryzacji Płatności i otrzymuje od niej potwierdzenie zapłaty
|
||||
|
||||
3a. System napotyka błąd podczas komunikacji z Agencją Autoryzacji Płatności
|
||||
1. System wyświetla informację o błędzie
|
||||
2. Kasjer informuje klienta o awarii
|
||||
3. Klient wybiera inną formę zapłaty
|
||||
|
||||
3b. System otrzymuje informację o odrzuceniu płatności
|
||||
1. System wyświetla informację o błędzie oraz drukuje fizyczne potwierdzenie nieudanej transakcji
|
||||
2. Kasjer informuje Klienta o błędzie i przekazuje fizyczne potwierdzenie
|
||||
3. Klient wybiera inną formę zapłaty
|
||||
|
||||
|
||||
Wymagania specjalne:
|
||||
--------------------
|
||||
|
||||
- Terminal Kasjera obsługiwany jest przez ekran dotykowy
|
||||
- Informacja o powodzeniu lub niepowodzeniu płatności musi nastąpić w ciągu 30 sekund
|
||||
|
||||
Wymagania technologiczne oraz ograniczenia na wprowadzane dane:
|
||||
---------------------------------------------------------------
|
||||
|
||||
1. Numer stolika jest jego unikalnym identyfikatorem, tabliczka informująca o numerze jest przytwierdzona do blatu każdego stolika w restauracji.
|
||||
|
||||
Kwestie otwarte:
|
||||
----------------
|
||||
|
||||
- Czy dopuszczamy możliwość wykorzystania kodów rabatowych np. dla stałych klientów?
|
||||
- Czy istnieje możliwość realizacji płatności poprzez bony podarunkowe?
|
||||
@ -9,7 +9,7 @@ Aktorzy procesu i ich cele
|
||||
Aktor | Cel
|
||||
-------------------|------------------------------
|
||||
Kelner | <ul> <li>zarządzanie zamówieniami</li> <li>dodanie niestandardowej potrawy do zamówienia</li> <li>sprawdzenie możliwości przygotowania potrawy (czy wystarczy na nią składników)</li> <li>śledzenie statusu zamówienia</li> </ul>
|
||||
Kasjer | <ul> <li>podgląd kosztu zamówienia i przyjęcie płatności</li> </ul>
|
||||
Kasjer | <ul> <li>przyjmowanie płatności</li> </ul>
|
||||
Kucharz | <ul> <li>przyjmowanie i wydawanie zamówień</li> <li>wgląd w zamówienia</li> </ul>
|
||||
Pracownik Spiżarni | <ul> <li>aktualizacja stanu spiżarni</li> </ul>
|
||||
|
||||
@ -89,7 +89,7 @@ Nowa dostawa produktów spożywczych trafia do spiżarni. Pracownik spiżarni we
|
||||
Za pomocą terminala, wprowadza do systemu dostarczoną ilość każdego z przyjętych produktów.
|
||||
System dodaje te wartości do aktualnego stanu spiżarni i zapisuje go.
|
||||
|
||||
### Use case 8: Podgląd kosztu zamówienia i przyjęcie płatności
|
||||
### Use case 8: Przyjęcie płatności
|
||||
|
||||
Klient podchodzi do kasy w celu opłacenia spożytego wcześniej zamówienia. Informuje kasjera o numerze stolika, przy którym siedział.
|
||||
Kasjer, za pomocą terminala, wprowadza numer stolika do systemu. Na tej podstawie system identyfikuje zamówienie oraz wyświetla należną kwotę.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user