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- ISO 26262: Part 8, 6.4.3, Part 8, 9.4.1, Part 8, 9.4.2, Part 5, 10 (hardware requirements), Part 6, 10.4 (software requirements and high-level requirements) and Part 6, 9.4 (software unit or detailed designs and low-level requirements)
- Automotive SPICE: SYS.5.BP4 (system level), SWE.6.BP4 (software requirements), HWE.4.BP5 (hardware requirements) and SWE.4.BP4 (software units and detailed design)
- IATF 16949: 8.3.5.1
- IEC 62304: 5.1.6 and 5.7.1
- ISO 13485: 7.3.6
- FDA QMSR: 820.10
- DO-178C: A-7.3 (high-level requirements) and A-7.4 (low-level requirements)
- AS9100D: 8.3.4
The clause text
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
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
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.
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.
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
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
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
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
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
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
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.
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.
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
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
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