Every requirement that lands on a solution architect's desk arrives wearing a disguise. Someone has already decided what they want, translated it into a feature, and handed you the feature. The job is to gently take the disguise off and find out what the organisation actually needs underneath it — because the two are very often not the same thing.

I wrote a whole chapter on this in the Microsoft Power Platform Solutions Architect's Handbook, because getting it wrong is one of the most expensive mistakes a programme can make. Build exactly what you were asked for, and you can still deliver something that solves the wrong problem.

The perceived need vs the real need

Here is the example I use in the book, lightly retold. A manager asks for a feature: every month, export an Excel file of customer invoices. Simple enough — you could build that in an afternoon.

But ask who needs it, and it turns out it is not the manager — it is the customer service team. Ask what they do with it, and they filter the list down to one type of customer and import it into the finance system. Ask why, and the finance team uses it to chase a specific class of overdue invoice. Ask why again, and the board uses the same data to project cash flow at its monthly meeting.

The “Excel export” was never the requirement. The requirement was a reliable monthly view of a particular category of receivables, in front of the right people, at the right time. Once you can see that, the Excel file is just one possible implementation — and probably not the best one. A manual export, filtered by hand and re-imported into another system, is a fragile chain of steps that could be a single automated process.

Keep asking “why” until you reach the business

The technique is not complicated. For every requirement, work through four questions: who needs this, what do they need from it, why do they need it, and when do they need it. The “why” is the one that does the work. You keep asking it — politely — until you stop hearing about features and start hearing about how the business actually runs.

That word “politely” matters. Asking someone “why do you need this?” repeatedly can sound like you are questioning their judgement. It isn't, and they need to know it isn't. I always explain up front that the questions exist to help me design the best possible solution for them — which may well turn out to be something they hadn't pictured. Framed that way, people open up rather than dig in.

Functional, non-functional, and the things nobody mentions

Functional requirements — what the system should do — tend to surface naturally once you are asking the right questions. Non-functional requirements rarely do. Nobody walks into a workshop wanting to talk about uptime, recovery time, data retention, or how many concurrent users the portal needs to hold. But those constraints decide whether the solution survives in production, so part of the discipline is deliberately drawing them out and writing them down as something measurable. “The portal should be fast” is not a requirement. “The portal should load in under three seconds on the top three browsers” is.

The other thing worth chasing is the exception path. Every process has a happy path that everyone describes, and a set of edge cases that happen occasionally and that nobody mentions until they break. You don't design the whole solution around the exceptions — but you do need to know they exist before you commit to a design, not after.

Why this is the foundation everything else sits on

Requirements capture is not paperwork you do before the real work starts. It is the real work. Every design decision, every estimate, every fit-gap call downstream is only as good as the understanding underneath it. Get to the real need, and the rest of the programme has something solid to stand on. Build on the perceived need, and you can do everything else right and still miss.

This post is adapted from the requirements analysis chapter of my book, the Microsoft Power Platform Solutions Architect's Handbook (Packt, 2nd edition). If you are scoping a Dynamics 365 or Power Platform programme and want a second opinion on whether the requirements are pointing at the real problem, that is a conversation worth having early.