StoryQ/Gherkin for Automotive Requirements

Automotive requirements are often written as statements.

For example:

The vehicle shall remain stable during emergency braking.

That sounds precise enough.

But several questions immediately remain.

Under what road conditions?

At what speed?

With what vehicle load?

What does “stable” mean?

What event triggers the requirement?

What observable result proves that the requirement has been satisfied?

ZenOps treats this as a problem of transformation.

A human need must eventually become something that reality can answer.

The chain is:

Human Need → NDD → Requirement → Scenario → Test → Evidence

StoryQ/Gherkin provides a particularly useful bridge between the requirement and the test.

Its simple structure is:

Given → When → Then

The syntax is easy to read, but its implications for automotive engineering are significant.

It turns a static requirement into a description of behavior under defined conditions.

From Human Need to Scenario

Suppose the original human need is:

I need the vehicle to remain controllable when I brake on an icy road.

The Need Definition Document might contain:

Maintain vehicle controllability on low-friction surfaces.

An engineering requirement might refine that into:

The vehicle shall maintain defined directional-control performance during braking under specified low-friction conditions.

StoryQ/Gherkin can then express the intended behavior:

Scenario: Emergency braking on a low-friction surface
Given the vehicle is travelling within the specified speed range
And the road surface has the defined low friction condition
When the driver applies emergency braking
Then the vehicle shall decelerate within the defined performance limits
And directional controllability shall remain within the accepted limits

We now have something much more useful than an isolated sentence.

We have a situation that can eventually be reproduced.

Given Describes Reality Before the Event

Automotive behavior depends heavily on context.

A battery behaves differently at -25°C than at +20°C.

A tire behaves differently on dry asphalt than on ice.

A vehicle behaves differently when fully loaded.

Therefore the Given part of a scenario is extremely important.

Examples might include:

Given the ambient temperature is within the specified cold-test range

or:

Given the battery state of charge is within the defined operating window

or:

Given the vehicle is travelling on a road surface with the specified friction level

The Given statement describes the starting state of the relevant part of reality.

Without it, many automotive requirements are incomplete.

When Defines the Trigger

The When statement defines what happens.

This might be a human action:

When the driver presses the brake pedal

an environmental event:

When the outside temperature falls below the defined threshold

a system event:

When communication with the wheel-speed sensor is lost

or a physical failure:

When the coolant pump stops operating

The trigger provides an explicit transition from one state to another.

This is especially useful in systems containing many sensors, controllers, software states, and actuators.

Then Defines What Must Become True

The Then statement expresses the expected outcome.

For example:

Then the braking system shall enter the defined degraded mode

or:

Then the battery temperature shall remain within the specified safe range

or:

Then a diagnostic event shall be recorded

The strongest Then clauses describe something that can eventually be observed or measured.

This is where the scenario begins connecting directly to evidence.

A Requirement Becomes a Question

This reveals an important ZenOps interpretation.

A StoryQ/Gherkin scenario is essentially a question to the system:

Given this state of reality, when this event happens, will the vehicle produce the expected result?

The test later asks that question.

Reality provides the answer.

The chain becomes:

Requirement
    ↓
Scenario
    ↓
Question to the System
    ↓
Test
    ↓
Result
    ↓
Evidence

This turns requirements into something much more active.

Example: Cold-Weather Start

Suppose the NDD contains:

Provide reliable winter transportation.

One resulting scenario might be:

Scenario: Start vehicle after cold soak
Given the vehicle has remained at the defined cold-soak temperature
And the battery is within the permitted state-of-charge range
When the driver requests vehicle start
Then the vehicle shall reach the defined ready state
Within the specified maximum time
And no safety-critical fault shall prevent normal operation

This can later be verified using:

• Simulation
• Hardware-in-the-loop testing
• Environmental chamber testing
• Full-vehicle testing

The test technology may change.

The behavioral intent remains the same.

