5 exercises on writing precise, testable requirements with MUST / SHALL / SHOULD and measurable criteria.
Key patterns
MUST / SHALL — mandatory; SHOULD — recommended; MAY — optional (RFC 2119).
Every requirement should be testable: state what, how much, and under what conditions.
Replace vague adjectives (“fast”, “reliable”) with numbers and thresholds.
Keep requirements atomic — one obligation per statement, no “and”-chains.
0 / 5 completed
1 / 5
A spec author wants to express a mandatory requirement that cannot be skipped. Following RFC 2119 conventions, which sentence is most precise?
Use MUST (or SHALL) for hard, non-negotiable requirements.
RFC 2119 defines a small vocabulary of requirement keywords, written in uppercase to flag that they are normative:
MUST / SHALL / REQUIRED — an absolute requirement; non-compliance means the implementation is wrong.
SHOULD / RECOMMENDED — strong advice, but a documented reason may justify deviating.
MAY / OPTIONAL — genuinely discretionary.
Option A uses should, which signals the check is optional — dangerous for a security control. Option B (“is expected to”) and Option D (“will probably”) are vague hedges that a reviewer or auditor cannot hold the team to. For a signature check, ambiguity is a security hole — MUST is the only correct strength.
2 / 5
Which requirement is testable and measurable — i.e. a QA engineer could write an unambiguous pass/fail test from it?
A testable requirement names the input, the threshold, and the conditions.
Option B is the only one a tester can verify objectively. It pins down:
the workload — a 100,000-row CSV;
the limits — under 10 seconds, peak memory below 512 MB;
the environment — “the reference hardware”.
Words like reliable, gracefully, well, performant, and too much are unfalsifiable — there is no agreed number behind them, so two people will disagree on whether the requirement is met. Good requirements answer what? how much? under what conditions? Quantify every adjective: replace “fast” with a latency budget, “large” with a row or byte count, “heavy usage” with a concurrency figure.
3 / 5
A draft requirement reads:
“The user should be notified when appropriate.”
Which rewrite removes the ambiguity?
“When appropriate” pushes the decision onto the reader. A requirement must state the trigger, the actor, the action, and any timing.
Option C nails all four:
Trigger — order status changes to shipped;
Actor — the system;
Action — send the customer an email;
Timing — within 5 minutes.
The distractors merely swap one vague phrase for another: “when relevant”, “as needed”, “important changes”, “always…informed”. None tells an engineer which event fires the notification or how fast it must arrive. Whenever you write “when appropriate”, “if necessary”, or “as needed”, treat it as a red flag and name the concrete condition instead.
4 / 5
Which requirement avoids the classic trap of compound (multi-part) requirements that are hard to trace and test?
One requirement, one verifiable statement. Each requirement should express a single, atomic obligation so it can be tracked, tested, and ticked off independently.
Option B does exactly that — it states one rule (bcrypt, cost factor 12, before storage) that maps to one test.
Option A bundles four separate obligations with and; if three pass and one fails, is the requirement “done”? You cannot give a clean answer, and a traceability matrix cannot link a test to it cleanly. Option C hides multiple requirements behind the umbrella word “secure”. Option D piles up unmeasurable adverbs (“securely”, “reliably”, “efficiently”).
Rule of thumb: if a requirement contains “and” joining distinct behaviours, split it into separate numbered requirements.
5 / 5
A team wants to express a strong recommendation that may be skipped only with a documented justification. Which keyword usage is correct?
SHOULD = recommended, with room for justified exceptions. That is precisely the strength the question asks for.
Per RFC 2119:
MUST (Option A) is too strong — it forbids any exception, even a deliberately small admin endpoint that returns a bounded list.
MAY (Option C) is too weak — it makes pagination purely optional, so a team could ignore it with no rationale.
SHOULD (Option B) is the sweet spot: pagination is the default, but a team can deviate if they document why.
Option D (“might want to”) is conversational, not normative — it carries no enforceable weight. Choosing the right keyword is half of good requirement writing: it sets the compliance bar. Reserve MUST for safety and correctness, SHOULD for best practice, and MAY for genuine options.