7 Parent outside this export, or an ID used twice
A link names a parent that no requirement in the paste carries, or one ID sits on more than one row. The parent may live in another module or export, which is often by design, or the link may point at an ID that was renumbered or deleted; the export alone cannot say which. Two rows with one ID are read as two requirements, never merged, because a trace to that ID cannot say which one it means.
- the test
- a parent ID that no requirement in the paste carries (outside this export, or not an ID at all: an export cannot tell the two apart), or one requirement ID on more than one row (never merged)
- the question
- Where is the parent held, and is the link current? For a repeated ID, which row is the requirement, and what should the other be numbered?
- asked of
- the requirement owner
- columns it reads
- ID and Parent
The clauses behind it, by standard
each shown when you tick its standard- ISO 26262: Part 8, 6.4.2 and Part 8, 6.4.3
- Automotive SPICE: SYS.2.BP5 (system level), SWE.1.BP5 (software requirements), HWE.1.BP5 (hardware requirements) and SYS.3.BP4 (system level)
- 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)
The clause text
Each safety requirement carries a unique identifier, a status and an ASIL, and the requirements are unambiguous, comprehensible, atomic, internally consistent, feasible, verifiable, necessary, implementation-free and, as a set, hierarchical, complete, externally consistent, non-redundant and maintainable. 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 attributes (identifier, status, ASIL) and characteristic checks
where it usually breaks Requirements with no ASIL attribute; Compound requirements that cannot be verified individually
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
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
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