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

Re: [XP] Non Functional Requirements And XP

Expand Messages
  • BenAveling
    ... Hi Tamer, If I can respond with a question, what do you see as the important differences between Functional and Non-Functional Requirements? Why do you
    Message 1 of 26 , Oct 2, 2005
    • 0 Attachment
      tasmisr wrote:
      > Hi Everyone,
      > How does the XP process model address Non Functional Requirements?

      Hi Tamer,

      If I can respond with a question, what do you see as the important
      differences between Functional and Non-Functional Requirements?

      Why do you think that XP might need to handle them differently?

      Regards, Ben A.
    • Ron Jeffries
      ... I d add to Ben s questions: What specific non-functional requirements do you commonly face, and how do you handle them now? Ron Jeffries
      Message 2 of 26 , Oct 2, 2005
      • 0 Attachment
        On Sunday, October 2, 2005, at 7:23:14 AM, BenAveling wrote:

        > tasmisr wrote:
        >> Hi Everyone,
        >> How does the XP process model address Non Functional Requirements?

        > Hi Tamer,

        > If I can respond with a question, what do you see as the important
        > differences between Functional and Non-Functional Requirements?

        > Why do you think that XP might need to handle them differently?

        I'd add to Ben's questions: What specific non-functional
        requirements do you commonly face, and how do you handle them now?

        Ron Jeffries
        www.XProgramming.com
        Keep away from people who try to belittle your ambitions. Small people
        always do that, but the really great make you feel that you, too, can
        become great." -- Mark Twain.
      • Dale Emery
        Hi Ben, ... I use The Fantasy of Perfect Technology to distinguish them. The fantasy says to imagine the software being implemented with perfect technology:
        Message 3 of 26 , Oct 2, 2005
        • 0 Attachment
          Hi Ben,

          > If I can respond with a question, what do you see as the important
          > differences between Functional and Non-Functional Requirements?

          I use The Fantasy of Perfect Technology to distinguish them. The
          fantasy says to imagine the software being implemented with
          perfect technology: Perfect technology is infinitely fast, has
          infinite storage capacity, uses no energy, and so on.

          "Functional" requirements are the requirements we would specify
          even if we knew the software would be implemented with perfect
          technology.

          "Non-functional" requirements (I prefer the term "quality
          attributes") are those requirements we specify because we know
          that real technology is imperfect.

          Dale

          --
          Dale Emery, Consultant
          Inspiring Leadership for Software People
          Web: http://www.dhemery.com
          Weblog: http://www.dhemery.com/cwd
        • Ravi Mohan
          Dale, ... Awesome! I will, in future, use this to explain the difference to people. Very insightful. Thanks ! Ravi
          Message 4 of 26 , Oct 2, 2005
          • 0 Attachment
            Dale,

            > > If I can respond with a question, what do you see as the important
            > > differences between Functional and Non-Functional Requirements?
            >
            > I use The Fantasy of Perfect Technology to distinguish them.

            Awesome! I will, in future, use this to explain the difference to
            people. Very insightful. Thanks !

            Ravi
          • BenAveling
            ... Why do you think that XP might need to handle these differently? Regards, Ben
            Message 5 of 26 , Oct 2, 2005
            • 0 Attachment
              Dale Emery wrote:
              > "Functional" requirements are the requirements we would specify
              > even if we knew the software would be implemented with perfect
              > technology.
              >
              > "Non-functional" requirements (I prefer the term "quality
              > attributes") are those requirements we specify because we know
              > that real technology is imperfect.

              Why do you think that XP might need to handle these differently?

              Regards, Ben
            • Steven Gordon
              Stories that represent a functional requirement can be estimated, implemented and tested in isolation from other functional stories. This supports an iterative
              Message 6 of 26 , Oct 2, 2005
              • 0 Attachment
                Stories that represent a functional requirement can be estimated,
                implemented and tested in isolation from other functional stories. This
                supports an iterative development strategy where stories are implemented in
                priority order and the software is runnable after each story is finished. We
                have tests to make sure we do not break the story in later iterations, but
                it should rarely happen.
                Quality attributes are not independent from functional stories (or from
                each other). We cannot simply implement them once and expect that the goal
                is achieved for the entire life cycle of the system. Therefore we cannot
                just schedule them in priority order, estimate them, and implement them and
                their tests like a functional story. In any iterative approach, these
                qualities must be taken into account for each and every functional story.
                Steven Gordon

                On 10/2/05, BenAveling <bena@...> wrote:
                >
                > Dale Emery wrote:
                > > "Functional" requirements are the requirements we would specify
                > > even if we knew the software would be implemented with perfect
                > > technology.
                > >
                > > "Non-functional" requirements (I prefer the term "quality
                > > attributes") are those requirements we specify because we know
                > > that real technology is imperfect.
                >
                > Why do you think that XP might need to handle these differently?
                >
                > Regards, Ben
                >
                >


                [Non-text portions of this message have been removed]
              • tasmisr
                This is well explained Steven. The top scenarios that a client can think about are real life scenarios which leads directly to stories - the primary step for a
                Message 7 of 26 , Oct 2, 2005
                • 0 Attachment
                  This is well explained Steven.

                  The top scenarios that a client can think about are real life
                  scenarios which leads directly to stories - the primary step for a
                  XP enabled project-, Then comes the principle of coding simplicty
                  and getting the iteration done on time.

                  So functional requirements are a necessary part of a XP model. But I
                  didn't see an emphasize on the NFRs in the XP model and the 12 XP
                  practices.

                  I think Non functional requirements(security, performance,
                  availability, etc) can be handled in the same manner as handiling
                  functional requirements, with informing the client of the importance
                  of NFRs, the client himself will start thinking about it and will
                  include it as a "must have" feature in story cards, then programmers
                  will try to recoginze NFRs during the development and the resulting
                  project will satisfy boths FR and NFR.



                  --- In extremeprogramming@yahoogroups.com, Steven Gordon
                  <sgordonphd@g...> wrote:
                  > Stories that represent a functional requirement can be estimated,
                  > implemented and tested in isolation from other functional stories.
                  This
                  > supports an iterative development strategy where stories are
                  implemented in
                  > priority order and the software is runnable after each story is
                  finished. We
                  > have tests to make sure we do not break the story in later
                  iterations, but
                  > it should rarely happen.
                  > Quality attributes are not independent from functional stories
                  (or from
                  > each other). We cannot simply implement them once and expect that
                  the goal
                  > is achieved for the entire life cycle of the system. Therefore we
                  cannot
                  > just schedule them in priority order, estimate them, and implement
                  them and
                  > their tests like a functional story. In any iterative approach,
                  these
                  > qualities must be taken into account for each and every functional
                  story.
                  > Steven Gordon
                  >
                  > On 10/2/05, BenAveling <bena@x...> wrote:
                  > >
                  > > Dale Emery wrote:
                  > > > "Functional" requirements are the requirements we would specify
                  > > > even if we knew the software would be implemented with perfect
                  > > > technology.
                  > > >
                  > > > "Non-functional" requirements (I prefer the term "quality
                  > > > attributes") are those requirements we specify because we know
                  > > > that real technology is imperfect.
                  > >
                  > > Why do you think that XP might need to handle these differently?
                  > >
                  > > Regards, Ben
                  > >
                  > >
                  >
                  >
                  > [Non-text portions of this message have been removed]
                • Keith Braithwaite
                  ... the goal ... them and ... Well, to remain in control of our project we must agree a level of the quality attribute to be met for the next release, and
                  Message 8 of 26 , Oct 2, 2005
                  • 0 Attachment
                    --- In extremeprogramming@yahoogroups.com, Steven Gordon
                    <sgordonphd@g...> wrote:

                    > Quality attributes are not independent from functional stories (or from
                    > each other). We cannot simply implement them once and expect that
                    the goal
                    > is achieved for the entire life cycle of the system. Therefore we cannot
                    > just schedule them in priority order, estimate them, and implement
                    them and
                    > their tests like a functional story.

                    Well, to remain in control of our project we must agree a level of the
                    quality attribute to be met for the next release, and estimate the
                    cost of meeting that, must we not? And it would be wrong to focus
                    attention now on the less important attributes, wouldn't it?

                    And having met the level for an attribute this release, we can put
                    tests in place to ensure that we do not accidentally fall below that
                    level during work on the next release. And so on. Can't we?

                    Do you have an exmaple of a real "non-functional" requirement that
                    couldn't be deal with this way, that we could discuss?

                    Keith
                  • Steven Gordon
                    I do not think we are disagreeing. Perhaps you misunderstood my point, so I will rephrase: We have to apply quality requirements to each and every user story
                    Message 9 of 26 , Oct 2, 2005
                    • 0 Attachment
                      I do not think we are disagreeing. Perhaps you misunderstood my point, so I
                      will rephrase:
                      We have to apply quality requirements to each and every user story during
                      the course of the entire project rather than just handling it once like a
                      user story. This means a non-functional story cannot just go on the backlog
                      and be taken off the backlog at the beginning of the iteration that the
                      customer chooses for us to deal with it. This is why we cannot just lump it
                      in with the functional stories on the backlog.
                      Saying they are different does not imply they are less important, just that
                      they cannot be dealt with the same way.

                      On 10/2/05, Keith Braithwaite <Keith.Braithwaite@...> wrote:
                      >
                      > --- In extremeprogramming@yahoogroups.com, Steven Gordon
                      > <sgordonphd@g...> wrote:
                      >
                      > > Quality attributes are not independent from functional stories (or from
                      > > each other). We cannot simply implement them once and expect that
                      > the goal
                      > > is achieved for the entire life cycle of the system. Therefore we cannot
                      > > just schedule them in priority order, estimate them, and implement
                      > them and
                      > > their tests like a functional story.
                      >
                      > Well, to remain in control of our project we must agree a level of the
                      > quality attribute to be met for the next release, and estimate the
                      > cost of meeting that, must we not? And it would be wrong to focus
                      > attention now on the less important attributes, wouldn't it?
                      >
                      > And having met the level for an attribute this release, we can put
                      > tests in place to ensure that we do not accidentally fall below that
                      > level during work on the next release. And so on. Can't we?
                      >
                      > Do you have an exmaple of a real "non-functional" requirement that
                      > couldn't be deal with this way, that we could discuss?
                      >
                      > Keith
                      >
                      >


                      [Non-text portions of this message have been removed]
                    • Keith Braithwaite
                      If we aren t disagreeing, then I definietely don t understand your point :) Seems to me that these non-functional stories absolutely must go on the backlog,
                      Message 10 of 26 , Oct 2, 2005
                      • 0 Attachment
                        If we aren't disagreeing, then I definietely don't understand your
                        point :)

                        Seems to me that these "non-functional" stories absolutely must go on
                        the backlog, otherwise we have no visibility of them. And when
                        satisifed, they must come out of the backlog, otherwise we can't track.

                        These things happen just fine with a "non-functional" story just like
                        any other, I find.

                        Actually, that's not quite right. What I find is that there isn't any
                        such thing as a "non-fuctional" requirement as distinct from a
                        "functinal" one, so there isn't any difference to take into account.

                        In the world where specifications get written far ahead of the system
                        being built far ahead of it being used it is very easy to be very
                        definite about ludicrous performance targets, lets say. Or even worse,
                        scalability (or other abstract qualities). Any claimed requirement
                        with an "ility" in it is suspect, I'd say. But when the system is
                        right there, all that's there working, with users banging on it, then
                        it's very easy to be realistic and concrete.

                        This much throughput, from this many users, on this hardware, or
                        whatever, and we can write (stress) tests that gauge if this is has
                        been met. And those tests can be run again in the future to tell us
                        that the required level of throughput is still met as new
                        functionality is added. And if, as the users gain experience with the
                        system, or as new functionality brings heavier use. it is seen that
                        the system needs to handle more throughput, a story can be written for
                        that with suitable tests, as and when required. And so forth.

                        Seems to me that a lot of the overblown, overengineered "enterprise"
                        cobblers that a lot of teams are busy taking out of their systems so
                        that they will be faster and support more users (using less system
                        resources to do it), be easier to maintain etc. etc. were put in so as
                        to (allegedly) deal with terribly abstract, very far forward looking,
                        non-functional pseudo-requirements like "scalability". This probably
                        has something to do with the dot.com business models that relied on
                        huge increases in user volumes over short periods coming out of thin
                        air to make even what little sense they did.

                        Are we in agreement?

                        Keith
                      • Andrew McDonagh
                        Keith Braithwaite wrote: snippet... ... Agreed - I ve been stressing this very point just lately - we are team that went from no process to full-on Architect
                        Message 11 of 26 , Oct 2, 2005
                        • 0 Attachment
                          Keith Braithwaite wrote:

                          snippet...

                          >Actually, that's not quite right. What I find is that there isn't any
                          >such thing as a "non-fuctional" requirement as distinct from a
                          >"functinal" one, so there isn't any difference to take into account.
                          >
                          >
                          >
                          Agreed - I've been stressing this very point just lately - we are team
                          that went from no process to full-on "Architect Driven, Req Spec,
                          Functional Spec, Use case Spec & plan driven" in one giant leap -
                          Thankfully we are now in the progress of tacking the problems that have
                          arisen by attempting to go agile (hence me being brought on board)

                          snippee


                          >
                          >Seems to me that a lot of the overblown, overengineered "enterprise"
                          >cobblers that a lot of teams are busy taking out of their systems so
                          >that they will be faster and support more users (using less system
                          >resources to do it), be easier to maintain etc. etc. were put in so as
                          >to (allegedly) deal with terribly abstract, very far forward looking,
                          >non-functional pseudo-requirements like "scalability". This probably
                          >has something to do with the dot.com business models that relied on
                          >huge increases in user volumes over short periods coming out of thin
                          >air to make even what little sense they did.
                          >
                          >
                          >
                          Another point I'll be having to 'address' - the notion that customers
                          will be mortified that we can't go from 10 concurrent users to 0000s
                          without any work - so far we 'have the (unproven) ability to do so'

                          >Are we in agreement?
                          >
                          >
                          >
                          with me you are ;-)

                          >Keith
                          >
                          >
                        • Steven Gordon
                          Suppose we have a customer who states that 95% of the time, all screens must return a result to users within 1.0 seconds. Can we just put this story on the
                          Message 12 of 26 , Oct 2, 2005
                          • 0 Attachment
                            Suppose we have a customer who states that 95% of the time, all screens must
                            return a result to users within 1.0 seconds. Can we just put this story on
                            the backlog, implement it in some iteration N, and be done with it? If so,
                            lets just implement it in iteration 1, when the cost would be really low,
                            and be done with it.
                            This is actually a meta-story (i.e., it applies to each and every story).
                            We have to build an acceptance test for this non-functional requirement for
                            each and every story we implement. It should not go on the backlog, because
                            it can never come off the backlog (because it continues to apply even after
                            we have statisfied it once).
                            Steven Gordon

                            On 10/2/05, Keith Braithwaite <Keith.Braithwaite@...> wrote:
                            >
                            > If we aren't disagreeing, then I definietely don't understand your
                            > point :)
                            >
                            > Seems to me that these "non-functional" stories absolutely must go on
                            > the backlog, otherwise we have no visibility of them. And when
                            > satisifed, they must come out of the backlog, otherwise we can't track.
                            >
                            > These things happen just fine with a "non-functional" story just like
                            > any other, I find.
                            >
                            > Actually, that's not quite right. What I find is that there isn't any
                            > such thing as a "non-fuctional" requirement as distinct from a
                            > "functinal" one, so there isn't any difference to take into account.
                            >
                            > In the world where specifications get written far ahead of the system
                            > being built far ahead of it being used it is very easy to be very
                            > definite about ludicrous performance targets, lets say. Or even worse,
                            > scalability (or other abstract qualities). Any claimed requirement
                            > with an "ility" in it is suspect, I'd say. But when the system is
                            > right there, all that's there working, with users banging on it, then
                            > it's very easy to be realistic and concrete.
                            >
                            > This much throughput, from this many users, on this hardware, or
                            > whatever, and we can write (stress) tests that gauge if this is has
                            > been met. And those tests can be run again in the future to tell us
                            > that the required level of throughput is still met as new
                            > functionality is added. And if, as the users gain experience with the
                            > system, or as new functionality brings heavier use. it is seen that
                            > the system needs to handle more throughput, a story can be written for
                            > that with suitable tests, as and when required. And so forth.
                            >
                            > Seems to me that a lot of the overblown, overengineered "enterprise"
                            > cobblers that a lot of teams are busy taking out of their systems so
                            > that they will be faster and support more users (using less system
                            > resources to do it), be easier to maintain etc. etc. were put in so as
                            > to (allegedly) deal with terribly abstract, very far forward looking,
                            > non-functional pseudo-requirements like "scalability". This probably
                            > has something to do with the dot.com <http://dot.com> business models that
                            > relied on
                            > huge increases in user volumes over short periods coming out of thin
                            > air to make even what little sense they did.
                            >
                            > Are we in agreement?
                            >
                            > Keith
                            >
                            >


                            [Non-text portions of this message have been removed]
                          • yahoogroups@jhrothjr.com
                            From: Steven Gordon To: extremeprogramming@yahoogroups.com
                            Message 13 of 26 , Oct 2, 2005
                            • 0 Attachment
                              From: "Steven Gordon" <sgordonphd.at.gmail.com@...>
                              To: "extremeprogramming@yahoogroups.com"
                              <extremeprogramming.at.yahoogroups.com@...>
                              Sent: Sunday, October 02, 2005 4:10 PM
                              Subject: Re: [XP] Non Functional Requirements And XP


                              > Suppose we have a customer who states that 95% of the time, all screens
                              > must
                              > return a result to users within 1.0 seconds. Can we just put this story on
                              > the backlog, implement it in some iteration N, and be done with it? If so,
                              > lets just implement it in iteration 1, when the cost would be really low,
                              > and be done with it.

                              > This is actually a meta-story (i.e., it applies to each and every story).
                              > We have to build an acceptance test for this non-functional requirement
                              > for
                              > each and every story we implement. It should not go on the backlog,
                              > because
                              > it can never come off the backlog (because it continues to apply even
                              > after
                              > we have statisfied it once).

                              I think I'm a bit puzzled.
                              This is what we've customarily called a "motherhood"
                              story, and each motherhood story has a tendency to
                              need to be handled differently.

                              If I saw it, I'd treat
                              it as a request for some form of realistic load test
                              (for some customer defined value of realistic), and
                              a measurement of response time, possibly with
                              an automated validation that the criterion passes,
                              and maybe some automated charts that go onto the
                              team Wiki, at least if I had a team member that could
                              do that kind of stuff quickly.

                              So I don't have to look at it for every story. What
                              I do have to do is make sure that the load test still
                              runs a representative load after every story (for some
                              customer or experiential value of representitive).
                              The requested performance measure can then take
                              care of itself.

                              > Steven Gordon
                              >
                              > On 10/2/05, Keith Braithwaite <Keith.Braithwaite@...> wrote:
                              >>
                              >> If we aren't disagreeing, then I definietely don't understand your
                              >> point :)
                              >>
                              >> Seems to me that these "non-functional" stories absolutely must go on
                              >> the backlog, otherwise we have no visibility of them. And when
                              >> satisifed, they must come out of the backlog, otherwise we can't track.
                              >>
                              >> These things happen just fine with a "non-functional" story just like
                              >> any other, I find.
                              >>
                              >> Actually, that's not quite right. What I find is that there isn't any
                              >> such thing as a "non-fuctional" requirement as distinct from a
                              >> "functinal" one, so there isn't any difference to take into account.
                              >>
                              >> In the world where specifications get written far ahead of the system
                              >> being built far ahead of it being used it is very easy to be very
                              >> definite about ludicrous performance targets, lets say. Or even worse,
                              >> scalability (or other abstract qualities). Any claimed requirement
                              >> with an "ility" in it is suspect, I'd say. But when the system is
                              >> right there, all that's there working, with users banging on it, then
                              >> it's very easy to be realistic and concrete.
                              >>
                              >> This much throughput, from this many users, on this hardware, or
                              >> whatever, and we can write (stress) tests that gauge if this is has
                              >> been met. And those tests can be run again in the future to tell us
                              >> that the required level of throughput is still met as new
                              >> functionality is added. And if, as the users gain experience with the
                              >> system, or as new functionality brings heavier use. it is seen that
                              >> the system needs to handle more throughput, a story can be written for
                              >> that with suitable tests, as and when required. And so forth.
                              >>
                              >> Seems to me that a lot of the overblown, overengineered "enterprise"
                              >> cobblers that a lot of teams are busy taking out of their systems so
                              >> that they will be faster and support more users (using less system
                              >> resources to do it), be easier to maintain etc. etc. were put in so as
                              >> to (allegedly) deal with terribly abstract, very far forward looking,
                              >> non-functional pseudo-requirements like "scalability". This probably
                              >> has something to do with the dot.com <http://dot.com> business models
                              >> that
                              >> relied on
                              >> huge increases in user volumes over short periods coming out of thin
                              >> air to make even what little sense they did.
                              >>
                              >> Are we in agreement?
                              >>
                              >> Keith
                              >>
                              >>
                              >
                              >
                              > [Non-text portions of this message have been removed]
                              >
                              >
                              >
                              > 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
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                            • Ron Jeffries
                              ... I m inclined to agree, Steven. And yet, I m not entirely comfortable with the notion of this NFR as a meta-story. Let me riff ... What if it s a standard
                              Message 14 of 26 , Oct 2, 2005
                              • 0 Attachment
                                On Sunday, October 2, 2005, at 6:10:04 PM, Steven Gordon wrote:

                                > Suppose we have a customer who states that 95% of the time, all screens must
                                > return a result to users within 1.0 seconds. Can we just put this story on
                                > the backlog, implement it in some iteration N, and be done with it? If so,
                                > lets just implement it in iteration 1, when the cost would be really low,
                                > and be done with it.
                                > This is actually a meta-story (i.e., it applies to each and every story).
                                > We have to build an acceptance test for this non-functional requirement for
                                > each and every story we implement. It should not go on the backlog, because
                                > it can never come off the backlog (because it continues to apply even after
                                > we have statisfied it once).

                                I'm inclined to agree, Steven. And yet, I'm not entirely comfortable
                                with the notion of this NFR as a meta-story. Let me riff ...

                                What if it's a standard task that often comes up, just like "add
                                fields to database" and "add widgets to screen"?

                                I wonder if there's a way to get the system to generate the timing
                                tests automatically? If there is ... then what happened to the NFR?

                                Ron Jeffries
                                www.XProgramming.com
                                Perhaps this Silver Bullet will tell you who I am ...
                              • Ken Boucher
                                ... ... Makes sense to me. It may have the effect of the cards that come after it may need higher estimates but that s normal enough. ...
                                Message 15 of 26 , Oct 2, 2005
                                • 0 Attachment
                                  --- In extremeprogramming@yahoogroups.com, Steven Gordon
                                  <sgordonphd@g...>
                                  wrote:
                                  > Suppose we have a customer who states that 95% of the time, all
                                  > screens must return a result to users within 1.0 seconds. Can we
                                  > just put this story on the backlog, implement it in some iteration
                                  > N, and be done with it? If so, lets just implement it in iteration
                                  > 1, when the cost would be really low, and be done with it.

                                  Makes sense to me. It may have the effect of the cards that come
                                  after it may need higher estimates but that's normal enough.

                                  > This is actually a meta-story (i.e., it applies to each and every
                                  > story). We have to build an acceptance test for this non-functional
                                  > requirement for each and every story we implement. It should not
                                  > go on the backlog, because it can never come off the backlog
                                  > (because it continues to apply even after we have statisfied it
                                  once).

                                  That last paragraph confuses me. Do you have anything that once
                                  you write the unit test for it doesn't need to continue to pass the
                                  unit tests whenever it's expanded? It seems to me that the test sounds
                                  a lot like:
                                  Top level screen class -> all subclasses do:
                                  <self should load screen in 1 second>.
                                  (Sorry, I tend to not write examples in any particular coding
                                  language).

                                  Once that test passes, take it off the backlog. Anything that causes
                                  that test to fail needs to be worked on before being released. How
                                  is this different from any other requirement?
                                • Steven Gordon
                                  ... The idea was that story A passing the response time test in iteration 1 does not necessarily imply that story Z in iteration 9 will pass the response time
                                  Message 16 of 26 , Oct 2, 2005
                                  • 0 Attachment
                                    On 10/2/05, Ken Boucher <yahoo@...> wrote:
                                    >
                                    > --- In extremeprogramming@yahoogroups.com, Steven Gordon
                                    > <sgordonphd@g...>
                                    > wrote:
                                    > > Suppose we have a customer who states that 95% of the time, all
                                    > > screens must return a result to users within 1.0 seconds. Can we
                                    > > just put this story on the backlog, implement it in some iteration
                                    > > N, and be done with it? If so, lets just implement it in iteration
                                    > > 1, when the cost would be really low, and be done with it.
                                    >
                                    > Makes sense to me. It may have the effect of the cards that come
                                    > after it may need higher estimates but that's normal enough.
                                    >
                                    > > This is actually a meta-story (i.e., it applies to each and every
                                    > > story). We have to build an acceptance test for this non-functional
                                    > > requirement for each and every story we implement. It should not
                                    > > go on the backlog, because it can never come off the backlog
                                    > > (because it continues to apply even after we have statisfied it
                                    > once).
                                    >
                                    > That last paragraph confuses me. Do you have anything that once
                                    > you write the unit test for it doesn't need to continue to pass the
                                    > unit tests whenever it's expanded?


                                    The idea was that story A passing the response time test in iteration 1 does
                                    not necessarily imply that story Z in iteration 9 will pass the response
                                    time test, even if Story A continues to pass this test.
                                    I suppose that under certain architectural assumptions, this might be
                                    unlikely (John's reference to just testing the "load" in a different email
                                    in this thread). If this assumption makes it hard to see my point, perhaps
                                    subsitituting security or localization for response time makes for a better
                                    example of how a NFS can affects each and every concrete user story.


                                    [Non-text portions of this message have been removed]
                                  • Ian Collins
                                    ... My last project had a number of these, things like update times, startup time and various other time constraints. These where tested exclusively in our
                                    Message 17 of 26 , Oct 2, 2005
                                    • 0 Attachment
                                      tasmisr wrote:

                                      >Hi Everyone,
                                      >I'm a XP newbie and I was doing some research about XP and how I can
                                      >apply at my work place. one of the questions that came to my attension
                                      >is How does the XP process model address the NFR(Non Functional
                                      >Requirements) ?
                                      >
                                      >
                                      >
                                      My last project had a number of these, things like update times, startup
                                      time and various other time constraints.

                                      These where tested exclusively in our acceptance test harness and
                                      generally ignored by the developers until one of the tests failed. We
                                      treated these constraints in the same was as an optimisation, not
                                      addressed until required.

                                      Ian
                                    • Keith Braithwaite
                                      ... better ... Well, we have very heavy localization needs, and the opposite happens. We have the exact same code deployed for web sites in with given
                                      Message 18 of 26 , Oct 3, 2005
                                      • 0 Attachment
                                        --- In extremeprogramming@yahoogroups.com, Steven Gordon
                                        <sgordonphd@g...> wrote:
                                        > On 10/2/05, Ken Boucher <yahoo@n...> wrote:
                                        >If this assumption makes it hard to see my point, perhaps
                                        > subsitituting security or localization for response time makes for a
                                        better
                                        > example of how a NFS can affects each and every concrete user story.

                                        Well, we have very heavy localization needs, and the opposite happens.

                                        We have the exact same code deployed for web sites in with given
                                        functionality, be they in English, French, Arabic, Thai, Mandarin,
                                        etc. etc. When a new site is deployed a resource bundle is created
                                        with the localised content (and by non-develoeprs at that), the locale
                                        is set in the deployment descriptors and it all just works. It just
                                        works because after the first few "functional" stories that required
                                        localisation were implemented the codebase ended up refactored to the
                                        point where localization is built in to everything.

                                        When a new kind of site is built, it's build within a codebase that
                                        assumes localisation, so a pair would have to do extra work to have
                                        their new functionality not exhibit localisation. What am I missing?

                                        Keith
                                      • tasmisr
                                        ... iteration 1 does ... response ... might be ... different email ... perhaps ... a better ... story. ... I agree one more time with Steven.. Also I agree
                                        Message 19 of 26 , Oct 3, 2005
                                        • 0 Attachment
                                          --- In extremeprogramming@yahoogroups.com, Steven Gordon
                                          > The idea was that story A passing the response time test in
                                          iteration 1 does
                                          > not necessarily imply that story Z in iteration 9 will pass the
                                          response
                                          > time test, even if Story A continues to pass this test.
                                          > I suppose that under certain architectural assumptions, this
                                          might be
                                          > unlikely (John's reference to just testing the "load" in a
                                          different email
                                          > in this thread). If this assumption makes it hard to see my point,
                                          perhaps
                                          > subsitituting security or localization for response time makes for
                                          a better
                                          > example of how a NFS can affects each and every concrete user
                                          story.
                                          >
                                          >
                                          > [Non-text portions of this message have been removed]

                                          I agree one more time with Steven..
                                          Also I agree with what Ken said, you can view the issue differently
                                          by applying the Top level concept: if a story is satisfied in the
                                          first unit test, it must still be satisfied in the next iterations.


                                          Overall, the point I understand now is that there is no way that you
                                          can consider a system wide requirement as a single user story.

                                          It apears to me that few steps must be considered at the very early
                                          stages of the planning phase of XP:

                                          1- Ask the customer which quality attributes(NFRs) they would like
                                          to have
                                          in the system, and what are the constraints.
                                          2- After defining user storeis, the quality attributes specified in
                                          step 1 (NFRs) should be distrebuted across all user stories as
                                          a "must have" in order to pass the iteration unit test.

                                          Don't you guys agree?
                                          If you do, Does the XP model address this in anyway? and if it
                                          doesn't, what shall be done?

                                          Tamer
                                        • J. B. Rainsberger
                                          ... If we have a test that runs through every page and every result and checks the response time and does the computation you describe, then yes, we can do it
                                          Message 20 of 26 , Oct 3, 2005
                                          • 0 Attachment
                                            Steven Gordon wrote:
                                            > Suppose we have a customer who states that 95% of the time, all screens must
                                            > return a result to users within 1.0 seconds. Can we just put this story on
                                            > the backlog, implement it in some iteration N, and be done with it? If so,
                                            > lets just implement it in iteration 1, when the cost would be really low,
                                            > and be done with it.

                                            If we have a test that runs through every page and every result and
                                            checks the response time and does the computation you describe, then
                                            yes, we can do it once and be done with it. All future work then has to
                                            pass this test, so each future story gets slightly more expensive
                                            because of this one response time test. We don't have to go back and do
                                            that story again--we simply follow the well-established rule that to be
                                            done, all Business Tests for that feature must pass.

                                            I would like to be on a project where the Customers actually followed
                                            through on their supposed concern about performance with requirements we
                                            can automate. Then I'd know whether the above works in practice.
                                            --
                                            J. B. (Joe) Rainsberger
                                            Diaspar Software Services
                                            http://www.diasparsoftware.com
                                            2005 Gordon Pask Award Winner for contribution to Agile practice
                                            Author, JUnit Recipes: Practical Methods for Programmer Testing
                                          • Steven Gordon
                                            When new functionality is added to the system, do you bother to test whether the new functionality works correctly in each supported language? If you do, then
                                            Message 21 of 26 , Oct 3, 2005
                                            • 0 Attachment
                                              When new functionality is added to the system, do you bother to test whether
                                              the new functionality works correctly in each supported language? If you do,
                                              then the localization NFS is still in effect, even though it was supposedly
                                              finished and taken off the backlog long ago.
                                              If a story about site administration came up that only required an English
                                              UI, would implementing it somehow magically produce the same UI in French,
                                              Arabic, Thai, Mandarin, etc? If not, then you must be consciously applying
                                              the localization NFS to any new functionality that does require its UI to be
                                              in all supported languages.
                                              The localization requirement will still be an active consideration for
                                              every new enhancement as long as the system is in maintenance.

                                              On 10/3/05, Keith Braithwaite <Keith.Braithwaite@...> wrote:
                                              >
                                              > --- In extremeprogramming@yahoogroups.com, Steven Gordon
                                              > <sgordonphd@g...> wrote:
                                              > > On 10/2/05, Ken Boucher <yahoo@n...> wrote:
                                              > >If this assumption makes it hard to see my point, perhaps
                                              > > subsitituting security or localization for response time makes for a
                                              > better
                                              > > example of how a NFS can affects each and every concrete user story.
                                              >
                                              > Well, we have very heavy localization needs, and the opposite happens.
                                              >
                                              > We have the exact same code deployed for web sites in with given
                                              > functionality, be they in English, French, Arabic, Thai, Mandarin,
                                              > etc. etc. When a new site is deployed a resource bundle is created
                                              > with the localised content (and by non-develoeprs at that), the locale
                                              > is set in the deployment descriptors and it all just works. It just
                                              > works because after the first few "functional" stories that required
                                              > localisation were implemented the codebase ended up refactored to the
                                              > point where localization is built in to everything.
                                              >
                                              > When a new kind of site is built, it's build within a codebase that
                                              > assumes localisation, so a pair would have to do extra work to have
                                              > their new functionality not exhibit localisation. What am I missing?
                                              >
                                              > Keith
                                              >


                                              [Non-text portions of this message have been removed]
                                            • Keith Braithwaite
                                              ... whether ... Well, no. Two part answer: there isn t really any way for the new functionality not to work in any language we care to support it in without
                                              Message 22 of 26 , Oct 3, 2005
                                              • 0 Attachment
                                                --- In extremeprogramming@yahoogroups.com, Steven Gordon
                                                <sgordonphd@g...> wrote:
                                                > When new functionality is added to the system, do you bother to test
                                                whether
                                                > the new functionality works correctly in each supported language?
                                                Well, no. Two part answer: there isn't really any way for the new
                                                functionality not to work in any language we care to support it in
                                                without deliberate effort, since out production codebase doesn't
                                                really offer any way to get text onto a web page without going through
                                                a localized resource bundle that your pair would let you get away
                                                with. Also, in our case new functionality (first of availability)
                                                tends to be quite specific to a customer, usually with a few given
                                                languages. If we're adding a feature for ElboniaTelecom, say, it will
                                                be built in English (since that's the common language of all our
                                                developers) and tested in Elbonian. Why would we test it in
                                                Flatlandish any time before we made the feature GA and managed to sell
                                                it to HexaNet?

                                                > If you do,
                                                > then the localization NFS is still in effect,
                                                Since we don't, then it isn't? Except that we slightly do, so maybe it
                                                is a bit?


                                                > If a story about site administration came up that only required an
                                                English
                                                > UI, would implementing it somehow magically produce the same UI in
                                                French,
                                                > Arabic, Thai, Mandarin, etc?
                                                Not quite. But once it was deployed in English then producing Arabic,
                                                Thai and Mandarin versions would be as easy as emailing the English
                                                resource bundle to our translation house and then dropping their reply
                                                into the build.

                                                > If not, then you must be consciously applying
                                                > the localization NFS to any new functionality that does require its
                                                UI to be
                                                > in all supported languages.
                                                Depending on how strict you want to be, either no it doesn't (so we
                                                are?), or yes it does (so we aren't?).

                                                > The localization requirement will still be an active consideration for
                                                > every new enhancement as long as the system is in maintenance.
                                                The localization mechanism is an inescapable constraint on every new
                                                enhancement, and has to be taken into account in building that
                                                enhancement, yes. But this causes very little variation in effort
                                                estimates (although cost estimates are effected by the translation
                                                fee). And none at all on elapsed time to deliver. We only built the
                                                localization subsystem once, and it sees very little maintainance in
                                                itself.

                                                It really does seem to me that in our process this
                                                functional/non-functional distinction is so blurred as to be near
                                                meaningless. YMMV.

                                                Keith
                                              • Dale Emery
                                                Hi Ravi, ... If you want to learn more about the idea of perfect technology, read McMenamin and Palmer s terrific, classic book Essential Systems Analysis.
                                                Message 23 of 26 , Oct 5, 2005
                                                • 0 Attachment
                                                  Hi Ravi,

                                                  > Awesome! I will, in future, use this to explain the difference
                                                  > to people. Very insightful.

                                                  If you want to learn more about the idea of perfect technology,
                                                  read McMenamin and Palmer's terrific, classic book Essential
                                                  Systems Analysis. Don't let the Data Flow Diagrams scare you
                                                  into thinking the book is outdated. I recommend it highly.

                                                  Dale

                                                  --
                                                  Dale Emery, Consultant
                                                  Inspiring Leadership for Software People
                                                  Web: http://www.dhemery.com
                                                  Weblog: http://www.dhemery.com/cwd
                                                • Dale Emery
                                                  Hi Ben, ... I don t have enough experience with XP s requirements practices to give an informed answer. Dale -- Dale Emery, Consultant Inspiring Leadership for
                                                  Message 24 of 26 , Oct 5, 2005
                                                  • 0 Attachment
                                                    Hi Ben,

                                                    >> "Functional" requirements are the requirements we would
                                                    >> specify even if we knew the software would be implemented
                                                    >> with perfect technology.
                                                    >>
                                                    >> "Non-functional" requirements (I prefer the term "quality
                                                    >> attributes") are those requirements we specify because we
                                                    >> know that real technology is imperfect.
                                                    >
                                                    > Why do you think that XP might need to handle these
                                                    > differently?

                                                    I don't have enough experience with XP's requirements practices
                                                    to give an informed answer.

                                                    Dale

                                                    --
                                                    Dale Emery, Consultant
                                                    Inspiring Leadership for Software People
                                                    Web: http://www.dhemery.com
                                                    Weblog: http://www.dhemery.com/cwd
                                                  • Dale Emery
                                                    Hi Tamer, ... I wholeheartedly agree. I think it s important to have a conversation very early about quality attributes. My theory is that quality attributes
                                                    Message 25 of 26 , Oct 5, 2005
                                                    • 0 Attachment
                                                      Hi Tamer,

                                                      > It apears to me that few steps must be considered at the very
                                                      > early stages of the planning phase of XP:
                                                      >
                                                      > 1- Ask the customer which quality attributes(NFRs) they would
                                                      > like to have in the system, and what are the constraints.

                                                      I wholeheartedly agree. I think it's important to have a
                                                      conversation very early about quality attributes. My theory is
                                                      that quality attributes are almost always the primary motivation
                                                      for selecting software rather than some other technology to carry
                                                      out organizational goals (and other goals, such as entertainment).

                                                      Applying the Fantasy of Perfect Technology tells us the essence
                                                      of the system: those responsibilities we would want the system
                                                      to fulfill regardless of the technology we use to implement the
                                                      system. Once we've defined the essence, we drop the fantasy,
                                                      remember (alas!) that real-world technology is imperfect, and use
                                                      quality attributes to determine which technologies to use to
                                                      implement that essence. If software is faster or more reliable
                                                      or more available than other available technologies, we use
                                                      software. If not, we use some other technology (such as lined
                                                      white index cards).

                                                      Essence tells us why we need a system. Quality attributes tell
                                                      us why we need the system to be software.

                                                      > 2- After defining user storeis, the quality attributes
                                                      > specified in step 1 (NFRs) should be distrebuted across all
                                                      > user stories as a "must have" in order to pass the iteration
                                                      > unit test.

                                                      I like the gist of this. I would relax the "all user stories"
                                                      part. Many quality attributes distribute to some subset of all
                                                      user stories. For example, response time is more important for
                                                      some functions than others, and the specific required response
                                                      times differ from function to function. So I would reword
                                                      something like: Distribute the quality attributes to the
                                                      appropriate stories, identifying the constraints that each story
                                                      must satisfy for each of its quality attributes.

                                                      I think that some quality attributes might apply to some other
                                                      unit than a story. For example, memory footprint. If you had a
                                                      constraint for the system's memory usage, to what units would you
                                                      distribute this memory? Classes? Modules? It isn't clear to me
                                                      that you'd allocate memory to individual stories (though I'll
                                                      happily defer to people who are living with real memory constraints).

                                                      Finally, I would loosen the step-wise-ness: Whenever you think
                                                      of a story, consider what quality attributes are important to
                                                      specify. Whenever you think of a quality attribute, consider
                                                      what stories it applies to.

                                                      I really like your emphasis on quality attributes.

                                                      Dale

                                                      --
                                                      Dale Emery, Consultant
                                                      Inspiring Leadership for Software People
                                                      Web: http://www.dhemery.com
                                                      Weblog: http://www.dhemery.com/cwd
                                                    Your message has been successfully submitted and would be delivered to recipients shortly.