• No results found

Detail Use Case Diagram and Use Case Description

2. Requirements Analysis

2.6 Detail Use Case Diagram and Use Case Description

Membership Maintenance Detail Use Case Diagram

Diagram 2.6.1 Membership Maintenance Detail Use Case Diagram

Membership Maintenance Use Case Description

Use Case Name : Membership Maintenance Actors : Staff

Brief Description: This use case describes how a staff can record their member profile, update, delete and edit their profile.

Pre-condition: The Staff is logged-in into the system.

Normal Flow of Events :

Actor Actions System Response

1. User clicks on „Membership

Maintenance‟ button to enter the page.

3. User decides whether they want to add, search, edit or delete the member‟s profile.

2. The system will display the maintenance interface.

If the user wants to add a new member profile S-1 : add new member is performed.

If the user wants to search a member profile S-2 : search member is performed.

If the user wants to edit a member profile S-3 : edit member is performed.

If the user wants to delete a member profile S-4 : delete member is performed.

Sub Flows:

S-1: Add Member

1. The system will display a membership form.

2. The user will enter the member details.

3. The system will validate the detail entered.

4. If valid, the new member is inserted into the membership database.

S-2: Search Member

1. The user will enter the keyword required for searching a particular member.

2. The system will search the particular member record based on the keyword and display in proper format.

S-3 : Edit Member

1. The user will enter the keyword required for searching a particular member.

2. The system will search the particular member record based on the keyword and display in proper format.

3. The staff can edit the member detail and click on submit button.

4. The system will validate the updated detail.

5. If valid, the system will update the member detail in the database.

S-4 : Delete Member

1. The user will enter the keyword required for searching a particular member.

2. The system will search the particular member record based on the keyword and display in proper format.

3. The Staff can delete the member detail by click on the delete button.

4. The system will prompt a confirmation message.

5. If the user clicks on confirm button, the system will delete the member detail from the database.

Alternate Flows:

S-1, 3a1: If user enter an invalid member details, the system prompt an error message and goes back to Step 2 of S-1.

S-2, 1a1: If user enters an invalid keyword for searching the member detail, the system will prompt an error message and goes back to Step 1 of S-2.

S-3, 1a1: If user enters an invalid keyword for searching the member detail, the system will prompt an error message and goes back to Step 1 of S-3.

S-3, 3a1: If user enter an invalid updated member details, the system prompt an error message and goes back to Step 3 of S-3.

S-4,1a1: If user enters an invalid keyword for searching the member detail, the system will prompt an error message and goes back to Step 1 of S-4.

Menu Maintenance Detail Use Case Diagram

Diagram 2.6.2 Membership Maintenance Detail Use Case Diagram

Menu Maintenance Use Case Description

Use Case Name : Menu Maintenance Actors : Staff

Brief Description: This use case describes how a staff can add, update, delete and edit their menu detail.

Pre-condition: The Staff is logged-in into the system.

Normal Flow of Events :

Actor Actions System Response

1. User clicks on „Menu Maintenance‟

button to enter the page.

3. User decides whether they want to add, search, edit or delete the member‟s profile.

If the user wants to add a new menu record S-1 : add new menu is performed.

2. The system will display the maintenance interface.

If the user wants to search a menu record S-2 : search menu is performed.

If the user wants to edit a menu record S-3 : edit menu is performed.

Sub Flows:

S-1: Add Menu

1. The system will display a menu form.

2. The user will enter the menu details.

3. The system will validate the detail entered.

4. If valid, the new menu record is inserted into the menu database.

3. The staff can edit the menu detail and click on submit button.

4. The system will validate the updated detail.

5. If valid, the system will update the menu detail in the database.

Alternate Flows:

S-1, 3a1: If user enter an invalid menu details, the system prompt an error message and goes back to Step 2 of S-1.

S-2, 1a1: If user enters an invalid keyword for searching the menu record, the system will prompt an error message and goes back to Step 1 of S-2.

S-3, 1a1: If user enters an invalid keyword for searching the menu record, the system will prompt an error message and goes back to Step 1 of S-3.

S-3, 3a1: If user enter an invalid updated menu detail, the system prompt an error message and goes back to Step 3 of S-3.

