Impact Analysis

What Impact Analysis Is For

Impact analysis is the process of examining a proposed or actual change to determine which requirements, designs, processes, systems, organizational units, and stakeholders will be affected, and how significant each effect will be. In BABOK v3, this activity sits primarily within the Requirements Life Cycle Management knowledge area's Assess Requirements Changes task, and it draws on risk-assessment thinking from Strategy Analysis as well. Its purpose is straightforward: before a change is approved and implemented, the organization needs to know what else it will disturb, how much that disturbance will cost, and whether the benefit still justifies moving forward.

Without impact analysis, teams accept changes that quietly break other requirements, blow past budget or schedule, or introduce risk nobody evaluated. With it, the organization makes an informed, traceable decision — approve, reject, or defer — through an appropriate governance process.

The Impact Analysis Process

A typical impact analysis, whether formal or informal, follows a consistent sequence:

1. Identify the proposed change — a new requirement, a design change, a defect fix, or an external event such as a new regulation that forces a change.
2. Trace relationships — use requirements traceability to find every requirement, design element, business rule, and system component connected to the changed item.
3. Identify impacted areas — business processes, technology and systems, organizational units, other requirements or designs, schedule, and budget.
4. Evaluate the change — weigh benefit against cost, assess urgency, and identify any new risk introduced.
5. Determine disposition — approve, reject, or defer the change through the organization's change control process.
6. Communicate the outcome — inform affected stakeholders of the decision and any resulting adjustments.

Techniques Used in Impact Analysis

Several BABOK techniques support this work, and each is useful for a different kind of impacted area:

Formality Varies with the Business Analysis Approach

Not every impact analysis looks the same. In a plan-driven, predictive initiative, a formal change control board may require documented impact analysis and sign-off before any requirement changes. In an adaptive (agile) environment, the same underlying questions — what does this affect, and is it worth doing — are often answered informally during backlog refinement or a conversation between the product owner and the team. Neither approach skips impact analysis; they differ in how much documentation and ceremony surrounds it. Recognizing which approach a given situation calls for is a common discriminator in situation-based ECBA questions.

A Worked Example

Consider a mid-size insurer where a compliance team requests a new mandatory field on the claims-intake form to capture a customer's preferred contact method, driven by a new regulation. A BA performing impact analysis would first trace the intake form's existing relationships: which downstream systems consume that data, which reports are generated from it, and which business rules govern how contact preferences are used. Tracing might reveal that three downstream systems ingest the intake form's data feed, one of which uses a fixed-length record format that would need to be restructured to accommodate the new field. It might also surface that customer service scripts reference the current set of contact-method options and would need to be updated. None of this is visible from the change request alone; it only becomes visible once traceability is used to follow the change's ripple effects.

Traceability as the Backbone of Impact Analysis

None of the impact-analysis steps above are possible without requirements traceability — the practice of recording and maintaining relationships between requirements, designs, business rules, and other artifacts as they are created. A traceability matrix or tool lets a BA answer, quickly and reliably, the question every impact analysis ultimately depends on: if this one thing changes, what else is connected to it? Without traceability in place, impact analysis degrades into guesswork or, worse, the missed dependency is only discovered after the change has already been implemented.

The Entry-Level BA's Role

At the ECBA level, a business analyst is rarely the person with sole authority to approve or reject a change. More often, the BA gathers data, traces relationships, documents affected items, and presents findings to the decision-makers — a product owner, a change control board, or a project sponsor — who then make the disposition call within the organization's governance structure. This distinction matters for situational questions: when a scenario asks what a BA should do upon receiving a change request, the strongest answer is usually to investigate and document the impact, not to unilaterally approve, reject, or implement the change outright.

Impact Analysis and Value Protection

Ultimately, impact analysis exists to protect the value the change was meant to create. A change that seems small in isolation — one new field on a form, one new business rule — can cascade into unexpected cost or risk if its true footprint isn't traced first. By systematically identifying impacted requirements, systems, processes, and people before a decision is made, the BA helps the organization avoid scope creep, wasted rework, and value-eroding surprises later in the initiative.