Skip to content

Casi d'uso

Jump to bottom
Ghelm99 edited this page May 3, 2021 · 40 revisions

UC1: Gestione dell’ordinazione al tavolo
Portata: Applicazione gestionale di un ristorante
Livello: Obiettivo utente
Attore primario: Cameriere, Cuoco
Stakeholders e interessi:

  • Cameriere: Vuole comunicare facilmente alla cucina le ordinazioni effettuate dai tavoli.
  • Cuoco: Vuole ricevere la lista di ordini dei vari tavoli e comunicare al cameriere quando i piatti sono pronti.
  • Cassiere: Vuole chiudere correttamente ciascun conto.
  • Tavolo: Vuole ricevere i piatti ordinati.
  • Capo: Vuole tener traccia in maniera chiara dei conti e verificare che essi vengano chiusi correttamente.
  • Fisco: Vuole ricevere notifica dei conti chiusi per provvedere ad una corretta tassazione.

Scenario principale di successo:

  1. Il tavolo al completo chiede e attende l’arrivo del cameriere per ordinare.
  2. All’arrivo del cameriere il tavolo comunica i piatti desiderati.
  3. Il cameriere, interagendo con il software, comunica la comanda al cuoco.
  4. Il cuoco prepara le pietanze ordinate, proseguendo nella comanda mano a mano che i piatti sono pronti.
  5. Completata la comanda, lo notifica al cameriere tramite il software.
  6. Il cameriere riceve la chiamata e si reca in cucina per prelevare i piatti.
  7. Il cameriere consegna i piatti al tavolo, chiude l’ordine e lo notifica al software.
  8. Terminata la consumazione, il tavolo richiama il cameriere dopo aver deciso se ordinare ancora o chiedere il conto:
    1. Se il tavolo ordina nuovamente, si ripetono i punti da 2 a 8.
    2. Se il tavolo chiede il conto, si passa al punto 9.
  9. Il tavolo si reca alla cassa e comunica il suo identificativo al cassiere.
  10. Il cassiere accede al conto relativo al tavolo e fornisce un preconto.
  11. Il tavolo paga il conto.
  12. Il conto viene chiuso e l’importo è comunicato al Fisco, lo scontrino fiscale viene stampato.

Scenari alternativi:

Il cuoco non può realizzare un piatto nella comanda poiché mancano ingredienti dall’inventario.

  1. Il cuoco interagisce con il software e notifica il problema al cameriere.
  2. Il cameriere comunica il problema al tavolo.
  3. Il tavolo effettua una nuova ordinazione.

Il tavolo sceglie di modificare la propria ordinazione.

  1. Il tavolo chiama il cameriere e chiede di modificare la comanda.
  2. Il cameriere interagisce con il software e notifica la richiesta al cuoco.
  3. Il cuoco comunica al cameriere lo stato dei piatti cancellati dalla comanda.
  4. Se il piatto non è in fase di preparazione il cameriere comunica al tavolo l’effettuata modifica, altrimenti offre la possibilità di scegliere tra mantenere l’ordinazione originaria ed il modificarla lasciando addebitati i piatti precedentemente ordinati.
  5. Il cameriere aggiorna la comanda in base alla scelta del tavolo.

Il tavolo vuole uscire dal locale prima della fine del servizio

  1. Il tavolo comunica la sua decisione al cameriere.
    1. Se il tavolo ha già effettuato ordini, il cameriere verifica i relativi stati. Gli eventuali ordini in fase di preparazione sono addebitati sul conto preesistente.
    2. Se il tavolo non ha effettuato alcun ordine non viene addebitato nulla ed il conto viene chiuso.

Il tavolo non è in grado di pagare il conto o il metodo di pagamento viene rifiutato.

  1. Il cassiere fornisce la possibilità di cambiare il metodo di pagamento o ritentare.
    1. Se il pagamento ha successo, lo scenario è concluso.
    2. Se il pagamento è nuovamente rifiutato, il cassiere ripete il punto.
    3. Se il tavolo rifiuta di fornire una soluzione, si procede al punto 2.
  2. Il cassiere controlla lo stato di debito dei clienti.
    1. Se i clienti non hanno debito, il conto viene addebitato.
    2. Se i clienti presentano un debito, essi vengono banditi dal locale.

