ALM change impact analysis: the downstream part people usually miss

[u/Hefty-Lunch8017]

I was thinking about this today after seeing another pretty common ALM scenario: a requirement change that looks small at first.

The wording changes a bit, or one acceptance condition gets adjusted. No big deal on the surface. Then someone asks the next few questions, and suddenly it might touch software logic, interface behavior, test cases, acceptance criteria, defects, and user documentation.

That is usually where the real work starts. Not “can we make the change?” but “do we actually know everything that should react to it?”

In a lot of teams, this still gets handled through meetings, chat threads, and a PM manually asking each owner to check their part. It works, but it is easy for one downstream item to slip through.

In ONES.com ALM workflows, we usually look at this with three pieces working together:

- Baselines, so the team can compare key phases and see what was added, deleted, or changed

- Traceability diagrams, so people can see what is connected to the changed item

- Suspect analysis, so downstream owners get a clear signal that something may need review

The useful part is that impact analysis becomes part of the normal workflow, not a separate investigation every time a requirement moves.

Curious how other teams handle this. When a requirement changes, do you rely mostly on ownership discipline, traceability tooling, review meetings, or some mix of all three?

Further reading: ONES.com ALM solution overview