Example: Windshield Defrost

Consider the need:

Maintain driver visibility during winter operation.

A scenario could become:

Scenario: Restore windshield visibility after frosting
Given the vehicle has been exposed to the defined cold condition
And the windshield has the specified frost coverage
When the driver activates the defrost function
Then the defined visibility area shall become clear
Within the specified maximum time

The requirement now has context, trigger, and measurable result.

Example: Battery Overtemperature

Failure behavior is especially important.

Scenario: Battery exceeds normal operating temperature
Given the battery is operating within the normal temperature range
When the measured battery temperature exceeds the defined threshold
Then the thermal system shall request the required cooling response
And battery power shall be limited according to the defined strategy
And the diagnostic system shall record the event

This scenario crosses several domain objects:

Battery

Temperature Sensor

Battery Controller

Thermal System

Diagnostic System

StoryQ therefore naturally fits the ORIGIN object-and-relation model.

Example: Sensor Failure

Suppose one wheel-speed sensor becomes unavailable.

Scenario: Wheel-speed sensor becomes unavailable
Given all wheel-speed sensor signals are initially valid
And the vehicle is moving
When one wheel-speed signal becomes unavailable
Then the system shall detect the loss of the signal
And the affected control function shall enter the defined degraded mode
And the diagnostic system shall record the fault
And no unsafe control command shall be generated

This is much more useful than simply writing:

The vehicle shall tolerate wheel-speed sensor failure.

The scenario forces us to define what tolerance actually means.

Gherkin Exposes Ambiguity

Consider the requirement:

The driver shall be warned when battery energy is low.

Try to write the scenario.

Immediately questions appear.

What is “low”?

How is available energy calculated?

When exactly should the warning appear?

What happens if temperature temporarily changes the estimated range?

Does the warning disappear again?

The requirement might become:

Scenario: Low usable-energy warning
Given the vehicle is operating normally
And usable energy is above the defined warning threshold
When usable energy falls below the defined threshold
Then the low-energy warning shall be presented to the driver
Within the specified response time

StoryQ/Gherkin therefore does not merely document requirements.

It helps discover where requirements are incomplete.

One Requirement Can Produce Many Scenarios

Consider:

The vehicle shall charge safely.

One scenario is not enough.

The requirement might generate scenarios for:

• Normal charging
• Cold-weather charging
• High-temperature charging
• Communication failure
• Loss of grid power
• Connector removal
• Battery fault
• Thermal-system failure
• Interrupted charging
• Recovery after interruption

Each scenario explores a different part of the same requirement space.

This creates systematic coverage.

Scenario Outlines Handle Variation

Some behavior must be tested under several conditions.

Gherkin can express this using a scenario outline.

Scenario Outline: Vehicle startup at low temperature
Given the vehicle has stabilized at <temperature>
When the driver requests vehicle start
Then the vehicle shall reach the ready state
Within <maximum_start_time>
Examples:
| temperature | maximum_start_time |
| T1          | S1                 |
| T2          | S2                 |
| T3          | S3                 |

The precise values can remain controlled engineering parameters.

The behavioral pattern remains readable.

Keep Engineering Parameters Separate

Gherkin should not become a replacement for engineering data.

A poor scenario might contain dozens of values:

Voltage
Current
Pressure
Temperature
Torque
Speed
Timing

until the behavioral logic disappears.

It is often better to write:

Given the battery is in the defined nominal operating condition

and allow the referenced test or requirement definition to specify the detailed numeric ranges.

StoryQ captures behavior.

Engineering data defines exact limits.

Requirements and Scenarios Are Different Objects

The requirement should still have its own identity.

For example:

REQ-02841
Loss of valid wheel-speed information shall
be detected within the defined diagnostic time.

The corresponding scenario might be:

Scenario: Detect missing wheel-speed information
Given the wheel-speed signal is initially valid
When the signal becomes unavailable
Then the system shall detect the missing signal
Within the defined diagnostic time

