Why Using the Correct Requirements Terms Matters
I recently received a request to address the correct use of terms when writing requirements.
“Lou,
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 Requirements Document
I have seen requirement documents with a variety of terms used: shall, will, should, must, and yes… even may. Often, these 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, you 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.
I 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.
'Will' - 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 and 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 be in your requirements 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 impede 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 impede crew mobility”?
Using Goals in Product Specs
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.
Using Goals in SOW’s
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.
Communicating Goals for Designs
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. For 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 and not buried in the requirements, but yet still 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 they have done to reduce my life-cycle costs, and what have they done to minimize impact on crew mobility, or how close to “Y” were they able to get?
'Must' - Is NOT a Requirements Term That Should Be Used
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, you are going to do it. But when writing requirements, keep things simple and just use ‘shall’.
