1. Use Cases

2. Question 1
Each waiter is assigned a group of tables, after taking orders for a table the waiters enter the orders (a list of dishes and drinks ordered by the diner or group of diners) into the system at the PC. The waiter usually knows of any dishes that are unavailable before taking an order but occasionally one of the specials will sell out. The system must confirm the availability of dishes. Should an item not be available the system must allow the waiter to change or even delete a customer’s order. Dishes to be prepared are sent to the kitchen, drinks orders to the drink section. Starters and main course orders are usually taken together. Drinks and desert orders may be taken separately.
Kitchen staff sees the dish orders on their screen, prepare them in an appropriate sequence and confirm preparation to the system when complete, similarly with the drink section.  
When a waiter sees the completion indications on his terminal he collects the items and takes them to the table. The waiter can also check on the status of dish and drink orders.
At the end of the meal the waiter will have the system print a bill, and he will enter the details of payment for it. The management can give discounts.
The system keeps track of the numbers of customers served by each waiter and the amount of money taken by each waiter. The management can view these statistics.

3. Question 1 Write down the functional and non- functional requirements.
• The Waiter shall enter order of drinks and food into the system
• The system shall alert the waiter that the food is out of stock. Then the Waiter shall change or delete the order in the system
• The system shall alert the Kitchen staff of the food orders
• The system shall alert the Bar staff of the drink orders
• Kitchen and Bar staff shall confirm preparation to the system when complete
• The system shall alert the Waiter that the drink or food order is ready
• The Management should grant a discount from the bill
• The Waiter shall use the system to print out the bill
• The Waiter shall enter the payment details into the system
• The Management shall use the system to view the statistics regard numbers of customers served by each waiter and the amount of money taken by each waiter
 Non- functional requirements
Experienced users shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.
(Reliability) If the connection between the user and the system is broken prior to an order being either confirmed or canceled, the Online Bookshop System shall enable the user to recover an incomplete order.

4. Question 1
We should be very careful when specifying non-functional requirements. Why?
If you don’t do it right you will build a very elegant software solution that solves the wrong problem. The result is project failure, wasted time and money, personnel frustration, and customer dissatisfaction.

5. Question 1
Use the following table to identify the: actor and unit of functionality.
Actor
Unit of Functionality
Waiter
The Waiter shall enter order of drinks and food into the system
The system shall alert the waiter that the food is out of stock. Then the Waiter shall change or delete the order in the system
The system shall alert the Waiter that the drink or food order is ready
The Waiter shall use the system to print out the bill
The Waiter shall enter the payment details into the system
Kitchen staff
• The system shall alert the Kitchen staff of the food orders
• Kitchen staff shall confirm preparation to the system when complete
Bar staff
• The system shall alert the Bar staff of the drink orders
• Bar staff shall confirm preparation to the system when complete
Management
• The Management shall use the system to view the statistics regard numbers of customers served by each waiter and the amount of money taken by each waiter
• The Management should grant a discount from the bill

6. Question 1
Draw the use case diagram.

7. Question 1
Draw the use case diagram.

8. Question 1
Draw the use case diagram.

9. Question 1 Write the high level description of all use cases.
Use case: Input Order
Actors: Waiter
Goal: To input an order for a meal
Description:
When a Diner orders a meal, the Waiter writes down the order and puts it into the
system. The system presents this order to the Kitchen staff who prepare the food.
Use case: Prepare orders
Actors: Kitchen staff and Bar staff
Goal: To prepare the orders presented by the system
The system presents the meal order to the Kitchen staff to prepare the food. The
system also presents the drinks order to the Bar staff to prepare the drink.

10. Question 1 Use case: Announce order readiness
Actors: Kitchen staff and Bar staff
Goal: To Alert the Waiter to the readiness of the order
Description:
The Bar staff prepare the drinks and use the system to send an announcement to the
Waiters terminal that they are ready to be served. The Kitchen staff prepare the
dishes and use the system to send an announcement to the Waiters terminal that
they are ready to be served.
Use case: Print Bill
Actors: Waiter
Goal: To print a bill for the Diner
Once the Diner has finished their meal, the Waiter uses the system to print a bill
for presentation to the Diner
Use case: Input payment details
Goal: To input payment details to the system
The Waiter takes the payment from the Diner and uses the system to input the
details about the payment.

11. Question 1 Write the high level description of all use cases.
Use case: Grant discount
Actors: Management
Goal: To grant a discount from the bill
Description:
Management use the system to alter the bill that is to be presented to the Diner.
Use case: View statistics
Goal: To view statistics
Management use the system in order to view various statistics about the Waiters
and the amount of money that they have taken.

12. Question 1
Write the expanded description of the two most important use cases.
Take order
Take payment

13. Question 1

14. Question 1

15. Question 2
The concrete use cases are Phone Order (initiated by the Customer actor) and Internet Order (initiated by Internet Customer). These are both variations of the more general Place Order use case. To simplify the Place Order use case, the Request Catalog use case and Supply Customer Data use case are used.
Draw the use case diagram showing use cases relationships and actors generalization if exist.
The Request Catalog use case represents an optional segment of behavior that is not part of the primary purpose of Place Order.
The Supply Customer Data use case represents a segment of behavior that was factored out since it is a separate function of which only the result is affecting the Place Order use case. The Supply Customer Data use case can also be reused in other use cases.

