Use Case Modeling: The Big Picture

Simple Definition: Use Case Modeling is a technique used to understand

and describe the functional requirements of a system by focusing on
how users (actors) will interact with it to achieve goals.

The PDF Says: "Capture what a system is supposed to do, i.e., systems
functional requirements."

Real-World Analogy: Think of a restaurant menu. The menu doesn't tell

you how the kitchen works (the stove, the chefs, the recipes). It just tells you
what you can order (the functions) and what you'll get (the result). Use case
modeling is like creating that menu.

1. Dynamic Behavior vs. Static Behavior (The "Why")

The PDF makes an important distinction:

Type Definition Banking App Example

The database schema, the list of

The structure of the system when it's
Static classes (Customer, Account,
NOT running. What are the parts?
Behavior Transaction), the folder structure of
How are they connected?
code.

The behavior of the system WHEN it IS The user enters a password, the syst
Dynamic running. What happens when a user checks it, the user selects accounts,
Behavior logs in? What happens when they system moves money, the system
click "Transfer Money"? sends a confirmation.

The PDF says: "Only static behavior is not sufficient... dynamic behavior is
more important."

Why? Because users don't care about your database structure. They care
about what happens when they press a button. Use case modeling captures
that dynamic behavior.

2. The Core Components of a Use Case Diagram

 The PDF identifies three main parts:

Component Simple Definition Banking App Example

The people or systems that interact Customer, Bank Teller, Fraud

Actors
with your system. Detection System, Credit Bureau

The specific things the system does for Withdraw Cash, Check Balance,
Use Cases
the actors. Transfer Funds, Pay Bill

The connections between actors and The Customer "uses" Check

Relationsh
use cases, and between use cases Balance. Transfer Funds "include
ips
themselves. Verify Funds.

3. Actors (The "Who")

Simple Definition: An actor is anyone or anything that interacts with your
system. They are external to the system.

The PDF Says: "These internal and external agents are known as actors."

Important: Actors are roles, not specific people.

 Not "John Smith" but "Customer"

 Not "Jane Doe" but "Bank Administrator"

Types of Actors (Banking App):

Actor Type Example Description

Primary The person who uses the system to achieve a goal (check
Customer
Actor balance, pay bill).

Secondary Bank Supports the system or uses it for different purposes (approv
Actor Teller large transfers).
Actor Type Example Description

External Credit Another computer system that the banking app talks to (to
System Bureau check credit score for loan applications).

Hardware Card
The physical device that reads the ATM card.
Device Reader

4. Use Cases (The "What")

Simple Definition: A use case is a description of a sequence of actions that
the system performs to give an actor something of value.

The PDF Says: "Describe sequences of actions a system performs that yield
an observable result of value to a particular actor."

Let's break down that definition:

Part of
Meaning Banking App Example (Transfer Money)
Definition

1. User selects "Transfer." 2. User chooses

Sequence of A series of steps, like a
"From" account. 3. User chooses "To" account
actions recipe.
User enters amount. 5. User confirms.

The system is doing The system checks balance, deducts money,

System
the work behind the adds money to other account, logs the
performs
scenes. transaction.

Observable Something the user

"Transfer Complete!" message appears. The
result of can see and wanted to
money has moved. The user achieved their go
value achieve.
 Part of
Meaning Banking App Example (Transfer Money)
Definition

A particular It's for someone This was done BY the Customer FOR the
actor specific. Customer.

5. Use Case Diagrams (The Picture)

