Week 6 Study Notes

Use Case Models & Data Flow Diagrams

Software Modeling — Use Cases (Lecture 1) | DFDs (Lecture 2)

KEY DEFINITIONS

Use Case: A description of a sequence of interactions between a system and an external actor
that results in something of value to the actor. Named using a verb + object format (e.g.
'Withdraw Cash', 'Search for an Item').

Actor: A role that a user, organisation, or external system plays with respect to the system being
built. Actors initiate or participate in use cases. They are always outside the system boundary.

System Boundary: The box in a use case diagram that separates what is inside the system (use
cases) from what is outside it (actors). Clarifies the scope of the system being designed.

Scenario: A specific path through a use case — a concrete sequence of steps describing one
particular interaction between a user and the system. A use case may have many scenarios
(normal and alternative).

Primary Scenario: The normal, expected flow of events in a use case — the 'happy path' where
everything goes as planned.

Secondary Scenario: An alternative or exception flow — a 'what-if' case that handles situations
where the normal flow cannot be completed (e.g. user cancels, data is invalid, or a dependency
fails).

<> Relationship: A use case relationship where one use case (X) always invokes another use
case (Y) as part of its own execution. Y is a mandatory sub-task of X. Notation: X --<>--> Y. Think
of it like a function call.

<> Relationship: A use case relationship where one use case (Y) is a special, more specific
version of another use case (X). Y extends X by adding extra steps in specific conditions.
Notation: Y --<>--> X.

Actor Generalisation: A relationship where one actor (e.g. 'Individual Customer') inherits all the
use cases of a more general actor (e.g. 'Customer') and may have additional ones. Shown as an
arrow from specialised to general actor.

Precondition: A condition that must be true before a use case can begin executing. Documents
the state the system must be in for the use case to start.
Postcondition: A condition that is guaranteed to be true after a use case finishes executing
successfully. Documents the resulting system state.

Use Case Verification: Checking that the use case correctly matches the user requirements —
i.e. it is correctly specified. Done through reviews.

Use Case Validation: Checking that the system built actually implements the use case correctly
— i.e. the use case is correctly implemented in working software.

Business Rule: A constraint or policy from the business domain that governs how a use case
executes. Can restrict who can perform a use case, define valid inputs, or dictate how
computations are performed.

Data Flow Diagram (DFD): A graphical model that shows how data flows through a system —
from external entities, through processes, to data stores and back. Used to model system
functionality without specifying implementation.

External Entity (DFD): A person, organisation, or system that is outside the system boundary
but sends data to or receives data from the system. Named with a noun. Equivalent to an actor in
use case diagrams.

Process (DFD): A function or activity within the system that transforms input data into output
data. Named with a verb phrase (e.g. 'Record Order', 'Calculate Payroll'). Shown as a circle or
rounded rectangle.

Data Flow (DFD): An arrow showing the movement of data between components (external
entities, processes, data stores). Named with the name of the data being transferred (e.g.
'Customer Order', 'Payment').

Data Store (DFD): A repository where data is held at rest — a database, file, or any persistent
storage. Named with a noun (e.g. 'PAYMENTS', 'INVENTORY'). Shown as an open-ended
rectangle.

Context Level DFD (Level 0 / Context Diagram): The highest-level DFD — shows the entire
system as a single process (Process 0.0), surrounded only by external entities and the data flows
between them. Defines the system boundary and its interactions with the outside world.

Level 0 DFD: The first decomposition of the context diagram. Breaks the single system process
into major sub-systems or functional areas (e.g. Sales, Production, Procurement, Payroll). Shows
data flows between sub-systems.

Level 1 DFD (and beyond): Further decomposition of each Level 0 process into detailed
sub-processes. This level also introduces data stores. Each sub-process is numbered (e.g. 1.1,
1.2, 1.3 for sub-processes of Process 1.0).

Process Decomposition: The hierarchical breakdown of a high-level process into increasingly

detailed sub-processes across DFD levels. A process at one level is expanded into multiple
processes at the next level.
PART A: USE CASE MODELS

