hisl_0080: Establish requirement granularity in a model

R2026b

Limit requirement links and child elements per linked component to ensure proper granularity

Since R2026b

Usage: High-Integrity System Modeling

Guideline ID: hisl_0080

Prerequisite: hisl_0070: Placement of requirement links in a model

Rules

hisl_0080: Establish requirement granularity in a 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 a model (Simulink Check) Example — Incorrect Requirement links in the subsystem component exceed the default limit of 5.
B	A component linked to a requirement shall not contain more than the defined number of child model elements. Default values are: Simulink^® — 100 child elements Stateflow^® — 100 child elements MATLAB^® — 200 lines of code Rationale Support single responsibility design. Ensure requirement granularity. Verification Check for requirement granularity in a model (Simulink Check) Example — Incorrect Child objects per requirement in an area annotation component exceed the default value.

hisl_0080: Establish requirement granularity in a model

A component shall not be associated with more than the defined number of unique requirement links. Default value is 5.

Rationale

Verification

Example — Incorrect

Requirement links in the subsystem component exceed the default limit of 5.

Simulink subsystem with requirement links exceeding the default limit of 5

A component linked to a requirement shall not contain more than the defined number of child model elements. Default values are:

Rationale

Verification

Example — Incorrect

Child objects per requirement in an area annotation component exceed the default value.

Area annotation component with child objects per requirement exceeding the default limit

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.
To reduce the number of requirements that are linked to a model, apply requirements at the component-level. A component contains a group of model elements, for example:
- In Simulink, a component is a top-level block diagram, subsystem, MATLAB Function, or area annotation.
- In Stateflow, a component is a chart, superstate, box, Simulink function, graphical function, Simulink State, MATLAB Function, or Truth Table.
- In MATLAB, a component is a function.

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, 8.4.5.d – 'Simplicity'
ISO 26262-6, 8.4.5.d – 'Suitability for software modification'
EN 50128, Table D.58 - 'Traceability'
EN 50128, Table A.10 (1) - 'Impact Analysis'
EN 50657, Table A.3 (23) - 'Modeling supported by computer aided design and specification tools'
EN 50657, Table D.58 - 'Traceability'
EN 50657, Table A.10 (1) - 'Impact Analysis'
EN 50716, Table A.9 (6) – 'Traceability'

Introduced in R2026b