Use Case Modeling

By Kurt Bittner, Ian Spence

...............................................
Publisher: Addison Wesley
Pub Date: August 20, 2002
Print ISBN-10: 0-201-70913-9
Print ISBN-13: 978-0-201-70913-1
Pages: 368

Foreword

Use cases have come a long way since I first proposed them in 1986. Their value and power were clearly revealed by Object-Oriented
programming. Use cases both contributed to and benefited from the development of the Object-Oriented paradigm. Today, knowledge
of use cases is critical to one's understanding and application of UML and other modern software processes, such as the Rational
Unified Process (RUP).
When used effectively, use cases have proven particularly valuable as part of the requirements activities of the software process. They
have vastly improved communication between development teams and stakeholders and have made the determination of requirements
far easier and more precise.
Use cases are unique in their ability to help teams understand the value the system must provide for its stakeholders. Because use cases
describe how users use the system and what the system does for those users, they provide a unique way to build consensus about what
the system must do. Building consensus is essential to a project's success: If the stakeholders cannot agree on the value the system
must deliver, it is unlikely that the project can be successful.
Because use cases help create this understanding, they naturally provide an excellent principle around which to structure project
activities. Use cases play an important role for analysts, who work with the requirements of the system; developers, who apply use
cases to design and develop the system; testers, who verify that the system delivers the value demanded by the stakeholders; technical
writers, who document how the system is used; and user-experience professionals, who help to make the system easy to use. All these
project team members must understand use cases in order to develop better solutions.
To date, there has been something missing from the literature of use-case modeling: a description of the practical, day-to-day details of
identifying and describing use cases. This book provides those details, defining the use-case model and fleshing out use-case
descriptions. It's a perfect extension and complement to my earlier works, finishing the story of how the use cases are identified and
how they evolve.
Use Case Modeling builds on the basic concepts by leveraging the practical experience that Kurt and Ian have gained through their
many years of work in various industries—working with development teams either as consultants or as team members themselves.
They have nicely distilled that experience into this very practical and insightful work. For people new to the field, this book provides
an excellent tutorial. For use-case veterans, it provides an excellent reference that can be called upon on a daily basis.
This is the very best book on use cases ever written. Read it to understand use-case ideas and to apply those ideas with common sense
based on the kind of system you are building and the maturity of your team members.
—Ivar Jacobson
July 2002

Preface Why Bother with Use Cases?

What Are "Use Cases" All About?

In a world where it seems we already have too much to do, and too many things to think about, it seems the last thing we need is
something new that we have to learn. As Eric Sevareid observed, the chief cause of problems is solutions.
But use cases do solve a problem with requirements: with strict declarative requirements it's hard to describe steps and sequences of
events. To see why, let's consider a simple example:
Example
Some requirements that must be satisfied by an automated teller system:
1. The system shall allow customers to withdraw cash from their accounts.
2. The system shall ensure that the customer's account is never overdrawn.
3. If the customer attempts to overdraw the account, the system will allow the account to be overdrawn, up to a
specified amount, for a transaction fee.
4. If the customer is using an automated teller machine (ATM) that is owned by a financial institution other than
the one to which the account belongs, an additional fee will be charged to the account.

Simple enough, you say. Or is it?

In what order should these things be done? Does it matter? If the ATM is not one that is owned by the customer's financial institution,
should the ATM usage fee be charged before or after checking for overdraft? If the customer's account balance is less than the ATM
usage fee, charging the ATM usage fee before checking for overdraft will automatically result in an overdraft charge being applied,
1
even if the customer decides to cancel the transaction. Is this the right behavior? With only declarative requirements, which is all that
many projects have, it's impossible to say.
Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful. As
simple as this sounds, this is important. When confronted only with a pile of requirements, it's often impossible to make sense of what
the authors of the requirements really wanted the system to do. In the preceding example, use cases reduce the ambiguity of the
requirements by specifying exactly when and under what conditions certain behavior occurs; as such, the sequence of the behaviors
can be regarded as a requirement. Use cases are particularly well suited to capturing these kind of requirements. Although this may
sound simple, the fact is that conventional requirement capture approaches, with their emphasis on declarative requirements and
"shall" statements, completely fail to capture the dynamics of the system's behavior. Use cases are a simple yet powerful way to
express the behavior of the system in way that all stakeholders can easily understand.
But, like anything, use cases come with their own problems, and as useful as they are, they can be misapplied. The result is something
that is as bad, if not worse, than the original problem. Therein lies the central theme of this book—how to utilize use cases effectively
without creating a greater problem than the one you started with.
WHO SHOULD BE INTERESTED IN USE CASES?
The short answer to this question is "just about everyone," or at least everyone involved in some aspect of delivering a system that
satisfies the needs of the customer. To be more specific about who should be interested in use cases, the following roles can benefit
from the use-case technique of describing system behavior:
 Customers, who need to be sure that the system that is getting built is the one that they want
 Managers, who need to have an overall understanding of what the system will do in order to effectively plan and monitor the
project
 Analysts, who need to describe and document what the system is going to do
 Developers, who need to understand what the system needs to do in order to develop it
 Testers, who need to know what the system is supposed to do so that they can verify that it does it
 Technical writers, who need to know what the system is supposed to so that they can describe it
 User-experience designers, who need to understand the users' goals and how they will use the system to achieve these goals.
 And anyone else who wants to better understand what needs to be built before it is actually constructed

2
 A Brief Introduction to Use-Case Modeling

The purpose of this chapter is to introduce use-case modeling and why you would want to use it. It provides a concise overview of the
basic concepts employed in use-case modeling, describes how these concepts are related to more traditional requirements-capture
techniques, and describes why use cases provide a superior way to capture and understand the behavior of a system. The intent is to
provide people who may be unfamiliar with use-case modeling with a brief overview of the use-case approach without getting too
embroiled in lots of detail. We will return to these concepts for a more in-depth look in Chapter 2, Fundamentals of Use-Case
Modeling.
Actors and Use Cases
The basic idea behind use-case modeling is quite simple: To get to the heart of what a system must do, you must first focus on who (or
what) will use it, or be used by it. After you do this, look at what the system must do for those users in order to do something useful.
The use-case model includes the following components:
Actors represent the people or things that interact in some way with the system; by definition, they are outside the system. We focus
on the actors to ensure that the system does something useful. Actors have a name and a short description, and they are associated with
the use cases with which they interact.
Use cases represent the things of value that the system performs for its actors. Use cases are not functions or features, and they cannot
be decomposed. Use cases have a name and a brief description. They also have detailed descriptions that are essentially stories about
how the actors use the system to do something they consider important, and what the system does to satisfy these needs.
The set of all actors and use cases describing a system are known as the system's use-case model. And that's basically it. Well, not
completely—other-wise there would not be much to fill a book. The subtleties of working with use cases come from writing the use-
case descriptions.
Use-Case Diagrams
The actors and use cases can be depicted on use-case diagrams. Actors are represented by stick people and use cases by ellipses.
Arrows (representing relationships) connect the actors and the use cases that interact. The arrowheads help to indicate the initiator of
the interaction. Figure 1-1 shows some of the actors and use cases for a very simple telephone system. The purpose of the diagram is to
summarize what the system will do. The diagram does not really describe the system—mistaking the use-case diagram for a complete
use-case model is a common error many teams make. The diagram provides a summary, but the bulk of the description is held, as text,
in documents associated with the use cases. These use-case descriptions provide the full story of what happens in the use case. So for
every use case in the use-case model, there will be a document describing how the actors and the system collaborate to fulfill the goal
represented by the use case. In this book, when we refer to a use case, we mean the totality of the use case, including its iconic
representation, its relationships, and, most importantly, its detailed description.
Figure 1-1. A simple telephone system

