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

Re: [XP] Non Functional Requirements And XP

Expand Messages
  • Ravi Mohan
    Dale, ... Awesome! I will, in future, use this to explain the difference to people. Very insightful. Thanks ! Ravi
    Message 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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.