Introduction
IT organizations continually struggle to assure that developed
software meets its specified requirements. But how can these
requirements be discovered, captured, and communicated most
effectively? With the advent of use cases six years ago, a solution
seemed close at hand. Although use cases have been assimilated into
the authoritative Unified Modeling Language (UML), many
organizations are finding that their promise is elusive. While use
cases were intended to be simple and straightforward, many IT
organizations are finding that identifying and gathering project
requirements through use cases is painful, that they are difficult
to manage, and difficult to understand.
In this paper I want to share a small
set of common characteristics shared by projects which successfully
employ use cases. These characteristics are a brief preview of the
presentations which I will be making with Bill Nazzaro of MCI
Systemhouse at the Software Development '99 conference in San
Francisco on May 12th. These ideas come from our combined
experiences, and this paper is a collaborative effort by Bill and
me. We assume that you have a basic knowledge of what a use case is
supposed to be, and hopefully you have written—or have tried to
write—a few.
According to Rational™
Software
Corporation, a use case "defines a sequence of actions
performed by a system that yields an observable result of value to
an actor
." This is a good starting point. First, it says
that an actor—a user of the system—is the judge and motivator of
the value the system provides.
Second, it says that the system provides value to an actor in a
sequence of actions, i.e. in a transactional metaphor. Actor
requests, and system responds. Or, system requests and actor
responds. A use case is not terribly useful when there is no dialog
between the actor and the system.
Lastly, the value of the use case is observable because a use
case has a result—a goal
. It might be a goal of the
corporation, or of the business model being described, or a goal of
the actor who just needs to get some work done. Unfortunately, very
little is written on the goal-oriented aspects of use cases, and
this will be a topic of a later paper.
Killing A Project With Use Cases
There are many ways to help kill a project with use cases. A few
that we will mention without much comment now are:
- Expecting use cases to capture all your requirements.
(They don't; they just capture functional requirements and
enforce business rules.) - Emphasizing notation over business goals and content.
(The use case diagram is like a Table of Contents; it is not the
book itself.) - Designing inside use cases.
(Use cases are not part of the design process and should not
discuss technology issues; use cases are a way to capture the
requirements so you can then do analysis and design.) - Coding from Use Cases.
(They are not part of the design process; they are a way to
capture the requirements so you can do analysis and design and thenimplementation.)
- Trying to use all the defined notations just because they are
defined.
(Just because UML 1.3 introduces generalization between use
cases, are you going to look for ways to use it?) - Identifying system functions as use cases.
(Yes, system functions e.g., validateAccount, are important; but
a use case describes a business process and business goal, and
the system functions which will be used to achieve that goal
will be determined in design, not requirements capture.)
If you have been involved with use cases on a project of any size
at all, you may have experienced some of these symptoms. But we want
to be more upbeat and take a positive approach. So let's talk about
what you can do right
to raise your chances of success with
use cases.
The Right Stuff
To capture requirements successfully with use cases, you must not
confuse use cases with code, or design, or any other part of the
software development lifecycle. My most recent visit to Rational's
UML Caf?(http://cafe.rational.com/HyperNews/get/hn/umlcafe.html),
amazed me a how many persons fall into this confusion. To succeed
with use cases we have found that how you think
about the
process of capturing requirements is even more important than what
you do
in that process.
Staff For Skillsets, Not Job
Positions
You need people who have the right skillsets, not just people who
are "available". To do use cases successfully you need:
- Subject Matter Experts (SMEs), and
- Analysts.
The SMEs are resources who provide raw material for the business
content of the use case description. They are the ones who
absolutely should understand the business as-is
, but much
more importantly, are willing to define the system to-be
.
The analysts facilitate the use case development and mentor the
SMEs, but it is the analysts who analyze and write the use
cases—period. The analysts must be able to think abstractly and
have a high tolerance for incompleteness. The analysts need to
thoroughly understand the process and goals of use case development.
They also must be comfortable with intentionally circumventing the
process so they can achieve the goal of developing use cases.
Don't Let Developers Write Use
Cases!
Now that we have your attention, let me explain. By
"developer" we mean that person who is a linear
thinker: one who starts at point A, and proceeds one by one through
intermediate steps to arrive at point Z. The linear thinker cannot
comfortably jump around within the use case description process.
Some persons are linear thinkers by nature—they were born with
this skill—and some by nurture—they have been trained this way.
Some persons adopt a strongly linear approach to solving a problem
if they are uncomfortable with the solution process, so they fall
into doing the rote mechanics. Some don't understand the goal to be
achieved—i.e., they do not have a vision of the end result—and
become retentive about rigidly following a prescribed set of steps
because they mistake making the journey for reaching the goal.
However they come to this unique skill, linear thinkers are
invariably uncomfortable when there are holes in what they are
doing.
Use cases are text: i.e., prose. They are not derived like
theorems—they are composed. This is why linear thinking is a
decided liability in use case development. Writing a use case has
nothing in common with writing code or writing a Fault Isolation
manual for a Field Engineer. A use case is closer in style to
writing a short story than writing a technical specification, and
for this reason linear thinking developers will not be successful at
writing them. Use cases often grow in fits and starts, almost
organically until they express their goal. They are not technical
documents, so don't let your technical people be the ones to write
them. Various instances of "The World's Worst Use Case"
float around the OO community: some of them are textual flowcharts,
some are pseudo-code replete with IF…ENDIF statements. This is not
how to succeed with use cases.
Now, realistically, some very technical people are also very good
at written expression, and some business people cannot speak in
complete sentences. To succeed with use cases they must be written
well, by people who have the skills to accurately express the
interplay between the system and its actors.
Bill and I have spent a lot of time pulling groups out of
quagmires of use cases written by people who cannot write a simple
narrative describing "What I Did on my Summer Vacation
".
They were, however, very competent and skilled in other areas. The
problem is that they were assigned to write use cases and this was not
one of their areas of expertise.
One of the best use case writers I have found is a woman who was
a banker. She was very business savvy, and not at all technical. We
spent three 2-hour sessions together developing some use cases for
an electronic commerce system. At the end of these sessions the
light came on for her, and she became a true-believer. She applied
her new knowledge with her excellent writing skills and immediately
produced a complete set of use case requirements for a new system.
They were wonderful: not one word of technology, just clearly
articulated business process.
In use case development our total focus is on what
work
the system must do for the user, not how
the work will be
done. Bill and I were involved in a project where part of a use case
involved producing a Bill of Materials for a transportation system.
A developer (actually a pretty decent C++ coder) spent a significant
amount of energy trying to interject into the discussion that
whether the Bill of Materials was electronic or hardcopy entailed
separate use case descriptions. He just could not rise to a higher
level of abstraction and see that the important system service was
that a Bill of Materials (a concept, not implementation) be
produced, and that its manifestation as a view on a window or as a
printed report was not at all significant in the conceptual modeling
of a use case.
Bill uses a wonderful analogy to capture this cognitive opaqeness.
Have you seen the stereograms that are sometimes called "Hidden
Pictures"? Until you know how to view them they look like
random jumbles of color-dots. When you can let your eyes drift just
the right amount, however, a 3-dimensional picture suddenly leaps
into your perception. But some people just cannot see the hidden
picture. No matter how long someone tells them the secret, they just
can't see it, and some never will. That's just the way it is with
linear thinkers: some will just never be able to think abstractly,
and will never be able to produce useful
use cases.
The bottom line: choose your use case writers very, very wisely.
They are not technical documents, so why would you have technical
thinkers doing them?
Think High-Level
…
Business
Level
Bad use cases describe isolated system functions that seem useful
from a technical perspective. A good use case represents an
identifiable business
transaction that has business
value from the end-user’s
perspective. In other words, a
use case must provide a meaningful result of measurable value to the
end-user. Use cases that only deal with a low-level, elementary
process (e.g., Retrieve Reservation
or Update Reservation
)
are likely to be too simple, and are invariably modeled on the
technical CRUD- functions of a relational database management
system: C
reate, R
etrieve, U
pdate and D
elete.
Typically a use case will include the series of steps the actor must
go through and require significant business policies and rules to
implement. But a good use case does not itself describe design,
performance, or implementation issues. A good use case does not
describe the relationships between subsystems. A good use case does
describe how the system to-be carries out the work that the actor
needs done to accomplish his/her business goals.
A use case "Manage Reservation
" would include
the following: entering the reservation details, locating the
customer (establishing the customer if necessary), determining
applicable discounts, calculating the bedroom rate, and storing
reservation details. The use case "Manage Reservation
"
could also include updating the reservation, as well as canceling
the reservation.
Follow a Process
—
Loosely
Use case development is not like building a model airplane: just
putting known pieces into the proper place. It is a discovery
process. It is a process of defining that which does not yet exist,
and which may not yet be understood. It is depressing to Bill and me
how often we enter an engagement and find that a project team have
read books on use cases, have selected use case description
templates, and have written perhaps dozens of use cases—yet do not
understand any of the dynamics of the process for developing the use
case descriptions. Some will have taken expensive courses on Requirements
Gathering with Use Cases
, or some similar title in which they
learn about <<include>>, <<extend>> and
generalization relationships. But they don't understand how to
"compose" a use case iteratively, in pieces, often in fits
and starts.
The basic use case description process is rather simple. For each
candidate use case in your system-to-be:
- First, articulate the goal
of the use case. - Second, produce an outline
use case description
focusing on the "Happy Path". The "happy
path" is that sequence of steps where everything works
perfectly (so we don't have to worry about exceptions and errors
yet) and the goal of the use case is achieved. - Next, construct a simple use case description framework
to think about the happy path. This framework lets us write an
accurate, but non-detailed, use case description. At this point
our description is analogous to a pen and ink drawing: it
conveys the overall form and structure of the use case but
without any "color" yet. - Fourth, flesh-out the use case description framework with more
business-process detail
for the happy path (but not
technology detail!). This is equivalent to filling-in our pen
and ink drawing with oil colors. Now our use case description
has depth and personality.
What is not
simple is that although this use case
description process is written as a time-sequence of steps, you do
not want to be linear here—especially within
steps 3 and 4.
Detail does not flow in an orderly fashion from top to bottom. This
is a dynamic detective and discovery process, and the single most
unique characteristic of developing use case descriptions is that
your approach
must be opportunistic rather than
deterministic, lateral rather than linear
. We hunt and
scrounge for any piece of relevant information and do not care
whether we find it in the "right order". A deterministic
thinker wants to build a jigsaw puzzle from top left to bottom
right. An opportunistic thinker will look for patterns and first
will put together small groups of pieces (perhaps arranged by color
or edge shape) and then will build the puzzle from these groupings
in what seems a haphazard fashion. (It is also interesting that the
opportunistic approach will complete the puzzle sooner than the
deterministic approach! We can prove this using Sorting theory.)
It is this pseudo-random, opportunistic approach that is
absolutely central to developing use cases successfully. It is a
pseudo-random approach because an experienced use case facilitator
will always have an appreciation for what remains to be done, and
knows just what he or she wants from the use case under development.
It is also an approach that drives linear thinkers over the brink,
and makes them dig in their heels, trying to bring "order"
to the process. Alas, it is this "order" which too often
results in missed and misunderstood requirements.
Conclusion
There is so much more that we could
add to this, but our goal is share a few proven ideas to help you
become more successful with use cases. And we will be adding more
ideas in the near future. The promise of use cases is real and they
can be a tremendous vehicle and catalyst for identifying and
capturing functional requirements. We will share other ideas about
this area through White Papers on my website. Personally, I really
don't like doing use cases. I prefer analysis and design activities,
with some fun coding thrown in. The problem Bill and I continually
run into, however, is that we seldom get good use cases, use cases
that we can use as a springboard into analysis and identifying the
classes in my system-to-be. So, we usually end up writing, or severely
rewriting
, the use cases on my projects. It's not a perfect
world, is it?