Modal Verbs in Requirements and Technical Specifications
5 exercises — master must, should, may, and might for writing clear, unambiguous software requirements: mandatory rules, recommendations, optional features, and uncertain outcomes.
Modal verbs in specs (RFC 2119)
must / shall → mandatory requirement: "The system must log all errors"
should → strong recommendation, exceptions allowed: "Functions should have one responsibility"
may → optional: "Clients may include a custom header"
might / could → uncertain possibility: "This might increase latency"
0 / 5 completed
1 / 5
A software requirements document states: "The system ___ encrypt all data at rest using AES-256." This is a non-negotiable mandatory requirement. Which modal is correct?
Must is the correct modal for mandatory, non-negotiable requirements. In technical specifications and requirements documents, modals carry precise legal and contractual weight. The RFC 2119 standard (widely used in technical specs) defines: MUST / SHALL = absolute requirement; SHOULD = recommended but not absolute; MAY = optional. In plain English requirements: "The system must authenticate users before granting access." · "Passwords must be hashed using bcrypt." · "The API must return responses within 200ms under normal load." Using should where must is intended creates ambiguity and can have contractual or compliance consequences. In security and compliance contexts especially, must signals that deviation is not acceptable.
2 / 5
A code style guide states: "Functions ___ have a single responsibility, though exceptions are permitted for legacy code." Which modal fits a strong recommendation that is not absolute?
Should is the correct modal for strong recommendations — best practices that are expected but allow exceptions in specific circumstances. RFC 2119: SHOULD means "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed." In practice: "Error messages should include a request ID for traceability." · "Tests should cover both happy path and edge cases." · "Functions should be no longer than 50 lines." The key signal here is "though exceptions are permitted" — this explicitly marks it as a recommendation, not a rule. Must would be too strong. May would be too weak (merely optional). Will expresses future fact, not obligation.
3 / 5
An API specification reads: "Clients ___ include an X-Request-ID header in all requests; this header is entirely optional." Which modal correctly marks an optional feature?
May is the correct modal for optional features. RFC 2119: MAY = truly optional; the implementation can choose to include or omit this feature without violating the spec. In API and protocol documentation: "Clients may include a Prefer header to request response formats." · "Implementors may add custom error codes in the 4xx range." · "The response body may include additional metadata fields." The sentence already signals optionality ("entirely optional"), confirming may is correct. Contrast: must = mandatory; should = recommended; may = optional; might = possible/uncertain (not used for requirements). Shall is a formal synonym for must in legal/contractual language — wrong for an optional feature.
4 / 5
A tech lead writes in a PR description: "This change ___ cause a slight increase in latency under heavy load — we're not sure yet." Which modal expresses uncertainty about a possible outcome?
Might is correct for expressing uncertainty or possibility — something that could happen but is not expected or confirmed. In technical communication: "Increasing the poll interval might reduce CPU usage." · "This refactor might introduce regressions in untested paths." · "The cache might not warm up fast enough on cold start." The phrase "we're not sure yet" confirms this is speculation, not a recommendation. Contrast the full modal spectrum in specs: must = mandatory obligation; should = strong recommendation; may = permitted option; might / could = uncertain possibility. In requirements writing, using the right modal prevents misinterpretation. Might and could signal informed uncertainty — valuable for flagging risks without asserting certainty.
5 / 5
Which sentence in a requirements document uses modals most precisely and professionally?
Option B demonstrates precise modal usage across three requirement types: ① must encrypt — mandatory security requirement (encryption of PII is non-negotiable). ② should include — strong recommendation for API keys (best practice with possible exception for public endpoints). ③ may be configured — optional configuration (the implementer can choose within a range). This tripartite structure (must / should / may) maps directly to RFC 2119 and is the professional standard for requirements writing. Option A mixes modals incoherently ("may optionally must", "will might"). Option C has the same problem ("must may", "should will"). Option D uses informal equivalents (has to, need to, possibly) — these are acceptable in conversation but lack the precision required in formal specs.