Requirements Traceability Gap Findertrace sheet

2 No verification method or no linked verification

Every requirement below the top level is expected to name how it will be verified and to link the test, analysis, inspection or review that does it. The paste shows no method, no linked verification, or neither, so there is nothing for the assessor to sample on this requirement.

the test
a requirement below the top level with a blank verification method, or with no linked test or verification ID in either paste; where every child is verified and passing, or an analysis, inspection, review or simulation carries a recorded justification, it is asked as a question for that justification, never counted as a break
the question
How is this requirement verified, which test or verification record covers it, and where is that link, or the justification for verifying it through its children or by another method, recorded?
asked of
the requirement owner
columns it reads
Verification Method, Verified By and Justification

Not every requirement without a direct verification is a gap. Where every child is verified and passing, the line reads covered through its children; where an analysis, inspection, review or simulation carries a recorded justification, the line reads justification recorded. Either way the finding asks for the justification, and the requirement is never counted as having no passing verification. Where the results carry a method, a verification recorded under a method the requirement does not list is asked about too.

The clauses behind it, by standard

each shown when you tick its standard

The clause text

ISO 13485 7.3.6Design and development verification

Verification of design and development follows planned, documented arrangements and confirms that the outputs satisfy the input requirements. The organization documents verification plans setting out the methods, the acceptance criteria and, where appropriate, statistical techniques together with the reasoning behind the sample size. If the intended use means the device must connect or interface with other devices, verification must show the outputs meet the inputs in that connected state. Records are kept of verification results, conclusions and any actions needed.

Held text: ISO 13485:2016, our statement of the clause, not the instrument verbatim.

what an assessor asks to see Verification plans with methods, acceptance criteria and sample-size rationale; Verification reports and records of actions; Interface or connected-use verification where applicable; Traceability showing every input verified

where it usually breaks Sample sizes chosen without a documented rationale; Verification of interfaces with other devices omitted; Inputs with no corresponding verification evidence

Every ISO 13485 clause we hold

FDA QMSR 820.10Quality management system requirements: ISO 13485 incorporated by reference

Section 820.10 establishes the substantive QMS requirements by incorporating ISO 13485:2016 SECTIONS 4 THROUGH 8 in full. Manufacturers must implement: ISO 13485:2016 SECTION 4 General QMS requirements + documentation (Quality Manual + Medical Device File + control of documents + records); SECTION 5 Management responsibility + customer focus + quality policy + planning + responsibility / authority / communication + management review; SECTION 6 Resource management (provision of resources + human resources + infrastructure + work environment + contamination control); SECTION 7 Product realization (planning + customer-related + design and development - the medical-device 'design controls' parallel + purchasing + production and service provision + control of monitoring + measuring equipment); SECTION 8 Measurement + analysis + improvement (monitoring + measurement + control of nonconforming product + analysis of data + improvement - including CAPA Sections 8.5.2 + 8.5.3). NB: ยง820.10 also clarifies that ISO 13485:2016 internal-audit + management-review requirements (Sections 8.2.4 + 5.6) apply to the QMSR.

Held text: 21 CFR Part 820 (QMSR), our statement of the clause, not the instrument verbatim.

what an assessor asks to see ISO 13485 Section 4-8 compliance file; Internal audit programme + records; Management review records + frequency; Cross-reference matrix between QMSR + ISO 13485 + EU MDR/IVDR + FDA Part 11

where it usually breaks ISO 13485 implemented in parts without full Section 4-8 coverage; Internal audit infrequent or scope-limited; Management review absent + meeting minutes incomplete

Every FDA QMSR clause we hold

AS9100D 8.3.4Design and development controls

The design and development process is controlled so that: the intended results are set out; reviews judge whether results can meet requirements; verification confirms that outputs match inputs; validation confirms that the resulting products satisfy the requirements of their intended use; problems are acted on; records are kept; and, under 9100, authorization is given before moving to the next stage, with people from the functions involved in the stage under review taking part in design reviews. 9100 adds that tests needed for verification and validation are planned, controlled, reviewed and documented, so that: test plans name the item tested, the resources, the aims, the conditions, the parameters to be recorded and the acceptance criteria; test procedures explain how the test is run and performed and how results are recorded; the right configuration is presented for test; the plan and procedures are followed; and the acceptance criteria are satisfied. Equipment used to measure tests is controlled under 7.1.5. When design is complete, reports, calculations and test results show that the design satisfies the specification under every operating condition identified.

