University of Science, VNU-HCM

Faculty of Information Technology

Requirement Modeling
Assoc. Prof. TRAN Minh Triet
Department of Software Engineering
Introduction to Requirement Process

Problem Space
Problem
Problem

Needs

Features The system to

be built

Software Solution Space

Requirements
Traceability

Test Procedures
Design User
Doc
2
Definitions

❖ Requirement
 A condition or capability to which the system must conform.

❖ Requirements management
 A systematic approach to:

▪ Eliciting, organizing, and documenting requirements.

▪ Establishing and maintaining agreement between
customer/user and the project team on the changing
requirements.

3
What Do Software Requirements Specify?

Inputs Outputs
System

Design Constraints
Functions
Non-Functional
Requirements
(E.g. Performance)

(E.g. Environments)

4
UML in Context of Requirement Modeling

Business Use-
case Modeling

System Use-
case Modeling

5
Use-case Modeling

6
Objectives

❖ When you complete this module, you should be able to:

 Define actor, use case, and use-case model
 List the benefits of use cases
 Explain how use cases fit into a requirements management
process and the software development lifecycle

7
Use cases involve a shift in thinking

From a focus on the function of To a focus on the value a

a system system must deliver for its
stakeholders

8
What Is Use-Case Modeling?

❖ Links stakeholder needs to software requirements.

❖ Defines clear boundaries of a system.
❖ Captures and communicates the desired behavior of the system.
❖ Identifies who or what interacts with the system.
❖ Validates/verifies requirements.
❖ Is a planning instrument.
Model

Use case 1

Actor 2
Use case 2

Use case 3
Use Case 2
Specification

9
A Use-Case Model is Mostly Text

The System

Use case 1
Use-Case-Model Survey Actor 1
- survey description
- list of all actors Actor 2
Use case 2
- list of all use cases

Use case 3

Actor 3

Use-Case 1 Spec Use-Case 2 Spec Use-Case 3 Spec

- brief description - brief description - brief description
- flow of events - flow of events - flow of events
10
Major Use-Case Modeling Elements

Actor
Someone/something outside the
system, acting in a role that
Actor interacts with the system

Use case
Use Case Represents something of value
that the system does for its actors

11
Actor

❖An actor represents a role that a human, hardware device, or another

system can play in relation to the system
❖An actor is external to the system
❖A complete set of actors describes all of the ways in which outside
users communicate with the system

Actor

12
What Is a Use Case?

Use Case Name

A use case defines a sequence of actions

performed by a system

that yields an observable result of value

to an actor.

13
Use cases contain software requirements

❖ Each use case

 Is a coherent unit of functionality provided by a system
 Describes sequences of actions that the system takes to
deliver something of value to an actor
 Models a dialog between the system and actors
 Is a complete and meaningful flow of events from the
perspective of a particular actor

14
Capture a use-case model

❖A use-case model is comprised of:

Use-case diagrams Use-case specifications

(visual representation) (text representation)

15
Use-case specification

❖A requirements document that contains

the text of a use case, including:
Use-case specification
 A description of the flow of events

describing the interaction between

actors and the system
 Other information, such as:

▪ Preconditions
▪ Postconditions
▪ Special requirements
▪ Key scenarios
▪ Subflows

16
Use-case diagram

❖Shows a set of use cases and

Use-case diagram
actors and their relationships
❖Defines clear boundaries of a The System
system
Use
Use case
case11
❖Identifies who or what interacts with Actor 1
the system Use case 2
Actor 2
❖Summarizes the behavior of the
Use case 3
system
Actor 3

17
Use cases drive software development

Use-Case Model

Realized by Verified by
Implemented
by

Design Model
Test Model

Implementation
Model 18
Benefits of use cases

❖ Give context for requirements

 Put system requirements into logical sequences

 Illustrate why the system is necessary

 Help verify that all requirements are captured

❖ Are easy to understand

 Use terminology that customers and users understand

 Tell concrete stories of system use

 Verify stakeholder understanding

 Aid team communication and understanding

❖ Facilitate agreement with customers

❖ Facilitate the creation of test cases, documentation, and design
❖ Facilitate requirements reuse

19
Who should care about use cases?

❖Analysts
❖Customers
❖Users
❖Software architects
❖Designers
❖Testers
❖Project managers
❖Documentation writers

20
Requirements management process

