Writing Good Use Cases

Slides from IBM/Rational

How to Specify Functional Requirements?

• Use both use cases and declarative statements.

– Both are necessary to understand any system of
significant complexity.
• Give preference to use cases, where
appropriate.
The system shall …

+ The system must …

The system shall ...
Use Cases Declarative Statements

? Which one to choose ?

INTRODUCTION
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

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

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

Detail a
use case
Process of writing use cases
Find actors
 Name and briefly
describe the actors
Find use cases that you have found

Outline a
use case

Detail a
use case
 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
 Actors and roles
• An actor represents a role that a human,
hardware device, or another system can play
in relation to the system.
 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?
 Name the actor
• Actor names should
clearly convey the
actor’s role Student

• Good actor names

describe their
responsibilities Registrar
Professor

Course Catalog
System
 Describe the actor
Name Student
Brief description A person who
signs up for a
course
Register for courses
Relationships with Student
use cases
 Review

• How do you find actors?

Process of writing use cases
Find actors
 Name and briefly
describe the use
Find use cases cases that you found
 Create a use-case
diagram
Outline a  Assess business
use case values and technical
risks for use cases
Detail a
use case
 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
 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
 Name the use case
• A use case name should:
– Be unique, intuitive, and self-
explanatory
– Define clearly and unambiguously Register for
the observable result of value courses
gained from the use case
– Be from the perspective of the actor
that triggers the use case Select a
– Describe the behavior that the use course to teach
case supports
– Start with a verb and use a simple
verb-noun combination

Guideline: Conduct a survey to learn whether customers, business

representatives, analysts, and developers all understand the names and
descriptions of the use cases
 Find use cases
What goal am I trying to
achieve by using the
system?

GOAL 1

Actor GOAL 2
 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?
 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.
Register for courses
Relationships with
actors Student
 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.
Do any actors play similar roles in relation to the
system? If so, merge them into a single actor.
Name Upload Additional Data
ID 11
Requirement 3.5
Number
Description Defines how the contributor and system
administrator upload additional data to already
publish entries
Primary Actor Contributor
Secondary System administrator
Actor(s)
Pre-condition A published entry already exist, user must
have contributor or system administrative
permissions
Post-condition A newly updated entry
Trigger Contributor/System Administrator selects to
add new data to existing entry
Do any actors play similar roles in relation to the
system? If so, merge them into a single actor.

Name Upload Additional Data

ID 11
Requirement 3.5
Number
Description Defines how a user uploads additional data to
already published entries.

Primary Actor User

Secondary
Actor(s)
Pre-condition A published entry already exist, user must
have contributor or system administrative
permissions
Post-condition A newly updated entry
Trigger User selects to add new data to existing entry
 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
 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.
 Use-case diagrams: communicates-
association
• A channel of communication
between an actor and a use
Actor 1 case
• A line represents a
Use Case communicates-association

Actor 2 Actor 3
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
 Use-case diagram example
Register for Courses

Request Course Course Catalog

Catalog System
Student
View Grades

Billing System
Close
Registration

Select Courses Professor

to Teach

Registrar Get Class List

for a Course Submit
Grades
Assess business value and technical
risk

• For each use case identified, get

consensus with stakeholders about its
business value and technical risk
• The business team decides what is
high-value and what is not
• The technical team decides what is
architecturally significant and what is
risky
• Hints:
– Limit time
– Use high, medium, low
 Review

• How do you find use cases?

OUTLINING USE CASES
 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
 Outline each use case
 An outline captures use case steps in short
sentences, organized sequentially
Use Case Name
Brief Description
Basic Flow
1. First step
Structure
Number 2. Second step the basic
and name 3. Third step
flow into
Alternative Flows
the steps 1. Alternative flow 1 steps
2. Alternative flow 2
3. Alternative flow 3 Identify
alternative
flows
 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
?
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
 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?
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. What are other
6. System displays completed schedule . alternatives?
Alternative Flows
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.
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.
 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
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
 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.
A4. Course Catalog System unavailable. What are other
A5. Course registration closed. scenarios?
…
Scenarios
1. Register for courses: Basic Flow
2. Unidentified Student: Basic Flow, Unidentified Student
3. Quit before registering: Basic Flow, Quit
…
 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
Collect additional requirements
• Collect system
requirements that Supplementary
Specification
cannot be allocated to
specific use cases in
other requirements
documents, such as
Supplementary
Specifications
 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?
