What is an Impact-Analysis in Requirements Engineering?

In Requirements Engineering, an impact analysis is a systematic process for identifying and evaluating the effects of a planned change to requirements. It determines which requirements, models, test cases, risks, or project artifacts are affected by the change, as well as the consequences of the change.

Thus, an impact analysis provides a solid foundation for informed change decisions. It reduces the risk of unexpected side effects, improves effort estimation, and supports controlled change management.

Changes are a daily occurrence in any development project. New customer requirements, altered framework conditions, new technical insights, and updates to standards and regulations may require adjustments to existing requirements, such as adding or removing them.

However, such changes rarely affect just one requirement. In modern Systems Engineering, requirements are linked to numerous other requirements and artifacts via hierarchies and traceability relationships. Therefore, even a minor change can impact system architecture, test cases, safety analyses, or project planning.

Impact analysis aims to make these effects as fully visible as possible before a change is actually implemented.

The term “impact” refers to the effects and consequences of a change. It’s not just about identifying affected elements. It is equally important to understand how and why they are affected.

Therefore, an impact analysis answers four central questions:

1. Which elements are affected by the change?
2. Why are they affected?
3. What content-related or structural consequences arise?
4. What measures result from this?

Different types of impact can occur in this context.

Hierarchical Impact

Requirements often form a hierarchy of overarching and subordinate requirements. When a requirement changes, the relationships with requirements above, below, and on the same level must be reviewed.

Technical Impact

Requirements form the basis of architecture models, interfaces, and software or hardware components. Therefore, a change may require adjustments to UML or SysML models, system architecture, interfaces, or implementation.

Quality and Verification Impact

Test cases and acceptance criteria are based on requirements. If an underlying requirement changes, verify which tests need to be adapted or re-executed, and determine if existing verification records are still valid.

Risk and Compliance Impact

Changes can influence existing risk analyses, safety assessments, or compliance records, especially in regulated or safety-critical projects.

Economic and Organizational Impact

Finally, changes can affect development efforts, resources, responsibilities, schedules, and costs. Therefore, the results of an impact analysis are a vital baseline for deciding how and whether to execute a planned change.

Impact analysis within a requirement hierarchy is particularly critical. For example, a system requirement can be specified by several subsystem requirements, from which component requirements are then derived.

Therefore, changes must not be viewed in isolation. Three directions of hierarchical impact must be examined to form a simple evaluation grid for analyzing these effects.

Parent Consideration

A Parent Consideration checks if a requirement is still compatible with its parent requirement and if it contributes to fulfilling that requirement.

For example, if a child requirement is changed, it may no longer support the original goal of the parent requirement.

Typical review questions are:

• Does the changed requirement still align with the goal of the parent requirement?
• Does it continue to specify the intended portion of the higher-level requirement?
• Does the change create a contradiction with the parent requirement?
• Might the change lead to moving outside the originally defined scope?

Thus, a Parent Consideration thus views the impact from bottom to top.

Child Coverage

Child Coverage looks in the opposite direction. Here, it is checked whether a parent requirement is still fully specified and covered by its child requirements.

For instance, when a parent requirement is expanded, the existing child requirements may still be technically correct, but insufficient to fully cover the new scope.

Typical review questions are:

• Do the existing child requirements still fully cover the changed parent requirement?
• Do the existing child requirements need to be adapted?
• Are additional child requirements necessary?
• Would removing a child requirement create a coverage gap?

Child Coverage thus views the impact from top to bottom.

Slot Fit: Delineation against Peer Requirements

A requirement must fit not only its parent and child requirements, but also the group of peer requirements. It must also occupy a logical and clearly defined position within the group of peer requirements.

This perspective is described as Slot Fit.

When a requirement is newly added or modified, you must check how it behaves relative to its sibling requirements.

Typical review questions are:

• Does the requirement overlap in content with an existing requirement?
• Does redundancy arise?
• Do two requirements contradict each other?
• Is there a functional or semantic gap remain between requirements?
• Does the requirement even belong at this specific point in the hierarchy?

