3. Requirements engineering and traceability for virtual delivery

In a virtual engineering program, the requirement is the single source of truth from which every model, test case, and simulation scenario derives its legitimacy. When a vehicle program runs on simulation rather than physical prototypes, there is no hardware to fall back on as an implicit specification. If a braking performance target exists only in a slide deck, no one can prove that the CAE model, the MIL test bench, or the HIL rig actually validated it. Requirements engineering and traceability are therefore not documentation overhead — they are the mechanism that makes virtual evidence admissible.

This chapter examines how three tooling paradigms support that mechanism: IBM Engineering Requirements Management DOORS (and DOORS Next), Siemens Polarion, and model-based systems engineering (MBSE) environments such as SysML-based tools. The goal is not to compare feature lists but to understand what each contributes to a traceable virtual delivery chain, and how to build one in practice.

What Traceability Actually Requires

Traceability is the ability to navigate, in both directions, from a stakeholder need to the artifact that satisfies it and back again. In a virtual delivery context, the chain typically has five links:

• Stakeholder requirement — e.g., "The vehicle shall stop from 100 km/h on dry asphalt within 38 m."
• System requirement — decomposed and allocated, e.g., "The friction brake system shall provide a minimum deceleration of 9.5 m/s² at 80% pedal travel."
• Design/model element — the SysML block, Simulink subsystem, or FMU that implements the allocation.
• Verification case — the simulation scenario, test bench configuration, or analysis that produces evidence.
• Evidence/result — the report, dataset, or pass/fail record generated by execution.

Each link must be a typed, queryable relationship, not a hyperlink buried in a document. The practical test is simple: given a failed simulation result, can you traverse upward to the requirement it violates and sideways to every other verification case covering that requirement? If the answer requires opening three tools and searching manually, the chain is broken.

DOORS and DOORS Next: The Baseline Discipline

DOORS (Dynamic Object-Oriented Requirements System) established the module-and-object model that most requirements tools still follow. A module is a structured container; each requirement is an object with a unique absolute number, attributes, and typed links. DOORS Next extends this to a web-based, OSLC-enabled platform with configuration management.

The strength of DOORS in virtual delivery is its rigor around baselines and suspect links. When a requirement changes, every downstream link is flagged as suspect, forcing a review before the change propagates. In a program where a single mass target change can invalidate dozens of CAE load cases, this flagging is what prevents silent divergence between the requirement set and the simulation matrix.

A typical DOORS workflow for a virtual program:

1. Import the stakeholder requirement set into a module with attributes: ID, Text, Priority, Verification Method (Analysis / Test / Inspection / Demonstration), Status.
2. Decompose into system requirements, creating typed links of type derives from.
3. Create a baseline (e.g., BR-2024-Q3) before releasing to the simulation team.
4. Link each system requirement to verification cases via verified by links, where the target object is a test case module entry.
5. Run a traceability query to produce a coverage matrix before each design review.

The limitation is that DOORS is document-centric. It knows nothing about the model structure. The link to a Simulink block or a SysML element must be maintained externally, which is where OSLC or MBSE integration becomes necessary.

Polarion: ALM Integration and Live Traceability

Polarion approaches the same problem from the application lifecycle management (ALM) side. Its differentiator is the LiveDoc — a document-like view backed by a relational database, where every requirement, test case, and defect is a work item with a stable ID. Because requirements and test management live in the same repository, traceability is native rather than bridged.

For virtual delivery, Polarion's value is the tight coupling between requirement, test case, and test run. A test case can be linked to a requirement, executed against a simulation or HIL run, and the result recorded with a timestamp and artifact reference. The traceability matrix then reflects actual execution status, not just planned coverage.

Consider a concrete example. A requirement REQ-BRK-0142 states the 38 m stopping distance target. In Polarion:

Work Item: REQ-BRK-0142
  Type: System Requirement
  Verification Method: Analysis
  Linked Test Cases:
    TC-BRK-SIM-007  (MIL, dry asphalt, 100-0 km/h)
    TC-BRK-SIM-008  (MIL, wet asphalt, 100-0 km/h)
    TC-BRK-HIL-003  (HIL, dry asphalt, 100-0 km/h)
  Linked Defects:
    DEF-2211  (ABS calibration overshoot at low mu)
  Trace Status: 3/3 executed, 2 passed, 1 failed

When TC-BRK-SIM-008 fails, the defect DEF-2211 is linked back to the requirement, and the trace status immediately shows partial coverage. This is the operational meaning of live traceability: the requirement's status is a function of its verification results, updated automatically.

MBSE: Making the Model the Traceability Backbone

MBSE shifts the center of gravity from documents to models. In a SysML environment, requirements are model elements (<<requirement>>), and traceability is expressed through standard relationships: <<deriveReqt>>, <<satisfy>>, <<verify>>, and <<allocate>>. Because the model is the source, traceability is structural rather than maintained by hand.

The critical advantage for virtual delivery is that the model element and the simulation artifact can be the same object. A SysML block that satisfies a requirement can be the same block from which a Simulink model or FMU is generated. When the requirement changes, the model's satisfy relationship is re-evaluated, and the impact on the simulation configuration is visible in the model itself.

A minimal SysML traceability pattern:

requirement StoppingDistance {
  id = "REQ-BRK-0142"
  text = "Vehicle shall stop from 100 km/h within 38 m on dry asphalt."
}

requirement BrakeDeceleration {
  id = "REQ-BRK-0143"
  text = "Friction brake shall provide >= 9.5 m/s^2 at 80% pedal travel."
}

// Derivation
BrakeDeceleration deriveReqt StoppingDistance

// Satisfaction
BrakeSystem satisfy BrakeDeceleration

// Verification
BrakeSimCase verify StoppingDistance

The practical challenge is tool interoperability. A SysML model in one tool, a Simulink model in another, and a requirements repository in a third must exchange these relationships. OSLC (Open Services for Lifecycle Collaboration) is the standard answer: it defines REST-based resources and link types so that a DOORS Next requirement can be linked to a Polarion test case or a SysML element without proprietary bridges.

Choosing and Combining

In practice, most organizations combine them. DOORS or DOORS Next holds the contractual requirement baseline. Polarion or an equivalent ALM layer manages test cases and execution status. The MBSE model provides the design-side traceability and generates the simulation configuration. OSLC links stitch the three together.

A Practical Traceability Check

Before a virtual design review, run this check against the requirement set:

1. Every system requirement has at least one verified by link. Requirements with zero links are unverified — flag them.
2. Every verification case links to at least one requirement. Orphan test cases waste simulation budget.
3. Every requirement with Verification Method = Analysis has a corresponding simulation scenario with a defined pass criterion.
4. Every failed test run has a linked defect, and the defect links back to the requirement.
5. No suspect links remain unresolved after the last baseline.

If any check fails, the virtual evidence for that requirement is not defensible. The simulation may have run, but the program cannot claim the requirement was verified.

The diagram above shows the full chain as it exists in a combined toolchain. The requirement layer is owned by DOORS Next, the design layer by the MBSE environment, and the verification layer by the ALM system. The dashed red path is the feedback loop that matters most: a failed simulation result must propagate back to the requirement it violates, not disappear into a test report. When that loop is closed and queryable, virtual delivery has a defensible evidence chain. When it is not, the program is running simulations without knowing what they prove.