When writing requirements, every word counts. Requirements are usually written in English using sentence templates. English is the standard these days, as products are approved globally and development teams and customers are distributed worldwide. Correct use of the modal auxiliary verbs "shall," "should," "must," "will," and "may" is especially important.
Shall (must)
A "shall" indicates a requirement as binding and is arguably the most important term for requirements. A requirement with "shall" in the sentence must be implemented, and its implementation verified. "Shall" should therefore not be translated as "should," but rather as "must"!
My recommendation is to formulate every mandatory requirement with "shall." A "shall not" indicates that something is not permissible. "Shall not" doesn't mean that something doesn't have to be done, but rather that it shouldn't be done. A crucial difference.
Should
The modal auxiliary verb "should" indicates a soft requirement. This is where a requirement is formulated that, if there are good reasons for doing so, can be omitted, taking the context into account. For example, if this requirement would disproportionately increase development costs, it can be ignored. Furthermore, "should" is appropriate for requirements that are not testable. This allows requirements to be formulated to specify goals for a development team that cannot be formally verified.
Must
"Must" is often used equally with "shall." I recommend against using "must," as it only creates uncertainty. What is the difference between "must" and "shall"? A mix of both should be avoided at all costs. Using "shall" is always a safe bet.
Will (will)
"Will" can be used to document factual decisions. This information is relevant for a supplier, but not a requirement for the supplier itself. "Will" can be used, for example, to specify how a third-party system or an existing solution behaves or will behave. "Will" requirements do not require verification by the supplier.
May (may)
Anything less than "may" is probably not possible. A requirement with "may" is completely arbitrary. It allows you to request a feature that would be nice, but is also completely irrelevant. It's a case of "do it or don't do it."
For those who enjoy these terminology, I have a quote from the mathematician and physicist Georg Christoph Lichtenberg.
I can't say, of course, whether things will be better if they change; but I can say this much: things must change if they are to be good.