The relationship can be modeled as:

Requirement
   verified by
Scenario

The scenario does not erase the requirement.

It makes the required behavior explicit.

Connect StoryQ to ORIGIN

Because ZenOps already models the vehicle as objects and relations, the scenario can reference the same domain.

For example:

Wheel-Speed Sensor
    reports to
Vehicle Controller
Vehicle Controller
    controls
Brake System
Diagnostic System
    observes state of
Wheel-Speed Sensor

The Gherkin scenario then describes a change propagating through that object network.

This creates consistency between:

domain model

and:

behavior model.

Patterns Can Contain Scenario Templates

The ZenOps Pattern Library can also store reusable StoryQ/Gherkin patterns.

Suppose the engineering pattern is:

Detect → Isolate → Report → Recover

It may carry scenario templates such as:

Scenario: Detect failure
Given the component is operating normally
When the defined failure occurs
Then the system shall detect the failure

followed by:

Scenario: Enter degraded mode
Given the failure has been detected
When normal operation can no longer be maintained
Then the system shall enter the defined degraded state

and:

Scenario: Recover after failure condition disappears
Given the system is in the defined degraded state
When the recovery conditions become valid
Then the system shall recover according to the defined strategy

Now the Pattern Library carries not only architectural knowledge but verification knowledge.

Gherkin Can Generate WBS Work

Once a scenario exists, work becomes visible.

Suppose the scenario says:

When the temperature sensor fails, the thermal system shall enter degraded control.

That may generate work to:

• Implement failure detection
• Implement degraded control
• Create diagnostic reporting
• Create test instrumentation
• Inject the failure
• Verify the response
• Record evidence

The behavioral scenario therefore helps generate the Work Breakdown Structure.

StoryQ and FLEXI

StoryQ also fits naturally with FLEXI micro-sprints.

Instead of assigning:

Work on charging software.

a micro-sprint can say:

Make charging scenario SCN-042 pass.

The work becomes bounded:

Scenario
↓
Implementation
↓
Test
↓
Result
↓
Evidence

This gives the engineer an explicit target.

StoryQ and Quality Thresholds

Scenarios can also contribute directly to QT.

Suppose the Winter Operation QT requires:

Cold Start
Windshield Visibility
Traction
Braking
Battery Heating
Charging

Each item may have several StoryQ scenarios.

The evidence hierarchy becomes:

NDD
↓
Requirement
↓
Scenario
↓
Test
↓
Evidence
↓
QT

A Quality Threshold PASS is therefore backed by specific behavior that has been demonstrated.

PASS Becomes More Meaningful

Compare:

Winter operation: 90% complete.

with:

Cold Start                 PASS
Windshield Defrost         PASS
Low-Friction Braking       PASS
Battery Heating            PASS
Cold Fast Charging         FAIL
Sensor Icing               UNKNOWN

The second representation gives the team useful engineering knowledge.

StoryQ/Gherkin makes this possible because the expected behavior has been broken into explicit scenarios.

Manufacturing Can Use the Same Approach

StoryQ/Gherkin need not stop at vehicle behavior.

Consider a battery installation process:

Scenario: Install correct battery pack
Given the vehicle identity is known
And the approved battery pack for the vehicle configuration is available
When the battery pack is installed
Then the mechanical connections shall satisfy the defined specification
And electrical connections shall be verified
And thermal connections shall be verified
And the battery identity shall be associated with the vehicle identity

The same behavioral logic can describe manufacturing.

Supplier Requirements Can Become Scenarios

Suppose a supplier provides a controller.

Instead of only specifying interfaces in prose, a behavioral scenario might state:

Scenario: Recover after communication interruption
Given the controller is operating normally
When communication is interrupted for the defined duration
And communication is restored
Then the controller shall return to the defined operational state
Without requiring a complete vehicle restart

