← back to the section

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 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").

on the stand: the report opened in 4.2 s and showed 12 rows as written The report loads fast and shows enough rows “fast” — how fast? “enough” — how many? passed tester A failed tester B one measurement, two verdicts: nothing here can be checked fixed: two requirements instead of one R-14 the report opens within 3 s with 1000 concurrent users R-15 at least 20 rows in the list on the first page of the report 4.2 s > 3 s — failed 12 < 20 — failed the same verdict for anyone who checks — nothing left to argue about

On top, a requirement written in evaluative words: on one and the same measurement two people record different marks — so the requirement has no verifiability. Below, the same thought split into two numbered requirements, each with a number and a condition: atomicity gives one verdict per requirement, unambiguity makes that verdict the same for anyone who checks.

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 check 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 catches 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 is a reason for a question.

Where this applies

Every sprint you read tasks and acceptance criteria — those are requirements at the user and product levels. Spotting ambiguity or a completeness gap in them works 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 to ask the author a question.

In short

  • Three levels: a business requirement answers "why," a user requirement names the task a person accomplishes, a product requirement says exactly how the system behaves.
  • Aiming a complaint at the wrong level causes half the arguments: a date format has no place in a business requirement, while "must work fast" at the product level is a defect.
  • Nine properties, and a violation of any of them hits verifiability first: you cannot build a check with an unambiguous outcome.
  • Evaluative words — "fast," "convenient," "if necessary" — are the main marker of ambiguity; the cure is a number plus a condition.
  • A glued requirement is fixed by splitting: two numbered requirements instead of one, each with its own verdict.