The consultation as a requirements-gathering technique

Patient consultations taught me requirements gathering before I ever wrote a ticket. The training is identical: what someone first says is the start of the inquiry, not the end of it.

The consultation method

The presenting complaint is not the diagnosis. A patient says "headache." The trained question isn't "which painkiller?" — it's the follow-up chain: since when, where exactly, what makes it worse, what else changed. In software, "we need a dashboard" gets a dashboard from the untrained. From the trained: what decision will this dashboard change? What did you do before? What will you stop doing if it exists?

History beats hypothesis. Pharmacists ask what's been tried. Half the time the answer reveals the real constraint: "we tried a spreadsheet but Ada is the only one who understood it" — that's not a data problem, that's a succession problem, and no tool fixes it alone.

Red flags stop the sale. Consultation training teaches when NOT to proceed — symptoms that mean escalate, not treat. Engineering equivalents: stakeholders who can't name a user, projects where the "requirement" is a solution in costume. Recognising red flags is knowing when requirements gathering has failed before development begins.

Why it transfers perfectly

Both disciplines face the same hazard: experts who answer the question asked instead of the problem present. The consultation trained me to keep asking until the problem stands still long enough to be built for — and to know the difference between what people say they want and what their behaviour shows they need.