In this article posted recently to AgileAlliance.org, the author compares XP-style requirements gathering with so-called “rigorous” requirements gathering. After comparing the two, he presents some interesting conclusions. The one that caught my eye was his assertion that “XP requirements techniques will work for you (only if) you’re building a new system, you’ve gotten to the 5-foot level, and the customer is starting to tell user stories.”
This is followed up with “XP requirements techniques will not work for you (when) the system is ill-defined, and the objectives need to be understood at this point.”
This bugs me. The author has obviously never actually participated on a well-run XP project. In my experience, XP requirements techniques are best used when the system is “ill-defined and the objectives need to be understood at this point.” With my customers, it is quite common for them to have a difficult time understanding “requirements”. Instead they just want to tell stories about how people will use the system. This is exactly what we want in XP. We want user stories that the developers can use to gain a better understanding of the problem. If after further discussion the user story needs to be replaced with one or more clearer stories, then that is a Good Thing.
Another thing I didn’t really like about this article was the statement, “The system is very complex, and any apparently simple change can cause many other segments of the system to change.” If the application design has this problem, then a significant redesign is in order.