Align your team with a UML use case diagram

To identify actors, focus on roles or functions. They can be users, external services, or even other systems. Keep it broad enough to stay useful, but specific enough to make sense. Actors should represent anything that interacts with the system you’re building.

For example, in a banking system, the customer is an actor who logs in to check their balance and transfer money, while the payment gateway is another actor that processes the transaction in the background. In a delivery system, the courier is an actor who receives delivery requests and updates delivery status, as is the admin who manages orders and users.

An “include” relationship means one step always happens as part of another step. It’s not optional — it’s something that must be done every time.

For example, in a banking app, a “Withdraw money” step may include “Verify Identity” after it, because confirming who the user is may be necessary before allowing them to take money out. The same idea can apply in healthcare systems where checking a patient’s appointment details might always be needed before accessing their record.

An “extend” relationship means an extra step that only happens sometimes. The main process can still run without it, and the extended behavior only happens under certain conditions.

For example, “Print receipt” extends “Withdraw Money” because the user may choose to print a receipt or not. Another example is “Send security alert” extending “Login”, which only happens if unusual activity is detected.

A use case diagram is the overall view of a system. It shows the main parts only, like who’s involved in a system and what they’re trying to achieve. A flowchart can be more intensive and detailed. It breaks the process down into specific steps, including decisions, conditions, and the exact order of actions.

For example, in a food delivery app, a use case diagram shows the main actors and what they do: the customer (actor) places an order (use case), the restaurant (actor) prepares the food (use case), and the delivery rider (actor) completes the delivery (use case).

A flowchart, on the other hand, can break down one of these specific processes into detailed steps. So, for placing an order, that can be selecting items, adding them to cart, entering delivery details, processing payment, and so on.

A system boundary, often represented by a box, shows what’s inside (use cases) and what’s outside (actors) a certain system. It keeps the scope clear, making it easier to understand what the system actually does.

In a university enrollment system, you would include actions like enrolling in courses, accessing learning materials, viewing class schedules, and paying tuition fees within the boundary because those are the things that actors (students or lecturers) would do.