From Customer Wishes to Engineering Requirements

Customers do not speak engineering.

They say:

“I want a safe car.”

“It should be cheap to run.”

“I don’t want to worry about range.”

“It needs to work in winter.”

“There should be enough room for the family.”

“I want it to feel good on the road.”

None of these statements can be handed directly to an engineering team and implemented.

What exactly is safe?

How cheap is cheap?

How much range is enough?

What does work in winter mean?

And how do we test whether a car feels good?

Yet these statements are enormously valuable.

They contain the reason the vehicle should exist.

The challenge is therefore not to replace customer language with engineering language.

The challenge is to transform one into the other without losing meaning.

In ZenOps, this transformation begins with x, becomes structured through the Need Definition Document (NDD), and eventually produces requirements that engineering can implement and evidence can verify.

The chain is:

Customer Reality → x → Need → Requirement → Engineering → Test → Evidence

The requirement is therefore not the beginning.

It is a transformation of something that came before.

Listen to the Customer Before Listening to the Technology

Suppose a customer says:

“I need a car that works reliably during a Norwegian winter.”

An engineering organization could immediately begin thinking about batteries, heaters, insulation, tires, traction control, corrosion protection and thermal-management systems.

But that jumps ahead.

First we need to understand the statement.

What does the customer actually experience?

Perhaps the customer means:

• The vehicle must start after being parked outside overnight.
• Doors must open after freezing rain.
• Windows must become clear.
• The cabin must become comfortable.
• The vehicle must remain controllable on snow.
• Energy consumption must not make normal journeys impractical.
• Road salt must not rapidly destroy the vehicle.
• Sensors must continue functioning in snow and slush.

The single customer statement has revealed an entire family of needs.

This is why ZenOps separates explication from implementation.

Before solving the problem, make the problem explicit.

Customer Wishes Are Signals

A customer wish should not automatically become a requirement.

Consider:

“I want a huge battery.”

That sounds specific, but it is already a proposed solution.

The useful question is:

Why?

Perhaps the customer replies:

“Because I regularly drive 350 kilometres to visit my family and I don’t want to stop twice.”

Now we have discovered something much more useful.

The real need concerns journey completion and interruption, not battery capacity.

A large battery is one possible response.

Other factors might include:

• Vehicle efficiency
• Charging speed
• Charging availability
• Temperature
• Route characteristics
• Reserve requirements
• Driving speed

The customer’s proposed solution has therefore been transformed back into a need.

This preserves engineering freedom.

Move From Wishes to Needs

Suppose we collect these customer wishes:

“Make it safe.”

“Give me plenty of space.”

“Make it good in winter.”

“Keep the running costs low.”

“I don’t want charging to become annoying.”

The NDD can begin translating them into structured needs.

For example:

Provide Useful Family Transportation
│
├── Protect Occupants
│   ├── Reduce Collision Risk
│   └── Reduce Injury During Collision
│
├── Transport Family and Possessions
│   ├── Accommodate Required Occupants
│   └── Accommodate Required Cargo
│
├── Support Winter Operation
│   ├── Operate at Low Temperature
│   ├── Maintain Visibility
│   ├── Maintain Traction
│   └── Maintain Occupant Comfort
│
├── Maintain Economic Viability
│   ├── Limit Energy Cost
│   ├── Limit Maintenance Cost
│   └── Limit Unexpected Repair Cost
│
└── Support Practical Long-Distance Travel
    ├── Provide Sufficient Usable Range
    └── Limit Energy-Replenishment Disruption

We have moved from subjective statements toward structured needs.

But we are not yet finished.

A Need Is Not Yet an Engineering Requirement

Consider:

Maintain occupant comfort during winter operation.

This is a legitimate need.

But an engineer still cannot prove that it has been satisfied.

We therefore need another transformation.

The organization must define what success means under specified conditions.

A requirement might eventually take a form such as:

Under defined ambient-temperature, initial-temperature and operating conditions, the passenger compartment shall reach the specified target temperature within the specified maximum time.

Now we have something engineers can work with.

More importantly, we have something testers can verify.

The transformation is:

“I don’t want to freeze.”

↓

Maintain occupant thermal comfort.

↓

Define acceptable thermal conditions.

↓

Define operating scenario.

↓

Define measurable requirement.

↓

Design thermal system.

↓

Test.

↓

Evidence.

The human meaning has not disappeared.

It has become measurable.

Good Requirements Need Context

A number without context can be almost as dangerous as no number at all.

Suppose someone writes:

Vehicle range shall be 500 km.

Under what conditions?

At what temperature?

At what speed?

With what load?

Using what measurement procedure?

With what battery condition?

With heating or air conditioning operating?

A requirement becomes useful when the conditions surrounding the measurement are sufficiently explicit.

The same principle applies throughout the vehicle.

“Stop within X metres” is incomplete without test conditions.

“Reach cabin temperature Y” is incomplete without starting conditions.

“Carry Z kilograms” is incomplete without defining where and under what configuration.

Engineering requirements therefore describe not merely desired values, but the conditions under which those values have meaning.

Requirements Must Be Traceable Upward

Every important requirement should be able to answer:

Why do you exist?

Consider a hypothetical requirement concerning windshield defrosting.

Its reasoning chain might be:

Human:
“I need to see where I'm going in winter.”
        ↓
Need:
Maintain Driver Visibility
        ↓
Sub-Need:
Remove or Prevent Windshield Obstruction
        ↓
