Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #17294 > unrolled thread

Who gets interviewed to produce use cases?

Back to article view | Back to comp.lang.java.programmer

Contents

  Who gets interviewed to produce use cases? David Lamb <dalamb@cs.queensu.ca> - 2012-08-07 14:26 -0400
    Re: Who gets interviewed to produce use cases? Robert Klemme <shortcutter@googlemail.com> - 2012-08-07 22:13 +0200
    Re: Who gets interviewed to produce use cases? Lew <lewbloch@gmail.com> - 2012-08-07 13:47 -0700
      Re: Who gets interviewed to produce use cases? Gene Wirchenko <genew@ocis.net> - 2012-08-07 14:23 -0700
        Re: Who gets interviewed to produce use cases? Lew <lewbloch@gmail.com> - 2012-08-07 14:54 -0700
        Re: Who gets interviewed to produce use cases? David Lamb <dalamb@cs.queensu.ca> - 2012-08-08 09:47 -0400
          Re: Who gets interviewed to produce use cases? Gene Wirchenko <genew@ocis.net> - 2012-08-08 09:48 -0700
          Re: Who gets interviewed to produce use cases? Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 22:57 -0400
      Re: Who gets interviewed to produce use cases? David Lamb <dalamb@cs.queensu.ca> - 2012-08-08 09:44 -0400
      Re: Who gets interviewed to produce use cases? Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 22:53 -0400
    Re: Who gets interviewed to produce use cases? Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2012-08-08 11:41 +0300
    Re: Who gets interviewed to produce use cases? Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 22:48 -0400
      Re: Who gets interviewed to produce use cases? Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-08-13 05:32 -0500
        Re: Who gets interviewed to produce use cases? Gene Wirchenko <genew@ocis.net> - 2012-08-14 12:35 -0700
        Re: Who gets interviewed to produce use cases? Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-08-14 15:35 -0500
          Re: Who gets interviewed to produce use cases? Gene Wirchenko <genew@ocis.net> - 2012-08-15 09:32 -0700

#17294 — Who gets interviewed to produce use cases?

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?

[toc] | [next] | [standalone]

#17300

On 08/07/2012 08:26 PM, David Lamb wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#17303

On Tuesday, August 7, 2012 11:26:41 AM UTC-7, David Lamb wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#17305

On Tue, 7 Aug 2012 13:47:02 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote:

>On Tuesday, August 7, 2012 11:26:41 AM UTC-7, David Lamb wrote:
>> 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.

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

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

     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

[toc] | [prev] | [next] | [standalone]

#17307

Gene Wirchenko wrote:
> Lew wrote:
>> 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 requirements those projects were instituted to fulfill, of course.

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

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

[toc] | [prev] | [next] | [standalone]

#17351

On 07/08/2012 5:23 PM, Gene Wirchenko wrote:
>       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.

[toc] | [prev] | [next] | [standalone]

#17355

On Wed, 08 Aug 2012 09:47:54 -0400, David Lamb <dalamb@cs.queensu.ca>
wrote:

>On 07/08/2012 5:23 PM, Gene Wirchenko wrote:
>>       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 
                                             ^^^^^^^
      I note that this word is not "perfect".  <sobs uncontrollably>

>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

[toc] | [prev] | [next] | [standalone]

#17773

On 8/8/2012 9:47 AM, David Lamb wrote:
> On 07/08/2012 5:23 PM, Gene Wirchenko wrote:
>>       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.

Note that use cases are not a part of UML.

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

Arne

[toc] | [prev] | [next] | [standalone]

#17350

On 07/08/2012 4:47 PM, Lew wrote:
> On Tuesday, August 7, 2012 11:26:41 AM UTC-7, David Lamb wrote:
>> 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.

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.

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

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

[toc] | [prev] | [next] | [standalone]

#17772

On 8/7/2012 4:47 PM, Lew wrote:
> On Tuesday, August 7, 2012 11:26:41 AM UTC-7, David Lamb wrote:
>> 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.

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

[toc] | [prev] | [next] | [standalone]

#17347

David Lamb <dalamb@cs.queensu.ca> writes:

> 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

[toc] | [prev] | [next] | [standalone]

#17771

On 8/7/2012 2:26 PM, David Lamb wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#17781

Arne Vajhøj <arne@vajhoej.dk> wrote:
> 
> 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

[toc] | [prev] | [next] | [standalone]

#17879

On Mon, 13 Aug 2012 05:32:48 -0500, Leif Roar Moldskred
<leifm@dimnakorr.com> wrote:

>Arne Vajhøj <arne@vajhoej.dk> wrote:
>> 
>> 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.

     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

[toc] | [prev] | [next] | [standalone]

#17882

Leif Roar Moldskred <leifm@dimnakorr.com> wrote:
> 
> 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

[toc] | [prev] | [next] | [standalone]

#17889

On Tue, 14 Aug 2012 15:35:51 -0500, Leif Roar Moldskred
<leifm@dimnakorr.com> wrote:

>Leif Roar Moldskred <leifm@dimnakorr.com> wrote:
>> 
>> 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.

     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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web