Use case diagram for food delivery app
This use case diagram shows who interacts with a food delivery app and what each of them can do inside the system. It suits students learning UML use case diagrams and developers scoping the main features of a delivery platform.
Example: Use case diagram for food delivery app: click to open it in the editor and change it.
Actors and their use cases
The system boundary is labeled Food delivery app. It contains six use cases. Three actors sit outside it: Customer on the left, and Restaurant and Delivery partner on the right.
| Actor | Connected use cases |
|---|---|
| Customer | Browse menu, Place order, Track order |
| Restaurant | Accept order |
| Delivery partner | Deliver order, Track order |
How the use cases relate
- Place order includes Pay online. Every order always runs the payment step, so payment is modeled as a required sub-behavior and not as a separate goal of the Customer.
- Track order is shared. The Customer starts it, and the Delivery partner takes part, since the rider's progress is what gets tracked.
- Accept order belongs to the Restaurant. This is where an incoming order gets confirmed.
- Deliver order belongs to the Delivery partner. It covers handing the food to the customer.
Read in sequence, the diagram follows the life of an order. The customer browses, places the order and pays. The restaurant accepts it. The delivery partner delivers it while the customer tracks it.
How to adapt it for your project
- Add an Admin actor if your app needs restaurant onboarding, refunds or reporting.
- Use an extend relationship for optional behavior. One example is Apply coupon extending Place order.
- Split Pay online into payment methods only if they behave differently. Otherwise keep it as one use case.
- Add customer goals your app supports, such as Rate order or Cancel order, and link them to the right actors.
- Open and edit the diagram to rename use cases so they match your own feature list.
Tip: Name every use case as a verb plus a noun, such as Place order, and describe a goal the actor cares about. Screens and buttons are not use cases. Show how the order moves step by step in a separate activity or sequence diagram.
Frequently asked questions
Who are the actors in a use case diagram for a food delivery app?
This diagram has three actors: **Customer**, **Restaurant** and **Delivery partner**. Each one connects to the use cases it starts or takes part in.
Why is Pay online an include relationship?
Payment always happens as part of **Place order**, so it is a mandatory piece of that use case. An include relationship models exactly that kind of required, reusable step.
How many use cases does the food delivery app diagram have?
It has six: **Browse menu**, **Place order**, **Pay online**, **Track order**, **Accept order** and **Deliver order**. All six sit inside the **Food delivery app** system boundary.
Make your own use case diagram with AI →