UC2: Gestione delle prenotazioni
Portata: Applicazione gestionale di un ristorante
Livello: Obiettivo utente
Attore primario: Cassiere
Stakeholders e interessi:

  • Cassiere: Vuole chiudere correttamente ciascun conto.
  • Capo: Vuole massimizzare i profitti dato il numero di coperti.
  • Clienti: Vogliono prenotare un tavolo adatto al gruppo di cui fanno parte.
    Un cliente contatta il locale per prenotare il tavolo. Il cassiere accede al software e verifica la disponibilità del locale in base all’orario scelto e alla tipologia di tavolo da riservare, infine comunica l’esito al cliente.

UC3: Gestione dell’accesso al locale
I clienti si recano alla cassa. Il cassiere verifica l’eventuale prenotazione. Se questa è presente i clienti sono accompagnati al tavolo, altrimenti il cassiere verifica la disponibilità in base ai tavoli momentaneamente liberi e alle prenotazioni precedentemente accordate. Il cassiere comunica ai clienti l’esito della ricerca.

UC1: Table ordering management
Scope: management software application of a restaurant
Level: user goal
Primary Actor: Waiter, Chef
Stakeholders and Interests:

  • Waiter: wants to easily communicate tables’ order to the kitchen.
  • Chef: wants to receive the list of orders and notify the waiter when dishes are ready.
  • Cashier: wants to close every bill correctly.
  • Table: wants to receive the ordered dishes.
  • Chief: wants to keep track of every bill clearly.
  • Revenue Agency: wants to receive notification of every paid bill to provide for a correct taxation.

Main Success Scenario:

  1. The full table asks for a waiter and waits his arrival to order.
  2. Upon arrival of the waiter the table communicates the dishes.
  3. The waiter communicates the command to the chef through the interaction with software.
  4. The chef prepares the ordered dishes.
  5. After the command has been completely realized the chef informs the waiter through the software.
  6. The waiter receives the notify and takes the dishes from the kitchen.
  7. The waiter delivers the dishes to the table and notifies the update to the software.
  8. When the members of the table have finished to consume the first ordered dishes the waiter is recalled and the table can choose between two possibilities:
    1. If at least a member of the table decides to order again there is a repetition of steps 2 – 8.
    2. If no member wants to make a new order the waiter closes the order and it is possible to move to step 9.
  9. The table goes to the cashier’s desk and communicates the id to the cashier.
  10. The cashier gains access to the table’s bill and gives a pre-bill.
  11. The table pays the bill.
  12. The bill is closed and the amount is communicated to the Revenue Agency; the tax receipt is printed.

Alternative Flows:
The chef is not able to cook a dish due to ingredient shortage.

  1. The chef interacts with the software and notifies the problem to the waiter.
  2. The waiter informs the table.
  3. The table makes a new order.

The table wants to modify the order.

  1. The table asks the waiter to change the order.
  2. The waiter interacts with the software and notifies the request to the chef.
  3. The chef verifies the state of the modified order and notifies it to the waiter.
  4. If the dish is not in preparation the waiter confirms to the table the change made, otherwise he gives the possibility to choose whether to maintain the original order or modify it by maintainig the additional charges.
  5. The waiter updates the command according to what the table has chosen.

The table wants to leave before the end of the service.

  1. The table communicates its decision to the waiter.
    1. If the table has already ordered something the waiter verifies its state. The potential orders in preparation are charged on the preexisting order.
    2. If the table has not made any order the bill is closed with no additional charges.

The table can’t pay the bill or the method of payment is rejected.

  1. The cashier gives the opportunity to change the method of payment.
    1. If the payment succeeds the extension is concluded.
    2. If the payment is rejected again step 1 is repeated.
    3. If the table refuses to find a solution step 2 is made.
  2. The cashier checks if the customers have debts.
    1. If the customers have no debts the bill is charged.
    2. It the customers have debts they are expelled from the restaurant.

UC2: Reservation management
Scope: management software application af a restaurant
Level: user goal
Primary Actor: Cashier
Stakeholders and Interests:

  • Cashier: wants to correctly close every bill.
  • Chief: wants to maximize profits, given the seats’ number.
  • Customers: want to reserve a suitable table for the group they belong to.
    A customer contacts the cashier to reserve the table. The cashier logs in to the software and checks restaurant’s availability, depending on the chosen time of day and the type of table. Finally he communicates the result to the customer.

UC3: Access management
Customers go to the cashier’s desk. The cashier looks for the eventual reservation. If he finds it customers are taken to the table, otherwise the cashier checks availability according to the momentarily free tables and the previously agreed reservations. The cashier communicates to customers the result of his search.

Clone this wiki locally