Who gets interviewed to produce use cases?

Discussion in 'Java' started by David Lamb, Aug 8, 2012.

  1. David Lamb

    David Lamb Guest

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

    From: 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?

    -+- 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, Aug 8, 2012
    #1
    1. Advertising

  2. David Lamb

    Lew Guest

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

    To: David Lamb
    From: Lew <>

    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

    -+- 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, Aug 9, 2012
    #2
    1. Advertising

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

    To: David Lamb
    From: Robert Klemme <>

    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

    -+- 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, Aug 9, 2012
    #3
  4. To: Lew
    From: "Gene Wirchenko" <gene.wirchenko@1:261/38.remove-qhs-this>

    To: Lew
    From: Gene Wirchenko <>

    On Tue, 7 Aug 2012 13:47:02 -0700 (PDT), 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.


    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

    -+- 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, Aug 9, 2012
    #4
  5. David Lamb

    Lew Guest

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

    To: Gene Wirchenko
    From: Lew <>

    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

    -+- 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, Aug 9, 2012
    #5
  6. To: David Lamb
    From: "Jukka Lahtinen" <jukka.lahtinen@1:261/38.remove-qhs-this>

    To: David Lamb
    From: Jukka Lahtinen <>

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

    -+- 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, Aug 9, 2012
    #6
  7. David Lamb

    David Lamb Guest

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

    To: Lew
    From: David Lamb <>

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

    -+- 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, Aug 9, 2012
    #7
  8. David Lamb

    David Lamb Guest

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

    To: Gene Wirchenko
    From: David Lamb <>

    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.

    -+- 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, Aug 9, 2012
    #8
  9. To: David Lamb
    From: "Gene Wirchenko" <gene.wirchenko@1:261/38.remove-qhs-this>

    To: David Lamb
    From: Gene Wirchenko <>

    On Wed, 08 Aug 2012 09:47:54 -0400, 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

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

    -+- 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, Aug 9, 2012
    #9
  10. David Lamb

    Arne Vajhøj Guest

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

    To: David Lamb
    From: Arne Vajhoj <>

    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

    -+- 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, Aug 13, 2012
    #10
  11. David Lamb

    Arne Vajhøj Guest

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

    To: Lew
    From: Arne Vajhoj <>

    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

    -+- 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, Aug 13, 2012
    #11
  12. David Lamb

    Arne Vajhøj Guest

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

    To: David Lamb
    From: Arne Vajhoj <>

    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

    -+- 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, Aug 13, 2012
    #12
  13. To: Arne Vajhøj
    From: "Leif Roar Moldskred" <leif.roar.moldskred@1:261/38.remove-nlb-this>

    To: Arne Vajhoj
    From: Leif Roar Moldskred <>

    Arne Vajh-,j <> 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

    -+- 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, Aug 13, 2012
    #13
  14. To: Leif Roar Moldskred
    From: "Gene Wirchenko" <gene.wirchenko@1:261/38.remove-z1z-this>

    To: Leif Roar Moldskred
    From: Gene Wirchenko <>

    On Mon, 13 Aug 2012 05:32:48 -0500, Leif Roar Moldskred
    <> wrote:

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

    -+- 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, Aug 15, 2012
    #14
  15. 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 <>

    Leif Roar Moldskred <> 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
     
    Leif Roar Moldskred, Aug 15, 2012
    #15
  16. To: Leif Roar Moldskred
    From: "Gene Wirchenko" <gene.wirchenko@1:261/38.remove-z1z-this>

    To: Leif Roar Moldskred
    From: Gene Wirchenko <>

    On Tue, 14 Aug 2012 15:35:51 -0500, Leif Roar Moldskred
    <> wrote:

    >Leif Roar Moldskred <> 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
     
    Gene Wirchenko, Aug 15, 2012
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. David Lamb
    Replies:
    13
    Views:
    326
    Gene Wirchenko
    Aug 15, 2012
  2. David Lamb
    Replies:
    14
    Views:
    306
    Gene Wirchenko
    Aug 15, 2012
  3. Lew
    Replies:
    0
    Views:
    107
  4. David Lamb
    Replies:
    4
    Views:
    151
  5. Gene Wirchenko
    Replies:
    0
    Views:
    233
    Gene Wirchenko
    Aug 16, 2012
Loading...

Share This Page