When users run an analysis on an artifact, they can set the traversal (direction) that the analysis explores. Four directions are available by default: Upstream, Downstream, Both (upstream and downstream), and Full Traceability. This topic discusses the Full Traceability traversal, and how it differs from the Both traversal. The following image shows the Traversal options on the Traversal tab that are on the Impact Analysis Diagram screen:

Using Full Traceability can result in a huge impact analysis diagram because Full Traceability traverses every node for the target artifact. Use this option cautiously. If you are unsure whether Full Traceability is the right option, use the Both traversal option first. Both explores upstream and downstream artifacts for a target artifact, but does not explore every node, so the impact analysis diagram contains fewer artifacts and performs faster.
The following scenarios discuss situations in which the Full Traceability traversal might be more helpful than the Both traversal.
Scenario 1: A new developer, John, is assigned to work on a component. John starts with the design for the component and explores the related artifacts. Because John is new to the project, he does not understand the possible dependencies and interactions, or even if he is starting in the best place. John uses Full Traceability traversal to see the links from one of the design elements up to the requirements and the containing module, then down from other requirements in that module to related parts of the design. John also follows the links down from a design element to a test case, from the test case to the owning test plans, and back from the test plans to other design elements and requirements.
Scenario 2: Susan is a product manager who is considering a change to generalize the capabilities of a component in one of her products. She uses Full Traceability traversal to see the configurations and product lines for the component. She follows relationships down from the configurations to similar, but unrelated components to see where the potential change might make the component applicable for inclusion in other product lines. This inclusion increases component reuse and reduces cost.
The following scenarios discuss situations in which the Both traversal might be more helpful than the Full Traceability traversal.
Scenario 1: Developer John must make a design change to some code to fix a scalability flaw. Before John changes the design, he wants to review both the upstream and downstream artifacts.
The upstream artifacts are the requirements and work items that are related to the design. The work item probably describes the details of the scalability problem. John was already assigned to the work item, so he does not learn much from that traceability link other than double-checking its existence. However, seeing the upstream requirements is important because he must ensure that the new design meets the requirements, including any newly linked performance requirements.
The downstream artifacts are the test cases. John must ensure that the test cases are updated to work with the new design. He might also need to create a test case for the new performance and scalability requirement and its design.
Each additional depth level can greatly increase the number of nodes that are drawn. Sometimes increasing the number of nodes is exactly what you want, while other times not. Use caution when you increase the depth.
The following image shows how each traversal (Upstream, Downstream, Both, Full Traceability) moves in relation to the focus artifact.
