4. Customer requirements capture

In automotive restraint programs, the customer's requirements arrive as a layered document set: a Statement of Requirements (SOR), a Request for Quotation (RFQ) package, and a stack of referenced technical specifications and standards. These documents are written by the OEM for procurement and engineering governance purposes, not for supplier execution. The program manager's first substantive task is therefore not scheduling or staffing — it is requirements capture: converting customer intent into a controlled, traceable, internally actionable set of program deliverables. If this translation is weak, every downstream activity (design, DV/PV testing, tooling, PPAP) inherits ambiguity that surfaces later as change orders, test failures, or launch delays.

Understanding the Three Input Layers

The three input layers serve different purposes and carry different authority levels.

• SOR (Statement of Requirements): The OEM's functional and performance expectations for the restraint system — occupant protection targets, deployment requirements, environmental ranges, interface constraints, and program milestones. It is the "what must the system do" document.
• RFQ (Request for Quotation): The commercial and programmatic wrapper — volumes, timing, sourcing assumptions, cost breakdown structure, and the required response format. It defines "what must the supplier commit to and how."
• Technical specifications and standards: The detailed "how it must be built and verified" layer — material specs, connector and harness standards, EMC requirements, and test standards such as FMVSS 208, ECE R94/R95, or OEM-specific test procedures.

A critical discipline: the SOR and RFQ are customer-authored and may conflict with each other or with referenced standards. Requirements capture must surface these conflicts explicitly rather than silently choosing one interpretation.

From Customer Documents to Program Deliverables

The translation process follows a consistent logic regardless of restraint commodity (airbag module, seat belt assembly, pretensioner, or occupant classification system):

1. Decompose each customer requirement into discrete, uniquely identifiable statements.
2. Classify each statement by type — functional, performance, interface, regulatory, or commercial.
3. Assign ownership to a responsible function (design, test, manufacturing, quality, purchasing).
4. Map to a deliverable — a drawing, a test report, a DFMEA line, a control plan item, or a milestone gate.
5. Define verification — the method (analysis, inspection, demonstration, test) and the acceptance criterion.

The output is a requirements traceability matrix (RTM) that becomes the backbone of the program. Every subsequent design review, test plan, and change request references the RTM.

Worked Example: Airbag Module SOR Capture

Consider a simplified SOR clause for a driver-side airbag module:

SOR Clause 4.3.2:
"The driver airbag module shall deploy within 30 ms after receipt of a valid
crash signal at 25°C ± 5°C, and shall meet occupant injury criteria per
FMVSS 208 for a 50th percentile male in a 56 km/h frontal barrier test."

RFQ Section 7.1:
"Supplier shall provide DV test reports per OEM-TP-208-01 by program
milestone M6. Cost breakdown shall separate module, inflator, and
harness content."

Decomposition yields distinct requirement IDs:

Note that REQ-002 references an external standard (FMVSS 208) and an OEM test procedure (OEM-TP-208-01). The capture process must attach the current revision of each referenced document. A common failure mode is capturing the requirement text but not the revision level, leading to testing against a superseded procedure.

Handling Conflicts and Gaps

Real SOR/RFQ packages contain conflicts. Typical examples in restraint programs:

• SOR specifies a deployment temperature range that is narrower than the referenced test standard requires.
• RFQ milestone dates are earlier than the test duration required by the technical specification.
• The SOR references a connector standard that is not compatible with the OEM's current harness drawing.

These must be logged as open issues with a formal clarification request (CR) to the customer. The program manager should not resolve them unilaterally. Each CR should state the conflict, the affected requirement IDs, the impact if unresolved, and a proposed resolution with a response deadline.

Deliverable: Requirements Capture Worksheet

The following worksheet structure is directly usable for any restraint commodity. It is intentionally minimal — only fields that drive program execution.

Verification and Closure

Requirements capture is not complete when the matrix is populated. It is complete when each requirement has a closed verification loop: the deliverable exists, the verification method has been executed, and the acceptance criterion has been evaluated. In practice, this means the RTM is a living document reviewed at every program gate.

For the worked example, closure of REQ-001 requires a bench deployment test at the specified temperature, with timing measured and compared against the 30 ms limit. If the measured value is, for example, 32 ms, the requirement is not met — and the program must either initiate a design change or request a deviation. The RTM records the outcome, not just the plan.

A practical check for program managers: at any point in the program, you should be able to answer three questions for every requirement — Who owns it? What deliverable proves it? What is the current verification status? If any answer is missing, the requirement is not truly captured.

The diagram above shows the complete capture chain: customer inputs are decomposed into discrete requirements, structured into an RTM, mapped to program deliverables, and closed through verification. Conflicts and gaps feed a parallel clarification track that must be resolved before requirements can be considered captured. The dashed feedback line from verification back to the RTM reflects that the matrix is a living document — status changes as evidence is produced.

In practice, the most common program management failure in this phase is treating the SOR and RFQ as reference documents rather than as controlled inputs requiring systematic decomposition. The second most common is allowing requirements to remain "open" without a linked clarification request, which creates invisible risk that surfaces during DV testing or PPAP. A disciplined capture process — with unique IDs, revision control, ownership, and verification linkage — converts customer documents into a program execution framework that the entire cross-functional team can work from.