Shall vs Should vs Will vs Must: What’s the Difference and Why Does It Matter?

Crafting requirements is a fundamental aspect of any engineering project, serving as the compass that directs design, development, testing, and validation. These statements define what a system or product should accomplish, how it should perform, and the constraints it must adhere to. Despite their critical role, writing requirements that are clear, concise, and consistent poses a formidable challenge.

Enter the dilemma faced by many systems engineers—the nuanced art of selecting the right words to articulate requirements precisely and unambiguously. It is the question of Shall vs Should that is what we aim to discuss and demystify here, and in the realm of requirements documents, the terms “shall,” “should,” “will,” and “must” are frequent players, often mingling interchangeably. Yet, each carries its own distinct meaning and implications.

In the following exploration, we delve into the differences among these four words, unraveling their unique connotations. Moreover, we aim to provide you with practical guidelines, empowering you to make informed decisions about when to deploy each term in your requirements documents. As we navigate this linguistic landscape, our goal is to shed light on the intricacies, making the process of requirement specification more transparent and manageable.

Shall

“Shall” stands as a linchpin in the lexicon of requirements, representing more than just a word—it embodies a contractual obligation. When “shall” graces a statement, it asserts that implementation and verification are non-negotiable aspects of the project. In essence, “shall” acts as a command, leaving no room for discretion or negotiation. Without this term, a statement cannot be rightfully classified as a requirement.

Examples:

1. The system shall provide a user interface for data entry, ensuring seamless interaction for end-users.
2. The product shall comply with the stringent standards set forth by ISO 9001, underscoring a commitment to quality and compliance.
3. The software shall be designed to generate an error message promptly, fortifying the system against invalid inputs.

The endorsement of “shall” echoes across international standards, including ISO, IEEE, and IEC. Moreover, the Construction Specifications Institute (CSI) upholds its significance in its Construction Specifications Practice Guide. The adoption of “shall” extends beyond standards; it holds sway in both the international and United States court systems as a clear and unequivocal means to express a requirement.

Shall Real-World Example

• IT Sector: In a software development contract, it might state, “The software shall support multi-platform functionality, including Windows, MacOS, and Linux operating systems.” This denotes a non-negotiable requirement for cross-platform compatibility, which is critical for contract fulfillment.
• Construction Industry: A construction specification might read, “All roofing materials shall meet the ASTM International standards for thermal resistance.” This example underscores a mandatory compliance requirement, leaving no room for negotiation or substitution.

In your journey of requirement articulation, consider “shall” as your steadfast ally, a beacon guiding your project towards precision and unwavering commitment.

Should

The term “should” assumes a nuanced role in the realm of requirements, serving as a beacon guiding design teams through a landscape of goals and suggestions. Unlike its more assertive counterparts, “should” does not wield the weight of legal enforceability; instead, it extends an invitation for consideration. It suggests that certain objectives are worthy of attention, but without the rigid constraints of obligatory compliance.

Examples:

1. The system should be equipped with a backup power supply, providing resilience in the face of potential power outages.
2. The product should prioritize user experience, striving to be not only easy to use but also intuitively navigable for end-users.
3. The software should be adaptable, designed to run seamlessly across multiple platforms and browsers, broadening its accessibility.

The utilization of “should” extends beyond a mere suggestion—it encapsulates a design philosophy. It signals to the design team that while these considerations are not legally binding, they merit thoughtful reflection. The implications of disregarding or diverging from a “should” statement should be meticulously assessed and documented.

Should Real-World Example

• Healthcare Sector: A guideline for electronic health record systems might suggest, “The interface should be user-friendly to facilitate quick adoption by healthcare professionals.” Although not enforceably required, this recommendation prioritizes user experience, implying it’s highly beneficial but not mandatory.
• Environmental Management: An environmental impact report might advise, “The project should aim to reduce water usage by 20% through the installation of efficient fixtures.” This suggests good practice for sustainability goals without imposing a strict requirement.

“Should” declarations reside in a realm where verification is not the primary objective. Instead, they invite review for viability and attractiveness, empowering the design team with the flexibility to make informed decisions. This flexibility is a crucial element, offering a balance between guidance and autonomy.

Will

