Production defect cannot be traced back to original requirement

ALM Azure DevOps
, , , , , , , ,
1

We have a critical production defect reported through our quality management process, but we cannot trace it back to the original requirement or change request that introduced the issue. This is blocking our root cause analysis and compliance audit.

The defect (Bug #45678) is linked to the release branch and several commits, but when we try to follow the traceability chain back to the requirement, the links are broken or missing. We can see the commits reference “Fixes CR#12345” in the commit messages, but that change request work item doesn’t show a relationship to the parent requirement.

Our audit trail shows:


Bug #45678 → Commit abc123de
Commit message: "Fixes CR#12345: Update validation logic"
CR#12345 → ??? (no parent requirement link)

How do we establish proper bidirectional work item relationships so we can trace production issues back to their source requirements? Our compliance team needs complete traceability for regulatory reporting.

2

Commit message requirement references alone aren’t enough for full traceability. You need to establish work item relationships at multiple levels. Create a query that shows the full hierarchy: Requirement → Change Request → Task → Commit → Build → Release → Bug. If any link in that chain is missing, your traceability breaks.

For the specific issue with CR#12345, manually add a “Parent” link from the CR to the requirement that originally requested that validation logic change. Then add a “Related” link from Bug #45678 to the CR to complete the chain.

3

Consider implementing work item templates that pre-configure the required relationships. When creating a new CR, use a template that includes a “Parent Requirement” field that must be filled. This prevents the broken chain issue from occurring in the first place. Azure DevOps supports custom work item templates under Organization Settings > Process > Work Item Types > Templates.

4

You need to configure your process template to enforce requirement linking. Go to Organization Settings > Process > [Your process] > Change Request work item type > Rules. Add a rule that makes the “Related Work Items” field required when the state transitions to “Active”. This forces developers to link CRs to requirements before they can start work.

For your existing broken traceability, you’ll need to manually review commit messages and git history to reconstruct the relationships. Use Azure DevOps queries to find all CRs that lack parent requirement links, then have your team manually establish those connections based on historical context.

5

The issue is that change requests need to be explicitly linked to requirements when they’re created. This isn’t automatic. When creating a CR work item, use the “Add link” option to establish a “Parent” relationship to the original requirement. Without this manual step, the traceability chain breaks at the CR level.

6

The commit message pattern “Fixes CR#12345” creates a link from the commit to the CR, but it’s one-directional. You need bidirectional work item relationships configured at the work item level, not just in commit messages. Use the Azure DevOps REST API to programmatically verify relationship integrity across your work item hierarchy.

7

Your traceability breakdown is a common issue when teams rely solely on commit message references without establishing formal work item relationships. Here’s the comprehensive solution addressing all four critical areas:

1. Change Request to Requirement Linking: Establish a mandatory parent-child relationship. Configure your process template:

  • Organization Settings > Process > [Your process] > Change Request
  • Add a custom rule: “When State = New, make Related Links required”
  • Add field rule: “Parent link must be of type Requirement, Epic, or Feature”

For existing CRs without parents, run this query to find orphaned change requests:


SELECT [ID], [Title], [State]
FROM WorkItems
WHERE [Work Item Type] = 'Change Request'
  AND [Parent] IS NULL

Manually review each result and establish the parent relationship based on git history and commit context.

2. Bidirectional Work Item Relationships: Commit messages create one-way links. You need formal work item relationships:

  • Bug → “Related” link → Change Request (the CR that introduced the defect)
  • Change Request → “Parent” link → Requirement (the original requirement)
  • Change Request → “Child” link → Task (implementation tasks)
  • Commit → Auto-linked via message pattern to both CR and Task

Configure these relationship types in your process template under Work Item Types > Links. Enable “Enforce link types” to prevent incorrect relationship configurations.

3. Commit Message Requirement References: Your current pattern is good but incomplete. Enhance commit message standards:


Fixes CR#12345, Related to REQ#6789

Update validation logic per requirement specification
- Added null check for user input
- Enhanced error message formatting

This creates links to both the CR and parent requirement. Train developers to include both references.

4. Audit Trail Configuration: Enable comprehensive audit logging:

  • Organization Settings > Policies > Change tracking
  • Enable “Track work item changes”
  • Enable “Track link changes”
  • Set retention to match compliance requirements (typically 7 years for regulated industries)

Create a traceability validation query that runs weekly:


SELECT [ID], [Title], [Work Item Type], [Parent]
FROM WorkItemLinks
WHERE [Source].[Work Item Type] IN ('Bug', 'Change Request')
  AND [Target].[Work Item Type] = 'Requirement'
  AND [Link Type] = 'Parent'

This identifies work items that should have parent requirements but don’t.

Fixing Your Specific Case: For Bug #45678 and CR#12345:

  1. Review git history for commit abc123de:

    • Identify which requirement originally requested that validation logic
    • Check sprint planning records or product backlog history

  2. Manually establish relationships:

    • Open CR#12345
    • Add link: “Parent” → Requirement #[identified from step 1]
    • Open Bug #45678
    • Add link: “Related” → CR#12345 (marks this CR as the source of the defect)

  3. Document the reconstruction process in Bug #45678 comments for audit purposes

Preventing Future Issues: Implement a pull request policy that requires:

  • Work item linking (at least one work item per PR)
  • Commit message pattern validation (regex check for proper format)
  • Approval from someone who verifies parent requirement link exists

For your compliance audit, export the full traceability matrix showing Requirement → CR → Commit → Build → Release → Bug relationships. Use Azure DevOps Analytics to generate this report with custom queries that validate relationship completeness across the entire chain.