Held text: AS9100D, our statement of the clause, not the instrument verbatim.

what an assessor asks to see Design review, verification and validation records with stage authorization.; Test plans and procedures meeting a) to e) with configuration of the test item recorded.; Completion evidence covering all identified operational conditions.

where it usually breaks Design reviews without representatives of manufacturing or quality.; Tests run on an undocumented configuration.; Next stage started before authorization.

Every AS9100D clause we hold

IATF 16949 8.3.5.1Design and Development Output - supplemental

Product design output is expressed so that it can be checked (verified and validated) against the design inputs. As applicable it includes: the design risk analysis (FMEA); results of reliability studies; special characteristics of the product; results of design error-proofing, for example DFSS, DFMA and FTA; the product definition, covering technical data packages, 3D models, geometric dimensioning and tolerancing (GD&T) and product manufacturing information; 2D drawings; outcomes of design reviews; guidelines for service diagnosis, together with instructions for repair and for serviceability; requirements for service parts; and requirements for packaging and labelling for shipment. Interim design outputs should include engineering problems being settled through trade-off. As revised: SI 30 (November 2025): item i) becomes requirements for replacement service parts, in line with the Rules 6th edition.

Held text: IATF 16949:2016, our statement of the clause, not the instrument verbatim.

what an assessor asks to see Design output package covering a) to j) as applicable.; Traceability from each output to the design inputs.

where it usually breaks Serviceability instructions and service part requirements missing from the output.; Special characteristics absent from the drawing package.

Every IATF 16949 clause we hold

ISO 26262 Part 8, 6.4.3Management of safety requirements

Safety requirements are managed under configuration and change management with traceability to their source and to their verification, and are verified for correctness, completeness and consistency against the level above. Requirement text not held.

Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.

what an assessor asks to see Requirements management tool records with traceability and verification status

where it usually breaks Requirements held in documents with no traceability

Every ISO 26262 clause we hold

ISO 26262 Part 8, 9.4.1Verification planning

Verification is planned for each phase and sub-phase: the work products to be verified, the objectives, the methods and their ASIL-dependent selection, the pass and fail criteria, the environment and tools, the actions on anomalies and the regression strategy. Requirement text not held.

Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.

what an assessor asks to see Verification plan per phase

where it usually breaks Verification methods chosen ad hoc

Every ISO 26262 clause we hold

ISO 26262 Part 8, 9.4.2Verification specification

The verification specification selects and specifies the methods, test cases with inputs, conditions and expected results, the equipment and environment, and the criteria, derived from the requirements and the design. Requirement text not held.

Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.

what an assessor asks to see Verification specification with test cases and expected results

where it usually breaks Tests run without specified expected results

Every ISO 26262 clause we hold

ISO 26262 Part 5, 10Hardware integration and verification

The hardware is integrated and verified against the hardware safety requirements using the methods of the part's tables for deriving test cases and for test methods by ASIL (part 11 Tables 27 and 28 interpret Tables 10 and 11 for semiconductors), including safety mechanism verification, environmental and stress tests and fault injection where applicable. Requirement text not held.

Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.

what an assessor asks to see Hardware integration and verification plan and results by ASIL-selected methods

where it usually breaks Hardware verified functionally with the safety mechanisms never exercised

Every ISO 26262 clause we hold

ISO 26262 Part 6, 10.4Software integration and verification

The software elements are integrated per the architectural design and the integration verified against it using the methods the standard recommends by ASIL (requirements-based test, interface test, fault injection, resource usage evaluation, back-to-back test), with structural coverage at the function and call level and the verification of freedom from interference and timing. Requirement text not held.

Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.

what an assessor asks to see Software integration verification results with function and call coverage

