hisc_0002: Establish requirement granularity in an architecture model

R2026b

Limit requirement links and child elements per component in architecture models

Since R2026b

Usage: High-Integrity System Modeling

Guideline ID: hisc_0002

Prerequisite: hisc_0001: Placement of requirement links in an architecture model

Rules

hisc_0002: Establish requirement granularity in an architecture model
A	A component shall not be associated with more than the defined number of unique requirement links. Default value is 5. Rationale Support single responsibility design. Ensure requirement granularity. Verification Check for requirement granularity in an architecture model (Simulink Check) Example — Incorrect Architecture model component with requirement links that exceed the default limit. Example — Incorrect Sequence diagram lifeline with requirement links that exceed the default limit. Example—Incorrect Activity diagram node with requirement links exceed the default limit
B	A component linked to a requirement shall not contain more than the defined number of immediate child elements. Default value is 7. Rationale Support single responsibility design. Ensure requirement granularity. Verification Check for requirement granularity in an architecture model (Simulink Check) Example — Incorrect Architecture model component with requirement link has child components that exceed the default limit.

Tips

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

• Components with excessive requirement links may indicate multiple responsibilities and should be decomposed into smaller, more focused sub-components. Similarly, if a component linked to a single requirement contains too many child model elements, the requirement may lack sufficient granularity. In such cases, create more granular child requirements and decompose the component so that each new sub-component is associated with a specific child requirement.

• 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)

Industry Standards

• IEC 61508-3, Table A.8 (1) - 'Impact analysis'

• IEC 62304, 7.4.2 - 'Analyze impact of software changes on existing risk control measures'

• ISO 26262-6, Table 3 (1b) – 'Restricted size and complexity of software components'
  ISO 26262-8: 8.4.3 'Change request analysis'
  ISO 26262-6: 7.4.2.a - 'The verifiability of the software architectural design'
  ISO 26262-6, Table 3 (1a) – 'Appropriate hierarchical structure of the software components'
  ISO 26262-8, Table 3 (1c) – 'Restricted size of interfaces'
  ISO 26262-8, Table 3 (1d) – 'Strong cohesion within each software component'
  ISO 26262-8, Table 3 (1e) – 'Loose coupling between software components'
  ISO 26262-8, 6.4.3.1.a – 'Hierarchical structure'
  ISO 26262-8, 6.4.3.1.b – 'Organizational structure'

• EN 50128, Table A.10 (1) - 'Impact Analysis
  'EN 50128, Table D.58 - 'Traceability'

• EN 50657, Table A.10 (1) - 'Impact Analysis
  'EN 50657, Table D.58 - 'Traceability'

• EN 50716, Table A.2 (2) – 'Structured Methodology'
  EN 50716, Table A.3 (19) – 'Structured Methodology'
  EN 50716, Table A.9 (6) – 'Traceability'
  EN 50716, Table A.10 (1) – 'Impact Analysis'

Version History

Introduced in R2026b