Requirements traceability in Automotive SPICE
Automotive SPICE asks, in its system, software and hardware engineering processes, for consistency and bidirectional traceability between each level of requirements and the level above, and between every requirement and its verification measures and results. An assessor samples the trace links in both directions, and a requirements traceability matrix exported from the requirements tool is the usual evidence.
- standard
- Automotive SPICE: the Automotive SPICE process assessment model, its system, software and hardware engineering base practices
- edition held
- Automotive SPICE v4.1, the version we hold; we make no claim that it is the current model
- clauses cited here
- 11 of the 229 held; shown when you tick Automotive SPICE
- every clause we hold
- Automotive SPICE, clause by clause
Where each finding cites it
- 1Requirement with no parent: SYS.2.BP5 (system level), SWE.1.BP5 (software requirements), HWE.1.BP5 (hardware requirements) and SWE.3.BP4 (software units and detailed design)
- 2No verification method or no linked verification: SYS.5.BP4 (system level), SWE.6.BP4 (software requirements), HWE.4.BP5 (hardware requirements) and SWE.4.BP4 (software units and detailed design)
- 3Verification failed, blocked or not run: SYS.5.BP3 (system level) and SWE.6.BP3 (software requirements)
- 5Test that traces to no requirement: SYS.5.BP4 and SWE.6.BP4
- 7Parent outside this export, or an ID used twice: SYS.2.BP5 (system level), SWE.1.BP5 (software requirements), HWE.1.BP5 (hardware requirements) and SYS.3.BP4 (system level)
The columns that show it in a requirements traceability matrix
Parent, Level, Derived, Verification Method, Verified By, Justification, the results: Result and Date, the results: Requirements, the results: Type and ID. The requirements traceability matrix template carries every one.
What it asks, clause by clause
11 clausesMake sure the system requirements agree with the stakeholder requirements and link the two in both directions, bearing in mind that links do not by themselves prove consistency and that non-functional stakeholder requirements without trace links, such as requirements on the process, must still be verified.
Held text: Automotive SPICE v4.1, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Requirement (17-00); Requirement Attribute (17-54); Analysis Results (15-51); Consistency Evidence (13-51)
where it usually breaks Stakeholder requirements with no link to system requirements left unaddressed; Trace links created in bulk without reviewing whether the system requirement covers the stakeholder need
Keep the software requirements in agreement with the system architecture and also with the system requirements (or, where only software is developed, the stakeholder requirements), linking them in both directions without duplicate links; non-functional system requirements that have no trace link must still be verified.
Held text: Automotive SPICE v4.1, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Requirement (17-00); Requirement Attribute (17-54); Analysis Results (15-51); Consistency Evidence (13-51)
where it usually breaks Trace links from software requirements stop at the system requirement level and never reach the system architecture; Untraced non-functional requirements left with no verification planned for them
Make sure the hardware requirements agree with the system architecture and also with the system requirements (or the stakeholder requirements where only hardware is developed), and keep trace links without duplication; non-functional requirements without trace links, such as process requirements, must still be verified.
Held text: Automotive SPICE v4.1, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Communication Evidence (13-52); Consistency Evidence (13-51); Requirement (17-00); Requirement Attribute (17-54)
where it usually breaks Trace links from hardware requirements to system requirements or architecture elements incomplete or one directional; Process and other non-functional requirements without trace links never planned for verification; Duplicate trace links hide requirements that have no coverage at all
Make sure the detailed design agrees with the software architecture, and the developed units with the detailed design, linking each pair in both directions, and link the detailed design to the software requirements.
Held text: Automotive SPICE v4.1, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Software Detailed Design (04-05); Software Unit (11-05); Consistency Evidence (13-51); Communication Evidence (13-52)
where it usually breaks Units linked straight to software requirements with no link to the detailed design element they implement; Duplicate trace paths kept both through the design and directly, drifting apart after changes
Make sure the verification measures agree with the system requirements and link the two in both directions; likewise link each verification result back and forth with the measure that produced it.
Held text: Automotive SPICE v4.1, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Consistency evidence (13-51), such as a trace matrix, linking each system requirement to its verification measures and each result to the measure run
where it usually breaks System requirements with no linked system test identified only at the final gate; System test results not traceable to the test case version run
Make sure the verification measures agree with the software requirements and link the two in both directions; likewise link each verification result back and forth with the measure that produced it.
Held text: Automotive SPICE v4.1, our statement of the clause, not the instrument verbatim.
what an assessor asks to see 15-52 Verification Results; 08-58 Verification Measure Selection Set; 03-50 Verification Measure Data; 08-60 Verification Measure
where it usually breaks Software requirements with no linked qualification test, discovered only at release review; Test results cannot be traced to the test specification version used
Make sure the verification measures agree with the hardware requirements and link the two in both directions; likewise link each measure back and forth with the results it produced.
Held text: Automotive SPICE v4.1, our statement of the clause, not the instrument verbatim.
what an assessor asks to see 15-52 Verification results linked back to the requirement verification measure and sample; 08-58 Verification measure selection set traceable to the hardware requirements in the release scope; 03-50 Verification measure data identifiers linked in the requirements management tool; 08-60 Verification measures linked both ways to each hardware requirement
where it usually breaks Hardware requirements without a linked verification measure pass unnoticed into the release; Requirement test results linked to the wrong requirement version after a specification update
Keep the verification measures consistent with the software units in the detailed design and link the two in both directions; likewise link each result back and forth with the measure that produced it.
Held text: Automotive SPICE v4.1, our statement of the clause, not the instrument verbatim.
what an assessor asks to see 15-52 Verification Results; 08-58 Verification Measure Selection Set; 03-50 Verification Measure Data; 08-60 Verification Measure
where it usually breaks Unit test cases carry no link to the unit or design element they verify; Results cannot be tied to the test case version that produced them after test scripts were edited
Verify the integrated system using the chosen measures and record each result as pass or fail together with the measure data; results that deviate are handled under SUP.9.
Held text: Automotive SPICE v4.1, our statement of the clause, not the instrument verbatim.
what an assessor asks to see System verification results (15-52) with pass or fail per measure, the system build tested and the test date
where it usually breaks System verification run on a configuration differing from the delivered system; Failed system tests not raised as problem reports under SUP.9
Verify the integrated software with the selected measures and record the results with pass/fail status and the measure data; deviating results go to SUP.9.
Held text: Automotive SPICE v4.1, our statement of the clause, not the instrument verbatim.
what an assessor asks to see 15-52 Verification Results; 08-58 Verification Measure Selection Set; 03-50 Verification Measure Data; 08-60 Verification Measure
where it usually breaks Qualification tests run on a software build other than the one released to the customer; Failed qualification tests marked as known issues without a problem report or customer agreement
Keep the elements of the system architecture consistent with those system requirements that describe properties of the physical end product, and link them in both directions; requirements of other kinds must still be verified, and the existence of links does not by itself show consistency.
Held text: Automotive SPICE v4.1, our statement of the clause, not the instrument verbatim.
what an assessor asks to see System Architecture (04-06); Consistency Evidence (13-51); Communication Evidence (13-52); Analysis Results (15-51)
where it usually breaks System requirements not allocated to architecture elements, discovered at system test; Links from system requirements to elements exist but consistency was never reviewed