Food Order Detail Use Case Diagram

Diagram 2.6.3 Food Order Detail Use Case Diagram

Food Order Use Case Description

Use Case Name : Food Order Actors : Staff

Brief Description: This use case describes how a staff can add, edit, remove an order and check the order detail.

Pre-condition: The Staff is logged-in into the system.

Normal Flow of Events :

Actor Actions System Response

1. User clicks on „Food Order‟ button to enter the page.

3. User decides whether they want to add, edit, remove or check the order detail.

If the user wants to add a new order S-1 : add new order is performed.

If the user wants check an order S-2 :

2. The system will display the food ordering interface.

check order is performed.

1. The system will display a menu list with ordering form.

2. The user will enter the order details.

3. The system will validate the detail entered.

4. If valid, the new order is inserted into the order database and new payment is created in the payment database.

S-2: Check Order

1. The user will enter the keyword required for searching a particular order detail.

2. The system will search the particular order detail based on the keyword and display in proper format.

S-3 : Edit Order

1. The user will enter the keyword required for searching a particular order detail.

2. The system will search the particular order detail based on the keyword and display in proper format.

3. The staff can edit the order detail and click on submit button.

4. The system will validate the updated detail.

5. If valid, the system will update the order detail and payment detail in the database.

S-4 : Remove Order

1. The user will enter the keyword required for searching a particular order detail.

2. The system will search the particular order detail based on the keyword and display in proper format.

3. The Staff can remove the order detail by click on the delete button.

4. The system will prompt a confirmation message.

5. If the user clicks on confirm button, the system will delete the order detail from the database and void the payment detail too.

Alternate Flows:

S-1, 3a1: If user enter an invalid order details, the system prompt an error message and goes back to Step 2 of S-1.

S-2, 1a1: If user enters an invalid keyword for searching the order detail, the system will prompt an error message and goes back to Step 1 of S-2.

S-3, 1a1: If user enters an invalid keyword for searching the order detail, the system will prompt an error message and goes back to Step 1 of S-3.

S-3, 3a1: If user enter an invalid updated order details, the system prompt an error message and goes back to Step 3 of S-3.

S-4,1a1: If user enters an invalid keyword for searching the order detail, the system will prompt an error message and goes back to Step 1 of S-4.

Reservation Detail Use Case Diagram

Diagram 2.6.4 Reservation Detail Use Case Diagram

Reservation Use Case Description

Use Case Name : Reservation Actors : Staff

Brief Description: This use case describes how a staff can add, delete, search a reservation and check for the reservation detail.

Pre-condition: The Staff is logged-in into the system.

Normal Flow of Events :

Actor Actions System Response

1. User clicks on „Reservation‟ button to enter the page.

3. User will enter the member ID.

5. User decides whether they want to add, search, edit or delete the member‟s profile.

2. The system will display the reservation interface.

4. The system will validate the existence of the member ID.

If the user wants to add a new reservation S-1 : add reservation is performed.

If the user wants to search a reservation detail S-2 : search reservation is

performed.

If the user wants to delete a reservation record S-3 : delete reservation is performed.

Sub Flows:

S-1: Add Reservation

1. The system will display a reservation form.

2. The system will retrieve the seat and time slot detail from the database.

3. The user will enter the reservation detail.

4. The user will select the seat and time slot that is available.

5. The system will validate the reservation detail.

6. If valid, the new reservation is inserted into the reservation database.

7. The system will send a SMS notification to the user.

S-2: Search Reservation

1. The user will enter the keyword required for searching a particular reservation detail.

2. The system will search the particular reservation detail based on the keyword and display in proper format.

S-3 : Delete Reservation

1. The user will enter the keyword required for searching a particular reservation detail.

2. The system will search the particular reservation detail based on the keyword and display in proper format.

3. The Staff can delete the reservation detail by click on the delete button.

4. The system will prompt a confirmation message.

5. If the user clicks on confirm button, the system will delete the reservation detail from the database.

Alternate Flows:

S-1, 5a1: If user enter an invalid reservation details, the system prompt an error message and goes back to Step 3 of S-1.

S-2, 1a1: If user enters an invalid keyword for searching the reservation detail, the system will prompt an error message and goes back to Step 1 of S-2.

