Who gets interviewed to produce use cases?

[David Lamb]

Does anyone have data, or at least an informed opinion, on how often
genuine users of a proposed piece of software get consulted on
developing use cases (or some close equivalent)? I ask here because of
the recent UML discussion and because I've seen people, especially Lew,
mention use cases reasonably frequently.

In an informal discussion with a colleague I was arguing based on things
I'd read that "modern best practices" recommended interviewing the
people who will actually use a software system in their jobs, rather
than only upper management or professional consultants. He said the
industry standard was to resell an old system to new customers and
charge for every small attempt to get it to work the way the customers
wanted.

Is he being excessively cynical, or am I being excessively naive? Does
anyone know which of us is closer to right? Is the answer different for
the Java and object-oriented-development community than it is for other
developers?

 

[Robert Klemme]

Does anyone have data, or at least an informed opinion, on how often
genuine users of a proposed piece of software get consulted on
developing use cases (or some close equivalent)? I ask here because of
the recent UML discussion and because I've seen people, especially Lew,
mention use cases reasonably frequently.

In an informal discussion with a colleague I was arguing based on things
I'd read that "modern best practices" recommended interviewing the
people who will actually use a software system in their jobs, rather
than only upper management or professional consultants. He said the
industry standard was to resell an old system to new customers and
charge for every small attempt to get it to work the way the customers
wanted.

Is he being excessively cynical, or am I being excessively naive? Does
anyone know which of us is closer to right? Is the answer different for
the Java and object-oriented-development community than it is for other
developers?

I actually believe you could both be right: it is in fact modern
practice to do so - but the practice might not be applied widely. Often
the people who decide about a software purchase and those who use it are
not identical.

It may be worse with web applications: there users are often not in the
same organization as the one who actually puts the money on the table.
Users might be asked when the product is operational already - or never.

In telco industries there are exist a lot of specifications. There is
is common practice to compare the sub set of the standard a customer
needs with the published compatibility documents of a vendor. Often
other aspects are given less weight, for example usability. But
customers actually describe use cases they want to have implemented.
Although these are often more formal than the term suggests (i.e.
contain specific protocol definitions).

Kind regards

robert

 

[Lew]

Does anyone have data, or at least an informed opinion, on how often
genuine users of a proposed piece of software get consulted on
developing use cases (or some close equivalent)? I ask here because of
the recent UML discussion and because I've seen people, especially Lew,
mention use cases reasonably frequently.

I mention use cases in a rather abstract sense, that is, to signify the underlying
phenomenon of a collection of circumstances and needs. You seem to use the
term in a more restricted sense of the documentation of such phenomena.

These are distinct things. The report is not the situation on the ground.

In an informal discussion with a colleague I was arguing based on things
I'd read that "modern best practices" recommended interviewing the
people who will actually use a software system in their jobs, rather
than only upper management or professional consultants. He said the
industry standard was to resell an old system to new customers and
charge for every small attempt to get it to work the way the customers
wanted.

Is he being excessively cynical, or am I being excessively naive? Does

You are not being naive, and he is being cynical. I cannot speak to whether
his cynicism is excessive.

I disagree that projects generally are designed to rip off customers as he
describes, but in some sectors such practices are more prevalent than in
others.

Every industry has its snakes in the grass.

anyone know which of us is closer to right? Is the answer different for
the Java and object-oriented-development community than it is for other
developers?

Those questions require data.

If there are data, they are either secret, in which case no one here
can tell you of them, or publicized, in which case GIYF.

Undoubtedly people here have opinions and anecdotes, but you are asking
about reality. To answer your questions requires data.

I can tell you from experience that projects exist that might give the
appearance of justifying your colleague's cynicism but that was not
deliberate. Many software projects are not well managed, but I attribute
that to incompetence rather than malice. Industry estimates of the failure
rate for multi-million-dollar projects (up into the billions!) range from
33% to 67%, that I've read.

So the data indicate that many projects fail to satisfy the requirements,
or even see deployment, with good evidence that it's the majority of projects.

The majority of *multi-hundred-million dollar* projects.

Is that on purpose? The data I've seen don't say.

 

[Gene Wirchenko]

