Writing Testable Requirements

The Testability Test

Here is the acid test for any requirement: can you write a test procedure that a competent tester can execute, and whose outcome is an objective pass or fail with no room for interpretation?

If the answer is no, you do not have a requirement. You have an aspiration.

This test must be applied at the time of writing, not deferred to the test planning phase. The most common failure mode in requirements engineering is writing requirements that sound reasonable in a design review but are impossible to verify in a test lab. By the time the test team discovers the problem, the design is built, the schedule has no margin, and the team is forced into a painful negotiation about what "compliance" really means.

Common Failures

Ambiguous terms — "adequate," "sufficient," "user-friendly," "minimal," "reasonable," "timely," "appropriate," "high-quality." Each of these words invites a different interpretation from every person who reads the requirement. The designer reads "timely" as "within the design's capability." The customer reads it as "within my operational tolerance." The tester has no idea what to measure.

Missing thresholds — "The system shall have high availability." Compared to what? A consumer website at 99% uptime? A medical device at 99.99%? A nuclear safety system at 99.9999%? Without a number, the requirement constrains nothing. It is a statement of general virtue, not an engineering obligation.

Compound requirements — "The system shall process sensor data in real time and store it in a database and generate alerts when thresholds are exceeded." This is three requirements fused into one. If the system processes in real time but the database write fails, is this requirement met? Failed? Partially met? Compound requirements create ambiguous verification status and make traceability meaningless.

Missing conditions — "The system shall detect targets at a range of 10 km." In clear weather? In rain? Against what target cross-section? At what probability of detection? A requirement without conditions is a requirement that is always true or always false depending on which conditions you test under.

Passive voice hiding the actor — "The data shall be encrypted." By whom? The sending system? The receiving system? The network infrastructure? When the actor is hidden, allocation is impossible, and two teams can each assume the other is responsible.

The INCOSE Quality Checklist

INCOSE defines eight attributes that every individual requirement must satisfy. This is not aspirational guidance — it is a quality gate. Requirements that fail any attribute should be reworked before they enter the baseline.

Singular — One requirement per statement. No "and" connecting separate obligations. Each requirement gets its own ID, its own verification, its own allocation.

Complete — The requirement contains all information needed to understand and verify it, without needing to refer to other documents for essential details. Referencing a standard for test methodology is acceptable; requiring the reader to infer the performance threshold from another document is not.

Consistent — The requirement does not contradict any other requirement in the set. Consistency is a set-level property — you cannot evaluate it by reading one requirement in isolation.

Unambiguous — Only one interpretation is reasonable. This is harder to achieve than it sounds, because the writer always thinks their requirement is clear. Peer review by someone from a different discipline is the most effective countermeasure.

Verifiable — At least one of the IADT methods (Inspection, Analysis, Demonstration, Test) can confirm that the requirement is met, and the expected result is defined well enough that two independent testers would reach the same conclusion.

Feasible — Current technology, schedule, and budget can achieve it. A requirement that demands performance beyond the state of the art is not a requirement — it is a research objective. These belong in a different management process.

Traceable — The requirement can be traced upward to its parent need and downward to the design elements and test cases that satisfy and verify it.

Necessary — Removing the requirement would cause the system to fail a stakeholder need or violate a constraint. If a requirement is not necessary, it adds cost without adding value — and every unnecessary requirement competes for verification budget with the requirements that matter.

Use the slider to move through three stages of the same underlying intent. Notice that the progression is not just about adding numbers — it is about specifying what is observed, under what conditions, with what method, and what constitutes pass or fail.

Techniques for Improving Requirements

Replace every adjective with a number. "High throughput" becomes "10,000 transactions per second minimum." "Low latency" becomes "round-trip latency of no more than 20 ms at the 99th percentile." If you cannot replace the adjective with a number, you do not understand the requirement well enough to write it.

Separate compound requirements ruthlessly. If a requirement contains "and" or "or" connecting separate obligations, split it. Each obligation gets its own ID, its own allocation, its own verification. The cost of more requirements in the database is trivial compared to the cost of ambiguous compliance status.

Define verification method at write time. Before baselining a requirement, write a one-sentence verification approach. If you cannot, the requirement is not yet ready. This exercise frequently reveals that the requirement is untestable, which is exactly the information you need before the design phase consumes budget.

Name the actor. Use active voice with an explicit subject. Not "data shall be transmitted" but "the telemetry subsystem shall transmit data." This forces allocation and prevents the "I thought they were handling it" failure mode.

Bound the conditions. Every performance requirement should specify the conditions under which the performance applies. Not just the happy path — the environmental extremes, the degraded modes, the worst-case combinations that the system will face in operation.

Why Quality Matters More Than Quantity

A requirements set of 500 well-formed, testable, traced requirements is infinitely more valuable than 5,000 poorly written statements that take six months to interpret and can never be objectively verified. The cost of a requirement is not in writing it — it is in designing to it, building to it, and verifying it. Every ambiguous requirement multiplies that cost because each ambiguity generates rework, negotiation, and re-test.

The most expensive words in requirements engineering are "what did we mean by this?"

Assessment