Editorial 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.

Getting ready for the new year

It’s that time of year again. You know, the end. 2012 had a lot of changes in my life which happen to coincide with changes in SolidWorks in various forms for various reasons, some of which I control, much of which has nothing to do with me whatsoever.

I moved from California and from industry to take a job as a Definition Product Manager for SolidWorks drawings In Massachusetts. As I write this, I’m snowed into my home, or at least my car is. I can get outside and leave a trail of 2 foot deep holes anytime I want. I just won’t get to anywhere useful very quickly. Contrary to popular conceptions, there is snow in California. The difference is that the snow is limited to the hills and mountains. Great for skiing and for going about your daily life without weather getting in the way very often at all. I will say that I prefer to be walking about in light snow rather than light rain. It’s the blizzards that are annoying.

Surprize, suprize, the world didn’t end 5 days ago. The next prediction for the end of the world has already been floating around and was being promoted in the weeks leading up to December 21, 2012. Sir Isaac Newton predicted the end of things to be 2060 based on his interpretation of Bible prophesy. We cannot get more creditable than that! Here’s some others: Yup, there’s others.

2012 was particularly busy for me, with all the changes and the fairly new job. Can you believe that I’ve already been in Massachusetts about 1 and a half years? Still seems like yesterday. A very special Thank You goes to my wife for being a good sport and indulging me in this grand change.

I do have a prediction for 2013. It will continue to be very busy for me. There’s a lot of cool stuff going on right now. I’m very proud of my role in SolidWorks 2013, eDrawings for iPad, and eDrawing Pro for iPad; not to mention all the new stuff planned for 2013. Keep an eye out at SolidWorks World 2013.

A Candidates’ Market Emerges, or Maybe It Always Has Been

Article by Rob Romaine, president of MRINetwork. Republished with permission of The Chatham Group, an MRI company. The statements expressed in this article are those of the original author and do not necessarily reflect the opinion of SolidWorks Legion or its authors.

No one seems to question the connection between unemployment, the employment market, and the economy. They are often used almost interchangeably. Yet, the three are different, and right now, they are in disparate places.

May saw a significant slowdown in the number of jobs being added to the workforce as the declines in the unemployment rate, which began early this year, came to a halt. The general economy, which a few months earlier had been showing signs of growing faster than expected, has failed to impress. The talent market, however, is such a different story that it seems counterintuitive.

In a recent survey of MRINetwork recruiters, more than half (54 percent) characterized the current market as candidate-driven. In fact, 52 percent of respondents noted an increase in the number and competitiveness of counteroffers in the last six months.

“Successful companies are frugal. They don’t throw money around just because they can and when they do begin making counteroffers, especially the kind we’ve seen recently, there is a reason for it,” says Rob Romaine, president of MRINetwork. “Employers who have had to conduct major searches over the last year understand better than anyone the cost and difficulty associated with finding top candidates today. When top talent resigns, employers are finding it easier to counteroffer, even if it falls outside their traditional pay grade for a role.”

In the survey, recruiters noted companies that never use counteroffers or even have explicit policies against them are making offers. Some are just monetary-recruiters report seeing as much as a 40-percent increase in base pay-while others focus on non-monetary issues.

“Compensation always plays a role when talent changes positions. But the last few years have been hard on corporate cultures as cost-cutting measures have trimmed back many, if not most, of the perks that defined great workplaces a decade ago,” says Romaine. “Not only is improving the workplace environment important for retention but also for recruitment. If a candidate sees a drab, low energy office in an interview, it’s going to take a substantially larger offer to lure them away than a bright and active office.”

What turns the act of recruiting from a science into an art form is the ability to nurture that sense of attraction and excitement for a position that will entice a great employee with a steady job to resign and take a new opportunity. If the hiring process is drawn out, that excitement will wane.

“On average, we are seeing employers take more than five weeks from a candidate’s first interview until an offer is made,” says Romaine. “After more than a month, what started as an exciting opportunity becomes a nerve-wracking process that has thrown the candidate’s future into limbo.”

Companies should not be fooled by a cool economy or a stubbornly high unemployment rate into thinking that it is an employer’s market.

“At the same time, when push comes to shove, for top talent, it always is a candidate-driven market,” notes Romaine. “Today we are seeing a tighter market for top talent than perhaps is typical. But in truth, top performers are sought after regardless of the economic cycle.”

To what extent should a company comply with ASME standards on their drawings?

Some time ago, a visitor to SolidWorks Legion asked something similar to this: Now that we decided to use them, to what extent should my company comply with the ASME standards on our drawings versus our own internal rules?