3
And that's about it. Use cases help us focus on what is essential and ultimately create a system that does something useful. The
description of what the system does is principally captured as text; the use-case diagram serves as an overview or a summary of the
system's behavior.
The Relationship Between Use Cases and Requirements
Use cases are primarily a way to express a system's requirements, principally its behavioral ones. To understand what this means, we
need to look at the broader context of requirements management. The purpose of requirements management is to establish and
maintain agreement with the customers and other stakeholders on what the system should do. Often this agreement is recorded as some
sort of requirements specification.
Types of Requirements
A requirement [1] describes a condition or capability to which a system must conform; it is either derived directly from stakeholder or
user needs or stated in a contract, standard, specification, or other formally imposed document. Sometimes it is useful to express
different kinds of requirements:
[1]
The Unified Modeling Language (UML), a standard for software descriptions provided by the Object Management Group (OMG—
see www.omg.org/uml), describes a requirement as "a desired feature, property, or behavior of a system."
 Needs: Things that the stakeholders believe that the system needs to do; problems that they need to have solved. Needs, while
important to understand, are so informal that we need other ways to express the requirements of the system.
 Features: Informal statements of capabilities of the system used often for marketing and product-positioning purposes, as a
shorthand for a set of behaviors of the system. Although useful when discussing the system in casual settings, features are not
very useful for defining the behavior of the system in precise enough terms to design, develop, or test the system.
The problem with features is that they are "all over the map"; they have no precise definition and/or consistent level of
abstraction. They are useful, however, as a kind of shorthand for something that the system must do. The feature list for a
particular release of one of our products included
- Discussion Groups, which allowed team members to discuss requirements and collaborate on their definition
- Multiselect Lists, which allowed users to select multiple values for the value of a requirements attribute
The main thing to note about this is that these two features are at wholly different levels of abstraction. The key thing about a
feature is that it highlights some area of the functionality of the system that is important to the users of the system at the
moment. The features for the next release of the system (the things we wanted to highlight) were completely different.
Since features cannot be used to define precisely the capabilities of a system, we need something else to capture the required
capabilities of the system. This leads us to
 Software Requirements: Individual statements of conditions and capabilities to which the system must conform.
Each software requirement is the specification of an externally observable behavior of the system; for example, inputs to the
system, outputs from the system, the functions of the system (the mapping of inputs to outputs and their various
combinations), the attributes of the system, or attributes of the system environment. The software requirements specify the
things that the software does on behalf of the user or another system. These are the detailed, unambiguous requirements that
are specific enough to direct the implementation and testing of the system.
Software requirements specifications are expressed in various ways. One of the most common is to use declarative
statements. Examples of software requirements for our simple telephone system could include the following:
- The response time between the completion of dialing and the ringing of the requested device shall be less than 0.5 seconds
in 95 percent of all cases.
- Dialing and connection errors shall be reported to the user in the main language associated with the handset's country code.
- The system shall terminate the call when either the caller or the callee hangs up.

Functional and Nonfunctional Requirements

Requirements are sometimes divided into two categories:
1. Functional requirements (things that define the required behavior of a system)
2. Nonfunctional requirements (other qualities or constraints to which the system must conform)
Functional requirements are those actions that a system must be able to perform, without taking physical constraints into consideration.
The functional requirements specify the input and output behavior of a system. Nonfunctional requirements specify the other qualities
that the system must have, such as those related to the usability, reliability, performance, and supportability of the system. [3] Many
requirements are nonfunctional and describe only attributes of the system or attributes of the system's environment.
[3]
One way of remembering these requirements categories is the FURPS+ model (see Grady, Practical Software Metrics for Project
Management and Process Improvement, 1992, Prentice Hall), using the acronym FURPS to describe the major categories of
requirements: functionality, usability, reliability, performance, and pupportability. The "+" in FURPS+ is a reminder that there are
additional requirements to consider, such as design constraint, implementation, interface, and physical requirements.
Even with the very small number of example requirements we have looked at so far we have seen examples of both functional and
nonfunctional requirements.
Functional: The system shall terminate the call when either the caller or the callee hangs up.
Nonfunctional: The response time between the completion of dialing and the ringing of the requested device shall be less than 0.5
seconds in 95 percent of all cases.
We have looked at various concepts related to capturing, documenting, and understanding the requirements of the system, and we have
examined the different levels and categories of requirements. So, let's have a look at how these concepts relate to use cases.

4
The Role of Use Cases
Use cases are a very powerful requirements-modeling technique. They provide us with a standard way of capturing, exploring, and
documenting what a system should do (the requirements of the system). So, what level of requirements detail do use cases represent?
The use cases we have seen so far appear to have names that could be applied to the features of the system. We have a use case "Place
Local Call," which sounds like a feature of the system: People can place local calls using the system. Even a cursory examination of
our simple telephone system and a selection of its features demonstrate the difference between features and use cases and the nature of
the relationship between them (Table 1-1). A number of things should be apparent here:
1. The names of use cases are active and expressed as goals of the actors: Place Local Call, Get Call History, and Retrieve
Customer Billing Information. The features are more passive and expressed as capabilities of the system: allow the placing of
local calls, provide a continuously up-to-date call history for all accounts, be available 24 hours a day, seven days a week.
2. The granularity of the features and the use cases are very different. Although the set of use cases can, on the face of it, appear
to be a reasonable set of features, the reverse is not necessarily true: Not all features would make sensible use cases.
3. As shown in the example by the "Place Long-Distance Call" use case and the "The system provides call history for all
accounts" feature, there can be many features provided by a single use case, or a feature could be provided by more than one
use case. Features are not use cases, and vice versa.
Table 1-1. Mapping Features to Use Cases
Feature Use Case Affected

People can place local calls Place Local Call

People can place long-distance calls Place Long-Distance Call

The system finds the least-expensive routing for all long distance calls Place Long-Distance Call

The system provides call history for all accounts Get Call History
Retrieve Customer Billing Information

The system is continuously available 24 hours a day, seven days a week All Use Cases

