When a requirement changes, how far do you walk its traceability links to build the impact set?

middlemust knowfreq 58%

answer

Start where the change was actually stated
Follow the links outward in hops
Criteria, then cases, then prior defects
Each hop weakens the claim behind it
Agree the stop rule before walking

basics

~20 s

Walk outward hop by hop — the requirement's acceptance criteria, the test cases linked to them, then the defects raised in that area before — and stop at the hop that stops adding anything you would re-verify.

solid answer

~50 s

An impact set is the bounded list of things a change could plausibly have disturbed. Build it in hops outward from the changed requirement: its acceptance criteria, then the test cases linked to those criteria, then the defects raised previously against that requirement or its cases, then whatever those cases share with other requirements. Each hop widens the set and weakens the evidence behind it, so the walk needs a stop rule agreed in advance — a fixed hop budget, or stop when you can no longer say in one sentence why an added item could break. Record what you excluded and why, because the exclusions are the part somebody will later challenge. The output is a scoped set with its boundary written down, handed to whoever owns depth and schedule — not a verdict on the release.

An impact set is the bounded list of things a change could plausibly have disturbed. Build it in hops outward from the changed requirement: **its acceptance criteria**, then **the test cases linked to those criteria**, then **the defects raised previously against that requirement or its cases**, then whatever those cases share with other requirements. Each hop widens the set and weakens the evidence behind it, so the walk needs a stop rule agreed in advance — a fixed hop budget, or *stop when you can no longer say in one sentence why an added item could break*. Record what you excluded and why, because the exclusions are the part somebody will later challenge. The output is a scoped set with its boundary written down, handed to whoever owns depth and schedule — not a verdict on the release.

code

pseudocode · 17 lines

pseudocode

impactSet = {}
frontier  = { changedRequirement }
hop       = 0

while frontier is not empty and hop < MAX_HOPS:
    nextFrontier = {}
    for node in frontier:
        for neighbour in linkedFrom(node):
            if canExplainInOneSentence(node, neighbour):
                impactSet.add(neighbour, atHop = hop + 1)
                nextFrontier.add(neighbour)
            else:
                excluded.add(neighbour, reason = "connection not explainable")
    frontier = nextFrontier
    hop      = hop + 1

report(impactSet, stopRule = MAX_HOPS, excludedItems = excluded)

go deeper

for a junior

Be ready to say what change-impact analysis produces: a bounded list of what a change could have disturbed, built outward from the requirement. Know that acceptance criteria sit between a requirement and the test cases that verify it.

for a middle

Explain the hops in order and what each one adds — criteria, then the cases linked to them, then defects raised in that area before. An interviewer expects you to name a stop rule rather than describe an unbounded walk.

for a senior

Show that you agree the stop rule before walking and hand over the exclusions alongside the inclusions. Expect to be asked what you do when the record is thin, and to answer without either giving up or widening the set to everything.

for a principal

Own the question of what this analysis is allowed to decide. Deriving a set is cheap; letting it quietly become a schedule is where teams lose the ability to challenge it. Set the boundary between derivation and decision, and make the stop rule a team default rather than a per-change argument.

What an impact set is

A change-impact analysis answers a single question: if this requirement changed, what else might now be wrong? Its output is an impact set — a bounded list of acceptance criteria, test cases, components and previously fixed defects that the change could plausibly have disturbed. It is deliberately a set and not a plan. It says what is in scope for further thought; it says nothing about what will actually be re-verified, in what order, or by whom. Those are separate decisions, made later, by people with a budget in front of them.

The raw material is the traceability record a team already keeps: a link from each requirement to the acceptance criteria that make it checkable, from each criterion to the test cases that verify it, and from each defect record to the case that caught it. Change-impact analysis is what those links are for. A team that maintains them only to satisfy an audit never collects this return on the effort.

Walking outward, one hop at a time

Treat the record as a graph and walk it in hops, starting at the changed requirement.

