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.
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.
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.
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.