CAD Mngmt Archives - SolidWorks Legion

Shall vs. Must: Which One Should Be in Use?

In technical standards, is SHALL outdated, or does MUST feel awkward? We explore the arguments from both. The key takeaway? Consistency is not negotiable.

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.

Writing for Engineering Standard Operating Procedures (SOPs)

Good writing practices are essential for engineering SOPs. They ensure clarity, reduction of errors and can save time. But what are good practices?

Good writing practices are essential for engineering SOPs (Standard Operating Procedures). They ensure clarity, reduce errors, and can save time. Clear procedures make processes easier to follow, improve accessibility for all team members, and support compliance with industry standards. Well-written SOPs also enhance professionalism, preserve organizational knowledge, and facilitate collaboration across teams. By prioritizing clear and concise writing, engineering departments can create SOPs that are efficient, reliable, and easy to use.

Clarity

Clarity is paramount. Long sentences can unintentionally become convoluted. The following is an actual statement found in a transcript from a doctor’s dictation.

“The baby was delivered, the cord clamped and cut and handed to the pediatrician, who breathed and cried immediately.”
The Bride of Anguished English by Richard Lederer, p65.

The problems with this quote are numerous. Unless the context is completely understood, the statement is a garbled mess.

Brevity

Keep sentences short. Especially avoid run-on sentences. Additionally, avoid wordiness.

Bad example, “I’m jumping off of the road.” The additional “of” is unnecessary.

Good example, “I’m jumping off the road.”
Do you speak American? by Robert MacNeil and William Cran quoting John Simon, p22

Directness

Instructions should be stated as imperatives. An imperative sentence gives the reader a direct instruction. These sentences begin with an action verb and are followed by the object being acted upon.

Additionally, write in the third-person or even “no-person” perspective.

Recommended, “Fill in all title block fields.”

Not recommended, “All title block fields will be filled in by you.” Really? All of them by me personally?

Not recommended, “Title block fields are filled in.” Wow, when did that happen?

Sometimes imperative sentences cannot be used, such as when there is a task for a particular role. In such cases, use gender-neutral pronouns. “They,” “their,” and “them” may be employed for both plural and singular forms.¹ Avoid the jargon “he/she,” as this can convolute instructions and create other avoidable grammatical issues in subsequent text.

When not using imperative sentences, use the words “shall”, “may” and “should”.

Shall – establishes a requirement
Should – states a recommendation
May – states a suggestion or option

“Should” and “may” are often used interchangeably. For example, in the ASME standards, they mean the same thing.

More recently, the word “must” is sometimes used in place of “shall.” Using modern English, “shall” is well-understood to mean a requirement within a set of instructions. However, “shall” has other meanings that may confuse localization and translation into other languages. That said, “must” is somewhat awkward when used in a set of instructions. The use of either term will be a matter of preference within your organization.

The word “will” may also be used to state a requirement, but only when the responsibility and timeframe are established by context.

Recommended, “Each operator shall be capable of lifting 50lbs.”

Not recommended, “Each operator will be capable of lifting 50lbs.” That’s nice, but when will that be a requirement?

Paragraphs should be kept as short as possible. That means each instruction should be numbered individually within the SOP. If you have multiple instructions for one action, then use sub-numbering.

1. Wash hands before eating.

1.1 Apply soap to hands.

1.2 Rub hands under water for 20 seconds.

1.3 Wipe dry on clean towel.

Other grammar considerations for SOPs

Use present tense. Avoid mixed tenses, especially future and past.

Recommended, “Each part number shall represent only one item.”

Not recommended, “Each part number will be used by only one item.” When will that happen?

Despite what Microsoft Word may suggest in its grammar check, the use of the passive voice is acceptable and sometimes necessary. However, using imperative statements reduces the need for the passive voice.

Acceptable, “Grease may be applied to reduce friction.”

Alternative, “Application of grease is acceptable to reduce friction.”

Imperative, “Apply grease as necessary to reduce friction.”

Avoid jargon. In particular, avoid slashed terms and legal terms, such as “he/she,” “and/or,” and “per se.”

Avoid conversational terms and personal opinions. The following are examples of inappropriate terms that I found in technical documents: “heaven forbid,” “totally,” and “roundabout.”

Lists within instructions

When you need to list several items within one instruction, you may be faced with the dilemma of how to apply commas. If your list is short enough and each item within your list is distinct, you can simply list the items within a sentence and separate them with commas. While the serial comma is now preferred for such lists, the extra comma is traditionally considered unnecessary. That said, if you have a list so long or complex that the serial comma seems necessary for clarity, use bullet points instead.

For this, “Affected departments are Engineering, Quality Control, Research and Development and Manufacturing.”

Use this:

“The following departments are affected:

Engineering

Quality Control

Research and Development

Manufacturing”

Lists that are organized into bullet points are easier to read. They also remove many grammatical issues.

CAD specific considerations

The next article in this series will discuss CAD-specific considerations you may wish to address within your standard operating procedures. This includes the following:

Engineering Roles
CAD environment
Network environment
Software in use
Lifecycle
Modelling methodologies
…and more.

Other resources

As noted in the previous article in this series, this information is an update to my presentation at SOLIDWORKS World 2011. That presentation is not currently available. However, I do have the PowerPoints for a couple of other previous presentations. These are available in the Files area of this blog. Please check them out.

Establishing Engineering Standard Operating Procedures

What do you need to established engineering standard operating procedures (SOPs) within your Engineering organization?

