Change request impact analysis not detecting all downstream test cases in traceability chain

ALM Siemens Polarion ALM
, , , , , , , ,
1

Our change management process relies heavily on impact analysis to identify affected test cases before approving changes. We’ve noticed that the impact analysis on change requests is missing test cases that are linked through multiple levels of requirements. For example, CR-2401 links to REQ-1055, which links to REQ-1120 (child requirement), which finally links to TC-3340. The impact analysis only shows direct links and one level deep, missing TC-3340 entirely. We suspect this is related to recursive depth configuration or how bidirectional links are being traversed. We’ve tried both Full and Quick analysis modes, but neither captures the complete downstream impact. This is causing release delays because we’re manually tracking these multi-level dependencies. Is there a configuration setting for recursive depth in impact analysis?

2

The default recursive depth for impact analysis is set to 2 levels in pol-2310. You can adjust this in the project configuration, but be careful - increasing it too much can cause performance issues on large projects. Check your Administration > Project Configuration > Traceability Settings for the “Impact Analysis Depth” parameter.

3

You don’t need to create redundant relationships - there’s a better solution. Here’s how to fix your incomplete impact analysis:

1. Configure Recursive Depth Properly Your depth setting of 5 is correct, but verify it’s applied to the right link types. Navigate to Administration > Project Configuration > Traceability Settings and expand the “Impact Analysis Configuration” section. Ensure these settings:

  • Recursive Depth: 5 (you have this)
  • Follow Hierarchical Links: TRUE (this is likely missing)
  • Bidirectional Traversal: TRUE
  • Include Indirect Links: TRUE

2. Enable Bidirectional Link Following The key issue is that impact analysis needs explicit permission to traverse parent-child relationships as part of the traceability chain. Edit your project’s traceability.xml configuration:

  • Add parent-child link types to the “allowed_impact_links” list
  • Enable bidirectional traversal for requirement hierarchies
  • This allows the analysis to follow REQ-1055 → REQ-1120 (child) → TC-3340

3. Create Custom Trace Views for Validation Build a custom trace view that explicitly shows multi-level paths:

  • Include both “traces to” and “parent of” link types
  • Set view depth to match your recursive depth (5)
  • Use this view to validate that your expected paths exist
  • Run this view on CR-2401 to confirm TC-3340 appears

If TC-3340 shows in the custom view but not in impact analysis, the link types aren’t properly configured in the impact analysis engine.

4. Understand Full vs Quick Analysis Modes These modes don’t affect recursive depth as you discovered:

  • Quick Analysis: Shows only direct impacts (1 level) with basic work item details
  • Full Analysis: Shows all configured recursive levels with complete metadata
  • Both respect your depth configuration, but Quick mode truncates the display

Always use Full Analysis for release planning to see complete downstream impacts.

5. Validate Configuration Changes After updating settings:

  • Clear the traceability cache (Administration > Repository > Clear Cache)
  • Rebuild the impact analysis index specifically (not just general traceability)
  • Test with CR-2401 to confirm TC-3340 now appears
  • Run impact analysis on 3-4 other change requests to verify consistent behavior

6. Performance Considerations With recursive depth of 5 and bidirectional traversal enabled:

  • Impact analysis may take 30-60 seconds on complex change requests
  • Consider running as background job for CRs with >50 direct links
  • Monitor server performance after enabling these settings

Prevention Going Forward Establish traceability standards that explicitly define when to use hierarchical vs trace links. Many teams use hierarchical links for requirement decomposition and trace links for cross-module dependencies. Make sure your impact analysis configuration covers both patterns.

This should resolve your missing test cases issue and eliminate the manual tracking overhead causing your release delays.

4

I’ve dealt with this exact scenario. The Full vs Quick analysis modes don’t actually change the recursive depth - they only affect how much detail is shown in the results. The real problem is that impact analysis uses a different query engine than the traceability matrix, and it has hardcoded limitations on link type combinations it will follow.


// Current behavior (simplified):
analyzeImpact(changeRequest) {
  links = getDirectLinks(CR);
  foreach link in links {
    childLinks = getDirectLinks(link);
  }
}

This doesn’t handle mixed hierarchical and trace relationships.

5

You’ve identified the core issue. Impact analysis in change-mgmt follows explicit traceability links but doesn’t automatically traverse hierarchical parent-child relationships unless they’re also defined as traceability links. Your REQ-1055 to REQ-1120 relationship might be a structural parent-child link rather than a traced dependency. Try creating a custom trace view that includes both link types and see if that reveals the gap in your traceability chain.

6

I found the setting you mentioned, but it’s already set to 5 levels, which should be more than enough for our scenario. The issue persists even with this configuration. I’m wondering if the problem is with bidirectional links - maybe the impact analysis isn’t following links in both directions properly? Our requirements have both parent-child relationships and separate traceability links to test cases.