4. Requirements engineering

Occupant safety targets are written at the vehicle level: "FMVSS 208 belted 50th-percentile male, 56 km/h frontal rigid barrier, HIC ≤ 700, chest deflection ≤ 42 mm, femur load ≤ 10 kN." These are outcomes. A restraint system engineer cannot design an airbag, a pretensioner, or a load limiter directly from an outcome. Requirements engineering is the discipline that converts those outcomes into a hierarchy of verifiable, traceable, and testable statements that a design team can actually build against — and that a validation team can objectively pass or fail.

The Requirements Hierarchy

Restraint requirements live in a layered structure. Each layer is derived from the one above it, and each layer must be verifiable at its own level of abstraction.

• Level 0 — Regulatory and consumer targets. FMVSS 208, FMVSS 226, ECE R94/R95, Euro NCAP, C-IASI. These are fixed, non-negotiable, and externally defined. They specify test mode, barrier type, impact speed, occupant size, and injury criteria thresholds.
• Level 1 — Vehicle-level occupant protection requirements. Derived from Level 0 plus internal targets (e.g., "meet Euro NCAP 2026 frontal MPDB with a minimum 0.5-star margin"). These are still outcome-based but now include the specific vehicle architecture, mass, and crash pulse.
• Level 2 — System-level restraint requirements. These describe what the restraint system as a whole must do: "Deploy driver airbag within 25 ms of ECU trigger," "Achieve chest deflection ≤ 35 mm at 56 km/h FRB for the 50th-percentile male," "Limit seat belt force to 4.5 kN ± 0.5 kN during the load-limiting phase."
• Level 3 — Component and subsystem requirements. These are the design team's daily working requirements: airbag inflator mass flow rate, vent hole diameter, pretensioner stroke, load limiter torsion bar diameter, seat belt webbing elongation, anchor point geometry.

The critical rule is that every Level 3 requirement must trace upward to a Level 2 requirement, which traces to Level 1, which traces to Level 0. If a component requirement cannot be traced to a regulatory or consumer target, it is either unnecessary or the traceability matrix has a gap.

Writing Verifiable Requirements

A requirement is verifiable only if it contains four elements: a subject, a condition, a metric, and a threshold. Consider the difference:

The second statement can be tested. The first cannot. In restraint engineering, vague requirements are the most common source of late-stage validation failures, because the design team interprets "quickly" as 40 ms while the validation team expects 25 ms.

Common verifiability traps in restraint systems include:

• Missing occupant reference: "Chest deflection shall not exceed 42 mm" — for which occupant? 5th-percentile female? 50th-percentile male? 95th-percentile male? Each has a different rib cage stiffness and seating position.
• Missing test mode: "The pretensioner shall fire in frontal impacts" — at what speed? What barrier? What offset? A 40 km/h ODB and a 56 km/h FRB produce very different trigger timing requirements.
• Ambiguous timing reference: "Deploy within 25 ms" — 25 ms from what? From impact? From ECU trigger? From first acceleration pulse? The reference point must be explicitly defined and consistent across all requirements.
• Unbounded tolerances: "Load limiter force shall be approximately 4 kN" — approximately is not a threshold. Specify 4.0 kN ± 0.5 kN.

From Targets to Requirements: A Worked Example

Assume a vehicle-level target: Euro NCAP frontal MPDB at 50 km/h, 50th-percentile male, chest deflection ≤ 35 mm (internal target, 5 mm margin below the 40 mm Euro NCAP threshold). The restraint system includes a seat belt with pretensioner and load limiter, plus a driver airbag.

The derivation proceeds as follows:

1. Identify the injury mechanism. Chest deflection is driven by belt force applied to the rib cage. The load limiter controls this force.
2. Estimate the required force level. Using a simplified spring-mass model of the chest (stiffness ~150 N/mm for the 50th-percentile male), a 35 mm deflection corresponds to approximately 5.25 kN of belt force. To leave margin for dynamic effects and belt geometry, set the load limiter target at 4.5 kN ± 0.5 kN.
3. Translate to component requirement. The load limiter torsion bar diameter, material yield strength, and belt payout length are specified to achieve 4.5 kN ± 0.5 kN over the payout range of 80–120 mm.
4. Define the verification method. Component-level: sled test with a 50th-percentile male ATD, measuring belt force at the retractor and chest deflection via chest band. System-level: full vehicle MPDB test, same measurements.
5. Establish traceability. The torsion bar diameter requirement traces to the load limiter force requirement, which traces to the chest deflection target, which traces to the Euro NCAP MPDB protocol.

This chain is the essence of requirements engineering: every design decision has a documented reason, and every validation test has a documented purpose.

Traceability Matrix Structure

A traceability matrix is not a single table — it is a relational structure that links requirements across levels and to verification evidence. The essential columns are:

Requirement ID	Requirement Text	Source / Parent ID	Verification Method	Test ID / Evidence	Status
L1-FR-001	Chest deflection ≤ 35 mm, 50th male, MPDB 50 km/h	Euro NCAP TB-012	Full vehicle test	FV-MPDB-007	Open
L2-RS-014	Load limiter force 4.5 kN ± 0.5 kN over 80–120 mm payout	L1-FR-001	Sled test + component bench	SL-LL-003	Open
L3-LL-002	Torsion bar diameter 6.2 mm ± 0.05 mm, material 11SMnPb30	L2-RS-014	Dimensional inspection + bench pull	BENCH-LL-011	Open

The matrix must be bidirectional: from any Level 3 requirement, you can trace upward to the regulatory target; from any regulatory target, you can trace downward to the components that satisfy it. Gaps in either direction are risks.

Verification Methods and Evidence

Each requirement must specify its verification method. In restraint engineering, the standard methods are:

• Analysis: CAE simulation (LS-DYNA, PAM-CRASH) with validated occupant models. Used for early design iteration, not for final regulatory compliance.
• Inspection: Dimensional check, material certification, visual examination. Used for Level 3 component requirements.
• Demonstration: Functional test of a subsystem (e.g., pretensioner firing time, airbag deployment pressure curve).
• Test: Physical sled or full vehicle test with instrumented ATDs. The definitive verification for Level 1 and Level 2 requirements.

The evidence must be linked to the requirement ID. A requirement without evidence is an open risk. A test without a linked requirement is wasted resources.

Common Pitfalls in Restraint Requirements Engineering

Practical Implementation: The Requirements Review Gate

In a well-run restraint program, requirements engineering is not a one-time activity. It is gated. At each program milestone (concept freeze, design freeze, validation start), the traceability matrix is reviewed for:

• Completeness: Every Level 0 target has at least one Level 1 requirement. Every Level 1 requirement has at least one Level 2 requirement. Every Level 2 requirement has at least one Level 3 requirement.
• Consistency: No two requirements contradict each other. For example, a load limiter force requirement of 4.5 kN and a belt force requirement of 3.5 kN cannot both be true.
• Verifiability: Every requirement has a defined verification method and a planned test or analysis.
• Traceability: Every requirement has a parent and at least one child (except Level 0, which has no parent, and Level 3, which may have no child if it is a leaf component specification).

The output of this review is not a report — it is a decision. Either the requirements are mature enough to proceed, or specific gaps are assigned to owners with due dates. This is how occupant safety targets become verifiable restraint system requirements: through disciplined, traceable, and testable engineering.