Agents as Requirements Engineers

Why Requirements Failure Is a Systems Problem

The Standish Group’s CHAOS reports have tracked software project failure for three decades. Consistently, the top causes of failure aren’t technical: they’re unclear requirements, stakeholder misalignment, and scope creep. These are information flow problems — signal that gets lost or distorted between business intent and engineering execution.

Phase	Traditional Loss	With Agentic Requirements
Business Intent → BA Documentation	40–60% signal loss (meetings, paraphrase, jargon)	Structured extraction with clarification loops
BA Docs → Developer Stories	Ambiguity preserved, context stripped	Formalized acceptance criteria, edge cases explicit
Stories → Test Cases	Often skipped or written post-hoc	Generated from story structure before implementation
Tests → Deployment	Tests validate implementation, not intent	Tests validate intent; implementation is constrained by them

The fundamental problem is that requirements are locked inside human heads in a format that resists formalization. Agents change the economics of extraction.

“The cost of fixing a defect found during requirements is 1x. During testing, 10x. In production, 100x. Agents compress this curve by surfacing defects in the requirements layer itself.” — Based on Barry Boehm, Software Engineering Economics, 1981 — still true in 2026

The Agentic Requirements Pipeline

A well-designed agent pipeline for requirements engineering operates in discrete, verifiable stages — each producing structured output that feeds the next. The key design principle: every artifact the agent produces must be machine-readable, not just human-readable.

🎙️

Discovery
Interviews

🔍

Extraction
NLP Analysis

📋

Structuring
Stories + ACs

⚡

Validation
Conflict Check

🧪

Test Gen
TDD Seeds

Stage 1: Discovery — The Agent as Interviewer

The agent’s first job is stakeholder elicitation. Unlike a passive document parser, a discovery agent conducts structured interviews using a conversational protocol designed to surface latent requirements — the ones stakeholders don’t know they have until you ask the right follow-up questions.

Best Practice: Discovery Protocol Design

Use a layered questioning model. Start with open-ended intent questions (“What problem does this solve for your users?”), then probe functional boundaries (“What happens when a user provides invalid input?”), then edge cases (“What should the system do if the upstream service is unavailable?”).

The agent should track which questions have been answered and which remain open, flagging unresolved ambiguities before moving to structuring.

Critically, the agent should be configured with domain-specific prompt scaffolding. A discovery agent for a financial services platform should know to probe around regulatory constraints, audit trail requirements, and data retention policies — automatically — without the stakeholder needing to volunteer that context.

Stage 2: Extraction — Turning Prose into Structure

Raw interview transcripts, Slack threads, email chains, and legacy documentation are the raw material. The extraction agent’s job is to identify and classify requirements from unstructured text, mapping each to a canonical form:

# Canonical Requirement Object
{
  "id": "REQ-0042",
  "type": "functional",        // functional | non-functional | constraint
  "priority": "must-have",     // MoSCoW: must | should | could | won't
  "statement": "The system shall send a confirmation email within 5 seconds of order placement.",
  "source": "stakeholder:jenny.chen@acme.com / interview-2026-05-14",
  "assumptions": ["Email service is available", "Order event is properly emitted"],
  "open_questions": [],
  "related": ["REQ-0039", "REQ-0041"]
}

This structured format is the foundation for everything downstream. It’s queryable, versionable, and — crucially — machine-processable by the test generation agent later in the pipeline.

Stage 3: Structuring — User Stories with Real Acceptance Criteria

From the canonical requirement objects, the structuring agent generates user stories in a format that is both human-readable and formally complete. The “given-when-then” (GWT) format is the lingua franca here — and it exists at the intersection of requirements language and test language for good reason.

User Story: US-0017
As a returning customer,
I want to see my previous order details on the confirmation screen,
So that I can verify my reorder was captured correctly.

