Before You Build Anything: The Discipline of Requirements Elicitation

Most expensive rework comes from the same place: building the wrong thing well. The discipline that prevents it is requirements elicitation, the structured process of drawing out what people actually need before anything gets built. It is a settled practice in software and business analysis, and it applies whether the work is AI-assisted or done entirely by hand.

Five questions to answer first

Before you start any project, answer these five. If you cannot, you are not ready to build.

• What problem exists today, and who feels it? Name the actual pain and the person who has it. "We want an app" is not a problem. "Clients call to ask the same three questions and it eats an hour a day" is.
• Who is this for? One primary audience. Work built for everyone tends to serve no one well.
• What does success look like, in one sentence? If you cannot state the outcome in a sentence, the scope is still fuzzy. "A client can get those three answers without calling" is a sentence you can build toward.
• What must not change? The constraints: the budget, the tools you are keeping, the rules you cannot break, the things that already work and must keep working.
• What is the risk if this goes wrong? Naming the failure mode up front tells you how much care the work needs and where to put a checkpoint.

Why skipping this is the leading cause of rework

When a project is scoped loosely, everyone fills the gaps with their own assumptions, and the assumptions do not match. The build proceeds, looks fine, and then the moment it meets reality the mismatch surfaces, usually after the expensive part is done. The cost of asking the five questions is an hour. The cost of not asking them is the rebuild.

A one-page template

You do not need a formal document. A single page with five headings does the job:

Problem (and who has it):
Audience (one primary):
Success (one sentence):
Constraints (what must not change):
Risk (what happens if this is wrong):

Fill it out before you write a prompt, hire help, or open a tool. If a section is blank, that is the conversation to have next.

This holds for AI work too

It is tempting to think AI lets you skip the scoping and just try things. It does not. An AI system will happily build the wrong thing quickly. The five questions are how you point it at the right thing first, so the speed is spent in the right direction. When the work involves automation, decide at this stage where a person will review the result before it is trusted.

Where this leaves you

Requirements elicitation sounds formal, but it is really just refusing to build until you know what problem you are solving, for whom, and what success means. One page, five questions, answered honestly. It is the cheapest insurance a project can buy.