I received a request to address the correct use of terms when writing requirements.
Here is a question for you and your blog readers: Customers have been known to want to include “non-mandatory” requirements in their specs. (One even referred to them as “non-requirement requirements”.) They use the verbs “should”, “may” and “will”, among others. Some customers do state that such “non-mandatory” requirements will not need to be verified. What is your take on any statement other than a “shall” being referred to, or used, as a requirement?
Using the correct terms in your requirement document
I have seen requirement documents with a variety of terms used: shall, will, should, must, and yes…may. Often the terms are used interchangeably, especially shall and must, with no definition of what either means. The three terms I have seen used most often in requirement documents are “shall”, “will”, and “should’.
The fact is that many international standards, including ISO, use the shall, will, should convention. So, I recommend that you limit your use to these 3 terms in your requirement document. Make sure to define these terms at the beginning of your document so everyone knows exactly what is meant. Another reason you should stick to the shall, will, should convention is that these have attained acceptance in both the international and United States court systems. .
Requirements are complicated enough – we advise that when writing requirements, stick to the basics.
Shall – Requirement: Shall is used to indicate a requirement that is contractually binding, meaning it must be implemented, and its implementation verified. Period! Don’t think of “shall” as a word, but rather as an icon that SCREAMS: “This is a requirement.” If a statement does not contain the word “shall” it is not a requirement.
In know…I know, “shall” is rather stilted and you probably don’t use it that often when talking with your pals, but use it when writing requirements. Remember, we are trying to communicate and it is much easier if we agree on the terms.
Facts or Declaration of Purpose. Will is used to indicate a statement of fact. Will statements are not subject to verification. For example: if I want to tell you something about another system I will use “will”. “The XYZ system will have the timing as defined in an ICD 1234.” Or if I am giving a description of something that exists today, I will use “will”. “This report will contain this data…” In a statement of work (SOW) or task order for a vendor or supplier, I use will to communicate something I will do for or provide to the vendor or supplier.
Should – Goals, non-mandatory provisions. Should is used to indicate a goal which must be addressed by the design team but is not formally verified.
Why include should (goal) statements in your requirement document? Because you may have a very important issue that you want to communicate to the developers, but can’t think of a way to do so in the form of a verifiable requirement. For example, NASA was developing a jet pack called SAFER and one of the requirements read “The SAFER shall not impede crew mobility”. Well anything but a decal will probably impeded crew mobility so how am I going to verify that statement if it is written as a requirement? I can’t. So, now that I recognize this, I change the statement from a requirement “shall” to a goal “should” and then I ask my designers and developers at every subsequent review, “how are you going to design the jet pack so that it does not impeded crew mobility”?
The commercial sector may use goals in their product specs as a way for Marketing to communicate extra “bells and whistles” that could make the product more attractive to the consumer. I have seen some organizations treat goals such that they are expected to be met unless the design team has a good reason for not doing so.
In statements of work (SOW), standards, regulations, process requirement documents that contain requirements on the organization producing a system/product/application “should” is also used to communicate a “best practice” that is recommended if applicable but is not mandatory.
You can also use “should” if you want to communicate design criteria. For example, rather than saying “The system shall minimize life cycle costs” which is not verifiable, you make it a goal using “should” instead of “shall”.
Another use for goals is in minimum/maximum or threshold/goal situations. Example: “ The system shall have a threshold response time of less than or equal to 1.0 seconds, with a goal of less than or equal to 0.25 seconds.” The requirement that must be verified is the first value, however I have communicated to the developer I would like better performance – if it doesn’t have a large impact on cost and schedule. Of course any value in between the threshold and goal is acceptable.
You always want to keep your goals in front. Not buried in the requirements, but in the same specification. Remember, these goals will be part of the design review, and using my examples, at each design review, I will ask the designers what have they done to reduce my life-cycle costs, what have they done to minimize impact on crew mobility, or how close to “Y” were they able to get?
Must – Don’t use must because no one has defined how must is different from shall. Also, shall has held up in court, must has not. Granted, must does sounds stronger, right? I mean, if your boss tells you that you “must” do something, well you are going to do it. But, when writing requirements, keep things simple and just use shall.
If you have any other questions on requirements, feel free to ask your question on our “Ask the Experts” page and we will do our best to provide a timely response.