Requirements Engineering & Discovery

Requirements Gathering That Builds The Right Thing The First Time

Every expensive rebuild we have been called into was already lost before the first line of code was written. The requirement was fuzzy, the spec was untestable, the build team guessed, and they guessed wrong. Facet's Requirements Engineering & Discovery service takes an ambiguous ask and engineers it into a structured, dot-notation specification that your build team, your reviewers and any agent working on the project can all check work against — because a requirement that cannot be tested is a wish, and wishes are expensive to unwind at sprint twelve. We can hold that standard because we already hold ourselves to it: Facet's own engineering, content and quality review run through Agent Loops under human command, and a loop cannot act on a requirement a person could only interpret by context. Writing specs precise enough for our own agents to execute is not a methodology we assembled for this page. It is the condition of our own company working.

We found out what our specs were worth when something else had to judge them

This service exists because of something that happened to us, not because of a methodology we admired. The lesson did not arrive as a vocabulary problem. It arrived as a reporting problem: our loops kept telling us they were finished.

They were not lying. A requirement written in ordinary professional prose leaves whatever reads it enough room to decide for itself what counts as satisfied, and then to report success perfectly honestly against its own reading. A human engineer closes that gap without noticing, by knowing what was meant and asking when they do not. Nothing else does. So what we had to learn to write was not clearer requirements — ours were clear — but falsifiable ones: every requirement paired, at the moment it is written, with a criterion capable of coming back false.

That is the whole of the methodology below, and it is why acceptance criteria are written alongside requirements here rather than retrofitted later by whoever built the feature. We arrived at it by shipping against our own specifications and finding out which of them were incapable of telling us we were wrong.

Three consequences for your engagement, and none of them is enthusiasm.

The specification keeps working after we leave. A document written to be checked by something other than a person does not go stale in a folder. The criteria stay runnable against the build, which is why this engagement hands you an asset rather than a deliverable.
Humans stay in command of every definition. An agent can show you that two of your systems disagree about what an account is. It cannot tell you which one your business meant, and it should not try.
We name the failure modes rather than hide them. A model asked to interpret an ambiguous field produces something plausible rather than stopping. Agents also lose the thread partway through a long document, and they will confidently fill a gap that a person would have flagged as a question. Every one of those is real, which is exactly why a Facet engineer owns the model and every requirement is argued in a room before anyone builds on it.

Why hire a requirements engineer?

Because precision before commitment is the cheapest thing you will buy on the whole project. In the rescues we are called into, the costly defect is almost never a coding error — it is a requirement two people read differently, and by the time it surfaces as a broken feature it has been paid for twice: once to build it wrong and again to rebuild it right.

Facet has been running software requirements gathering since 2014 across industries from medical spas to law firms to B2B wholesale. We have seen every flavour of fuzzy ask, and the pattern underneath the expensive ones is almost always the same: the requirement was not wrong, it was undecided, and everybody routed around the gap rather than naming it.

The math on getting it wrong (illustrative)

Scope creep and rework are not random. They are traceable to the requirements phase, and the arithmetic is not subtle.

Take a 12-week build opened on an ambiguous brief — six two-week sprints. It surfaces three to five major scope changes mid-build (illustrative), and each one costs at least a sprint to unwind (illustrative). You do not need the top of that range for the schedule to be gone: three unwound sprints out of six is half the build spent rebuilding work that had already been built once. That is not a budget overrun you can manage your way out of afterwards. It is the schedule.

Run the same arithmetic on your last project. Count the scope changes that turned out to be requirements nobody captured, multiply by what a sprint costs you, and compare it to what defining the thing properly would have cost at the start. The comparison is the whole argument, and it is better made on your numbers than on ours.

What precise requirements unlock for an agentic business

When a requirement is written in dot-notation — order.fulfillment.status.confirmed triggers notification.customer.email.dispatch — it can be evaluated programmatically rather than read and interpreted. That is the difference between a document that describes the system and a document the system can be checked against.

