In the Second Edition of the eXtreme Programming Explained, Kent Beck writes:
“Software development has been steered wrong by the word ‘requirement’ defined in the dictionary as something mandatory or obligatory. The word carries a connotation of absolutism and permanence – inhibitors to embracing change. And, the word ‘requirement’ is just plain wrong.”
On his blog, Jeff Patton tries to explain why using the word requirement is plain wrong:
- When faced with challenges or in pursuit of a goal we decide on a course of action
- The software we eventually build is the compounding of a great number of decisions
- “Requirement” is a label we put on our decisions
- Decisions and requirements build on each other
- Giving requirements stops collaboration
- Asking for requirements avoids responsibility
- Requirements come from outside, not inside
- Stop using that word and start collaborating to solve problems
There are great points. In addition I feel:
Typically requirements for given business problem is derived based on some hypothesis. In today’s dynamic world, where Change is the only constant, those hypothesis can change. So instead of holding on to the by-product of the hypothesis, why not focus on the real business problem that we are trying to solve.
Requirements belongs to the solution domain. Since, there are multiple ways to solve any problem. Prematurely deciding on any one solution does not seem like a good idea. We need to spend time in the problem domain to actually come up with the closest solution.
The word requirements comes from a Target driven planning approach. Target Driven Planning has huge drawbacks that Agile methods try to avoid. Instead they focus on value driven planning.
When ever I hear about Business Analysis capturing the requirements, it reminds me of waiters in a restaurant. In most restaurant, you have a menu to select from, a waiter who will take your order (requirement) and pass it on to the chef (developers). I don’t mean to look down upon Business Analysts or Waiters.
What I’m trying to highlight is, in my experience, the BAs I’ve worked with, pretty much capture what the customer wants in form of requirements. But there is no rationale behind what is the real problem that we are trying to solve. Even if that is understand by the BA, its not communicated to everyone on the team. Do we even need some software for it? Critical questions seems to be missed out.
Also going back to the analogy, I think the analogy is flawed. In software, customers don’t get a menu. Even if they get a menu its in a language they don’t understand and to make matters worst the restaurant is serving a cuisine that the customers have no clue about. How can one possible order stuff without actually having a conversion around what kind of an appetite they have, whether they are in a hurry or not, if they like spicy food or not and so on.