This is machine translation

Translated by Microsoft
Mouseover text to see original. Click the button below to return to the English version of the page.

Note: This page has been translated by MathWorks. Click here to see
To view all translated materials including this page, select Country from the country navigator on the bottom of this page.

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 Simulink® Requirements™to trace between the model and the requirements from which the model was developed. Apply user tags (Simulink Requirements) 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, or graphical function.

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 Check

  • By Task > Modeling Standards for DO-178C/DO-331 > High-Integrity Systems > Requirements > Check for model elements that do not link to requirements

  • By Task > Modeling Standards for IEC 61508 > High-Integrity Systems > Requirements > Check for model elements that do not link to requirements

  • By Task > Modeling Standards for IEC 62304 > High-Integrity Systems > Requirements > Check for model elements that do not link to requirements

  • By Task > Modeling Standards for ISO 26262 > High-Integrity Systems > Requirements > Check for model elements that do not link to requirements

  • By Task > Modeling Standards for EN 50128 > High-Integrity Systems > Requirements > Check for model elements that do not link to requirements

For check details, see Check for model elements that do not link to requirements.

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

  • 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 8 (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
Last ChangedR2017b
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.