Requirement interpretation as a discipline

A procurement document describes an intended outcome. It does not describe a system. Reading between those lines is where the real design work begins.

A procurement document is not a system specification. It is a statement of intent, written under time pressure, by people who understand the problem better than they understand the solution, translated through procurement language that may be several layers removed from the operational reality it is trying to describe.

Responding to what is written is not the same as responding to what is needed.

What requirement interpretation is

Requirement interpretation is the discipline of reading a brief not only for what it asks but for what it means: the operational context that produced the request, the constraints that shaped the language, and the outcomes that a successful system would actually deliver.

It is the difference between a vendor who quotes against a specification and an adviser who interrogates it. The interrogation is not adversarial. It is diagnostic. It assumes that the brief is a starting point, not an endpoint, and that the most valuable contribution a technology partner can make is to arrive at the real requirement before the build begins.

Three skills

Reading context. A brief does not arrive in isolation. It arrives from an organisation with a history, a set of existing systems, a political landscape, and a set of constraints that shaped what could be asked for. Reading context means understanding the organisation behind the document: why this brief exists now, what previous attempt it may be responding to, what the brief cannot say because of political or commercial constraints.

Identifying constraints. Every brief has explicit constraints (budget, timeline, technology stack) and implicit ones: departmental politics, vendor relationships, regulatory obligations, internal capacity. Implicit constraints are as binding as explicit ones. A system that does not account for them will not be adopted regardless of its technical merit.

Surfacing unstated assumptions. The most consequential content of most briefs is what is assumed rather than stated. The assumption that data exists and is structured. The assumption that a particular role will manage the system. The assumption that the organisation will change its workflow to accommodate the technology. These must be examined before the build.

Three reading skills

CONTEXT

Organisation history, prior attempts, political landscape. Why was this request made now, and by whom?

CONSTRAINTS

Explicit: budget, timeline, technical stack. Implicit: political realities, cultural resistance, and dependencies no one mentioned.

ASSUMPTIONS

Data exists and is structured. A role will manage the system. The workflow will adapt. Each assumption that proves false reshapes the build.

The problem as described is often a symptom. The problem as it actually exists is a structural condition that the symptom is pointing to.

The diagnostic interview sequence

BRIEF

as stated

What the client believes the problem is. Often framed as a platform request.

↓

DIAGNOSTIC INTERVIEW

the translation layer

Questions about context, constraints, history, and what success actually looks like in practice.

↓

REAL REQUIREMENT

as found

Almost always different from the brief: sometimes smaller, sometimes differently structured, sometimes a different problem entirely.

The diagnostic interview

The instrument of requirement interpretation is the diagnostic interview, a structured conversation conducted before any technical response is written. It does not ask stakeholders to describe the system they want. It asks them to describe the problem they have, the context in which it exists, the constraints they are working within, and the outcomes a successful engagement would produce.

From that conversation, the real requirement emerges. It is almost always different from what the brief asked for. Sometimes smaller. Sometimes differently structured. Occasionally more ambitious in the right direction and less ambitious in the wrong one.

Why this matters

A vendor who responds to the brief as written produces a system that solves the problem as described. A practitioner who interrogates the brief produces a system that solves the problem as it actually exists.

Building a system for the symptom makes the symptom prettier. It does not address the condition. Requirement interpretation is the discipline that makes that distinction. It is not a phase in a project plan. It is a professional commitment to understanding before building.

←All insights

If this resonates with a challenge you are navigating, we are happy to talk through it.

Start a conversation