That is a complex and difficult question. Purist will say, “Follow the standard exactly! Otherwise, why have a standard at all?” Internal traditionalists will say, “We already have a way that works for us. Why change what works?”

The answer, in my opinion, is in the middle. ASME Y14.100-2004 paragraph 1.1 states that the ASME standard establishes essential requirements for the creation and revision of drawings and BOMs. However, paragraph 1.2 then allows for “tailoring” of the standard to exclude unnecessary requirements. Though this is not an explicit statement that allows outright customization, it does provide a crack in the door that may be used to justify such customization of the standard. It is important to note that the ASME standard does not take the place of internal standards; it forms their foundation. The ASME standard still leaves options open for individual companies to define for themselves.

In a company’s internal drafting standard, I recommend including the statement, “Exclude from practice any portions of any standards (e.g., ASME Y14.100) that differ from instructions within this document.” This formalizes the effort to employ exceptions to the ASME standard. However, this must be used with caution.

One area that is a good case for exceptions is in how a company might handle BOMs within the context of a PLM. In such cases, it is often considered bad practice to list BOMs in two places (on the drawing and within the PLM). It may be advantageous to store and control the BOM within the PLM, rather than on the drawing. ASME does not address this. However, as long as the PLM displays the BOM in a manner consistent with the intent of ASME, I don’t personally see any issue with relying solely on that PLM for BOMs. The internal drafting standard should address such exceptions to ASME.

An area that is bad for exceptions is in the non-standard use of established symbols or abbreviations. This is because the symbols and abbreviations are already defined by the ASME standards. For example, if a company allows GD&T symbols to be used in a way that is not defined by ASME Y14.5-2009, a manufacturing vendor will not know how to properly interpret the custom use of the symbology. ASME does not allow ambiguity on drawings. However, if a company wishes to continue the use of a few of its own custom symbols and abbreviations, these need to be fully defined on each drawing or in an internal document that is referenced by the drawing.

In my opinion, this is the bottom line: leverage the ASME standards to save time and work (both in the creation and interpretation of drawings). Try to adhere to ASME as much as possible. Allow deviations that are necessary, but clearly state such exceptions within the company’s drafting standard or on the drawing itself (whichever works best for the situation).

My road to becoming a presenter at SolidWorks World

I have now been to four SolidWorks World conferences. My first was in 2008. As with most attendees, my first time was overwelming. So much information is packed into such a short time frame. There are three general sessions and up to 11 opportunities to learn in breakout sessions.

The real value in SolidWorks World are those breakout sessions. Nowhere else is it possible to learn from first hand interaction about so many different SolidWorks related topics in one place. Yet, the topics aren’t just about SolidWorks itself. One of the most helpful sessions I’ve attended was about how CAD can work within an FDA regulated environment.

This inspired me. I wanted to present my own breakout sessions to share my knowledge. What could I talk about? Well, I know drawings very well. In 2008, I submitted my first presentation proposal on drawings for SolidWorks World 2009. It was rejected.

In the meantime, I started presenting locally at the SolidWorks User Group meetings. I did two presentations (written about here and here) that covered SolidWorks World 2008 at the Tri-Valley SolidWorks User Group and the Silicon Valley SolidWorks User Group.

I also started presenting at the SolidWorks User Group Network Technical Summits. In Los Angeles, CA in 2008, I gave a presentation on advanced drawing tips and tricks. In San Jose, CA in 2010, I gave another well received presentation on advanced SolidWorks customization techniques. If someone cannot make it to SolidWorks World, I recommend attending a Technical Summit when is in their area.

I didn’t submit any breakout session proposals for SolidWorks World 2010. It turns out that I ended up being a co-presenter of sorts for the Stump the Chumps II breakout session. Jeff Mirisola organized this presentation. My role was small, but this was my debut on a breakout session stage at SolidWorks World.

I was again inspired to submit my own breakout session proposals for SolidWorks World 2011. To my delight, both of my proposals were accepted. However, I soon realized that my time would be limited again. I had to make the hard decision to withdraw one of my proposals. This allowed me to focus on making sure my one presentation was high quality. My presentation was Establishing CAD standards within a SolidWorks Environment, written about here. (I’ll talk more about the content of my presentation at a later time.)

My presentation was well received. I was approached by many individuals over the next two days at SolidWorks World 2011 to thank me for the presentation. This was an unexpected bonus that made the whole endeavour very rewarding. I’ve given back to the same community that has benefited my growth so much. I hope that I will be able to give two presentations at SolidWorks World 2012!