Who gets interviewed to produce use cases?

[David Lamb]

From: "David Lamb" <david.lamb@1:261/38.remove-p82-this>

From: David Lamb <[email protected]>

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?

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Lew]

To: David Lamb
From: "Lew" <lew@1:261/38.remove-qhs-this>

To: David Lamb
From: Lew <[email protected]>

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.

--
Lew

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Robert Klemme]

To: David Lamb
From: "Robert Klemme" <robert.klemme@1:261/38.remove-qhs-this>

To: David Lamb
From: Robert Klemme <[email protected]>

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

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Gene Wirchenko]

To: Lew
From: "Gene Wirchenko" <gene.wirchenko@1:261/38.remove-qhs-this>

To: Lew
From: Gene Wirchenko <[email protected]>

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

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Lew]

To: Gene Wirchenko
From: "Lew" <lew@1:261/38.remove-qhs-this>

To: Gene Wirchenko
From: Lew <[email protected]>

projects.

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.

--
Lew

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Jukka Lahtinen]

To: David Lamb
From: "Jukka Lahtinen" <jukka.lahtinen@1:261/38.remove-qhs-this>

To: David Lamb
From: Jukka Lahtinen <[email protected]>

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.

--
Jukka Lahtinen

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[David Lamb]

To: Lew
From: "David Lamb" <david.lamb@1:261/38.remove-qhs-this>

To: Lew
From: David Lamb <[email protected]>

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."

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[David Lamb]

To: Gene Wirchenko
From: "David Lamb" <david.lamb@1:261/38.remove-qhs-this>

To: Gene Wirchenko
From: David Lamb <[email protected]>

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.

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Gene Wirchenko]

To: David Lamb
From: "Gene Wirchenko" <gene.wirchenko@1:261/38.remove-qhs-this>

To: David Lamb
From: Gene Wirchenko <[email protected]>

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

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Arne Vajhøj]

To: David Lamb
From: "Arne Vajhoj" <arne.vajhoj@1:261/38.remove-nlb-this>

To: David Lamb
From: Arne Vajhoj <[email protected]>

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

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Arne Vajhøj]

To: Lew
From: "Arne Vajhoj" <arne.vajhoj@1:261/38.remove-nlb-this>

To: Lew
From: Arne Vajhoj <[email protected]>

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

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Arne Vajhøj]

To: David Lamb
From: "Arne Vajhoj" <arne.vajhoj@1:261/38.remove-nlb-this>

To: David Lamb
From: Arne Vajhoj <[email protected]>

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

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Leif Roar Moldskred]

To: Arne Vajhøj
From: "Leif Roar Moldskred" <leif.roar.moldskred@1:261/38.remove-nlb-this>

To: Arne Vajhoj
From: Leif Roar Moldskred <[email protected]>

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

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.

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.

--
Leif Roar

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Gene Wirchenko]

To: Leif Roar Moldskred
From: "Gene Wirchenko" <gene.wirchenko@1:261/38.remove-z1z-this>

To: Leif Roar Moldskred
From: Gene Wirchenko <[email protected]>

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

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Leif Roar Moldskred]

To: Leif Roar Moldskred
From: "Leif Roar Moldskred" <leif.roar.moldskred@1:261/38.remove-z1z-this>

To: Leif Roar Moldskred
From: Leif Roar Moldskred <[email protected]>

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.

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.

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.

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.

--
Leif Roar Moldskred

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Gene Wirchenko]

To: Leif Roar Moldskred
From: "Gene Wirchenko" <gene.wirchenko@1:261/38.remove-z1z-this>

To: Leif Roar Moldskred
From: Gene Wirchenko <[email protected]>

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

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/38)
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24