“Will” steps into the arena of requirements with a unique role, serving as a messenger of factual statements and declarations of intent. Unlike its more prescriptive counterparts, “will” doesn’t lay down mandates but rather paints a picture of what currently exists or is destined to unfold in the future. These statements, devoid of a strict requirement tag, are not subject to the scrutiny of verification; instead, they encapsulate the reality or a committed course of action.

Examples:

1. The system will be composed of three main components: input, processing, and output, outlining its structural foundation.
2. The product will make its way to clients within six months after the contract is signed, signifying a concrete timeline commitment.
3. The software will seamlessly integrate with the existing database system, ensuring compatibility and smooth interaction.

“Will” finds its significance in its ability to convey not just facts but also intentions. It serves as a conduit for expressing commitments undertaken by the customer or supplier as part of the contractual agreement. In the intricate tapestry of systems engineering, the use of “will” is not just recommended but deemed crucial for fostering clear and effective communication.

Will Real-World Example

• IT Sector: In a service level agreement, one might find, “The vendor will provide monthly performance reports to the client.” This statement outlines a factual commitment or an action that will take place, indicating a future event that is planned as part of the service.
• Real Estate Development: A development proposal might state, “The new community center will feature solar panels and green roofs.” This describes a feature of the project, detailing what is planned or expected to happen without it being a negotiable performance criterion.

The Construction Specifications Institute (CSI), in its Project Delivery Practice Guide, aligns with the endorsement of “will.” This clear and unequivocal expression becomes a cornerstone in articulating facts, intentions, and commitments within the expansive realm of systems engineering. “Will” thus becomes more than a word; it transforms into a vessel for communicating a certain and committed future.

Must

“Must” commands attention within the spectrum of requirements, standing as an unequivocal indicator of absolute necessity and imperativeness. This term, akin to “required” and “shall,” underscores the paramount importance of the stipulation it accompanies. In its plain and assertive language, “must” becomes a beacon, guiding the necessary actions and drawing a clear line against inappropriate ones.

Examples:

1. The system must operate continuously without interruption, emphasizing the non-negotiable need for seamless functionality.
2. The product must not contain any hazardous materials, reflecting a stringent imperative for safety and compliance.
3. The software must not allow unauthorized access to sensitive data, emphasizing the critical importance of data security.

In the intricacies of systems engineering, “must” and its counterpart “must not” align themselves with the more traditional and formal expressions of “shall” and “shall not.” These expressions play a pivotal role, guiding engineers and stakeholders toward actions that are imperative for success and prohibiting those that could lead to adverse consequences.

Interestingly, the usage of “must” is gaining popularity among legal experts and contract drafters who argue for its clarity and emphasis. However, the preference for “must” over “shall” is not universal, as some standards and organizations adhere to the more traditional and formal nature of “shall.” This nuanced choice reflects the evolving dynamics within the field, where clarity and tradition interplay.

Must Real-World Example

• Healthcare Compliance: In healthcare regulations, one might encounter, “All patient data must be encrypted in transit and at rest, as per HIPAA regulations.” Here, “must” indicates an absolute imperative based on regulatory compliance, emphasizing the necessity for encryption to protect patient data.
• Food Safety Standards: In food production, guidelines might specify, “All food contact surfaces must be sanitized according to federal health standards.” This statement is an explicit command that highlights the necessity for sanitation to ensure food safety.

As you navigate the landscape of requirements, consider “must” as a linguistic force that leaves no room for ambiguity, signaling requirements that are absolutely essential for the success and integrity of your engineering endeavors.

Legal Implications of Misusing Terms in Contracts

The precision of language in contract specification is not just a matter of semantic preference; it has significant legal implications. Incorrect usage of terms such as “shall,” “should,” “will,” and “must” can lead to ambiguities, misinterpretations, and potentially costly legal disputes. This section delves into the legal ramifications that may arise from the improper use of these terms across various industries, underscoring the importance of clarity and precision in contractual documentation.

General Legal Framework

In the realm of contract law, clarity and unequivocality in language are paramount. Contracts are binding legal documents, and every word contributes to the definition of the obligations, rights, and responsibilities of the parties involved. The misuse of directive terms can lead to interpretations that diverge from the intended agreement, potentially resulting in breaches of contract, litigation, and financial losses.

