Marcin Dobrowolski use case

use-case-4.md

@@ -1,94 +1,128 @@
-Use Case 1: Nazwa ...
+Use Case 4: Zakup ciepłego produktu
 =====================
 
-**Aktor podstawowy:** <!-- np. Klient -->
+**Aktor podstawowy:** Klient
 
 
 Główni odbiorcy i oczekiwania względem systemu:
 -----------------------------------------------
 
- - Odbiorca1: oczekiwania ...
+ - Klient: oczekuje możliwości sprawnego zakupu ciepłego posiłku oraz bezbłędnych operacji płatniczych. Chce mieć możliwość dostosowania posiłku do swoich preferencji.
 
- - Odbiorca2: oczekiwania ...
+ - Właściciel automatu: oczekuje poprawnie realizowanych transakcji oraz zadowolenia klienta. Ponad to ciągłego działania automatu pomimo ewentualnych usterek czy braków w towarze.
 
- - Odbiorca3: oczekiwania ...
+ - Agencja autoryzacji płatności: chce otrzymać zapytania o potwierdzenie zapłaty w poprawnym protokole transmisji danych. Chce poprawnej obsługi transakcji realizowanej przez automat.
+
+ - Urząd Skarbowy: chce uzyskać podatek od każdego sprzedanego produktu.
+
+ - Inspektorat Sanitarny: oczekują by automat spełniał wszelkie wymogi sanitarne dotyczące przechowywania półproduktów jak i przygotowywania posiłków.
 
 Warunki wstępne:
 ----------------
 
-...
+Automat musi być w trybie operacyjnym.
 
 Warunki końcowe:
 ----------------
 
-...
+Sprzedaż została sfinalizowana. Podatki zostały poprawnie policzone. System księgowy i magazynowy został zaktualizowany. Klient jest zadowolony.
 
 Scenariusz główny (ścieżka podstawowa):
 ---------------------------------------
 
- 1. Krok 1 scenariusza głównego. <!-- np. 1. Klient wkłada kartę do bankomatu. -->
- 2. Krok 2 scenariusza głównego. <!-- np. 2. System prosi o podanie pinu. -->
- 3. Krok 3 scenariusza głównego. <!-- np. 3. Klient wprowadza pin.) -->
- 4. ....
+ 1. Klient wpisuje na klawiaturze kod produktu. 
+ 2. System prosi o dostosowanie szczegółów posiłku i wyświetla panel menu, który to umożliwia.  
+ 3. Użytkownik dostosowuje posiłek do swoich preferencji poprzez wybór jego pszczególnych składowych, może również przystać na ich domyślną kombinację.
+ 4. Użytkownik potwierdza swój wybór.
+ 5. System akceptuje wprowadzone preferencje.
+ 6. System uruchamia moduł odpowiedzialny za monitorowanie      przebiegu transakcji.
+ 7. System prosi o wybór metody płatności. 
+ 8. Użytkownik wybiera metodę płatności. Użytkownik wybrał          płatność kartą. Przejście do use case 5: płatność kartą.
+ 9. System wyłącza moduł odpowiedzialny za monitorowanie transkacji.
+ 10. System przygotowywuje posiłek.
+ 11. System wydaje gotowy posiłek.
+ 12. Klient odbiera posiłek.
 
 Rozszerzenia (ścieżki alternatywne):
 ------------------------------------
 
- *a. nazwa rozszerzenia <!-- rozszerzenie *a może wystąpić w dowolnym kroku -->
+ *a. Zawieszenie się systemu w dowolnym momencie procesu zakupu posiłku.
  
-   1. krok pierwszy rozszerzenia *a
-   2. krok drugi rozszerzenia *a
+    1. System wykrywa błąd.
+    2. System restartuje się.
+    3. System uruchamia się ponownie i odczytuje dane z modułu monitorującego transakcje.
+    4. System w zależności od informacji zawartych w danych podejmuje pewne kroki.
+        4.1. Jeżeli rozpoczęta przed restartem transakcja została sfinalizowana, system Ją unieważnia.
+        4.2. Jeżeli mechanizm odpowiedzialny za przygotowywanie posiłku nie jest na pozycji domyślnej, uruchamia jego czyszczenie i sprowadza na domyślną pozycje.
+    5. System wysyła komunikat o zdarzeniu do serwisanta.
+    6. System wyświetla komunikat o błędzie.
+    6. System przechodzi w tryb operacyjny.
     
- 3a. nazwa rozszerzenia <!-- np. 3a. Nieprawidłowy pin -->
+     4a. Któraś z operacji kończy się niepowodzeniem.
+        1. System wyświetla stosowną informację dla klienta.
+        2. System wysyła wiadomość o błędzie do serwisanta.
+        3. System przechodzi w tryb uśpienia.
 
