← back to the section

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.

one requirement, three questions — and what each one finds “The application must start up fast” 1 design a check 2 walk the scenario 3 ask the question 1 design a checkno checklist forms:what goes into theexpected result? 2 walk the scenariothe walk stumbles:the window appeared— has it started? 3 ask the question“how fast?” —“well… fast”:the answer gave nothing good question: what startup time is acceptable?on what hardware? what counts as startup beingfinished — the window, or readiness to work? “Startup ≤ 3 s to input readiness, 8 GB laptop”now the check writes itself: launch, time it, compare with 3 s

A requirement with the judgement word “fast” is run through three questions. The first tries to build a check from it and hits an empty expected result; the second walks the scenario and finds that the end of startup is undefined; the third shows that a vague question returns an equally vague answer. The three findings add up to one question whose answer makes the requirement verifiable.

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

In short

  • A walkthrough is the everyday form of review: it expects questions and comments from you, not "looks fine".
  • A requirement is tested by trying to build a check from it: if no checklist comes together, the problem is the requirement, not the reader.
  • A mental walk through the scenario catches the gaps between requirements — where it is unclear what the system shows next.
  • A good question is measured by its answer: if the answer does not let you improve the requirement, rewrite the question.
  • Anchor a comment to its place and leave it with the document's own tools; a silently corrected requirement is a lost one.
  • "This one is fine" marks and twenty pages of comments get in the way equally: the comments that matter drown.