Building the Automotive Need Definition Document (NDD)

In the previous step, we asked the most important question at the beginning of automotive development:

What problem is the car actually supposed to solve?

ZenOps calls this search finding x.

But discovering x is only the beginning.

A statement such as:

A family needs safe, reliable and affordable transportation throughout the year.

is useful, but it is nowhere near detailed enough to design a vehicle.

Hundreds or thousands of needs are hidden inside that sentence.

They must be discovered.

They must be organized.

They must be made explicit.

This is the purpose of the Need Definition Document — NDD.

From x to Structure

The ZenOps process can be viewed as:

x → NDD → ORIGIN → Patterns → Architecture → Implementation → Evidence

The NDD occupies a critical position.

On one side is reality.

On the other side is engineering.

The NDD is the bridge.

Its purpose is not to describe the car we intend to build.

Its purpose is to describe, as precisely as possible, what reality requires from the eventual solution.

That distinction prevents us from jumping prematurely from problem to technology.

Start With the Root Need

Every NDD begins with a root.

For our example:

Provide safe, reliable and affordable year-round personal transportation.

This becomes the root node of the automotive NDD.

Below it, we begin asking:

What must become true for this need to be satisfied?

The answer immediately branches.

Provide Personal Transportation
│
├── Transport People
├── Transport Goods
├── Reach Destinations
├── Protect People
├── Operate Reliably
├── Operate in Expected Environments
├── Remain Economically Viable
└── Provide an Acceptable Human Experience

We have not designed anything yet.

There is no engine.

There is no electric motor.

There is no battery.

There are no wheels.

There is not even a formal assumption that the solution must be a conventional automobile.

We are still describing need.

Decompose the Need

Each node can now be expanded.

Consider:

Transport People

This might become:

Transport People
│
├── Transport Driver
├── Transport Adult Passengers
├── Transport Children
├── Accommodate Child Seats
├── Allow Entry
├── Allow Exit
└── Accommodate Personal Belongings

Another branch might be:

Operate in Expected Environments
│
├── Operate in Summer
├── Operate in Winter
│   ├── Start in Low Temperatures
│   ├── Travel on Snow
│   ├── Travel on Ice
│   ├── Maintain Cabin Temperature
│   └── Maintain Visibility
│
├── Operate in Rain
├── Operate in Darkness
├── Operate on Public Roads
└── Resist Expected Environmental Exposure

Notice what is happening.

The original sentence is becoming a tree of needs.

Complexity is not being removed.

It is being made visible.

Safety Becomes a Need Tree

Safety provides another example.

Writing:

The vehicle must be safe

is almost meaningless from an engineering perspective.

What does safe mean?

The NDD forces us to decompose the concept.

Protect Human Life
│
├── Prevent Accidents
│   ├── Maintain Controllability
│   ├── Maintain Visibility
│   ├── Detect Relevant Hazards
│   └── Communicate Vehicle Intent
│
├── Reduce Collision Probability
│
├── Protect Occupants During Collision
│   ├── Protect Head
│   ├── Protect Torso
│   ├── Protect Lower Body
│   └── Restrain Occupants
│
├── Protect Other Road Users
│   ├── Pedestrians
│   ├── Cyclists
│   └── Other Vehicles
│
└── Support Emergency Response

Each level makes the original need more explicit.

Eventually these needs can become sufficiently precise to drive architecture, engineering and testing.

Needs Are Not Components

This distinction is fundamental.

Suppose somebody adds the following node:

Install eight airbags.

That is not a pure need.

It is a proposed implementation.

The underlying need might instead be:

Reduce occupant injury during defined collision conditions.

Airbags may eventually become part of the solution.

But they belong later in the reasoning chain.

Likewise:

100 kWh battery

is not a need.

Four-wheel drive

is not a need.

ABS

is not a need.

Heat pump

is not a need.

LIDAR

is not a need.

These are technologies or architectural choices.

The NDD should first capture why such technologies might become necessary.

Ask “Why?” Upward

There is a simple way to test an NDD node.

Ask:

Why does this need exist?

The answer should normally point upward through the tree.

For example:

Maintain Windshield Visibility
        ↑
Operate Safely in Snow
        ↑
Operate in Winter
        ↑
Provide Year-Round Transportation

This creates a chain of justification.

Later, when an engineering solution appears, the chain can continue downward:

Provide Year-Round Transportation
        ↓
Operate in Winter
        ↓
Operate Safely in Snow
        ↓
Maintain Windshield Visibility
        ↓
Remove Snow / Ice / Condensation
        ↓
Heating + Airflow + Wipers
        ↓
Specific Components

Now the engineer can answer:

Why does this component exist?

The answer is traceable.

Add Context to the NDD

Needs do not exist in isolation.

They exist under conditions.

A vehicle intended for northern Scandinavia might face:

• Sub-zero temperatures
• Snow
• Ice
• Road salt
• Long distances
• Rural roads
• Darkness
• Limited service infrastructure in some locations

A vehicle intended primarily for a dense city may instead face:

• Congestion
• Short journeys
• Limited parking
• Frequent stopping
• Pedestrians
• Cyclists
• Restricted urban space

The physical world therefore changes the NDD.

This is exactly what should happen.

The product must adapt to reality rather than forcing reality into a predefined product.

Add Quantification Carefully

As the NDD matures, qualitative needs can become measurable.

For example:

Carry passengers

may become:

Accommodate five occupants.

Travel long distances

might eventually become:

Support a defined journey profile without unacceptable interruption.

Operate in cold weather

might become:

Remain operational at -30°C.

Carry luggage

might become:

Provide at least X litres of usable luggage capacity.

But quantification should have a reason.

Why -30°C?

Why five occupants?

Why a particular cargo volume?

The answer should come from x, observation, market evidence, regulation, safety analysis or another justified source.

Otherwise arbitrary numbers begin masquerading as requirements.

Separate Need From Requirement

This also reveals an important distinction.

A need describes what must become true.

A requirement constrains how success will be judged.

For example:

Need:

The occupants must remain acceptably comfortable during winter travel.

Possible requirement:

The passenger compartment must reach a defined temperature within a defined time under specified environmental conditions.

The requirement is more precise.

But it still exists because of the need.

The chain becomes:

Reality → Need → Requirement → Solution → Test → Evidence

Build Traceability Into the NDD

Every meaningful node should eventually receive an identity.

For example:

NDD-001  Provide Personal Transportation
NDD-010  Protect Occupants
NDD-011  Prevent Avoidable Collisions
NDD-012  Maintain Vehicle Control
NDD-020  Operate Year-Round
NDD-021  Operate in Winter
NDD-022  Maintain Visibility in Snow
NDD-030  Maintain Economic Viability

Now downstream objects can reference these identities.

An engineering specification might reference NDD-022.

A test case might reference NDD-022.

A defect might reference the same node.

A field failure could eventually reference it too.

The original human need remains connected to the physical vehicle.

The NDD Is a Living Structure

The NDD should not be treated as a document written once and forgotten.

Learning changes our understanding.

Suppose winter testing reveals that snow accumulates somewhere unexpected.

The team discovers a need that was previously invisible.

The NDD changes.

Suppose customer observation reveals that elderly passengers have difficulty entering the vehicle.

A new need appears.

The NDD changes.

Suppose field data reveals a failure mode under environmental conditions that were underestimated.

Again:

the NDD changes.

This is not necessarily failure.

It is learning.

ZenOps expects the model to become better as contact with reality increases.

The NDD Can Become the Backbone of the Vehicle Program

This leads to a powerful possibility.

Instead of organizing the vehicle program primarily around departments, documents and component lists, we can organize its knowledge around the NDD.

Imagine selecting:

NDD-022 — Maintain Visibility in Snow

and immediately seeing:

• Why the need exists
• Parent needs
• Child needs
• Related ORIGIN objects
• Relevant patterns
• Requirements
• Responsible engineering systems
• Components
• Software
• Tests
• Test results
• Quality Threshold status
• Manufacturing dependencies
• Field evidence

The NDD then becomes much more than a requirements document.

It becomes an entry point into the knowledge structure of the vehicle.

From Tree to Object Network

Eventually the hierarchy reaches a limit.

Reality is not purely hierarchical.

One need may affect several systems.

For example:

Reduce energy consumption

might affect:

• Aerodynamics
• Tires
• Vehicle mass
• Thermal management
• Power electronics
• Motor efficiency
• Software
• Driver interface

The NDD therefore begins as a useful tree, but downstream ZenOps modeling expands the structure into networks of objects and relations.

This is where ORIGIN becomes important.

The NDD tells us:

what must become true.

ORIGIN begins asking:

what objects exist, and how are they related?

From Human Need Toward Engineering

We can now see the first stages of automotive ZenOps clearly.

REALITY
   ↓
Find x
   ↓
Human Need
   ↓
NDD Root
   ↓
Need Decomposition
   ↓
Context
   ↓
Quantification
   ↓
Traceability
   ↓
ORIGIN
   ↓
Patterns
   ↓
Architecture
   ↓
Engineering
   ↓
Vehicle

The important point is that engineering has still not been allowed to dominate the process prematurely.

We first construct an explicit representation of why the product should exist.

Only then do we decide what the product should contain.

Before the Bill of Materials Comes the Bill of Needs

Automotive manufacturing eventually requires an extraordinarily detailed Bill of Materials.

Every bolt, connector, sensor, controller, wire, seat, bearing and structural element must ultimately be accounted for.

ZenOps suggests that something should exist before that:

a Bill of Needs.

The Bill of Materials answers:

What is the vehicle made from?

The NDD answers:

Why must the vehicle become what it becomes?

The first without the second gives us an extraordinarily detailed description of a machine.

The two together give us something more valuable:

a traceable explanation of the machine.

And that is the purpose of the Automotive Need Definition Document.

Before we build the car, we build the structure of the need.

Because if we cannot explain precisely what must become true, we are not yet ready to decide precisely what must be built.