1. WHAT IS A USE CASE?

A use case describes a sequence of interactions between a system and an external actor that
produces something of value. Use cases capture user actions and the system responses to them —
they describe software behaviour from the user's point of view.

Naming convention: always verb + object

• Check in for a Flight
• Create an Invoice
• Search for an Item
• Withdraw Cash

Two user-centric requirement techniques:

Technique Description

Use Cases Structured, diagram-based technique using UML. Formally documents sequences of interactions betw

User Stories Informal, short descriptions of features from the user's perspective. Used in Agile (XP, Scrum). Less s

Note: Both techniques focus on understanding what different types of users need to accomplish through
interactions with a software system. Use cases lead to functional requirements; user stories are directly
used in sprint planning.

2. COMPONENTS OF A USE CASE MODEL

Component Description

Use Case Specifies a complete piece of system functionality. Must always deliver some output or response to th

Actor A role that a user, organisation, or external system plays. Initiates or participates in use cases. Always

System Boundary A rectangle that separates the system (use cases inside) from the external world (actors outside). Def

Association A straight line or arrow connecting an actor to a use case. Shows which actors participate in which use

Relationship A dotted arrow between two use cases. Shows <<include>> or <<extend>> relationships.

3. SCENARIOS vs. USE CASES

A use case describes all possible interactions for a given piece of functionality. A scenario is one
specific path through that use case — a concrete example of one interaction.

A use case may have multiple scenarios:

Type Description Example

Primary scenario The normal, expected flow of events — the 'happy

User
path'.
searches
Everything
for item,
goesresults
as planned.
appear successfully.

Secondary scenario An alternative or exception flow — what happensSearch

when something
returns nogoes
results;
wrong
userorcancels
the userdeletion;
does somethin
payme

Example: 'Search' use case — primary scenario:

• Step 1: User enters keyword
• Step 2: User presses the Search button
• Step 3: System displays search results

Example: 'Delete Information' secondary scenario:

• If the information is being used by another use case, the deletion is cancelled
• The Cancel Action use case is triggered instead

4. USE CASE RELATIONSHIPS

<> Relationship
Use <> when one use case (X) always calls another use case (Y) as a mandatory sub-step during
its own execution. X cannot complete without Y. This is similar to a function calling another function.

Rules:
• The included use case (Y) is always executed when X runs — it is not optional
• X depends on the outcome of Y
• Used to extract common behaviour shared by multiple use cases
• Notation: X --<>--> Y

Example — Withdraw Cash:

• 'Withdraw Cash' <> 'Validate User Account'
• 'Withdraw Cash' <> 'Check Balance'
• Both sub-steps always happen whenever a withdrawal is attempted

<> Relationship
Use <> when one use case (Y) is a special, more specific version of another use case (X). Y adds
extra steps to X that only apply in certain conditions. Y inherits everything from X and adds more on
top.

Rules:
• Y is a conditional extension — it only applies in specific situations
• X is complete on its own — Y is not required for X to finish
• Think of it as a generalisation-specialisation relationship
• Notation: Y --<>--> X
Example — Place Phone Call:
• 'Place Conference Call' <> 'Place Phone Call'
• A conference call does everything a normal phone call does, plus sets up a multi-party
connection

Includes vs. Extends — Key Distinction

Aspect <<include>> <<extend>>

What it means X always does Y as a sub-step Y is a special case of X with extra steps

Is the relationship mandatory?

Yes — Y always runs when X runs No — X is complete without Y

Direction of arrow X --> Y (X uses Y) Y --> X (Y extends X)

Analogy A function call (always happens) A subclass (inherits + adds more)

Example 'Withdraw Cash' includes 'Validate Account''Place Conference Call' extends 'Place Phone Call'

5. ACTOR GENERALISATION

Just as use cases can be related by <>, actors can also be generalised. A specialised actor inherits
all the use cases of the general actor and may have additional ones of its own.

Example — Credit Card Validation System:

• 'Customer' can perform 'Perform Card Transaction' and 'Process Bills'
• 'Individual Customer' and 'Corporate Customer' are both specialisations of 'Customer'
• Both inherit Customer's use cases, and may have their own additional ones
• Shown as an arrow from the specialised actor pointing to the general actor

Note: This is the same concept as inheritance in object-oriented programming — the child actor inherits all
properties of the parent actor.

6. DOCUMENTING A USE CASE

A use case diagram alone is not enough. Each use case must be fully documented in a structured
template covering the following fields:

Field Description

Priority How important is this use case? (e.g. High, Medium, Low)

Actor(s) Who initiates or participates in this use case?

Summary A brief plain-English description of what the use case does and why.
Preconditions What must be true before this use case can begin?

Postconditions What is guaranteed to be true when the use case finishes successfully?

Includes / Extends Which other use cases does this one include or extend?

Normal course of events Step-by-step table of user actions and system responses in the happy path.

Alternative path What happens if the user takes a different route (e.g. cancels)?

Exception / Alert What errors or system-level problems can occur and how are they handled?

Assumptions Any assumptions made about the system state or user behaviour.

Worked Example: 'Delete Information' Use Case

Priority:
High (1)

Actor:
User

Summary:
Allows the user to permanently remove a complete set of information from the system. Deletion is
only possible when the information is not being used by any other part of the system.

Precondition:
The information has been previously saved to the system and the user needs to permanently
remove it.

Postcondition:
The information is no longer available anywhere in the system.

Includes:
Record Transaction, Cancel Action

Extends:
None

Normal course of events:

Step User Action System Response

1 User wants to delete a set of information (e.g. a user or group).

2 User selects the information to delete and instructs the system to delete it.

3 System asks the user to confirm deletion. <Cancel Action>

4 User confirms deletion. <Cancel Action>

5 System deletes the information. <Record Transaction> (Alt 1)

6 System notifies the user that deletion is complete. (Exception 1)

Alternative path:
• If the user does not confirm deletion, the information is NOT deleted
• Includes: Cancel Action
Exception:
• The system will not allow deletion of information that is currently being used by another part of
the system
Assumptions:
• Deleted information is permanently removed and not retained anywhere
• Deleting only part of a record constitutes modification, not deletion

7. HOW TO IDENTIFY USE CASES

Three practical approaches:

# Approach Description

1 Actor-first Identify all actors first. Then for each actor, ask: what tasks does this actor need to perform using th

2 Process-first Start from a description of the business process. Ask: 'What tasks must the system perform to comp

3 Event-first Identify external events the system must respond to. Then relate each event to the actor that trigger

Note: Use cases emerge through brainstorming sessions with clients and by studying domain documents.
There is no single correct set of use cases for a system — they depend on the level of detail and the scope
agreed with the client.

8. TESTING USE CASES

Type Description

Verification Checks that the use case correctly matches the user requirements — i.e. it is correctly specified. Done th

Validation Checks that the system built actually implements the use case correctly — i.e. the use case is correctly re

9. LIMITATIONS OF USE CASES

Use cases describe systems from the user's external perspective — they treat the system as a black
box. This means they have important limitations:

• Cannot describe non-functional requirements (reliability, performance, security, legal

compliance)
 • Do not document business or domain rules
• Do not document legal constraints
• Hide all internal system details from the user — developers need additional specification
• Use cases describe what the system does, not how it does it — developers still need detailed
functional specs

Because of these limitations, use cases must always be supplemented with additional
documentation: non-functional requirements, business rules, domain models, and detailed
functional specifications.

Use cases and business rules:

Business rules and use cases are tightly intertwined. Rules may restrict which actors can perform a
use case, define valid inputs, dictate computations, or impose preconditions the system must check.

Example: An airline charges a premium for preferred seats. When a passenger runs the 'Select
Seat' use case and picks a premium seat, the relevant business rule changes the airfare — this rule
is not captured in the use case itself.

PART B: DATA FLOW DIAGRAMS (DFDs)

10. WHAT IS A DATA FLOW DIAGRAM?

A Data Flow Diagram (DFD) visualises how data flows through a system — from external entities,
through processes, into data stores, and back out. DFDs model what a system does with data
without specifying how it is implemented.