If your organization follows ISO manufacturing standards (e.g., ISO 9000) or plans to, your Engineering department will need Standard Operating Procedures (SOPs) for key tasks. These aren’t about how to ‘Engineer’ but focus on managing documentation and design processes more effectively. SOPs ensure consistency, improve efficiency, and help your team meet compliance requirements without extra headaches. This article builds on my SOLIDWORKS World 2011 presentation and offers updated information to help your team navigate these needs.

The following are examples of procedures that will likely be necessary for your organization.

Drawing Standards SOP – preparing mechanical drawings per Engineering Standards (e.g., ISO 128, ASME Y14.5, BS 8888). This should include instructions on selecting templates, naming conventions, part numbering, filling out title blocks and even preferred drawing view layouts. Model-based Definition may require its own SOP too.
CAD Document Management SOP – processes for organizing, naming, storing, accessing and distributing CAD documents, including guidelines for 3D CAD models and cloud-based tools. This may include instructions on file and model formats, such as creating PDFs of drawings or distributing models as STEP to outside vendors.
Drawing Review and Approval SOP – steps for peer reviews, quality checks and approvals of drawings.
Revision Notation and Control SOP – marking and controlling revisions of drawings.
Template and Symbol Libraries SOP – maintenance and use of standardized templates, symbols, blocks and CAD customizations such as macros and data tables .
Design Review SOP – formal process for review of design and drawings
Engineering Change SOP – steps for initiating and documenting proposed changes to designs and drawings (Engineering Change Request; ECR), then their approval and implementation (Engineering Change Order; ECO), including notification and effectivity for full traceability (Engineering Change Notification; ECN).

For Engineering departments, these procedures should be tailored around their CAD application(s), PDM and PLM systems.

Structure of SOPs

Organizations that have well-documented processes should establish a template for their procedures. There are several elements that most standard operating procedures should include. Each SOP should be use a number-base layout that employs functionality of the chosen wordprocessor. This list of elements should be tailored for the Engineering department. The following is an example of the required (as applicable) elements with a brief explanation.

Title and Document Information
- Title – descriptive and specific to the task or process.
- Document Number – unique identifier for tracking.
- Version or Revision Number – indicates current version.
- Effective Date – the date upon which the document becomes valid.
- Approval Signatures – for validation and compliance.
Purpose – the reason the procedure exists.
Scope – extent to which the procedure applies (the processes and roles are controlled by this document).
Responsibilities – define roles and responsibilities of personnel involved.
Definitions – list and define specialized terms and abbreviations.
Materials, Tools, and Equipment – list of required resources to complete the procedure. Include software applications that are utilized within the process described within this document.
Procedure – actual procedural instructions, often in step-by-step format with clear statements with explanatory diagrams and images. Typically, this will be the bulk of the document.
Troubleshooting – guidance for handling common issues or errors.
References -links to related documents, manuals, or regulations.
Revision History – a table that tracks changes over time with notes on updates.

Once the types of SOPs are established and a structure for the SOPs is agreed upon within your organization, the task of actually writing the procedures comes next. This could mean completely rewriting old procedures or writing new ones. Future articles in this series will address good writing practices for SOPs and specific considerations that cover CAD related needs and an organization’s processes.

Military Precision (Supacat and SolidWorks)

Recently, a DEVELOP3d contributor visited Supacar with an interesting report. Of note is Supacat’s use of SolidWorks on products, including their Coyote truck.

“For the Coyote truck (6×6) we have the following breakdown: Full vehicle drawing pack – 2,200+ drawings (parts and assemblies) consisting of unique 5,500 parts and assemblies, 18,000 individual parts in the bill of materials,” explains Dr Jonathan Farley, Supacat’s principal systems engineer. All of the drawings and assemblies are done in SolidWorks, of which there are 20 seats in-house.

The very detailed article is a facintating read: Military Precision – DEVELOP3D

SolidWorks User Group Network Technical Summit in San Jose, CA on Dec 18, 2012

Some people say the world will end 10 days from now. My bet? We’ll be just fine on December 22, 2012. That in mind, if you are in the Northern California area (or within an hour’s flight) and interested to improve your SolidWorks skill, networking with others professionals, and meeting SolidWorks employees, I recommend you look into attending this year’s SolidWorks User Group Network Technical Summit in Silicon Valley on December 18, 2012.

I’ve written about the benefits of the Technical Summits in the past. SolidWorks employees will be attending this year, along with very helpful presentations. Registration and details are found on the SWUGN site here.

My SolidWorks World 2011 presentation

I’ve first attended SolidWorks World in 2008 in San Diego, CA as a customer. At SolidWorks World 2009 and 2010, I attended as a member of the Press. In 2010, I participated on the panel in the Stump the Chumps II breakout session. My short debut as a co-presenter was less than glorious but not terribly horrible.

At SolidWorks World 2011 in San Antonio, TX, I will be presenting my first breakout session, Establishing CAD standards within SolidWorks environment. The session will be on Monday 24 at 2:45PM (local time), scheduled in room 202 of the convention center. (All sessions may be viewed at the SolidWorks World 2011 website.) My breakout session is one hour long and will discuss the general areas that require documentation which are essential for establishing company CAD standards within an engineering environment that utilizes SolidWorks.

This session will cover as much as I can in one hour. There will be a discussion on procedure writing techniques, important considerations when establishing standards, and the types of documents that should be written. I will offer some specific advice, but the breakout session will focus on the big picture by providing a general road map for creating and maintaining your own CAD standards.

Monday is a busy day for many attendees. Even still, I’m hopefully that many will join me for my breakout session.