I mention use cases in a rather abstract sense, that is, to signify the underlying
phenomenon of a collection of circumstances and needs. You seem to use the
term in a more restricted sense of the documentation of such phenomena.

I do both, but favour the underlying. My case is a bit special.
Having worked for my customer for about twenty years off and on, I
have a pretty good idea what needs to be handled.

These are distinct things. The report is not the situation on the ground.


You are not being naive, and he is being cynical. I cannot speak to whether
his cynicism is excessive.

I agree.

I disagree that projects generally are designed to rip off customers as he
describes, but in some sectors such practices are more prevalent than in
others.

Every industry has its snakes in the grass.

I agree here, too.

Those questions require data.

If there are data, they are either secret, in which case no one here
can tell you of them, or publicized, in which case GIYF.

Undoubtedly people here have opinions and anecdotes, but you are asking
about reality. To answer your questions requires data.

I can tell you from experience that projects exist that might give the
appearance of justifying your colleague's cynicism but that was not
deliberate. Many software projects are not well managed, but I attribute
that to incompetence rather than malice. Industry estimates of the failure
rate for multi-million-dollar projects (up into the billions!) range from
33% to 67%, that I've read.

And it could just be that the customer really does not know what
he wants. You can try describing it, but too often, he nods and then
complains later that it was not what he expected. Or the old "That's
just what I said, but it's not what I want!"

So the data indicate that many projects fail to satisfy the requirements,
or even see deployment, with good evidence that it's the majority of projects.

Sometimes, what requirements?

The majority of *multi-hundred-million dollar* projects.

Is that on purpose? The data I've seen don't say.

I have read posts by Lynn Wheeler (a long-time IBMer) of the
effect of companies having found that they can make more on marge
projects by not getting it right the first time.

Sincerely,

Gene Wirchenko

 

[Lew]

Sometimes, what requirements?

The requirements those projects were instituted to fulfill, of course.

I have read posts by Lynn Wheeler (a long-time IBMer) of the
effect of companies having found that they can make more on marge
projects by not getting it right the first time.

Those are anecdotes. They might even be credible and accurately
describe the motivation for some projects of his experience. They
aren't enough data to generalize about the degree of this practice.

 

[Jukka Lahtinen]

Does anyone have data, or at least an informed opinion, on how often
genuine users of a proposed piece of software get consulted on developing
use cases (or some close equivalent)? I ask here because of the recent UML

Not as often as they should.

 

[David Lamb]

I mention use cases in a rather abstract sense, that is, to signify the underlying
phenomenon of a collection of circumstances and needs. You seem to use the
term in a more restricted sense of the documentation of such phenomena.

Not really, which is why I said "or close equivalent." I should probably
have expanded a bit to say some reasonably precise description of user
requirements in a reasonably user-comprehensible form.

Those questions require data.

I know, which is why in the opening paragraph I asked if anyone had data
and, if not, falling back on informed opinons -- which you gave me later
in your response. Thanks! and thanks to everyone else who is responding
-- I'm waiting to see how the conversation plays out before saying much
more than I have already (except I plan to clarify what I meant whenever
it becomes apparent I left out important details).

In any case the data I was hoping for was on practices, not motivations
-- my colleague's expression was to me a hyperbolic version of "they
don't ask the actual users."

 

[David Lamb]

And it could just be that the customer really does not know what
he wants. You can try describing it, but too often, he nods and then
complains later that it was not what he expected. Or the old "That's
just what I said, but it's not what I want!"