16. Question 2
Draw the use case diagram showing use cases relationships and actors generalization if exist.

17. Question 2
Identify abstract use cases. What could be changed if Order Registry Clerk actor, who can enter orders into the system on behalf of all kind of customers, are added to the model?
*This actor would initiate the general Place Order use case.
*The child use cases can add behavior to the structure that the parent use case provides, and also modify behavior in the parent
* Place Order can also be specialized by the use cases Phone Order or Internet Order

18. Question 2
Are use cases always related to actors? Are there exceptions?
The execution of each use case includes communication with one or more actors.
A use case instance is always started by an actor asking the system to do something. This implies that every use case should have communicates-associations with actors.
The reason for this rule is to enforce the system to provide only the functionality that users need, and nothing else.
Having use cases that no one requests is an indication that something is wrong in the use-case model or in the requirements.

19. Question 2
Are use cases always related to actors? Are there exceptions?
However, there are some exceptions to this rule:
If a use case is abstract (not separately instantiable), its behavior may not include interaction with any actor. In that case, there will not be any communication-associations to actors from that abstract use case.
A child use case in a generalization-relationship does not need to have an actor associated with it if the parent use case describes all actor communication.
A base use case in an include-relationship does not need to have an actor associated with it if the inclusion use case describes all actor communication.
A use case may be initiated according to a schedule (for example, once a week or once a day), which means the system clock is the initiator. The system clock is internal to the system - and the use case is not initiated by an actor, but by an internal system event. If no other actor interaction occurs in the use case, it will not have any associations to actors. However, for clarity, you can use a fictive actor "Time" to show how the use case is initiated in your use-case diagrams.

20. Concrete and Abstract Use Cases
A concrete use case is initiated by an actor and constitutes a complete flow of events. "Complete" means that an instance of the use case performs the entire operation called for by the actor.
An abstract use case is never instantiated in itself. Abstract use cases are included in (Include-Relationship), extend into (Extend-Relationship), or generalize (Use-Case-Generalization) other use cases.
When a concrete use case is initiated, an instance of the use case is created. This instance also exhibits the behavior specified by its associated abstract use cases. Thus, no separate instances are created from abstract use cases.
The distinction between the two is important, because it is concrete use cases the actors will "see" and initiate in the system.
You indicate that a use case is abstract by writing its name in italics.

21. Simple Online shopping portal
An online shopping portal allows their customers to browse or buy different items. A customer may buy item(s) or just view the items and logout. If the customer decides to purchase an item, he/she selects the item and adds it to the shopping cart. Once the customer finishes selecting the item(s) the cart can be viewed. The customer can edit the final cart then submit the final cart for payment, or logout from the site without buying the items. The site's administrator can add or update different items in the system, manage the registration of new customer, and ensure the authorization of already registered customers.
Draw the use case diagram for this system,
without using extends or includes use cases…

22. Simple Online shopping portal
An online shopping portal allows their customers to browse or buy different items. A customer may buy item(s) or just view the items and logout. If the customer decides to purchase an item, he/she selects the item and adds it to the shopping cart. Once the customer finishes selecting the item(s) the cart can be viewed. The customer can edit the final cart then submit the final cart for payment, or logout from the site without buying the items. The site's administrator can add or update different items in the system, manage the registration of new customer, and ensure the authorization of already registered customers.
Draw the use case diagram for this system,
without using extends or includes use cases…

23. Online shopping System
Browse Items
Log in
Log out
Customer
Add item to cart
View the cart
Edit the cart
Make Payment
Add new Item
Update Item
Register
Admin
Authorize Customers

24. Question 4
Do the following operations on the use case diagram stated bellow

25. Question 4
Update the use case diagram such that a new patient can open a file. Also nurses help in making appointments and they can view a schedule. Also, Management and doctors can view the schedule. Add any other appropriate missing things.

26. Question 4
Nurse
View Schedule
<<extends>>
Open File

27. Question 4 Write a high level format for make appointment use case.
Write typical course of events and alternatives for make appointment use case.

28. Use case: Make appointment
Actor: Patient (initiator), Nurse.
Purpose: To record a new appointment.
Overview (Success Scenario): This use case begins when the patient ask a nurse to reserve an appointments with a certain doctor. On completion, an appointment slip is produced.
Type: Primary, Essential.

29. Use case: Make appointment
System Response
Actor Action
1. This use case begins when the patient come to the nurse or call her to ask for an appointment.
3. Show patient information.
2. The nurse request the patient id from the patient and enter it.
5. System returns all possible appointment dates and times for the specified doctor.
4. Nurse ask the patient for doctor name and department and enter them.
7. Reserves the appointment.
6. Nurse tell the patient about all the possibilities and get from him/her the most desired one, and reserve it.
9. Generate appointment slip.
8. The nurse request the appointment slip.
10. The nurse gives the printed appointment slip to the patient.
11. The patient leaves with appointment slip.

30. Use case: Make appointment
Alternatives: Line 2. If patient was a new one, then a new file should be created; see open file use case.
Line 2. If patient forgot ID, provide Phone number.
Line 3. If the ID was wrong, the system will display a message to indicate that.