Specs become machine-readable checks: dot-notation requirements translate directly into the acceptance criteria an agent loop uses to validate its own output, closing the gap between what was specified and what was built without waiting for a sprint review.
Ambiguity is the bottleneck AI tooling cannot solve: agent-assisted development accelerates build velocity, and that speed amplifies the cost of a bad requirement in exact proportion. Precision is the rate-limiter that decides whether acceleration produces value or produces rework faster.
Both kinds of worker need the same ground truth: whether a human engineer or an agent is doing the work, both need a testable standard to check against. If you are heading toward Agentic Engineering, the requirements document is the thing that has to exist first.

What the requirements loop actually does

A Facet engagement runs as a sequence of passes over your business, most of them carried by agents under an engineer's direction. Each is high-volume, checkable work — which is precisely the category agents are good at.

Read everything before anyone proposes anything. Existing documentation, ticket histories, support transcripts, database schemas, the spreadsheet that four departments actually run on. The inventory pass runs first and runs wide, so the interviews start from what the systems already say rather than from a blank page.
Extract the domain model from the evidence. Agents propose the entities, their states, and the transitions between them directly from what they read, producing a first-cut model within days instead of after a fortnight of workshops.
Hunt for contradictions at volume. Every requirement is checked against every other requirement for logical conflict. Applying that check for the four-hundredth time exactly as carefully as the first is the thing agents do that people genuinely cannot, and it is where most of the expensive finds come from.
Draft the acceptance criterion for every requirement. Each functional requirement gets a paired, testable criterion written at the same time as the requirement itself — never retrofitted later by the developer who built the feature.
Trace every requirement through to implementation. Tagging and coverage checks run continuously, so when scope moves you get an impact list rather than a guess.

What a person still decides

Everything above is throughput. None of it is judgment, and we would rather say so plainly than have you discover it in week three.

What the business actually meant. When two systems disagree about what a customer is, the model surfaces the conflict. Which definition is correct is a business decision with revenue attached to it, and it belongs to you.
Which contradictions matter. An automated conflict check produces a list. Ranking that list by consequence — this one is a rounding error, this one would have shipped a compliance breach — takes a Facet engineer who has watched each of them play out before.
What is out of scope, and what that costs. The most valuable line in most specifications is a subtraction. Cutting a requirement has consequences an agent does not carry.
Sign-off. Every stakeholder reviews the final spec against their own domain, and nothing goes to a build team without a named person on your side agreeing it says what they meant.

How an engagement runs

Three phases, each with defined outputs and a defined entry gate, so you know what you are getting and when.

Phase 1: Discovery — map the domain

We start with your business, not your feature list. Every role that touches the system is identified — users, operators, integrations, downstream consumers — and the interviews are structured around them. We build the shared entity model: the objects your system manages, their states, and the rules governing how they move between them. We trace every process the system supports, including the exception paths and failure modes that are absent from every initial brief because they live in one person's head. Technical, regulatory and integration constraints are catalogued and ranked by build impact before a design decision gets made.

If that reads like the thing your last automation attempt was missing, it is. You cannot automate a process you cannot define, which is why a failed DIY automation is one of the most common reasons a team ends up here.

Phase 2: Specification — engineer the requirements

Discovery output becomes a structured, testable document. Functional requirements are written in domain-driven dot-notation, each with its acceptance criterion. Non-functional requirements — performance budgets, security posture, compliance mandates such as HIPAA, SOC 2 or ABA, and integration contracts — are documented with measurable thresholds rather than narrative descriptions. The backlog is ranked by business value and dependency order, producing a build sequence that front-loads value and minimizes blocking. Then every stakeholder reviews the spec against their domain, and ambiguities are resolved before handoff rather than discovered during build.

Phase 3: Handoff — build-ready and loop-ready

