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

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

Re: Who gets interviewed to produce use cases?

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

Contents

  Re: Who gets interviewed to produce use cases? "Leif Roar Moldskred" <leif.roar.moldskred@1:261/38.remove-s96-this> - 2012-08-16 19:16 +0000
    Re: Who gets interviewed to produce use cases? "Gene Wirchenko" <gene.wirchenko@1:261/38.remove-s96-this> - 2012-08-16 19:16 +0000

#17930 — Re: Who gets interviewed to produce use cases?

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

  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 <leifm@dimnakorr.com>

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

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

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

[toc] | [next] | [standalone]

#17940

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

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

  To: Leif Roar Moldskred
From: Gene Wirchenko <genew@ocis.net>

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

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

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

[toc] | [prev] | [standalone]

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

csiph-web