A requirement is good enough when the people who build and test it can do their work without coming back to ask what it means. Everything on this checklist serves that one test.
The short answer: review every requirement for seven qualities before it is approved. It should be clear, complete, testable, consistent, feasible, bounded and owned. Each "no" becomes a fix, an owned open question, or a recorded decision to accept the risk.
Requirement quality checklist (PDF): one page, one copy per requirement, with space for the review decision. The full checklist is also below.
The requirement quality checklist
Clear
- It has one reading only. No vague words such as fast, easy, appropriate or user friendly, and every number has a unit.
- Terms mean the same thing everywhere they appear, and match the policy or glossary wording.
Complete
- Actor, trigger and outcome are stated: who does what, when, and what changes.
- Business rules include their limits and exceptions, and the owner of each rule is known.
- Failure behaviour is stated: invalid input, repeated attempts, a dependency that fails.
- Permissions are stated: who may do this, and who must not.
Testable
- Each acceptance criterion has an observable pass or fail result, without a clarifying question.
- Boundaries are explicit, so the values either side of each limit can be tested.
Consistent
- Conflicts with other requirements, policies or how the system behaves today are resolved. Where the requirement intentionally changes current behaviour, the change is stated explicitly.
Feasible
- Delivery is achievable within the known technical, time and resource constraints. Assumptions are recorded, and concerns from the people who will build it have been raised and answered.
Bounded
- In scope and out of scope are both written down, and dependencies are named.
Owned
- The requirement has an owner, and decisions are recorded with who made them and why.
- Every open question has an owner and a due date.
Before-and-after examples
Each example uses the refund requirement from the ReqLens Academy. The "after" versions are illustrations of the fix, not the only correct wording.
Ambiguous. Before: "Refunds should be processed quickly." Why it fails: quickly has no number, so it cannot be tested or agreed. After: "The customer sees a refund confirmation within 2 seconds of submitting, and the refund is sent to the payment provider within one business day." The thresholds here are illustrative; use the ones your team agrees.
Incomplete. Before: "Customers can request a refund within 30 days." Why it fails: 30 days from what, order or delivery? What happens on day 31? After: "Customers can request a refund up to 30 days after delivery. A request on day 31 or later is refused, and the reason is shown."
Untestable. Before: "The refund form should be user friendly." Why it fails: nobody can observe pass or fail. After: name the behaviour you mean, for example "Required fields are marked, and the form keeps the customer's input when validation fails."
Missing failure behaviour. Before: "The refund is credited to the original card." Why it fails: it says nothing about the gateway timing out. After: add "If the payment gateway does not respond, the request stays pending, the customer is told, and the refund is retried."
Missing permission. Before: "A customer can request a refund for an order." Why it fails: any customer, or the one who placed it? After: "Only the customer who placed the order can request a refund for it."
Inconsistent. Before: one requirement says refunds go to the original card; another says refunds can be issued as store credit. Why it fails: nothing says which applies when. After: state the rule that decides, or record that store credit is out of scope.
For the acceptance criteria themselves, see acceptance criteria examples and a template.
How to identify gaps in requirements
Most gaps are found by asking the same few questions of every rule:
- Walk each boundary. For every limit, ask what happens just inside it, exactly on it, and just outside it.
- Ask "what if it fails". For every system the requirement touches, ask what the user sees and what the system does when that system is slow, down or returns an error.
- Ask "who must not". For every action, ask who is not allowed to do it, and what they see if they try.
- Ask "how would we know". For every outcome, ask what would be logged, audited or reported, and who needs to see it.
- Read it as the tester. If you cannot write the first test case without asking a question, that question is a gap.
Grouping gaps by theme, such as failure behaviour, business rules, permissions, data or observability, makes it easier to see which kind of thinking a requirement is missing.
Make an explicit review decision
A review that ends without a decision is a discussion. The checklist above suggests three outcomes for your own review process:
- Ready: every check is yes or not applicable.
- Ready with conditions: the remaining items are written down, each with an owner and a due date, and a named reviewer explicitly accepts the conditions and the remaining risk.
- Not ready: a rule, failure behaviour or acceptance criterion is still unknown or contested, or delivery is not feasible as written.
Record who decided, the conditions and their owners, and the risk that was accepted, wherever your team keeps requirement decisions.
How ReqLens supports the review
The three outcomes above are a suggested process, not ReqLens statuses. In ReqLens the review works like this:
- A readiness verdict of READY or NOT READY. It is calculated, not generated: it is derived from blocking issues, open coverage gaps and criticality signals, and recalculated each time a gap is resolved. A criticality mismatch is advisory and never blocks on its own.
- Coverage gaps grouped by theme, such as failure behaviour, business rules and observability, each with a severity. Each one is resolved by a decision: add a criterion, convert it to an action item with an owner, or mark it not applicable.
- Review flags on weak criteria, stating the issue, a suggested fix and a severity, for a person to accept, edit or reject.
- Lifecycle controls for the decision: Approve, Block with a reason, Hold and Archive. Approving while blocking issues are still open needs an explicit override, which is recorded in the audit trail.
ReqLens has no "ready with conditions" status. Converting remaining gaps to assigned action items supports that decision, but it does not make it: a reviewer still has to accept the conditions and the remaining risk explicitly, and record that acceptance. See how Requirement Studio elaborates and checks a requirement, or how ReqLens manages requirements from first draft to release.
Key takeaways
- Review every requirement for seven qualities: clear, complete, testable, consistent, feasible, bounded and owned.
- Rewrite vague words as numbers, and state failure behaviour and permissions explicitly.
- Find gaps by walking boundaries, asking what fails, who must not, and how you would know.
- End every review with an explicit decision. Give every condition an owner, and have a named reviewer accept any remaining risk.