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

Re: [XP] Non Functional Requirements And XP

Expand Messages
  • 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 1 of 26 , Oct 2, 2005
      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 2 of 26 , Oct 2, 2005
        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 3 of 26 , Oct 2, 2005
          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 4 of 26 , Oct 2, 2005
            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 5 of 26 , Oct 2, 2005
              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 6 of 26 , Oct 2, 2005
                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 7 of 26 , Oct 2, 2005
                  --- 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 8 of 26 , Oct 2, 2005
                    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 9 of 26 , Oct 2, 2005
                      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 10 of 26 , Oct 2, 2005
                        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 11 of 26 , Oct 2, 2005
                          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 12 of 26 , Oct 2, 2005
                            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 13 of 26 , Oct 2, 2005
                              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 14 of 26 , Oct 2, 2005
                                --- 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 15 of 26 , Oct 2, 2005
                                  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 16 of 26 , Oct 2, 2005
                                    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 17 of 26 , Oct 3, 2005
                                      --- 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 18 of 26 , Oct 3, 2005
                                        --- 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 19 of 26 , Oct 3, 2005
                                          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 20 of 26 , Oct 3, 2005
                                            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 21 of 26 , Oct 3, 2005
                                              --- 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 22 of 26 , Oct 5, 2005
                                                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 23 of 26 , Oct 5, 2005
                                                  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 24 of 26 , Oct 5, 2005
                                                    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.