|
In
February, I concluded that the widespread adoption of Use
Cases could lead to the death of Interaction Design. Following the
publication of Software For
Use, which documents the Usage Centered Design Process, I
have decided to revisit the thorny topic of Use Cases and the role
they have to play in Software Engineering for the next century.
Constantine and Lockwood have
proposed a very simple solution to the key problem with Use Cases
which I detailed in this column Feb 99, namely, Use Case analysis
leads to premature Interaction Design as a part of the
requirements process. Usage Centered Design shows us how to
develop first a Scenario describing a Single Path through a work
process, abstract that out to a Use Case (the Jacobson definition)
then further abstract to an Essential Use Case (the Constantine &
Lockwood definition). Essential Use Cases have the Interaction
Details removed, thus leaving the UI Designer to interpret them as
they please. So everything is OK now?!
Well, NO frankly it isn't!
The second problem I described in
February still remains - People! And then you can go on to list
another set of identified problems with Use Cases which are more
to do with code development and fundamental software engineering
than Interaction Design.
People
The problem with people is that there
simply aren't enough good ones around to fill the demand for
software engineering worldwide. Face it! Its a fact of life. You
will work with a lot of people who are out of their depth and very
uncomfortable. In an industry that needs professionalism, many of
your colleagues will never have read a book since they left
college, with the possible exception of API reference materials,
or UI Guidelines references.
The importance of People in the
Process, Technology, People triad can never be over estimated.
Processes
Use Cases are part of the software
engineering process. Processes are developed in order to give
humans a framework in which to do their work. A good process is
designed to produce repeatable results and will endeavour to save
humans for their own humanity. Human beings are not designed to
perform repeatedly with reliability. Processes are designed to
prevent humans from straying and making mistakes.
Consider for a moment the sport of
golf. The world's greatest golfers are the ones who can repeat the
perfect shots the most often. Arguably the best golfers are those
who are automaton like - the least human. They achieve this
standard through constant analysis of their own swing. They spend
hours perfecting the swing. They learn to understand all the
movements in it and what's involved in repeating it. The swing is
the golfers process for hitting a good ball. It is designed to
make him perform with reliability and repeatability. To give him
that in-human property that can make him win over his more "human"
opponents.
Software processes must also be
designed to make the industry practitioners perform with reliable
and repeatable results. They must help to save them from their own
human frailties.
I fail to be convinced that Use Cases
can deliver this.
Pick and Choose Methodologies
About 10 years ago, I sat in a church
on Christmas night. The minister was giving his sermon when he
said, " Christianity is not a Pick and Choose religion".
Though arguable, his point was a simple one - you had to follow
all the teachings of Christianity to be compliant as a Christian.
You can make this same point about
rigorous software methodologies. You can not pick and choose the
bits you like from various ones and hope to have a reliable and
repeatable solution.
So for example, you may find that
your colleagues are advocating Use Cases because Constantine &
Lockwood have shown them to be "OK", but if you're not
practising Usage Centered Design then it clearly isn't OK. Essential
Use Cases are designed to be used as the input to an Interaction
Analysis and Design process as part of the whole Usage Centered
Design methodology. If you're not doing all of this, then my
argument from February still holds true.
Analysis is still difficult
The people problem is even more acute
with Analysis. How many truly great Analysts have you worked with
in your whole career? How many do you work with now? If its more
than a handful then you are truly lucky. Analysis is hard and good
analysts are rare.
It is obvious from reading "Software
for Use" that Essential Use Case analysis is a difficult
task, requiring skill and experience. I believe that teams could
learn and develop these skills, particularly if they hire a guru
such as Larry Constantine to help. However, for many teams around
the world, this will not be possible. The chance, then that their
Essential Use Cases are properly developed, is slim.
Use Case is vague term
The term Use Case has now been over
used in the industry. Many authors have produced their own
variations. Consider the writings of Jacobson, Fowler, Cockburn,
Mayhew, Schneider and others. All offer a slightly different
definition of Use Case. All offer slightly different claims for
what can be done with them.
If you are following the Usage
Centered Design methodology and using Use Cases as the
requirements for your Interaction Design, then it will be all too
tempting for others to hijack this effort and use the expensive to
develop Use Cases, for more traditional purposes.
At this point things go awry! All the
identified problems with Use Cases will start to haunt your
project.
Traditional Problems with Use
Cases
- Understanding the problem, the
business and its rules must happen first. Defining business
process, system operating procedures or lines of communication
is secondary. Use Cases lead to definition of procedures without
proper understanding of the problem domain.
- Developing Use Cases with a User
Group or Business Analyst group leads to premature interaction
design by unskilled practitioners
- Its hard to determine the
completeness of Use Cases because of their "single path"
nature. This can lead to developers using their imagination to
complete exception handling cases or rarely taken paths. This
can quickly ruin a good Interaction Design.
- Use Cases do not lend themselves
to OO development due to their nature as procedural descriptions
of functional decomposition.
- The User Group defining them are
required to second guess the future system operation. They find
this difficult or even impossible. This leads to new systems
which don't make an adequate improvement in operations
procedures and can miss the opportunity to simplify a process
and remove unnecessary people.
- Use Cases because of their
procedural nature lend themselves to action-object User
Interface designs. If you need or want to have an object-action
UI Design (aka OOUI) then Use Cases are a poor foundation.
- Use Cases can end up as the
repository for the whole requirements. Everything goes into the
Use Cases and the Business Analyst group will claim, "the
design is done already, now write the code". This is very
very bad for Interaction Design.
- Use Cases are poor input for
Object Modeling. They can lead to poor definition of classes
from noun extraction as you may otherwise be hoping to eliminate
some of the domain terms used within the object model.
Summary
Usage Centered Design is a rigorous
methodology for Interaction Design. I was impressed with the
approach of Essential Use Cases. However, be warned! Essential Use
Cases are NOT Use Cases as you may have known them. With
sufficient skill in Essential Use Cases and following the Usage
Centered Design methodology entirely then I believe that they can
be useful. Applying Essential Use Cases within more established
approaches will almost certainly lead to some or all of the
problems listed above!
Acknowledgments
Jeff
de Luca and Stephen Palmer contributed their thoughts to
this article which draws on published work and Usenet postings by
Ben Kovitz www.manning.com/KOVITZ
), K. Alexander ( www.ksiinc.com
), Peter Coad, Don Firesmith and Bertrand Meyer. |
