The Pull Request Is Approved. But Does the Change Still Meet the Requirements?
Summarize this article with:
The code is clean. The tests pass. The CI pipeline is green.
Two developers approved the pull request. Everything looks ready to merge.
Yet one question can remain open: does the behavior introduced by this change still meet the software requirements?
This is not a criticism of code review. A good review helps find errors, discuss implementation choices and check the tests associated with the change. It remains essential.
Some teams also check requirements directly during their reviews. Others work with highly structured processes.
The problem appears mainly when the context is scattered. The code is in the repository. The requirements are in another tool. The applicable rules are in documents. The tests provide part of the evidence.
In that situation, a pull request can be technically correct and still introduce behavior that no longer meets a requirement.
A Simple Change, a Simple Divergence
Consider a requirement:
Requirement
After three consecutive failed authentication attempts, the account must be locked for 30 minutes.
The current implementation follows this rule.
The 30-minute duration is defined directly in the code.
During a refactoring, the team decides to move this value into a configuration file. The goal is simple: centralize the authentication settings.
But during the change, the configured value becomes 15 minutes.
The code compiles.
The change is clean.
The tests pass.
Why?
Because the existing tests check that the account is locked after three failed attempts. They do not check how long it remains locked.
The pull request can therefore be approved even though the software no longer meets the requirement.
The requirement says 30 minutes.
The implementation now uses 15 minutes.
The tests check the lockout, but not its duration.
Everything is green. Yet the behavior is wrong.
What Is Sometimes Missing from the Review Context
The reviewer sees the diff. They see the modified tests. They can understand exactly what the developer changed.
But that is not always enough to know what the change was supposed to preserve.
In our example, the value 15 minutes can look perfectly valid when it is read only in the code.
The requirement is what reveals the problem.
The same case can occur with a numerical limit, a delay, an activation condition, a state transition or a security rule.
The problem is therefore not to review more code.
The change must be connected to the expected behavior.
That usually means answering a few questions: which requirements could be affected? What exactly do they impose? Does the new behavior still meet those constraints? And would the tests detect a divergence?
Start from the Change, Then Look at Its Impact
This does not mean rereading the entire specification for every pull request.
The effort must remain proportionate to the change and the risk.
A rename or purely internal refactoring does not require the same analysis as a change to a critical calculation, a state machine or an authentication mechanism.
The change therefore remains the starting point.
From there, we look for what it could affect.
In our example, the diff moves a duration into a configuration file. The immediate question becomes: is this duration constrained by a requirement?
If so, we need to check that the expected value is still respected.
A Six-Step Method
A requirements-based review follows the logic shown in this image.
We start from the change. We then look for the requirements or rules it could affect. Once that context has been found, we examine what it actually imposes on the software.
We can then compare those constraints with the new behavior.
The tests and other evidence come next. The question is not simply whether they pass, but whether they would detect the divergence we are looking for.
Finally, a decision must be made. The code may need to be corrected. A test may be missing. A requirement may be ambiguous or may no longer match the current need.
In our example, the entire analysis fits in three lines:
Requirement: 30 minutes.
Implementation: 15 minutes.
Tests: no verification of the duration.
The problem becomes obvious as soon as this information is brought together.
That is precisely the difficult part.
Seeing 15 minutes in a diff is not enough to know that the value is wrong. We need to find the requirement that imposes 30 minutes, understand that it applies to this change and check that the tests do not cover this duration.
With an example this simple, it takes a few seconds.
The Real Problem Is Repeating This Analysis for Every Change
A real project rarely contains a single requirement and a few tests.
It may contain hundreds or thousands of them. Several standards may apply. Internal policies add other rules. Tests are spread across several components and levels of verification. Several pull requests evolve in parallel.
The method does not become more complicated.
What becomes difficult is bringing together the right context at the right time.
For each change, the team must find what could be affected, locate the right sources, read the relevant passages and compare them with the code.
Then do it again for the next pull request.
Apply This Analysis to Every Pull Request with KomAInu
This is precisely the problem for which we developed the KomAInu Compliance Reviewer.
The principle remains the one we have just described.
The Compliance Reviewer starts from the code change in the pull request and analyzes it with the context that applies to the project: requirements, standards, internal policies and other documents provided to KomAInu.
It then looks for potential divergences between what the change introduces and what those sources impose.
In our example, 15 minutes is not a problem in itself.
The value becomes problematic when compared with the requirement that imposes a 30-minute lockout.
That connection is what matters.
The reviewer does not only need to know that a value changed. They need to see the rule with which the change may conflict.
The Compliance Reviewer aims to provide this context during the review.
When an issue is raised, the finding is linked to its source. The reviewer can see why the change was flagged and find the passage that supports the finding.
This prevents a result from being reduced to an alert that is difficult to interpret.
The decision remains with the team.
The code may indeed need to be corrected. The requirement may need to evolve. Further investigation may be necessary. The finding may also be irrelevant in the actual project context.
KomAInu provides context and surfaces potential divergences. It does not replace the engineer's judgment.
The value becomes most visible at scale.
For the 30 → 15 case, no one needs a tool to compare two numbers.
The difficult work is knowing that the requirement exists, that it is affected by this change and that this specific passage of the document needs to be examined now.
Then repeating that search for the following changes.
With KomAInu, this logic can be integrated directly into pull request reviews. The reviewer does not have to manually reconstruct the full context from several artifacts before starting the analysis.
The method remains the same.
What changes is the ability to apply it more systematically as the project and the number of changes grow.
Conclusion
An approved pull request shows that the change was reviewed.
Green tests show that the behaviors they verify are still satisfied.
But when a change affects software behavior, one final question remains useful before the merge:
What was this change supposed to preserve?