Loading ...
Sorry, an error occurred while loading the content.

108872Re: New article: "Ideas," not "Requirements"

Expand Messages
  • David Hecksel
    Jul 17, 2005
      I think getting away from the word "requirement" completely is
      problematic. There are requirements, optional requirements,
      desired features/functionality, and future requirements.

      Strict requirements can come from:

      - government mandates / law changes that must be done and
      supported by an exact timeframe (with substantive penalities or
      revenue loss if not done)
      * both functional and reporting requirements
      - competitive pressures ( changes from competition )
      The business says if we don't match or improve what the
      competitor has we will lose 30% of our revenue in 6 months.
      That's pretty much a "requirement" ( or a decision to go out
      of business )
      - Mandate from corporate. Ie, we are introducing this product
      on MM/DD/YYYY with this new pricing/ordering scheme (assumes
      there is a new pricing mechanism. Our order management
      systems must support this new product / marketing
      promotion / recommendation engine / ... because it is
      tied to a holiday promotion, national advertising campaign , ... -
      something with an inflexible date and driven by another
      activity (and directly linked to that activity). Another
      example is supporting a new partner / partner sales program.
      If publicly announced to customers that it will be available
      on MM/DD/YYYY, supporting orders from and/or shipments to that
      partner is more than an idea

      I think substituting "ideas" for future requirements, potential
      requirements or items on an existing optional requirements list
      is a better way to use the term "Idea". The Business group can
      have real requirements that are more than ideas. I find the
      best ideas originating outside the business group coming from
      the hands on architect or a very good technical writer (someone who
      is software saavy and also has usability knowledge).

      The use of "idea" I like, and I encourage further thinking along
      that line. But I caution a "one glove fits all" approach to
      eliminating the word "Requirement" and changing it to "Idea".


      David Hecksel

      --- In extremeprogramming@yahoogroups.com, "Jeff Grigg"
      <jeffgrigg@c...> wrote:
      > --- Jim Shore <jshore@t...> wrote:
      > > "I've been working with a customer to help them define a
      > > custom agile process. One of the first things I've been
      > > doing is looking at where software requirements come from
      > > and how they're prioritized."
      > >
      > > Find my new article at
      > > http://www.jamesshore.com/Blog/Ideas_Not_Requirements.html.
      > I've been challenging the word "requirements" too. "How can you say
      > that this thing is a *REQUIREMENT*, when the business is doing just
      > fine right now without it? In what sense is is objectively
      > required???"
      > "Ideas." Now there's a nice idea. ;-> One possible shortcoming,
      > however: I'm looking for ideas that people are willing to *pay*
      > for. "Hey, I have an idea!" I say, "We could paint the house
      > pink." However, nobody really wants the house to be pink. So
      > something's missing there.
      > I think that the things masquerading as "requirements" today aren't
      > really requirements. They are (hopefully) things that people want
      > enough to pay for them. If I'm implementing things that no one
      > wants enough to be willing to pay for them, then I think that
      > someone is misusing someone else's money. :-[
    • Show all 8 messages in this topic