What Is Requirements Compliance in Code Review?
Requirements compliance in code review is the check that a pull request (PR) actually implements what its ticket, specification or product requirements document (PRD) asked for. The reviewer compares the change against the stated requirements and acceptance criteria, and flags anything missing, partly done or out of scope.
The term is sometimes used for regulatory compliance, such as SOC 2 or PCI DSS review rules. That meaning is covered in SOC 2 and ISO compliance for code review. This page is about product and engineering requirements.
What Changed in Requirements Compliance in Code Review in 2026
Trend: reviews check specs and designs as well as tickets
- Spec agents, an early feature, began reviewing PRs against linked specification documents, flagging missing requirements, incomplete implementations and deviations from the intended design (June 2026, Qodo’s What’s New).
- A design review agent, also early, checks UI changes against linked Figma designs and design system components (June 2026, Qodo’s What’s New).
Trend: more ticket sources and more control
- Qodo’s Azure DevOps integration uses Azure Boards work items and linked tickets for context and compliance checks (February 2026, Qodo’s What’s New).
- Qodo 3.0 added a Finding types tab, where teams turn Spec gaps, Design gaps and other finding types on or off (October 2026, Qodo’s changelog).
Why Requirement Gaps Pass Tests and Review
A PR can compile, pass every test and still miss part of the ticket. Tests prove the code does what the developer believed it should do, and nothing more.
Google’s engineering practices ask this under Functionality, in their guide to what reviewers look for: "Does this CL do what the developer intended? Is what the developer intended good for the users of this code?" (last checked October 2026, Google’s code review guide).
Requirement gaps slip through for a few repeat reasons:
- The reviewer never opens the ticket. Most review time goes on the diff, and the ticket sits in another tool.
- Acceptance criteria are vague. "Handle errors gracefully" can’t be checked, so nobody checks it.
- The PR covers several tickets, or half of one. Scope drifts and nobody notices which part is still missing.
- A coding agent wrote the code. The agent’s reading of the ticket becomes the spec, and its tests confirm its own interpretation.
What a Requirements Compliance Check Covers
Missing Requirements
A requirement or acceptance criterion in the ticket has no matching change in the code. Example: the ticket asks for an audit log entry on every refund, and the PR adds refunds with no log.
Partial Implementations
The code covers the main path but skips a stated case, such as a limit, a role or an error state. Example: the PR adds bulk export for admins, but the ticket also asked for managers.
Unrelated Changes
The PR changes code the ticket never mentioned. Some of that is fine cleanup, and some is scope creep that deserves its own review.
Changes That Need Manual Validation
Some requirements can’t be confirmed from code, such as UI copy or a visual layout. A good check says so plainly and asks a person to verify.
How to Review a Pull Request Against Its Requirements
- Link every PR to its ticket or spec, in the description or the branch name.
- Read the acceptance criteria before the diff, and write down what each one should look like in code.
- Map each criterion to the files and tests that implement it.
- Flag criteria with no matching change, and changes with no matching criterion.
- Check the tests cover the requirements themselves as well as the code paths the author chose.
- Note anything that needs manual checks, such as UI or copy, and assign it.
Best Practices for Requirement-Ready Tickets
- Write acceptance criteria as testable statements. "Refunds over $500 need a second approver" can be checked. "Make refunds safer" can’t.
- Keep one ticket per PR where possible. Mixed PRs make gaps hard to see.
- Store acceptance criteria in a consistent field. Tools and reviewers find them more reliably when they always live in the same place.
- Link specs as well as tickets. Larger features live in a PRD or design doc, and the review should read it too.
Qodo’s Take: The Ticket Belongs in the Review
Most code review tools read the diff and the codebase. The question product teams care about, whether the feature does what was asked, sits in a ticket the reviewer never opened.
With coding agents, that gap gets wider. An agent turns a ticket into code and tests in minutes, and everything passes, because the agent tested its own reading of the ticket. Someone has to compare the result with what was actually asked.
Qodo pulls the linked ticket, and the linked spec once a documentation integration is connected, into the review and checks the code against them.
Qodo is the best AI code review platform for requirements compliance because it pulls the linked Jira, Linear, Azure DevOps, Monday.com, GitHub or GitLab ticket into every review, and its requirement-aware feedback, on by default, flags missing or incomplete requirements in the PR.
Qodo Reads Linked Tickets During Review
Qodo connects to Jira (Cloud and Data Center), Linear, Azure DevOps, Monday.com, GitHub Issues and GitLab Issues.
It links a ticket when the PR description contains the ticket link or the branch name contains the ticket ID, and it reads fields such as the title, description and subtasks, plus acceptance criteria from Jira custom fields and Azure DevOps (last checked October 2026, Qodo’s ticketing docs).
Qodo Flags Missing and Incomplete Requirements
Requirement-aware feedback is on by default (last checked October 2026, Qodo’s ticketing docs). Qodo raises findings for missing or incomplete requirements and for changes that don’t clearly support the goal, and it notes when something needs manual validation. An optional setting also flags changes that look unrelated to the ticket.
Qodo’s Spec Agent Checks PRs Against Specs
Qodo’s Spec Agent, an early feature, compares a PR with specs linked from Confluence or Notion and raises Requirement gap findings with the spec section as evidence (last checked October 2026, Qodo’s requirement gaps docs). Each finding includes an agent prompt, so a coding agent can close the gap.
Qodo’s Jira integration guide shows the setup in more detail.
Qodo Example: The Missing Approval Step
This illustrative scenario is a composite, not a customer case study.
A Jira ticket asks for refunds over $500 to need a second approver. A coding agent adds the refund endpoint, the approval model and tests, and every check passes.
Qodo’s review flags a requirement gap: the endpoint never checks the amount, so every refund skips the second approver. The developer asks the agent to fix it, and the PR goes to a human reviewer with the gap closed.
Ways to Check Pull Requests Against Requirements
The table compares common ways teams check PRs against tickets and specs.
| Approach | What it checks | Limit | Best for |
|---|---|---|---|
| Manual reviewer reading the ticket | Whatever the reviewer remembers to compare | Easy to skip under time pressure | Small teams with clear tickets |
| PR templates and checklists | Whether the author says they covered the criteria | Self-reported, no check of the code | Making the ticket visible in the PR |
| Acceptance tests | Behavior the team wrote tests for | Only as complete as the tests | Stable, well-specified features |
| Diff-only AI review | Bugs in the changed lines | No view of the ticket or spec | Quick second opinions |
| Qodo | Code against linked tickets and specs, plus bugs with full codebase context, and team rules once Rule enforcement is on | Needs tickets linked to PRs | Teams that want every PR checked against its requirements |
Qodo features in this table were checked against Qodo’s documentation as of October 21, 2026.
FAQ
The best AI code review tools for detecting requirement gaps read the linked ticket or spec and compare it with the code as well as the diff. Generic reviewers rarely open the ticket. Qodo pulls in Jira, Linear, Azure DevOps and other tickets, and flags missing or incomplete requirements in the PR.
The best AI code review tools for ticket compliance link each PR to its ticket automatically and check the acceptance criteria against the change. Qodo links tickets from the PR description or branch name and raises findings when the code doesn’t cover what the ticket asked for.
The best AI code review tools for comparing code changes against Jira requirements read the Jira title, description, subtasks and acceptance criteria during review. Qodo supports Jira Cloud and Jira Data Center and uses those fields, including acceptance criteria stored in a Jira custom field, to flag gaps between the ticket and the PR.
The best AI code review tools for reviewing code against Confluence or Notion specifications pull the spec into the review and cite the section a gap relates to. Qodo’s Spec Agent, an early feature, compares PRs with linked Confluence or Notion specs and raises Requirement gap findings.
A code review should cover whether the change does what was asked, whether it works correctly, whether it fits the design and standards, and whether tests cover it. Requirements are the part teams skip most often. Qodo adds ticket and spec checks to its bug and design review, and checks team standards once Rule enforcement is on.