 |
An essential use case (Constantine
and Lockwood 1999), sometimes called a business use
case, is a simplified, abstract, generalized use case
that captures the intentions of a user in a technology
and implementation independent manner. A fully
documented essential use case is a structured narrative,
expressed in the language of the application domain and
of users, comprising a simplified, abstract,
technology-free and implementation-independent
description of one task or interaction. An essential use
case is complete, meaningful, and well designed from the
point-of-view of users in some role or roles in relation
to a system and that embodies the purpose or intentions
underlying the interaction. |
|
It isn’t quite accurate to say that
an essential use case is a business use case in the RUP
sense of the term, although they are very close. A
business use case is often more focused on the business
process and existing technology concerns are often
brought into them. Think of them as somewhere in
between essential and system use cases, although leaning
towards the essential end of the spectrum.
Figure 1
presents an example of a detailed essential use case.
Notice how brief and to the point the language is.
There isn’t a lot of detail because you only need to get
the basic idea across. The language of the application
domain and of users is used, comprising a simplified,
generalized, abstract, technology-free and
implementation-independent description of one task or
interaction. An essential use case is complete,
meaningful, and well designed from the point-of-view of
users in some role or roles in relation to a system and
that embodies the purpose or intentions underlying the
interaction.
Figure 1. Essential use
case.
Enroll In Seminar
ID: UC 17
Preconditions:
- The student is enrolled in the university.
Postconditions:
|
User Intention |
System Responsibility |
|
Student identifies himself
Choose seminar
Confirm enrollment |
Verifies eligibility to enroll
via BR129 Determine Eligibility to Enroll.
Indicate available seminars
Validate
choice via BR130 Determine Student Eligibility to
Enroll in a Seminar.
Validate
schedule fit via BR143 Validate Student Seminar
Schedule
Calculates fees via BR 180
Calculate Student Fees and BR45 Calculate
Taxes for Seminar.
Summarize fees
Request confirmation
Enroll student in seminar
Add fees to student bill
Provide confirmation of
enrollment |
Essential use cases are typically
written in two column format, the column on the left
indicates the intention of the user/actor and the column on the right
the system's responsibility to hopefully respond. The actor(s) will
try to do
something and receive one or more responses to that
action. As you can see the flow of the use case is
apparent from the spacing of the actions and responses,
although you may decide to number the steps to make it
more apparent.
The use case refers to
business rules but does not embed the rule in the
use case, reflecting AM's practice of
Apply the Right Artifact(s). This is a
style issue, albeit one that over the years has enabled
me to travel light by only recording information in one
place (other artifacts will need to refer to business
rules as well). You basically want to avoid
Use Cases of Mass Destruction.
Notice how I’ve chosen to indicate a unique identifier for the use case
as well as its preconditions and postconditions. These
three pieces of information are optional although very
useful. I indicate an identifier whenever I need to
reference an artifact somewhere else – for example the
use case itself references business rules, each of which
have a unique identifier. The preconditions, if any,
indicate what must be true before this use case is
allowed to run. The postconditions, if any, indicate
what will be true once the use case finishes
successfully.
A significant advantage of
essential use cases is that they enable you to stand
back and ask fundamental questions like "what's really
going on" and "what do we really need to do" without
letting implementation decisions get in the way. These
questions often lead to critical realizations that allow
you to rethink, or reengineer if you prefer that term,
aspects of the overall business process.
When you are essential use case modeling you can be
technology independent but you will never be perfectly
“system independent”. You will always be bound by the
scope of your effort, but the vision/goals of your
project. As a result the perceived system that you’re
building, be it manual, automated, or a hybrid of the
two, will always affect your how you write your use
cases.
Why essential use cases?
Traditional/system use cases typically contain too
many built-in assumptions, often hidden or implicit,
about the underlying technology implementation and the
user interface yet to be designed. This is a good
feature during your analysis and design efforts, but not
so good for your requirement efforts. An essential use
case, on the other hand, is based on the purpose or
intentions of a user, rather than on the concrete steps
or mechanisms by which the purpose or intention might be
carried out.
This artifact description is excerpted from Chapter 5 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
 |
|
This is the best book to read if you
want to learn how how write use cases effectively. |
|
|
|
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
of the
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
 |
|
This is a very good book describing
techniques for working with your stakeholders,
including use case modeling. |
 |
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
elicit requirements,
architect, and then
design your system in an agile manner. |
 |
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around. |
|
Other artifact overviews
|
|
Use Case Diagrams and
System Use Cases. |
|
Other Use Case Writings |
|
UML Use Case Diagram Style Guidelines
Reuse in Use Case Models |
Translations
I actively work with clients around the world to
improve their information technology (IT) practices as
both a mentor/coach and trainer. A full
description of what I do, and how to contact me, can be
found here.
|
