Change impact analysis

Published 21 October 2026

A change impact analysis works out, before a change is agreed, everything it touches — the requirements, the built work, the data, the integrations, the tests, the cost and the dates — so the decision is made on the whole change, not on how small it sounds. Below are what to check, a template, a worked example, how to do it, the three ways impact is found, impact analysis in testing, an Excel version, and impact analysis in agile and with AI coding agents.

Customer: Hey this field name does not exactly represent what we want to convey. Can we change its name quickly before we go live?

Eager Novice (who is unfortunately in front of the customer at that moment): Oh yeah, that’s just a small change in the Customer model. I think we an get this ready and unit tested in 2 hours.

[…]

Grizzled Veteran/Grey Beard (who for some reason wasn’t consulted on the change request): Hmmm....have we done an impact analysis of the change? What are the downstream impacts on code that references this field? What do we need to do to propagate the change to the db? What about the seven or so Web Services that are impacted by this field change? How long does it take to do a regression test? etc..

Net effect: 2 Hrs initial estimate given to customer; 4 Days worth of work in actuality; Production deployment moved down a week..

— Hacker News, 2016

In the software literature, Bohner and Arnold define impact analysis as “identifying the potential consequences of a change, or estimating what needs to be modified to accomplish a change”; Pfleeger and Atlee add “the evaluation of the many risks associated with the change, including estimates of the effects on resources, effort, and schedule” (Wikipedia). In organisational change management, a “change impact assessment” means something else — how a change affects people’s roles and work. This page is about changes to software and its requirements.

What a change impact analysis covers

Change impact analysis template

Copy it into the change request, or keep it as its own document. Square brackets are yours to fill in.

CHANGE IMPACT ANALYSIS
Change:      CR-[n], [title]
Asked by:    [name, role], [date]
Requirements version: [x.y]
Analysed by: [name, role], [date]

1. THE CHANGE
Now:       [what the requirement says]
Proposed:  [what it would say]
Why:       [the reason, in their words]

2. CHANGED DIRECTLY
[requirement ID]  [what changes]

3. AFFECTED THROUGH THEM
Requirements:  [IDs, and how]
Design, code:  [screens, services]
Data:          [fields, migrations]
Integrations:  [other systems]
Documents:     [specs, help, contract]

4. TESTS
To change:     [IDs]
To run again:  [IDs]
New:           [cases not tested yet]

5. NON-FUNCTIONAL
[what changes, or "none", and why]

6. EFFORT, COST, DATES
Effort:  [days], including retesting
Cost:    [amount] at the contract rate
Dates:   [what moves]

7. RISKS
If done:      [   ]
If not done:  [   ]

8. OPTIONS
A. [as asked]
B. [a smaller version]
C. [later, or a swap]

9. OPEN QUESTIONS
Q1  [question], owner [name], by [date]

10. DECISION
Decision:  approved / declined / deferred
Option:    [   ]
By:        [name, role], [date]
New requirements version: [x.y]

Change impact analysis example

The customer portal from the other templates, after phase 1 was signed off. The client’s finance lead asks for CR-10: customers paying large invoices in parts.

CHANGE IMPACT ANALYSIS
Change:      CR-10, pay part of an invoice
Asked by:    finance lead, 10 June
Requirements version: 1.3
Analysed by: business analyst, 12 June

1. THE CHANGE
Now:       FR-014: a signed-in customer
           can pay any open invoice of
           their company by card.
Proposed:  ... can pay all or part of
           any open invoice ...
Why:       "Some customers pay large
           invoices in two or three goes."

2. CHANGED DIRECTLY
FR-014  the amount can be less than
        the balance

3. AFFECTED THROUGH THEM
FR-010  invoice list: new status
        "Partly paid", amount still due
FR-011  PDF: payments so far, balance
FR-015  receipt: amount paid, balance
FR-016  reminder: for a partly paid
        invoice too? (Q1)
FR-021  CSV export: not built yet; add
        the balance column now
UC-03   steps 2 and 6
Data:   many payments per invoice
        (today: at most one)
Integrations: the accounting export
        sends one payment per invoice

4. TESTS
To change:     TC-103, UAT-03
To run again:  TC-101, TC-102,
               UAT-01, UAT-02
New:           a part payment; the last
               part pays it in full; an
               amount above the balance

5. NON-FUNCTIONAL
NFR-007 unchanged: one payment at a
time, same page

6. EFFORT, COST, DATES
Effort:  9 days, including retesting
Cost:    7,200 EUR at the SOW day rate
Dates:   phase 2 moves by one week

7. RISKS
If done:      the accounting export
              must change at the same
              time, or it double-counts
If not done:  large invoices stay on
              bank transfer