IBM® Rational Unified Process® (RUP®)

Find Actors Requirements Management workflow
and Use Cases

Outline
Use Cases
Detail a Use Case
21
Review

❖What is an actor?
❖What is a use case?
❖What are some of the benefits of using use cases?
❖What is a use-case model?
❖What is a use-case diagram?
❖What is a use-case specification?
❖How does use-case modeling fit into the requirements management
process?
❖How does use-case modeling fit into the software development
lifecycle?

22
Use-case Model

23
Objectives

❖When you complete this module, you should be able to:

 Describe the use-case writing process

 Find and describe actors

 Find and describe use cases

 Relate use case

24
Process of writing use cases

Find actors Registrar

Close Registration
Find use cases Brief description: This use case allows a Registrar to
close the registration process. Courses that do not have
enough students are cancelled. The Billing System is
notified for each student in each course that is not
cancelled, so the student can be billed.

Outline a Close Registration Outline

-Flow of events
use case -Step by step

Close Registration Use-Case Specification

-Detailed Flow of Events
Detail a -Special Requirements
use case -Pre/Postconditions
25
Process of writing use cases (cont.)

Find actors

Important Note:
Use case writing is an iterative process
Find use cases

Outline a
use case

Detail a
use case
26
Process of writing use cases

Find actors
 Name and briefly describe the
actors that you have found

Find use cases

Outline a
use case

Detail a
use case
27
Actors and the system boundary

❖Determine what the system boundary is

❖Everything beyond the boundary that interacts with the system is an
instance of an actor
System boundary?
Is the Accounts
Receivable System an
actor or part of the
system?

Financial
Analyst
Order Entry System ? ?
Accounts
Receivable Financial
System Analyst

28
Actors and roles

❖ An actor represents a role that a

human, hardware device, or
another system can plan in
relation to the system.

29
Find actors

❖ Who or what uses the system?

❖ Who or what gets information from this system?
❖ Who or what provides information to the system?
❖ Where in the company is the system used?
❖ Who or what supports and maintains the system?
❖ What other systems use this system?

30
Name the actor

❖ Actor names should clearly convey the

actor’s role
❖ Good actor names describe their Librarian
responsibilities

Patron Clerk

Bank
System

31
Describe the actor

Name Librarian
Brief description A person who adds a resource into a
library
Relationships with
use cases
Add Resource
Librarian

32
Review

❖How do you find actors?

33
Process of writing use cases

Find actors
 Name and briefly describe the
use cases that you found
 Create a use-case diagram
Find use cases  Assess business values and
technical risks for use cases

Outline a
use case

Detail a
use case 34
Find use cases

What goal am I trying

to achieve by using the
system?

GOAL 1

Actor GOAL 2

35
Find use cases (cont.)

❖ What are the goals of each actor?

 Why does the actor want to use the system?
 Will the actor create, store, change, remove, or read data in the
system? If so, why?
 Will the actor need to inform the system about external events
or changes?
 Will the actor need to be informed about certain occurrences in
the system?
❖ Does the system supply the business with all of the correct
behavior?

36
Is Log in a use case?

❖By UML definition, log in is not a use case, because it does not
produce results of value to an actor.
❖However, in many cases, there is a need to capture log in separately
because it:
 Captures more and more complex behaviors (security,

compliance, customer experience)

 Is included in other use cases

❖Recommendation: Make an exception and capture log in as a

separate use case.

Log in
User
37
CRUD Use Cases

❖A CRUD use case is a Create, Read, Update, or Delete use case

❖Remove CRUD use cases if they are data- management use cases
that do not provide results that are of value to actors

Create a schedule

Read a schedule • Do not confuse use

Register for
cases with functions
courses
Update a schedule • Focus on value

Delete a schedule

38
Name the use case

❖A use case name should:

 Be unique, intuitive, and self-explanatory
 Define clearly and unambiguously the observable Register for
result of value gained from the use case courses
 Be from the perspective of the actor that triggers the
use case
 Describe the behavior that the use case supports
 Start with a verb and use a simple verb-noun Select a
combination course to teach

Guideline: Conduct a survey to learn whether customers, business

representatives, analysts, and developers all understand the names and
descriptions of the use cases
39
Describe a use case (text description)

Name Register for Courses

Brief description The student selects the courses they wish to
attend to the next semester. A schedule of
primary and alternate courses is produced.