Slot Fit thus complements the vertical views of Parent Consideration and Child Coverage with a horizontal perspective.

Every structural intervention in the requirements model can trigger a chain reaction. The three review directions help to systematically evaluate the consequences:

When an Existing Requirement Is Changed

The most common scenario in everyday project work is changing an existing requirement.

When an existing system requirement is expanded to include an additional aspect, all three perspectives are relevant.

Finally, investigate which downstream artifacts, such as architecture models, risks, and test cases, are affected.

When a Requirement Is Removed

Removing a requirement can also trigger a chain reaction.

In the case of a child requirement, the question arises, from the perspective of  Child Coverage, whether its parent requirement is still fully covered afterwards. If a gap emerges, it must be closed by either an existing requirement or a new one.

Conversely, if a parent or intermediate requirement is removed, the underlying child requirements can lose their logical reference. This creates so-called orphaned requirements.

A decision must then be made as to whether to drop these orphaned requirements or reassign them to a different parent requirement.

The Slot Fit can also change. Dropping a requirement can shift the areas of responsibility of the remaining sibling requirements or create new gaps.

When a new requirement is added

Parent Consideration first checks whether it actually belongs to the intended parent requirement and supports its goal.

Next, Child Coverage examines whether the new requirement needs further specification and whether additional child requirements are necessary to achieve this.

Finally, Slot Fit checks its position against already existing sibling requirements. This can reveal redundancies, overlaps, or contradictions.

Simply inserting a new requirement into a hierarchy is therefore not enough. It is crucial that it fits semantically and structurally into the existing model.

Another important distinction is between direct and indirect impacts.

• A direct impact affects elements that are immediately connected to the changed requirement. This can be, for example, the direct parent requirement, child requirements, or an assigned test case.
• An indirect impact, on the other hand, occurs across multiple relationship steps.

For instance, if a system requirement changes, this may initially affect a subsystem requirement. that change, in turn, influences an interface, which then impacts another component and its corresponding test cases.

The longer these impact chains grow, the harder it becomes to fully identify all the consequences of a change.

Traceability connects requirements, for example, with:

• Parent and child requirements,
• Other dependent requirements,
• Architecture models,
• Risks,
• Test cases,
• Implementation artifacts.

Traceability thus initially answers the question:

Which elements are related to the changed requirement and could therefore be affected?

It thereby provides the structural foundation for the impact analysis.

However, the existence of a relationship alone does not answer what content-related consequences a change has for the connected element. To determine this, the meaning of the change must be evaluated within its specific context.

In small requirements models, a requirements engineer can often manually oversee many impacts. However, as project size increases, the number of requirements and their relationships grow.

With several thousand requirements, a complex network of hierarchies and dependencies emerges.

A change can then:

• Affect numerous direct relationships,
• Propagate across multiple hierarchy levels,
• Have indirect effects on distant artifacts, and
• Cause semantic contradictions or coverage gaps that are not recognizable from the relationships alone.

Therefore, the true challenge lies not only in identifying affected elements, but also in accurately assessing the significance of a change for those elements.

objectiF RPM manages requirements and their relationships in a central repository. These requirements can be structured hierarchically and linked to other project artifacts. This makes it possible to see which elements may be affected by a planned change.

In objectiF RPM, traceability, requirement hierarchies, and linked project artifacts establish a structured data foundation for impact analyses. This enables the systematic investigation of relationships and, in the future, their evaluation using automated or AI-supported analysis methods.

With objectiF RPM, these perspectives can be mapped transparently. A Parent Consideration supports the upward view, a Child Coverage supports the downward coverage check, and Slot Fit supports the delineation from requiements at the same level.

objectiF RPM creates a shared working foundation for Requirements and Change Management. Changes can be systematically evaluated based on linked requirements, artifacts, and dependencies. This creates a reliable foundation for controlled project decisions.

Conduct Impact Analysis Methodically and Reliably

Discover how objectiF RPM brings Requirements Engineering, Traceability, and Change Management together in a single environment.