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

[XP] Re: New article: "Ideas," not "Requirements"

Expand Messages
  • aacockburn
    I prefer Kent Beck s word: wishes . see http://c2.com/cgi/wiki?RequirementsVsWishes
    Message 1 of 8 , Jul 2, 2005
    • 0 Attachment
      I prefer Kent Beck's word: "wishes".
      see http://c2.com/cgi/wiki?RequirementsVsWishes
      <<Requirement: n. that which is required; a thing demanded or
      obligatory.

      This is exactly the wrong word for this thing. In my projects, I
      often deliver a quarter of the original "things demanded or
      obligatory", and I still get paid. Either I do a terrible job of
      writing down these things, or they aren't actually "demanded or
      obligatory". If the latter, we should use a different word to denote
      them.

      I nominate wishes, as in "What are the wishes for the project so
      far?" "How have the wishes changed in the last week?" This puts us in
      the (perhaps uncomfortable) position of wish fulfillment, a
      ProgramFairy?. -- KentBeck
      >>

      I recently found it handy to refer to the use cases we had just
      collected as "the users' wishes" -- this worked well even to the
      users and stakeholders as well as the programming team. I couldn't
      have gotten as much mileage saying "the users' ideas".

      Alistair





      --- In extremeprogramming@yahoogroups.com, Jim Standley
      <jimstandley@a...> wrote:
      > We frequently have a "requirement" that is one of five equally
      > acceptable solutions to a business problem. If we find that one of
      the
      > others would be much cheaper to build, it takes an act of Congress
      to
      > change the fool thing. I'd rather see the "requirement" as solving
      the
      > problem with more leeway in implementing it. I sent the article
      about
      > "ideas" to the whole team.
      >
      > Jeff Grigg 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. :-[
      > >
      > >
      > >
      > >
      > > To Post a message, send it to: extremeprogramming@e...
      > >
      > > To Unsubscribe, send a blank message to: extremeprogramming-
      unsubscribe@e...
      > >
      > > ad-free courtesy of objectmentor.com
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > >
      > >
      > >
      > >
    • David Hecksel
      I think getting away from the word requirement completely is problematic. There are requirements, optional requirements, desired features/functionality, and
      Message 2 of 8 , Jul 17, 2005
      • 0 Attachment
        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".

        Regards,

        David Hecksel
        http://davidhecksel.com/about.html

        --- 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. :-[
      • Brad Appleton
        Interesting response David. I tend to call them all requests , and to me the difference is one of granularity: a requirement is the smallest possible testable
        Message 3 of 8 , Jul 18, 2005
        • 0 Attachment
          Interesting response David. I tend to call them all "requests", and to
          me the difference is one of granularity: a requirement is the smallest
          possible testable unit of behavior. A "request" may encompass one or
          more requirements, which together from a complete concept/idea from the
          perspective of the requestor.

          So from your perspective, are "Requirements" and "Ideas" simply
          different "states" of a request?

          I know of some shops that use a formal gated progression of incoming
          requests.:
          * They are initially called "ideas", and
          * if the basic idea is "accepted" it gets elaborated a bit more and
          becomes a "concept"
          * if the concept is accepted, as business case is developed, and if that
          is accepted, it becomes a "proposal"
          * if the "proposal" is accepted, it gets elaborated even more, and
          depending on the scope/scale of the request, it might become a
          "portfolio", or a "capability" or a "feature" or a "project" or an
          "enhancement"

          I like Dave Astel's idea of calling these requirements thingies
          "behaviors". A behavior would be the smallest possible testable unit of
          functionality. A behavior might have an attribute or priority associated
          withg it noting its criticality and how mandatory-vs-optional it is.

          David Hecksel wrote:
          > 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".
          >

          --
          Brad Appleton <brad@...> www.bradapp.net
          Software CM Patterns (www.scmpatterns.com)
          Effective Teamwork, Practical Integration
          "And miles to go before I sleep" --Robert Frost
        Your message has been successfully submitted and would be delivered to recipients shortly.