Should, Shall, May, Can; Key Word Etiquette in Standards


Robert A. Webb, P. E.


Before you read more, please be aware that the following is my personal thoughts on the subject. Other practitioners can have varying viewpoints.

While it would be much easier for technical writers to stick to numbers, one has to also use words to communicate effectively. In this article I refer to "key words" to mean the certain words used in standards and internal practices to establish the requirements, recommendations, and permissions. These words when used properly set a common framework that helps users to concisely know what is expected.

API standards currently contain the following statements at the beginning of each document:

    "shall" denotes a minimum requirement in order to conform to the specification
    "should" denotes a recommendation or that which is advised but not required in order to conform to the specification

I consider what the API says to be a minimum application of key words in standards. It is necessary for API to address things at a high level. However, for internal technical practices more meaning should be given to the key words used in the documents.  Best practice calls for companies to formalize what the words mean for internal standards or in the actual implementation of the industry standards.

Cardinal rule: Always avoid using the word "must".

The word "must" often carries too high of an imperative for general use in standards. It is very unlikely that any use of the word "must" in a standard cannot be replaced with the word "shall". The exception might be in the case of safety standards. I always think of this phrase, "I must breath oxygen to live". So, if what I am trying to convey in the standard meets that imperative level, the word "must" applies. But, I have never found that to be the case.
The Shall-Statement

For real operations, a shall-statement indicates a mandatory requirement. A mandatory requirement requires a written requested wavier from a technical authority to NOT follow the requirement. The written request shall include a technical justification and a risk assessment for NOT following the requirement.   Also the alternate method, procedure, or equipment shall be documented in writing for approval by a technical authority. It should also instigate a management of change process the extent of which is consistent with the time frame. Temporary deviations should be treated differently than permanent (life of facility) deviations. Permanent deviations should be avoided and studied by peer groups to support such extreme outcomes.

Additionally, "shall" statement waivers should be monitored from both a high level (e.g. segment-wide) and a regional level to assure consistency. Excessive use of waivers can be an indication of over stringent requirements that are not achievable due to technology limitations or operational realities.   Excessive waivers may also indicate a lack of commitment to achieving operational excellence via accepted standard practices.

For shall-statement waiver requests within project design or execution, in addition to a technical authority approval, shall require approval from the operational entity who will operate the newly constructed or modified facility. If this person or group has not been identified, a review and majority approval by operational management for like operations shall be obtained.
The Should-Statement

The use of the word "should" indicates a recommendation. Additionally, if there is a recommendation in addition to a requirement, there must be two or more options to achieve the requirement. If there is no justification given for the recommendation, it ends up as only one option to satisfy the requirement. A singular option is equal to the requirement and should be contained in a shall-statement. Also, the recommendation usually contains some language qualifying the recommendation.

Clauses like the following, taken from an internal technical practice, demonstrates the point:

Gas density and energy determination shall be via proportional-to-flow sampling and gas chromatography (GC). Either on-line GC analyzers or composite samplers and lab GC analysis may be used. For installations with greater than 25 MMSCF/DAY, on-line GC analyzers should be consider first.

In the above example the shall-statement sets the requirement (proportional-to-flow sampling and gas chromatography). There is a may-statement to list options.  And, finally there is a should-statement to identify a prime recommendation and criteria.  Please note the above clause is only an example and not an actual recommendation.
The use of "May" and "Can"

As illustrated above the word "may" should be used to convey an allowable option. All the options should be listed in the may-statement. this sets the stage for a should-statement if there is a prime recommended option. If a should-statement is not attached to the may-statement, it indicates that all options are considered equal.

The word "can" is less used in standards.   And, the can-statement is sometimes used mistakenly as a may-statement. For example from the above clause:

Either on-line GC composite samples and lab GC can be used.

My approach is to use a can-statement to convey possible outcomes. It often is used in an informative sense to provide useful information to the user. For example, the following can-statement could be added to the above clause:

The use of online GC for remote and offshore installations can result in increased use of specialist technicians.

As a good rule, if the phrase "is allowed" fits into the sentence, use a may-statement. If the phrase "might cause" fits, use a can-statement.
Conclusion

Although it can seem stringent or knit-picky, using the proper key words in standards improves the conveyance of the exception to the user more effectively. It helps in word search functions and generally when combined with good general writing skills, provides a very effective engineering tool. This article is just a small portion of the subject of effective engineering standards. I have been involved in reviewing, writing, critiquing industry standards and internal technical practices for over 30 years. A poorly written standard leads to design and operational mistakes, internal disputes over interpretations, and unjustified inconsistency throughout an organization. Although it can be difficult to assign value to effective standards, it goes without saying if you are going to write internal standards do it the correct way and it will stand the test of time.

source: You are not allowed to view links. Register or Login