Acceptance Criteria:
  AC-1: GIVEN I am a returning customer with prior orders
        WHEN my order is confirmed
        THEN the confirmation screen displays my 3 most recent orders

  AC-2: GIVEN I am a new customer with no order history
        WHEN my order is confirmed  
        THEN the order history section is hidden (not empty, not error)

  AC-3: GIVEN the order history service is unavailable
        WHEN my order is confirmed
        THEN the confirmation displays without history and logs a non-fatal error

Definition of Done:
  - [ ] All ACs pass automated tests
  - [ ] Tested on mobile viewports (320px–768px)
  - [ ] Accessibility: screen reader announces order confirmation

Notice that AC-3 — the failure mode — is explicitly specified. Human requirements writers routinely omit failure paths. Agents, prompted correctly, enumerate them systematically.

Best Practice: INVEST Validation

Configure the structuring agent to validate each user story against the INVEST criteria: I ndependent, N egotiable, V aluable, E stimable, S mall, T estable. Stories that fail one or more criteria are flagged for human review before proceeding.

An agent that generates 40 user stories in 90 seconds still needs a human to review borderline cases — the value is in the flagging, not the bypassing.

Stage 4: Conflict Detection — Consistency Before Code

One of the most underappreciated capabilities of an agent-driven requirements process is cross-requirement consistency checking. A human BA writing story #47 doesn’t necessarily remember that story #12 made a conflicting assumption about session behavior. An agent does.

Conflict detection agents scan the requirement graph for:

Logical contradictions Two requirements that cannot both be true simultaneously (e.g., “users can delete their account” vs. “all user records must be retained for 7 years”).

Duplicate coverage Two stories that address the same scenario from different angles, risking inconsistent implementations.

Missing coverage Implicit requirements never stated (e.g., a checkout flow with no story for payment failure handling).

Unstated non-functionals Performance, security, and accessibility requirements that are implied by the domain but never made explicit.

Closing the Loop: Agents and Test-Driven Development

Here is where agentic requirements engineering transforms from a productivity tool into a structural improvement to software quality. TDD’s core premise — write the test before the code, let the test define correctness — has always been philosophically sound but operationally difficult. Writing good tests requires deep understanding of the requirements. If requirements are ambiguous, tests are too.

When requirements are agent-generated in structured, formal formats, test generation becomes a mechanical transformation, not a creative act.

From Acceptance Criteria to Test Skeletons

A test generation agent consumes the structured user stories and produces test scaffolding in whatever framework the team uses. Because the acceptance criteria are already in given-when-then format, the mapping is nearly direct:

// Auto-generated from US-0017 / AC-2
// Source: requirements/stories/US-0017.json
// DO NOT MODIFY — regenerate from requirements changes

describe('Order Confirmation — Returning Customer View', () => {

  describe('AC-2: New customer with no order history', () => {
    it('should hide the order history section entirely', async () => {
      // GIVEN
      const newUser = await createTestUser({ orderHistory: [] });
      const order = await placeOrder(newUser, testOrderPayload);
      
      // WHEN
      const confirmationPage = await renderConfirmation(order.id, newUser.token);
      
      // THEN
      expect(confirmationPage.queryByTestId('order-history')).toBeNull();
      expect(confirmationPage.queryByTestId('order-history-empty')).toBeNull();
      expect(confirmationPage.queryByTestId('order-history-error')).toBeNull();
    });
  });

  describe('AC-3: Order history service unavailable', () => {
    it('should render confirmation without history and log non-fatal error', async () => {
      // GIVEN
      const user = await createTestUser({ orderHistory: [mockOrder] });
      mockOrderHistoryService.setUnavailable(true);
      const errorSpy = jest.spyOn(logger, 'error');
      
      // WHEN
      const confirmationPage = await renderConfirmation(order.id, user.token);
      
      // THEN
      expect(confirmationPage.queryByTestId('confirmation-header')).toBeInTheDocument();
      expect(confirmationPage.queryByTestId('order-history')).toBeNull();
      expect(errorSpy).toHaveBeenCalledWith(
        expect.stringContaining('order-history-service-unavailable'),
        expect.objectContaining({ severity: 'non-fatal' })
      );
    });
  });
});