I understand that. I was under the impression that "user centred design"
involved a collection of practices meant to improve communication
between customers and developers, of which UML use cases were one
example. In fact I recently read parts of the 3 UML books I have on
hand (reference, user's guide, and Unified Process) and found a
statement to the effect that use cases in particular were designed to
improve communications.

But, as I said in answer to Lew upthread, I should have made clearer
that use cases were just one example of the kind of user-centred
requirements elicitation mechanisms I had in mind.

 

[Gene Wirchenko]

I understand that. I was under the impression that "user centred design"
involved a collection of practices meant to improve communication

^^^^^^^

between customers and developers, of which UML use cases were one
example. In fact I recently read parts of the 3 UML books I have on
hand (reference, user's guide, and Unified Process) and found a
statement to the effect that use cases in particular were designed to
improve communications.

If we skip the gory detail, we can get it wrong by missing
important detail.

If we include the gory detail, we can get it wrong, because the
user just signs. (Do you read every EOLA? Etc.)

Either way, it seems to end up being our fault.

But, as I said in answer to Lew upthread, I should have made clearer
that use cases were just one example of the kind of user-centred
requirements elicitation mechanisms I had in mind.

I think that that was understood though.

Sincerely,

Gene Wirchenko

 

[Arne Vajhøj]

Does anyone have data, or at least an informed opinion, on how often
genuine users of a proposed piece of software get consulted on
developing use cases (or some close equivalent)? I ask here because of
the recent UML discussion and because I've seen people, especially Lew,
mention use cases reasonably frequently.

In an informal discussion with a colleague I was arguing based on things
I'd read that "modern best practices" recommended interviewing the
people who will actually use a software system in their jobs, rather
than only upper management or professional consultants. He said the
industry standard was to resell an old system to new customers and
charge for every small attempt to get it to work the way the customers
wanted.

Is he being excessively cynical, or am I being excessively naive? Does
anyone know which of us is closer to right? Is the answer different for
the Java and object-oriented-development community than it is for other
developers?

It is my clear impression that it is widely accepted that the real
domain experts must be involved in detailed requirements gathering
(use cases or other methods). For GUI that means the people that is
to use the GUI. For business rules that means the people that actually
make or understand those rules.

Customer management making up requirements is mostly a myth - no manager
want to write 100's/1000's/10000's of pages of requirements
documentation.

The real problems are that:
- the domain experts now how the old systems works but may have
huge difficulties explaining how the new system should work
- asking people about requirements is an open invitation to
scope creep

Most software development today is object oriented (not always
a good/elegant way, but ...).

I don't think Java is different from C# or PHP or C++
regarding requirements (and it is common to use more than
one language in the overall solution anyway).

Arne

 

[Arne Vajhøj]

I mention use cases in a rather abstract sense, that is, to signify the underlying
phenomenon of a collection of circumstances and needs. You seem to use the
term in a more restricted sense of the documentation of such phenomena.

These are distinct things. The report is not the situation on the ground.

Real use cases are widely used.

(and UML use case diagrams are actually pretty nice to give an overview
of them including the relationships between them)

Agile user stories are also widely used, so there are alternatives.

Arne

 

[Arne Vajhøj]

I understand that. I was under the impression that "user centred design"
involved a collection of practices meant to improve communication
between customers and developers, of which UML use cases were one
example. In fact I recently read parts of the 3 UML books I have on
hand (reference, user's guide, and Unified Process) and found a
statement to the effect that use cases in particular were designed to
improve communications.

Note that use cases are not a part of UML.

UML just provides a diagram that shows use cases and their relationship.

Arne

 

[Gene Wirchenko]

Another problem -- or perhaps rather a restating of the first problem
you mentioned -- is that even users with a very good _implicit_
knowledge of their work process often have a poor _explicit_
understanding of it. Often, a lot of important business requirements
are overlooked because the users either plain doesn't realise that
they're there, or because they take them as implicitly understood.

Such a user might also understand his job very well in terms of
how it is currently executed, but not have the strategic knowledge
behind that.

For the same reason, users are often terrible at prioritising between
features and choosing between different solutions. Often, the highest
priority goes to whichever feature the user thought of most recently.

Quite.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

Commenting to my own post here, but I really should add that the above
isn't to mean that the software developers know best and should
overrule the customer on requirements and priorities. Far from
it. (Well, _sometimes_ we should do that for _technical_ requirements,
but only sometimes.) It's still the users that actually _knows_ the
requirements, but sometimes they don't know what they know.

It is some of this, some of that. I have worked with one cient
for nearly 25 years. I know some of his requirements to the point
where I need not discuss them with him. Some are his to the point
where I do not know in detail why he wants it. In the middle are the
ones we discuss. We respect each other and come up with a plan.

Gathering requirements thus often turn into an explanatory dig into
the user's work process and business, and you often end up with not
only having the users teach the software developers about the buisness
domain but also with the software developers having to teach the users
about requirement gathering.

Again, quite.

Sincerely,

Gene Wirchenko