So, if use cases are not the equivalent of features, then what are they?
A feature is a kind of shorthand for a whole set of behaviors, but it doesn't describe those behaviors at all. Features may be useful
when discussing the system at a high level, as one would in marketing literature, but they are not specific enough to really understand
what the system does. That's where use cases come in—they are specific enough to allow us to understand the behavior of the system.
Whereas features represent capabilities of the system that help meet the actor's goals, use cases take a broader view by identifying the
goals themselves and how the actor interacts with the system to accomplish those goals. The description of the way in which the actors
and the system collaborate takes the form of a narrative or dialog between the parties involved. If we think about the content of this
dialog, we see that it is going to involve describing three things:
1. The events raised by the actors and the system
2. The system's response to the events (its behavior)
3. The information exchanged between the actors and the system (the system's inputs and outputs)
In other words, a use case contains the description of a set of software requirements; the software requirements are presented in the
form of a narrative rather than an itemized list (as is common when documenting software requirements in a declarative format).
A use case places the software requirements it contains into the context of a description of something that the user wants to achieve.
The context provided by the use cases has many benefits when capturing, manipulating, verifying, and managing requirements. For
this reason, use cases are our preferred mechanism for the capturing and documentation of software requirements.
Use Cases Place Software Requirements in Context
Given that the use cases themselves are containers for sets of related software requirements, how does a use-case model handle
functional and nonfunctional requirements?
Use cases easily capture sets of functional requirements; they describe the behavior of the system as it interacts with its users and other
systems to do something useful for its users. Use cases place the functional requirements into the context of a user actually doing
something useful. Use cases can also be used to capture any nonfunctional requirements that are specific to a use case. For example,
the following requirement can be attached to the Place Local Call use case:
The response time between the completion of dialing and the ringing of the requested device should be less than 0.5 seconds in 95
percent of all cases, and in no case more than 1 second.
Nonfunctional requirements are best described using declarative requirements. These are then attached or traced to the use cases to
which they apply. [4] Trying to describe nonfunctional requirements within the text of the use-case description is at best confusing; in
some instances the results may be disas-trous. Subsequent chapters deal more directly with this problem, as well as the problem of
representing detail without becoming overwhelmed by it.
[4]
For a thorough discussion of requirements-gathering techniques, including representing nonfunctional requirements and the
relationship of those requirements to use cases, see Leffingwell and Widrig, Managing Software Requirements: A Unified Approach,
1999, Addison-Wesley.

5
To sum up, all functional requirements can be captured as use cases, and many of the nonfunctional requirements can be associated
with use cases.
There are two common misconceptions related to use cases that often cause people problems when they first start to use the technique:
 Use cases are just a way of capturing the functional requirements of a system and nothing else. The nonfunctional
requirements are all captured somewhere else.
 Use cases are all that you need to capture the requirements of a system.
In fact, use cases capture a large, usually the largest, subset of the software requirements for the system. This relationship is shown in
Figure 1-3. The use-case model itself is a vehicle for organizing the software requirements in an easy-to-manage way. It allows
stakeholders, customers, users, and developers to understand the requirements and enables them to communicate about their needs in a
consistent, nonredundant way. It also allows the developers to divide the requirements-capture work among themselves and then to use
the results (primarily use cases) as input when analyzing, designing, implementing, and testing the system.
Figure 1-3. Mapping use cases to the requirement types

Use cases are very powerful because they place requirements in context by showing how the system provides value for its stakeholders
while making the requirements easier to understand. Use cases focus on the functionality of the system and require additional, more
declarative requirements statements to provide a full software requirement specification.
We always expect the use-case model to be complemented by additional requirements documentation that contains functional and
nonfunctional requirements or systemwide requirements that do not readily fit into the use-case model. These are captured in the
supplementary specifications documentation and are often referred to as Supplementary Specifications (the Supplementary
Specification is one of the standard Rational Unified Process requirements artifacts). We would be very suspicious of any project that
used only use cases to document its requirements; it would suggest to us that a large set of the requirements of the system
(predominantly the nonfunctional requirements) were missing or forgotten.
To "Use Case" or not to "Use Case"
New techniques may solve old problems, but they often bring a whole set of new problems as well. Consider the automobile—we no
longer have to worry much about feeding and cleaning up after carriage horses, but we have other things—mechanical failure, regular
tune-ups, emissions tests—to worry about. Any time you adopt some new technique or technology, you should take a little time to
consider why you are making the change to ensure that the change is worthwhile.
When Are Use Cases Useful?
Or to put it another way, "when does the use-case technique work when other techniques do not?"
Sometimes the hardest thing to visualize is how the system will work. We can have excruciatingly detailed requirements [5] and have
almost no idea of what the system is supposed to do. The use-case descriptions give us a way of visualizing how the users and the
system will interact so that everyone can see that the system will do something useful.
[5]
One system on which we worked had over 18,000 requirements. The development team was completely lost and had very little idea
of what the system really needed to do. Applying use cases helped to straighten out the mess, resulting in a system with less than 30
use cases.
Because use cases focus on ways of using the system to do useful things, it is easier to ensure that we are building the right system. We
can see how the system reacts when the user does something, or when some external event occurs, but most importantly we make sure
that the system does something of value. The problem with so many systems is that they may satisfy many or most of their stated
requirements but are still not really useful because they do not give the users what they want or need; they do not work the way that
people want or expect them to work. Use cases help by allowing us to visualize what the system does and how to use it.

6
Use Cases Provide a Conceptual Model of the System
What use cases help us with is what Donald Norman, in The Design of Everyday Things, calls the conceptual model. This is the model
that the stakeholders and users of the system have of the system itself. In other words, use cases help us form a mental model of how
the system works, at a conceptual level.
To use a system, we must have a mental model of how it works; this mental model helps us to form strategies of how we can use the
system to accomplish tasks. Without a mental model, we are unable to use the system effectively, and the simpler the mental model,
the easier the system is to use. The electronic spreadsheet metaphor is powerful because it has a simple mental model—the paper-
based spreadsheet. The word processor we are using to write this book has another simple mental model. The internal designs of
electronic spreadsheet and word processor programs are nothing like the mental model a user has for them, but the mental model is
nevertheless essential to using the programs effectively.
Use cases help us to explore, form, and refine the mental model of how the system will work. If the system is to be usable, it is
essential that it have a simple mental model that is consistently applied throughout the design. The users and the builders of the system
must share this mental model for the system to be useful. For simple systems, achieving a shared vision is not so difficult, but as the
complexity of the requirements increases, the chances of it happening naturally decrease. When written correctly, use cases can
become a catalyst for creating this shared mental model of the system.
Use Cases Describe How the System Is Used and What It Does for Its Stakeholders
Use cases are also very good at describing the interactions between the users of a system (either people or other systems) and the
system itself. They capture what a user does to initiate some behavior in the system, and, in turn, what the system does to provide the
required behavior. They clearly define the responsibilities of the system with regard to satisfying the goals of the users, and the
responsibilities of the users with regard to supporting the system. They are excellent vehicles for envisioning the system and for
coming to agreement with users and customers of the system on what the system must do. They help facilitate discussion and build
common understanding among all the stakeholders of a system. For the development team, they provide a means to better understand
the system behavior and to derive the design and other artifacts used to build the system.
Does Everything the System Does Have to Be Described in a Use Case?
Yes, and no.
In order to have a comprehensive overview of the behavior of the system, it is important that all of the use cases be identified and
briefly described. What this means in practical terms is that you must understand who or what uses the system and what they expect to
achieve by using the system. Failure to understand this will result in a system that does not meet the expectations of its stakeholders.
Use cases provide us with a simple way to capture this.
On the other hand, not every use case needs to be fully described. In some cases, a brief outline of the flow of events of the use case
will be sufficient for everyone to understand what needs to be done, and the description can stop there. In other cases, however, when
the flow of events is complex and the flow of control branches in complicated ways, a full description will be essential to both build
and test the system. So some parts of a system will be deeply described, and other parts will be described more superficially. The
balance will vary depending on how dynamic the system to be built needs to be. Where there is a lot of interaction between the system
and its actors (for example, an automatic teller machine), a detailed description will be useful, even necessary, to make sure we
understand the behavior well enough to develop and test it. In cases where the interactions are few and/or very simple, a simple
description supplemented with declarative requirements and user-interface prototypes may be sufficient. In all cases, however, we at
least identify the use cases and briefly describe them.
Because use cases are descriptions of behavior, they need to be supplemented with nonfunctional requirements in order to present a
complete picture of what the system must do. These nonfunctional requirements include system platform requirements, design
constraints, performance requirements, and other requirements that cannot be expressed as sequences of actions that the system
performs. Since these nonfunctional requirements augment or supplement the use cases, we call them supplementary requirements.
Requirements-management tools can track and trace these requirements to their related use cases, enabling us to have a complete
picture of the system.
These observations are explored in greater detail in subsequent chapters.
General Principles of Use-Case Modeling
The intent of this book is to capture and present best practices derived from day-to-day exposure to the successes and failures of many,
many project teams who have employed use cases as a way to capture requirements and understand the systems they are to build.
Some of these best practices are fundamental and underlie everything that we have to say about use cases and their application.
Use Cases Do Not Exist in Isolation
The use cases, like the system that they describe, do not exist in isolation. To assess the effectiveness and applicability of a use-case
model, we must first understand the environment in which the system will exist. To use use-case modeling techniques effectively, you
must understand the economic, technological, political, and business environment into which the system will be introduced and how
that environment will be changed by the new system. Many formal techniques can be used to develop and capture this understanding,
such as business modeling and other more general requirements-management techniques. [6] This information can be developed
alongside the use-case model itself, with the use-case model acting as a catalyst and facilitation device for its construction.
[6]
A number of these techniques are explored in Chapter 3, Establishing the Vision.
An understanding of the following factors complements and provides context for the use-case model:
 The Stakeholder Community: the set of people who are materially affected by the development of the system. The
stakeholders also expect to get some value from the system.

7
  The Users: the set of people who will use the system, playing the roles defined by the actors. The users are one particular
kind of stakeholder.
 The Customer: the ones who have commissioned the system (the folks who are paying for it). These people may have a set
of goals and interests distinctly different from those of the users of the system.
 The Various Stakeholder Requests: requests and ideas for new functionality, which will be generated throughout the life of
the system. These must be accepted and managed alongside the use-case model.
 Constraints: restrictions on the degree of freedom the developers have in providing a solution, imposed by requirements
such as the system must run on a handheld organizer. Constraints such as this will mean that it would be pointless to describe
a system that required a windowing, multitasking operating system (at least at the time of this book's writing). It is pointless
to specify a solution that cannot be built.
 The Underlying Problem to Be Solved: it is important to always bear in mind the underlying problems that the system is
intended to solve and ensure that all of the functionality provided by the system is directly contributing to the alleviation of
these problems.
 The Problem Domain: a model must also be built to capture the terminology and facts about the problem domain addressed
by the system. At the very minimum a glossary must be maintained to define the vocabulary used within the use-case
descriptions.
It is a very common mistake to build the use-case model in isolation. If the stakeholders and users are not continuously involved in the
production and validation of the model, it can quickly and easily become an expression of the assumptions and prejudices of the
development team rather than the actual requirements of the system. If the constraints implied by the technological and business
environments are ignored, then the solution described may be uneconomical or technically infeasible.
These issues, and how to handle them, are examined in Chapter 3, Establishing the Vision.
Use Cases Are a Synthetic Rather Than an Analytic Technique
The problem with requirements is that we drown in them. There are innumer-able things that the system must do, endless details that
must be attended to, and from this massive wish list it's impossible to see the real system and how it will work. We may be able to
build an infinite number of systems that would satisfy the requirements but not the people who must use the system. Requirements are
also often ambiguous and sometimes conflicting; we need a way to sort through all this.
Some people treat use cases as an analytic technique, whereby functional requirements are understood, grouped, and then decomposed
into little packages of functionality that they call a use case. This is classic analytic thinking at work: Take a big problem and break it
down into smaller problems. This works in a lot of fields such as mathematics and engineering in which the problem is well
understood but the solution is not. In developing systems, the problem is often not very well defined either. So taking an ill-defined
problem and breaking it down into smaller pieces creates problems of its own, not the least of which is that we can't really see the
original problem anymore. To build successful systems, we need a way to better understand the problem, to build up our
understanding of the problem.
The term analysis means to break something down into its constituent elements, whereas synthesis means to build something up from
its constituent parts. Use cases are fundamentally a synthetic technique, targeted at building shared understanding among the various
stakeholders. The goal of writing a use case is to ensure that everyone has the same conceptual model (or mental picture) of what the
system will do and how it will work. We build up this understanding from the raw materials of features, functional requirements,
nonfunctional requirements, user interface prototypes, domain models, and the ideas in the heads of stakeholders. If we employ use
cases in an analytic way, we lose their primary value—building shared understanding.
Rules of Thumb
Before we dive into the definitions of actors, use cases, and the other basic building blocks of a use-case model, five rules of thumb
should be borne in mind throughout the evolution of any use-case model:
1. Focus on Effective Communication. The purpose of the use-case model is to facilitate communications.
2. Pursue Simplicity. The model should be as simple and straightforward as possible.
3. Remember Your Stakeholders. The audience for the model is the entire stakeholder community.
4. Good Enough Is as Good as It Gets. There is no such thing as perfection in use-case modeling.
5. Write Things Down. You will have to write down what the system is supposed to do in detail—there is no way to avoid this.
Not only are these five rules of thumb applicable to use-case modeling, they also provide a good foundation to adopt when writing
documents about the nature and application of use cases. Their application has been fundamental in shaping the content and style of
this book.
Summary
Use cases are a simple and powerful technique for representing the behavior of a system. But for all their simplicity, they are easily
misapplied. The basic ideas are quite simple:
 Actors are people or things that interact in some way with the system; by definition, they are outside the system. Actors have
a name and a brief description.
 Use cases are stories about how the actors use the system to do something they consider important. Use cases are a technique
for primarily expressing functional requirements, but they are not functions or features, and they cannot be decomposed. Use
cases are particularly useful for describing the behavior of a system when that behavior consists of some sequence of events
triggered by actions of the user (or some entity external to the system).

8
Use cases can be depicted in diagrams, but they are principally described in text. Too much focus on the diagrams often leads people
down the path of decomposition. Remember that the use case must tell a story about how an actor achieves something significant with
the system.
Finally, remember that use cases are used to build up our understanding of what the system should do. They are not used to analyze or
break down the requirements into smaller parts; that is the job of analysis and design.
In subsequent chapters we will delve more deeply into the structure and contents of a use case, as well as discuss how use cases are
discovered and how they are used. This chapter provided a basic introduction to the question of what use cases are and why they exist.
After a little more background, we can take up the questions of how use cases are identified and described and when they are
developed.

9
 Fundamentals of Use-Case Modeling
The preceding chapter presented a brief and relatively informal picture of use-case modeling and its goals. As with many techniques,
there is a bit more to use-case modeling that needs to be understood before it can be successfully applied.
Use-case modeling is based on a formal technique. This is both a strength and a weakness. It is a strength because we can use the
underlying formalisms to improve our precision and provide additional depth and rigor to our modeling activities. It is a weakness
because it is easy to (mistakenly) assume that use-case modeling is limited to drawing diagrams and because the formality and
terminology can be confusing to people who are new to use cases. The reality is that the formalism provides a framework for the
creation of our models and the diagrams provide a nice overview of the system, but the real value of a use case is in the textual use-
case descriptions. It is in the use-case descriptions that the majority of the model's content resides, and it is in the authoring of the use-
case descriptions where most effort will be expended.
In this chapter we look at the formal definitions of the fundamental elements of the use-case model, consider the contents of the use-
case descriptions, and describe the artifacts that are required in addition to a use-case model to form a complete software requirements
specification. This chapter is structured as a reference guide to the basic components of a use-case model and provides the foundation
for the subsequent chapters in the book. If you are familiar with the basic building blocks of use-case modeling and want to start
writing your own use cases, you can skip to Chapter 3, Establishing the Vision, and come back to this chapter later.
The Use-Case Model
The use-case model is the set of all the use cases, actors, and use-case–actor associations used to describe a particular system. See
Figure 2-1. The UML (Unified Modeling Language) defines a model as
a semantically closed abstraction of a subject system
In other words, a model is a complete description of a system from a particular perspective. (Here, complete means self-contained; you
don't need any additional information to understand the model.) In software development, as in many other fields, the models are
simplifications of reality, created to enhance understanding of the system being built.
Figure 2-1. Use-case model
*
Ivar Jacobson, et al. Object Oriented Software Engineering: A Use-Case Driven Approach, 1992, ACM Press, introduced all the
fundamental concepts of use-case modeling: actors, use cases, use-case models, use-case instances and descriptions, and related
concepts. We have based our work on these original concepts, and have focused on applying these concepts rather than
introducing new concepts.

So, does the use-case model provide a complete description from a requirements perspective? No, it doesn't. To provide a complete
requirements definition, the use-case model must be complemented by other requirements models and artifacts. [1] Use cases place
requirements in context and often contain all of the functional requirements of a system. This is the relationship that drives the UML
definition of a use-case model:
[1]
These are described in the Supporting Artifacts section later.
A model that describes the functional requirements of a system or other classifier in terms of use cases [2]
[2]
Although this book focuses on using use cases to describe systems, they can be used anywhere that there is a clear boundary.
The use-case model presents a system in terms of its usage. When treated formally, the use-case model describes all the possible ways
of using the system. Use-case models can also be used less formally where the set of use cases illustrates the most significant ways of
using a system rather than all possible ways of using the system.
The Basic Building Blocks of a Use-Case Model
The basic building blocks of the use-case model are the actors, the use cases, the relationships between them, and the diagrams in
which they appear. In this section we explore these concepts in more depth.
Actors
If we refer to our simple telephone system, the subtle distinction between the roles the users can play and the users themselves will
become clear. See Figures 2-2 and 2-3.
Figure 2-2. The graphical representation of an actor

10
Figure 2-3. Human actors

In the system in Figure 2-2, we have three actors that define roles that will be adopted by the users of the system. Now obviously,
several users can play the same role; in fact, the list of people that can take on the role "Caller" or "Callee" is almost unlimited. It is
equally obvious that the same person can take on more than one role: In most cases the Customers (the people who actually pay the
bills) would be very upset if they could not also be Callers or Callees.
A list of all the actors would be a list of all the different roles that people or other systems could play while interacting with the
system. This is subtly different from a list of users, which would be a list of all the different people and other systems that are allowed
to interact with the system. Like the term user, the term actor, is often taken to imply a person, especially given its stick-person
representation, but few systems operate without interacting with other systems, and many systems interact only with other systems. In
the example of the simple telephone system, actors also define roles to be taken by other systems. See Figure 2-4.
Figure 2-4. System actors

Just like the human users of a system, these other systems are beyond the control of the system being built and they impose certain
requirements on what the system being built must do.
Now you may be thinking, "If the actors are either humans or systems why are they all represented by stick people?" The answer is
that the role defined by the actor is not restricted to being only a human or a system. In Figure 2-3, an answering machine, a fax
machine, or a computer could take the role of Callee. The telephone system will treat these in exactly the same way as it would a
human Callee, and the Caller may not even be able to tell the difference. When defining actors, it is important to capture their
characteristics and any constraints that these place on their interaction with the system rather than making assumptions about the form
that the users playing the roles will take.
Actors According to the UML
The more formal UML definition of actor is
A coherent set of roles that users of use cases play when interacting with these use cases
We prefer our more expansive, but compatible definition, as it is less self-referential, and, we hope, more approachable.
Actors in Summary
To sum up, actors:
 Can represent people or other systems
 Define the roles that users or other systems play while interacting with the system
 Are outside the system, and usually outside the control of the system
 Impose requirements on what the system being built must do
Use Cases
Several concepts in this definition in Figure 2-5 are central to a thorough understanding of use cases:
Figure 2-5. The graphical representation of a use case

A use case has a description. Use-case modeling provides much more than a simple visual representation of a system and its actors.
Like an iceberg, the true extent of the use case is not immediately apparent; the ellipse is just an iconic placeholder for a description of
how the system and its actors interact. A use case is mostly text that describes what the system does for a particular actor; the use-case
diagram can be thought of as a visual aid to comprehension but does not tell the whole story.
11
The actor uses the system. When defining and describing use cases, remember that the system provides the use case and the actor
starts the use case.
The use cases describe how the system provides value to one or more of the actors. Each use case delivers something of value to
at least one of the actors. The concepts of actor goals and the delivery of value to the actors are fundamental to the successful
discovery, definition, and application of use cases. The use cases should reflect the goals of the actors and enable, at least in part, their
achievement.
For example:
 The actors use the system only if it enables them to do something that they want to do.
 The actors perform a use case only if doing so helps them achieve one of their goals. The physical manifestation of the goal is
the value that the use case delivers to the actor.
 A concrete value can be put on the successful performance of a use case. Every use case should have an easily understandable
and clearly identifiable value.
From a well-formed set of use cases you can immediately, and intuitively, identify the benefits that the system offers its actors, why
the actors would want to use the system, and why you would want to buy or develop it.
Use Cases, According to the UML
The formal UML definition of a use case is
A description of a set of sequences of actions, including variants, that a system performs that yields an observable result of value to a
particular actor [3]
[3]
Booch, The Unified Modeling Language User Guide, 1999, Addison-Wesley, p. 468.
We prefer our less formal, and more expansive, expression—it's easier for people to understand, and therefore easier to apply. The
UML definition focuses more on the form that the story described by the use case should take than the underlying purpose of use
cases.
Too often, when presented with this kind of formal definition, people get hung up on the meaning of the specific phrases it contains,
phrases like sequences of actions. The original meaning with respect to a use case was more informal and simply referred to some
sequence of steps that occurred together or not at all. The story metaphor works better for most people; it is simpler and gets to the real
essence of the use case—providing a coherent picture of how the system is used and what it does.
The Use-Case Description Is a Kind of Story
The use-case description tells a story of how a system and its actors collaborate to achieve a specific goal. It is a step-by-step
description of a particular way of using a system. The structure of a use case is essentially narrative in nature. The story it tells is of
how the system and its actors work together to achieve something of significance to the actors involved. This collaboration takes the
form of a dialog between the system and its actors, with all the parties contributing to the completion of the use case.
Just like a story, every use case should have a clear beginning (how the actor starts the use case), middle (how the system and actors
work together), and end (how the use case is concluded). The use case starts when an actor does something, causing the system to do
something in response. This dialog continues (at least) until the system has done something useful for at least one of the actors. The
use case is not a complete description of all possible ways that some task is performed, nor does it in any way say anything about how
the system is designed or implemented. It's just a story, although sometimes a very detailed one. As the term suggests, use cases
describe typical ways (or cases) of using the system.
Each use case expresses a goal of the actors involved and describes a task that the system, with the assistance of the appropriate actors,
will perform. You can get an idea of a use case's goal simply by observing its name and associations. In the example of our simple
telephone system, the use cases clearly represent the goals of a Caller. See Figure 2-6. When treated formally, the collected set of a
system's use cases constitute all the possible ways of using the system.
Figure 2-6. The goals of the Caller

Use Cases in Summary

To sum up, use cases:
 Are started by an actor
 Are provided by the system
12
  Can involve more than one actor
 Describe how a system and its actors collaborate to fulfill at least one of the actors' goals
 Provide a coherent picture of how the system will be used and what it does
Connecting Actors and Use Cases
The system and its actors interact by sending signals or messages to one another. To indicate such interactions, we use a communicate
association between the use case where the interaction occurs and the actors involved in the interaction. See Figure 2-7. A use case has
at most one communicate association to a specific actor, and an actor has at most one communicate association to a specific use case,
no matter how many interactions there are. The complete network of such associations provides a static picture of the communication
between the system and its environment.
Figure 2-7. The graphical representations of a communicate association
*
There are other associations between actors, and between use cases, that we will discuss later in Chapter 10, Here There Be
Dragons. While getting started with use cases, the communicate association is all that we will need to be concerned about.

This view is essential to the understanding of the use-case model. To fully understand the role defined by an actor, you must know in
which use cases the actor is involved. To fully understand the scope of a use case, you must know the actors with which it
communicates. This is shown by communicate associations between the actors and the use cases.
Actors communicate with the system for many reasons, including:
 To start a use case. Use cases are always started by actors.
 To ask for some data stored in the system, which the use case then presents to the actor.
 To change the data stored in the system by means of a dialog with the system.
 To report that something special has happened in the system's surroundings that the system should be aware of.
One actor initiates a use case. However, after the use case has started, the use case can communicate with several actors. Communicate
associations are added between the use case and the supporting actors to show the actors with which the use case communicates.
The communicate association is sometimes mistakenly regarded as representing data flow. It does not. The communicate association
represents a dialog between the actor and the system, a kind of communication channel over which data flows in both directions during
the dialogue.
Use cases communicate with actors for many reasons, including:
 If something special has taken place in the system, an actor might need to be informed.
 A use case may need to ask an actor for help in making a decision needed to achieve a goal.
 A use case may delegate responsibility to an actor.
It is common, but not always true, that the use case waits for an answer when it has sent a signal to an actor. This time period may be a
microsecond, a minute, a day, a year, or any length of time. The details of the communication between the actors and the use case is
explicitly described in the use case.
In the simple phone system example, we can see quite clearly how the communication association works. When placing a local call,
the Caller communicates with the system to set up the call (by lifting the handset and dialing the number), and the system
communicates with the Callee (ringing the Callee's telephone). The communication is bidirectional, with the telephone system relaying
information back to the Caller, thereby enabling the Caller and Callee to communicate directly as soon as the call is established. See
Figure 2-8.
Figure 2-8. Communicate associations without arrowheads

13
In Figure 2-8 which actors start which use cases? From the diagram, it's not possible to say. By adding arrowheads (optional in the
UML), we add clarity to the diagram. See Figure 2-9.
Figure 2-9. Communicate associations with arrowheads

The use of the arrowheads allows us to clearly see who starts the interaction. As shown by Figures 2-8 and 2-9, the diagrams are far
more communica-tive when the arrowheads are included, especially when you consider that no meaning is attached to the positioning
of the actors on the diagram.
To sum up:
 The communicate association shows which actors are involved in which use cases.
 Arrowheads indicate which party initiates the interaction; this provides a visual indication of which actor starts the use case.
Use-Case Diagrams
The use cases, actors, and their associations can be shown on use-case diagrams, such as Figure 2-10. On this diagram, we see an actor
called "Customer" and a use case called "Get Call History." The direction of the arrow shows that the Customer initiates the
communication.
Figure 2-10. A simple use-case diagram

A use-case diagram provides a view of a use-case model. Many use-case diagrams can be used to view and provide different
perspectives on a single use-case model. A use-case diagram may contain only actors, only use cases, or any combination of the two.
Commonly used use-case diagrams include the following:
 An overview diagram showing all the use cases and actors
 Actor summary diagrams showing a set of conceptually related actors
 Actor perspective diagrams showing all the use cases involving an actor
 Use-case summary diagrams showing a set of conceptually related use cases
 Use-case perspective diagrams illustrating how a use case relates to its actors and other user cases
The diagrams are used to convey who the actors are, what the use cases are, and how they are related. The diagrams are just views into
the underlying use-case model; they should not be confused with the use-case model itself.
Brief Descriptions
Each actor and each use case must have a brief description, no more than a few sentences long, that states what it is and why it exists.
For example, our simple phone system model generates the following descriptions:
A Caller is any person or external device that uses the system to make a phone call.
A Customer is the person, or authorized representative of the organization, that pays the bills. The Customer is the owner
of the account with the telecom's provider. The Customer is identified by an account number.
The use case Get Call History provides the Customer with the ability to access the details of all of the calls that have
been charged to the account. This call history is made available in both text and audio formats.

The purpose of these brief descriptions is to make sure we know what we are talking about, or more important, to make sure that we
all agree on the purpose of and the value provided by the use cases. Without a brief description of the actors, we may think we agree
on who or what the actors represent when in fact we may have slightly different conceptions. Without a brief description of the use
cases, we may not agree on the purpose of the use case, or worse yet, we may think we agree when we do not. In many senses, the
diagrams alone are incomplete. Without more explanation, they are ambiguous at best. This is never truer than when a team spends
14
several hours filling white boards and flip charts with use-case diagrams of actors and use cases, forgetting to record the brief
descriptions that flow naturally during the brainstorming process. Days later, the diagrams can become a source of confusion if no one
remembers whether the use case "Manage Orders" includes order fulfillment or not. Recording brief descriptions prevents this.
The brief descriptions should be at least a sentence or two long, but no more than a short paragraph; anything longer is probably
overkill. Keep the descriptions simple and direct. If you cannot come up with a simple and direct description of the actor or use case,
then you should reconsider whether you need it—if you can't define it you may not have a clear idea of what you are trying to achieve.
This is always a good first sanity check of the actors and use cases chosen by the modelers. There's a different vehicle for the more
complete description—the use-case description itself.
Use-Case Descriptions
Use cases are much more than just a named ellipse and a brief description. For each use case there will also be a use-case description
where the full story of the use case is told.
The use-case descriptions provide the substance of the use-case model, and they are the basis for most of the use-case modeling work.
The graphical representations we have seen so far are useful in positioning and scoping the system to be built, but they only provide a
very general overview of what it will do—they represent merely the tip of the use-case modeling iceberg. More than 90% of the use-
case model lies beneath the surface, in the textual use-case descriptions themselves.
Ever since Ivar Jacobson first popularized use cases, [4] the industry has seen many different approaches to the writing of use case
descriptions. Each approach recommends a different writing style and level of detail and content. Alistair Cockburn has described 18
different styles of use-case description that he has seen in use on projects. [5] One of these styles is the one proposed by Jacobson in his
book and subsequently adopted by the Rational Unified Process. We have found it to be the most effective, and so it is the one we
present here.
[4]
See Jacobson, et al., Object-Oriented Software Engineering: A Use-Case Driven Approach, 1992, ACM Press.
[5]
See A. Cockburn, "Goals and Use Cases," Journal of Object-Oriented Programming, 10(5), Sept., 1997.
The use-case description is where the details of the use case, sometimes referred to as the use-case properties, are defined. The UML
defines many properties for a use case. Here we concentrate on the key properties of the use case: the flow of events, preconditions,
and postconditions. It is important that you have an understanding of the principles behind these key use-case properties before you
start attempting to identify your system's use cases. This will help you to find an appropriate set of use cases for your system. We
explore the full set of use-case properties in Chapter 7, The Structure and Contents of a Use Case.
The Flow of Events
The most important part of the use-case description is the Flow of Events. This is the section where the story is told. Although the flow
of events is only considered a single use-case property by the UML, it has a well-defined and significant structure.
The Flow of Events as a Map ff the Territory
The flow of events provides the description of how the system and actors collaborate to deliver the value promised by the use case,
including all the things that can prevent the value from being achieved. It acts as a map of the territory for people interested in what the
system will do. Unlike a pictorial map, or flowchart, it does not merge all of the paths together into a single picture. The storylike
nature of the use case leads to a much more narrative format where the normal route is described first, followed by a description of
alternative routes. The use-case descriptions focus on describing each path individually as a unique flow of events.
The approach taken is the one that people use when providing directions to others:
Instructions to Get to Kurt's Party
Turn right out of the car park. Carry straight on down the main road for five miles until you reach the crossroads. Take the
first right and then the second left. The house is the third on the left. Don't forget to bring something to drink.
If the main road is busy, you can turn off by the pub and follow the winding country lane, but normally this will take a lot
longer.
If you need to get some alcohol on the way, there is a wine shop in the shopping center opposite the pub. If the wine shop
is shut then the pub will do carry outs. If you can't get any alcohol at all then just come anyway.

First the expected, successful route is described, followed by the alternative routes and variations on the normal route. This is exactly
the way that use-case descriptions are structured. There is a bit more formality in the way that the text is formatted and the actor and
system interactions are described, but the basic principle is the same. First the expected flow of events is described, and then the
alternatives and exceptions are detailed. The normal, expected route is called the basic flow. All the other routes, regardless of whether
they end in success or failure, are called alternative flows.
We will now start to look at how an actual use-case description is constructed. The focus here is on how the flow of events is
structured and how the different kinds of flow are related to each other. To this end, the descriptions are kept at the outline level—we
will look at how to complete the use-case descriptions in Chapter 8, Writing Use-Case Descriptions: An Overview, and Chapter 9,
Writing Use-Case Descriptions: Revisited. The example we will use is the Place Local Call use case from the Simple Telephone
System example.
The Basic Flow
The basic flow is the description of the normal, expected path through the use case (sometimes referred to as the happy day scenario).
This is the path taken by most of the users most of the time. The basic flow for the Place Local Call use case could look like this:
Use Case—Place Local Call
Basic Flow
The use case starts when the Caller lifts the receiver.
The Caller enters the number to be called.
15
 The system connects the Caller's phone to the requested device.
The call is made.
The connection is terminated.
The details of the call are recorded.
The use case ends.

Remember that this is just an outline, not the full use-case description. The assumption behind the basic flow is that it will successfully
enable the actor to achieve the goal.
Alternative Flows—Optional Behavior and Variations on a Theme
Because of the circumstances that may prevail at the time the use case is being performed, other, less common elements of behavior
may be required to extend the flow of events.
If the basic flow represents the normal route to success, the alternative flows can be considered as detours. Some of these occur at the
actor's discretion, perhaps providing an easier or more scenic route. Others occur at the system's discretion, perhaps enforcing a higher
degree of security, exploiting the system's knowledge of the user's preferences, or handling special cases. For example, the variant and
optional behavior in the Place Local Call use case could include the following alternative flows:
No Answer
If the Callee does not answer, the Caller replaces the handset and use case ends.

Line Busy
If the Callee's line is in use, the system rings the busy tone. The Caller then replaces the handset and the use case ends.

Note: the descriptive text is included for explanatory purposes only and is not supposed to represent how the alternative flows of
events themselves would be written.
When you consider all of the possible optional and variant behavior that could be defined for a system, it is easy to become
overwhelmed with the available possibilities and forget to focus on the system's core, essential behavior. One of the benefits of the
flow of events' structure is that all of this information is kept independent of the use case's basic flow. The basic flow defines the core
behavior; the alternative flows complement this. Some of these are essential to the success of the system, but many are extraneous
"bells and whistles" and wish-list materials. The structure of the flow of events allows us to address each flow on its own merits and
maintain our focus on the system's essential behavior.
Alternative Flows—Exceptions/Error Conditions
The most common kinds of alternative flows are those that describe the errors that can occur and how they should be handled.
In our experience 60 to 80 percent of all software is written to handle exception and error conditions. Use cases are no exception to
this rule; it is very common for 60 to 80 percent of the text in the use-case descriptions to describe what errors can occur, when they
can occur, and how they are handled. For example, in the Place Local Call use case, the exceptional and error handling behavior could
include the following alternative flows:
Number Dialed Not Known
The system cannot identify a receiving device from the number dialed.

Number Is Engaged
The receiving device is already involved in a call.

The Signal Is Lost

The carrier / signal is lost during the call.

When you start to consider all the things that could go wrong at each step in the basic flow, you quickly generate a long list of error-
related alternative flows. This is one of the reasons that the use-case descriptions adopt the additive structure described here. This
allows the basic flow to be kept simple and avoids swamping it with descriptions of all the exceptions that can occur. This structure
also helps you write the use cases; plan the project; and scope, test, analyze, design, and implement the system.
Subflows
As a use case becomes more detailed, the text of the individual flow of events can become unwieldy and overlong. This is true for
even the simplest systems. Generally, as a flow of events grows in size, it naturally falls into a series of smaller, self-contained
subsections, each with its own clearly identifiable purpose. For example, the Place Local Call use case includes the sentence:
The system connects the Caller's phone to the requested device.

This requires elaboration into a set of individual actions and responses:

The system analyzes the digits of the entered number and determines the network address of Callee.
The system determines whether a connection can be established between Caller and Callee.
The system establishes the connection.
The system rings Callee's phone.

16
This expansion can lead to the thread of the flow becoming lost in the details. In cases like this, the individual sections of the flow can
be broken out into self-contained sections of text called subflows. These are given their own title and are presented as a miniflow of
events.
Subflow—Connect Caller and Callee
The system analyzes the digits of the entered number and determines the network address of Callee.
The system determines whether a connection can be established between Caller and Callee.
The system establishes the connection.
The system rings Callee's phone.

They are then included in the original flow of events by their title:
The Caller enters the number to be called.
Perform connect Caller and Callee.
The system maintains the connection until either the Caller or the Callee terminates the call.

This name of the subflow could be entered into the electronic format as a hyperlink or in a different text style. What is important is that
you can see that this is a placeholder and not the actual text from the flow of events.
Remember that the key to writing effective use cases is to focus on communication. It is only worth splitting up the flow of events into
subflows if they make the use case itself easier to read.
The Relationship Between the Various Flows
Another side effect of developing the use-case descriptions is that the identified alternatives and subflows will start to have
alternatives, exceptions, and subflows of their own. This can even be seen in the simple example, "Instructions to Get to Kurt's Party":
". . . If the wine shop is shut then the pub will do carry outs" or ". . . If you can't get any alcohol at all then just come anyway." One of
the powerful things about the way that use cases are structured is that we are always dealing with the same, simple constructs. As we
saw in the preceding example, defining subflows is very easy. A section of the flow of events is extracted and given a separate section
and a heading. It can then be included in any other flow of events in the use case by simply placing its title in the text and providing a
pointer to it. Defining alternative flows is also very simple. We just have to define when and where these flows may occur, what the
alternative flow of events is, and where the original flow of events is resumed if the use case is not explicitly ended by the alternative
flow. When writing basic and alternative flows, it is important that the basic flow of events is written independently of the alternative
and that it has no knowledge of the alternative flows; it must make complete sense without reference to the alternatives. The
alternative flow knows the details of when and where it is applicable as opposed to the original flow. It inserts itself into the basic flow
when a particular condition is true. See Figure 2-11.
Figure 2-11. The typical structure of the flow of events. The straight arrow represents the basic flow of events, and the curves
represent alternative paths in relation to the basic flow. Some alternative paths return to the basic flow of events, whereas others
end the use case.

If the subflow or alternative flow is being applied to another subflow or alternative flow, then the rules are the same except that the
original flow of events is no longer the basic flow. Figure 2-11 illustrates the typical structure of a flow of events.
We shall look at these relationships in more detail in Chapter 7, The Structure and Contents of a Use Case.
The Size and Complexity of a Use-Case Description
Or "how long is a piece of string?" [6]
[6]
Answer: It should be as long as necessary to accomplish the task at hand.
Typically, use-case descriptions are 5 to 15 pages long. We have seen some as short as half a page and others as long as 30 pages. The
key thing to remember is that each use-case description has to be long enough to clearly tell its story. It has to explain the basic and
alternative flows in a form that satisfies all of the stakeholders. For a very simple, data-capture use case with few or no alternatives,
this can be a few sentences long, and in other cases—say for a complex interaction involving many actors with many alternatives—

17
this will require a lot of text. Even in a use case as simple as one describing how to withdraw cash from an automatic teller machine,
we have seen as many as 22 alternative flows identified. If the alternatives and exceptions themselves have lots of alternatives and
exceptions, this will again lead to longer use-case descriptions.
Use-case descriptions should be as long as it takes to tell the full story. As we shall see in Chapter 10, Here There Be Dragons, there
are various techniques we can use to help to manage the textual descriptions of the use cases. However, these techniques do not really
change the underlying size and complexity of the use-case model, they just move text from one use case to another and should be used
sparingly, if at all.
We have met some who might say that detailed use cases are unnecessary. To this complaint we would respond "is the behavior
required?" If the system must do the things described, then you'll have to capture the requirements at some point, and a use case offers
a number of advantages over other means of description.
Preconditions
To elaborate on our map analogy a little more, we can see that the description provided by the flow of events is of no use unless you
are at the correct starting point. The Instructions to Kurt's Party are of little or no use to you unless you are either in the car park or
know how to get there.
In the use-case model, this starting point is represented by the states of the actor(s) and the system at the time the use case is to be
started. This statement is known as a precondition. For example, the Place Local Call use case could be given the following
precondition:
The Caller's device has a connection to the system, i.e., the carrier signal is there.

Preconditions are not a description of the event, or trigger, that starts the use case, but rather a statement of the conditions under which
the use case is applicable. The precondition is necessary for the use case to be started but is not sufficient to start the use case. The use
case must still be started by an actor but can only be started when the precondition is true. In the example, the precondition clearly
states that no local calls can be made when there is no carrier signal available.
Postconditions
In addition to using preconditions to clarify when the use case is available, it is often very useful to also specify the state of the system
when the use case ends. This is done by the use of postconditions.
A postcondition for a use case should be true regardless of which alternative flows were executed; it should not be true only for the
basic flow. If something could fail, you would cover that in the postcondition by describing the states in which the system can be when
the use case is completed. For example, the Place Local Call use case could be given the following postcondition:
The connection between the Caller and Callee has been terminated and all call details have been recorded.

This may seem trivial, but we know that as alternative flows are added to the use case, they can often lead to the system being left in
unacceptable states. For example, one of our colleagues was once phoned by a friend who was using a prototype next-generation
mobile phone. Unfortunately, the new system didn't allow the termination of the connection from the Callee's phone. When the initial
call was over and the prototype phone was returned to its owner's pocket, the call button was accidentally pressed and the phone
redialed our colleague's number. He answered the call and hung up when nobody replied to his greeting. This should have ended the
call, and, by implication, the use case, but unfortunately it did not terminate the connection between the two phones. He was able to
repeatedly pick up the phone receiver and listen to events at his friend's house, such as the playing of music, and so on. The end result
was that our colleague's phone was left in an unusable state for the next few days as a consequence of receiving a call from a badly
behaved system.
The clear definition of the use case's postcondition can go a long way toward alleviating this kind of problem, because it provides a
clear statement of the responsibilities of each use case and defines the state the system must be left in when the flow of events
completes.
Preconditions and postconditions can be powerful tools when initially defining and scoping the use cases. You first define when the
use case is applicable, using a precondition, and what the use case is supposed to achieve, using a postcondition. You can then describe
how to reach the postcondition from the precondition by writing the flow of events. See Figure 2-12.
Figure 2-12. A precondition is the state of the system and its surroundings that is required before the use case can be started. A
postcondition is the state the system can be in after the use case has ended.

18
Care should be taken when using pre- and postconditions: Only use them if the use-case audience perceives this as adding value. We
introduce them here to illustrate that use cases don't have to start from square one all the time. We revisit preconditions and
postconditions in more detail in Chapter 7, The Structure and Contents of a Use Case.
Use-Case Descriptions in Summary
To sum up:
 Ninety percent of the use-case model is beneath the surface shown by the use-case diagrams; the diagrams themselves are
merely overviews of system behavior.
 The most important part of a use case is the detailed description.
 The most important part of the use-case description is the flow of events.
 The flow of events has a well-defined structure based around the concepts of the basic and alternative flows.
 The basic flow describes the normal way of achieving the goals of the use case.
 Alternative flows extend the basic flow to cater to variants and exceptions.
 Subflows can be used to make a complex flow of events easier to read.
 Use cases do not have to start from square one but can make assumptions about the state of the system at the time that they
start.
 Preconditions and postconditions can be used to clarify the scope of a use case and document any assumptions the use-case
author has made about the state of the system.

19