A requirement can be clear, testable, and implemented exactly as written, and the resulting system can still behave in a way nobody intended. Good requirements review is therefore not only about checking individual requirements. It is also about understanding how they work together.
Consider an online shop where customers can request returns through their accounts. The same shop also allows customers to delete their accounts immediately. Both features may work exactly as specified. But together, they raise a question: what happens if a customer deletes their account and later needs to return an eligible order?
The problem is not necessarily in either requirement by itself. It appears when the two are considered together. If AI is going to help with this kind of review, it needs enough context to see those connections.
What requirements review needs to establish
Requirements describe what people expect from a system, what qualities it should have, and what constraints it needs to follow. Requirements engineering helps teams develop and maintain a shared understanding of those expectations.
Reviewing requirements can happen at different levels. An individual requirement might be unclear or difficult to test. Several requirements might overlap, contradict each other, or leave an important situation uncovered. Later in development, teams may also want to check whether the implementation and tests actually support what the requirements describe.
AI can already help with some of this work. It can find ambiguous wording, compare similar requirements, and point out possible gaps.
But finding something unusual is only the first step.
A missing requirement may actually be covered by a project-wide policy. Two requirements that look almost identical may apply to different users. A difference that looks like a conflict may be intentional.
To judge these cases, AI needs more than the requirement text itself. It needs information about how that requirement fits into the project.
Context changes the meaning of a finding
Take a simple example. Imagine two requirements that give different response-time limits. At first, they may look inconsistent. But perhaps one applies during normal operation and the other during an emergency. In that case, there may be no conflict at all.
The same problem appears when looking at similar requirements.
A requirement for creating a shipping label and another for creating a return label might use almost the same wording. That similarity could be useful. They may share carrier rules or tests. But treating them as duplicates could also remove an important distinction between two different processes.
AI can help find these relationships. Deciding what they mean requires context.
One way to provide that context is through a context graph. Requirements can be connected to related requirements, policies, implementation tasks, tests, and the needs that originally led to them. Information about where a connection came from and when it applies can also be kept with it.
This is closely related to requirements traceability. The difference for AI-assisted review is that these connections can become part of the information available when an AI system analyses a requirement.
That information also needs to be treated carefully. An old policy may no longer apply. A relationship suggested by AI may be wrong. Reviewers should be able to see where the context came from and whether it was recorded by the project or inferred by AI.
Visualisation supports investigation
A large project may contain hundreds or thousands of requirements. AI analysis can add even more information: possible conflicts, similarities, quality assessments, missing links, and other findings.
Looking at these findings one by one is not always the best way to understand them.
Visualisation can help reviewers see patterns and decide where to look more closely.
ReqSpace is being developed to explore how AI analysis, visual interaction, and project context can support requirements review. The examples here use a synthetic online shopping project.
In the semantic map, each point represents a requirement. Requirements with similar meanings appear closer together. Findings from AI analysis can also be shown as connections between requirements.
The return and account-deletion example is shown in Figure 1. A connection between the two requirements draws attention to a possible problem.
The important point is that the connection is not a final answer. Instead, it gives the reviewer something specific to investigate: if account access disappears, how can the customer make a return?
There may already be another return channel in the system. If there is, that information should be part of the review. The visualisation helps reveal the question. The reviewer still has to work out the answer.
Different questions may also need different views.
For example, a reviewer could ask ReqSpace: “Show clarity versus testability, coloured by requirement type.”
ReqSpace can then generate a view based on the recorded AI assessments. A reviewer can select a point to see the actual requirement and investigate why it received those scores.
The same requirements can be explored from different angles depending on what the reviewer wants to understand. Similarity, wording quality, conflicts, and available test evidence are all useful for different reasons.
A low score or warning should therefore be treated as a place to investigate, not as proof that a requirement is wrong.
A finding should lead to a decision
Pointing out a possible problem is useful only if the reviewer can understand why it was raised.
A good finding should show the concern, the information behind it, and what is still unclear. The reviewer should be able to trace it back to the project information and question the assumptions behind it.
This becomes especially important when tests and implementation information are involved.
A test case tells us what should be checked. A test execution tells us what actually happened when the test was run. Even a passing test only gives evidence for a particular version of the system and under particular conditions.
If the execution information is missing, the AI should say that the evidence is missing. It should not jump to the conclusion that the test was never performed.
Figure 3 shows another example from ReqSpace. A customer-service permissions requirement leaves several questions open. Who assigns the role? What counts as a risky action? How should the different authorisation conditions work together?
The analysis also points to a possible inconsistency involving access to customer cases.
These questions need to be settled before the behaviour and its tests can be specified clearly. Here, the value of the AI explanation is not that it gives the team the answer. It makes the unresolved decisions easier to see.
AI should also make it clear when a suggestion would change the agreed behaviour.
For example, delaying account deletion could solve the return problem from the earlier example. But that is not simply a clarification. It changes what the deletion requirement says the system should do.
That decision belongs to the people responsible for the product. AI can help expose the trade-off, but fluent wording should not make a design or policy choice look settled.
Context has to evolve with the project
Project context is not static.
Requirements are revised. Policies change. New implementation decisions are made. Tests are added or replaced. A decision that solved a conflict six months ago may no longer apply.
Suppose the account-deletion process changes. The team may then need to revisit the return process and the tests connected to it. Keeping a history of these relationships can help show which earlier decisions still apply and which ones need another look.
This could also be useful before a change is made. If a requirement changes, the surrounding context may help teams see which other requirements, decisions, or tests could be affected.
There is still research to do here. We need to understand whether this kind of support actually helps reviewers find relevant problems, understand them faster, and explain their decisions using project evidence.
At GPT-Lab, this work is part of ANSE (AI-Native Software Engineering), a collaboration between Tampere University and the University of Jyväskylä. ANSE looks at how software engineering can evolve as AI becomes a more active part of software development. The project explores new ways for people and AI to work together across software engineering rather than simply adding AI tools to existing practices.
ReqSpace contributes to this work from a requirements engineering perspective. We are exploring how AI, visualisation, and connected project information can help people understand and review requirements. This is one part of the broader work happening in ANSE around how software development may need to change as the role of AI grows.
About the author