The Four Components of a DFD

Component Symbol Naming Rule Description

External Entity Rectangle Noun A person, system, or organisation outside the system that pro

Process Circle / Rounded rectangle

Verb phrase or systemAname
function that transforms input data into output data. Number

Data Flow Arrow (labelled) Name of the data Shows the movement of data between components. The labe

Data Store Open-ended rectangle Noun A repository where data is stored at rest (database, file). Data

11. DFD NAMING GUIDELINES

Component Naming Rule Examples

External Entity Noun CUSTOMER, VENDOR, EMPLOYEE

Data Flow Name of the data passing Customer Order, Payment, Sales Forecast

Process Verb phrase, system name, or subsystem name

Record Order, Calculate Payroll, Serve Product

Data Store Noun (often in CAPITALS) PAYMENTS, INVENTORY, ORDER, TIME CARDS

12. KEY RULES FOR DRAWING DFDs

• Data flows must be labelled — unlabelled arrows are not valid

• Every process must have at least one input data flow and at least one output data flow
• External entities interact with processes only — they cannot interact directly with data stores
• Data stores interact with processes only — data cannot flow directly between two data stores
• Data cannot flow directly between two external entities
• Data cannot flow directly between an external entity and a data store without going through a
process
• Each process at one level must be decomposed consistently at the next level

Note: A common mistake is drawing a data flow directly from an external entity to a data store (or vice versa)
— all data must pass through a process before being stored or sent out.

13. DFD LEVELS — CREATING A DFD STEP BY STEP

DFDs are built in levels of increasing detail. You start with the big picture and progressively
decompose each process into sub-processes.

Level Description Lemonade Stand Example

