When we maintain only a trace link between a requirement and a test case, we know the link exists and nothing else. We do not know whether the two artifacts agree. A trace link and an agreement between two artifacts are different things, and the two checks are separate in VDA guidance.
When our requirement and test diverge, the cost usually lands at audit, in rework of the verification package and findings against the traceability objectives. Executable specifications remove that ambiguity by making the requirement itself the artifact that runs. This guide covers how executable specifications connect Easy Approach to Requirements Syntax (EARS) requirements, Given-When-Then scenarios, regulated verification evidence, and artificial intelligence (AI)-assisted development.
What Is an Executable Specification?
An executable specification is a requirement written so a test runner can execute it directly. The plain-language statement is the test, and a layer of step definitions connects each clause to the code that exercises it. Strip out the automation and a living specification is still there. Strip out the plain-language intent and all that is left is brittle test code.
In a regulated program the approved requirement text has to survive into the executable layer unchanged. The trace link then records which scenario verifies which requirement, and a reviewer reading the scenario is reading the approved requirement itself rather than a developer’s restatement of it. An assessor asking to see the link is checking for exactly that property.
Specification by Example emerged alongside early executable acceptance-testing frameworks such as the Framework for Integrated Test (FIT). BDD followed, and Given-When-Then grew out of collaborative work at ThoughtWorks. Gojko Adzic’s book Specification by Example later established living documentation as the name for the output.
Gherkin, the grammar Cucumber reads, keeps the scenario readable with the runner removed, and step definitions hold the execution detail. The split lets a systems engineer review a scenario without reading any code, and lets a scenario survive a change of test framework, because only the step definitions are framework-specific.
Map EARS Requirements to Given-When-Then Scenarios
Three of the six EARS patterns map onto Given-When-Then almost clause for clause. Free-form requirements don’t convert cleanly into tests, which is why EARS exists. Developed at Rolls-Royce, it constrains natural language with a fixed clause order and a small keyword vocabulary, the same kind of constraint Given-When-Then imposes. The pattern set covers ubiquitous, state-driven, event-driven, optional-feature, unwanted-behavior and complex requirements. Ubiquitous is identified by the absence of a keyword and complex by the presence of more than one. The other four each carry a single keyword. Several of them land in Gherkin almost clause for clause:
Take an event-driven requirement written to the EARS template:
| EARS pattern | Requirement template | Gherkin mapping |
|---|---|---|
| Event-driven | When [trigger], the [system] shall [action] | Given sets pre-conditions; When carries the trigger; Then holds the response |
| State-driven | While [state], the [system] shall [action] | Given holds the state; When holds the implicit trigger; Then holds the required behavior |
| Unwanted behavior | If [condition], then the [system] shall [action] | Given or When carries the fault condition; Then carries the required response |
When the cell temperature exceeds the shutdown threshold, the battery management system shall open the main contactor within 100 ms.
The scenario is the same statement with its clauses redistributed:
Nothing there is new information. The trigger became When, the response became Then, and Given carries the pre-conditions the requirement left implicit. The pre-conditions are the part worth arguing about in review, because an unstated one is where two engineers agree on a sentence and disagree on what it means. Behind those five lines sit step definitions holding the rig setup, the temperature ramp and the contactor state read. None of that appears in the specification, and the specification is what the systems engineer signs.
Syntax alone doesn’t stop a well-formed EARS statement from producing a meaningless test. Singular statements and combinators bear directly on testability, and that is where the EARS pattern deliberately leaves the details open. The INCOSE writing guide covers both.
We should express a single thought in each requirement and avoid joining multiple obligations with terms such as “and,” “or,” “then,” and “unless.” If we write a requirement that combines obligations, the scenario checks multiple things at once. A green result then can’t say which obligation held, so the quality check belongs at authoring time, before any scenario exists.
Why a Green Suite Is Not Coverage Evidence
A green Gherkin suite is requirements-based verification evidence. It is not structural coverage evidence, and no standard lets one stand in for the other.
DO-178C and its hardware counterpart DO-254, International Organization for Standardization (ISO) 26262, International Electrotechnical Commission (IEC) 62304, and ISO 13485 all require requirements-based verification evidence. DO-178C calls for requirements-based testing and traceability between requirements and tests. ISO 26262 expects safety requirements to connect to their origins and downstream verification evidence, while IEC 62304 requires documented software testing procedures and results linked to requirements. ISO 13485, as incorporated into 21 CFR Part 820 under the Quality Management System Regulation, calls for records of verification methods, acceptance criteria, results, and conclusions, so we need evidence that connects each verification result to the applicable requirement.
DO-178C draws the line precisely enough that it is worth reading twice, because requirements-based coverage confirms only that the selected tests satisfy specified criteria. Structural coverage confirms that those tests actually exercised the code to the applicable criterion, and Design Assurance Level A adds Modified Condition/Decision Coverage (MC/DC) on top. Only a coverage tool produces the second number, and a scenario runner has no way to produce it.
A third obligation sits behind both, and teams building a Gherkin suite tend to meet it last:
- DO-330: A tool credited with achieving a DO-178C objective, where its output will not be independently verified, has to be qualified.
- ISO 26262 Part 8: Tool confidence is determined from the tool’s potential impact and the likelihood that its errors will be detected, which in turn determines whether qualification is needed.
For our programs, any BDD runner whose output we cite without review sits inside those considerations. We therefore need to assess how we use the runner and whether its errors would be detected.
When the Requirement Changes After the Scenario Goes Green
A scenario passes against the requirement it was written from, not the requirement as it stands today. Teams should write scenarios before the code because BDD depends on conversation, and notation alone is insufficient. Writing scenarios after the code creates a risk that they will couple to the interface and compound brittleness. As the scenario count grows, each flaky test creates another opportunity for an unrelated failure to make the full suite unreliable.
A passing scenario needs change-controlled reassessment the moment the requirement changes after the scenario turns green. Without a recorded relationship between the two, nothing tells the test lead which scenarios to look at, and the suite keeps reporting green against a requirement that no longer exists.
The operational cost of that gap often becomes visible at a formal review gate. If relationships among requirements, scenarios, and results have not been kept current, the team must determine which scenarios were affected by changes and reassess them before closing the evidence package.
Loram encountered this challenge while working toward EN 50128 compliance. The company had been managing requirements, testing, and changes in Word and Excel, contributing to long project timelines and, in some cases, as much as a year to close a project gate. After adopting Jama Connect®, Loram reported up to a 24% reduction in software-gate engineering hours.
For cyber-physical systems, Given-When-Then scenarios can feed simulation and Hardware-in-the-Loop (HIL) test generation according to the assigned verification method. The scenario stays at the observable system boundary and the rig supplies the execution detail, so the same scenario survives on a desktop simulator and on target hardware. Only the step definitions change underneath; the specification the engineer approved does not.
Govern AI-Generated Specifications for Regulated Programs
AI-generated scenarios can enter a regulated verification package after human review. An industrial study of large language model (LLM) generated acceptance tests for web applications found 92% of generated cases useful, but only 60% were usable as written: 8% needed minor fixes and 24% had to be regenerated with additional input. A third of the suite still failed to land first time, which is a good result, and it is the argument for keeping a reviewer in the loop. Because faults in generated code can be replicated in tests written from the same model, domain experts still need to validate generated tests, and the specification has to come before the code.
Unspecified AI-generated tests aren’t ISO 26262 evidence. An AI-generated unit test that was not written from a specified, traceable test condition needs additional analysis before it can support ISO 26262 evidence. LLM-based test generation tools also remain subject to the applicable tool-qualification framework when their output replaces verification work without manual review.
When agents write the code, the specification becomes the governing input, and spec-driven development frameworks structure the work around version-controlled specifications. Some take each feature through a fixed sequence of phases, from specification and planning through task breakdown to implementation, against a set of project-level principles. OpenSpec is lighter: each change gets its own folder holding proposal.md, delta specs, design.md and tasks.md, and moves through explore, propose, apply, sync and archive. Spec drift is the documented failure mode: an agent changes the code, the specification is not updated, the tests continue to pass, and the divergence is never flagged.
For AI-generated software, regulated programs need traceable provenance among the approved specification, generated code, and verification result. Tooling in this space is converging on the same idea, that a specification which executes cannot silently drift from the behaviour it describes. A functional safety program still has to show where each artifact came from. Where an agent’s output carries no record of which model produced it, under which prompt, and who approved it, an auditor has nothing to assess it on. An undocumented human-written artifact has always been in that position, and neither one gets credit for intent.
How Jama Connect Supports Executable Specifications
Jama Connect is a web-based requirements management and traceability platform for complex, regulated product development, and it is the foundation that becomes the Product Context Layer. Jama Connect connects requirements, risks, tests, Systems Modeling Language (SysML) models, code, simulations and verification evidence into a governed system of record, organized by the Traceability Information Model (TIM), which defines how those artifacts relate. The Model Context Protocol (MCP) Server add-on, released 4 May 2026 with Jama Connect 9.35 for cloud and self-hosted deployments, exposes that model to external AI agents and LLM-powered tools.
Jama Connect addresses each of the three problems covered above: mapping, evidence and change. For the mapping problem, Jama Intelligence scores each requirement against 30 of the 40 INCOSE rules and 6 EARS syntax patterns as we write, catching the compound, multi-thought statements that make a scenario untestable, and generates up to ten test cases that are created and linked only when an engineer accepts them. For the evidence problem, built-in test management holds the requirement-to-test results an assessor asks for, and sits alongside the structural coverage report without replacing it. And for the change problem, suspect links mark every test case linked to a requirement that has changed, which is how the test lead knows which scenarios to reassess without rereading the suite. Anything done with AI inside Jama Connect is versioned and documented as AI-generated, which is an audit trail an external chat tool cannot produce.
Getting Started With Executable Specifications
Start with the verification method. Requirements assigned to test can become executable scenarios, while those assigned to analysis, inspection or demonstration need separate evidence paths. A verification method belongs on every requirement from the outset, and the traceability matrix gets populated during planning while there is still something to trace.
For a requirement triggered by an event, we can begin with the EARS template “When [trigger], the [system] shall [action].” We then apply the EARS-to-Gherkin mapping above. The systems engineer can confirm the intent while the V&V engineer checks that the response is observable and suitable for automation.
The team should then review the scenario before implementation. If your suites are green, the open question is what they are green against. You can check that against your own requirement set and see it in action with a spec-driven development demo.
Frequently Asked Questions About Executable Specifications
How do ATDD and BDD differ?
ATDD and BDD share the executable-example idea and can produce similar outcomes despite differences in emphasis. The primary need determines the choice. ATDD establishes a concrete acceptance target; BDD supports collaborative discovery and a shared description of behavior across roles.
Can executable specifications describe hardware behavior?
Yes, at the specification layer, with the runner kept separate from it. The Object Management Group (OMG) approved SysML v2 for final adoption on July 21, 2025, and it lets systems engineers specify analysis and verification cases that check whether a system satisfies its requirements. Simulink requirements tables can place formal pass/fail criteria inside the test environment itself. The scenario should remain at the observable system boundary, while simulation or HIL equipment supplies the execution detail on target hardware.
Do executable specifications satisfy structural coverage objectives?
No, and the two evidence paths have to run in parallel from the outset: scenario results trace to requirements, structural coverage reports trace to code. The part teams miss is retention: capture the coverage report at each release or audit checkpoint and keep the matching baseline, so a later review can establish exactly which code and which build the number covered.
Who should write the scenario, the systems engineer or the test engineer?
Scenario authorship is shared. A practical ownership convention is for the systems engineer to own the intent and preconditions, the software developer to check implementation feasibility, and the V&V engineer to own observable acceptance criteria and the automation handoff. The team should also name one maintainer who reassesses the scenario when a suspect link appears.
