Should I Use Shall? May I Use Should? Shall I Use May?

I learned in my Technical Writing course that the words “may”, “should”, “can” and “will” are to be avoided at all costs in a requirements document, unless they are in a note or a special section called “Recommendations” or something similar.

However, I had a customer who insisted that this is wrong because he has been using these [forbidden] words in documentation for eternity “and it is all over the Internet”. I asked him how the reader is supposed to know whether it is a requirement, a recommendation, or an option. His answer: At the beginning of the doc he has a table defining “shall”, “should”, and “may” (he doesn’t use “will” or “can”.)

So I did a bit of Internet research and found this quote from the IEEE style manual (quoted here: http://www.ieee802.org/20/email_req/msg00102.html)

The word shall is used to indicate mandatory requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted (shall equals is required to). The use of the word must is deprecated and shall not be used when stating mandatory requirements; must is used only to describe unavoidable situations. The use of the word will is deprecated and shall not be used when stating mandatory requirements; will is only used in statements of fact.

The word should is used to indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain course of action is deprecated but not prohibited (should equals is recommended that

The word may is used to indicate a course of action permissible within the limits of the standard (may equals is permitted).

The word can is used for statements of possibility and capability, whether material, physical, or causal (can equals is able to)."

Furthermore, RFC 2119 “Key words for use in RFCs to Indicate Requirement Levels” Harvard University, 1997 states the proper use of these imperatives. RFC 2119 also states that these words should also be defined at the beginning of the document, just like my customer did.

In his 2009 blog entitled, “You Must Not Write the System  Shall…”, Scott Sehlhorst (a product manager, business architect and business analyst) states:

In English, shall and must mean the same thing – something is mandatory. Should means, roughly “it would be a good idea.” In fact, should is such an ambiguous term, you should never use it in requirements.

NASA’s “Writing Effective Requirements Specifications” has a similar list (“may” and “can” are noticeably absent):

This list presents imperatives in descending order of their strength as a forceful statement of a requirement. The NASA SRS documents that were judged to be the most explicit had the majority of their imperative counts associated with items near the top of this list.

• Shall is usually used to dictate the provision of a functional capability.
• Must or must not is most often used to establish performance requirements or constraints.
• Is required to is often used as an imperative in specifications statements written in the passive voice.
• Are applicable" is normally used to include, by reference, standards or other documentation as an addition to the requirements being specified.
• Responsible for is frequently used as an imperative in requirements documents that are written for systems whose architectures are already defined. As an example, "The XYS function of the ABC subsystem is responsible for responding to PDQ inputs."
• Will is generally used to cite things that the operational or development environment are to provide to the capability being specified. For example, "The building's electrical system will power the XYZ system."
• Should is not frequently used as an imperative in requirement specification statements. However, when it is used, the specifications statement is always found to be very weak. For example, "Within reason, data files should have the same time span to facilitate ease of use and data comparison."

An article printed in TechWR-L in January 2009 (PDF) by Donn Le Vie, Jr. states the following:

Options: A category of words that provide latitude in satisfying the SRS [Software Requirements Specification] statements that contain them. This category of words loosens the SRS, reduces the client's control over the final product, and allows for possible cost and schedule risks. You should avoid using them in your SRS. The options below are listed in the order they are found most often in NASA SRSs

1. Can
2. May
3. Optionally

The Microsoft Manual of Style for Technical Publications 3rd Edition says to use the word “should” to describe a recommendation, but to avoid the phrase “it is recommended”.

So it seems that there might be some debate regarding “can” and “may”, but “should” and “will” seem to be acceptable in requirements documents. What is certain is that the standards (I think) I learned in my Technical Writing course are not universally accepted.

What is your take on this?

---

Comments are most welcome!
Follow on Twitter: @ykarp
Subscribe to Y. Karp? Why Not! or follow on Facebook (see the side-bar).
Add this blog to your RSS feed reader