Hop one — acceptance criteria. Which criteria attached to this requirement now say something different? A criterion whose wording was tidied but whose meaning is unchanged is not impact. Only reading them tells you which is which, and this is the hop where the change is actually stated, so it is the strongest evidence you will get.
Hop two — verifying test cases. Every case linked to a changed criterion is in the set: it asserts behaviour that was just redefined. Cases linked only to unchanged criteria of the same requirement sit in a grey band — they exercise the same feature and often share setup, but nothing about them was asked to change.
Hop three — prior defects. Defect records raised previously against this requirement, or against the cases from hop two, show where this area has broken before. Historical fragility is a reason to look, not proof of new breakage, and treating it as proof is how an impact set turns into a list of everybody's least favourite code.
Hop four — shared reach. The components, shared data and common setup that the hop-two cases also touch, plus the other requirements that reach the same places. This hop is where the set starts growing faster than the evidence supporting it.

Each hop adds items and weakens the claim attached to them. Hop one is near-certain; hop four is a guess with a rationale attached.

Hop	What it adds	Strength of the claim
Criteria of the changed requirement	Exactly what was asked to change	Direct — the change is stated here
Cases linked to those criteria	Verifications that still assert the old behaviour	Strong — an explicit link exists
Defects raised here before	Where this area historically breaks	Historical — fragility, not causation
Shared components and their requirements	Everything reachable through common ground	Weak — reachability is not effect

Where the walk has to stop

Nothing in the record stops the walk for you. Follow shared reach far enough and the impact set becomes the whole product, which carries exactly as much information as having done no analysis at all. So the stop rule is agreed before the walk rather than argued afterwards. Three that hold up in practice:

A hop budget. Two or three hops, fixed in advance. Crude, but auditable, reproducible, and impossible to argue into growing halfway through.
The one-sentence test. Stop at the hop where you can no longer say, in one sentence, why an added item could break. If the connection needs a paragraph, it is speculation wearing the clothes of derivation.
Marginal yield. Stop when a hop adds items but changes nothing anyone would look at. If a hop only restates what the previous one already implied, the walk is finished regardless of how much graph remains.

Which rule you pick matters less than picking one and writing it next to the result.

What you hand on

The deliverable is the set plus its boundary: the stop rule you used, the hops you took, and — the part most people omit — the items you excluded and why. Exclusions are where an escape comes from, and they are the only part of the analysis anyone can meaningfully review. Two impact sets listing the same forty items are not equivalent if one of them cannot say what it left out.

Keep the analysis honest about its own direction as well. It derives what might be affected. It does not rank those items, allocate effort between them, or choose the subset that will actually run; those belong to whoever owns the schedule and the risk position. Handing over a set with a schedule quietly baked into it is the fastest way to lose the trust of the people receiving it, because they can no longer tell which part was derived from links and which part is your opinion.

