diff --git a/use-case-2.md b/use-case-2.md index dc5000a..5340310 100644 --- a/use-case-2.md +++ b/use-case-2.md @@ -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 + *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: @@ -55,34 +58,30 @@ 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: -------------------- - - ... - - - ... - - - ... + - 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. ... Kwestie otwarte: ---------------- - - ... - - - ... - - - ... \ No newline at end of file + - 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? \ No newline at end of file diff --git a/use-case-4.md b/use-case-4.md index e69de29..0bdccf2 100644 --- a/use-case-4.md +++ b/use-case-4.md @@ -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ę.
+ 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? \ No newline at end of file diff --git a/use-case-8.md b/use-case-8.md index 7e448fd..54f133f 100644 --- a/use-case-8.md +++ b/use-case-8.md @@ -1 +1,117 @@ -# first line \ No newline at end of file +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 +
      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? \ No newline at end of file diff --git a/use-cases.md b/use-cases.md index 2d4097a..f2403c4 100644 --- a/use-cases.md +++ b/use-cases.md @@ -9,7 +9,7 @@ Aktorzy procesu i ich cele Aktor | Cel -------------------|------------------------------ Kelner | -Kasjer | +Kasjer | Kucharz | Pracownik Spiżarni | @@ -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ę.