Requirements Analysis & Specification

Writing Good Requirements

18 min Lesson 3 of 10

Writing Good Requirements

Collecting requirements is only half the job. The other half — often harder — is turning raw stakeholder input into precise, testable statements that a developer can implement and a tester can verify. A requirement that says "the system should be fast" or "users need a friendly interface" is not a requirement at all: it is a wish. This lesson teaches you how to write requirements that hold up under scrutiny and drive real design decisions.

What Makes a Requirement "Good"?

A well-written requirement shares six qualities, sometimes summarised with the acronym SMART-U:

Specific — it describes one precise behaviour or constraint, not a vague category.
Measurable — there is an objective way to confirm it is satisfied.
Achievable — it is technically and economically feasible within the project scope.
Relevant — it traces back to a real stakeholder need or business goal.
Testable — a test case can be written for it with a clear pass/fail outcome.
Unambiguous — every reader interprets it the same way.

The testability rule: If you cannot write a test case for a requirement — a scenario with inputs, expected outputs, and a clear pass/fail — rewrite the requirement until you can. Testability is the single most practical quality gate.

The Language of Shall and Should

Professional requirements documents use modal verbs deliberately. The IEEE 830 standard and most enterprise style guides distinguish three levels:

shall — a mandatory requirement. The system shall do this; non-compliance is a defect.
should — a recommended but optional behaviour. The system should do this when feasible.
may — a permitted option. The system may offer this capability.

Using these words consistently lets every reader — developer, tester, auditor — immediately understand the obligation level. Avoid will in requirement statements (it reads as a prediction, not an obligation), and never use must as a synonym for shall in formal documents (it creates legal ambiguity in contracts).

Quick check: Search your draft SRS for the words "fast," "easy," "user-friendly," "robust," and "flexible." Every occurrence is a candidate for a vague requirement that needs to be rewritten with a measurable criterion.

Anatomy of a Well-Formed Requirement

A single requirement statement typically follows this pattern:

[Subject] shall [action] [object] [qualifier/constraint].

Consider a clinic booking system. Compare these two versions of the same need:

Vague: "The system should quickly confirm appointments."
Good: "The system shall send an appointment confirmation notification to the patient within 30 seconds of the booking being saved."

The good version names the subject (the system), the action (send a confirmation notification), the object (to the patient), and the measurable qualifier (within 30 seconds of the booking being saved). A QA engineer can now write an automated test for it.

Each component of a requirement statement contributes to making it precise and testable.

Common Patterns of Badly Written Requirements

Recognising anti-patterns in requirements is as important as knowing good ones. Here are the most frequent offenders, with real examples from an online store project:

Vague adjectives: "The checkout page shall be intuitive." — Intuitive according to whom? Replace with a measurable usability criterion: "A first-time user shall be able to complete the checkout process in under 4 steps without consulting help documentation."
Compound requirements (the AND trap): "The system shall validate the shipping address and calculate the delivery estimate and display the total cost." — This is three separate requirements masquerading as one. When one is satisfied and another is not, tracking becomes impossible. Split them.
Passive voice hiding the actor: "Invoices shall be generated automatically." — By what? Triggered by what event? Write: "The system shall automatically generate a PDF invoice within 5 seconds after an order status changes to Confirmed."
Unmeasurable performance: "The system shall handle high traffic." — Quantify it: "The system shall support a minimum of 500 concurrent users without response times exceeding 2 seconds on any page."
Implicit assumptions: "The system shall display delivery dates." — In which timezone? For which carrier? In what format? Every implicit assumption is a future defect.

The AND trap in compound requirements: Every time you write "and" or "or" inside a single requirement statement, ask whether you have combined two separate requirements. Compound requirements make testing ambiguous — a test that partially passes cannot be clearly marked pass or fail.

Applying the Rules: A Logistics Scenario

A logistics firm is building a shipment tracking portal. The raw stakeholder note reads:

Drivers need to be able to update delivery status from their phones. It should be quick and work even in areas with poor signal.

Decomposing this into well-formed requirements:

"The mobile application shall allow an authenticated driver to update the delivery status of an assigned shipment within 3 taps from the home screen." (usability + interaction)
"The mobile application shall cache pending status updates locally and automatically synchronise them to the server within 60 seconds of the device regaining network connectivity." (offline behaviour + sync)
"The system shall retain a timestamp and the driver identifier for every status update." (data integrity + auditability)

Three testable, independent requirements replace one vague note. Each can be assigned to a different developer, estimated separately, and tested with a specific scenario.

One vague stakeholder note decomposed into three distinct, testable requirements covering usability, reliability, and data integrity.

Quantifying Non-Functional Requirements

Non-functional requirements (NFRs) are the most frequent victims of vague writing, because their subject matter — performance, security, availability — feels inherently abstract. The remedy is always the same: name the metric and set the threshold.

Performance: "The product search page shall return results in under 1.5 seconds at the 95th percentile under a load of 300 concurrent users."
Availability: "The booking service shall maintain 99.5% uptime, measured monthly, excluding scheduled maintenance windows announced at least 24 hours in advance."
Security: "All patient data transmitted between the client and the server shall be encrypted using TLS 1.2 or higher."
Usability: "A new receptionist with no prior system training shall be able to book an appointment within 5 minutes, measured during onboarding testing."

Performance baseline source: Quantify NFRs based on benchmarks where possible. If the existing system processes 200 transactions per minute, a reasonable target for the new one is 300–400 TPM — not "faster." Stakeholders who struggle to name a number often agree quickly when you ask: "What is the minimum acceptable value that would still make this worth building?"

Checklist Before Signing Off a Requirement

Before a requirement statement enters your baseline, run it through this checklist:

Does it contain exactly one shall (or should) statement?
Is the actor or system component unambiguous?
Is there a measurable, objective criterion for satisfaction?
Could two different readers interpret it differently? If yes, rewrite.
Can a test case be written for it right now?
Does it describe what the system does, not how it should do it? (Implementation belongs in design, not requirements.)
Is it free of compound statements? (No hidden AND / OR splits.)

Good requirements are not written in a single pass. Even experienced analysts revise each statement two or three times before it passes every item on this checklist. The investment pays back many times over when the development team never needs to ask "what did you mean by this?" and the test team can automate verification from day one.