144RE: [usage-centered] Capturing alternative paths, exceptions and business logic.
- Apr 18, 2002Kiril,
Thanks for opening up some important issues with your questions.
> I have been working on a large project to replace a number of disparateKeeping the essential narrative to the main flow or "success case" is so
> systems supporting a financial services business with an off-the-shelf
> product, which will act as a system of record, a batch processor
> and a call
> center UI.
> Our first step was to discover and document "the world" as it is today,
> since there was no coherent business domain documentation. We
> it by creating a business use case model to describe existing business
> processes. (We're using Rational Rose for modeling activities.)
> After that we went through the business model and identify required
> actor-system interactions and created system use cases.
> The next task to elaborate system use cases, and here're the questions.
> 1. It seems that all essential use case examples that I've seen describe
> the main path of interaction, leaving out alternative and exception paths.
> I'm reluctant to use extension use cases to capture other paths
> for the fear
> of making the model unreadable. Is there a better way?
widely practiced because that's what usually works best for so many
purposes, but especially for guiding interaction design and user interface
design. This practice keeps the design focused on essentials and leads to
cleaner interactions. However, the alternatives and exceptions ultimately
need to be modeled and handled somewhere. We expand these as extension use
cases whenever the extension cases make sense in and of themselves and are
of use (or potential use) elsewhere, that is in other use cases. If not, we
follow Alistair Cockburn's suggestion, and describe them as internal
extensions or "footnotes" within the base use case.
The real point is embodied in Constantine's Third Law: "Complexity, though
easily created, cannot be eliminated but can only be hidden or moved from
one place to another." Putting exceptions in separate use cases does not
make the model any more complex or unreadable, it just moves the complexity
from one place to another. Either you have fewer but messier use cases or
you have more but cleaner ones. Experienced modelers try to strike a
balance, such as that suggested by the best practices just described.
Ideally, we would like to see the software tools recognize this problem and
incorporate structured use cases so that, at a click of a button or link,
one could trace all the external extensions, see them on one page as if they
were internal, or extract internal extensions into external extension cases.
We keep trying to get the tool vendors to listen.
> 2. As we're elaborating use cases with our users, much of business logic,Following Ellen Gottesdiener's recommendations, we capture and retain
> procedural and legal constraints will come out. They must be
> captured. In
> the past I used activity diagrams to map out logic behind system
> responsibilities. Is anybody doing something different?
business rules in a separate model that is cross-linked to the essential use
cases. The use cases contain references to applicable business rules, and
each rule refers to the use cases affected. Putting them inside use cases is
an invitation to mistakes and maintenance headaches.
> 3. Recently I have re-read the book that started it all "Usage CenteredThe template looks very thorough and well thought out, but, as you say, it
> Design..." and it made me wonder if I overloaded the essential use case
> narrative with my modified template (attached) too much. The information
> that I added is useful, but it does make each use case a bit heavier. Any
has been weighted down some. We have always been hesitant to try and put too
much into any one model. Independent but cross-linked models are generally
better. One consequence of cramming so much into the use case narrative is a
great deal of redundancy and wordiness. We would address stakeholder issues
at the system/context level, but rarely if ever at the use case level, as
any significant impact on the task model is typically carried through by way
of the role/actor model. I would also have reservations about some sections.
For example, inclusion of "triggers" and "implementation notes" violates
One danger of such heavily loaded models is that they promote a kind of
obsessive-compulsive approach to box-filling. The modeling drags out into an
exercise in tedium within which an appreciation for the forest gets lost in
the recording of every leaf on every tree. This becomes a variant disease of
the old analysis paralysis.
The Extreme Programmers have an expression, YAGNI ("You ain't going to need
it.") that applies. In our experience, much of the time all the stuff that
gets stuffed into bloated use cases never gets read or used in any any
meaningful way. We strongly favor the cleanest, simplest use case model that
supports good visual and interaction design, with elaboration only later and
as necessary. In the YAGNI spirit, for example, most of the "future
improvements" and "implementation notes" that one could write when doing the
task modeling will most likely prove to be wrong headed or outright wrong
once the system is being built or actually being used.
Another danger is that modelers get so worn down by the implicit
requirements of documenting so much, that they start just ignoring or
skipping over all the extra stuff, which can lead to a false sense of
security about what is or is not in the model. If it takes a lot to write
such stuff, it also takes a lot to understand it. In addition, all that
information has to be maintained, which it will almost certainly not be.
Often, where highly elaborate use cases have been developed initially, very
quickly much of the contents becomes obsolete or even wrong, so they are, in
effect, discarded after one use. Much more streamlined use cases are more
apt to remain valid or to be maintained as the project continues and the
That said, the direction your template takes might be justified in some very
large projects with many participants and an external or business need (or
mandate) for highly structured, systematic process. In that context, I could
myself argue in favor of almost everything you have added, and even add a
few more things myself. However, in many cases, YAGNI rules. For my part, I
would still do most or all of my initial modeling on index cards and leave
the box-filling to someone with the stomach and talent for it.
I hope to see you at forUSE 2002 in August (www.forUSE.com/2002/).
BTW, would you have any objection to our posting your comprehensive use case
template on our Web site? Others in similar circumstances might find it
Director of Research & Development | Constantine & Lockwood, Ltd.
58 Kathleen Circle | Rowley, MA 01969
t: +1 978 948 5012 | f: +1 978 948 5036 | www.foruse.com
- << Previous post in topic Next post in topic >>