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 / 16 completed
1 / 16
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 / 16
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 / 16
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 / 16
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 / 16
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.
6 / 16
John, a senior developer, comments on a pull request: 'The service must validate all user input against the schema before processing it.' Which modal verb best reflects this requirement's strictness?
Using 'must' indicates an absolute necessity and a non-negotiable constraint. This is appropriate for critical security or data integrity requirements. 'Should' implies recommendation; 'may' suggests permission; and 'could' expresses possibility – none of which align with John's forceful statement emphasizing the requirement's importance.
7 / 16
Sarah, during a Slack discussion about a new feature, says: 'We need to implement rate limiting on the API endpoint.' What is the primary purpose of using 'need' in this context?
The modal verb 'need' signifies a strong obligation or necessity. In technical specifications and discussions about features, it's often used to highlight what is essential for correct functionality and stability. Options 'suggest', 'offer', and 'describe' use different modals with significantly altered meanings.
8 / 16
John, a senior developer, comments on a pull request: 'The service must validate all user input against the schema before processing it.' Which modal verb best reflects this requirement's strictness?
Using 'must' indicates an absolute necessity and a non-negotiable constraint. This is appropriate for critical security or data integrity requirements. 'Should' implies recommendation; 'may' suggests permission; and 'could' expresses possibility – none of which align with John's forceful statement emphasizing the requirement's importance.
9 / 16
Sarah, during a Slack discussion about a new feature, says: 'We need to implement rate limiting on the API endpoint.' What is the primary purpose of using 'need' in this context?
The modal verb 'need' signifies a strong obligation or necessity. In technical specifications and discussions about features, it's often used to highlight what is essential for correct functionality and stability. Options 'suggest', 'offer', and 'describe' use different modals with significantly altered meanings.
10 / 16
John, a senior developer, comments on a pull request: 'The service must validate all user input against the schema before processing it.' Which modal verb best reflects this requirement's strictness?
Using 'must' indicates an absolute necessity and a non-negotiable constraint. This is appropriate for critical security or data integrity requirements. 'Should' implies recommendation; 'may' suggests permission; and 'could' expresses possibility – none of which align with John's forceful statement emphasizing the requirement's importance.
11 / 16
Sarah, during a Slack discussion about a new feature, says: 'We need to implement rate limiting on the API endpoint.' What is the primary purpose of using 'need' in this context?
The modal verb 'need' signifies a strong obligation or necessity. In technical specifications and discussions about features, it's often used to highlight what is essential for correct functionality and stability. Options 'suggest', 'offer', and 'describe' use different modals with significantly altered meanings.
12 / 16
Maria, a QA engineer, is writing a bug report for a new microservice. She states: 'The service must handle requests with a maximum payload size of 1MB.' Which modal verb best describes this requirement's strictness and enforceability?
'Must' denotes an absolute requirement, indicating that failure to adhere to this constraint constitutes a critical defect. The other options ('should', 'could', 'may') suggest less stringent conditions, failing to convey the necessary level of obligation for a bug report. It's crucial in technical specifications to clearly define what *must* be done.
13 / 16
Ben writes a PR description: 'This change will improve the performance of the database queries.' Which modal verb is most appropriate to use here?
'Will' expresses a prediction or anticipated outcome. While likely true, it doesn't guarantee performance improvement—it's an expectation based on the change. 'Must', 'should', and 'can' all imply more concrete requirements or recommendations.
14 / 16
A developer is documenting a new API endpoint. They need to state that clients are allowed to send data using JSON format. Which modal verb best conveys this allowance?
'Shall' historically indicated a mandatory requirement but is rarely used in modern specifications. 'Can' expresses permission or possibility – the API 'allows' JSON data. 'Should' suggests recommendation and 'must' indicates obligation.
15 / 16
A requirements document states: 'The application ___ support both iOS and Android platforms.' Which modal verb is most appropriate to indicate a necessary capability?
'Must' correctly indicates an absolute requirement – the application *needs* to support both platforms. 'Shall' is rarely used in specifications, 'can' and 'should' imply flexibility, while 'will' suggests a future action.
16 / 16
A requirements document states: 'The system ___ ensure data integrity through checksum validation.' Which modal verb best describes the expected behavior of the system?
'Must' indicates a fundamental requirement – the system *has* to guarantee data integrity. This reflects a critical non-functional requirement. 'Should' is too weak for this context, and 'can' and 'will' offer less precise descriptions of the system's behavior.
What will I practise in "Modal Verbs in Requirements and Technical Specifications | Coders Lingo"?
Practise must, should, may, and might in software requirements documents and API specifications. 5 grammar exercises for technical writers and developers.
How many exercises are in this module?
This module has 16 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the grammar rule and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Grammar exercises?
Browse the full Grammar hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain grammar rules in prose; this exercise tests and reinforces those rules through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.