Sign up for freeSign up

MUST, SHOULD or MAY? Must, should and may in specs and requirements

Must, should and may in requirements come in two styles in this B2 English for IT lesson plan: capitals for a spec, plain words for a help page.

Grammar
Spec key words (MUST, SHOULD, MAY) and their plain partners (need to, we recommend, don't have to), plus must not (forbidden) against don't have to (not necessary).
Topic
A draft spec for payout webhooks at Kestrel Cloud, a fictional payments startup, with words such as requirement, mandatory, optional and ambiguous.
Activities
The story of RFC 2119, a webhook spec, a call that settles a MUST, self-checking drills, a chat, a wheel, and rules to write in two styles and record.

What's inside

  1. Chapter 1Warm-up: Rules, Rules, Rules

    • PictureUnlock
    • Open a box and answerOpen the boxUnlock
    • Study the words for specs and rulesVocabularyTry it
    • Look at the pictures and choose the wordChoose by pictureUnlock

  2. Chapter 2The Story: Three Pages, Three Little Words

    • Read the story of RFC 2119ArticleUnlock
    • Choose the correct answer about the storyQuizUnlock

  3. Chapter 3At Work: The Payout Webhook Spec

    • Read the spec: payout webhooksArticleUnlock
    • True or false? Check the specTrue or falseUnlock
    • Choose the best plain-English version for the help pageQuizUnlock

  4. Chapter 4Listen: MUST or SHOULD?

    • Listen to Beatriz and Rui: MUST or SHOULD?ListeningTry it
    • Transcript, for the teacherUnlock
    • Choose the correct answer about the callQuizUnlock

  5. Chapter 5Grammar: Must, Should, May and Friends

    • Study the scheme: MUST, SHOULD, MAY and plain EnglishGrammar schemeTry it
    • Choose the key word that matches the meaning in bracketsChoose the optionUnlock
    • Sort the phrases by meaningSort into columnsUnlock
    • Choose the correct option: forbidden or not necessary?Choose the optionUnlock
    • Fill in the gaps: rewrite each rule in the other styleFill in the gapsTry it
    • Drag the key words into the gaps in the app specDrag and dropUnlock

  6. Chapter 6Speak Up: Clear Rules, Friendly Words

    • Choose the best reply to a partner developerChatTry it
    • Spin the wheel: rules at your workSpin the wheelUnlock

  7. Chapter 7Homework: Write Your Own Spec

    • Read your phrase bankReal-life documentTry it
    • Choose the correct sentenceQuizUnlock
    • Match the sentence halvesMatchUnlock
    • Write five rules in two stylesWriting, checked by the teacherUnlock
    • Record the rules for a new colleagueSpeaking, checked by the teacherUnlock

25 exercises in 7 chapters. Start a 7-day free trial to open all of them, copy any part into your own lessons, and teach the lesson live.

Requirements vocabulary

12 words and phrases from the lesson, each with a picture and audio in edio.

+9 more with pictures and audio in the lessonMore words

  • mandatory
  • optional
  • retry
  • ambiguous
  • exception
  • comply with
  • interpret
  • leave out
  • fall back to

Grammar: modal verbs for requirements in specs

Specs and help pages state the same rules in formal and informal English. Through a draft spec for payout webhooks, learners match each capital key word to its plain partner, tell must not from don't have to, and keep MAY for an option and might for a possibility.

MUST, SHOULD or MAY? Say how strong a rule is

Specs use capital key words (RFC 2119). Help pages and chats say the same in plain English: need to, have to, should, don't have to.

Five levels, from MUST to MAY

MUST (or REQUIRED, SHALL) is an absolute requirement, and MUST NOT an absolute ban. SHOULD is a strong recommendation that only a valid reason can override; SHOULD NOT marks what is usually a bad idea, and MAY (or OPTIONAL) is truly optional.

MeaningSpec (formal)Plain English (informal)
Necessary, no exceptionsMUST · is REQUIRED · SHALLyou need to · you have to
Forbidden, no exceptionsMUST NOT · SHALL NOTyou mustn't · never … · you aren't allowed to
Recommended: skip it only for a valid reasonSHOULD · is RECOMMENDEDyou should · we recommend + -ing
Usually a bad idea, but there can be an exceptionSHOULD NOT · is NOT RECOMMENDEDyou shouldn't · we don't recommend + -ing
Not necessary: your choiceMAY · is OPTIONALyou can · you don't have to · you don't need to · it's up to you

Base verb, no to

Key words take the base verb: Your endpoint MUST answer within 10 seconds, never must to answer. Longer forms say the same: Merchants are required to use HTTPS. As must has no do form, the negative of necessity is doesn't have to or doesn't need to.

FormPatternExample
Key wordMUST / SHOULD / MAY + base verb (no to)Your endpoint MUST answer within 10 seconds.
Negative key wordMUST NOT / SHOULD NOT + base verbYour code MUST NOT fail on a new field.
be + key wordis REQUIRED / RECOMMENDED / OPTIONALVerifying the signature is REQUIRED.
be required toam / is / are required to + verbMerchants are required to use HTTPS.
need to / have toneed(s) to / have to / has to + verbYour endpoint has to answer within ten seconds.
Not necessarydon't / doesn't have to, don't / doesn't need to + verbYour endpoint doesn't need to use port 443.

Must not or don't have to?

Must not means it's forbidden: You mustn't share your signing secret. Don't have to and don't need to mean it isn't necessary: You don't have to subscribe to both event types. Mixing them up turns a free choice into a ban.

must not / mustn't = it's forbidden

  • You mustn't share your signing secret.
  • Your code must not crash on a new field.

don't have to / don't need to = it isn't necessary

  • You don't have to subscribe to both event types.
  • Your endpoint doesn't need to use port 443.

Formal spec, informal help page

The same rule changes register with its reader: The client MUST send the event ID in a spec becomes You need to send the event ID on a help page, and A description is OPTIONAL becomes You don't have to add a description.

Formal or informal?

Spec (formal)

  • The client MUST send the event ID.
  • Merchants are required to use HTTPS.
  • A description is OPTIONAL.

Help page or chat (informal)

  • You need to send the event ID.
  • You have to use HTTPS.
  • You don't have to add a description.

From the payout webhook spec

  • Your endpoint MUST verify the signature before it trusts an event.an absolute requirement
  • Kestrel MUST NOT send events to a plain HTTP address.an absolute ban
  • Your endpoint SHOULD answer first and do any slow work afterward.a strong recommendation
  • Merchants MAY subscribe to only one of the two event types.truly optional
  • If you store payouts, you need to check the event ID. If not, you don't have to.the plain version for the help page

Capitals, and MAY or might?

Since RFC 8174 (2017), only key words in capitals carry the special meanings; a lowercase must is ordinary English. In a spec, MAY gives permission, so a possibility takes might: The same event might arrive twice.

Capitals, and MAY vs might

Since RFC 8174 (2017), only the key words in CAPITALS have the special meanings; a lowercase “must” or “should” is ordinary English. In a spec, MAY gives permission: it's an option. For a possibility, write might: “The same event might arrive twice.”

Typical mistakes

  • The client must to send the event ID.

    The client must send the event ID.

    no to after must, should or may

  • Your endpoint doesn't must use port 443.

    Your endpoint doesn't have to (doesn't need to) use port 443.

    must has no do / does form

  • Merchants should to check the signature.

    Merchants should check the signature.

    should + base verb

  • You must not subscribe to both events. (meaning: it isn't necessary)

    You don't have to subscribe to both events.

    must not = forbidden; don't have to = not necessary

More lessons on this grammar: Modal verbs lessons and exercises

Try the modals for requirements exercises

Try them yourself: these are the same exercises your students do in edio.

More exercises

What's in the lesson

  • 13 auto-checked exercises
  • 2 games
  • 2 teacher-checked tasks
  • 1 real-life document
  • 2 articles
  • 1 grammar scheme
  • 1 set of word cards
  • 1 audio clip
  • 1 picture
  • 1 transcript

The main objectives of this lesson are to:

  • say how strong a rule is with spec key words: Your endpoint MUST verify the signature. Merchants MAY subscribe to only one event type.
  • tell what is forbidden from what isn't necessary: You mustn't share your signing secret. You don't have to use port 443.
  • rewrite a formal rule in plain English and back: A description is OPTIONAL becomes You don't have to add a description.
  • write five requirements for your own feature or team in two styles, and explain them to a new colleague

Lesson 4 of English for IT B2 · Beyond the Code opens Docs people read, the unit on writing docs that others can follow and act on. It builds on must, mustn't and don't have to from A2.2 lesson 22 and should for advice from A2.1 lesson 26; lessons 5 and 6 go on to participle clauses and plain English. When another company's developers build from your spec, each modal decides what they build.

The lesson starts with an open box of questions about rules at work, then twelve words with pictures and audio and a picture quiz. The story tells how a three-page document from 1997 fixed what the capital key words mean. At work, learners read a draft webhook spec with a plain-English summary and choose the best help-page wording for formal rules; in the AI-voiced call, a product owner and a developer argue over a MUST.

The scheme leads into five self-checking drills, from matching key words to meanings to choosing between forbidden and not necessary. In the chat, learners answer a partner developer's questions in friendly, exact English, and a wheel turns to rules at their own work.

Homework begins with a phrase bank of rules in two styles, then a choice of correct sentences and sentence halves to match, both self-checking. Learners write five rules for their own feature or team in formal spec style and in plain English, then record them for a new colleague; the teacher reviews both.

Grammar:
modal verbs for requirements · must not vs don't have to · formal and informal register
Topic:
specifications · RFC 2119 · webhooks · documentation

Teaching tips

  • Bring a real spec or style guide: in-company groups find three rules in their own documentation and decide whether each is a MUST, a SHOULD or a MAY, and whether the wording says so.
  • Debate the open clause before the call: half the class argues for MUST and half for SHOULD on duplicate events, then everyone listens for how the product owner and the developer split the rule.
  • Draw two columns, forbidden and not necessary, and have learners place rules from their own jobs under each before the drill on must not and don't have to.
  • One-to-one, swap registers aloud: read a formal rule from the learner's own docs and have them say it as they would to a new colleague, then reverse the roles.

Liked it?

Teach the whole lesson in edio

25 exercises in 7 chapters, ready to teach. edio is an online platform for language schools and teachers: ready-made interactive lessons, live classes, homework and student progress in one place.

  1. Start a free trial

    7 days, no credit card.

  2. Open the lesson

    Find it in the library of 621 ready lessons. Teach it as it is, or copy any chapter into your own lessons.

  3. Teach it live or as homework

    Students work in their own accounts, in sync with you during the lesson, and the practice exercises check themselves.

Teach it free for 7 days

The whole course: English for IT B2 · Beyond the Code

24 lessons at B2 for software teams, in American English. A year on at Kestrel Cloud, a fictional payments startup, Iryna and her team estimate work, write docs and postmortems, argue trade-offs, give demos and negotiate scope. Each lesson starts from a real case, from the Apollo 11 alarms to Conway's law.See the course

  1. Unit 1 Planning and estimates

    estimates and deadlines: approximating numbers, the future continuous and perfect, likelihood

    1. Lesson 1It always takes longerApproximating numbers in estimates
    2. Lesson 2By New Year's Eve, we'll have fixed itFuture continuous and future perfect
    3. Lesson 3Let's play planning pokerLikelihood with bound to, likely to and may well

  2. Unit 2 Docs people read

    specs and design docs: modals for requirements, participle clauses, plain English

    1. Lesson 4 · you're hereMUST, SHOULD or MAY?Modal verbs for requirements in specs
    2. Lesson 5Four kinds of docsParticiple clauses in documentation
    3. Lesson 6Just a request for commentsPlain English for design docs

  3. Unit 3 Incidents and postmortems

    telling an incident without blame: narrative tenses, the passive, the third conditional

    1. Lesson 7The 1202 alarmNarrative tenses for incident stories
    2. Lesson 8Blameless by designActive vs passive voice in a postmortem
    3. Lesson 9If we had had an alert…The third conditional: a different past

  4. Unit 4 Architecture and trade-offs

    comparing options and recording decisions: contrast linkers, modals of deduction, mixed conditionals

    1. Lesson 10Your system copies your org chartContrast linkers for comparing options
    2. Lesson 11It's always DNSModals of deduction for troubleshooting
    3. Lesson 12Write down the whyMixed conditionals for looking back on decisions

  5. Unit 5 Demos and tech talks

    a clear structure on stage: signposting, cleft sentences, describing trends

    1. Lesson 13The mother of all demosSignposting language for demos
    2. Lesson 1420 slides, 15 secondsCleft sentences for emphasis
    3. Lesson 15Numbers that tell a storyDescribing graphs and trends

  6. Unit 6 Stakeholders and scope

    saying no and finding yes: diplomatic language, as long as and unless, negotiating

    1. Lesson 16Pay down the debtDiplomatic language for hard messages
    2. Lesson 17Why meetings argue about the bike shedAs long as, provided, unless and otherwise
    3. Lesson 18Yes, if…Negotiating language for scope and deadlines

  7. Unit 7 AI, security and ethics

    AI tools, passwords and team rules: be used to and get used to, past modals of deduction, purpose linkers

    1. Lesson 19Your new pair programmerUsed to, be used to and get used to
    2. Lesson 20Change your password? Maybe notPast modals of deduction
    3. Lesson 21Rules for AI at workPurpose linkers for rules with a reason

  8. Unit 8 Growing your career

    feedback, retros and goals: phrasal verbs, reporting verbs, wish and if only

    1. Lesson 22Your next levelCareer phrasal verbs and goal frames
    2. Lesson 23Feedback that helpsReporting verbs and their patterns
    3. Lesson 24Start, stop, continueWish and if only for wishes and regrets

Questions about this lesson

What's the difference between formal and informal English?
Formal English uses impersonal, exact forms suited to documents, while informal English sounds like one person talking to another. Merchants are required to use HTTPS fits a spec; You have to use HTTPS fits a help page or a chat. Formal writing prefers is required, is recommended and is optional; informal writing uses you, contractions and short verbs: you need to, you don't have to, it's up to you.
What's the difference between "should" and "must"?
Must states a requirement; should states a strong recommendation. Your endpoint must use HTTPS allows no exceptions, while Your endpoint should answer first and do slow work afterward leaves room for a valid reason to do otherwise. Specs write them in capitals, MUST and SHOULD, to make the difference exact. In a chat, should can sound softer still, so say need to when you mean a rule.
How do you write a rule in formal and informal English?
Keep the rule's strength and change only the forms: Merchants are required to check the signature becomes You need to check the signature, Checking the event ID is RECOMMENDED becomes We recommend checking the event ID, and A description is OPTIONAL becomes You don't have to add a description. A rewriting drill in MUST, SHOULD or MAY?, a B2 English for IT lesson on edio.ai, works in both directions.
What do MUST, SHOULD and MAY mean in a specification?
In a specification, MUST is absolute, SHOULD is recommended and MAY is optional. MUST NOT is an absolute ban, and SHOULD NOT means usually a bad idea, with room for exceptions. A SHOULD can be skipped only for a valid reason, once you understand the consequences; a MAY feature can be left out, and products with and without it must still work together. These meanings come from RFC 2119.
Is "must not" the same as "don't have to"?
No: must not means forbidden, don't have to means not necessary. You mustn't share your signing secret bans it; You don't have to subscribe to both event types leaves the choice to you. In the positive, must and have to both mean necessary: You must use HTTPS, You have to use HTTPS. A drill in the B2 English for IT lesson MUST, SHOULD or MAY? on edio.ai has learners choose between them in eight rules.
Can you say "must to" or "doesn't must"?
No: must takes the bare verb and has no do form. Say The client must send the event ID, not must to send; should and may work the same way (Merchants should check the signature). For the negative of necessity, use doesn't have to or doesn't need to: Your endpoint doesn't have to use port 443, never doesn't must.
What's the difference between MAY and might in a spec?
In a spec, MAY gives permission and might states a possibility. Merchants MAY register a second endpoint means they're allowed to; The same event might arrive twice means it can happen. Writing The same event MAY arrive twice turns a fact about retries into an option. The B2 English for IT lesson MUST, SHOULD or MAY? on edio.ai checks this in its homework quiz.
What is RFC 2119?
RFC 2119 is a 1997 document defining the key words for requirements: MUST, MUST NOT, SHOULD, SHOULD NOT and MAY, with equivalents such as REQUIRED and OPTIONAL. Scott Bradner wrote it as advice for internet standards, and RFC 8174 added in 2017 that only capitals count. Specs refer to it in one line near the top: The key words in this document are to be interpreted as described in BCP 14.
What's the difference between mandatory and optional?
Mandatory means required for everyone; optional means your choice. In a spec, mandatory rules take MUST or is REQUIRED and optional ones take MAY or is OPTIONAL; on a help page, compare You need to check the signature with You don't have to use port 443. Between the two sits recommended: We recommend testing first.
How do you write clear requirements for a spec?
One key word per rule, and a reason per SHOULD: Your endpoint MUST verify the signature. Merchants SHOULD NOT use the same endpoint for test and live events: mixing them makes it easy to book a test payout as real money. Keep MUST for what systems need to work together or to prevent harm, and add a plain-English summary for readers who don't read specs.
What's good homework for practicing must, should and may?
Good homework is five rules written twice: formal, then plain, for an API, a screen, code review or how bug reports are written. Ask for MUST, MUST NOT, SHOULD and MAY at least once each, with a reason for every SHOULD. In the B2 lesson MUST, SHOULD or MAY? on edio.ai, a sentence quiz and a match of halves check themselves first; the rules and a recording for a new colleague go to the teacher.
Are there interactive exercises for modals for requirements?
Yes: rewriting drills and chats with instant checking suit requirement modals. Without an account, this page plays four parts of MUST, SHOULD or MAY?, a B2 English for IT lesson on edio.ai: a call that settles whether a rule is a MUST or a SHOULD, a drill that rewrites each rule in the other style, a chat with a partner developer about the spec, and the homework's phrase bank. The rest stays locked.
Unlock full lesson

Teach this lesson with your students

Book a demoStart free trial

No credit card required