IT Sector: The Importance of “Shall”

In software development agreements, the term “shall” denotes a binding obligation. For instance, stating that “the software shall maintain a 99.9% uptime” establishes a clear, enforceable requirement. If the software fails to meet this criterion, the provider could be held legally accountable for not fulfilling a contractual obligation, leading to penalties or damage claims.

Construction Industry: The Consequences of “Must”

In construction, “must” signifies an imperative, often related to safety and regulatory compliance. For example, “All materials must meet the regional safety standards.” Non-compliance not only endangers safety but also exposes parties to legal actions from regulatory bodies, potential nullification of insurance policies, and civil litigation from affected individuals or entities.

Healthcare Sector: Distinguishing “Should” from “Must”

The healthcare industry frequently grapples with the implications of “should” versus “must” in compliance and policy documents. “The hospital should follow patient privacy protocols” implies a recommendation, whereas “The hospital must follow patient privacy protocols” indicates a mandatory action, often tied to legal regulations such as HIPAA in the United States. Misinterpreting “should” as an option rather than a strongly recommended action can lead to breaches of patient confidentiality and significant legal repercussions.

Environmental Law: The Ambiguity of “Will”

Statements of intent or descriptions of future actions, denoted by “will,” can also bear legal weight, especially in environmental law. A declaration such as “The company will reduce emissions by 40% within five years” can be interpreted as a commitment in contexts such as environmental impact statements or sustainability reports. Failure to achieve the outlined goals might not directly breach a contract, but it could lead to regulatory scrutiny, fines, and reputational damage if the statement is deemed misleading or insincere.

Mitigating Legal Risks

To mitigate these legal risks, parties drafting contracts should:

• Seek Legal Counsel: Engage legal professionals during the drafting stage to ensure that the language used accurately reflects the intentions and obligations of all parties.
• Use Unambiguous Language: Opt for clear, straightforward language that unmistakably defines the expectations and commitments involved.
• Standardize Terms: Where possible, adhere to industry standards for contractual language, which can help reduce the likelihood of misinterpretation.
• Include Definitions: Define key terms within the document to provide clarity and reduce ambiguity.
• Contemplate Scenarios for Enforcement: Consider how each requirement might be enforced legally and whether the language used supports that enforcement.

Understanding and properly employing directive terms like “shall,” “should,” “will,” and “must” can significantly reduce the risk of contractual disputes and their associated costs. As demonstrated across various industries, the legal and financial stakes of accurate language in contracts are high, making it imperative for contract drafters to approach their task with diligence and precision.

Language Evolution and Regional Variations in Contractual Terms

The interpretation of contractual terms such as Shall vs Should vs Will vs Must is not static; it evolves over time and can vary significantly across different legal jurisdictions and industries. This evolution and variation can lead to misunderstandings, especially in international projects where diverse legal systems and cultural understandings come into play. Below, we explore how these terms have evolved and how their interpretations can differ, highlighting the importance of context and clarity in multinational and cross-industry contracts.

Evolution within Legal Systems

• Shall: Traditionally, “shall” has been used in legal contexts to indicate mandatory actions. However, its interpretation has become more nuanced, with some modern legal documents using it less frequently due to its potential for ambiguity. For instance, in some jurisdictions, “shall” is being replaced with “must” to denote obligations more clearly.
• Must: “Must” is increasingly preferred in legal documents for its unequivocal expression of necessity or requirement. This shift reflects a broader trend towards plainer language in legal writing, aiming to minimize ambiguity.
• Should: Historically and across regions, “should” suggests a recommendation rather than a mandatory action. Its interpretation remains relatively consistent, promoting best practices without implying legal obligation.
• Will: “Will” generally denotes future actions or facts, with its interpretation remaining stable across most legal systems. However, the degree to which it implies commitment can vary, especially in contractual deadlines or deliverables.

Regional Variations

