The Art of the Requirements Interview: Turning "I Want a System" Into a Spec

After a decade-plus of building systems, the opening line we hear most is: "I want a system." Ask one question deeper — "what problem should this system solve?" — and about half of business owners freeze. That's not their fault. When you're soaked in your own operations every day, pain points exist as feelings, not as specifications. The requirements interview exists to translate those feelings into something engineers can build from. Translate well and the project flows; translate badly and you discover the mistake only after it's built — painful for everyone.

The client asks for A, but needs B

Here's a pattern we run into repeatedly. The owner says: "I want a reporting feature that emails me an Excel file every day." Build exactly that, and two weeks later you have a daily email nobody opens. A few more questions reveal the real pain: "I don't find out a branch's inventory is off until month-end, when it's too late to fix." What he actually needs isn't a report — it's an anomaly alert that fires the same day an inventory number looks wrong, instead of a daily spreadsheet he has to scan by eye.

That's the core interviewing skill: clients usually describe a "solution"; your job is to dig backward to the "problem." The solution is something the owner assembled from their limited technical imagination; the problem is what's actually real. The most useful digging question we know: "If this feature existed today, what would be different about your work tomorrow?" A feature that can't produce a concrete answer is, nine times out of ten, an imagined requirement.

The question categories we always cover

We operate an inventory and order-management SaaS that supports the daily operations of physical franchise stores, so we know firsthand that "how the floor actually works" and "how the boss thinks the floor works" are often two different things. Don't interview only the boss — interview the people who actually operate. These categories are our standing menu:

• Current process: How is this done today? With what tools? How many times a day? By whom? — Not "what do you want," but "how do you survive right now."
• Exceptions: When does it go wrong? How is it fixed when it does? — Exception handling often accounts for half the development effort, and it's the part most often left out.
• Scale: How many transactions a day? How many concurrent users? How many years of data retention? — Scale determines architecture; ten records and a hundred thousand records are two different systems.
• The picture of success: Three months after launch, how will you judge whether the money was well spent? — This forces both sides to align on "what success looks like" before work begins.

The goal of a requirements interview isn't to write down everything the client says — it's to find the thing the client never said, without which nobody will use the system.

Three moves that turn an interview into a spec

An interview can't end as just meeting notes. Our practice is three moves. First, draw the flow — map the main process like "order in, through to shipment" and take it back to the owner; wrong parts jump out at a glance, ten times faster than reading text. Second, list the fields — for every screen, what's displayed and what's entered, one by one. It's the most tedious step, but small questions like "do products need an expiry-date field?" cost five minutes to settle now versus a database migration after launch. Third, tag priorities — split features into "can't launch without" and "later." This directly shapes the quote and the timeline, and it's the foundation for carving out a first-version scope.

One more honest piece of advice: dare to say "we don't recommend building this" at the interview stage. We've talked clients out of plenty of features — not because we couldn't build them, but because nobody would use them, or a cheaper solution existed (sometimes a well-designed Excel template solves it; no code required). A team willing to debate requirements with you at the interview stage is usually more reliable than a team that only nods.

How owners can prepare

If you're about to talk to a team about a system, three preparations make the process far more efficient: photograph or screenshot your current workflow (Excel sheets, LINE conversations, paper slips — anything); identify the two or three steps that go wrong or eat time most often; and get clear on your budget's order of magnitude. You don't need to write a spec — that's our job — but bringing the full "current state" makes one interview worth three.

A solid requirements interview is what gives the subsequent spec document, quote, and timeline their footing. If you're carrying an "I want a system" idea and aren't sure where to start untangling it, talk to us — the first conversation is free, and we'll start by helping you ask the right questions.