## What an impact set is A **change-impact analysis** answers a single question: if this requirement changed, what else might now be wrong? Its output is an **impact set** — a bounded list of acceptance criteria, test cases, components and previously fixed defects that the change could plausibly have disturbed. It is deliberately a *set* and not a plan. It says what is in scope for further thought; it says nothing about what will actually be re-verified, in what order, or by whom. Those are separate decisions, made later, by people with a budget in front of them. The raw material is the traceability record a team already keeps: a link from each requirement to the acceptance criteria that make it checkable, from each criterion to the test cases that verify it, and from each defect record to the case that caught it. Change-impact analysis is what those links are *for*. A team that maintains them only to satisfy an audit never collects this return on the effort. ## Walking outward, one hop at a time Treat the record as a graph and walk it in hops, starting at the changed requirement. 1. **Hop one — acceptance criteria.** Which criteria attached to this requirement now say something different? A criterion whose wording was tidied but whose meaning is unchanged is not impact. Only reading them tells you which is which, and this is the hop where the change is actually stated, so it is the strongest evidence you will get. 2. **Hop two — verifying test cases.** Every case linked to a changed criterion is in the set: it asserts behaviour that was just redefined. Cases linked only to unchanged criteria of the same requirement sit in a grey band — they exercise the same feature and often share setup, but nothing about them was asked to change. 3. **Hop three — prior defects.** Defect records raised previously against this requirement, or against the cases from hop two, show where this area has broken before. Historical fragility is a reason to look, not proof of new breakage, and treating it as proof is how an impact set turns into a list of everybody's least favourite code. 4. **Hop four — shared reach.** The components, shared data and common setup that the hop-two cases also touch, plus the other requirements that reach the same places. This hop is where the set starts growing faster than the evidence supporting it. Each hop adds items and weakens the claim attached to them. Hop one is near-certain; hop four is a guess with a rationale attached. | Hop | What it adds | Strength of the claim | | --- | --- | --- | | Criteria of the changed requirement | Exactly what was asked to change | Direct — the change is stated here | | Cases linked to those criteria | Verifications that still assert the old behaviour | Strong — an explicit link exists | | Defects raised here before | Where this area historically breaks | Historical — fragility, not causation | | Shared components and their requirements | Everything reachable through common ground | Weak — reachability is not effect | ## Where the walk has to stop Nothing in the record stops the walk for you. Follow shared reach far enough and the impact set becomes the whole product, which carries exactly as much information as having done no analysis at all. So the stop rule is agreed before the walk rather than argued afterwards. Three that hold up in practice: - **A hop budget.** Two or three hops, fixed in advance. Crude, but auditable, reproducible, and impossible to argue into growing halfway through. - **The one-sentence test.** Stop at the hop where you can no longer say, in one sentence, why an added item could break. If the connection needs a paragraph, it is speculation wearing the clothes of derivation. - **Marginal yield.** Stop when a hop adds items but changes nothing anyone would look at. If a hop only restates what the previous one already implied, the walk is finished regardless of how much graph remains. Which rule you pick matters less than picking one and writing it next to the result. ## What you hand on The deliverable is the set plus its boundary: the stop rule you used, the hops you took, and — the part most people omit — the items you **excluded and why**. Exclusions are where an escape comes from, and they are the only part of the analysis anyone can meaningfully review. Two impact sets listing the same forty items are not equivalent if one of them cannot say what it left out. Keep the analysis honest about its own direction as well. It derives what *might* be affected. It does not rank those items, allocate effort between them, or choose the subset that will actually run; those belong to whoever owns the schedule and the risk position. Handing over a set with a schedule quietly baked into it is the fastest way to lose the trust of the people receiving it, because they can no longer tell which part was derived from links and which part is your opinion.

What do you do when the changed requirement has no acceptance criteria linked to it at all?
Treat the missing links as the first finding rather than as a blocker. Derive the criteria from the requirement text yourself, write them down, and mark the impact set as reconstructed rather than traced. Then add the links you just worked out, so the next change in this area starts from a record instead of from somebody's reading.
Why record the items you excluded from the impact set rather than only the ones you included?
Because the exclusions are where an escape comes from, and they are the only part of the analysis anyone can review. An included item defends itself by being visible; an item dropped silently at the boundary leaves no trace of the judgement that dropped it, so the same gap repeats next release with nobody the wiser.
Where does this analysis end and the decision about what to re-verify begin?
The analysis ends at a bounded set with a stated stop rule and stated exclusions. Depth, ordering and the subset that actually executes belong to whoever owns the schedule and the risk position. Blurring the two hides which items were derived from links and which were chosen by preference, and it makes the set impossible to challenge on its merits.

Like tracing a water leak: you start at the wet patch and follow the pipe joint by joint, stopping when the next joint is dry — not when you run out of pipe.

saying these in an interview costs you the question

Treats the whole product as impacted whenever anything shared is touched
Stops at the first hop and calls the linked cases the whole set
Cannot say what was excluded from the impact set or why
Confuses the impact set with the list of work that will run
Assumes a re-worded acceptance criterion always means changed behaviour

When a requirement changes, how far do you walk its traceability links to build the impact set?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What an impact set is

Walking outward, one hop at a time

Where the walk has to stop

What you hand on

▾common follow-ups3 questions

▾analogy~10 s

▾red flags5 flags

What an impact set is

Walking outward, one hop at a time

Where the walk has to stop

What you hand on

answer

go deeper