• Common Law vs. Civil Law Systems: In common law jurisdictions (e.g., the United States and the United Kingdom), there’s a strong emphasis on the precise meaning of contractual terms, with substantial jurisprudence on terms like “shall” and “must.” Civil law jurisdictions (e.g., Germany and Japan), however, may place more weight on the intent behind the contract and the parties’ behavior than on the literal interpretation of specific words.
• Industry-Specific Language: In the engineering sector, “shall” often signifies binding requirements, crucial for safety and performance standards. Conversely, in the IT industry, especially in agile development environments, there is a movement towards more flexible language to accommodate changing project scopes, leading to varied uses of “should” and “will.”
• Cultural Interpretations: Cultural differences can also affect the interpretation of these terms. For example, in some cultures, direct commands might be avoided in favor of suggestive language to maintain harmony. This cultural nuance can influence contract language in multinational projects, where what is considered a firm commitment in one culture might be seen as a guideline in another.

Recommended Further Reading Amazon Books

Implications for International Projects

To navigate the complexities of language evolution and regional variations in international projects, consider the following approaches:

• Clear Definitions: Include a definitions section in your contracts that clearly outlines what each term means within the context of your agreement.
• Cultural Sensitivity: Be aware of cultural differences in interpretation and strive for language that is clear and unambiguous across cultures.
• Legal Consultation: Engage legal experts familiar with the jurisdictions and industries involved to review contract language for potential ambiguities.

By understanding and addressing the nuances of language evolution and regional variations, parties can significantly reduce the risk of misinterpretation and ensure that contracts are executed as intended, regardless of the legal or cultural context.

Common Challenges in Requirements Language

In the dynamic landscape of requirements engineering, practitioners often grapple with challenges that can impact the clarity and effectiveness of their projects. Here, we delve into some common hurdles and offer practical solutions to navigate these complexities.

Ambiguity and Vagueness: The use of ambiguous or vague language in requirements can be a stumbling block. To overcome this, precision is key. Employ clear and specific terms, and consider using standardized language, such as “shall,” to mitigate any potential misunderstandings.

Overuse of Technical Jargon: In the quest for technical accuracy, an overabundance of jargon can hinder collaboration, particularly with non-technical stakeholders. Striking a balance between technical precision and simplicity is crucial. Consider including a glossary or providing explanations for complex terms to ensure comprehension across the board.

Inadequate Stakeholder Involvement: When key stakeholders aren’t fully engaged, requirements may fall short of capturing crucial user needs. Regular communication is the antidote. Conduct workshops, interviews, or feedback sessions to foster collaboration and integrate diverse perspectives into the requirements.

Evolving Requirements: Projects evolve, and so do requirements. Managing these changes effectively is critical. Implement a robust change management process that involves clear documentation and communication. This ensures that all team members are informed of modifications promptly.

Balancing Flexibility and Specificity: Striking a balance between flexibility for innovation and specificity in requirements is an ongoing challenge. Use terms like “should” to express goals and preferences, allowing room for creative exploration, while employing “shall” for non-negotiable aspects. Clearly delineate between flexible recommendations and strict requirements.

In the journey of overcoming these challenges, certain practical tips can significantly enhance the requirements engineering process:

Collaborative Workshops: Engage all stakeholders in collaborative workshops. This not only aids in defining and refining requirements but also promotes a shared understanding, helping identify potential ambiguities early in the process.

Prototyping and Mockups: Visualizing requirements through prototyping and mockups is a powerful tool. It aids stakeholders, including those with non-technical backgrounds, in grasping the intended functionality and design.

Regular Reviews: Establish a routine review process for requirements within the project team and with stakeholders. This ongoing dialogue helps identify and address ambiguities or changes promptly, maintaining alignment.

Clear Documentation: Maintain documentation that is clear, concise, and well-organized. Clearly define sections for different types of information, facilitating easy navigation and understanding for all readers.

Training and Awareness: Invest in training sessions or awareness programs for the project team on effective requirement writing. This not only improves the overall quality of requirements but also reduces misunderstandings.

Use of Requirement Management Tools: Leverage specialized tools for requirement management to streamline documentation and enhance collaboration. Features like version control and change tracking are valuable assets in effectively managing evolving requirements.

Challenges in Requirements Language Summary

