Transcript The Misuse of Use Cases Presented at SIGS Smalltalk ‘99

Analysis
Requirements Artifacts
Information Needed
Define
Information Representation
•
Stakeholders

Enhanced actor model
•
Business goals

Textual descriptions - must be
traced to the architecture
•
System functions

Use case hierarchy
•
Technical system requirements

Textual descriptions cross
referenced to the use cases
•
Fundamental domain concepts
and relationships

Domain class model
•
Domain algorithms

Interaction diagrams
•
Domain level state behavior

state transition diagrams
•
application behavior, look and
feel

prototypes
Analysis -2
Actors
An actor is an external entity that interacts with the system
Analysis -3
Definition
• When an actor instance uses a system, it
will perform a behaviorally related
sequence of transactions with the system.
We call such a sequence a use case.
• A use case is a specific way of using a
system
Analysis -4
Use Case Template
Use Case ID: {This should be coded to identify the owning team and the level of the use case}
Use Case Type: {Essential, Concrete, Abstract}
Use Case Name: {Short descriptive phrase}
Basic Course: {This is a complete description of the use. Each subsection is explained below.}
Actor: {Which actor from the actor model initiates this course of the use case?}
Pre-conditions: {Requirements on the state of the system prior to this use being valid.}
Description: {Numbered flow of events: 1 The user initiates an action by…
2 The system responds by...}
{In this section reference is made to sub-use cases that this use case uses.}
Relevant requirements: {Reference to other relevant requirements documents.}
Post-conditions: {This describes the state of the system following the successful completion of
this use. Affects on other systems and actors may also be described.}
Alternative Courses: {Structured like the basic course}
Rationale: {Explanation of why this requirement is present in the system. This field is typically only used
for essential use cases}
Extensions: {This section presents variations on this use case that “specializes” it. It presents those use
cases that have an extends relation with the current use case.}
Exceptions: {This section describes all error conditions that can arise in the use case.}
Concurrent Uses: {This use can occur concurrently with the uses listed in this section.}
Related Use Cases: {use cases that are either usually performed just before or after the current use.}
Analysis -5
Use Case Template
(Continued)
Decision Support
Frequency: {How often will this use of the system occur? This field is combined with the criticality field
to determine the number of tests that will be used to test the functionality. It may also be used in certain
design decisions.}
Criticality: {How necessary is this use to the successful functioning of the program from a user’s
perspective. This field is used to assist in determining the extent to which the use will be tested.}
Risk: {The project risk associated with providing this use. This is used in project planning. Often riskier
uses will be implemented early to provide sufficient recovery time.}
--------------------------------------------------------------------------------------------------------------------Modification History -- {Follow the standard corporate document versioning template}
Owner:
Initiation date:
Date last modified:
Analysis -6
Good Foundation
Analysis -7
Use Case to Test Case
Instance*1
Test case 1
Instance n
Test case n
Instance n+1
Test case n+1
Instance n+m
Test case n+m
Instance n+m+1
Test case n+m+1
Instance n+m+j
Test case n+m+j
Analysis -8
* A use case instance is often called a scenario
No Silver Bullet
• Use cases have become the standard for
documenting functional requirements,
however,
• Use cases are no more than a structured
format for gathering and expressing
requirements
• Good format is helpful but not sufficient
Analysis -9
Complete Set of Actors
Identifying a complete set of actors means I will capture
all of the user’s viewpoints
Analysis -10
Useful Use Cases
• Good use case development relies on
knowledge gained during domain analysis
• To understand a domain it is useful to to
know the actors and the major domain
activities
Analysis -11
Impossible
• Analysts can’t create correct, useful use
cases if they don’t understand the
domain.
– This is as true for the client as for the
development team
• Developers can’t implement correct use
cases correctly if they don’t understand
the domain.
Analysis -12
Parallel Levels of Abstraction
R eq u irem en ts A rtifacts
D ev elo p m en t A rtifa cts
B u sin ess requ irem en ts
d o m ain m o d els
first few lev els of use cases
interface sp ecificatio ns
app lication m o d els
level at w hich interface bindings are
introduced
architectu res
m o re d etails
d etail designs
several m ore levels of use cases
co m p lete d etailed sp ecification s
sou rce cod e
final level of use cases
Analysis -13
Fundamental Principles of
Requirements Gathering
• Requirements should be organized hierarchically
• Use cases are best developed iterativaly and
incrementally (the same way as the rest of the system
deliverables)
• Hierarchical classification of use cases need not, and
should not, be functional decomposition
• Business requirements should be kept separate from
interface specifications
• Do not directly derive your design from your use cases
Analysis -14
Requirements should be
organized hierarchically
UC 1
UC 2
UC1.1 UC1.2
UC1.1.1
UC1.3 UC1.4
UC1.1.2
UC1.1.3
UC1.10
UC1.10.1
UC 1.1.1.1 UC1.1.1.2 UC1.1.1.3 UC1.10.1.1
UC3
UC2.1 UC2.2
UC2.1.1
UC2.3 UC2.4
UC21.1.2 UC2.1.3
UC2.10
UC2.10.1
UC2.1.1.1 UC2.1.1.2 UC2.1.1.3 UC2.10.1.1
Analysis -15
Use Case Hierarchy
• Manage complexity
• Top level < 12
• No level should have more than 5 to 10
times the number of use cases than in the
previous level
• Allows for “testing” of models,
architectures, etc
• Each level should be complete
Analysis -16
Use cases are best developed
iterativaly and incrementally
• The only way to get quality is to iterate
• Requirements change while the system is
being developed
• As the development team better
understands the domain, the are better
able to review the use cases
Analysis -17
Understanding Matures
• You can’t get the use cases totally correct
at the beginning of the project
Analysis -18
Hierarchical classification of use
cases need not and should not
be functional decomposition
UC 1 - customer makes purchase
UC 1.1 - scan UPC
UC 1.2 - add tax
UC 1.3 - calculate total
UC 1.4 - accept payment
UC 1.5 - make change
Analysis -19
Each Level is Complete
1. Define course policies
1.1 Define late policy
1.2 Define category weights
Use case 1.1 is a specific, more detailed, complete use case within the
category of use cases defined by use case 1.
Analysis -20
Use Case 1
• Customer buys soda at vending machine
– customer inserts enough coins for purchase
– machine displays total deposited
– customer pushes button to indicate selection
– machine dispenses soda can to bottom tray and
change to change tray
– customer retrieves soda and change
Most OO teams incorrectly think the first level of use cases should jump
directly to interface specifications.
Analysis -21
Business requirements should
be kept separate from interface
specifications1
Analysis -22
1
This is the idea of essential use cases - see bibliography
How?
• Keep first n levels of the use case
hierarchy interface neutral
• Have a separate field in the
use case template for the
interface binding
Analysis -23
Do not directly derive your
design from your use cases
• Use cases DO describe sequences of actions that
actors follow in using the system
• Use cases must NEVER specify what steps the
system takes internally in responding to the stimulus
from an actor
Analysis -24
Interface
System
Types of Use Cases
•
•
•
•
•
Concrete use case
Abstract use case
Complete use case
Essential use case
Partial use case
• High-level use case
• System-level end-toend use case
• Functional sub-use
case
Analysis -25
Levels of Use Cases
• High Level
• Expanded (high) level
• Detail level (including exception and
alternate courses of action)
• Abstract level (for common functionality)
Analysis -26
Boiling it down
• Essential use cases
• Concrete use case
• Abstract use case
Analysis -27
Essential Use Cases
• “are uncontaminated by presumptions
about the design of an interface that is yet
to be designed”
1
1
Larry Constantine, p70
Analysis -28
Essential Use Case Template
View from 500 - 20,000 feet
• Interface neutral
• Focus on the basic course (as opposed to
alternative courses and exceptions)
• Basic course narrative is short prose
focusing on goals of the actor
• Includes a “Rationale” field - Explanation
of why this is a business requirement
Analysis -29
Knowing Why Is Important
Analysis -30
It Took Joint Stars 2 Years
Without the “WHY”
Analysis -31
Concrete Use Case
(In the Trenches)
• Interface-specific, complete end-to-end
set of interactions between an actor and
the system to accomplish an actor’s
goal
• Focus is on the details of the basic and
alternative courses of action
Analysis -32
Abstract Use Case
(Reusable Use Case)
• Sometimes called a partial use case, or
functional sub-use case
• Captures partial set of interactions that is
common across multiple concrete use
cases
• Focus is on common interface-specific
details
Analysis -33
Use Case Instance
(Scenario)
Analysis -34
Test Everything
R eq u irem en ts A rtifacts
D ev elo p m en t A rtifa cts
B u sin ess requ irem en ts
d o m ain m o d els
first few lev els of use cases
interface sp ecificatio ns
app lication m o d els
level at w hich interface bindings are
introduced
architectu res
m o re d etails
d etail designs
several m ore levels of use cases
co m p lete d etailed sp ecification s
sou rce cod e
final level of use cases
Analysis -35
Change Cases
• Change cases are use case that the
architecture must support, but that will not
be built as a part of the current project
Analysis -36
Use Cases - Summary
• Use cases are an important part of the
development process
• Most teams do not get as much value from
use cases as they should
• One can’t build good use cases without
good domain knowledge
• One size doesn’t fit all. Configure your use
case process carefully and manage it
wisely
Analysis -37
Case Study
Case of the Useless Use Cases
Analysis -38
Project X
• Over 1000 software developers assigned
to the project
• 3 continents
• near-simulations development of a
multi-level framework with numerous
applications built on the framework
Analysis -39
Consequences
• Poor quality requirements
• Poor quality designs
– “functional decomposition” in “object
clothing”
• Wasted time and effort
Analysis -40
Framework Team
Analysis -41
Send Us Your Use Cases
Analysis -42
By the Book
Analysis -43
Recycling Machine
Analysis -44
12,386 Use Cases
Analysis -45
Filed
Analysis -46
12,386 Useless Use Cases
•
•
•
•
Wrong level of abstraction
1/2 Million $$
Morale cost
Confidence in the
framework team
was eroded
Analysis -47
Really Sad Part
:-(
• Not only too detailed
• Typically full of errors
• Almost always have to be redone
Analysis -48
Continued Information
For
Articles Regarding Use Cases
and E-Mail Updates
register at
http://www.korson-mcgregor.com/usecase.htm
Analysis -49
Use Case Bibliography

Berard, Edward V. “Be Careful with Use Cases” The Object Agency, Inc. Publications On-Line,
www.toa.com/pub/html/use_case.html.

Cockburn, Alistair, “Using Goal Based Use Cases,” JOOP, The Journal of Object-Oriented
Programming, November/December 1997, p. 56-62.

Constantine, Larry, “The Case for Essential Use Cases,” Object Magazine. May 1997, p. 72, 70

D’Souza, Desmond Frances, and Alan Cameron Wills, Objects, Components, and Frameworks with
UML, The Catalysis Approach, Addison Wesley, Reading, Massachusetts, 1999.

Fowler, Martin with Kendall Scott, UML Distilled, Applying the Standard Object Modeling Language,
Addison Wesley, Reading, Massachusetts, 1997.

Jacobson, Ivar, Grady Booch and James Rumbaugh, The Unified Software Development Process,
Addison Wesley, Reading, Massachusetts, 1999.

Jacobson, Ivar, Grady Booch and James Rumbaugh, The Unified Modeling Language Reference
Manual, Addison Wesley, Reading, Massachusetts, 1999.

Jacobson, Ivar, Object Oriented Software Engineering, A Use Case Driven Approach, Addison Wesley,
Reading, Massachusetts, 1992.

Korson, Timothy D., “Constructing Useful Use Cases,” Component Strategies, March 1999, p. 27-28.

Korson, Timothy D., “Configuring A Use Case Process,” Component Strategies, September 1998, p.
20-21

Korson, Timothy D., “The Misuse of Use Cases” Object Magazine, May 1998, p. 18, 20.

Schneider, Geri and Winters, Jason P., “Applying Use Cases, A practical Guide,” AddisonAnalysis
Wesley,-50
1998.
Domain Analysis
• What is domain analysis
• Why is it important
• What is the role of domain analysis in RUP
• What are the practical issues involved
– best practices
– pitfalls
Analysis -51
Outline
• What is domain analysis
• Why is it important
• What is the role of domain analysis in RUP
• What are the practical issues involved
– best practices
– pitfalls
Analysis -52
Domain Analysis
Discover
– Domain analysis is a process whose goal is to understand
the problem domain, the context or environment in which
the problem exists. Domain models are sometimes called
business models.
– We identify concepts, relationships, behavior and
algorithms that domain experts identify as important in the
problem domain:
– We use the concepts and relationships we find in the
problem domain as the components and relationships in the
system being developed.
Analysis -53
Domain Analysis Process
• High-level software
requirements
• Domain Knowledge
Define
• Existing Domain Models
Domain
Analysis
• New Domain models
• Updated Domain Models
Analysis -54
Domain Analysis -- Steps &
Deliverables
Step
Gain initial understanding of application
requirements
Determine domain limits
Identify domain actors and their basic interactions
with domain
Determine the activities of interest within the domain
Identify key concepts in domain
Clarify meaning of domain key concepts
Determine static relationships between all key
domain objects
Record standardized dynamic behavior
Record domain algorithms
Summarize knowledge of domain
Deliverable
Initial problem statement
Domain Dimensions and Change Cases
Use Case Diagram
Domain activities (Domain-level use-cases)
List of classes
Class description cards
Domain class diagram
State transition diagrams
Sequence diagrams
Domain digest
Analysis -55
Analysis -56
The classes represent domain concepts, NOT software components!
Analysis -57
RUP Vocabulary
• Domain Analysis
• Business Analysis
• Business Engineering
Analysis -58
Outline
• What is domain analysis
• Why is it important
• What is the role of domain analysis in
RUP
• What are the practical issues involved
– best practices
– pitfalls
Analysis -59
Why is Domain Analysis Important?
• Getting the right requirements
• Getting the requirements right
• Keeping everyone on the same page
• Development of frameworks, components, and
other multi-use assets
• Because requirements change.
Analysis -60
Why is Domain Analysis Important?
Getting the Right Requirements
• Never assume the client knows and can
articulate true business needs
• Each actor has their own limited point of view
– Doctors, nurses, lab technicians, administrators
• The process of domain analysis helps the
project stakeholders to understand what they
really need.
Analysis -61
Why is Domain Analysis Important?
Getting the Requirements Right
• Developers often misunderstand written
requirements – understanding the domain models
helps them correctly read between the lines.
Case Study: SEI Lecture Series – radar signal processing
Analysis -62
Why is Domain Analysis Important?
Keeping Everyone on the Same Page
Case Study:
The use case
calls for an
accountant to
be able to print
a journal
Case Study:
NASA, Ease of
bringing new
employees up
to speed
Analysis -63
Why is Domain Analysis Important?
Development of Multi-Use Assets
• Domain analysis is concerned with “areas of
knowledge” and “families of systems.”
• This type of analysis is necessary for the
identification of multi-use assets
– Components
– Frameworks
– Patterns
Analysis -64
Why is Domain Analysis Important?
Because Requirements Change
• Because of the constant change in the
external business world, technology,
corporate priorities, business strategies, and
domain understanding - system
requirements are always changing.
.
A p p lica tio n
Analysis -65
Outline
• What is domain analysis
• Why is it important
• What is the role of domain analysis in
RUP
• What are the practical issues involved
– best practices
– pitfalls
Analysis -66
RUP Summary
Phases
Core Workflows
Inception
Elaboration
Construction
Transition
Requirements
Analysis
Design
Implementation
Test
Preliminary
iteration(s)
Itr.
#1
Itr.
#2
Itr.
#n
Itr.
#n+1
Iterations
*Figure 11.2 page 296 “The United Software Development Process, Jacobson, Booch, Rumbaugh
Itr.
#n+2
Itr.
#m
Itr.
#m+1
Analysis -67
Examining Core Workflows
Phases
Core Workflows
Inception
Elaboration
Construction
Transition
Requirements
Includes both domain analysis and use case development
Analysis
Adds detail and structure to the requirements deliverables
Unfortunately, in the original RUP
book, domain analysis is viewed as
optional.
Analysis -68
Which Comes First?
• Functional Requirements (Use cases)
• Domain Analysis
Analysis -69
Outline
• What is domain analysis
• Why is it important
• What is the role of domain analysis in
RUP
• What are the practical issues involved
– best practices
– pitfalls
Analysis -70
Best Practices
• Use the domain models to develop a
shared mental model among the team
members and external stakeholders
• Spend at most 3-4 weeks on the first cut of
the domain models
• Involve domain experts other than clients
• Have the domain models widely reviewed
Analysis -71
Pitfalls
•
•
•
•
Not doing domain analysis
Neglecting the dynamic models
Not bounding the domain correctly
Design issues creeping into the domain
models
• Analysis paralysis
• Neglecting to keep the domain models up
to date
Analysis -72
Domain Analysis Summary
• The Rational Unified Process incorrectly treats domain
analysis as optional.
• Without domain analysis, you will not get the correct
requirements, nor get the requirements correct.
• You must have the courage to formally bound the domain
• Insist that the top level use cases are complete
• Don’t let design or implementation considerations creep
into the domain model
Analysis -73