A requirement changes after tests were designed, some were run, and a defect or two was raised against it. The question is not whether to accept the change. It is what the change touches, and what each of those things now needs.
The short answer: requirements change impact analysis follows the trace from the changed requirement to everything that depends on it. That means its acceptance criteria, dependent requirements, use cases, test cases and test data, earlier results and open defects. It ends with a recorded decision about what to update, re-test or re-decide.
What to trace when a requirement changes
- Acceptance criteria: which criteria change, which are added, which no longer apply.
- Dependent requirements: anything that builds on this requirement or assumes its behaviour.
- Use cases and flows: main, alternate and exception flows that describe the changed behaviour.
- Test cases and test data: cases designed to test the changed criteria, and data values sitting on a boundary that moved.
- Earlier test results: what was already run against the old version.
- Open defects: whether each one is still a defect under the new behaviour.
- Release scope and estimates: whether the change still fits the plan.
A traceability matrix makes this a lookup instead of a search. If you do not have one, start with the requirements traceability matrix template.
How to do a requirements change impact analysis
- State the change precisely. Write the before and after side by side, with who asked for it and why. "The refund window is shorter" is not a change; "30 days after delivery becomes 14 days after delivery" is.
- Classify it. A clarification changes the words but not the behaviour. A behaviour change alters what the system must do. A scope change adds or removes behaviour. Each needs a different depth of analysis.
- Find the affected criteria. Mark each acceptance criterion as changed, added, removed or unaffected.
- Follow the trace. For every affected criterion, list the linked test cases, test data, use-case flows, dependent requirements and open defects, and decide whether each one is actually affected. A link is a reason to look, not proof of impact.
- Reassess earlier results. Treat them as historical evidence, as described below.
- Record the decision. Accept, defer or reject the change; name who decided, and what will be updated, re-tested or re-decided, with owners.
- Update and re-baseline. Change the criteria, cases and data, re-run what needs re-running, and keep the previous version so the change can be understood later.
Earlier test results are historical evidence
A result recorded before the change is evidence of how the system behaved against the old requirement. It is not automatically wrong, and it is not automatically still valid. Reassess each one against the changed requirement:
- Still applicable: the case tests behaviour the change did not touch. The result can stand.
- Needs re-running: the case tests changed behaviour, or its data sits on a boundary that moved. The old result describes the old rule; record a new result against the new one.
- No longer applicable: the behaviour it tested was removed. Keep the result as history, and retire the case.
Write the reassessment down. A release decision made weeks later should be able to see which evidence was re-earned after the change and which was carried over.
A worked example: shortening the refund window
This change was not made in ReqLens. It applies the steps above to the refund requirement used across the ReqLens Academy, using the test cases from its published TestCraft export, to show what the analysis looks like.
The change. Acceptance criterion ac-1, "refunds can be requested within 30 days of delivery", becomes 14 days after delivery. Requested by the payments lead, for a policy change. Classification: behaviour change.
Affected criteria. ac-1 changes. ac-2 (original card), ac-3 (no second refund), ac-4 (agent approval above a threshold) and ac-7 (only the order placer) are unaffected.
Following the trace from ac-1:
| Test case | Linked to | Affected? | Action |
|---|---|---|---|
| TC-001 Verify customer can initiate refund for eligible card payment within 30 days | ac-1 | Yes. Its title and its test data, an order delivered 15 days ago, sit on the wrong side of the new window. | Update the title and data to an order inside 14 days; re-run. |
| TC-012 Verify refund request for payment delivered exactly 30 days ago | ac-1 | Yes. The boundary moved. | Rewrite for exactly 14 days; re-run. |
| TC-013 Verify system rejection of refund request for orders outside the 30-day window | ac-1 | Yes. The first day outside the window is now day 15. | Rewrite for day 15; re-run. |
| TC-027 Verify system error handling for refund requests with non-existent order IDs | ac-1 | No. It tests unknown order IDs, not the window. | No change; its earlier result can stand. |
New questions the change creates. Which window applies to orders delivered before the change date? Does the customer-facing refund policy text change on the same day? Each one needs an owner and a date before the change is approved.
Earlier results. The published refund suite has not been executed, so there are no results to reassess. In a live project, an earlier pass of TC-012 would be historical evidence for the 30-day rule: it would need re-running against the 14-day rule, while an earlier result for TC-027 could stand.
A change impact record
Copy this for each change and keep it with the requirement.
Requirement and version:
Change (before / after):
Requested by, and why:
Classification (clarification / behaviour change / scope change):
Criteria changed, added or removed:
Dependent requirements affected:
Use-case flows affected:
Test cases to update, add or retire (with owners):
Test data to change:
Earlier results: still applicable / re-run / no longer applicable:
Open defects to re-check:
New open questions (owner, due date):
Decision (accept / defer / reject), decided by, date:
How ReqLens supports change impact
When a change to a requirement is committed, whether by editing it, applying or restoring a version, or committing a scope extension, ReqLens raises impact flags on:
- Dependent requirements, linked to it as depending on it. They are flagged on the Lifecycle Board and in the requirement drawer, where a team member can dismiss a flag; dismissals are recorded.
- Generated test suites and use-case sets. On the requirement's relationships panel, each shows as current, drifted (generated from an older version, with the versions shown) or not tracked.
- Individual test cases generated from an older version of the requirement.
Some things are deliberately not flagged, and you should cover them in your own analysis:
- Manually written test cases and cases imported from Jira or Azure DevOps carry no record of which requirement version they came from, so they cannot be flagged. Artifacts without that record show as not tracked, never as current.
- Earlier execution results and open defects are not flagged. Reassess them yourself, as described above.
Dismissing a flag acknowledges it; it does not make the artifact current. Regenerating from the new version does. The edit itself keeps the previous version, so the change can be compared later. See how edits are handled in Requirement Studio, or how ReqLens keeps traceability current.
Key takeaways
- State the change as before and after, then classify it before analysing it.
- Follow the trace from each affected criterion, and decide whether each linked item is really affected.
- Earlier results are historical evidence: reassess each one as still applicable, needing a re-run, or no longer applicable.
- Record the decision with owners, and keep the previous version.