Collaborative Workshops	Conduct collaborative workshops involving all stakeholders to define and refine requirements. This promotes a shared understanding and helps identify potential ambiguities.
Prototyping and Mockups	Use prototyping and mockups to visualize requirements. This helps stakeholders, including non-technical ones, grasp the intended functionality and design.
Regular Reviews	Establish a regular review process for requirements with the project team and stakeholders. This ensures that any ambiguities or changes are identified and addressed promptly.
Clear Documentation	Maintain clear and concise documentation. Ensure that requirements are well-organized, with defined sections for different types of information, making it easier for readers to navigate.
Training and Awareness	Provide training sessions or awareness programs for the project team on effective requirement writing. This can improve the overall quality of requirements and reduce misunderstandings.
Use of Requirement Management Tools	Leverage requirement management tools to streamline the documentation process and enhance collaboration. These tools often include features for version control and change tracking.

By addressing these common challenges and implementing practical solutions, systems engineers can enhance the effectiveness of their requirements engineering processes.

Recommended Further Reading Amazon Books

Case Study: Boeing 787 Dreamliner Project

Boeing’s 787 Dreamliner project was a revolutionary undertaking in the aerospace industry. The company aimed to create a fuel-efficient, long-range aircraft with innovative features, incorporating advanced materials and cutting-edge technology.

One of the critical challenges faced by Boeing was the need to develop a comprehensive set of requirements that would guide the design, manufacturing, and testing of the 787 Dreamliner. The complexity of the project, involving multiple stakeholders, stringent safety regulations, and evolving technological advancements, required meticulous requirement specifications.

Boeing opted to use the term “shall” to denote non-negotiable, contractual obligations in their requirements documentation. For example:

• “The aircraft shall be constructed with lightweight composite materials to achieve fuel efficiency goals.”
• “The avionics system shall comply with international safety standards for commercial aircraft.”

The use of “shall” in Boeing’s requirements played a crucial role in establishing clear and unambiguous guidelines. It helped align the diverse teams working on the project, including engineers, designers, and suppliers, by clearly specifying the essential features and standards that must be met.

1. Regulatory Compliance: The use of “shall” ensured that the Dreamliner’s design and construction adhered to the rigorous safety and performance standards set by aviation authorities worldwide.
2. Supplier Collaboration: By employing precise language, Boeing facilitated effective communication with suppliers, ensuring that every component met the stipulated requirements.
3. Project Transparency: The use of “shall” provided transparency and traceability throughout the project, essential for managing the complexity of a large-scale aerospace endeavor.

The Boeing 787 Dreamliner case study demonstrates how the strategic use of “shall” in requirements engineering contributes to the success of a complex engineering project. It emphasizes the importance of clear, non-negotiable terms in guiding a diverse and collaborative team toward a common goal.

Boeing’s experience with the Dreamliner project underscores the critical role of language in requirements engineering, particularly in industries where safety, performance, and compliance are paramount. The careful selection of terms like “shall” helped set the foundation for the Dreamliner’s success as a groundbreaking aircraft in the aviation industry.

Shall vs Should vs Will vs Must Summary

In summary, the words “shall”, “should”, “will” and “must” have different meanings and implications when used in requirements documents. Here is a table that summarizes the main differences and recommendations:

Word	Meaning	Implication	Verification	Recommendation
Shall	Requirement	Contractually binding	Yes	Use to express requirements
Should	Goal	Not contractually binding	No	Use to express goals or preferences
Will	Fact or intention	Not a requirement	No	Use to express facts or intentions
Must	Requirement or prohibition	Absolute necessity or imperative	Yes	Use with caution, as it may be confused with “shall” or “should”

We trust that this blog post has provided you with clarity on when to utilise ‘shall’, ‘should’, ‘will’, and ‘must’ while crafting excellent requirements. It’s crucial to remember, the selection of appropriate words plays a significant role in conveying your requirements in a clear and unambiguous manner. Furthermore, it aids in preventing any future misunderstandings or disagreements.

If you have any questions or comments, please feel free to leave them below. Thank you for reading and happy systems engineering engineering!

Further Reading and References

1. Construction Specifications Practice Guide, First Edition, CSI, 2011
2. Top 10 Systems Engineering Courses for the new engineer
3. Specifications Language: The Meaning of “Shall,” “Will,” and “Must”, Kevin O’Beirne, PE, FCSI, CCS, CCCA, CDT, 2020
4. Project Delivery Practice Guide, Second Edition, CSI, 2018
5. Best practices for usage of “shall” and “must” when writing requirements, softwareengineering.stackexchange.com, 2013