In the article about requirements-based testing we established the main point: requirements are the starting point of all your work, and they need checking too. Now let's add two tools that make that checking systematic: an understanding of requirement levels (so you know what to expect from each document) and a list of properties of a good requirement (so you check against criteria, not against "like it / don't like it").
Three levels of requirements
Requirements are written for different readers and with different levels of detail. Three levels are usually distinguished.
Business requirements answer the question "why does this product exist at all." They're written in business language, without technical detail: "we need to halve the time an operator spends processing a request," "we need a tool that shows the best currency rate in real time." No buttons or fields here — just the goal and the benefit.
User requirements describe the tasks a person accomplishes with the system: "an administrator can view the list of users currently working in the system," "on first login the user sees the license agreement." Typical forms are user stories and scenarios: the system's behavior is already visible, implementation details are not yet.
Product requirements are the most detailed level: exactly how the system behaves. This is where you find:
- functional requirements — what the system does: "the email address entered at registration is validated for correct format";
- non-functional requirements — what the system should be like: speed, reliability, usability. "With 1000 concurrent users, response time is no more than 2 seconds";
- business rules — domain constraints: "an article can be published only after approval by the editor";
- constraints — implementation boundaries: "the client side must work without installing additional software."
Why a tester needs this: your analysis must match the level. Demanding technical detail from a business requirement is a mistake: it's supposed to be general. And the reverse: a product-level requirement saying "the system must be fast" is a defect — at this level, specifics are mandatory. Half of all pointless arguments about requirements are complaints aimed at the wrong level.
Properties of a good requirement
When you "test" a requirement, you're checking it against a specific set of properties. Here are the main ones, with typical problems.
Completeness. The requirement contains all the necessary information; nothing is omitted on the grounds of "everyone knows that anyway." Problem: "passwords are stored encrypted" — with which algorithm? "Export to PDF, PNG, etc." — what hides behind "etc."?
Atomicity. One requirement describes one situation and can't be split into parts without losing meaning. Problem: "the Restart button is not shown while the service is stopped, and the Log window holds at least 20 entries" — two unrelated requirements glued into one; changing one forces you to touch both.
Consistency. The requirement doesn't contradict itself or its neighbors. Problem: one place says "the Close button is always red," another — "always blue." Or within a single sentence: "after a successful login by a user who has no right to log in…" — so did they log in or not?
Unambiguity. The requirement is understood by everyone the same way. The main enemies are evaluative words: fast, convenient, effective, at a minimum, if necessary, usually, large, flexible, simple. Every such word is a signal: the requirement can't be verified, and it can't be implemented "correctly" either. When you spot one — ask a question.
Verifiability. You can build an objective check from the requirement — a test case that shows unambiguously whether it's fulfilled. This is the summary property: if any of the previous ones is violated, verifiability is the first to suffer. We covered it in the requirements article — "the page loads fast" versus "no longer than 3 seconds."
Feasibility. The requirement is technically achievable and fits the project's time and budget. The classic problem is "gold plating": expensive embellishments nobody will actually use.
Currency and necessity. The requirement is still needed by someone. Requirements added "just in case," or outdated ones that were never removed, are clutter that confuses both development and testing.
Traceability. You can see where the requirement came from and what's connected to it: which cases verify it, which code implements it. In practice this means numbered requirements and a traceability matrix: without numbers you can't even reference a requirement.
Prioritization. Requirements have priorities assigned. When everything is "equally important," the team spends effort on the secondary while the essential arrives last.
How to use this
The property list is your checklist when reading any requirements document. You don't need to formally run every requirement through all nine points — with time your eye will start catching glued-together requirements, evaluative words, and contradictions on its own. Until that experience builds up, keep the list in front of you.
A practical trick: try to design a check for the requirement. If a test case comes together easily, then verifiability, completeness, and unambiguity are probably fine. If you have no ideas at all — you've found a problem, and that's a reason to ask the author a question.
Where this applies
Every sprint you read tasks and acceptance criteria — those are requirements at the user and product levels. The ability to quickly spot ambiguity or a completeness gap in them is the skill that makes you useful before any code exists: a question asked during task discussion is cheaper than a bug found during regression.
Where beginners stumble:
- They aim complaints at the wrong level. "The business requirement doesn't specify the date format" — nor should it; the format lives at the product level.
- They let evaluative words slide. "Fast," "convenient," "if necessary" read smoothly — which is exactly why they slip through. Train your eye on them.
- They notice a problem and stay silent. A property violation you found is not a checkbox — it's a reason for a question. How to ask it properly is the next article.
What to learn next. How requirements review works and how to phrase questions that get substantive answers — in the article about requirements review.