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

Re: [XP] Non Functional Requirements And XP

Expand Messages
  • BenAveling
    ... Why do you think that XP might need to handle these differently? Regards, Ben
    Message 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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.