Question
What is a Use Case (UC) in UML and what perspective does it capture?
Answer
A use case captures a functional requirement from the user's outside-in view: who (actor) does what (interaction) with the system, and why (goal).
* A use-case diagram — actors outside the system boundary linked to the use cases they drive. — Marcel Douwe Dekker, CC BY-SA 3.0, via Wikimedia Commons. *
A use case deliberately stays on the outside of the system — it describes the value a user gets, never how the code achieves it. That external framing is what makes use cases readable by non-engineers (customers, analysts) and a good place to start a requirements discussion.
A UC answers three questions:
| Question | Element | Example |
|---|---|---|
| Who? | Actor (stick figure) | Customer, Admin |
| What? | Use Case (oval/ellipse) | "Reserve Hotel Room" |
| Why? | Goal/Purpose | Complete a booking |
Key characteristics:
- Drawn as an oval in UML, named with a verb phrase (e.g., "Process Payment")
- Describes a complete sequence of events from the actor's point of view
- External perspective only — no implementation details
- Each UC represents one distinct piece of business functionality
Go deeper:
Use case diagram (Wikipedia) — UML behavioral diagram: actors, use cases, the outside-in view.
Note saved — thanks!
Question
What are the four major elements of a UML Use Case Diagram (UCD)?
Answer
Just four: Actors (who), the System boundary (what's in scope), Use Cases (what it does), and the Relationships (lines) connecting them.
A UCD is intentionally minimal — these four are all you get, which is why it's such a fast, low-jargon way to agree on scope with non-technical stakeholders early in a project. Each element answers one question:
| Element | Answers | Description | Visual |
|---|---|---|---|
| Actor | Who? | Entity outside the system that interacts with it (user, device, external system) | Stick figure |
| System | What's in scope? | The boundary separating what you're building from the outside world | Rectangle |
| Use Case | What does it do? | A service or function the system offers | Oval/ellipse |
| Relationship | How do they connect? | Lines tying actors to use cases (and use cases to each other) | Lines/arrows |
Why it matters for security: the system boundary is also the trust boundary, and every actor-to-use-case line is a place where untrusted input crosses into your system — so the same four-element sketch that scopes the project also maps its initial attack surface.
Note saved — thanks!