Karol Frühauf

Sharing My Doubts on Shall / Should / Will etc.

When shall does not need to be must

I doubt whether it is always useful to include the priority in the wording of a requirement. A requirement expresses a need that a future system is supposed to satisfy. The priority of a requirement is intended to indicate how urgent it is to have the requirement implemented.

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:


  1. A requirement is a statement about a future system.

  2. 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.

  3. 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.

  4. 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:

  1. 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.

  2. 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

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).