Business Analysis Notes

Basics

The "Why? What? How?" Principle

4 min read · Updated

In short When you gather requirements, the question that matters most is “Why is this needed?”, not “What should it do?” and certainly not “How should it work?”. Getting to the why turns a requested solution into a requirement that designers can solve well and testers can check.

Based on: Yu. Khimonin, Collecting and Analyzing Software Product Requirements (in Russian), v1.03, 2009; D. Paul, D. Yeates, J. Cadle (eds.), Business Analysis (BCS), 2nd ed., ch. 12.

On this page

Key ideas#

The main mistake in gathering requirements#

Khimonin argues that the most common error is to build a picture of the product from answers to “What should the product do?” or, worse, “How should it work?”. Those answers describe solutions. The purpose of elicitation is to find out why the product is needed. The one question an analyst should keep asking, of themselves and of the customer, is “Why?”.

Solutions are a symptom#

When a stakeholder says “we need three wizards” or “use this color scheme”, they are describing a solution or an implementation detail. Khimonin treats this as a sign that the real need has not been uncovered yet. If you build what was asked, you risk a flawed design: missing functions, platform limits nobody considered, or other users whose interests were ignored.

From request to requirement#

Khimonin gives an example along these lines. A user asks for autocomplete on the “last name” field. That answers “what”. The analyst asks why. The answer: operators need to enter customer personal data as quickly as possible. That is the real requirement: speed up entry of customer personal data by operators. Autocomplete becomes one possible way to do it, alongside others.

Two teams benefit. Designers now know the goal, not a ready-made (and maybe not the best) solution. Testers get a criterion they can check: is data entry actually faster?

In terms of the core concept model#

In the language of the BACCM, asking “why?” moves you from a proposed solution back to the need and the value behind it. Jumping straight to “what” or “how” means choosing a solution before the need is understood.

How to apply it#

  1. Listen for solution words. “Button”, “dropdown”, “app”, “report”, “integrate with”, “like system X”. Each one is a cue to ask why.
  2. Ask “why” without sounding hostile. Useful phrasings: “What will that help you do?”, “What happens today without it?”, “How will you know it is working?”
  3. Keep going until you reach a business outcome. Usually two or three rounds are enough. Stop when the answer is a goal the business would recognize: time, money, risk, customer satisfaction, compliance. For a deeper chain, use root cause analysis.
  4. Write the requirement in terms of the need. State the outcome and, if possible, how it will be measured. Keep the original request as a design option, linked to the requirement.
  5. Look for other options. Once the need is clear, list at least two ways to meet it. If only one solution fits, check whether you have really reached the need.
  6. Respect real constraints. Sometimes the “how” is a genuine constraint (an existing platform, a regulation, a contract). Record it as a constraint, with its reason, not as a requirement.

When you are selecting an off-the-shelf package, the BCS book makes a related point: requirements should focus on what is needed rather than how it must work, unless the “how” is critical to competitive advantage, and the organization should be ready to adapt its processes to what the package does well.

Example#

A workshop manager at The Workshop, a fictional chain of 12 bike-repair workshops, asks: “Add a dropdown with all 200 spare parts to the job card.”

  • Why? “So mechanics record which parts they used.”
  • Why does that matter? “Because at the moment they forget, the stock count is wrong, and we reorder too late.”
  • What happens then? “Repairs wait two or three days for parts, and customers call to complain.”

The requirement becomes: parts used on each repair are recorded reliably at the time of the repair, so that reorders happen before stock runs out. Success measure: fewer repairs delayed by missing parts.

Now there are several design options: the dropdown, barcode scanning, a short list of the 20 most-used parts with search for the rest, or a weekly stock count. When the analyst shows these to mechanics, scanning wins. The dropdown would have met the request and missed the need.

Pitfalls#

  • Asking “why” like an interrogation. Repeated bare “why?” can feel like a challenge. Vary the wording and explain that you want to get the best solution for them.
  • Never stopping. Past the business goal, “why” turns philosophical. Stop at an outcome the sponsor would sign.
  • Discarding the original idea. The stakeholder’s solution may be a good one. Keep it as an option; just do not treat it as the requirement.
  • Ignoring constraints. Not every “how” is a premature solution. Some are fixed by law, budget or existing systems.

Sources and further reading#

  • Yu. Khimonin. Collecting and Analyzing Software Product Requirements (in Russian), v1.03, 2009.
  • D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010. Ch. 12 (requirements for off-the-shelf packages).