The supplier now receives an observable behavioral expectation.

Service Can Use StoryQ Too

Consider component replacement:

Scenario: Replace failed drive module
Given diagnostics identify the drive module as faulty
When an approved replacement module is installed
Then the replacement identity shall be recorded
And the required software configuration shall be applied
And the verification procedure shall pass
And the vehicle service history shall be updated

The same conceptual method now spans engineering, manufacturing, and service.

Field Failures Should Become New Scenarios

One of the most valuable uses of StoryQ is regression learning.

Suppose field vehicles reveal a failure nobody anticipated.

The organization investigates.

The cause is understood.

Then a new scenario should often remain behind:

Field Failure
↓
Root Cause
↓
Requirement Update
↓
New Scenario
↓
Regression Test
↓
Permanent Organizational Knowledge

A failure should not merely be repaired.

It should teach the engineering system something.

Every Important Bug Can Become Memory

Suppose charging fails only after:

• Cold soak
• Communication interruption
• Recovery attempt

Once discovered, the condition can become:

Scenario: Charging recovers after cold communication interruption
Given the vehicle is at the defined low temperature
And charging is operating normally
When the charging communication is interrupted
And communication is restored
Then charging shall recover according to the defined recovery behavior

Future vehicle versions can rerun this scenario.

The mistake becomes less likely to return.

Scenario Identity Enables Traceability

Each scenario can receive its own identity:

SCN-001 Cold Start
SCN-002 Windshield Defrost
SCN-003 Sensor Failure
SCN-004 Low-Friction Braking

Relations can then connect:

NDD Need
   ↓
Requirement
   ↓
Scenario
   ↓
Test
   ↓
Evidence
   ↓
QT

Now the scenario becomes a first-class object in the ZenOps domain model.

A Shared Language Across Disciplines

Perhaps the greatest advantage of Given/When/Then is its readability.

Automotive programs include:

• Domain experts
• Systems engineers
• Mechanical engineers
• Electronics engineers
• Software developers
• Test engineers
• Manufacturing engineers
• Suppliers
• Product owners
• Project managers

Not everyone can read control software.

Not everyone can interpret a detailed mechanical specification.

But many people can understand:

Given this condition, when this happens, then the vehicle must behave like this.

This creates a common behavioral language across disciplines.

StoryQ Turns Stories Into Questions

StoryQ can be interpreted as a progression:

Story
↓
Question
↓
Scenario
↓
Experiment
↓
Evidence

A customer says:

I need the car to work reliably in winter.

ZenOps structures that through the NDD.

Engineering produces requirements.

StoryQ asks:

What situation would demonstrate whether the requirement is actually true?

Gherkin expresses the situation.

Testing asks the question physically.

Reality answers.

The Complete ZenOps Chain

The automotive ZenOps flow can now become:

HUMAN REALITY
      ↓
      x
      ↓
     NDD
      ↓
REQUIREMENTS
      ↓
 STORYQ
      ↓
GIVEN / WHEN / THEN
      ↓
   TEST
      ↓
 EVIDENCE
      ↓
     QT
      ↓
 RELEASE

The crucial transformation happens in the middle.

Requirements stop being passive statements.

They become questions that can be asked of the system.

Reality Gets the Final Word

This may be the most important reason for using StoryQ/Gherkin in automotive ZenOps.

A requirement can look convincing on paper.

A design can look correct in CAD.

Software can compile.

Simulation can predict success.

But sooner or later we need to ask:

Given the real conditions the vehicle must face, when the relevant event occurs, does the system actually behave as intended?

StoryQ/Gherkin gives us a disciplined way of writing that question.

Testing provides the experiment.

Evidence provides the answer.

And ZenOps keeps the entire chain connected back to the original human need.

That is the purpose of StoryQ/Gherkin for automotive requirements:

to transform what we hope the vehicle will do into behavior precise enough for reality to confirm or reject.