Relationships with actors

Register for courses

Student

40
Checkpoints for actors

✓ Have you found all of the actors?

✓ Have you accounted for and modeled all roles in the system's
environment?
✓ Is each actor involved with at least one use case?
✓ Do any actors play similar roles in relation to the system? If so,
merge them into a single actor.

41
Checkpoints for use cases

✓ The use-case model presents the behavior of the system; it is easy

to understand what the system does by reviewing the model.
✓ All use cases have been identified; the use cases collectively
account for all required behavior.
✓ The use-case model contains no superfluous behavior; all use cases
can be justified by tracing them back to a functional requirement.
✓ All CRUD use cases have been removed.

Create, Retrieve, Update, Delete

42
Checkpoints for use cases (cont.)

✓ The use cases have unique, intuitive, and explanatory names so that
they cannot be confused at a later stage. If not, change their names.
✓ Customers and users understand the names and descriptions of the
use cases.
✓ The brief description gives a true picture of the use case.
✓ Each use case is involved with at least one actor.
✓ No use cases have very similar behaviors or flows of events.

43
Use-case diagrams: communicates-association

❖ A channel of communication between an actor

and a use case
❖ A line represents a communicates-association
Actor 1

Use Case

Actor 2 Actor 3

44
Each communicates-association is a whole dialog

Student logs on to system

System approves logon
Student requests course
information

Register for
Student Courses Course
Catalog
System

System displays course list System transmits request

Student selects courses Course Catalog returns course
information
System displays approved schedule

45
Use-case diagram example

Register for Courses

Course Catalog
System
Student

Select Courses
Professor to Teach

Get Class List

for a Course

46
Review

❖How do you find use cases?

47
Relating Use-case

❖ Use cases can be related to each other.

 includes, extends, and generalization-specification

❖ We explore:
 Concepts.

 Notation.

 Practice.

48
Relating Use Cases

❖ Use cases can be organized and related to simplify their

descriptions.
❖ Three associations are:
 Includes.

 Extends.

 Generalization-specialization.

49
Includes

❖ includes: “The insertion of additional behavior into a base use case

that explicitly describes the insertion.”
 Used to factor out a shared subprocess.

Partial Use Case Diagram

Borrow Renew
Resources «in Membership

»
des
clu

clu
des

«in
»

Check
Privileges

50
Includes (continued)

❖ When a super-task use case (base use case) uses a subtask use
case (an abstract use case).
An abstract use case is a factored-out subtask that does not
stand on its own as a complete, separate process.
❖ In the use-case text, the base use case explicitly initiates the
abstract use case.
“initiates” is a verb favored by some use case writers.
Use Case: Borrow Resources
...
Step 5. Initiate use case Check Library Privileges
...

51
Includes (continued)

❖ When to use?
 When several use cases share a common subflow that can be

factored out.
 When a use case is too complex and needs factoring into

smaller, understandable chunks.

52
Extends

❖ extends: “The insertion of additional behavior into a base use case

that does not know about it.”
❖ Used to extend an existing self-complete story.

Partial Use Case Diagram

Borrow Renew
Resources Membership
«extends»

«extends»
«e
xt
en
ds
»

Return Join Library as

Resources Patron

53
Extends (continued)

❖ When a second use case extends the story of the first use case.
 “Chapter 1 followed by Chapter 2.”

❖ The two use cases are complete on their own.

❖ The first use case does not know about or refer to the second use
case.

54
Extends (continued)

❖ The second use case can extend the first at its end or at any point -
the extension point.
❖ The second use case might unconditionally extend the first or only
under some condition.
❖ In the use case text of the second, it notes (in the Cross Reference
section) that it extends the first.
▪ Use Case: Return Resources
▪ Cross-References: Extends use case Borrow Resources
▪ ...

55
Extends (continued)

❖ When to use?
 To add new possible postflows to a complete use case.

 To show a conditional or alternate subflow.

56
Generalization-Specialization

❖ “… to add a more specific use case that inherits and adds features
to (a more general use case).”

Partial Use Case Diagram

«includes» Arrange
Pay Fine
Payment

Arrange
Pay by Cash Credit

57
Generalization-Specialization (continued)

❖ Example:
▪ Use Case: Pay Fine
▪ ...
▪ Step 3. Initiate use case Arrange Payment
▪ …
▪ --------------------------------
▪ Use Case: Arrange Payment
▪ Step 1. Collect payment
▪ Step 2: Verify payment
▪ Step 3: Record payment

