Assess Allocation and Impact

You can use the Traceability Diagram window to visualize links between Model-Based Design items. The diagram originates from a starting node that corresponds to an item and displays links, also called edges, from the starting node to other nodes that correspond to other linkable items. For more information, see Visualize Links with Traceability Diagrams.

Traceability diagrams also allow you to visually inspect the requirements allocation in a requirement set, which is a process of decomposing requirements and linking them to design elements and test for implementation and verification. Requirements allocation allows you to confirm that the design implements and verifies behavior that is required at a high-level, such as requirements that describe end-user needs.

You can also use a traceability diagram to visualize indirect links to assess how a change impacts and propagates between Model-Based Design items, especially when requirements change within a requirements hierarchy that contains multiple levels.

Assess Requirements Allocation

The process of requirements allocation allows you to confirm that functionality required at the high-level is implemented and verified by the design and tests, respectively. To allocate a single high-level requirement, you must:

1. Decompose the high-level requirement into one or more low-level requirements that are more detailed in order to allow for final implementation and verification. The low-level requirements should cumulatively capture the functionality required at the high level.

2. Create links between the high-level requirement and the decomposed requirements. This creates traceability from the high-level required functionality to low-level implementation and verification.

3. Implement and verify the low-level requirements by linking them to design and test items.

After you allocate a requirement, you can use a traceability diagram to create a diagram from that requirement and visually inspect the allocation. You can visualize the links to low-level requirements and to the implementation and verification items, such as Simulink^® blocks and test cases.

Decomposing Requirements

The first step of requirements allocation is to decompose your high-level requirements. Some requirements are too abstract and must be decomposed into low-level functional requirements that can be implemented and verified.

Decomposing high-level requirements into more detailed low-level requirements allows you to implement the requirements with design components that explicitly carry out the required functionality. Additionally, you can create tests that only require the part of the system that contains that component. This component-level implementation and verification helps requirements to remain implemented and verified when multiple components are integrated into a system.

For example, the files in the CruiseRequirementsExample project describe a cruise control system design. Open the project by entering the following command in the MATLAB^® command prompt:

openExample("slrequirements/CruiseRequirementsExample")

The crs_req_func_spec requirement set contains requirements that ensure that the system meets the functional specifications. The Calculate Target Speed and Throttle Value requirement is an example of a decomposed, high-level requirement.

Linking, Implementing, and Verifying Requirements

In order for a decomposed high-level requirement to be allocated, it must link to the corresponding low-level requirements. Additionally, each low-level functional requirement must have at least one outgoing link for implementation and one outgoing link for verification. If you intentionally did not implement or verify a low-level functional requirement, you can create a link to a justification and add information about why this requirement is exempt from implementation or verification. For more information, see Justify Requirements.

You must fully allocate your high-level requirements to visualize the design items in the Traceability Diagram window. For example, the Calculate Target Speed and Throttle Value is decomposed but it is not linked to its child requirements. The diagram below shows that it only has one link.

You can use the Requirements Editor, Requirements Perspective, or Traceability Matrix to create links. For more information, see Create and Store Links.

Visualizing Requirements Allocation

After you allocate your requirements, you can visualize the allocation by creating a traceability diagram from the high-level requirement. For more information, see Generate Traceability Diagrams.

For example, the diagram below originates from the Calculate Target Speed and Throttle Value requirement and shows added links between Calculate Target Speed and Throttle Value and its child requirements.

Each child requirement has at least one Implement type link to a model element. However, the child requirements do not have Verify type links to test items or to justifications, so the Calculate Target Speed and Throttle Value requirement is not considered fully allocated.

Visualize Change Propagation

Requirements Toolbox™ allows you to track changes to requirements. If a linked requirement changes, the associated link has a change issue. For more information, see Track Changes to Requirement Links.

In the Traceability Diagram, links with change issues are shown as dashed red lines. Because change issues apply only to the immediate link when you change a linked requirement, you can use the Traceability Diagram to assess the change propagation for links that have change issues and items that indirectly link to a changed requirement.

Visualize Indirect Links

If you make a change to a requirement, a change issue is only applied to that immediate link. However, changes may affect other items that are indirectly linked. Indirect links are links between items that have at least one degree of separation. You can use a traceability diagram to visualize indirect links.

For example, this diagram shows an indirect link between the Disabling cruise control requirement and the Enumerated Constant Simulink block:

Assess Change Propagation

Changes can flow from the changed node through several layers of upstream or downstream nodes. You can use a traceability diagram to visualize how changes propagate through indirect links, and assess how the changes might affect further upstream or downstream nodes.

For example, the diagram below originates from the Calculate Target Speed and Throttle Value requirement and shows links to child requirements. A change has been made to the Calculate Target Speed and Throttle Value requirement. The diagram indicates that four outgoing links from the Calculate Target Speed and Throttle Value requirement have change issues.

Although the links to the grandchild requirements Throttle Value Computation and Next Target Speed Computation do not have change issues, the diagram shows that they are indirectly linked to the changed requirement – Calculate Target Speed and Throttle Value.

You can assess the impact that the change to the Calculate Target Speed and Throttle Value requirement has on the grandchild requirements by navigating to them in the Requirements Editor. For more information, see Navigate from Node or Edge to Artifact.