Drawing a use case diagram from a scenario

Name:

Date:

Class:

Quick Questions

Shade in the A or B circle for each question.

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

2. Where do you place the actors in a use case diagram?

A Outside the system boundary box

B Inside the system boundary box

3. Scenario: 'A customer can pay for an order.' Which is the best use case name?

A Customer

B Pay for order

4. Which item from the scenario 'A teacher marks attendance and the Principal views reports' is an actor?

A Views reports

B Principal

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

Match the Pairs

Draw a line connecting each item on the left to its match on the right.

Left column		Right column
1Actor: Student (outside the box)		AA 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.
2Use case: Borrow Book (oval inside the box)		BBorrow Book <<include>> Check Account
3The scenario says every loan must also check the member's account status, so the use case is always required as part of the loan.		CActors must be placed outside the system boundary. Only use cases belong inside it.
4The scenario says a librarian can sometimes add a late fee, but only when a book is returned late, so the use case is optional.		DA goal an actor wants to achieve with the system is written as a verb phrase in an oval inside the system boundary.
5A Student stick figure is drawn inside the system boundary box with the use cases.		EA person or external system that interacts with the system is drawn as a stick figure outside the system boundary.
6Use case oval named 'Library Database' linked to the Student actor		FAdd Late Fee <<extend>> Return Book

Definitions

use case diagram

Fill in the Blanks

Complete each line of code by filling in the missing parts.

Scenario: A member borrows a book. _____: Member

Actor: Member (outside boundary) ________: Borrow book (inside boundary)

Use case: Borrow book ______ --- Borrow book

Step: Log in is always needed to borrow Borrow book <<_______>> Log in

Optional: member may email a receipt Email receipt <<______>> Borrow book

Spot the Error

Shade in the letter of the line that contains an error.

Question 1

A System: Member

B Outside: Member

C Inside: Borrow book

D Link: Member - Borrow book

Question 2

A System: Online Shop

B Outside: Customer

C Outside: Place order

D Link: Customer - Place order

Question 3

A System: Bill App

B Inside: Pay bill

C Inside: Log in

D Include: Log in > Pay bill

Question 4

A System: Library App

B Inside: Return

C Inside: Late fee

D Include: Late fee > Return

Question 5

A System: School Portal

B Inside: Enter marks

C Inside: Teacher

D Link: Teacher - Enter marks

Answer Key

Drawing a use case diagram from a scenario

Section A: Quick Questions

A — Find the actors (students, librarians) and the goals each one has

A — Outside the system boundary box

B — Pay for order

B — Principal

A — Includes, because the login check always happens

Section B: 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.

Section C: Definitions

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.

Section D: Fill in the Blanks

Scenario: A member borrows a book.
Actor: Member

Actor: Member (outside boundary)
Use case: Borrow book (inside boundary)

Use case: Borrow book
Member --- Borrow book

Step: Log in is always needed to borrow
Borrow book <<include>> Log in

Optional: member may email a receipt
Email receipt <<extend>> Borrow book

Section E: Spot the Error

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'.

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'.

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'.

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'.

C — Actors are users or external systems, so they are drawn outside the system boundary. Teacher should be 'Outside: Teacher'.