Requirement:
Achieve Defined Visibility Under
Specified Frosting Conditions
        ↓
Engineering:
HVAC + Glass + Airflow + Heating
+ Controls + Software
        ↓
Verification:
Environmental Test
        ↓
Evidence:
Measured Visibility Performance

Now the engineering requirement has context.

If somebody later proposes changing the HVAC system, the team can see what needs may be affected.

If a test fails, the failure can be traced upward.

If field evidence reveals poor winter visibility, the information can travel back through the same structure.

Requirements Must Also Be Traceable Downward

Traceability works in both directions.

Starting from a human need, we should eventually be able to discover which parts of the vehicle participate in satisfying it.

For example:

Protect occupants during collision

might connect to:

• Body structure
• Seats
• Seat belts
• Airbags
• Sensors
• Control electronics
• Software
• Interior geometry
• Glass
• Doors

One need can therefore influence many engineering systems.

Conversely, one component can satisfy many needs.

A camera might contribute to parking, collision avoidance, lane assistance and driver visibility.

This is why automotive engineering eventually becomes a network rather than a simple hierarchy.

Avoid Premature Implementation Requirements

There is an important difference between:

The vehicle shall prevent wheel lock during defined braking conditions.

and:

The vehicle shall contain component X from supplier Y.

The second statement may eventually be necessary for manufacturing.

But it belongs much further downstream.

ZenOps tries to delay unnecessary commitment.

At the need level, preserve the problem.

At the requirement level, define required behavior and constraints.

At the architecture level, decide how systems collaborate.

At the implementation level, select technologies and components.

This creates a progression:

Need → What must become true

Requirement → What must be demonstrably achieved

Architecture → How responsibilities are distributed

Implementation → What we actually build

Evidence → Whether it actually works

Requirements Can Conflict

Real automotive development becomes difficult because customer wishes are not independent.

Customers may simultaneously want:

More range.

Lower price.

Lower weight.

More space.

Better crash protection.

More performance.

Lower energy consumption.

These wishes can pull the design in different directions.

A larger battery might increase range but also increase:

• Cost
• Mass
• Material consumption

Additional structural reinforcement might improve one crash scenario while increasing mass.

Greater performance might conflict with efficiency or cost targets.

The purpose of structured requirements is not to pretend these conflicts do not exist.

It is to make them visible.

Priorities Must Come From the Need

When requirements conflict, the organization must make trade-offs.

ZenOps provides a useful anchor:

Return to x.

Which problem are we solving?

For whom?

Under what conditions?

What outcomes matter most?

If the target is inexpensive urban transportation, one set of trade-offs follows.

If the target is long-distance family transportation in a cold rural region, another follows.

If the target is emergency medical transportation, the priorities change dramatically.

There is no universally correct automobile.

There is only a vehicle that is more or less appropriate for a defined x.

Every Requirement Should Eventually Meet Reality

A requirement without verification is merely a statement.

For each significant requirement, we should eventually ask:

How will we know?

That question may produce:

• Inspection
• Calculation
• Simulation
• Component testing
• Software testing
• Hardware-in-the-loop testing
• Crash testing
• Environmental testing
• Road testing
• Manufacturing inspection
• Field evidence

This gives us the full reasoning chain:

Customer Wish
      ↓
Human Need
      ↓
NDD
      ↓
Engineering Requirement
      ↓
Architecture
      ↓
Implementation
      ↓
Verification
      ↓
Evidence

At the end, reality answers the question.

Quality Threshold Instead of “Probably Good Enough”

This is where the ZenOps Quality Threshold — QT becomes important.

A requirement should not be considered satisfied simply because engineering work has been completed.

It should cross a defined threshold of evidence.

The question changes from:

Are we finished designing this?

to:

Do we have sufficient evidence that this satisfies the need?

That is a fundamentally different definition of progress.

A completed CAD model is not evidence that the physical component survives reality.

Completed software is not evidence that the control system behaves correctly.

A manufactured prototype is not evidence that customers’ needs have been satisfied.

Completion describes activity.

Evidence describes reality.

Customer Language Should Never Disappear

By the time a vehicle reaches production, the organization may possess millions of pieces of engineering information.

CAD models.

Software.

Requirements.

Simulation results.

Test reports.

Manufacturing instructions.

Supplier specifications.

Quality records.

The danger is that somewhere inside this enormous technical structure, the original human reason for the vehicle disappears.

ZenOps attempts to prevent this.

Imagine selecting an engineering requirement and being able to navigate upward:

Requirement → Need → Parent Need → x → Original Customer Context

and downward:

Requirement → Architecture → Component → Test → Evidence → Field Result

Now engineering knowledge forms a continuous chain.

The Customer Does Not Specify the Car

The customer provides something more valuable.

The customer provides evidence about the world in which the car must succeed.

Engineering then transforms that information.

A customer says:

“I need enough room for my family.”

ZenOps asks:

What does that mean?

The NDD structures the answer.

Engineering quantifies it.

Architecture allocates responsibility.

Design implements it.

Testing measures it.

Manufacturing reproduces it.

And the customer ultimately decides whether the resulting vehicle actually works in life.

That gives us the complete transformation:

Wish → Understanding → Need → Requirement → Solution → Evidence

The goal is not to turn customers into engineers.

Nor is it to allow engineers to guess what customers meant.

The goal is to create an explicit, traceable transformation between the two worlds.

Because a successful vehicle is not the one that contains the most technology.

It is the one in which technology can ultimately answer a much simpler question:

Did we solve the problem the human actually had?