Testable Requirement¶
Verification criterion — instantiates Functional Specification
States a single expected behavior in a form a specific test can confirm or refute — a given precondition and stimulus paired with the exact postcondition that must result — so 'did it work?' has one unambiguous answer.
A Testable Requirement is a statement of expected behavior written so that a concrete test can show whether it is met. It pairs a precondition and a defined stimulus with the exact postcondition that must follow, and it names the observable evidence — the acceptance check — that decides the question. Its defining move is verifiability: the requirement is phrased so that a demonstration, inspection, or test yields a single unambiguous pass or fail, with no room for "sort of." That is what separates it from an aspiration ("the system shall be reliable") and from a Service-Level Definition: the service-level promise is a statistical threshold measured continuously over many events, while a testable requirement is a discrete check on one specified behavior under one specified condition.
Example¶
A municipality procuring survey drones needs its requirements written so a vendor's delivery can be accepted or rejected without argument. One reads: "Given a fully charged standard battery at an ambient temperature of 15°C, when the drone flies the defined survey pattern at cruise, then it shall remain airborne for at least 25 minutes." The verification method is a field flight test run under exactly that condition; a unit that lands at 24 minutes fails, unambiguously, and one that makes 26 passes. Compare the draft this replaced — "the drone shall have good battery life" — which no test could ever settle, because "good" names no condition, no stimulus, and no threshold. The discipline of writing a requirement so that a single test decides it is the entire difference between a specification you can accept against and a wish you can only argue about.
How it works¶
The requirement fixes three things: a precondition and stimulus (the "given" and "when"), the exact postcondition that must result (the "then"), and a named verification method — test, inspection, demonstration, or analysis — that produces the pass/fail. It keeps to one behavior per requirement so the outcome is never ambiguous, and it states the criterion objectively enough to be falsified. The Given-When-Then[n1] shape, and the older engineering habit of the verifiable "shall" statement, are the standard forms; both exist to force the question "how would we know?" to have an answer before the requirement is accepted.
Tuning parameters¶
- Granularity — one behavior per requirement or several bundled. Fine-grained requirements verify cleanly; bundled ones are shorter but blur what failed.
- Verification method — test, inspection, demonstration, or analysis. Stronger methods give more confidence and cost more to run.
- Tolerance band — how much slack the postcondition allows (exactly 25 minutes vs. ≥25). Tight bands are strict; wider bands admit acceptable variation.
- Positive vs. negative — whether the requirement also states what must not happen. Negative cases catch failures a happy-path test would miss.
When it helps, and when it misleads¶
Its strength is that it makes acceptance objective: procurement, quality assurance, contracts, and even education can hang a decision on it because the pass/fail is not a matter of opinion. Its failure modes are two. The requirement can be written so it is not actually verifiable — vague or unfalsifiable — so no test can settle it and the "requirement" quietly means whatever the reader wants. Or the specifier writes down only the easily measurable behaviors, so important qualitative behavior disappears from the spec entirely, creating false precision. The related misuse is satisfying the literal test while missing its intent — teaching to the test. The discipline is to require a named verification method for every requirement (if you cannot say how it would be checked, it is not yet a requirement) and to include negative and boundary cases so the test measures the intended behavior rather than a convenient proxy for it.
How it implements the components¶
acceptance_test— the named, observable check (test, inspection, or demonstration) that confirms or refutes the stated behavior; the evidence that the requirement was met.precondition_postcondition_pair— the given precondition and stimulus, and the exact postcondition that must result, stated as a single falsifiable claim.
It verifies one behavior but does not declare the input_domain it must accept or run the edge_case_handling that routes bad cases (that is Input Validation), bound the output_codomain of a model (that is Model Specification), or watch a live observability_signal over time the way a Service-Level Definition does — its check is discrete and falsifiable, not a running metric.
Related¶
- Instantiates: Functional Specification — it makes one expected behavior explicit and checkable.
- Sibling mechanisms: Service-Level Definition · Input Validation · Model Specification · API Specification · Policy Implementation Rule · Clinical Protocol Definition · Type Signature · Output Schema · Role Charter
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Testable Requirement is defined in the frozen evidence as: States a single expected behavior in a form a specific test can confirm or refute — a given precondition and stimulus paired with the exact postcondition that must result — so 'did it work?' has one unambiguous answer. Its operative deployed or enacted form is therefore Representation, Specification & Plan.
Nearest alternative: Rule, Policy & Commitment — Rule, Policy & Commitment can support this mechanism, but the evidence centers the concrete operation described above rather than the alternative family's defining operation.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Testable requirement derives most directly from engineering's design, reliability, interface, and lifecycle tradition; its defining operation is to states a single expected behavior in a form a specific test can confirm or refute — a given precondition and stimulus paired with the exact postcondition that must result — so 'did it work?' has one unambiguous answer.
Related originating lineages:
- Computer Science & Software Engineering — Computer science and software-engineering practice supplies a parallel or contributing lineage for the mechanism's defining operation: states a single expected behavior in a form a specific test can confirm or refute — a given precondition and stimulus paired with the exact postcondition that must result — so 'did….
- Law & Governance — Legal doctrine, regulatory governance, and procedural accountability supplies a parallel or contributing lineage for the mechanism's defining operation: states a single expected behavior in a form a specific test can confirm or refute — a given precondition and stimulus paired with the exact postcondition that must result — so 'did….
- Systems Thinking & Cybernetics — Systems science's feedback, stock-flow, boundary, and regulation tradition provides a formative adjacent lineage for the same testable requirement operation.
Review resolution: Both blind reviewers independently select engineering_design as the primary historical origin for the concrete operation—States a single expected behavior in a form a specific test can confirm or refute — a given precondition and stimulus paired with the exact postcondition that must result — so 'did it work?' has one unambiguous answer. The queued differences concern alternate origin disagreement, origin mode disagreement, domain reach disagreement, encyclopedia synthesis disagreement, not the primary lineage. I retain every alternate that either reviewer explains, without a numeric cap, and choose origin_mode=cross_disciplinary_synthesis because the reviewers' combined evidence identifies material construction from multiple disciplines. domain_reach=universal records later portability rather than multiplying historical origins; confidence=high is the conservative shared evidentiary level, and encyclopedia_synthesis=true preserves either reviewer's affirmative synthesis finding.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] A core rule of requirements engineering (e.g., INCOSE's characteristics of a good requirement) is that every requirement must be verifiable — stated so a specific test, inspection, demonstration, or analysis can show it is met or not. "The system shall be user-friendly" fails this test; "shall remain airborne for at least 25 minutes" passes. The Given-When-Then structure popularized by behavior-driven development is one common way to write a requirement in that falsifiable form. ↩