-   1. krok pierwszy rozszerzenia 3a
-   2. krok drugi rozszerzenia 3a
+1a. Klient pragnie złożyć reklamację.
 
-     2a. nazwa scenariusza alternatywnego dla kroku 2 rozszerzenia 3a
+    1. Klient wciska na klawiaturze przycisk reklamacji.
+    2. System wyświetla instrukcje opisujące kroki, które klient musi podjąć na drodze reklamacji.
  
-       1. Krok pierwszy.
-       2. Krok drugi.
-       3. ...
+1b. Klient wprowadza niewłaściwy kod produktu:
 
-     2b. nazwa scenariusza alternatywnego dla kroku 2 rozszerzenia 3a
+    1. System wyświetla komunikat o wprowadzeniu niepoprawnego kodu.
+    2. System odrzuca wprowadzone dane.
 
-       1. Krok pierwszy.
-       2. ...
+2/7a. Klient pozostaje bezczynny.
 
-   3. krok trzeci rozszerzenia 3a
-   4. krok czwarty rozszerzenia 3a
+    1. System odczekuje określoną ilość czasu.
+    2. System anuluje proces zakupu.
+    3. System oczekuje następnego klienta.
 
- 3b. nazwa rozszerzenia
+8a. Klient wybiera inną metodę płatności.
 
-   1. krok pierwszy rozszerzenia 3b
-   2. krok drugi rozszerzenia 3b
-   3. ...
+    1. Klient wybiera metodę płatności gotówką.
+    2. Przejście do use case 6: płatność gotówką.
     
- 3-4a. nazwa rozszerzenia <!-- rozszerzenia 3-4a. może wystąpić w kroku 3 lub 4 -->
+10a. Podczas przygotowywania posiłku dochodzi do błędu.
+
+    1. System wydaje posiłek, który nie spełnia oczekiwań klienta.
+    2. Klient wciska na klawiaturze przycisk reklamacji.
+    3. System wyświetla instrukcje opisujące kroki, które klient musi podjąć na drodze reklamacji.
+
+12a. Klient nieodbiera gotowego posiłku z automatu.
+
+    1. System oczekuje określoną długość czasu.
+    2. System pozbywa się gotowego produktu.
+    3. System ustawia mechanizmy odpowiedzialne za wydawanie produktu w pozycji domyślnej.
+    4. System oczekuje następnego klienta.
 
 Wymagania specjalne:
 --------------------
 
- - ... <!--np. Interfejs użytkownika musi być dostępny w języku polskim i angielskim. -->
+ - Aby zapewnić poprawne księgowanie, niezbędne jest aby wszystkie kluczowe dane dotyczące transakcji mogły zostać odtworzone w dowolnym momencie ścieżki podstawowej.
   
- - ...
+ - Automat nie posiada systemu odpowiadającego za dokładne monitorowanie przebiegu przygotowania ciepłego posiłku. Dlatego gdy podczas tego procesu dojdzie do błędu automat mimo wszystko doprowadzi go do końca, co może oznaczać oddanie w ręce klienta niekompletnego lub uszkodzonego posiłku. Może też nie oddać go wcale.
 
- - ...
+ - Niezbędna jest klawiatura aby zapewnić klientowi kanał komunikacji z systemem.
+
+ - Niezbędny jest ekran aby zapewnić systemowi kanał komunikacji z klientem.
 
 Wymagania technologiczne oraz ograniczenia na wprowadzane dane:
 ---------------------------------------------------------------
 
- 2a. ...
+ 1a. Brak jakiegokolwiek półproduktu z pewnej grupy składowych uniemożliwia przygotowanie potrawy tego rodzaju i czyni ją niedostępną.
  
- 2b. ...
+ 1b. Niewłaściwy kod to taki, który: dotyczy produktu, który nie jest dostępny bądź nie jest przypisany do żadnego z produktów.
 
- 3a. ... <!-- np. 3a. Pin składa się z 4 cyfr. -->
+ 2a. Brakujące półprodukty nie są wyświetlane w menu dostosowywania szczegółów posiłku.
+ 
+ 3a. Domyślna kombinacja półproduktów jest wybierana na zasadzie pierwszego dostępnego półproduktu z danej kategorii półproduktów.
 
 Kwestie otwarte:
 ----------------
 
- - ... <!-- np. Czy dopuszczamy autoryzację z wykorzystaniem rozpoznawania twarzy?-->
+ - Jak ma wyglądać proces reklamacji?
 
- - ...
+ - Ile czasu ma odczekać system zanim uzna stan bezczynności klienta?
 
- - ...