The package is structured for engineering consumption: entity models, requirement maps, acceptance criteria and a prioritized backlog, formatted for the project tooling you already use. For clients running an agentic operating model, requirements are formatted so a QA loop can evaluate compliance programmatically. And we define the success metrics for the system at requirements time, so the build team knows what done means before it starts.

The KPIs we track against

Precision, completeness and rework prevention, measured in terms you already use.

Requirement stability rate: the share of requirements that survive the build unchanged — the most direct proxy there is for specification quality.
Defect origin traceability: every defect found in QA or after launch is traced to requirements, design or implementation, so the next engagement improves whichever upstream phase is generating the most downstream cost.
Stakeholder alignment at sign-off: did every stakeholder confirm the document reflects their intent? Disagreements at sign-off are resolved. Disagreements discovered mid-build are expensive.
Acceptance criteria coverage: the share of functional requirements with automated-runnable criteria — which is also the measure of how much of your spec is agent-executable rather than human-dependent.

When those criteria are machine-readable, a QA loop can run them continuously against the build and surface drift between specification and implementation as it appears rather than at the next review. The requirements document stops being an artefact filed at kickoff and becomes a live check.

How could AI agents run your requirements process? Book a 45-minute Requirements Working Session on one real project you are about to start. You leave with the entity model sketched, a ranked list of the specification steps an agent loop could absorb, and a written view of which of your requirements are already testable and which are still wishes.

Take one requirement and try to make it come back false

Here is a test you can run this afternoon, on the project you are about to start, without talking to anyone. Pick a single requirement from the brief. Write down the check that would prove it was not met — a specific condition, on a specific field or state, capable of coming back false. Then try to do it for five more.

The ones you cannot write a check for are not badly written. They are undecided, and the build team is going to decide them for you, silently, in whatever order they happen to hit them.

That test is the whole of this service, and also the smallest possible version of it. The reason we write acceptance criteria at the same moment as the requirement rather than after it is that a criterion is the only thing capable of telling you the requirement was wrong. We learned that the expensive way: our own loops kept reporting they were finished, honestly, against their own reading of specifications that were clear and were not falsifiable. Nothing downstream of you can settle a term your business has not settled — a person asks, and an agent guesses.

The evidence here is a spec that survives contact with a build, and you can measure how yours have done so far without hiring anyone. Open your last project, count the requirements that reached production unchanged from the way they were first written, and divide. That is your requirement stability rate. It comes out of your own ticket history in an afternoon, and it is the number this engagement exists to move.

What accumulates afterwards is the vocabulary itself, and we watched it happen to our own company. The second domain we modeled went faster than the first — not because we had got better at modeling, but because half its terms were already settled, and the entity names, the states and the review discipline carried straight over. That is the part worth starting now: a company that has settled what confirmed means never has to settle it again. The argument gets had once, in a room, by the people with the authority to end it, and everything built afterwards inherits the answer.

Where requirements work goes next

This is a ladder, and plenty of clients stop on the first rung. That is a complete outcome, not a failed upsell.

Agentic Engineering — the build layer. Agents that plan, build, check and improve under human command, working against the acceptance criteria this engagement produced. The natural next rung when the spec is done and the question becomes how fast you can build against it.
Forward Deployed Engineering — a senior Facet engineer embeds with your team and transfers the specification method itself, so writing agent-executable requirements becomes something your people do rather than something you buy.
AI Managed Services — the run layer, for when the checks the spec defines need to keep running as your business, your data and your thresholds move.
Agentic Operating System — the same pattern applied across every operating area rather than one build.
Discovery Workshop — the smaller front door, if you are not yet sure the project is real enough to specify.

FAQ

What is requirements gathering and why does it matter for my project?

Requirements gathering is the process of identifying, documenting and validating exactly what a software system must do before any design or build work begins. It matters because the most common and most expensive cause of project failure is not bad code — it is a bad or missing requirement nobody caught until the build was finished.

