Edmund Schweppe wrote:
> Ilja Preuss wrote:
> > Actually I'd
>> think that having to "make a change" invariably had to be a reaction
>> to a "defect in the requirements" for him. At least that's the only
>> way I can imagine introducing a "bug" in the "analysis phase" at
> I can imagine two scenarios:
> 1) When I'm initially gathering requirements from you, you tell me
> that the app needs to display information in both English and German.
> I misunderstand you (or lose my notes) and deliver an English-only
> app. That would be a "requirements bug".
> 2) When I'm initially gathering requirements from you, you tell me
> that the app needs to display information in English. I deliver an
> English-only app; then you tell me that you also need the app to
> display information in German. (For instance, you might have been
> building a payroll system for an American automotive manufacturer who
> subsequently was purchased by a German one :-) That, to me, is a
> change that's not due to a bug in the requirements; instead, it's due
> to a change in the environment.
Yes - though I think in a waterfallish environment it could be seen as a
bug, too. You simply didn't do enough analysis upfront - else you should
have known that you could need a different language version in the
future. Because you didn't, you have to restart the whole development
To an agile team, of course, *both* scenarios just result in another
feature to be added incrementally. That's why I think that "requirement
bugs" aren't that important in agile development.