Use Case 2: Zakup posiłku
===================

**Aktor podstawowy:** Klient


Główni odbiorcy i oczekiwania względem systemu:
-----------------------------------------------

- Klient: Oczekuje zamówionego posiłku, który został poprawnie przygotowany
w warunkach, które spełniają normy sanitarne.

- Magazyn: Oczekuje informacji na temat stanu liczebności danego posiłku po każdym zakupe.

- Serwisant: Oczekuje informacji o stanie urządzenia przygotowującego posiłki po każdym
wykonanym posiłku.

Warunki wstępne:
----------------

Automat posiada posiłek na stanie i urządzenie wydawania posiłku spełnia normy sanitarne (stan jest akceptowalny)

Warunki końcowe:
----------------

Automat wydaje poprawie przygotowany posiłek, stan magazynu jest zaktualizowany, informacja
o stanie urządzenia jest u serwisanta.

Scenariusz główny (ścieżka podstawowa):
---------------------------------------

1. Klient wybiera posiłek
2. Automat wyświetla cenę do zapłaty Brutto
3. Klient wybiera metode płatności
4. Klient płaci
5. Automat wyświetla informacje o przygotowywaniu posiłku
6. Automat przygotowywuje posiłek
7. Automat wydaje posiłek
8. Klient odbiera posiłek
9. Automat wysyła informacje o stanie ilości posiłku, który właśnie został zakupiony, do magazynu
10. Automat sprawdza stan urządenia przygotowywującego posiłki
11. Automat wysyła informacje o stanie urządzenia do serwisanta

Rozszerzenia (ścieżki alternatywne):
------------------------------------

*a: Zawieszenie systemu:
Automat zapisuje stan, w którym proces zakupu posiłku się znajduje.
- 1. Automat wyświetla informacje o błędzie
- 2. Serwisant resetuje automat
- 3. Automat sprawdza czy stan zakupu jest po dokonaniu płatności.

  - 1. Stan zakupu jest po dokonaniu płatności
     - Płatności dokonana gotówką
       - Automat zwraca pieniądze
     - Płatność dokonana kartą
       - Automat wysyła żądanie do Systemu Płatności o anulowanie transakcji
  - 2. Stan zakupu jest przed płatnością 
    - Automat wraca do stanu początkowego 



4. Klient płaci
- 4a Klient płaci kartą (UseCase 3)
- 4b Klient płaci gotówką (UseCase 4)

6. krok pierwszy rozszerzenia *a
7. krok drugi rozszerzenia *a

3a. nazwa rozszerzenia <!-- np. 3a. Nieprawidłowy pin -->

1. krok pierwszy rozszerzenia 3a
2. krok drugi rozszerzenia 3a

     2a. nazwa scenariusza alternatywnego dla kroku 2 rozszerzenia 3a

       1. Krok pierwszy.
       2. Krok drugi.
       3. ...

     2b. nazwa scenariusza alternatywnego dla kroku 2 rozszerzenia 3a

       1. Krok pierwszy.
       2. ...

3. krok trzeci rozszerzenia 3a
4. krok czwarty rozszerzenia 3a

3b. nazwa rozszerzenia

1. krok pierwszy rozszerzenia 3b
2. krok drugi rozszerzenia 3b
3. ...

3-4a. nazwa rozszerzenia <!-- rozszerzenia 3-4a. może wystąpić w kroku 3 lub 4 -->

Wymagania specjalne:
--------------------

- ... <!--np. Interfejs użytkownika musi być dostępny w języku polskim i angielskim. -->

- ...

- ...

Wymagania technologiczne oraz ograniczenia na wprowadzane dane:
---------------------------------------------------------------

2a. ...

2b. ...

3a. ... <!-- np. 3a. Pin składa się z 4 cyfr. -->

Kwestie otwarte:
----------------

- ... <!-- np. Czy dopuszczamy autoryzację z wykorzystaniem rozpoznawania twarzy?-->

- ...

- ...