where it usually breaks Integration verified with unit tests re-run

Every ISO 26262 clause we hold

ISO 26262 Part 6, 9.4Software unit verification

Software units are verified against the unit design and the software safety requirements using the methods of Table 7 (walk-through, pair programming, inspection, semi-formal and formal verification, control flow analysis, data flow analysis, static code analysis, static analyses based on abstract interpretation, requirements-based test, interface test, fault injection test, resource usage evaluation, back-to-back comparison test between model and code), with test cases derived per Table 8 (analysis of requirements, equivalence classes, boundary values, error guessing) and structural coverage measured per Table 9 (statement, branch, MC/DC by ASIL). Requirement text not held.

Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.

what an assessor asks to see Unit verification specification with methods by ASIL; Static analysis results against the coding guidelines; Structural coverage measurements with the target per ASIL

where it usually breaks Coverage measured at statement level for an ASIL D unit; Static analysis run without MISRA or an equivalent rule set

Every ISO 26262 clause we hold

IEC 62304 5.1.6Software verification planning

The plan contains, or points to, the verification information: which deliverables need verifying, what verification is done for every life cycle activity, at which milestones deliverables are verified, and the criteria for accepting that verification. Applies to classes A, B and C.

Applies to software safety class A, B and C: a line of another class does not carry it.

Held text: IEC 62304:2015, our statement of the clause, not the instrument verbatim.

what an assessor asks to see Verification plan with deliverables, tasks, milestones and acceptance criteria.

where it usually breaks Verification planned as 'review' with no acceptance criteria.

Every IEC 62304 clause we hold

IEC 62304 5.7.1Establish tests for software requirements

For software system testing, a set of tests covering every software requirement is defined and run, each stated in terms of inputs, expected results, pass or fail criteria and procedure, and the suitability of the verification strategies and test procedures is evaluated. Requirements may also be tested at earlier stages or in combination. Applies to classes A, B and C.

Applies to software safety class A, B and C: a line of another class does not carry it.

Held text: IEC 62304:2015, our statement of the clause, not the instrument verbatim.

what an assessor asks to see System test specification covering every requirement; procedure adequacy evaluation.

where it usually breaks Requirements with no test.; Tests with no expected outcome stated.

Every IEC 62304 clause we hold

DO-178C A-7.3Tests cover every high-level requirement

Requirements coverage analysis shows each high-level requirement has test cases. Table A-7 objective 3, described in 6.4.4.a; applies at levels A, B, C, D, independence required at level A; activities 6.4.4.1; outputs Software Verification Results.

Applies at software level A, B, C, D: a line at another level does not carry it.

Held text: DO-178C / ED-12C, our statement of the clause, not the instrument verbatim.

what an assessor asks to see Requirements-based coverage analysis showing every high-level requirement is tested

where it usually breaks Requirements with no test case

Every DO-178C clause we hold

DO-178C A-7.4Tests cover every low-level requirement

Requirements coverage analysis shows each low-level requirement has test cases. Table A-7 objective 4, described in 6.4.4.b; applies at levels A, B, C, independence required at level A; activities 6.4.4.1; outputs Software Verification Results.

Applies at software level A, B, C: a line at another level does not carry it.

Held text: DO-178C / ED-12C, our statement of the clause, not the instrument verbatim.

what an assessor asks to see Requirements-based coverage analysis at the low-level requirements

where it usually breaks Low-level coverage assumed from high-level tests

Every DO-178C clause we hold

Automotive SPICE SYS.5.BP4Ensure consistency and establish bidirectional traceability

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

Every Automotive SPICE clause we hold

Automotive SPICE SWE.6.BP4Ensure consistency and establish bidirectional traceability

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

Every Automotive SPICE clause we hold

Automotive SPICE HWE.4.BP5Ensure consistency and establish bidirectional traceability

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

Every Automotive SPICE clause we hold

Automotive SPICE SWE.4.BP4Ensure consistency and establish bidirectional traceability

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

Every Automotive SPICE clause we hold

See the specimen runTrace your own export