Level: Introductory Scott W. Ambler (scott_ambler@ca.ibm.com), Practice Leader, Agile Development, Rational Methods Group, IBM
04 Jan 2001 This article presents a collection of tips and techniques to improve the quality of system use-case models. This article is adapted from Chapter 6 of The Object Primer 2nd Edition.
Write from the point of view of the actor and in the active
voice
Use cases should be written in the active voice: "The student indicates
the seminar," instead of in the passive voice, "The seminar is indicated
by the student." Furthermore, use cases should be written from the
point of view of the actor. After all, the purpose of use cases is to
understand how your users will work with your system.
Write scenario text, not functional requirements
A use case describes a series of actions that provide value to an actor;
it doesn't describe a collection of features. For example, the "Enroll
Student in Seminar" use case describes how a student interacts with the
system to sign up for a seminar. It doesn't describe what the user
interface looks like or how it works. You have other models to describe
this important information, such as your user interface model and your
supplementary specifications. Object-oriented analysis is complex, which
is why you have several models to work with, and you should apply each
model appropriately.
Use cases only document behavioral requirements
A use case is neither a class specification nor a data specification.
This is the sort of information that should be captured by your conceptual
model, which in the object world is modeled via a UML class model. You are
likely to refer to classes described in your conceptual model, for
example, the "Enroll in Seminar" use case includes concepts, such as
seminars and students, both of which would be described by your conceptual
model.
Don't forget the user interface
System use cases often refer to major user interface (UI) elements, often
called boundary or user interface items, such as HTML pages and
reports. Use cases will sometimes refer to minor UI elements, such as
buttons or data entry fields, although this level of detail is not as
common.
Create a use case template
Use cases include a fair amount of information, information that can
easily be documented in a common format. You should consider developing
your own template (see the tip "Documenting a Use Case)."
Organize your use-case diagrams consistently
Common practice is to draw inheritance and extend associations
vertically, with the inheriting/extending use case drawn below the
parent/base use case. Similarly, include associations are typically drawn
horizontally. Note that these are simple rules of thumb -- rules
that, when followed consistently, result in diagrams that are easier to
read.
Don't forget the system responses to the actions of actors
Your use cases should describe both how your actors interact with your
system and how your system responds to those interactions. For example,
with the "Enroll in Seminar" use case, if the system does not respond when
the student indicates they want to enroll in a seminar, the student
would soon become discouraged and walk away.
Alternate courses of action are important
Start with the happy path, the basic course of action -- but don't forget
the alternate courses as well. Alternate courses will be introduced to
describe potential usage errors, as well as business logic errors
and exceptions. This important information is needed to drive the design
of your system, so don't forget to model it in your use cases.
Don't get hung up on <<include>> and <<extend>>
associations.
I'm not quite sure what happened, but I've always thought the proper use
of include and extend associations, as well as uses and extends
associations in older versions of the UML,
were never described well. As a result, use-case modeling teams had a
tendency to argue about the proper application of these associations,
wasting an incredible amount of time on an interesting, but minor, portion
of the overall modeling technique. I even worked at one organization that
went so far as to outlaw the use of the <<include>> and <<extend>>
stereotypes, an extreme solution that had to be reversed after a few weeks
when it was realized that the company still needed these concepts, even
though the organization hadn't come to a full agreement as to their proper
use.
Let use cases drive user documentation
The purpose of user documentation is to describe how to work with your
system. Each use case describes a series of actions taken by actors using
your system. In short, use cases contain the information from which you
can start writing your user documentation. For example, the "how to enroll
in a seminar" section of your system's user documentation could be written
using the "Enroll in Seminar" use case as its base.
Let use cases drive presentations
Part of software development is communicating your work efforts with
project stakeholders, resulting in the occasional need to give
presentations. Because use cases are written from the point of view of
your users, they contain valuable insight into the type of things your
stakeholders are likely to want to hear about in your presentations. In other
words, use cases often contain the logic from which to develop
presentation scripts.
Resources
About the author  | | |
Scott W. Ambler is President of Ronin International, a consulting firm specializing in object-oriented software process mentoring, architectural modeling, and Enterprise JavaBeans (EJB) development. He has authored or co-authored several books about object-oriented development, including the recently released The Object Primer 2nd Edition, which covers, in detail, the subjects summarized in this article. He can be reached at scott.ambler@ronin-intl.com and at his Web site at www.ambysoft.com. |
Rate this page
| 