58
Generalization-Specialization (continued)

Use Case: Pay by Cash

Cross References: Specializes Arrange Payment
...

--------------------------------

Use Case: Arrange Credit

Cross References: Specializes Arrange Payment
...

59
Exercise 2: Finding actors and use cases

❖In this exercise, you:

 Find and describe actors and use cases
 Create a use-case diagram

60
Process of writing use cases

Find actors
Outline the flow of
events
Find use cases Capture use-case
scenarios
Collect additional
Outline a requirements
use case

Detail a
use case 61
Outline each use case

▪ An outline captures use case steps in short sentences, organized

sequentially

Use Case Name

Brief Description
Basic Flow Structure
Number 1. First step the basic
and name 2. Second step flow into
the steps 3. Third step steps
Alternative Flows
1. Alternative flow 1 Identify
2. Alternative flow 2 alternative
3. Alternative flow 3 flows

62
Why outline use cases?

DRAFT
Use-Case Size

Too Small? Too Big?

Is it more than
one use case?

? ?
Outlining helps find
alternative flows
Use Case
?

63
Flows of events (basic and alternative)

❖ A flow is a sequential set of steps

❖ One basic flow
 Successful scenario from start to finish

❖ Many alternative flows

 Regular variants

 Odd cases

 Exceptional (error) flows

64
Outline the flows of events

❖ Basic flow
 What event starts the use case?

 How does the use case end?

 How does the use case repeat some behavior?

❖ Alternative flows
 Are there optional situations in the use case?

 What odd cases might happen?

 What variants might happen?

 What may go wrong?

 What may not happen?

 What kinds of resources can be blocked?

65
Step-by-step outline: Register for Courses

Basic Flow
1. Student logs on.
2. Student chooses to create a schedule.
3. Student obtains course information.
4. Student selects courses.
5. Student submits schedule.
6. System displays completed schedule . What are other
Alternative Flows alternatives?
A1. Unidentified student.
A2. Quit.
A3. Cannot enroll.
A4. Course Catalog System unavailable.
Can we allow students to register if the Course
Catalog is unavailable?
A5. Course registration closed.

66
What is a use-case scenario?

▪ An instance of a use case

▪ An ordered set of flows from the start of a use case to one of its
end points

Flow
Scenario
Note: This diagram illustrates only some of the
possible scenarios based on the flows.
67
Why capture use-case scenarios?

❖Help you identify, in concrete terms, what a system will do when a

use case is performed
❖Make excellent test cases
❖Help with project planning
❖Useful for analysis and design

68
How to capture use-case scenarios

❖ Capture scenarios in the Use-Case Specification in their own section

❖ Give each scenario a name
❖ List the name of each flow in the scenario
 Place the flows in sequence

❖ Example:
Use Case: Register for Courses
Scenario: Quit before registering
Flows: Basic Flow, Quit

69
Outline: Register for Courses

Basic Flow of Events

1. Student logs on.
2. Student chooses to create a schedule.
3. Student obtains course information.
4. Student selects courses.
5. Student submits schedule.
6. System displays completed schedule.
Alternative Flows
A1. Unidentified student.
A2. Quit.
A3. Cannot enroll.
What are other
A4. Course Catalog System unavailable.
scenarios?
A5. Course registration closed.
…
Scenarios
1. Register for courses: Basic Flow
2. Unidentified Student: Basic Flow, Unidentified Student
3. Quit before registering: Basic Flow, Quit 70
Checkpoints for use cases

✓ Each use case is independent of the others

✓ No use cases have very similar behaviors or flows of events
✓ No part of the flow of events has already been modeled as another
use case

71
Collect additional requirements

❖Collect system requirements that cannot

be allocated to specific use cases in other Supplementary
Specification
requirements documents, such as
Supplementary Specifications

72
What Is an Activity Diagram?

❖ An activity diagram in the use-case model can be used to capture the

activities and actions performed in a use case.
❖ It is essentially a flow chart, showing flow of control from one activity or
action to another.

Flow of Events

This use case starts when the Registrar requests that the
system close registration.

1. The system checks to see if registration is in progress. If Activity 2

it is, then a message is displayed to the Registrar and the
use case terminates. The Close Registration processing
cannot be performed if registration is in progress.

