Use Case 4: Zakup ciepłego produktu

Aktor podstawowy: Klient

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

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.
Właściciel automatu: oczekuje poprawnie realizowanych transakcji oraz zadowolenia klienta. Ponadto ciągłego działania automatu pomimo ewentualnych usterek czy braków w towarze.
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):

Klient wpisuje na klawiaturze kod produktu.
System prosi o dostosowanie szczegółów posiłku i wyświetla panel menu, który to umożliwia.
Użytkownik dostosowuje posiłek do swoich preferencji poprzez wybór jego poszczególnych składowych, może również przystać na ich domyślną kombinację.
Użytkownik potwierdza swój wybór.
System akceptuje wprowadzone preferencje.
System uruchamia moduł odpowiedzialny za monitorowanie przebiegu transakcji.
System prosi o wybór metody płatności.
Użytkownik wybiera metodę płatności. Użytkownik wybrał płatność kartą. Przejście do use case 5: płatność kartą.
System wyłącza moduł odpowiedzialny za monitorowanie transakcji.
System przygotowuje posiłek.
System wydaje gotowy posiłek.
Klient odbiera posiłek.

Rozszerzenia (ścieżki alternatywne):

*a. Zawieszenie się systemu w dowolnym momencie procesu zakupu posiłku.

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ą pozycję.
5. System wysyła komunikat o zdarzeniu do serwisanta.
6. System wyświetla komunikat o błędzie.
6. System przechodzi w tryb operacyjny.

 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.

1a. Klient pragnie złożyć reklamację.

1. Klient wciska na klawiaturze przycisk reklamacji.
2. System wyświetla instrukcje opisujące kroki, które klient musi podjąć na drodze reklamacji.

1b. Klient wprowadza niewłaściwy kod produktu:

1. System wyświetla komunikat o wprowadzeniu niepoprawnego kodu.
2. System odrzuca wprowadzone dane.

2/7a. Klient pozostaje bezczynny.

1. System odczekuje określoną ilość czasu.
2. System anuluje proces zakupu.
3. System oczekuje następnego klienta.

8a. Klient wybiera inną metodę płatności.

1. Klient wybiera metodę płatności gotówką.
2. Przejście do use case 6: płatność gotówką.

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 nie odbiera 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:

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:

1a. Brak jakiegokolwiek półproduktu z pewnej grupy składowych uniemożliwia przygotowanie potrawy tego rodzaju i czyni ją niedostępną.

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.

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:

Jak ma wyglądać proces reklamacji?
Ile czasu ma odczekać system, zanim uzna stan bezczynności klienta?

5.9 KiB Raw Blame History