1 Requirement with no parent
An assessor samples the chain from each requirement up to the need or requirement it serves. This one sits below the top level of the paste, is not flagged as derived, and its parent cell is blank, so the chain stops here. It may be a link that was never made, a requirement that belongs higher, or a derived requirement that has not been marked as one.
- the test
- an unexpected blank parent: a requirement below the top level of the paste, not flagged derived, whose parent cell is empty (a confirmed top-level requirement, a flagged derived one and a parent outside this export are their own states, never this finding)
- the question
- Which higher-level requirement does this one serve? If none, is it derived, and has it been identified as derived and passed back for review?
- asked of
- the requirement owner
- columns it reads
- Parent, Level and Derived
Four states, each shown on the line, in the trace and in the CSVs: top level (a confirmed root, by its level), derived (flagged in the paste), parent outside this export (finding 7 asks where it is held), and an unexpected blank parent below the top level. Only the last is this finding.
The clauses behind it, by standard
each shown when you tick its standard- ISO 26262: Part 8, 6.4.1 and Part 8, 6.4.3
- Automotive SPICE: SYS.2.BP5 (system level), SWE.1.BP5 (software requirements), HWE.1.BP5 (hardware requirements) and SWE.3.BP4 (software units and detailed design)
- IEC 62304: 5.2.6
- ISO 13485: 7.3.2
- FDA QMSR: 820.10
- DO-178C: A-3.6 (high-level requirements) and A-4.6 (low-level requirements)
- AS9100D: 8.1.2
The clause text
Safety requirements are specified through the hierarchy from safety goals to functional, technical, hardware and software safety requirements, with each requirement derived from and traceable to the level above, allocated to an element, and specified in natural language or in an informal, semi-formal or formal notation per the standard's table 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 Safety requirements hierarchy with derivation and allocation
where it usually breaks Requirements written at one level with no traceability to the safety goals
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
The manufacturer verifies and documents that the software requirements implement the system requirements including those for risk control, do not contradict one another, avoid ambiguity, are stated so that test criteria can be established and tests performed, can be uniquely identified, and are traceable to system requirements or another source; no formal specification language is required. 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 Requirements review record against the six criteria; traceability matrix.
where it usually breaks Requirements that cannot be tested as written.; Unnumbered requirements.
The organization plans and controls how the product is designed and developed, and keeps the planning documents up to date as the work moves forward. The planning documents set out the stages of design and development; the reviews each stage needs; the verification, validation and design transfer work suited to each stage; responsibilities and authorities; how design outputs will be traced back to design inputs; and the resources required, including staff competence.
Held text: ISO 13485:2016, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Design and development plan per project with stages, reviews, verification, validation and transfer activities; Responsibilities and authorities for design; Traceability method (trace matrix) from outputs to inputs; Resource and competence planning; Evidence the plan was updated as the design progressed
where it usually breaks Plan written at project start and never updated; Transfer activities absent from the plan; No method for traceability, so verification coverage cannot be shown
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
Each high-level requirement links to the system requirements it implements, derived ones excepted and identified. Table A-3 objective 6, described in 6.3.1.f; applies at levels A, B, C, D, no independence required; activities 6.3.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 Trace review showing every high-level requirement traces to system requirements
where it usually breaks Orphan high-level requirements
Each low-level requirement links to a high-level requirement, derived ones excepted and identified. Table A-4 objective 6, described in 6.3.2.f; applies at levels A, B, C, no independence required; activities 6.3.2; 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 Trace review from low-level to high-level requirements
where it usually breaks Orphan low-level requirements not identified as derived
Suited to its products and services, the organization plans, runs and controls configuration management so that physical and functional attributes are identified and controlled over the whole product life. This controls product identity and traceability back to requirements, including carrying out identified changes, and keeps the documents (requirements, design, verification, validation and acceptance records) in step with the actual attributes of what is delivered.
Held text: AS9100D, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Configuration management process and configuration records showing as-designed, as-built and as-delivered consistency.
where it usually breaks Design changes implemented without configuration identification.; Documentation not matching the delivered configuration.
Make 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