It defines the scope precisely: the document is the contract between stakeholders and the build team, agreed before the first design decision.
It surfaces contradictions early: stakeholders routinely hold conflicting expectations they do not know are conflicting. Resolving that in a structured session costs almost nothing; resolving it in a QA cycle costs a sprint.
It produces testable acceptance criteria: a requirement that cannot be tested is a liability. Criteria give your reviewers — human or agent — an objective standard to check against.
It prevents scope creep: most mid-build scope changes are known requirements that were never captured.
It enables agentic operations: machine-readable requirements let a loop evaluate compliance automatically, turning the spec into a continuous check rather than a one-time document.

How is Facet's approach different from a standard discovery workshop?

A standard discovery workshop generates discussion and produces meeting notes. A Facet requirements engagement produces a structured, dot-notation specification that is testable, traceable and agent-executable.

Domain-first, not feature-first: we model entities, states and rules before touching features, which exposes the requirements stakeholders forgot to mention because they assumed them.
Dot-notation precision: order.payment.status.captured is either true or false at any moment. "Payment is confirmed" is a phrase that means different things to different people.
Contradiction detection as a deliverable: conflicts are found and resolved during specification, where they cost almost nothing.
Cross-industry pattern recognition since 2014: we have run discovery across medical spas, law firms, B2B wholesale, property management, nonprofits and SaaS companies. We know which requirements are always missing, and we look for those first.

How does Facet price a requirements engagement?

Fixed fee, scoped and quoted before work starts, with no hourly billing. Scope is driven by project complexity, the number of stakeholders and the integration surface area — which is why we quote after a scoping conversation rather than from a feature list.

The question is not what requirements engineering costs, it is what ambiguity costs. A single mid-build scope change driven by a missed requirement can consume one or more sprint cycles (illustrative), and that cost is already in your project. It is simply invisible.
You are buying certainty before commitment: the alternative is funding a build where ambiguity and rework are priced into someone's estimate silently. This moves that cost to the front, where it is visible and discrete.
For agentic engagements the return compounds: once acceptance criteria are machine-readable, the layer that checks them runs continuously at close to no marginal cost.

Can requirements engineering integrate with an agentic operating model?

Yes — this is the part that goes beyond what a traditional discovery consultancy delivers. Dot-notation requirements paired with machine-readable acceptance criteria become the input layer for loops that validate work automatically.

Specs become check criteria: order.fulfillment.shipment.tracking.available is either satisfied or flagged, with no interpretation layer in between.
The feedback loop closes in the same cycle: a violation surfaces when it is introduced rather than two weeks later in a sprint review.
Requirements become living documents: the spec is the live contract the QA loop enforces continuously, updated as the system and the business evolve.
We build both layers: the specification and the loop that enforces it are designed together rather than assembled separately by two vendors — and every requirement an agent drafted clears exactly the same review as one a person typed.

Build the right thing the first time

In our experience the costliest defect in a build is already sitting in its specification. Facet engineers requirements with a methodology that has been tested across professional services, healthcare administration, legal practice and B2B operations — dot-notation domain modeling, structured elicitation, contradiction detection, and acceptance criteria your build team and your loops can both check work against. Facet has run technology work for clients since 2014 and was named a CIOReview Top 10 Digital Transformation Services Company in 2021.

How could AI agents run your requirements process? Book a 45-minute Requirements Working Session on one project you are about to start. You leave with a sketch of the entity model, a ranked list of the specification work an agent loop could absorb, an illustrative before-and-after built on your own sprint numbers, and a written recommendation you keep and can act on with anyone, including us.

Some of those sessions end with the opposite of a proposal. If the working session shows that what you have is not a requirements problem but an unmade business decision — that no specification will resolve what two departments have declined to settle for two years — that is the finding, and it is the one worth the most to you. It also means we are pointing you at a conversation you can have internally this week rather than at an engagement, which is a trade we will make every time rather than sell you a document that cannot fix the thing that is actually broken.