Hands-On: Bidirectional Traceability Setup

This hands-on exercise walks through building a complete bidirectional traceability structure for a realistic automotive ECU project. You will create and link requirements, architecture components, design units, and test cases at every level of the V-model - the way ASPICE expects it to be done on a real project.

Bidirectional traceability means every item can be followed in both directions:

• Downward (derivation): From OEM stakeholder requirement → system requirement → software requirement → architectural component → design unit → unit test
• Upward (verification): From unit test → design unit → software requirement → system requirement → qualification test confirmation

An ASPICE assessor checking traceability performs exactly this exercise - taking a random requirement and following it in both directions. If any link is missing, the chain is broken and a finding is raised at the responsible process.

Our exercise project is the BMS-3 ECU - a Battery Management System ECU for a 400V EV platform. The OEM Technical Specification provides the following stakeholder-level requirements (SYS.1 inputs):

We will trace one complete chain from STK-002 (protection functions) through all levels of the V-model. This single chain touches every ASPICE SWE process and demonstrates the complete traceability structure.

SYS.2 decomposes STK-002 into specific, measurable system requirements. Each SYS.2 requirement must be testable, have an acceptance criterion, carry an ASIL rating if safety-relevant, and trace back to the STK requirement that motivated it.

Key practice: Notice that SYS-012 is ASIL-D - this drives significant ASPICE implications downstream. The SWE processes for the software component implementing this function must use ASIL-D-appropriate development methods (formal reviews, MC/DC coverage, no dynamic memory allocation, etc.).

SWE.1 receives the software-relevant portions of SYS.2 and decomposes them into software-specific requirements. SYS-012 is partially a hardware function (relay switching) and partially a software function (overvoltage detection and relay control signal). The SWE.1 requirements below address the software portion.

Traceability note: SW-045 and SW-046 both trace to SYS-012. Neither alone fully realizes SYS-012 - together they do. ASPICE requires that the allocation table shows that SYS-012 is realized by {SW-045, SW-046} plus the hardware relay driver. This multi-to-multi relationship is the normal case; tools like DOORS handle it natively; Excel matrices must explicitly show it.

SWE.2 defines the software architecture and allocates SWE.1 requirements to specific architectural components. For the BMS, the protection functions are allocated to the CellMonitor and ProtectionManager software components.

This allocation table is the key SWE.2 traceability artifact. It shows which component realizes which requirements and defines the interface contract between components. An assessor will use this table to verify that every SWE.1 requirement is allocated to at least one component, and that every component has a clear interface specification.

SWE.3 provides detailed design for each software unit, traceable to the architectural component it implements. For ASIL-D functions, the detailed design must be at a level of precision that enables independent verification - function-level pseudocode, state machine diagrams, or formal description.

ASIL-D detail requirement: For OvervoltageDetect (ASIL-D), the detailed design must document the timing margin analysis explicitly - not just state "meets timing." The design document must show the calculation so an independent reviewer can verify it. This is the SWE.3 evidence for ASIL-D detailed design sufficiency.

SWE.4 Unit Test Cases (traced to SWE.3 design)

SWE.6 Qualification Test Cases (traced to SWE.1)

Critical distinction: UT-OverV-001 through UT-OverV-005 are SWE.4 unit tests - they test the software unit in isolation using a test harness, verifying the detailed design logic. QT-SW-046-001 is a SWE.6 qualification test - it tests the complete software against the stated software requirement using a realistic (HIL) environment. Both must exist and both must be traceable to their respective test basis (SWE.3 design vs SWE.1 requirement).

SYS.5 tests the complete integrated system (SW + HW) against SYS.2 system requirements. SYS-012 required the entire system (not just the software) to disconnect within 10ms. The SYS.5 test must measure the full hardware path including relay switching time.

The Complete Traceability Chain - Summary

An ASPICE assessor picking SYS-012 at random and asking "show me the full traceability chain" can now follow this table from top to bottom and bottom to top. Every link is explicit, every ID is present, and the evidence at each level is tangible and verifiable.

Excel / Spreadsheet (Small Projects, <300 requirements)

A traceability matrix spreadsheet with columns: ID | Description | Traces_To_Up | Traces_To_Down | Status. One sheet per traceability level (SYS2↔SWE1, SWE1↔SWE2, etc.). Use Excel VLOOKUP or data validation to enforce that "Traces_To" values reference valid IDs in the adjacent sheet. Maintain the matrix in CM alongside the requirements documents - never in someone's local drive.

IBM DOORS / DOORS Next (Large Projects)

DOORS uses Link modules to establish bidirectional links between requirement modules at different levels. Create one link module per traceability relationship (e.g., "SYS2_to_SWE1_Links"). Use DOORS DXL scripts to generate coverage reports. The DOORS view showing a requirement and its upstream/downstream links is your primary assessment evidence - export this as PDF for the document package and demonstrate it live during interviews.

Polarion ALM

Polarion uses "Work Items" with "Links" between them. Define link types: "derives from" (upward), "is realized by" (downward), "is tested by" (test traceability). Configure Polarion reports to generate full traceability matrices across work item types. The Polarion traceability matrix report is directly usable as ASPICE evidence.

Jira + Plugins

Base Jira lacks formal traceability. Use plugins: Xray (for test case traceability), Jira Issues Links (for requirement-to-requirement links), or dedicated ALM tools like Jama Connect integrated with Jira. The risk with Jira is that traceability discipline depends entirely on team practice - there is no enforcement mechanism built in. This requires strong process governance to maintain.