2. For each course offering, the system checks if a professor

Activity 1 Activity 3
has signed up to teach the course offering and at least three
students have registered. If so, the system commits the
course offering for each schedule that contains it.

73
What Is an Activity?

❖ A specification of behavior expressed as a flow of execution via

sequencing of subordinate units.
 Subordinate units include nested activities and ultimately

individual actions.
❖ May contain boolean expression constraints when the activity is
invoked or exited

Activity 2

<<Precondition>> Activity 4
Boolean constraint

<<Postcondition>>
Activity 5 Boolean constraint

74
Example: Activity Diagram

Decision
Select Course Activity/Action
Concurrent
Threads [ delete course ]
Delete Course
[ add course ]
Synchronization
Bar (Fork)
Check Check
Guard Schedule Pre-requisites
Condition
Synchronization
[ checks completed ] [ checks failed ] Bar (Join)

Assign to Resolve Transition

Course Conflicts

Update
Schedule

75
Review

❖What is the basic flow?

❖What is an alternative flow?
❖What is a scenario?
❖Why do you capture use-case scenarios?
❖Where do you collect requirements other than use cases?

76
Exercise 3: Outlining use cases

❖In this exercise, you outline a use case

77
Process of writing use cases

Find actors
Detail the flow of
events
Find use cases Structure the flow of
events
Specify additional use
Outline a case properties
use case

Detail a
use case 78
Detail a use case

You found actors and use cases, then outlined the use cases. Next, you
add detail.

<Use-Case Name>
1. Brief Description
2. Basic Flow of Events
3. Alternative Flows
4. Subflows
5. Key Scenario
6. Preconditions Add Detail
7. Postconditions
8. Extension Points
9. Special Requirements
10. Additional Information

79
Use case style

❖Use cases are structured text

❖How you structure the text is the use case style
❖There are a number of acceptable styles
❖Choose and use only one style
 For consistency

 For readability

 For usability by the development team

❖This course uses the RUP style

80
Detail the basic flow of events
Register for Courses
Structure the 1.1 Basic Flow
flow into steps 1. Log On.
This use case starts when someone accesses the
Course Registration System and chooses to register for
courses. The system validates that the person accessing
the system is an authorized student.
Number and 2. Select “Create a Schedule ”.
title each step The system displays the functions available to the
student. The student selects “Create a Schedule ”.
3. Obtain Course Information.
The system retrieves a list of available course offerings
Describe the from the Course Catalog System and displays the list to
steps the student .The student can search the list by
department, professor, or topic to obtain the desired
course information .
4. Select Courses.
The student selects four primary course offerings and
two alternate course offerings from the list of available
offerings course offerings.
…
81
Phrasing of steps

❖ Use the active voice

 Say: “The Professor provides the grades for each student”
 Instead of: “When the Professor has provided the grades”
❖ Say what triggers the step
 Say: “The use case starts when the Professor chooses to submit
grades”
 Instead of: “The use case starts when the Professor decides to submit
grades ”.
❖ Say who is doing what (use the Actor name)
 Say: “The Student chooses …”
 Instead of: "The user chooses …"
 Say: “The System validates …”
 Instead of: "The choice is validated …"

82
Structure the use-case flows

❖ Internal organization of the use case

 Increases readability

 Makes the requirements easier to understand

❖ Document acceptable styles in the Use-Case Modeling Guidelines

83
Cross-referencing using a label

Register for Course

RUP Style

1. Student Logs On

In the Student Logs On step of the Basic Flow,

84
Review: Flows of events (basic and
alternative)

❖ One basic flow

 Happy day scenario

 Successful scenario from start to finish

❖ Many alternative flows

 Regular variants

 Odd cases

 Exceptional (error) flows

85
Detail of Alternative Flows
Alternative Flows Describe what
happens
2.8 Unidentified Student.
In the Log On step of the Basic Flow, if the system
Location
determines that the student identification information is
not valid, an error message is displayed, and the use
case ends.
2.9 Quit and Save. Condition
At any time, the system will allow the Student to quit. The
student chooses to quit and save a partial schedule
before quitting. The system saves the schedule, and the Actions
use case ends.
2.10 Waiting List
In the Select Courses step of the Basic Flow, if a course
the Student wants to take is full, the systems allows the
Resume
student to be added to a waiting list for the course. The location
use case resumes at the Select Courses step in the Basic
Flow.
86
Visualize behavior

