hisc_0001: Placement of requirement links in an architecture model

R2026b

Link requirements to architecture model components to establish bidirectional traceability

Since R2026b

Usage: High-Integrity System Modeling

Guideline ID: hisc_0001

Rules

hisc_0001: Placement of requirement links in an architecture model

Apply requirement links to components of an architecture model to establish bidirectional traceability between requirements and the components that are used to implement the requirement. Rationale Establishing requirement links at the component level maintains the traceability between safety requirements and architecture. Verification Check for architecture components without requirement links (Simulink Check) Example — Correct Requirement links placed on component, reference component, and variant component. Example — Correct Requirement links placed on sequence diagram lifelines. Example — Correct Requirement links placed on activity diagram Actions, Decision or Merge, and Join or Fork blocks.

Tips

• Use Requirements Toolbox™ to trace between the model and the requirements from which the model was developed.

• For System Composer™, the following elements qualify as components for requirement linking:

  • Component (System Composer), Reference Component (System Composer), Variant Component (System Composer), and Variant Choices (architecture model)

  • Lifelines (System Composer)(sequence diagram)

  • Action Node (System Composer), Decision or Merge Node (System Composer), and Join or Fork Node (System Composer)(activity diagram)

• Exempted elements include:

  • Area Annotations, Gauge, Display, Slider, Adapter (System Composer) (architecture model)

  • Initial Node (System Composer), Flow Final Node (System Composer), Activity Final Node (System Composer) (activity diagram)

Industry Standards

• DO-331, Section MB.6.3.1.f - 'High-level requirements trace to system-level requirements'

• IEC 61508-3, Table A.2 (12) - 'Computer-aided specification and design tools'
  IEC 61508-3, Table A.2 (9) - 'Forward traceability between the software safety requirements specification and software architecture'
  IEC 61508-3, Table A.2 (10) - 'Backward traceability between the software safety requirements specification and software architecture'
  IEC 61508-3, Table A.4 (8) - 'Forward traceability between the software safety requirements specification and software design'

• IEC 62304, 5.2 - 'Software requirements analysis'

• ISO 26262-6, Table 2 (1a) - 'Natural language'
  ISO 26262-6, Table 5 (1a) – 'Natural language'
  ISO 26262-6: 7.4.2.a - 'The verifiability of the software architectural design'
  ISO 26262-6, Table 10 (1a) – 'Requirements-based test'
  ISO 26262-6, Table 10 (1b) – 'Interface test'
  ISO 26262-6, Table 11 (1a) – 'Analysis of requirements'
  ISO 26262-8, 6.4.2.3 – 'Safety requirements shall be allocated to the item or element which implements them'
  ISO 26262-8, 6.4.3.1.a – 'Hierarchical structure'
  ISO 26262-8, 6.4.3.1.b – 'Organizational structure'
  ISO 26262-8, 6.4.3.2 – 'Safety requirements shall be traceable with a reference'
  ISO 26262-8, 8.4.3 – 'Change request analysis'

• EN 50128, Table A.3 (23) - 'Modeling supported by computer aided design and specification tools'

• EN 50657, Table A.3 (23) - 'Modeling supported by computer aided design and specification tools'
  EN 50657, Table A.3 (18) – 'Modeling'

• EN 50716, Table A.9 (6) – 'Traceability'

Version History

Introduced in R2026b