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.