❖ Visual modeling tools

 Activity diagrams or flow charts

 Business process models

❖ Should you illustrate behavior?

 Pro

▪ Great tool to identify alternative flows, especially for visually

oriented people
▪ Succinctly conveys information about use case flows
 Con

▪ Costly to keep diagrams and use-case specifications

synchronized

87
Subflows

❖ If flows become unwieldy, break individual sections into self-

contained subflows
❖ Subflows
 Increase clarity

 Allow internal reuse of requirements

 Always return to the line after they were called

 Are called explicitly, unlike alternative flows

Alternative
Flows Subflow
88
Example subflow

89
Preconditions

❖ Describe the state that the system must be in before the use case
can start
 Simple statements that define the state of the system, expressed

as conditions that must be true

 Should never refer to other use cases that need to be performed

prior to this use case

 Should be stated clearly and should be easily verifiable

❖ Optional: Use only if needed for clarification

❖ Example
 Register for Courses use case

 Precondition:

 The list of course offerings for the semester has been created

and is available to the Course Registration System

 Student has logged into the Course Registration System

90
Postconditions

❖ Describe the state of the system at the end of the use case
 Use when the system state is a precondition to another use

case, or when the possible use case outcomes are not obvious
to use case readers
 Should never refer to other, subsequent use cases

 Should be stated clearly and should be easily verifiable

❖ Optional: Use only if needed for clarification

❖ Example:
 Register for Courses use case
 Postcondition: At the end of this
use case either the student has been
enrolled in courses, or registering was
unsuccessful and no changes have been made to the student
schedules or course enrollments

91
Sequence use cases with pre- and
postconditions

Use case 1 Use case 2

Use cases do not interact with each other.

However, a postcondition for one use case
can be the same as the precondition for another.

92
Other use case properties

❖ Special requirements
 Related to this use case, not covered in flow of events

 Usually nonfunctional requirements, data, and business rules

❖ Extension points
 Name a set of places in the flow of events where extending

behavior can be inserted

❖ Additional information
 Any additional information required to clarify the use case

93
RUP style summary
RUP Use-Case Specification
Template
❖Basic flow
 Steps are numbered and named
 Steps do not reference alternative
flows
 Shows the main actor succeeding
in that actor’s main goal
❖Alternative flows
 Have names
 May have steps

94
Use case checkpoints

✓ The actor interactions and exchanged information is clear

✓ The communication sequence between actor and use case conforms to
the user's expectations
✓ How and when the use case's flow of events starts and ends is clear
✓ The subflow in a use case is modeled accurately
✓ The basic flow achieves an observable result for one or more actors

95
Review

❖What are the steps to detailing a use case?

❖Give a few examples of best practices in phrasing use case steps?
❖What is a subflow, and when should you use one?
❖What are pre- and postconditions, and when should you use them?

96
Guidelines for when to use Use cases

Good candidate Not a good candidate

• System with behaviors that • System with behaviors

can be captured using a that cannot be captured
sequence of actions using a sequence of
• Example: actions
Telephone switch • Example:
• System with a lot of Data-warehouse
externally observable system
behavior
• Example:
Course Registration
System

97
What is NOT a use case

❖Functional decomposition
❖User interface specification
❖System design specifications

98
Functional Decomposition

❖ Is breaking down a problem into small, isolated parts.

 The parts work together to provide the functionality of the

system.
▪ Often do not make sense in isolation.
❖ Use cases:
 Are NOT functional decomposition.

 Keep the functionality together to describe a complete use of the

system.
 Provide context.

99
Functional Decomposition: An Example

Insert Card Process Transaction

Bank
Consortium

Enter PIN Select “To” Account

Select Transfer Funds Customer Enter Amount

Select “From” Account

Select Withdraw Cash

Select Account Balance

100
Avoid Functional Decomposition

Symptoms Corrective Actions

 Very small use cases  Search for larger context
 Too many use cases “Why are you building this
 Uses cases with no result of system?”
value  Put yourself in user’s role
 Names with low-level operations
“What does the user want to
▪ “Operation” + “object”
▪ “Function” + “data”
achieve?”
▪ Example: “Insert Card” “Whose goal does this use case
 Difficulty understanding the satisfy?”
overall model “What value does this use case
add?”
“What is the story behind this use
case?”

101