DETAILING A USE CASE
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
 Detail a use case
You found actors and use cases, then outlined the
use cases. Next, you add detail.

<Use-Case
<Use-CaseName>
Name>
1.
1.Brief
BriefDescription
Description
2.
2.Basic
BasicFlow
Flowof
ofEvents
Events
3.
3.Alternative
AlternativeFlows
Flows
4.
4.Subflows
Subflows
5.
5.Key
KeyScenario
Scenario
6. Add Detail
6.Preconditions
Preconditions
7.
7.Postconditions
Postconditions
8.
8.Extension
ExtensionPoints
Points
9.
9.Special
SpecialRequirements
Requirements
10.
10.Additional
AdditionalInformation
Information
 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
• The examples in these slides use the RUP
style
• However, the principles generalize
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.
…
 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 …"
 Example
Name Upload Additional Data
ID 11
Requirement 3.5
Number
Description Defines how a user uploads additional data to
already published entries.

Primary Actor User

Secondary
Actor(s)
Pre-condition A published entry already exist, user must
have contributor or system administrative
permissions
Post-condition A newly updated entry
Trigger User selects to add new data to existing entry
Cross-referencing using a label
Register for Course
RUP Style

1. Student Logs On

In the Student Logs On step of the Basic Flow,

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
 Detail of 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. Condition
2.9 Quit and Save.
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 Resume
the Student wants to take is full, the systems allows the location
student to be added to a waiting list for the course. The
use case resumes at the Select Courses step in the Basic
Flow.
 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
Visualize Alternative Behavior
Trading System Quote System
Customer
 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
Example subflow
 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
 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
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.
 Sequencing with pre/post conditions

Name Upload Additional Data

ID 11
Requirement 3.5
Number
Description Defines how a user uploads additional data to
already published entries .

Primary Actor User

Secondary
Actor(s)
Pre-condition A published entry already exists, user must
have contributor or system administrative
permissions
Post-condition A newly updated entry (not a statement)
Trigger User selects to add new data to existing entry
 Sequencing with pre/post conditions

Name Upload Additional Data

ID 11
Requirement 3.5
Number
Description Defines how a user uploads additional data to
already published entries .
Primary Actor User
Secondary
Actor(s)
Pre-condition A published entry already exists, user is
logged in , and must have contributor or
system administrative permissions
Post-condition The new data is associated with the
entry.
Trigger User selects to add new data to existing entry
 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
 Business rules and other special
requirements

Guideline:
If the business rule is specific to the use case, put it in the use case.
If it is general to the application, put it in a business rules document,
Supplementary Specification, or domain model.
 RUP style summary
• Basic flow RUP Use-Case Specification
Template
– 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
 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
 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?
MANAGE THE LEVEL OF
DETAIL
 Manage the detail

Black Box White Box

• Know your audience

• Strive for black box
• Some white box text may make it easier
to understand because it makes the use
case more concrete
What guides the level of use case detail on a
project?
Fewer, better use cases Functional decomposition
What What and how

Experienced analysts Developers’ demands

Experienced architects Transition from old
Better techniques and requirements approach
methods Waterfall approaches
Training, mentoring, Low team sophistication
guidance about modeling
 Correct level of detail
• No user interface design details – focus on
information and events not formats and controls
• No architectural assumptions (requirements not
design)
– But use case steps may affect the architecture
• No internal processing unrelated to a
stakeholder requirement –focus on what
behavior to capture, not how to implement the
behavior

How much detail in a use case?

Enough to satisfy all stakeholders that their
interests (requirements) will be satisfied in the
delivered system.
Discussion: Use case example
1
Discussion: Use case example
2
Discussion: Use case example
3
 More use case checkpoints

The use case contains no embedded

architectural assumptions
The use case contains no embedded
user-interface assumptions
USE CASE WRITING TIPS
Use-case writing challenges

• How do you keep the use case flows

focused and concise?
• How do you deal with issues about the
user interface?
• What do you do in a flow when
– An actor may choose among different
options?
– An actor may repeat actions before moving
forward?
– Steps are not necessarily sequential?
• How do you handle conditional behavior
in the use case flow?
 How to keep flows focused and
concise?
• Capture common vocabulary in a
glossary
– Define terms used in the project in the
glossary, not in flows
– Help prevent misunderstandings
• Start as soon as possible
• Continue throughout the project