This test skeleton is not complete — it requires the team to implement the test helpers and fill in specific assertions. But it does something crucial: it ensures every acceptance criterion has a corresponding test before any engineer writes implementation code.

“The test generation agent doesn’t replace the QA engineer. It ensures the QA engineer starts every sprint with a complete map of what ‘done’ means — and has test stubs already in the repo.” — Agentic Engineering Pattern

Traceability as a First-Class Artifact

One of the most significant benefits of agent-generated requirements + tests is bidirectional traceability. Every test knows which requirement generated it. Every requirement knows which tests cover it. This creates a living requirements traceability matrix — something that enterprises typically spend hundreds of hours maintaining manually — automatically.

Enterprise Value: Audit & Compliance

For regulated industries (healthcare, finance, government), requirements traceability isn’t optional — it’s auditable. An agentic pipeline that produces a complete requirements-to-test traceability matrix as a byproduct, with no additional engineering effort, represents significant compliance cost reduction.

When an auditor asks “how do you know your system does what you claimed it would do?”, the answer is a structured graph from requirement to test to CI pass log.

Regression as a Requirements Concern

When a new requirement is introduced that modifies existing behavior, the conflict detection agent can identify which existing tests may no longer be valid — before implementation begins. This flips the typical regression discovery timeline: instead of finding that a new feature broke old behavior in CI three days later, the requirements agent flags the conflict at story creation time.

Organizational Best Practices

1. Keep humans in the loop at decision gates

Agent-generated requirements should flow through human review checkpoints — not to slow the process, but to ensure the right person validates the right artifact. Product owners approve story priority. Architects review non-functional requirements. QA leads review test coverage maps. The agent does the drafting; humans do the deciding.

2. Version requirements like code

Requirements stored as structured JSON or YAML in a version-controlled repository gain all the benefits of software engineering practice: diffs, blame, branching, and pull request review. A change to a requirement triggers a review workflow, not a Word document revision.

3. Feed agent outputs back into the agent

The most powerful pattern is a closed feedback loop: test failures inform requirement refinement. When a test fails not because of a code bug but because the requirement was underspecified, that signal should flow back to the requirements agent to update the formal specification. The requirement and its tests converge on precision together.

4. Domain-specialize your discovery agents

A generic discovery agent will produce generic requirements. Invest in prompt engineering and fine-tuning for your specific domain. A healthcare agent should know HIPAA implications. A payments agent should know PCI DSS constraints. Domain knowledge baked into the agent means domain constraints surface in requirements automatically, not after a security review six months later.

5. Treat “definition of ready” as an agent gate

Before a story enters a sprint, the agent validates it against a definition of ready checklist: acceptance criteria present, INVEST criteria met, no open conflicts with existing requirements, test skeletons generated and committed. Stories that fail this gate don’t enter planning. This is the agentic equivalent of a linting step for requirements.

Where This Is Heading

The convergence of agentic requirements engineering and TDD points toward a development model where the gap between intent and implementation is systematically minimized rather than managed. Today’s best teams manually enforce the discipline that connects requirements to tests. Tomorrow’s best teams will have agents enforce it structurally, with humans focusing on the judgment calls that genuinely require human judgment.

The organizations that get there first won’t just ship faster. They’ll ship with fundamentally fewer defects, more complete coverage, and an audit trail that documents not just what they built — but why.

Key Takeaways

1. Requirements are the highest-leverage target for AI agents — the cost of a requirements defect is an order of magnitude higher than a code defect.

2. Structured output is the unlock — agent-generated requirements in machine-readable formats (JSON/YAML with typed fields) enable mechanical test generation and automatic traceability.

3. Given-when-then bridges requirements and tests — acceptance criteria written in GWT format are simultaneously human-readable specifications and test generation templates.

4. Conflict detection before code is the real TDD accelerant — catching requirement contradictions at the story level, not the code level, eliminates an entire class of expensive late-stage rework.

5. Traceability is a compliance byproduct, not a separate workstream — agentic pipelines produce audit-ready requirement-to-test linkage automatically.