Your Agents Are Only as Good as Your Requirements
We’ve spent a lot of energy making agents better at writing code and tests.
We’ve spent far less making the inputs to those agents less terrible.
Most modern teams don’t have an “AI coding” problem. They have a requirements problem—and agents make it louder. Give Claude a vague story with “fast,” “easy,” and a missing error path, and it will happily invent behaviour. Give Playwright-authoring agents an untestable scenario, and they will automate the guess. Garbage in doesn’t just produce garbage out anymore. It produces confident garbage—at merge velocity.
That isn’t a new insight in software engineering. It’s just newly expensive.
We’ve known what “good” looks like for decades
Quality requirements aren’t a 2026 invention.
Agile teams have INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)—Bill Wake’s checklist for backlog items that don’t sabotage the sprint. The “T” is the one that keeps biting agentic workflows: if you can’t write a test for it in principle, you don’t have a requirement—you have a vibe.
Formal requirements engineering went further. ISO/IEC/IEEE 29148 spells out characteristics like unambiguous, complete, singular, and verifiable—measurable properties of a requirement, not a gut feel in a grooming meeting. Industry write-ups of the standard make the same point in plain language: “user-friendly” isn’t a requirement; a verifiable threshold is (overview of ISO 29148 quality criteria).
And for scenario thinking, Specification by Example and Given-When-Then have been the antidote to “as a user I want stuff so that value” for years.
The gap was never knowing. The gap was doing it continuously, on every story, without a two-day workshop and a whiteboard full of sticky notes.
Enter DeFOSPAM
DeFOSPAM is a seven-lens mnemonic from Paul Gerrard’s Business Story Method (with Jonathon Wright / OpenTest.AI)—popularized recently by OpenRequirements.AI as an agentic requirements-validation approach. The goal is blunt:
A perfect requirement lets the reader predict the behaviour of every feature in all circumstances.
Where that prediction fails, DeFOSPAM tells you why—systematically:
| Lens | What it attacks |
|---|---|
| Definitions | Undefined terms, synonym collisions, glossary gaps |
| Features | Unclear scope, mixed concerns, incomplete decomposition |
| Outcomes | Missing or unmeasurable “so that…” value |
| Scenarios | Happy-path-only coverage; missing edges and errors |
| Prediction | Steps without verifiable expected results |
| Ambiguity | Weasel words, open-ended “etc.”, unclear actors |
| Missing | Actors, data, NFRs, acceptance criteria, cross-cuts |
Paul has talked about this as structured appraisal of requirements for years—including how AI can help walk the checklist without replacing human judgment (Analyzing and improving requirements — Richard Seidl podcast). OpenRequirements frames the same idea as specialist analyst agents over living documentation (OpenRequirements.AI; methodology notes on GitHub).
We didn’t invent DeFOSPAM. We operationalized it where our plans already live.
Requirement quality governance in TestChimp
If you’ve been following us, you know the thesis: Test Planning as Code—stories and scenarios as markdown in Git, workflows layered on for humans, context for agents. Traceability without the spreadsheet circus (requirement traceability).
The next piece is governance: not just having plans, but knowing whether those plans are good enough for agents to build and test against.
In TestChimp you can run agentic DeFOSPAM-style checks on a story, a scenario, or a plans folder. What you get back isn’t a vague “needs more detail” comment:
- Scores across clarity, completeness, testability, consistency, ambiguity risk, and scenario coverage—plus an overall score
- Findings with severity (critical / major / minor)
- Suggested fixes you can apply or ignore
- Tracked state in Plans → Insights → Requirement quality, so quality is a backlog you can govern—not a chat transcript that evaporates
Applied and ignored findings stay out of the penalty box on re-score. The board shows remaining work.
Full walkthrough: Requirement Quality Governance. Agent playbook: /testchimp analyze requirement quality.
Cloud vs local agent: pick for context, not vibes
There are two ways to run the checks.
TestChimp Cloud — one click from the story/scenario editor. Fast. No IDE setup. Costs an AI credit. Great when you want a quality pass without leaving the platform.
Local coding agent (recommended when you can) — install the TestChimp skill and run:
/testchimp analyze requirement quality of US-181
/testchimp analyze requirement quality of plans/stories/billing
Why we recommend local when it fits: the agent can ground findings in your code—fixtures, seed routes, existing scenarios, how “subscription” is actually modelled. Cloud is the simpler path; local is the richer one. Same governance surface either way—results land in Insights.
Authoring fits the same loop. Upskill the agent, then:
/testchimp author story for <objective>
Playbook: Author Plans. Docs: Authoring test scenarios.
Why this matters now
In a human-only world, ambiguous requirements wasted meetings and produced “works as designed” arguments.
In an agentic world, they waste tokens, CI minutes, and PR cycles—and they poison the feedback loop we care about: planned reality → tested reality → production reality (boiling the QA lake).
Agents are extraordinary executors. They are mediocre mind-readers.
If you want high-quality dev output and high-quality test output, start earlier than /testchimp test. Harden the story. Score it. Fix the critical findings. Then let agents implement and automate.
Requirements stop being static tickets. They become governed assets—the same way we already treat code.
Wrapping up
We believe the next leverage in agentic QA isn’t another “generate tests” button. It’s making the contract agents work from clear, detailed, and unambiguous—and keeping that quality visible over time.
DeFOSPAM gives the lenses. INVEST and ISO 29148 gave the vocabulary. TestChimp puts governance on the plans you already sync to Git.
If that resonates, start here:
References and further reading
- OpenRequirements.AI — DeFOSPAM / living requirements
- OpenRequirementsAI on GitHub — DeFOSPAM methodology notes
- Paul Gerrard / Richard Seidl — Analyzing and improving requirements (DeFOSPAM)
- Gerrard Consulting
- Agile Alliance — INVEST
- Bill Wake — INVEST in Good Stories, and SMART Tasks (XP123)
- ISO/IEC/IEEE 29148 — Systems and software requirements engineering
- ISO 29148 quality characteristics (overview)
- Martin Fowler — GivenWhenThen
- Gojko Adzic — Specification by Example
- ISTQB — Test planning