Glossary
 What terms need defining?

Name Upload Additional Data

ID 11
Requirement 3.5
Number
Description Defines how a user uploads additional data to
already published entries

Primary Actor User

Secondary
Actor(s)
Pre-condition A published entry already exists, user is
logged in, and must have contributor or
system administrative permissions
Post-condition A newly updated entry
Trigger User selects to add new data to existing entry
 Use the glossary effectively
Use Case Glossary
5. Enter Customer Information Customer Details
The system prompts the Customer Information that uniquely
to enter their Customer Details. identifies and provides
contact information for a
The Customer enters the Customer customer located in the
Details. U.S.A. The information
The Customer creates the account. consists of Name, two
address lines, city, state,
ZIP code, and daytime
phone number.

Implementation
Visualize the glossary with a domain model

Student 1 0..* Schedule 0..* 0..4 Course Offering

0..* 0..*

0..1 1
Part-time Student Full-time Student Professor Course
 How do you deal with the user
interface?
• Leave the user interface out of the use case
– Use cases are independent of the user interface
– Describe user interfaces with
• User-experience models or prototypes
• User interface specifications

Words to Avoid Words to Use

Click Drag Form Prompts Chooses
Open Close Drop
Button Field Drop-down Initiates Specifies
Pop-up Scroll Browse Submits Selects
Record Window Starts Displays
Informs
How do you handle actor choice in the
flow?
Register for Courses

Include one choice in the

basic flow; put other
choices in the alternative
flows.

CRUD use
cases
 How do you handle repetitive
behavior?
Register for Courses

Simple, repetitive
behavior can be
captured within
the basic flow.
 How do you handle repetitive behavior?
Basic Flow
(cont.)
1. Log On. Register for Courses
…
2. Create Schedule.
1.2. The system displays the functions available to the student. These
functions are Create A Schedule, Modify a Schedule and Delete a Schedule.
The student selects ‘Create a Schedule’.
3. Perform Subflow Select Courses
Repetitive flow of 4. Submit Schedule
events can be …
Alternative Flows
captured using a 1. Modify Schedule.
subflow. 1.1 In the Create Schedule step of the Basic Flow, if the student already has a
schedule that has been saved; the system retrieves and displays the
Student’s current schedule (e.g., the schedule for the current semester) and
allows him/her to use it as a starting point.
1.2 Perform Subflow Select Courses.
1.3 The use case resumes at the Submit Schedule step of the Basic Flow.
…
Subflows
1. Select Courses.
1.1 The system retrieves a list of available course offerings from the
Course Catalog System and displays the list to the student.
1.2 The Student selects up to 4 primary course offerings and 2 alternative
course offerings from the list of available offerings.
1.3 The student can add and delete courses as desired until choosing to
submit the schedule.
 How to handle steps that are not
sequential?
Create Requirement
Developers will assume
that steps are sequential
unless you specify
otherwise.
 How do you handle conditional?
Option 1: Use inline conditional behavior (if
statements) in the basic flow
 Pros Basic Flow Register for Courses
 Familiar to 1. Log On.
programmers …
 Easier to handle 2. Create Schedule.
The student chooses to create a schedule. The system
small variations in retrieves a list of available course offerings from the Course
flows Catalog System and displays the list to the student.
 Cons
 Can be hard to If the student has an existing schedule and chooses to
modify a schedule, the system retrieves and displays the
follow student’s current schedule (e.g., the schedule for the
 Harder to identify current semester) and allows him/her to use it as a starting
scenarios point.
 Harder to implement If the student has an existing schedule and chooses to
and test delete it, the system retrieves and displays the Student
current schedule. The system prompts the Student to verify
the deletion. The Student verifies the deletion. The system
How would you deletes the schedule.
remove the ifs? …
 How do you handle conditional
