Stop 03 · Requirements Analysis & DocumentationTopics · 8/10

Writing Clear, Testable Requirements

In short

'The system should be fast' sounds fine until the tester asks 'How fast?' and the developer says 'Fast enough?' Clear requirements end those arguments before they start.

A requirement should be specific, unambiguous, and verifiable — 'the system should be fast' is untestable; 'the system should load search results within 2 seconds' is testable.

The purple blob sits at an exam desk with a pencil, looking thoughtful over a question paper.

Think of it like this

Vague vs exact exam questions

'Write about photosynthesis' could mean anything, and two teachers would mark it differently. 'Name the three inputs of photosynthesis (3 marks)' has one right answer. A testable requirement is the second kind of question.

Watch it happen

Turning a vague wish into a testable requirement

Vague

Who

What

How much

Testable

1/5Start: 'Search should be fast.' Nobody can test this.

The big ideas

What you need to know

One requirement, one idea

Avoid 'and' joining two needs. Split them, so each can pass or fail on its own.

Ban fuzzy words

Words like fast, easy, user-friendly and 'as appropriate' hide decisions. Replace them with numbers or examples.

Measurable and verifiable

If you can't describe a test that proves it, it isn't a requirement yet.

Given, When, Then

Writing acceptance criteria as Given, When, Then forces you to state the setup, the action and the expected result.

See it in code

Walk through the code

gherkin

1Feature: Search speed2  Scenario: Results load quickly at normal traffic3    Given 500 users are using the app at the same time4    When a customer searches for "running shoes"5    Then the first 20 results appear within 2 seconds6    And each result shows a price and a photo

1/4Name the feature and the specific situation being checked.

The same requirement as a Gherkin scenario. Testers can turn this straight into a test, by hand or automated.

Save yourself the pain

Common mistakes

Oops

'The system should handle errors properly.'

Do this instead

'If payment fails, show the reason and keep the cart unchanged for 30 minutes.'

Oops

Writing the solution instead of the need, like 'Add a dropdown for cities'.

Do this instead

Write the need, like 'User can select their city from the list of cities we serve', and let design choose the control.

Your mission

Fix five bad requirements

~20 min

Quick check

Which requirement is testable?

Go deeper

1Rewrite 5 vague requirements into specific, testable ones.
2Learn the SMART-adjacent checklist many BAs use: specific, measurable, achievable, relevant, testable.
3Practice this on a real ambiguous requirement you've encountered or can imagine.