Main Content

Requirement Considerations

hisl_0070: Placement of requirement links in a model

ID: Titlehisl_0070: Placement of requirement links in a model
Description

Establish bidirectional traceability between model requirements and the model elements that are used to implement the requirement. A single element or combination of elements can link to requirements.

When linking requirements, follow these guidelines.

AApply requirement links to the lowest level component of model elements. Model elements that do not impact the model's behavior or the generated code are exempt from requirement linking. See Notes for additional information.
BAt the project level, define the maximum number of unique requirement links associated with each component. A minimum of one requirement link is required.
CAt the project level, define the maximum number of child model elements for each linked component.
Notes

Use Requirements Toolbox™ to trace between the model and the requirements from which the model was developed. Apply user tags (Requirements Toolbox) to define model elements as derived and/or safety requirements.

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.

  • In System Composer, a Component is an Adapter, a Component block, or a Sequence Diagram.

Components that contain only these model elements are exempt from requirement linking:

When a linked component contains a nonexempt child model element, the child implements the associated requirement either in part or whole.

RationaleAEstablishing requirement links at the component level captures the relationship of model elements. In addition, maintainability improves because the need to update requirement links for minor logic changes is reduced.
B, CSupport requirement change impact analysis.
Model Advisor CheckCheck for model elements that do not link to requirements (Simulink Check)
References

  • DO-331, Section MB.6.3.2.f - 'Low-level requirements trace to high-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 61508-3, Table A.8 (1) - 'Impact analysis'

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

  • ISO 26262-6, Table 2 (1a) - 'Natural language'
    ISO 26262-6, Table 3 (1b) – ‘Restricted size and complexity of software components’
    ISO 26262-6, Table 5 (1a) – Natural language
    ISO 26262-6: 7.4.2.a - The verifiability of the software architectural design
    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 50128, Table D.58 - Traceability
    EN 50128, Table A.10 (1) - 'Impact Analysis'

See Also

Link Requirements (Requirements Toolbox)

Last ChangedR2021a
Examples

Recommended: Requirement links on parent component

Requirement link placed at the top level model with no subsystems.

Recommended: Requirement links placed on area annotation

Requirement link placed on an area annotation.