behavior?
Option 2: Use alternative flows
• Pros Basic Flow Register for Courses
– Can be used anywhere there is 1. Log On.
conditional behavior
– Clearer
…
– Easier to read 2. Create Schedule.
– Easier to define scenarios The system displays the functions available to the student. These
• Cons functions are Create A Schedule, Modify a Schedule and Delete a
– More alternative flows Schedule. The student selects ‘Create a Schedule’.
– Increased complexity in
maintaining cross-references 3. Select Courses
…
Alternative Flows
1. Modify Schedule.
In the Create Schedule step of the Basic Flow, if the student has an
existing, the system retrieves and displays the student’s current
schedule (e.g., the schedule for the current semester) and allows
him/her to use it as a starting point. The use case resumes at the
Basic Flow Select Courses.
2. Delete a Schedule
In the Create Schedule step of the Basic Flow, if the student has an
existing schedule and chooses to delete it, the system retrieves
and displays the student current schedule. . The system prompts
the Student to verify the deletion. The student verifies the
deletion. The system deletes the schedule. The use case ends
 Review

• What is the value of using a glossary?

• How do you deal with the user interface in a
use case?
• How do you deal with actor choice in a use
case flow?
• How do you handle repetitive behavior in a
use case flow?
• How do you handle steps that are not
necessarily sequential?
• How do you handle conditional behavior in a
use case flow?
 Writing Good Use Cases
summary
• An actor represents a role that a human,
hardware device, or another system can play
in relation to the system
• A use case is…
– the specification of a set of actions
– performed by a system,
– which yields an observable result that is, typically,
– of value for one or more actors or other
stakeholders of the system. (Unified Modeling
Language - UML 2.0)
• A use-case model is composed of
– Use-case diagrams (visual representation)
– Use-case specifications (text representation)
Writing Good Use Cases summary
(cont.)
Find actors Name and briefly describe the actors
you have found.

Name and briefly describe the use

cases you have found.
Find use cases Create a use-case diagram.
Assess business values and technical
risks for use cases.

Outline a Outline the flow of events.

Capture use case scenarios.
use case
Collect additional requirements.

Detail the flow of events.

Detail a Structure the flow of events.
use case Specify additional use case properties.
Writing Good Use Cases summary
(cont.)

• Requirements of a use case

– Must provide value to an actor/stakeholder
• Goal orientation
– Must be a complete narrative describing
how the value is provided
• Must have basic and alternative flows
– Must stand alone
• No sequencing of use cases
– Must not describe internal processing
unrelated to a stakeholder requirement
• Focus on what, not how
Use cases and legacy systems

• If you are maintaining or enhancing a

legacy system that is not documented
using use cases, it is still beneficial to
find actors and use cases for the legacy
system
– Provide an overview of what the system
does for its actors and stakeholders
– Help understand change impact and test
coverage
• Rather than detail all use cases, focus
on new requirements
 Additional resources

• Use and Abuse Cases, Martin Fowler, 1998

http://www.martinfowler.com/distributedComputing/abuse.pdf
• Why use cases are not functions, Kurt Bittner, 2000
http://www-128.ibm.com/developerworks/rational/library/content/Ratio
nalEdge/dec00/WhyUseCasesAreNotFunctionsDec00.pdf
• Hunting for use-case scenarios, Pan-Wei Ng, 2003
http://www-106.ibm.com/developerworks/rational/library/content/Ratio
nalEdge/oct03/m_hunting_ng.pdf
• Use Cases: Yesterday, Today, and Tomorrow, Ivar Jacobson,
2003
http://www-128.ibm.com/developerworks/rational/library/775.html
• Traceability from Use Cases to Test Cases, Peter
Zielczynski, 2006
http://www-128.ibm.com/developerworks/rational/library/04/r-3217/ind
ex.html
What About Nonfunctional Requirements?
• The “URPS” of FURPS • Design Constraints
– Usability – Operating Systems
– Reliability – Environments
– Performance – Compatibility
– Supportability
– Application
• Compliance with Legal Generality
Standards
F unctionality
Feature set
Security
and Regulatory Capabilities
Human factors Consistency
requirements U sability
Aesthetics Documentation
Frequency/Severity
– FCC of failure
Predictability
Accuracy
R eliability Recoverability MTBF
– FDA P erformance Speed Throughput
Efficiency
– DOD Resource usage
Response time

– ISO S upportability
Testability
Extensibility
Configurability
Serviceability
Adaptability Installability
Maintainability Localizability
Compatibility Robustness
 Example: Nonfunctional
Requirements

• Example:
– The system must provide price quotes
that are no more than 15 minutes
delayed.

• What are some others?

• Where should each of these be
specified?
 Specify Usability
