Category: ASME Standards

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.

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.

  1. 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.
  2. Purpose – the reason the procedure exists.
  3. Scope – extent to which the procedure applies (the processes and roles are controlled by this document).
  4. Responsibilities – define roles and responsibilities of personnel involved.
  5. Definitions – list and define specialized terms and abbreviations.
  6. 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.
  7. 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.
  8. Troubleshooting – guidance for handling common issues or errors.
  9. References -links to related documents, manuals, or regulations.
  10. 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.

North Alabama SolidWorks User Group

After my great Nashville visit, I headed on down to Huntsville, AL last week.  I was able to meet with a lot of SOLIDWORKS customers and users.  I presented at the April 2015 meeting of the North Alabama SolidWorks User Group (NASWUG) about the topic of Model Based Definition (MBD), how to apply it within SOLIDWORKS.  I also demonstrated the new SOLIDWORKS MBD product which streamlines SOLIDWORKS for MBD processes and provides 3D PDF output for non-CAD consumption for the purpose of contributing to Technical Data Packages (TDP).


 

There was a lot of great questions by user group meeting attendees about implementation Model Based Definition, the standards that support Model Based Definition (such as MIL-STD-31000), and Product and Manufacturing Information (PMI) solutions available in SOLIDWORKS, such as DimXpert.

Matthew Lorono speaking at NASWUG

I’m glad I had the opportunity to visit Nashville and Huntsville, along with many SOLIDWORKS customers in these areas.  I learned a lot, and I also hope I provided a lot of new information to those interested in MBD and SOLIDWORKS in general.

New Section View Assist tool in SolidWorks used as example of teamwork

I was recently interviewed by Entertainment Engineering, an online magazine that covers technologies used in many types of entertainment devices and events such as movies, concerts, theme and amusement parks, electronic games, etc.  The November 2012 issue focuses on the value of individual contributors and also of teamwork in the design process.  Here’s the kicker, I’m quoted in the issue’s editorial article along side the great Steve Wozniak.  Kinda cool.

The article for which I was specifically interviewed is called Teamwork Improves Section-View Options in SolidWorks 2013, which leads-off a series of interviews with various individuals from all over the engineering discipline.  In my interview, I talk about the new SolidWorks section view functionality (now called Section View Assist) that has a whole new user interface that changes the way section views are created on drawings in CAD.  This includes how I originally developed the concept which was then improved and refined via teamwork within the SolidWorks organization.

Section View Assist replaces the need to first create sketches before being able to create a section view.  Instead, you can directly place cutting line on the original view and have the section view generated automatically.  If you want to use aligned section view, you can add offsets to the cutting line directly in the Section View Assist interface (without the need to draw lines or edit sketches).  Same goes to notch and single offsets.  The new user interface saves time and steps.  The improvement is nearly exponential.  The more complex your cutting line, the quicker you can create it versus old methods using sketches.

How to add a Geometric Tolerance frame to your Sheet Format

**OUTDATED Content: Update–>SOLIDWORKS 2020 now allows you to add Geometric Tolerance and Surface Finish symbols onto your Sheet Formats directly without the following workaround**

SolidWorks Sheet Formats do not support Geometric Tolerance frames.  So, what can be done if you wish to display a frame with your Sheet Format on drawings?

First, a quick review.  SolidWorks has two separate files that serve as the starting point for creating new drawings.  The primary file is the Drawing Template (*.slddot).  Every time you start a new drawing, it must be from an existing Drawing Template.  The template contains all the settings and other information needed for every drawing.  In particular, it uses information from a Sheet Format (*.slddrt) for the border and title block.  Each time you create a new sheet on your drawing, the Sheet Format is directly loaded.  However, neither the Sheet Format or the Drawing Template automatically update existing drawings.  For more information on Sheet Formats and Drawing Templates, see SolidWorks Help.  The tip found in this article is for more advanced users and CAD Administrators that are already familiar with these topics.

Back to the story.  Perhaps your company is moving towards using the model to define your product, but still uses the drawing to established specifications, such as tolerances, general notes, process control dimensions, etc.  Common practice for this scenario is to establish a generic Profile specification on the drawing that is then applied to the model.   But, you cannot store a Geometric Tolerance frame within a Sheet Format.  You won’t likely want to draw your frame using sketches.

Solution? You can have a Sheet Format display a Geometric Tolerance frame that is present on a Drawing Template!  Here’s how.

1.  First, make backup copies of your Sheet Formats and Drawing Templates!  OK, once that is done, open your Drawing Template using File>Open dialog set to Template (*.prtdot; *.asmdot; *.drwdot)

2. Create your Geometric Tolerance frame using the Geometric Tolerance annotation tool.

3. Place your new frame in the lower right corner of your Drawing Template.  Don’t be concerned if it overlaps the border, but it is a good idea to keep it inside the paper space.

4. Create an annotation note (Insert>Annotations>Note…) and place it anywhere on the drawing.

5. While the annotation note is still being edited, click on the Geometric Tolerance frame.  The frame will now appear in the note.  Select OK to accept.

6. Select the new note.

7. Press CTRL-X.  The note should disappear, as it is being cut from the Drawing Template.

8. RMB click on any empty area of the blank paper space and select Edit Sheet Format.  This will take you into the Sheet Format editing mode.

9. Click on the approximate location where you wish the frame to appear and press CTRL-V.  This will insert the note onto the Sheet Format.  Click and drag it to the desired location.

10. RMB click on an empty area of the paper space.  Select Edit Sheet.  This will exit the Sheet Format mode and return you to normal drawing mode.

11. RMB click on the original Geometric Tolerance frame and select Hide.

 

12. Goto File>Save to save your Drawing Template.

13. Goto File>Save Sheet Format to save your Sheet Format.

(14.) Now, if you wish to edit the frame later, simply use View>Hide/Show Annotations.  The hidden frame will appear faded gray.  Select it and it will turn black.  Press ESC to exit the Hide/Show mode.  Edit the frame as your normally would any Geometric Tolerance frame.  When done, hide it again.  You may need to Rebuild to see the update.

Note:  If you open the Sheet Format directly without loading the Drawing Template or if you load the Sheet Format into a drawing created with an older Template, the annotation note containing the frame will be blank.  This is because the information is contained in your new Drawing Template, but the note is in the Sheet Format.

GD&T Feature Control Frame user interface?

Remember this old faithful interface for creating Geometric Tolerance frames (a.k.a, GD&T feature control frames, or GTOL annotations)?

There a new thread on the Drawings forum at SolidWorks Forums asking about how you use this user interface to create Geometric Tolerance Frames.  Your input is very welcome there (and here, if you wish).  What would you do to improve the inferface?

  • When do you use it?
  • How does it work for you?
  • What do you think about the workflow of creating the frame before you place
    it on the sheet?
  • How do you feel about the preview window (and would it be necessary if you
    could just see your frame being modified directly on the sheet)?
  • Do the restrictions within the interface (meant to force you to follow
    GD&T rules) ever prevent you from creating the frame that you need?
  • Have you used the PropertyManager settings that also pop up when you edit an
    existing frame?