← VCE Software Development U3O2

Drawing a use case diagram from a scenario

A diagram drawn from a scenario by finding each actor and their goals, then placing actors outside a system boundary box and use cases inside it, linking them with lines.

Part of: VCE Software Development - U3O2 - Analysis and Design — Module 50

Understanding Drawing a use case diagram from a scenario in VCE Software Development U3O2

What it does: A step that always happens as part of another use case is shown with an includes relationship. The arrow points to the included use case. Start by reading the scenario to find who uses the system (actors) and what each of them wants to achieve (their goals). The goals become use cases. Actors are users or external systems that interact with the software, so they sit outside the boundary. Only the use cases sit inside it. A use case is a goal written as a short verb phrase, such as Pay for order. Customer is an actor, not a use case.

Common mistakes: The system boundary is named after the whole system being built, such as Library App. Member is an actor and sits outside the boundary. Line 1 should be 'System: Library App'. A use case is something the system does, so it sits inside the system boundary. Only actors go outside. It should be 'Inside: Place order'.

Class: _____________________  ·  Name: _____________________  ·  Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

🖨 Print worksheet + answer key Add Drawing a use case diagram from a scenario to a class →

This module's key terms are also in a printable crossword (Modules 42–51) and word search (Modules 26–51).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning
Duo
A scenario says: 'Students borrow books and librarians approve new memberships.' How do you start drawing the use case diagram?
Draw the database tables first, then add the actors laterFind the actors (students, librarians) and the goals each one has
Matches
A Student stick figure is drawn inside the system boundary box with the use cases.
↓
Actors must be placed outside the system boundary. Only use cases belong inside it.
Applying
Meanings
Term
use case diagram
Meaning
A diagram drawn from a scenario by finding each actor and their goals, then placing actors outside a system boundary box and use cases inside it, linking them with lines.
Practice
System: Library App
Testing
Gaps
: Member
Check Answer
Spots
1System: Member
2Outside: Member

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

The 'Tree Frog' badge — Leap of Logic, one of Cloodit's 106 collectible badges
Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy
Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games
Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print
Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Add to class →

Quick Questions

1. A scenario says: 'Students borrow books and librarians approve new memberships.' How do you start drawing the use case diagram?
A. Find the actors (students, librarians) and the goals each one has ✓
B. Draw the database tables first, then add the actors later
Start by reading the scenario to find who uses the system (actors) and what each of them wants to achieve (their goals). The goals become use cases.
2. Where do you place the actors in a use case diagram?
A. Outside the system boundary box ✓
B. Inside the system boundary box
Actors are users or external systems that interact with the software, so they sit outside the boundary. Only the use cases sit inside it.
3. Scenario: 'A customer can pay for an order.' Which is the best use case name?
A. Customer
B. Pay for order ✓
A use case is a goal written as a short verb phrase, such as Pay for order. Customer is an actor, not a use case.
4. Which item from the scenario 'A teacher marks attendance and the Principal views reports' is an actor?
A. Views reports
B. Principal ✓
The Principal is a person who uses the system, so it is an actor. Views reports is a goal, so it becomes a use case.
5. Scenario: 'Every time a user places an order, the system must check their login.' Which relationship links Place order to Check login?
A. Includes, because the login check always happens ✓
B. Extends, because the login check always happens
Includes is used when a step always happens as part of another use case. Extends is used for optional extra behaviour.

Match the Pairs

Actor: Student (outside the box) → A person or external system that interacts with the system is drawn as a stick figure outside the system boundary.
Use case: Borrow Book (oval inside the box) → A goal an actor wants to achieve with the system is written as a verb phrase in an oval inside the system boundary.
The scenario says every loan must also check the member's account status, so the use case is always required as part of the loan. → Borrow Book <<include>> Check Account
The scenario says a librarian can sometimes add a late fee, but only when a book is returned late, so the use case is optional. → Add Late Fee <<extend>> Return Book
A Student stick figure is drawn inside the system boundary box with the use cases. → Actors must be placed outside the system boundary. Only use cases belong inside it.
Use case oval named 'Library Database' linked to the Student actor → A use case should be a goal written as a verb phrase, such as Search Catalogue. A data store like a database is not a goal.

Key Term

use case diagram
A diagram drawn from a scenario by finding each actor and their goals, then placing actors outside a system boundary box and use cases inside it, linking them with lines.

Fill in the Blanks

1. Scenario: A member borrows a book. Actor: Member
Hint: Type the label for a person or external system that sits outside the system boundary.
2. Actor: Member (outside boundary) Use case: Borrow book (inside boundary)
Hint: Type the two-word label for a goal the system performs, drawn inside the boundary.
3. Use case: Borrow book Member --- Borrow book
Hint: Type the actor that the association line links to this use case.
4. Step: Log in is always needed to borrow Borrow book <<include>> Log in
Hint: Type the relationship for a step that always happens as part of another use case.
5. Optional: member may email a receipt Email receipt <<extend>> Borrow book
Hint: Type the relationship for optional behaviour that only sometimes adds to a use case.

Spot the Error

Question 1
A System: Member
B Outside: Member
C Inside: Borrow book
D Link: Member - Borrow book
Line A — The system boundary is named after the whole system being built, such as Library App. Member is an actor and sits outside the boundary. Line 1 should be 'System: Library App'.
Question 2
A System: Online Shop
B Outside: Customer
C Outside: Place order
D Link: Customer - Place order
Line C — A use case is something the system does, so it sits inside the system boundary. Only actors go outside. It should be 'Inside: Place order'.
Question 3
A System: Bill App
B Inside: Pay bill
C Inside: Log in
D Include: Log in > Pay bill
Line D — An include arrow points from the base use case to the use case it always needs. Pay bill always needs Log in, so it should be 'Include: Pay bill > Log in'.
Question 4
A System: Library App
B Inside: Return
C Inside: Late fee
D Include: Late fee > Return
Line D — A late fee only applies in some cases, such as when a book is overdue. Optional or conditional behaviour is an extend relationship. It should be 'Extend: Late fee > Return'.
Question 5
A System: School Portal
B Inside: Enter marks
C Inside: Teacher
D Link: Teacher - Enter marks
Line C — Actors are users or external systems, so they are drawn outside the system boundary. Teacher should be 'Outside: Teacher'.

Student with a class code? Join your class →