How AI could help us not only identify the impact of requirements changes, but also understand what that impact means.
A requirement changes. What happens next? In well-structured Requirements Engineering, traceability already provides an important answer. It shows which other requirements, architecture models, risks, test cases, or other project artifacts are linked to the changed requirement. That tells us where a change could have an impact.
But that is not enough for a sound impact analysis. The harder question is: What does the change actually mean for the linked elements? Does a child requirement really need to change? Does the changed requirement still align with its parent requirement? Has an overlap with a neighboring requirement suddenly emerged? Is a test case really no longer valid or does the traceability relationship still exist even though the change is not relevant to it?
This is exactly where artificial intelligence becomes interesting.
The central thesis is:
Traditional traceability identifies potentially affected elements. AI can help assess whether and how they are affected in terms of meaning.
Impact Analysis Starts with Relationships
In our knowledge base article “What Is Impact Analysis in Requirements Engineering?” we described impact analysis as a systematic method for making the effects of planned requirements changes visible.
Impact analysis is not just about finding affected elements. It needs to answer four questions:
- Which elements are affected?
- Why are they affected?
- What semantic or structural consequences result?
- What actions follow from them?
The last three questions in particular show the limits of a purely structural view.
A traceability link can clearly document, for example, that Requirement A is linked to Requirement B. But it does not automatically answer: What does the specific change to A mean for B? To answer that, the meaning of the change must be understood and interpreted in the context of the linked requirement. This is one area where generative AI has particular strengths.
From Relationship Knowledge to Semantic Knowledge
Large Language Models can compare natural-language content and identify signals of semantic differences and relationships.
This creates an interesting division of labor for impact analysis.
- The requirements management system provides the relationship knowledge.
It knows hierarchies, traceability links, models, test cases, risks, versions, and other project information. - AI adds semantic knowledge to this relationship knowledge.
It analyzes what changed in a requirement and what semantic consequences that change could have for linked elements.
In short:
Traceability defines the search space. AI helps interpret the impact within that search space.
The three review directions of hierarchical impact analysis provide a good way to see what this could look like in practice.
Three Concrete Review Tasks for AI
For requirements hierarchies, hierarchical impact can be structured into three review perspectives:
- Parent Consideration: looking upward to the parent requirement.
- Child Coverage: looking downward to the child requirements.
- Slot Fit: looking sideways at requirements on the same level.
These methodological perspectives can be translated directly into three tasks for an AI assistant. One point is important: Parent Consideration, Child Coverage, and Slot Fit are initially local reviews of directly linked requirements.
If such a review produces a reasoned indication that another requirement may need to change, the responsible engineer must first assess whether that requirement should actually be modified. If it is changed, it becomes the starting point for a new impact analysis. In this way, a change can propagate step by step through the requirements hierarchy.
1. Parent Consideration: Does the Change Still Support the Higher-Level Goal?
A child requirement is changed. Traceability tells us which parent requirement it belongs to, so the relationship is clear. But does the changed child requirement still support the goal of the parent requirement?
An AI assistant could analyze the old wording, the new wording, and the parent requirement together. It could, for example, point out that:
- The new wording may be moving away from the higher-level goal.
- Part of the parent requirement may no longer be addressed.
- The changed requirement may extend the previous scope.
- A potential conflict may have emerged between parent and child.
A simple link thus becomes a concrete review task.
- Traceability says: These two requirements belong together.
- AI asks one additional question: Do they still fit together semantically after the change?
The Requirements Engineer receives not just an affected element, but a reasoned indication of why that element should be reviewed.
The review does not necessarily end with the immediate parent requirement. If the analysis produces a reasoned indication that this parent requirement could also be affected, the next step is to determine whether a change is actually required. If the parent requirement is then changed, it must be reviewed again against its own parent requirement. In this way, Parent Consideration can progress upward through several levels of the requirements hierarchy.
2. Child Coverage: Are the Existing Child Requirements Still Sufficient?
Now consider the opposite direction. A parent requirement initially states: “The system shall store measurement data.” Child requirements have been derived for retention period, data format, and storage capacity. The parent requirement is then changed to: “The system shall store measurement data in encrypted form.”
The existing traceability may still look perfectly fine. All child requirements are present. All relationships still exist. No requirement is orphaned. Yet a problem has emerged: None of the existing child requirements addresses the newly added aspect of encryption.
Structurally, the model is complete. Semantically, however, there is a gap. An AI assistant could therefore review:
- What meaning was added by the change?
- Which existing child requirements already cover that meaning?
- Which aspects are not yet addressed?
- Does an existing child requirement need to be extended?
- Is an additional child requirement needed?
This changes the question fundamentally. It is no longer just: Which child requirements exist? Instead: Do they still fully cover the changed requirement?
Child Coverage can also continue across multiple hierarchy levels. If the review produces a reasoned indication that a child requirement no longer fully covers the changed parent requirement, a decision must first be made about whether and how it should be modified.
If the child requirement is changed, its own child requirements must then be reviewed to determine whether they still fully cover the new meaning. In this way, every follow-up change that is actually made can trigger another Child Coverage review at the next level.
3. Slot Fit: Does the Requirement Still Fit Its Place in the Hierarchy?
A requirement is not only connected vertically to parents and children. It also has a context within its hierarchy level. If it changes, or if a new requirement is added, it must therefore be reviewed against its sibling requirements. The structural part is straightforward: The Requirements Management system can identify which requirements share the same parent. The semantic assessment is more difficult.
AI could analyze the relevant sibling requirements together and provide indications that:
- two requirements now describe the same subject matter,
- their scopes overlap,
- requirements contradict one another,
- there is a functional or semantic gap between several requirements,
- a new requirement may fit better at a different position in the hierarchy.
This is where the difference between structure and meaning becomes especially clear. Slot Fit does not merely ask, which requirements are on the same level, it asks: Are their scopes still clearly and meaningfully separated?
AI-Supported Impact Analysis Covers Different Change Events
Adding and Deleting Are Also AI-Relevant Change Events
Impact analysis does not start only when a requirement is reworded. Adding or removing a requirement also changes the requirements model. When a new requirement is added, an AI assistant could, for example, review Parent Consideration and Slot Fit:
- Does it really belong under the intended parent?
- Is there already a requirement with very similar meaning?
- Does it create a conflict?
Removing a requirement raises different questions:
- Is the parent requirement still fully covered?
- Do child requirements become Orphaned Requirements?
- Does a gap emerge between the remaining siblings?
AI support could therefore respond not only to one type of editing operation, but to different change events in the requirements model.
From Direct to Indirect Impact
Indirect impact can already arise within the requirements hierarchy. For example, if changing a requirement leads to a change in its parent or child requirement, that follow-up change can affect additional requirements at the next hierarchy level.
A single change can therefore create a recursive chain of effects:
Grandparent <- Parent <- changed requirement -> Child -> Grandchild
The analysis does not stop at a predefined hierarchy level. It continues as long as another engineering-relevant impact is visible at the next level.
This results in an overall impact-analysis model with three levels: local semantic review, recursive propagation of impacts, and indirect impact across artifact boundaries.
The analysis becomes even more challenging when the effect of a change extends beyond the requirements hierarchy to architecture, risks, tests, or other project artifacts.
Traceability can make these impact paths visible. But as the paths grow longer and more interconnected, the number of potentially affected elements increases substantially. Not every structurally reachable node in the traceability network necessarily has an engineering-relevant impact.
This creates another interesting task for an AI assistant: assessing the semantic relevance of impact paths and prioritizing them. It could help answer the key question: Which structurally reachable elements are actually relevant because of the specific semantic change?
A potentially long list of affected elements could thus become a prioritized review list of potential impacts, with reasons for each.
From a List of Results to a Reasoned Impact Finding
The value of AI-supported impact analysis should therefore not come from simply displaying even more hits. A reasoned assessment would be more useful. An AI assistant could, for example, produce findings like these:
- Parent Consideration – potential conflict
Finding:
The changed child requirement now requires a retention period of ten years. The parent requirement limits storage to five years.
Recommended review:
Check consistency between parent and child.
- Child Coverage – potential coverage gap
Finding:
After the change, the parent requirement additionally requires stored data to be encrypted. None of the currently linked child requirements appears to specify this aspect.
Recommended review:
Extend existing child requirements or derive a new requirement.
- Slot Fit – potential overlap
Finding:
The changed requirement semantically overlaps with an existing sibling requirement regarding encryption of persistent measurement data.
Recommended review:
Check whether the requirements should be separated more clearly or consolidated.
This would turn “This element could be affected” into a much more useful statement: “This element could be affected – for this reason and with this potential consequence.”
What AI-Supported Impact Analysis in objectiF RPM Could Look Like
objectiF RPM already includes AI-supported capabilities. AI support specifically for impact analysis does not exist yet. The vision therefore builds on two existing strengths. On one hand the structured traceability in objectiF RPM and on the other hand its integrated generative AI assistants.
That is exactly why it is worth exploring what such an assistant could look like. The starting point is strong: requirements are not managed in isolation in objectiF RPM. Hierarchies, relationships, and other project artifacts already provide the structural context.
A future Impact Assistant could build on this foundation. One possible workflow could start with a change event, use existing hierarchical evaluations – simplified as an “Impact Map” in the following graphic – and add a semantic AI pre-check, leading to a reasoned finding for human review and decision-making.
What a Good Impact Assistant Could Do
After a change, it could, for example:
- identify potentially affected elements through traceability,
- perform AI-supported pre-checks for Parent Consideration, Child Coverage, and Slot Fit,
- analyze direct and indirect impact paths, including recursive follow-up changes across multiple hierarchy levels,
- flag potential conflicts, coverage gaps, or redundancies,
- prioritize the relevance of identified impacts,
- provide an understandable rationale for each finding,
- suggest affected architecture, risk, and test artifacts for review,
- recommend possible next steps.
That would be more than a graphical view of dependencies. An Impact Map could become an interpreted Impact Map. For Requirements Engineers, the main benefit would be spending less time manually searching for possible side effects, identifying critical impacts earlier, and basing change decisions on clearly reasoned review hypotheses.
What a Good Impact Assistant Should Not Do
Because Large Language Models are probabilistic models, such an assistant should not present its assessments as absolute truth.
A statement such as “Child Coverage violated” would be more problematic than: “Potential coverage gap: The newly added encryption aspect is not evident in the currently linked child requirements.”
The second result is easier to understand, verifiable, open to engineering review and discussion, and much more useful to the responsible engineer. An AI assistant should therefore not become an automated Change Control Board. A more appropriate division of responsibilities is:
AI analyzes, prioritizes, and explains. The human reviews and decides.
Especially in regulated and safety-critical development environments, traceable engineering decisions by responsible professionals remain essential.
Explainability Becomes a Feature
This leads to another requirement for future AI capabilities. An Impact Assistant should not just provide a result. It should show:
- What was reviewed?
Which requirements and artifacts were considered? - Which relationship was relevant?
Parent, child, sibling, or another traceability path? - Which text change triggered the finding?
- Why is an impact suspected?
- How confident or clear is the assessment?
- What should the user review next?
Explainability therefore becomes more than a technical detail; it becomes a central part of the feature.
AI Makes Good Traceability More Valuable
The capabilities of modern language models might suggest that carefully maintained traceability will become less important. After all, a model could supposedly identify which content belongs together on its own.
For reliable impact analysis, however, that would be the wrong conclusion. The better the structure of the available information, the more focused AI can be.
A shared data foundation with
- uniquely identified requirements,
- well-maintained hierarchies,
- defined relationships,
- versions and baselines,
- architecture information,
- risks
- test information
reduces the search space and provides domain context.
AI then does not have to reconstruct the entire relationship model from an unstructured body of information. It can focus on the more demanding task: assessing the meaning of a change. Or, in short: AI does not replace the Single Source of Truth. It increases its value.
The Next Step in Impact Analysis
Traditional impact analysis and AI-supported impact analysis are therefore not opposites. They build on each other:
- Traceability identifies relationships.
- Impact analysis turns them into review tasks.
- AI can help assess and prioritize those review tasks semantically.
Parent Consideration, Child Coverage, and Slot Fit provide a simple but powerful methodological framework for this. And the idea can go further: from requirements to architecture, from architecture to risks, from risks to tests – and across multiple relationship steps. This creates a perspective that goes far beyond a single AI button.
A requirements management system that manages relationship knowledge can gradually evolve into a system that actively assists engineers, using that knowledge to make the effects of changes visible earlier, more systematically, and in a way that is easier to understand.
The key question in impact analysis is then no longer just: What is connected to this requirement?
Instead: What does this change mean for our system – and where should we take a closer look?
This is exactly where AI could provide especially valuable support to Requirements Engineers in the future.