Simple Definition: A use case diagram is a picture that shows:

 The system boundary (what's inside vs. outside)

 The actors (stick figures outside the box)
 The use cases (ovals inside the box)
 The relationships (lines connecting them)

Banking App Example (Visual Description):

Imagine a rectangle (the system boundary) labeled "Online Banking

System."

Outside the box (Actors):

 👤 Customer (stick figure)

 👤 Bank Administrator (stick figure)
 ☐ Credit Bureau (a box representing another system)

Inside the box (Use Cases - ovals):

 ○ Check Balance
 ○ Transfer Money
 ○ Pay Bills
 ○ View Statements
 ○ Apply for Loan
 ○ Manage Users (for Admin only)

Lines (Relationships):

 A line connects Customer to Check Balance, Transfer Money, Pay

Bills, View Statements, Apply for Loan.
 A line connects Bank Administrator to Manage Users.
 A line connects Apply for Loan to Credit Bureau (showing the system
talks to an external system).

6. Why Use Cases Are Powerful (The Benefits)

The PDF lists several benefits. Let's translate them:

Benefit (Textbook) Simple Translation Why It Matters

"Support requirements Helps you figure out Gives you a structured way to as
engineering activities" what to build. "What should this system do?"

"Capture what a system is Ensures you don't forget anythin

Lists all the features.
supposed to do" important.

"Describe sequences of Shows the step-by-step Helps developers understand

actions" flow. exactly how a feature should wor

Keeps you focused on what the u

"Yield an observable result
Focuses on user goals. actually wants, not just cool
of value"
technology.

"Model actions at external Shows what users see

Helps design the user experience
interface" and touch.

Shows the interaction

"Capture how the system
between user and Helps design the workflow.
coordinates human actions"
system.

7. Multiple Diagrams for Complex Systems

The PDF Says: "A single use case diagram captures a particular
functionality of a system. Hence to model the entire system, a number of use
case diagrams are used."

It would be too messy. Instead, you create multiple diagrams:

Diagram Name Focus Use Cases Included

Customer Account What customers do with Check Balance, View Statements,

Management their accounts. Update Profile

Transfer Money, Pay Bills, Schedu

Money Movement How money moves.
Payments

Apply for Loan, Check Loan Statu

Loan Services Loan-related activities.
Make Loan Payment

Create User, Reset Passwords, Vie

Administration What admins do.
Logs

Summary: Use Case Modeling at a Glance

Concept Simple Definition Banking App Example

Dynamic What the system DOES when Transferring money, checking

Behavior running. balance.

Actor Who uses the system. Customer, Bank Teller, Credit Bure

Use Case A specific goal the actor achieves. "Withdraw Cash," "Pay Bill."

Sequence of 1. Enter amount. 2. Select account

The steps to achieve the goal.
Actions Confirm.
 Concept Simple Definition Banking App Example

Observable
The visible outcome. "Payment Successful" message.
Result

Use Case The picture showing actors, use A rectangle with stick figures outsi
Diagram cases, and relationships. and ovals inside.

System The line between what's in your Inside: Your code. Outside: The use
Boundary system and what's outside. other banks, credit agencies.

The Problem: Many Diagrams Show "Dynamic

Behavior"
The PDF correctly states that five UML diagrams capture dynamic behavior:

1. Use Case Diagrams

2. Activity Diagrams

3. Sequence Diagrams

4. Collaboration Diagrams (now called Communication Diagrams)

5. Statechart Diagrams

So if they all show dynamic behavior, why do we need all five? And what
makes Use Case Diagrams unique?

The Simple Answer: Different Levels of Detail

Think of it like planning a vacation:
Diagram Type Analogy What It Shows

Use Case A map of countries you'll High-level: "I'm going to France, Italy, and
Diagram visit Spain"

Activity Medium-level: "I'll drive from Paris to Lyon

The route you'll drive
Diagram Marseille"

Sequence The hour-by-hour Detailed: "At 9am I check out of hotel, at

Diagram itinerary 10am I visit the museum..."

Statechart How your mood Special view: "Happy when sightseeing, tir
Diagram changes during the trip at night, hungry at mealtimes"

All show dynamic behavior, but at different levels and from different
angles.

The Unique Purpose of Use Case Diagrams

Let's break down each specific purpose from your PDF with real examples.

Purpose 1: "Used to gather the requirements of a system"

What This Means: Use case diagrams help you discover and organize what
the system should do.

Banking App Example:

You sit with bank customers and ask: "What do you want to do with the
app?" They tell you:
 "Check my balance"

 "Transfer money to my wife"

 "Pay my credit card bill"

 "Find an ATM nearby"

Each of these becomes a use case in your diagram. The act of creating the
diagram forces you to list all these requirements so nothing is forgotten.

Purpose 2: "Used to get an outside view of a system"

What This Means: Use case diagrams show the system from the user's
perspective, not the developer's perspective. They ignore internal details.

Banking App Example:

 Outside View (Use Case Diagram): Customer sees "Transfer Money."

They don't care how it works.

 Inside View (Code): Developers care about databases, APIs, encryption,

validation rules.

The use case diagram deliberately hides complexity. It shows only what's
visible to the outside world.

Perspective Shows Hides

Outside View Features, goals, actors Code, databases, algorithms

Inside View Implementation details User experience

 Purpose 3: "Identify the external and internal factors influencing the
system"

What This Means: Use case diagrams show what's outside the system
(actors) and what's inside (use cases), and how they influence each other.

Banking App Example:

Factor
What It Is Banking App Example Influence on System
Type

Customers, Bank
Actors Customers want easy
External Tellers, Credit Bureaus,
outside the transfers. Regulators
Factors Government
system require security.
Regulators

Use cases Check Balance, These are the functions

Internal
inside the Transfer Money, Pay the system must perform
Factors
system Bills to satisfy external actors.

The system boundary line in the diagram literally

separates internal from external.

Purpose 4: "Show the interaction among the requirements and actors"

What This Means: Use case diagrams show who does what. They
connect actors to their goals.

Banking App Example:

Instead of a long list of requirements like:

 Requirement 1: System shall display balance

 Requirement 2: System shall allow transfers

 Requirement 3: System shall allow bill payment

You create a visual map:

 text

[Customer] ------○ Check Balance

\
\----○ Transfer Money
\
\---○ Pay Bills

[Bank Admin] ----○ Manage Users

\
\--○ View Audit Logs

THE STRENGTHS OF USE CASE MODELING

Strength 1: "Relatively easy to write and easy to read"

What This Means: Use cases use plain language, not technical code or
complex diagrams.

Banking App Example:

Instead of writing technical specifications like:

"The system shall implement a secure socket layer connection to transmit

encrypted payloads containing user credentials to the authentication
microservice..."

You write a simple use case:

Use Case: User Login

1. User enters username and password

2. System verifies credentials

3. System grants access to account

Why it matters: Everyone can understand it—managers, customers,

developers, testers.
 Strength 2: "Comprehensible by users"
What This Means: Real users (who don't know programming) can read and
understand use cases.

Banking App Example:

You show a customer the "Transfer Money" use case:

1. User selects "Transfer"

2. User chooses "From" account

3. User chooses "To" account

4. User enters amount

5. User confirms

6. System shows confirmation

The customer can immediately say: "Wait, you forgot step 4.5—I need to
select whether it's one-time or recurring!" This feedback is invaluable.

Why it matters: Users can validate requirements directly without needing a

translator.

Strength 3: "Engage the users in the requirements

process"
What This Means: Use cases give users a way to participate actively in
designing the system.

Banking App Example:

During a meeting, you put the use case on a whiteboard. The customer says:

 "Actually, I need to save favorite recipients"

 "I want to schedule transfers for future dates"

 "Can I get a notification when the transfer completes?"

 Each comment becomes a new requirement or an extension to the use case.

Why it matters: Users feel ownership of the system. They're not just told
what's being built—they help shape it.

Strength 4: "Force developers to think through the

design from a user viewpoint"
What This Means: Developers naturally think about code, databases, and
algorithms. Use cases force them to think about what the user experiences.

Banking App Example:

A developer might initially think: "I need to build a transfer function with
database updates and transaction logs."

But the use case forces them to think:

 What does the user see first?

 What options do they have?

 What happens if they enter an invalid amount?

 What confirmation do they get?

Why it matters: The result is a system that's intuitive and useful, not just
technically impressive

Strength 5: "Identify a context for the requirements of

the system"
What This Means: Use cases show not just what the system does,
but when and why it does it.

Banking App Example:

A simple requirement might say: "System shall display balance."

But the use case adds context:

Use Case: Check Balance After Large Purchase

Context: User just made a big purchase and wants to ensure funds are
available.
1. User logs in

2. User views recent transactions

3. User checks current balance

4. System shows balance with pending transactions highlighted

Why it matters: Context helps designers create better user experiences

that match real situations.

Strength 6: "Critical tool in design, implementation,

analysis and testing"
What This Means: Use cases are useful throughout the entire project
lifecycle.

Phase How Use Cases Help Banking App Example

"We need a Transfer Money feature with these

Design Define what to build
steps"

Implementati
Guide developers "Write code that follows this sequence"
on

Validate
Analysis "Does this use case cover everything users need
requirements

Test each step: "What if user enters negative

Testing Create test cases
amount?"

Why it matters: Use cases become a single source of truth that everyone
references.
 Strength 7: "Rapid change allows exploratory
approach"
What This Means: Use cases are easy to modify. You can quickly explore
different approaches.

Banking App Example:

You sketch a use case for "Pay Bill":

Version 1: User selects payee, enters amount, confirms

After user feedback, you rapidly change it:

Version 2: User selects payee, enters amount, selects payment date,

confirms, sewschedule

This took 2 minutes to change on paper. Changing code would take days.

Why it matters: You can experiment and iterate quickly without costly
rework.

Strength 8: "Serve as inputs to user documentation"

What This Means: The use cases you write become the basis for user
manuals and help files.

Banking App Example:

The "Transfer Money" use case steps become:

 The Help section in the app

 The User Guide chapter on transfers

 The Tooltips that appear when users hover over buttons

Why it matters: Documentation is consistent with what was actually built,

and you don't have to start from scratch.

The Weaknesses of Use Case Modeling

Now for the critical part—understanding what use cases don't do well.
 Weakness 1: "Lack of non-functional requirements"
What This Means: Use cases describe what the system does, but not how
well it does it.

Banking App Example:

Aspect Use Case Covers Use Case MISSES

Function "User transfers money" ✅ Covered

Performance How fast should transfer be? ❌ Not covered

Security How secure must transfer be? ❌ Not covered

Reliability What if system crashes during transfer? ❌ Not covered

Usability Should transfer take 3 clicks or 10? ❌ Not covered

The Problem:
You might build a perfect "Transfer Money" feature that:

 Works correctly (✅ functional)

 But takes 30 seconds per transaction (❌ poor performance)

 And doesn't encrypt data (❌ poor security)

 And crashes if 100 people use it simultaneously (❌ poor reliability)

The Solution: You need supplementary documents that capture non-

functional requirements alongside use cases.
Non-Functional Requirement Banking App Example

Performance "Transfer must complete in under 5 seconds"

Security "All transfers must use 256-bit encryption"

Reliability "System must handle 10,000 concurrent transfers"

Availability "Transfer service must be available 99.99% of the time"

Weakness 2: "Lack of what the system shall not do"

What This Means: Use cases describe positive scenarios—what the
system should do. They don't describe forbidden behaviors or things the
system must avoid.

Banking App Example:

Use Case Says What's MISSING

"User can transfer up to $10,000" ❌ System shall NOT allow transfers over $10,000

"User can log in with password" ❌ System shall NOT store passwords in plain text

"User can schedule future ❌ System shall NOT allow scheduling payments on past
payments" dates

"User can add payees" ❌ System shall NOT allow adding duplicate payees
 Why This Matters:
Systems need boundaries. You need to specify:

 Constraints: What limits exist?

 Prohibitions: What is forbidden?

 Safety rules: What must never happen?

 Security rules: What accesses are denied?

The Solution: Create additional documentation:

 Business Rules Document: "Maximum transfer limit is $10,000 per day"

 Security Requirements: "Passwords must never be logged or stored in

plaintext"

 Constraints Document: "Payment dates cannot be in the past"

Summary: Use Cases Strengths and Weaknesses

Aspect Strengths Weaknesses

Easy for everyone to Can oversimplify complex

Communication
understand systems

Users may focus only on happy

User Involvement Engages users directly
paths

Functional Excellent for capturing what Misses non-functional

Requirements system does requirements

Boundaries Shows system scope Misses what system should NO

Aspect Strengths Weaknesses

do

Misses performance, security,

Testing Provides basis for test cases
stress testing

Not sufficient alone for technic

Documentation Inputs to user manuals
specs

Example System: Student Management System

🔷 1. Identify Actors
👤 Main Actors:

 Student
 Admin
 Teacher

🔷 2. Identify Use Cases

📌 Student Use Cases:

 Register Course
 View Result
 Login

📌 Admin Use Cases:

 Manage Users
  Generate Reports
 Login

📌 Teacher Use Cases:

 Upload Marks
 View Students
 Login

🔷 3. Apply <<include>>
(Mandatory Behavior)
✅ Common Functionality:

All actors must Login

👉 So we extract it:

 Login is included in:

o Register Course
o View Result
o Manage Users
o Upload Marks

💡 Include Relationships

Register Course ─────► <<include>> ─────► Login

View Result ─────────► <<include>> ─────► Login
Manage Users ───────► <<include>> ─────► Login
Upload Marks ───────► <<include>> ─────► Login

✅ Meaning:

 Login is mandatory
 Every action requires authentication
🔷 4. Apply <<extend>> (Optional
Behavior)
✅ Optional Features:

 Forgot Password
 Send Notification
 Apply Late Registration

💡 Extend Relationships

Forgot Password ─────► <<extend>> ─────► Login

Send Notification ───► <<extend>> ─────► Upload Marks
Late Registration ──► <<extend>> ─────► Register Course

✅ Meaning:

 These features happen only if needed

 Not required for main flow

🔷 5. Add Generalization (Actors)

User
/ | \
Student Teacher Admin

✅ Meaning:

 All actors inherit from User

 Share common behaviors (like Login)
🔷 6. Full Combined Diagram
(Conceptual View)
Actors:
Student ───────┐
Teacher ───────┼──► System
Admin ─────────┘

Use Cases:
Register Course ──► <<include>> Login
View Result ──────► <<include>> Login
Upload Marks ─────► <<include>> Login
Manage Users ─────► <<include>> Login

Optional:
Forgot Password ─► <<extend>> Login
Send Notification ─► <<extend>> Upload Marks
Late Registration ─► <<extend>> Register Course

🔷 7. Step-by-Step Explanation
(Very Important for Exams)
🧠 How we built this:

Step 1: Identify Actors

Ask:

Who interacts with the system?

✔ Student
✔ Teacher
✔ Admin
Step 2: Identify Use Cases

Ask:

What does each actor do?

✔ Register Course
✔ Upload Marks
✔ Manage Users

Step 3: Find Common Behavior

Ask:

What is repeated?

✔ Login → used everywhere → <<include>>

Step 4: Find Optional Behavior

Ask:

What is conditional?

✔ Forgot Password
✔ Notifications

→ <<extend>>

Step 5: Add Structure

✔ Generalization (User → Actors)

✔ Relationships (include & extend)

🔷 8. Final Key Understanding

✔ <<include>>

 Mandatory
 Reusable
 Always executed

👉 Example: Login

✔ <<extend>>

 Optional
 Conditional
 Adds extra behavior

👉 Example: Forgot Password

🎯 Bonus (Exam-Ready Definition)

📌 <<include>>

A relationship where a use case always includes another use

case as part of its execution to reuse common functionality.

📌 <<extend>>

A relationship where a use case optionally extends another use

case under specific conditions using extension points.

👉 Is it ALWAYS required?

✔ Yes → <<include>>

👉 Is it OPTIONAL / conditional?

✔ Yes → <<extend>>