8. OPTIONS
A. Any amount, as asked: 9 days,
   7,200 EUR.
B. At most two parts: 6 days,
   4,800 EUR.
C. Phase 3.

9. OPEN QUESTIONS
Q1  Remind about a partly paid invoice?
    Owner: finance lead, by 16 June

10. DECISION
Decision:  approved
Option:    A
By:        finance lead (client), 17 June
New requirements version: 1.4

The request changes one sentence in FR-014. The impact is five more requirements, the use case, the data model, an integration, six existing tests and three new ones. Most of it came from following links: the requirements that show an invoice’s status or amount all depend on FR-014. Two things did not. The payments table allows one payment per invoice — that came from the code. And the accounting export assumes the same — that came from the developer who built it, because no requirement mentions it.

The old wording stays readable after the decision: version 1.3 is still what phase 1 was signed against, and 1.4 is what phase 2 will be. See the requirements baseline, and requirements change management for what happened to CR-10 after the decision.

How to do a change impact analysis

1. Write the change as wording. Not “add part payments” but the requirement as it is now and as it would be. Most of the questions show up in the difference.
2. Follow the links from the requirement. Up to its source, across to the requirements that depend on it, down to the design, the code and the tests. A traceability matrix makes this a lookup instead of a memory exercise.
3. Search the code and the data for what the links miss. One commenter: “I find doing a quick org-wide code search for a specific call a great starting point for impact analysis for API changes” (Hacker News, 2023).
4. Ask the people who built it. Integrations, reports and workarounds often live in nobody’s requirements. Do not answer in the meeting where the change is asked for. In the words of someone who calls themselves one of a couple of domain experts on their team: “One simply cannot know these things off the top of their head in a meeting for a system of any meaningful size” (Hacker News, 2018).
5. List the tests: which change, which run again, which are new.
6. Check the rest of the list: non-functional requirements, data migration, documents, the contract.
7. Size it, including retesting, and turn it into cost and dates at the contract rate.
8. Write the risks and the options: as asked, a smaller version, later, or a swap for something of equal size.
9. Get a decision, then update everything to a new version — the requirements, the traceability matrix, the tests. The change request template has the form and the decision email.

The effort should match the change. A typo in a label needs a minute’s check; a change to how money is taken needs the whole template.

Traceability, dependency and experience

The example found its impact three ways, which match the three types of impact analysis described in the literature (Wikipedia):

Traceability is the only one that works before anything is built, and the only one a client can follow. Dependency analysis needs the code. Experience leaves when the people do.

Impact analysis in software testing

In testing, impact analysis decides which tests a change makes necessary: the tests of what changed, the tests of what depends on it, and new tests for what was not there before.

Impact analysis vs regression testing: impact analysis is the thinking — what could this change break? Regression testing is the running — the tests that check that what worked before still works. The impact analysis is what keeps the regression run from being either everything or a guess.

At the code level, this can be automated. Test impact analysis “works by analyzing the call-graph of the source code to work out which tests should be run after a change to production code” (Paul Hammant on martinfowler.com, 2017). One commenter adds that it is “something worth making deterministic. Like with an algorithm, and without an LLM.” (Hacker News, 2025). Acceptance tests — the ones the client cares about — still come from the requirements.

Change impact analysis in Excel

For a project with many changes, one row per affected item:

CR,Item,Type,How affected,Action,Tests,Days,Owner

Summed by change request, the Days column is the estimate; filtered by Type = Test, it is the test plan for the change.

Impact analysis in agile

In Scrum or Kanban the change usually arrives as a new story or an edit to an old one, and the question is the same. A story not started yet costs only its rewrite. A story that is done is a change to built work: its acceptance criteria, its tests and every story that relies on it are affected. In Jira, linking the stories (“relates to”, “is blocked by”) and the requirements they implement makes the impact a search instead of a meeting.

Reordering the backlog is not impact analysis: it decides what comes next, not what a change breaks. The two meet in refinement, where a story with a large impact gets split or re-estimated.

Impact analysis and AI coding agents

An AI coding agent can do dependency analysis quickly: search the code, follow calls, list the files a change touches. What it cannot find is what was never written down — the accounting export in the example, or the client’s reason for the original wording. An agent asked to make a change may also edit the tests until they pass; the impact analysis says in advance which tests should change, so that the others stay as they are.

Specs for agents help only if they are linked: a requirement in a spec file, with the tests and code that implement it, can be traced; a paragraph in a chat history cannot. See spec drift.

Where Specroot fits

This is the problem Specroot works on: each change shown against the requirements it touches and the version that was agreed, with its impact visible before anyone says yes. Specroot for agencies and consultancies.