Requirements
• Usability is the ease with which software
can be learned and operated by the
intended users.
• Usability requirements include:
– Training time requirements, measurable task
times.
– User abilities (beginner/advanced).
– Comparison to other systems that users know
and like.
– Online help systems, tool tips, documentation
needs.
– Conformity with standards.
• Examples: Windows, style guides, GUI Standards
All user documentation must conform to the
Microsoft® Manual of Style for Technical Publications.
 Specify Reliability
Requirements
• Reliability is the the ability for the
software to behave consistently in a
user-acceptable manner.
• Reliability requirements include:
– Availability (xx.xx%)
– Accuracy
– MTBF (xx hrs)
– Max. bugs per/KLOC (0-x)
Reporting of velocity for the Mars Lander must be in units of
meters per second and accurate to 1 in 1e6.
 Specify Performance
Requirements

• Performance is a measure of speed

or efficiency of the running system.
• Performance requirements include:
– Capacity - Memory
– Throughput - Degradation
modes
Processor, memory, disk, network
– Response time - Use of scarce resources
bandwidth
There must be no more than four protocol exchanges, of no greater
size than 512k bytes each, between the client and the server for
each user action.
 Specify Supportability
Requirements
• Supportability is the ability of the software to
be easily modified to accommodate
enhancements and repairs.
• Supportability requirements include:
– Languages, DBMS, tools, and so on.
– Programming standards.
– Error handling and reporting standards.
• Often difficult to specify
– If not measurable or observable, it is not a
requirement.
– Is it a design constraint?
– Is it an intent or goal?
 How to Describe Communication
Protocols

• Specify a communication protocol if

the actor is another system or
external hardware.
– The description of the use case should
state if some existing protocol is to be
used.
– If the protocol is new, it will be fully
described during object-model
development.
 Review: Refine the System
Definition
1. When are use cases used to specify
requirements?
2. When are declarative statements used?
3. What is the difference between black and
white-box use cases? Which is better? Why?
4. What are some alternatives for expressing
conditional behavior? What are the benefits
and drawbacks of each alternative?
5. When would you use a subflow?
6. How should you handle describing forms or
data types in a use case?
7. What are the benefits of using pre- and
postconditions?
EXAMPLE
Name Upload Additional Data
ID 11
Requirement 3.5
Number
Description Defines how the contributor and system
administrator upload additional data to already
publish entries
Primary Actor Contributor
Secondary System administrator
Actor(s)
Pre-condition A published entry already exist, user must
have contributor or system administrative
permissions
Post-condition A newly updated entry
Trigger Contributor/System Administrator selects to
add new data to existing entry
 Normal Scenario
1. Contributor/System Administrator logs into
the system
2. Contributor/System Administrator selects
option to upload additional data to an entry
3. Contributor/System Administrator selects on
which entry to upload additional data
4. Contributor/System Administrator revises
newly added data
5. Contributor/System Administrator saves
additional data to entry
6. Contributor/System Administrator signs out of
system
 Extensions
1.1 Contributor/System Administrator does not
have a login account:
1.1.a – Contributor/System Administrator
creates account to login into the system

3.1 Chosen entry does not exist:

3.1.a – Contributor/System Administrator
creates a new entry into system
Name Update Item
ID 11
Requirement 3.5
Number
Description A user modifies or adds attributes of an Item
that is in the System.

Primary Actor User

Secondary (none)

Actor(s)
Pre-condition The User is logged into the System and has
appropriate privilege to perform the operation,
and the Item exists in the System.
Post-condition The value(s) of the attribute(s) of the Item
have been updated.
Trigger User indicates the desire to update the Item.
 Normal Scenario
1.
2. Contributor/System Administrator selects
option to upload additional data to an entry
3. Contributor/System Administrator selects on
which entry to upload additional data
4. Contributor/System Administrator revises
newly added data
5. Contributor/System Administrator saves
additional data to entry
6. Contributor/System Administrator signs out of
system
 Normal Scenario
1. User requests initiation of update, specifying
the Item whose attributes are to be modified.
2. System displays current values of attributes
that can be modified.
3. User selects attribute to modify, enters value,
and submits update request.
4. System confirms update and displays updated
attribute.
 Extensions
1.1 Contributor/System Administrator does not
have a login account:
1.1.a – Contributor/System Administrator
creates account to login into the system

3.1 Chosen entry does not exist:

3.1.a – Contributor/System Administrator
creates a new entry into system