Technical Specification Writing
3 exercises — write testable requirements, acceptance criteria using Given/When/Then, and precise API error-handling specifications.
0 / 3 completed
Technical specification principles
- Testable: every requirement must have a measurable, pass/fail criterion
- Normative language: use MUST / SHOULD / MAY (RFC 2119) not "might" or "could"
- Given/When/Then: the standard format for acceptance criteria
- Concrete values: replace "fast" with "under 200 ms", "large" with "over 10 MB"
- Conditions: every behaviour spec should state "under what conditions"
1 / 3
A product manager writes this requirement for a new feature:
"The system should be fast."
Which rewrite turns this into a testable technical requirement?
Option B is the only testable requirement. It specifies: a measurable threshold (200 ms), a statistical measure (95th percentile), and a defined load condition (1,000 concurrent users).
Testable requirements answer: What? How much? Under what conditions?
Options A, C, and D are not testable — there is no agreed definition of "fast", "responsive", or "not slow" that a QA engineer could use to write a pass/fail test.
Requirement writing vocabulary:
Testable requirements answer: What? How much? Under what conditions?
Options A, C, and D are not testable — there is no agreed definition of "fast", "responsive", or "not slow" that a QA engineer could use to write a pass/fail test.
Requirement writing vocabulary:
- must — mandatory requirement (RFC 2119: MUST)
- should — recommended but not mandatory (SHOULD)
- p95 / 95th percentile — 95% of requests complete within this time
- under load — performance specification applies at a defined concurrency level
Next up: Bug Report Writing →