Business Analysts often start with four erroneous assumptions when eliciting requirements. 50% of errors in software projects are caused by requirements errors. These four faulty assumptions, presented by James A. Ward, can exacerbate the error-prone process of gathering requirements.
The Assumptions
In his article on stickyminds.com, James points out that analysts tend to fall in one of two camps – those who make these assumptions and those who don’t. The course of action an analyst takes when gathering requirements is driven by these assumptions. From James’ article, they are:
- Customers can define their systems requirements.
- The software development organization is a “customer”–not the “owner” of the process.
- Requirements management starts after requirements have been defined.
- The customer “owns” the requirements.
Our Analysis
While agile principles aren’t generally founded on these assumptions, some types of agile processes do appear to be built on them. Kent Beck, author of extreme programming (xp), argues that customers don’t know their requirements. Feature-driven development (FDD) is agnostic about this point.
Beck’s argument is that because customer’s don’t know what they want, we should start building stuff right away, with the expectation that by seeing tangible results (good or bad), they will have epiphanies about what they really do want. This approach treats requirement extraction as an emergent process, like strip-mining. With each new layer of mining, we unearth a new set of hidden requirements.
While this approach has strengths, it also has weaknesses. Those weaknesses are caused by the assumption that the requirements can not be identified up front.
This reminds us of the old Thomas Edison response to a reporter asking about his 700 failed attempts at creating an electric light:
“I have not failed seven hundred times. I have not failed once. I have succeeded in proving that those seven hundred ways will not work. When I have eliminated the ways that will not work, I will find the way that will work.â€
Alan Cooper’s argument is that with proper analysis, more accurate requirements can be discovered. This approach is much more like exploratory drilling and surveying than strip-mining. By leveraging different requirements gathering techniques with business process modeling and analysis, a business analyst can discover and invent the appropriate requirements to satisfy market needs.
Conclusion
We accept the premise that customers can rarely articulate their requirements in sufficient detail to develop a software solution. Their areas of expertise are their businesses, not software development. We do not believe the customer should be responsible for developing those requirements. We believe that the requirements can be identified before delivering something to the customer. We like the ideas proposed by James Shore a while ago about moving from the general to the specific.
This belief that requirements do exist, and can be identified should be combined with an incremental delivery process that focuses efforts on the most important requirements first. This results in faster delivery of value.
A couple of characterizations of Beck’s XP that are open to misinterpretation:
“Beck’s argument is that because customer’s don’t know what they want, we should start building stuff right away [emphasis added], with the expectation that by seeing tangible results (good or bad), they will have epiphanies about what they really do want.”
While Beck does favor building the system early and often, he doesn’t favor building it “right away”. A “planning game” and initial set of user stories come first.
“While this approach has strengths, it also has weaknesses. Those weaknesses are caused by the assumption that the requirements can not be identified up front.”
Beck favors specifying requirements up front, just not to a high level of detail. His assumption is that noone can know all of the requirements up front, and that some of the ones you think you know will change.
Your comparison to strip-mining nicely captures things:
“This approach treats requirement extraction as an emergent process, like strip-mining. With each new layer of mining, we unearth a new set of hidden requirements.”
Roger,
Thanks for reading and commenting!
In the debate between Beck and Cooper, if I recall correctly, Beck was in favor of days of upfront analysis, in contrast with Cooper who felt like weeks of big upfront design would be required for a large project. While a couple days isn’t “none”, it is comparatively miniscule.
The challenge is to understand enough of the domain to know which of the handfull of initial requirements is actually the most valuable. That’s where I tend to like the FDD approach versus XP.
In keeping with the mining analogy, think of it as a detailed survey in advance of strip mining, to increase the likelihood of finding the most valuable requirements when the digging begins.
Okay, but I would just be careful about creating the impression that XP or any other form of agile development calls for no up-front requirements. All of them call for up-front requirements; the differences are a matter of degree.