What is DeFOSPAM?
Short answer: DeFOSPAM is the structured technique REQQA uses to find faults in your requirements and your Gherkin stories. Rather than reading a requirement once and forming a general impression, REQQA runs it through a sequence of focused analysis steps — each one hunting for a specific kind of fault, such as ambiguity, missing information, undefined terms, or unhandled edge cases. The issues those steps raise are what you act on to improve the text.
DeFOSPAM is the technique; the Analysis Engine is the machinery that runs it.
What the name means
DeFOSPAM is the name of the method REQQA was originally built around — you'll see it written
as DEFOSPAM in some of the underlying step records. It is best understood not as a word to
decode but as a checklist of fault categories: each letter corresponds to a distinct angle of
attack on a requirement. In practice you never need to memorise the name. What matters is the
set of steps it expands into, and each step carries a short, readable analyser code (for
example R-A for ambiguity or R-M for missing elements).
The codebase still carries the original project name in a few internal places (the database
is named defospam). The technique and the product are the same thing under two names —
"DeFOSPAM" the method, "REQQA" the product that applies it.
How it works in practice
DeFOSPAM is applied as a series of single-purpose steps, not one monolithic pass. When you analyse a requirement, REQQA can run up to eleven requirement steps, each with its own code and its own prompt. Running them separately is deliberate: a step that is only looking for, say, boundary conditions does a sharper job than a single prompt asked to find everything at once.
The requirement steps are:
| Code | Step | What it hunts for |
|---|---|---|
| R-D | Definitions | Domain terms and jargon that are used but never defined |
| R-G | Goals & Users | Missing or unclear user roles, goals, and stakeholders |
| R-F | Features | Functional behaviour that can be decomposed into discrete features |
| R-I | Interfaces | System interfaces, APIs, and UI screens that need specifying |
| R-R | Rules | Business rules, policies, and validation logic |
| R-E | Entities & Data | Data entities, attributes, and relationships |
| R-C | Conditions & Decisions | Conditional logic, state transitions, decision points |
| R-B | Boundaries | Edge cases, limits, thresholds, and error boundaries |
| R-Q | Quality Attributes | Non-functional qualities — performance, security, usability |
| R-A | Ambiguity | Vague wording, contradictions, and unclear statements |
| R-M | Missing Elements | Gaps and incomplete specifications that earlier steps missed |
REQQA does not blindly run all eleven on every requirement. A suggestion pass first reads the requirement and recommends which steps are worth running — for instance, it skips the Features step on a pure non-functional requirement, but it almost always recommends R-A (Ambiguity) and R-M (Missing Elements) because those checks are valuable for any requirement.
DeFOSPAM for stories, too
The same technique applies to Gherkin user stories, with its own set of step codes prefixed D-:
| Code | Step | What it hunts for |
|---|---|---|
| D-D | Definitions | Undefined terms used in the story |
| D-A | Ambiguity | Vague or contradictory steps |
| D-F | Features | The features the story exercises |
| D-S | Scenarios | Missing or weak scenarios |
| D-O | Outcomes | Whether the Then-steps express clear, checkable outcomes |
| D-P | Prediction | Behaviour the story implies but does not state |
| D-M | Missing Elements | A final comprehensive check for gaps |
So whether you are working on a written requirement or a behaviour-driven story, DeFOSPAM gives you the same disciplined, multi-angle critique — every issue it raises is tagged with the code of the step that found it, so you always know why something was flagged.
What you do with the results
Each step produces issues, and each issue is attributed to its analyser code, given a severity, and presented for you to triage. You decide what to fix, what to defer, and what to dismiss — DeFOSPAM finds the faults; you remain the author. The point is to surface the weaknesses in a requirement before anyone builds against it, when they are cheapest to fix.
A high issue count on a first analysis is not a failure — it is the technique doing its job. The value is in the fix-and-re-analyse loop, where the count falls as the requirement sharpens.
Related
- The Analysis Engine — how REQQA runs the DeFOSPAM steps.
- Analyser codes — the full reference for every R- and D- code.
- How to analyse a requirement — running DeFOSPAM step by step.
- What is REQQA? — the product that applies the technique.