risks and requirements


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 3 of 3

Thread: risks and requirements

  1. #1
    keithray homepage.mac.com/keithray/blog/ Guest

    risks and requirements


    Agile Modeling can fit into two (or more) methods: Rational Unified Process,
    and Extreme Programming. Both of those methods ALLOW business analysts to
    be involved (RUP probably recommends it more strongly).

    In Extreme Programming, rights and responsibilities are divided between "business"
    and "developers". The "business" side has the business analysts, the QA testers,
    domain experts, users, stakeholders, and so on. All wrapped up in the single
    word "Customer" in XP lingo.

    The "developer" side has the programmers, DBA, and so on. User interface
    experts may be either side, depending on whether they do programming as well
    as user interface design.

    The two sides are clearly divided (but on the same team) to reduce risks:
    if the business guys (who are not programmers) start telling telling the
    developers how to do programming, they risk technical failure. If the programmers
    tell the business guys what features should be implemented, there is a risk
    that project will not meet business needs, and instead become a playground
    for developers.

    If you have business analysts in your team, it is the job of business analysts
    to help a stakeholder come up with requirements. Some developers are also
    skilled analysts, others are not.

    > I'm being over-dramatic on purpose, but when you say
    > that I "know what I want" I am here to tell you that I very frequently

    do not
    > know what I want. You might argue that it's in my head somewhere and it

    just
    > has to be brought out. OK, it might be. <she says with doubt in her voice>

    But
    > I am not going to be able to get it out by myself. That's just not going

    to
    > happen. And we cannot be mealy-mouthed about the fact that it is the
    > developer's JOB, RESPONSIBLITY, to help me. If you agree with that statement,


    > then this is what I meant when I said that I perceive a contradiction.



    I find this "fear of requirements" interesting. I've been in software development
    for close to 18 years, and this is first time I've ever met someone expressing
    this sentiment.

    When talking about what to ask the genie in the magic lamp, (which is what
    software developers are) I've never seen anyone with a lack of ideas. They
    may not know HOW to get what they want, but they always know enough of what
    they want to say something. Things like...

    "Wouldn't it be great if ...."
    "Could you make it so that ..."
    "I want this..."
    "Our customers are doing this manually, and we want to sell them software
    that does it for them..."
    "This is what I do all day, I want it simpler and faster."
    "Make it do this."
    "Our competitor has product x, we need something like that."

    The great thing about agile projects, is that you DON'T have to ALL the requirements
    up-front, just enough to get started. Once you see the software working (minimally),
    you can change your mind about the requirements that are not yet implemented
    or have been implemented.

    The business side is responsible for the requirements, because they are
    responsible for running their business. To avoid this responsibility is to
    let the developers run your business; unless the business is about making
    tools for other software developers, it's unlikely that have the expertise
    to satisfy your customers and make a profit.

    Recommended reading:

    "Exploring Requirements: Quality Before Design" by Gerald M. Weinberg
    <http://www.amazon.com/exec/obidos/AS...ithraymacco-20>

    "Planning Extreme Programming" by Kent Beck, Martin Fowler.
    http://www.amazon.com/exec/obidos/AS...ithraymacco-20


  2. #2
    Dennis Bronstein Guest

    Re: risks and requirements

    <keithray homepage.mac.com/keithray/blog/> wrote in message
    news:3e9056a9$1@tnews.web.devx.com...

    > The two sides are clearly divided (but on the same team) to reduce risks:
    > if the business guys (who are not programmers) start telling telling the
    > developers how to do programming, they risk technical failure. If the

    programmers
    > tell the business guys what features should be implemented, there is a

    risk
    > that project will not meet business needs, and instead become a playground
    > for developers.
    >
    > If you have business analysts in your team, it is the job of business

    analysts
    > to help a stakeholder come up with requirements. Some developers are also
    > skilled analysts, others are not.


    This is the part I don't get in this discussion. It's been pretty clear in
    my experience as a developer that the only input developers should have into
    requirements is giving an estimate of how long it will take to implement
    them. Having developers help define requirements is like having end users
    help design the system architecture.

    > I find this "fear of requirements" interesting. I've been in software

    development
    > for close to 18 years, and this is first time I've ever met someone

    expressing
    > this sentiment.
    >
    > When talking about what to ask the genie in the magic lamp, (which is what
    > software developers are) I've never seen anyone with a lack of ideas. They
    > may not know HOW to get what they want, but they always know enough of

    what
    > they want to say something. Things like...
    >
    > "Wouldn't it be great if ...."
    > "Could you make it so that ..."
    > "I want this..."
    > "Our customers are doing this manually, and we want to sell them software
    > that does it for them..."
    > "This is what I do all day, I want it simpler and faster."
    > "Make it do this."
    > "Our competitor has product x, we need something like that."


    I agree. I have never worked with any end users/customers who didn't know
    what they wanted. There have been times when they have had trouble
    expressing it clearly - which is where a good business analyst really
    helps - but they always know what they want the software to do.

    > The business side is responsible for the requirements, because they are
    > responsible for running their business. To avoid this responsibility is to
    > let the developers run your business; unless the business is about making
    > tools for other software developers, it's unlikely that have the expertise
    > to satisfy your customers and make a profit.


    Exactly.




  3. #3
    Mike Mitchell Guest

    Re: risks and requirements

    On Mon, 7 Apr 2003 08:43:39 -0600, "Dennis Bronstein"
    <dbronstein@yahoo.com> wrote:

    >This is the part I don't get in this discussion. It's been pretty clear in
    >my experience as a developer that the only input developers should have into
    >requirements is giving an estimate of how long it will take to implement
    >them. Having developers help define requirements is like having end users
    >help design the system architecture.


    Developers should not even need to be consulted on the time
    requirements! If the tasks required to produce a software application
    were properly standardised, measurable, quantifiable and capable of
    being verified, all designers would be able to consult a standard work
    to determine how long a project should take.

    Software production is far too much like the activity of World War One
    fighter pilots, seat-of-the-pants being the fount of all decisions,
    and every minute bringing new challenges and new dangers.

    MM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center