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

Re: [XP] Non Functional Requirements And XP

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