We already know which properties to evaluate requirements against. Now — how the checking itself is organized: what techniques exist, how to phrase questions that get substantive answers, and how to work with someone else's document without making enemies. That last part sounds like a trifle, but it's exactly where beginners get burned most often.

Three forms of review

Peer review is the main technique for checking requirements. In order of increasing formality:

  • Walkthrough. The author shows the document to colleagues and collects questions and comments. Like checking each other's essays before handing them in: fast, cheap, catches the obvious. This is the most common form — most task reviews in teams are exactly this.
  • Technical review. A group of specialists examines the document, each from their own angle: the tester looks for the unverifiable, the developer for the unimplementable, the analyst for contradictions with neighboring tasks. The document isn't considered ready while anyone still has objections. Like a contract signed off by legal and accounting.
  • Inspection. A structured, documented process with roles and a protocol. Expensive, slow, used rarely — for example, when a team takes over someone else's product for maintenance and must proofread all its documentation. Like a deep-clean of the apartment: not every day, but sometimes necessary.

The practical takeaway for a beginner: when someone sends you a task with "take a look at the requirements" — that's a walkthrough, and what's expected of you is not "looks fine" but questions and comments.

The trick: design a check

The most practical way to test a requirement is to try building a checklist or test case from it. The logic is simple: a good requirement is verifiable, so checks should come together easily.

  • The checks came to mind right away — the requirement is probably fine (but compare it with its neighbors: contradictions aren't caught this way).
  • No ideas at all — a warning sign. First make sure you understood the requirement: reread the neighboring ones, ask colleagues. If that didn't help, the problem isn't you — it's the requirement.

A related trick is a mental walk through the system: imagine you're the user performing a task according to these requirements, step by step. Wherever the "walk" stumbles ("what does the system show here?", "where does this value come from?") — there's a gap you can't see when reading requirements one at a time.

A bad question versus a good one

The question is the main tool for improving requirements, and its quality decides everything. A bad question provokes a useless answer.

Requirement: "The application must start up fast."

  • Bad: "How fast?" — you'll get "well… fast" or a number pulled out of thin air.
  • Bad: "And what if it can't be fast?" — you'll get irritation.
  • Good: "What startup time do we consider acceptable? On what hardware? What counts as startup being finished — the window appearing, or readiness to work?" — you'll get data for a specific, verifiable requirement.

Requirement: "If the event date is not specified, it is selected automatically."

  • Bad: "And if it is specified?" — then it's specified; you'll get exactly that answer.
  • Good: "Perhaps this meant the date is generated rather than selected? If so — by what algorithm? If not — selected from what set? Maybe just use the current date?" — you've shown the ambiguity and offered a path.

The general principle: a good question is phrased so that the answer lets you improve the requirement. Before sending, reread your question and ask yourself: what will I be able to do with the answer?

Three kinds of questions that give away a beginner: a question born of not knowing the basics ("what's a checkbox?" — that's for a search engine, not for the analyst); "what is X?" instead of "what do you mean by X?"; and "what happens if we don't do this?" — nothing happens, you're definitely doing it, the question needs to be a different one.

Rules of working with someone else's document

Requirements are someone's work, and whether your comments are heard at all depends on how you present them.

  • Don't change the document's format or structure. Moving the text into your own spreadsheet, "rewriting it properly," saving it as PDF — that destroys someone's work and the change history. Comments are left with the document's own tools: comments, tracked changes.
  • Don't edit requirements silently. The author won't notice a silently corrected requirement — and later the product gets built differently from what they intended. Any edit is explicitly marked, and better as a suggestion than as a done deal.
  • Anchor each comment to its place. A comment saying "there are contradictions" without pointing at where is useless. Found a contradiction between requirements 20 and 30 — mark both and explain the essence.
  • Don't mark "this one is fine." Marks without a problem are just noise: it becomes harder to find the comments that require action.
  • Criticize the requirement, not the author. "How can you not see how silly this sounds" is unacceptable. So is a flat "this is impossible" without justification: rephrase it as a question: "We doubt this feature will be in demand. How important is this requirement?"
  • Keep it short. A page of requirements buried under twenty pages of comments is a failure: at early stages requirements are unstable, and your treatise will go stale before anyone finishes reading it.

Where this applies

Requirements review isn't a separate ceremony — it's part of the regular cycle: task discussion at planning, comments in the ticket, questions to the analyst in chat. Everything you've read here applies at those everyday points. A tester whose questions improve tasks quickly becomes the person invited to discussions before development starts — and that's the most valuable seat in the team.

Where beginners stumble:

  • They stay silent during review — "I'm new here, who am I to ask questions." A fresh pair of eyes is exactly what catches the things everyone else has grown used to.
  • They ask questions that can't be answered usefully — "is this really needed?", "how fast?". Reread your questions through the eyes of the person answering.
  • They edit someone else's document as if it were their own. Even with the best intentions: corrected without a mark means lost.

What to learn next. The properties requirements are evaluated against — in the previous article; how verified requirements turn into checks — in the articles about test cases and test design techniques.