I sat through a great use case analysis session recently.
because I saw lots of ways to derail a simple process. Eventually, we
did identify a couple of actors and a couple of use cases. But it took
hours and hours.
Bonus: this was the third
go-round on these exact use cases.
The first go-round of
requirements gathering was a conference call. We produced some nice
notes. Very good stuff.
whiteboarding tools available with Skype work pretty well. We could
sketch stuff, and collect notes, and digest the conversation down to a
The actual work went pretty
well. Stuff got built. The principal users need -- of course -- to
review the preliminary stuff. There's a first sprint to build stuff,
followed by some chance to comment, followed by a second sprint to
Focus was lost two ways. One, the
technical folks were derailed by other, more important projects.
Customer pilots, reinstallation on a new host, and an unrelated project
threw down trump cards. Second -- and more important -- the principal
users simply could not find time or interest to review the preliminary
no sensible reason, we had a second go-round of requirements gathering.
The core problem is that the users simply won't take the time to try
something out on their own. They're sales folks, without an actual
customer in the room, they seem incapable of doing anything. This kind
of world view takes some getting used to.
of previewing what was available, they insisted on more requirements
gathering. What we got was a random document that purported to describe
what the actors might do. It was intended to repeat the initial phone
call with more focus. Instead it had lots of "We'll need to talk about
this" parenthetical comments.
In short, it was
impossible for them to even set down a coherent idea on paper. All
they could do was talk about it. There was no alternative to a
order to make some progress, our Adobe FLEX developers were brought in
to create something a little snappier than the simplistic HTML interface
we had been working on. We redid the entire requirements gathering for
The principle users -- sales folks --
did not want any of the previous requirements gathering results brought
in. We had to have a "conversation", repeating the entire previous
effort from the ground up.
And -- of course --
all of the previous dead-ends, bad ideas, logical impossibilities and
business impossibilities had to be repeated yet again. Data that's
never been available was still spoken of as "required". The
conversation on why the data cannot possibly exist had to be rehashed.
derailing the process is simple. The sales folks cannot work
independently. Each interaction must be a hands-on, guided tour of the
software in which the sales folks say random things that must be
At some point in the future, there's
a remote possibility that someone will login on their own and actually
run the demo that's been in place for months.
developers, we have been remiss in not catering to their learning
style. They cannot think without talking, and they cannot take action
unless they're influencing someone. Asking them to test the demo site
is unproductive because they simply wont. Asking them for "comments"
can be troublesome because they're job is influence, not simply provide a
simplified "ok/not ok" feedback on specific features of the
implementation of their use case.
Additionally, we have folks that keep
trying to define the requirements in broad, sweeping terms. They're
uncomfortable with an end-to-end use case. At each step in the
interaction they want to define all the possible future courses of
events and interactions and consequences of each alternative course.
with the big-picture view have a hard time writing a use case that
describes a task from beginning to the end. Even basic concepts like
"Creating Business Value" can be elusive since the possibilities are
As developers, we were successful at
focusing down on a complete use case. With some effort we got from the
user's initial interaction to the final bit of business value.