What to Do When the Client Brings Ambiguity — Undefined Requirements?

There's a type of client every architect knows: they arrive with an idea, enthusiasm, and the phrase "you're the architect, that's what I'm paying you for." Formally the task sounds like "build me a project," but behind it lies emptiness: raw material, fragments of thought, no spec. How do you turn that uncertainty into working architecture, and where does the specialist's boundary of responsibility run — let's go step by step.

What ambiguity is and why it's normal

Ambiguity — undefined requirements — is the state of any idea at an early stage. A person arrives with a sense of the product but no description of it. They see the result but not the path. Formulating requirements is a separate competence, and not everyone has it.

The problem doesn't start with the missing spec. It starts with the attitude toward that absence. One client says "I have an idea, help me shape it" — and that's a workable situation. Another says "you're the architect, you figure it out" — and that's already a warning sign, because behind it lies a shifting of responsibility rather than collaboration.

The difference is fundamental. In the first case the architect is a partner helping turn raw material into structure. In the second they're an executor handed a blank sheet and asked to paint a masterpiece. The outcome will differ, even if the architect is the same person.

Why "I'm paying you, so you decide" is a bad position

Architecture is built on information. When there's no information, it's built on guesses. Guesses sometimes hit the mark, but more often they lead to rework. That's not a reproach to the architect, it's a law of the craft.

An architect may not know all the business processes and the project roadmap. They aren't required to carry the entire company's context in their head. But they are required to obtain that context from those who hold it. If the holder refuses to pass it on, the work turns into guesswork.

Bright ideas and effective solutions are part of the architect's job. But they're born in dialogue, where the client provides domain knowledge and the architect provides structure and technical logic. When one side drops out, the other works blind.

The architect is responsible for the result. The client is responsible for the input data. It's like a doctor: they're responsible for the diagnosis and treatment, but the patient has to say what hurts and where. If the patient stays silent, the diagnosis will be imprecise.

The brief with questions is a mandatory stage

The architect prepares a brief with questions. It's a must-have, not a phone call where you catch the client's ideas on the fly. The difference is huge. In conversation, thoughts get lost, details get forgotten, and a week later nobody remembers what was agreed. The brief records: what was asked, what was answered, what remains open.

A good brief is a structured set of questions across key zones: project goal, users, constraints, data, integrations, success criteria. The questions are worded so the client can answer briefly and to the point. If there's no answer, that's a result too: it means the zone hasn't been worked through and needs a separate decision.

A warning sign — when the client refuses to fill in the brief. The reasons vary: "I'm too busy," "I don't have time to describe even the theses," "let's do it verbally." All of them mean one thing: the client isn't ready to invest in the stage on which the entire project depends.

How to turn uncertainty into artifacts

The key principle for working with ambiguity: inside the working contour, a concept must become a boundary, an artifact, or a verifiable criterion. The general phrasing "we need a smart assistant" is a direction, not a requirement. A requirement sounds different: "the assistant answers questions from internal documentation, finds the answer in five seconds, and responds without hallucinations in ninety-five percent of cases."

Step one — boundaries. What's inside the project, what stays outside. The most common zone of uncertainty, because the client thinks in terms of the result, not the frame.

Step two — input data. Which sources are used, who owns them, how often they update, in what format. Here it's important to record everything explicitly: not "data from systems," but "data from the CRM via API, updated hourly, owned by the sales department."

Step three — owner. Every element needs a person responsible for it. Without an owner, an element becomes a dangling task everyone forgets about.

Step four — constraints. What can't be done, what isn't available, what the deadlines are, what the budgets are, what the regulatory requirements are. Constraints are the basis for realistic architecture.

Step five — failure mode. What happens if a component breaks, data doesn't arrive, the model errs. Describing failure modes turns architecture from a picture into a working document.

Step six — a measurable criterion of correct operation. How we'll know the system works properly. Accuracy, latency, cost, share of successful scenarios. The main thing — the criterion must be verifiable, not declarative.

Handoff as a criterion of correct operation

Transferring architecture to implementation is a check. If the team taking the project can start work without further questions — the architecture succeeded. If they ask dozens of clarifications — it means uncertainty remains somewhere, unclosed.

A good sign is when, a month after handoff, the team discusses implementation details rather than basic architecture questions. A bad one is when questions surface whose answers should have been in the documents.

Author's column

Climax: where the boundary runs

Working with ambiguity is discipline, not patience. The client arrives with uncertainty, the architect turns it into structure. But the transformation requires both sides. Without business knowledge, architecture becomes a set of assumptions. Without structure, business knowledge remains a set of wishes.

The architect's responsibility is to bring the project to a state where it can be implemented. The client's responsibility is to provide the information the project is built on. When the balance holds, ambiguity becomes a working state from which a good product is born. When the balance breaks, the project becomes guesswork, and guesswork eventually ends in rework.

Everything is within our power. We just have to look honestly at where the boundary between architecture and business runs, and not blur it for convenience.

Glossary of terms

• Ambiguity (undefined requirements) — a project state where the client cannot precisely formulate the task and the expected result.
• Project boundary — a description of what's inside the project and what remains outside it.
• Artifact — a tangible result of work: document, diagram, register, criterion.
• Verifiable criterion — a condition that can be measured and confirmed rather than merely asserted.
• Input data — the information sources on which the project is built.
• Element owner — the person responsible for a specific component or decision.
• Project constraints — conditions defining the implementation frame: deadlines, budget, regulation, resources.
• Failure mode — a description of how the system behaves when a component fails.
• Correct operation criterion — a measurable indicator by which system success is determined.
• Handoff — transferring architecture and documentation to the implementation team.
• Zone of responsibility — the area a specialist answers for personally and within which they make decisions.
• Teamwork — a process where the result depends on the contribution of all participants.
• Assumption — an explicitly recorded premise used when data is scarce.
• Business process — a sequence of actions aimed at achieving a result in a company.
• Roadmap — a plan for a project's development over time with stages and priorities.
• API — a programmatic interface for interaction between systems.
• Architecture — the structure of a system: components, their connections, distribution of responsibility, and boundaries.
• Feasibility — a property of architecture whereby the system can be built under given conditions.
• Project risk — the probability of an event that may negatively affect the project.
• Approval — the process of signing off on decisions by all project participants.