...you are trying to gather requirements necessary for specifying a system, but some received requirements are design decisions that come from the stakeholder. You want to build a flexible system
* * *
A project must question requirements and differentiate between design decisions suggested by the customer and the underlying problem that the customer’s solution is trying to solve.
You need requirements, and the requirements providers are pleased to give you requirements. Yet they are not experts in providing requirements suitable for specifying flexible systems. This skill belongs to the Systems Analyst or equivalent role.
It is common for the requirements providers to try and be helpful and suggest a solution to the problem. More common is the description of the requirement in terms of the solution they currently use.
Commonly, the problem to be solved is relatively invariant; workers in the domain have needed to find solutions for many years, often centuries. These solutions change, yet the problem remains the same.
A system that tackles the underlying problem is more likely to be flexible than one that slavishly implements the current solution.
Enquire into the reasons for each requested feature.
Drill down into the problem that the stakeholder is trying to solve with his required feature.
There will be some level at which each requirement can be expressed that has meaning in the business context and in the system context, whereby the requirement is describing the problem to be solved, and not the solution.
* * *
The requirement is too generic and doesn’t describe the problem in the problem domain, it describes the motivations for setting up in business.
Q: Why do you work?
A: To earn money.
Q: Why do you want money?
A: To buy a house.
Q: Why do you want to own a house?
A: To have a feeling of security.
Q: Why do you want to feel secure?
A: So I don’t worry.
Q: Why do you want not to worry?
A: So I can feel happy.
Q: Why do you want to feel happy?
A: I don’t know, you’ve got me there. I just do.
Clearly, asking “why?” Can be taken too far. It also needs to be done diplomatically.
The title of this pattern arrived after an OTUG exchange between H.S. Lahman and Paul Oldfield. The underlying idea of the pattern is thought to come from early Chinese philosophy, but the “5 times” is a Japanese addition from the ‘60s or thereabouts.