S-3, 1a1: If user enters an invalid keyword for searching the member detail, the system will prompt an error message and goes back to Step 1 of S-3.

Payment Detail Use Case Diagram

Diagram 2.6.5 Payment Detail Use Case Diagram

Payment Use Case Description

Use Case Name : Payment Actors : Staff

Brief Description: This use case describes how a staff can generate bill, receipt and carry out payment transaction.

Pre-condition: The Staff is logged-in into the system.

Normal Flow of Events :

Actor Actions System Response

1. User clicks on „Payment‟ button to enter the page.

3. User decides whether they want to generate bill, receipt or make payment transaction.

If the user wants to generate bill S-1 : generate bill is performed.

2. The system will display the payment interface.

If the user wants to make payment S-2 : make payment is performed.

If the user wants to generate receipt S-3 : generate receipt is performed.

Sub Flows:

S-1: Generate Bill

1. The user will enter the table ID.

2. The system will retrieve the ordering detail and payment detail from the database based on the table ID.

3. The system will display the billing information.

4. The user will click on generate bill button.

5. The system will print the bill.

S-2: Make Payment

1. The system will identify the payment method selected by user.

2. The staff needs to enter PIN code to access customer‟s PayPal account.

3. PayPal system, the external entity transfer amount and update customer‟s balance.

4. The system will update the payment status.

S-3 : Generate Receipt

1. The user will enter the table ID.

2. The system will validate the latest payment status based on the table ID.

3. The system will retrieve the payment history based on the table ID.

4. The system will display the receipt information.

5. The user will click on generate receipt button.

6. The system will generate the receipt.

Alternate Flows:

S-1, 1a1: If user enters an invalid table ID, the system prompt an error message and goes back to Step 2 of S-1.

S-2, 2a2: If user enters the insufficient amount for the payment transaction, the system will prompt an error message and goes back to Step 1 of S-2.

S-2, 3a1: PayPal system, the external party system will validate the username and password, if the password and username mismatch, it will goes back to Step 2 of S-2.

S-2, 3a2: If the customer PayPal account balances are insufficient for the payment, the transaction will be cancel and back to Step 1 of S-2.

S-3, 1a1: If user enters an invalid table ID, the system prompt an error message and goes back to Step 2 of S-1.

S-3, 2a1: If the payment status is unpaid, the system will prompt an error message and goes back to Step 1 of S-3.

Report Detail Use Case Diagram

Diagram 2.6.6 Report Detail Use Case Diagram Report Use Case Description

Use Case Name : Report Actors : Staff

Brief Description: This use case describes how a staff can view and generate the report.

Pre-condition: The Staff is logged-in into the system.

Normal Flow of Events :

Actor Actions System Response

1. User clicks on „Report‟ button to enter the page.

4. User will select the report criteria.

8. User will decide whether to print the report or not to print the report.

If user wants to print the report S-1: Print Report is performed. information from the database based on the report criteria selected.

6. The system will generate the report.

7. The system will display the report information in proper format.

Sub Flows:

S-1: Print Report

1. The user will click on print button.

2. The system will prompt a confirmation message whether to print the report.

3. If user clicks on confirm button, the system will print the report.

Alternate Flows:

4a1: If the report criteria selected by user is invalid, the system will prompt and error message and goes back to Step 4.

Kitchen Detail Use Case Diagram

Diagram 2.6.7 Kitchen Detail Use Case Diagram

Kitchen Use Case Description

Use Case Name : Kitchen Maintenance Actors : Staff

Brief Description: This use case describes how a staff can view the food list and update the food status

Pre-condition: The Staff is logged-in into the system.

Normal Flow of Events :

Actor Actions System Response

1. User clicks on „Kitchen Maintenance‟

button to enter the page.

4. User decides whether they want to filter the food list or edit the food status.

If the user wants to filter the food list S-1 : filter food list is performed.

If the user wants to edit food status S-2 :

Sub Flows:

S-1: Filter Food List

5. The system will filter and rearrange the existing food list.

6. The system will redisplay the food list.

S-2: Edit Food Status

3. The user click on the edit button.

4. The system will update the selected food record and update the database.

Related documents