2. Requirements engineering fundamentals for occupant safety

Occupant safety requirements rarely originate from a single author. They arrive from legislation, from consumer rating programmes, from internal platform strategies, and from field data. Requirements engineering in this domain is therefore less about writing sentences and more about reconciling heterogeneous sources into a verifiable, traceable specification that a restraint control module, a seat structure, and a crash simulation team can all work against. This chapter establishes the three foundations that everything later depends on: how requirements are elicited from regulations and ratings, what makes an individual requirement well-formed, and how traceability links are structured so that verification evidence can be shown to close the loop.

Eliciting from Regulations: Obligation, Test Procedure, and Acceptance Criterion

A regulation is not a requirement. It is a legal text containing several distinct artefacts that must be separated before they can be engineered. Consider a frontal impact regulation: it defines a scope (vehicle categories, seating positions, test configurations), a test procedure (barrier type, impact speed with tolerance, dummy type, belt configuration, seat position), and acceptance criteria (injury criteria thresholds measured at specified locations). Each of these becomes a different kind of engineering object.

The practical elicitation pattern is to decompose each regulatory clause into a triplet: obligation (what the vehicle must guarantee), verification method (how conformity is demonstrated), and acceptance criterion (the numeric threshold and its measurement location). For example, a clause mandating a head injury criterion limit under a 50 km/h frontal barrier impact decomposes into an obligation on the restraint system and interior geometry, a verification method of a full-scale sled or vehicle crash test with a specified dummy, and an acceptance criterion expressed as HIC₁₅ ≤ threshold measured at the dummy head centre of gravity. Writing this as a single sentence such as "the vehicle shall comply with frontal impact regulation" is a common and costly error: it is untestable, unallocatable, and impossible to trace to a subsystem.

Two elicitation disciplines matter here. First, capture tolerances and boundary conditions explicitly. Impact speed is typically specified with a tolerance band, and the barrier offset, seat track position, and belt anchorage geometry are all part of the test definition. A requirement that omits these cannot be reproduced. Second, record the regulatory source with clause-level granularity — regulation identifier, revision or amendment level, and clause number — because regulations are amended, and a trace link to "the regulation" without a revision is worthless during a change impact analysis.

Eliciting from Consumer Ratings: Turning Scores into Design Targets

Consumer rating programmes differ fundamentally from regulations. They are voluntary, they evolve on shorter cycles, and they express results as scores rather than pass/fail thresholds. Elicitation therefore requires a translation step: the rating protocol's scoring tables must be converted into engineering targets that the design can be optimised against.

A workable approach is to build a score-to-target mapping. For each assessed body region and crash mode, the protocol defines point bands against measured injury values. The engineering team selects a target score, then reads back the corresponding injury value band and adopts the lower bound of the next band up as the design target, creating margin against test-to-test variation. If, for instance, a protocol awards full points below a given injury value and reduced points above it, a team targeting full points should design to a value meaningfully below the threshold — not at it — because a single test run is a sample, not a mean.

Rating protocols also introduce requirements that regulations often leave open: far-side occupant protection, post-crash eCall behaviour, active bonnet deployment, and child presence detection. These are frequently derived requirements with no direct regulatory parent, and they must be traced to the rating clause and to the internal design decision that adopted them.

Specification Quality Criteria

An individual requirement is well-formed when it satisfies a small set of properties that can be checked mechanically or in review. The following table summarises the criteria used in occupant safety specifications, with the failure mode each one prevents.

Two of these deserve emphasis in occupant safety. Singularity is frequently violated when a requirement bundles a performance threshold with a diagnostic behaviour, for example "the airbag shall deploy within the specified time and illuminate the warning lamp on fault." These are two obligations with two verification methods and must be split. Boundedness is violated whenever a requirement omits the occupant state it applies to — belted or unbelted, 5th percentile female or 95th percentile male, out-of-position or in-position. The same restraint system can satisfy a requirement for a belted 50th percentile occupant and fail it for an unbelted small occupant; without the state in the requirement text, neither result is meaningful.

A useful review heuristic is the stranger test: hand the requirement to an engineer outside the programme and ask them to state the verification setup. If they must ask a question, the requirement is not yet bounded or unambiguous.

Traceability Principles

Traceability is the ability to navigate from a source obligation to the design element that satisfies it and onward to the verification evidence that proves it — and back again. In occupant safety the trace chain typically runs through five levels: source (regulation clause or rating protocol clause), stakeholder or system requirement, subsystem requirement (restraint control, seat structure, interior trim, pyrotechnic device), design element (CAD part, calibration parameter set, software function), and verification artefact (test report, simulation correlation report, bench test record).

Three principles govern how these links are built. First, every requirement must have at least one upstream link; an orphan requirement is either unnecessary or its source has been lost, and both cases require resolution. Second, every source obligation must have at least one downstream requirement; a regulation clause with no derived requirement is a compliance gap waiting to be discovered at type approval. Third, links must be typed — satisfies, derives, verifies, refines — because a verification link and a derivation link carry different meanings during impact analysis.

The value of traceability is realised during change. When a rating protocol raises a threshold, the impact analysis walks downstream from the affected clause through derivation links to the affected subsystem requirements, then through satisfies links to the design elements, then through verifies links to the test cases that must be re-run. Without typed links, this walk degenerates into a manual search and the change is either missed or over-applied.

Putting the Three Foundations Together

The three foundations are interdependent. Elicitation without quality criteria produces a long list of unverifiable statements. Quality criteria without traceability produce well-written requirements that nobody can prove are complete. Traceability without disciplined elicitation produces a beautifully linked structure rooted in a misread regulation clause.

A concrete way to exercise all three is to take one regulatory clause and one rating clause and build the chain by hand. Decompose the regulation clause into obligation, verification method, and acceptance criterion, and record the revision level. Convert the rating clause into a design target with margin. Write the resulting system requirement in singular, bounded form, stating occupant state, impact configuration, and tolerance. Then allocate it to at least two subsystem requirements, link each to a design element, and link each design element to a verification artefact. Finally, ask what happens if the rating threshold moves by one band: the answer should be a finite, enumerable set of requirements and test cases reachable by following typed links. If that set cannot be enumerated, the trace structure is decorative rather than functional.

With these foundations in place, the specification becomes an engineering instrument rather than a compliance document: it can be reviewed against objective criteria, allocated to subsystems with confidence, and re-verified efficiently when regulations or rating protocols change.