Context Level The entire system shown as ONE single process (e.g.
Lemonade
'0.0 Lemonade
SystemSystem').
(0.0) receives:
Only external
Customerentities
Order,and
Time
th
(Level 0)

Level 0 DFD The single context-level process is broken into major

1.0
sub-systems
Sale, 2.0 Production,
(e.g. Sales,
3.0Production,
Procurement,
Procurement,
4.0 PayrollPa
—

Level 1 DFD Each Level 0 sub-system is broken into its individual1.0

processes.
Sale decomposes
Data stores
into:
appear
1.1 Record
at thisOrder,
level. Each
1.2 Receiv
proc

Level 2+ DFDs Further decomposition of Level 1 processes if they are

Rarely
still needed
too complex.
exceptContinue
for very until
largeeach
systems.
process is simp

14. WORKED EXAMPLE — LEMONADE STAND SYSTEM

The lemonade stand is used in the slides to demonstrate DFD construction step by step. Here is
how it breaks down:

Step 1: List of Activities

Core activities:
• Customer Order
• Serve Product
• Collect Payment
• Produce Product
• Store Product
Supporting activities:
• Order Raw Materials
• Pay for Raw Materials
• Pay for Labor

Grouped into functional areas:

Area Activities

Sales Customer Order, Serve Product, Collect Payment

Production Produce Product, Store Product

Procurement Order Raw Materials, Pay for Raw Materials

Payroll Pay for Labor

Step 2: Context Level DFD

Single process: 0.0 Lemonade System

External entities:
• CUSTOMER — sends: Customer Order; receives: Product Served, Payment
• EMPLOYEE — sends: Time Worked, Sales Forecast; receives: Pay
• VENDOR — sends: Received Goods; receives: Purchase Order, Payment

Step 3: Level 0 DFD — Four Sub-Systems

Sub-System Responsibility

1.0 Sale Handles customer interactions — receiving orders, serving product, collecting payment.

2.0 Production Manages product creation and storage — using raw materials from inventory.

3.0 Procurement Manages purchasing — generating purchase orders, receiving goods, paying vendors.

4.0 Payroll Manages employee payment — recording time worked and calculating and issuing pay.

Step 4: Level 1 DFD — Decomposing Each Sub-System

1.0 Sale decomposes into:
• 1.1 Record Order → writes to ORDER data store
 • 1.2 Receive Payment → writes to PAYMENT data store
• 1.3 Produce Sales Forecast → reads from ORDER, sends Sales Forecast

2.0 Production decomposes into:

• 2.1 Serve Product → reads from ORDER, reduces INVENTORY
• 2.2 Produce Product → reads RAW MATERIALS, adds to INVENTORY
• 2.3 Store Product → tracks quantity produced and location in INVENTORY

3.0 Procurement decomposes into:

• 3.1 Produce Purchase Order → writes to PURCHASE ORDER data store
• 3.2 Receive Items → updates RAW MATERIALS and RECEIVED ITEMS stores
• 3.3 Pay Vendor → sends Payment to VENDOR

4.0 Payroll decomposes into:

• 4.1 Record Time Worked → reads from EMPLOYEE, writes to TIME CARDS
• 4.2 Calculate Payroll → reads TIME CARDS, writes to PAYROLL store
• 4.3 Pay Employee → sends Payment, writes to PAYMENTS store

15. PROCESS DECOMPOSITION HIERARCHY

The full decomposition hierarchy for the Lemonade Stand system looks like this:

Context Level Level 0 Level 1 Sub-Processes

0.0 Lemonade System 1.0 Sale 1.1 Record Order, 1.2 Receive Payment, 1.3 Produce Sales Forecast

2.0 Production 2.1 Serve Product, 2.2 Produce Product, 2.3 Store Product

3.0 Procurement 3.1 Produce Purchase Order, 3.2 Receive Items, 3.3 Pay Vendor

4.0 Payroll 4.1 Record Time Worked, 4.2 Calculate Payroll, 4.3 Pay Employee

16. USE CASE MODELS vs. DATA FLOW DIAGRAMS

Aspect Use Case Model Data Flow Diagram

Focus User interactions with the system How data moves through the system

Perspective External (user's view — black box) Internal (how data is processed)

Main elements Actors, use cases, relationships External entities, processes, data flows, data stores

Shows What users can do with the system What the system does with data

Captures NFRs? No No
Best used for Defining scope, user requirements, functionalUnderstanding
requirements data processing, system structure

UML standard? Yes (UML diagram) No (predates UML, still widely used)

17. EXAM TIPS — COMMON QUESTIONS

What is the difference between <> and <>?

<>: X always calls Y as a mandatory sub-step. X --<>--> Y. Y is required for X to complete. <>: Y is
a special case of X with extra steps in specific conditions. Y --<>--> X. X is complete without Y. Key
memory trick: include = mandatory sub-task; extend = optional specialisation.

What is the difference between a use case and a scenario?

A use case describes all possible interactions (both normal and exceptional). A scenario is one
specific path through the use case — a concrete example of how one particular interaction plays
out. A use case has many scenarios.

What are the limitations of use cases?

Use cases cannot capture non-functional requirements, business rules, legal constraints, or internal
system behaviour. They describe the system as a black box from the user's perspective and must
be supplemented with additional documentation.

What appears at each DFD level?

Context level: one process (the whole system), external entities, and data flows only — no data
stores. Level 0: major sub-systems and data flows between them — still no data stores. Level 1:
individual processes (numbered e.g. 1.1, 1.2) AND data stores appear for the first time.

What are the DFD rules most likely to be tested?

(1) Data cannot flow directly between two external entities. (2) Data cannot flow directly between
two data stores. (3) Data cannot flow directly between an external entity and a data store — it must
pass through a process. (4) Every process must have at least one input and one output.

How do you identify use cases?

Three approaches: (1) Start with actors — ask what each actor needs to do. (2) Start with the
business process — ask what tasks the system must perform. (3) Start with events — identify
external events the system must respond to and define a use case for each.

What is actor generalisation?

A specialised actor inherits all use cases of a more general actor and may add its own. Shown as an
arrow from the specialised actor to the general actor. Example: 'Individual Customer' and 'Corporate
Customer' both inherit from 'Customer' and can perform all Customer use cases.

Week 6 Study Notes | Use Case Models & Data Flow Diagrams