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

New article: "Ideas," not "Requirements"

Expand Messages
  • Jim Shore
    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
    Message 1 of 8 , Jun 30, 2005
    • 0 Attachment
      "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.

      Cheers,
      Jim

      --
      James Shore - Titanium I.T. LLC - Successful Software

      phone: 503-267-5490
      email: jshore@...
      web/blog: http://www.jamesshore.com
    • Dominic Williams
      Hi Jim, I agree that using the word requirements is inappropriate in an XP context. User story is a vast improvement, but I really like your suggestion to
      Message 2 of 8 , Jul 1, 2005
      • 0 Attachment
        Hi Jim,

        I agree that using the word "requirements" is
        inappropriate in an XP context. "User story" is a vast
        improvement, but I really like your suggestion to use
        the word "idea", because it is less definitive than
        user story, and as you say in the article, anyone can
        have an idea.

        One problem is see with it is that one can also have
        "ideas" about the code, about the process... just like
        a story can be about anything, which may be why Kent (I
        presume) prepended the word "user".

        I still find myself using the word "feature" when I need
        to make it clear I'm talking about what the software
        does.

        Ideally, I'd like a word that merged all the qualities
        of idea, user story and feature... In the meantime,
        I'll definitely try "idea" in some circumstances.

        Thanks,

        Dominic Williams
        http://www.dominicwilliams.net

        ----
      • Willem Bogaerts
        When I look at the software as a tool, the word use (as a noun) comes to mind. For instance, the uses of a welding torch are welding, cutting, heat
        Message 3 of 8 , Jul 1, 2005
        • 0 Attachment
          When I look at the software as a tool, the word "use" (as a noun) comes
          to mind.
          For instance, the uses of a welding torch are welding, cutting, heat
          treatment, etc.
          However, these uses are generally not fine-grained. The use of a word
          processor might be to layout a text, but few people would say that
          saving a document is a use of a word processor.

          Best regards,
          Willem Bogaerts

          Dominic Williams wrote:
          > Hi Jim,
          >
          > I agree that using the word "requirements" is
          > inappropriate in an XP context. "User story" is a vast
          > improvement, but I really like your suggestion to use
          > the word "idea", because it is less definitive than
          > user story, and as you say in the article, anyone can
          > have an idea.
          >
          > One problem is see with it is that one can also have
          > "ideas" about the code, about the process... just like
          > a story can be about anything, which may be why Kent (I
          > presume) prepended the word "user".
          >
          > I still find myself using the word "feature" when I need
          > to make it clear I'm talking about what the software
          > does.
          >
          > Ideally, I'd like a word that merged all the qualities
          > of idea, user story and feature... In the meantime,
          > I'll definitely try "idea" in some circumstances.
          >
          > Thanks,
          >
          > Dominic Williams
          > http://www.dominicwilliams.net
          >
          > ----
          >
          >
          >
          > To Post a message, send it to: extremeprogramming@...
          >
          > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
          >
          > ad-free courtesy of objectmentor.com
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
        • Jeff Grigg
          ... 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
          Message 4 of 8 , Jul 1, 2005
          • 0 Attachment
            --- 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. :-[
          • Jim Standley
            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
            Message 5 of 8 , Jul 1, 2005
            • 0 Attachment
              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@...
              >
              > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
              >
              > ad-free courtesy of objectmentor.com
              > Yahoo! Groups Links
              >
              >
              >
              >
              >
              >
              >
            • aacockburn
              I prefer Kent Beck s word: wishes . see http://c2.com/cgi/wiki?RequirementsVsWishes
              Message 6 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 7 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 8 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.