The Internet Engineering Task Force [1] did a great deal of work to define the modal verbs to be used to express priority of requirements in the standards issued by IETF.
| Modal verb | Explanation |
|---|---|
| MUST REQUIRED SHALL |
Mean that the definition is an absolute requirement of the specification. |
| MUST NOT SHALL NOT |
Mean that the definition is an absolute requirement of the specification. |
| SHOULD RECOMMENDED |
Mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. |
| SHOULD NOT NOT RECOMMENDED |
Mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications must be understood and the case carefully weighed before implementing any behavior described with this label. |
| MAY OPTIONAL |
Mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) |
IEEE standard [2] uses the term “degree of necessity” instead of priority. Instead of modal verbs, values of the requirements attribute “degree of necessity” are defined.
| Attribute value | Explanation |
|---|---|
| Essential | Implies that the software will not be acceptable unless these requirements are provided in an agreed manner. |
| Conditional | Implies that these are requirements that would enhance the software product, but would not make it unacceptable if they are absent. |
| Optional | Implies a class of functions that may or may not be worthwhile. This gives the supplier the opportunity to propose something that exceeds the SRS. |
| Functional requirements should define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs. | |
| These are generally listed as “shall” statements starting with “The system shall...” | |
Of course, this can be applied to requirements other than functional ones too.
I especially like that the IEEE standard recommends use of the modal verb “shall” independently of the degree of necessity. If something is required, then it needs to be done. Therefore, it is natural to use a strong imperative to express a requirement. When (versus if) it needs to be done does not contribute anything to the understanding of the requirement, i.e. does not need to be included in the requirement’s expression.
The point in time when a requirement needs to be implemented can change during a project. If it is included in the expression of the requirement itself, then the requirement’s statement needs to be modified every time the requirement’s degree of necessity changes. This does not make sense to me. There is a good reason why in the agile world the priority is expressed by ranking in the backlog but not in the requirement’s description.
There is one exception. Calls for bids will usually not be maintained during the course of a project, so the degree of necessity of the requirements will not change during the project. In this case the attribute values essential, conditional and optional could be expressed e.g. in modal verbs shall, should and may. This does not mean that requirements or their degree of necessity will not or even must not change during the course of the project, but these changes will be reflected in other documents than the call for bid document.
The official IREB book [3] uses the term “degree of legal obligation” instead of priority / degree of necessity of a requirement and defines modal verbs to be used, but also opens a back door.
| Modal verb | Degree of legal obligation |
|---|---|
| shall | legally obligatory requirements |
| should | urgently recommended requirements |
| will | future requirement |
| Alternatively, the legal obligation of a requirement can be documented by a specific requirement attribute. |
My view in summary:
- A requirement is a statement about a future system.
- The priority or degree of necessity or degree of legal obligation (I will use only degree of necessity from now on) is not a statement about the product but a characteristic of the requirement, needed for planning.
- The two things thus serve different purposes and shall therefore be separated, i.e. the expression of the requirement shall not include its degree of necessity. This shall be managed as an attribute of the requirement or by other mechanisms of planning.
- In order to simplify the handling, the degree of necessity can be included in the expression of the requirement using different modal verbs, provided the degree of necessity does not change (too often). I have so far identified two areas where this applies:
-
Standards
They are revised every 5 years. A clear definition of the modal verbs to express the degree of necessity and their consistent use in the standard’s requirements simplifies the standard document. -
Calls for bids
They are revised rarely or not at all. Again, a clear definition of the modal verbs to express the degree of necessity and their consistent use in the requirements simplifies the call for bid document.
My view can be considered as detailing the IREB definition.
I know that I did not consider all the nuances used in the field to express the degree of necessity. That was not my intention. My intention was to show the different nature of a requirement expression and the requirement’s degree of necessity. I doubt whether the two exceptions cover all situations where the inclusion of degree of necessity in the expression of the requirement is justified by a simplified handling of the requirements document. I am sure the readers of the RE Magazine can help me to get rid of this doubt.
A hint: If you’re interested in the topic you may visit
http://reqexperts.com/blog/2012/10/using-the-correct-terms-shall-will-should/
and read “Using the correct terms – Shall, Will, Should”, posted on: October 9th, 2012 by Lou Wheatcraft with 15 comments.
Karol Frühauf
P.S: Thanks to Oliver Hoeffleur who shared first my doubts and helped me to sharpen them.
References and Literature
- [1] S. Bradner: Request for Comments: 2119, The Internet Engineering Task Force (ITEF), Network Working Group March 1997
- [2] IEEE Std – 830-1998 – IEEE Recommended Practice for Software Requirements Specifications
- [3] Klaus Pohl, Chris Rupp: Requirements Engineering Fundamentals, Rooky Nook, Inc,, 2011, 1. edition, ISBN 98-1-933952-81-9.
Karol Frühauf is co-founder of INFOGEM AG in Switzerland, since 1987 consulting in the field of software project and quality management (http://www.infogem.ch). He worked 12 years for BBC Brown Boveri & Cie and helped since 1987 many companies to improve their processes and products. He co-authored two books and is a frequent speaker, tutor and teacher in the field of software engineering. His main interests are test and quality management and requirements engineering.
He initiated and directs the "Bridge Guard Art / Science Residence Centre" in Štúrovo, Slovakia (http://www.bridgeguard.org).
Comments (9)
I completely agree with what is written in the article. In my courses, I recommend to not codify the degree of bindingness or priority in the requirement's text. This would not support a systematic and efficient RE process. Prioritization should not modify a requirement's content. Priority must be managed in a specific attribute anyway in order to support views, release planning etc. Worst case would be to have the same information in the text and in the attribute, because this invites the risk that the information becomes inconsistent.
As for the negation: I recommend to use a separate section or attribute denominating exclusion. So, the information that a requirement has been discussed but delayed to a later point of time, should be managed, too. But not in the requirements' text neither.
I think that the agile approach is a good example for this: The user story text here does not include such information neither, but instead the user story is prioritized repeatedly and moved up or down in the backlog. We need this flexibility in non-agile projects, too.
Andrea Herrmann
I definitely support the views of the author and commentators that building words into requirements to express importance, liability or urgency is counter-productive. By 'giving commands' it also sets a poor tone of order/waiter between customer and supplier, which makes it more difficult to engage the expertise of the professional. See more comments on this in the section 'The Roles Of Language And Attributes' in my own article, about requirements to buy not make:
http://re-magazine.ireb.org/issues/2015-4-building-the-extreme/it-requirements-when-buying-not-making/
Subject: When shall does not need to be must
Dear RE,
Have you ever used such user requirement templates:
In my opinion, we should only use “shall” or “shall not” when writing textual product requirements and manage a priority attribute for each requirements.
No doubt : the use of other modal verbs seems to be an « old fashion » practice.
Gildas
Absolutely agree with the statements in this article. MoSCoW method for setting priorities to the requirements always seemed a bit risky to me. Even Karl Wiegers talked about it in one of his articles: https://www.batimes.com/karl-wiegers/elements-of-requirements-style-part-1.html
Thanks for the reference to Karl’s article.
Enjoy life where you are (not in Moscow, I guess).
Karol Frühauf
There is an important implied assumption here that I would like to raise and discuss the consequences of.
Namely that the requirements and priority collected and documented are for a single project/organisation.
PLAN TO RE-USE REQUIREMENTS IN OTHER PROJECTS - As a consultant I have found it important to re-use requirements with multiple organisations/projects and support recording multiple solution assessments. E.g. In supporting CRM, Health and other specific areas, there are several major benefits to proper re-use of requirements. That means including an indication of the priority in the wording of individual requirements would be very limiting. Different organisations will have different priorities for the same requirement, and even within the organisation, specific departments and what-if scenarios may have different priorities that it would be useful to evaluate.
HAVE SPECIFIC EXPLICIT PRIORITY ATTRIBUTES - Allow each Organisation/Project/Scenario to specify their own priority 'value' for the requirement.
a. The Priority Value is a Number - A refinement is that instead of just a priority label like: Shall, Must, Should or Will etc, the priority value is a number within a range like 0 to 9 where 0=Not Required and 9=Mandatory / Essential. Specific numbers within that range can be defined as Mandatory, Conditional, Not Required etc and have formatting/icons associated to them to visually highlight the requirements when listed.
b. Priority Value Extended Range - When able to use numbers for the Priority, some requirements are better documented when the actual number required is specified directly. E.g. If need 60 characters for a customer name attribute then the requirement is a question of how many characters are required for a customer name attribute, and it allows 60 'chars' to be recorded as the actual priority value and each solution records the actual maximum number of characters they support. That is more re-usable and much easier to automatically evaluate.
c. Separate Required By Milestone Date attribute - Another refinement is to separately specify the actual 'required by' milestone date for each requirement/scenario. Solutions have their delivery modules with delivery date, and so evaluating requirement level schedule gaps can be an automatic by-product of data already collected and recorded.
In Summary
My doubts were justified. Thanks Alan for pointing out that reuse of requirements is another scenario in which the degree of necessity included in the requirements statement is “in the way”.
You shall have a good time (better than can?)
Karol Frühauf
Thanks for your article. I saw in the past, in a number of company recommendations, the type of gradation you develop in this article. The goal was to settle priority levels among requirements, whatever this may mean in concrete situations.
Having several priority or necessity levels raises additional problems of consistency: you may do A or you may do B.
The other challenge raised by your article is the use of negation. In principle, according to most norms or recommendations, negation should be banned. But, we all know this is not realistic. However, negation raises several deep semantic issues: is 'shall not' the opposite of 'shall' and what does : 'shall not P' mean (where P is any proposition)? what about 'may not P' or 'P is not recommended'? Recommended may also be analyzed as fuzzy, and therefore should be banned as well. etc. Fortunately, humans can accommodate these problems rather efficiently and in a sound way.
Dear Patrick,
thanks for your feedback. Actually, I did not intend to discuss the denotations of the degrees of necessity. I quoted some literature as a kind of introduction. My intentions was to point out the disadvantage of expressing the degree of necessity in the requirement statement. Many of the problems you pointed out would vanish if that is not the case. I advocate to use only the “shall” form and express the degree of necessity as an attribute of the requirement. But I admit that there are cases in which the expression of the degree of necessity in the requirement statement is harmless. I was curious whether I missed one or another such a case.
Have a good time
Karol Frühauf