In the world of technical writing and engineering standards documentation, few debates are as persistent as the choice between shall and must. Some critics reject “shall” by calling it outdated and prone to misinterpretation. Meanwhile, others insist that must feels awkward and is an unnecessary departure from established norms. So which should you use?

The Case for Shall

The word shall has multiple definitions, which can sometimes contribute to the confusion surrounding its use. In an archaic sense, shall referred to something that would inevitably happen in the future; similar to will. However, its modern use in technical writing is well-established as a term denoting a mandatory requirement. As such, this distinction is important because shall actually serves a precise function in structured documentation.

Shall has traditionally been used in standards, contracts and technical documents to indicate mandatory requirements. Organizations such as ASME, ISO, and IEEE use shall to denote obligations. This distinguishes it from should (a recommendation) and may (an option).

Proponents of shall argue that:

• It has an established precedent in both technical writing and law.
• It clearly separates requirements from recommendations when used correctly.
• It avoids the potential ambiguity of must, which in some contexts can imply an obligation imposed by an external authority rather than a requirement intrinsic to the document itself.

However, misuse of shall, such as applying it inconsistently or overuse within nonrequirement statements, has led to confusion in some industries, thus fueling arguments against its use.

The Case for Must

In response to historical inconsistencies with shall, some organizations, including the Federal Aviation Administration (FAA) and the International Organization for Standardization (ISO), recommend must as a preferred term for mandatory statements.

Supporters of must argue that:

• It is more common in everyday language, making it clearer to a general audience.
• Unlike shall, which still carries some historical and archaic connotations, must has a narrower and more consistent definition in modern usage. While shall retains some associations with its older meaning of inevitability, must is more straightforward in denoting obligation, making it less susceptible to varying interpretations across different contexts.
• It aligns with the push for plain language in technical writing.

However, must can feel unnatural in certain contexts, especially when transitioning from a shall-based standard. For example, in structured requirement statements, shall often integrates more smoothly:

“The system shall provide error logs for all failed login attempts.”

Replacing shall with must here can feel slightly forced:

“The system must provide error logs for all failed login attempts.”

This isn’t necessarily incorrect, but it illustrates how familiarity with shall makes it feel more native in some contexts.

Additionally, must may not yet have enough support for a consistent interpretation. As mentioned above, there is also concern that must infers that a requirement has some sort of external enforcement outside of the document or organization. These issues mean that both must and shall have their own separate interpretation issues.

The Key Takeaway: Consistency Is What Matters

Ultimately, the choice between shall and must is not about one being superior to the other. What matters most is consistency within a document and clarity for the reader. If you choose shall, ensure that it is used exclusively for mandatory requirements and is not mixed with should or will in ways that create ambiguity. If you prefer must, apply it consistently and avoid any unintended interpretations.

Regardless of which term you adopt, define your preferred term. Include the term in a Definitions section at the beginning of your document or in your high-level Quality Policy that specifies how requirements are expressed (e.g, “Shall denotes a mandatory requirement” or “Must is used for all required actions”). This eliminates confusion and ensures clarity.

Conclusion

Both shall and must are valid choices for expressing requirements in technical documents. Shall has a longstanding history of use in standards and contracts, though it still retains traces of its older meaning of future inevitability in some contexts. Must, on the other hand, offers a plain-language approach with a narrower and more consistent definition, though it can also have its own interpretation issues. While some industries are shifting toward must for simplicity, shall remains entrenched in many longstanding standards. The most important factor is not which word you choose, but how consistently and clearly you use it. Pick one, define it explicitly in your documentation, and stick with it.

Disclaimer: This article is for informational purposes only and is not intended to provide legal advice. Nothing in this article represents actual legal advice.