My opinion – that is an unfortunate choice of terms to be used when writing specifications. You may be “required” to use it, but that doesn’t make it good.

4.3.8 Use of “shall”, “will”, “should” and “may”.
Use “shall” whenever a manual expresses a provision that is binding. Use “should’ and “may” whenever it is necessary to express non-mandatory previsions. “WW maybe used to express a declaration of purpose. It maybe necessary to use “will” in cases where simple futurity is required, e.g. “Power for the meter will be supplied by the ship.

http://sehlhorst.smugmug.com/Other/blog/shenzhen-sign/1180618030_BMHFf-S.jpg

The problem with “must” is that it is very aggressive. That’s Ok as far as talking about “the system must” although it is preferable to state “the system is or does”. Systems are of a nature that they have to do the thing for which they are designed. One would not normally say “the airplane should fly”. Although it can be said as to mouth the words or write them down, the possibility of its use in a specificatin is remote.

Seriously. Is it really going to be the case that someone will deliver an airplane that doesn’t fly and then the manufacturer to respond … “Gee, you didn’t actually tell me that it had to fly!!”

Where “must” runs into a problem is when applied to people and their actions. An instruction might say “you shall cross the street”. It implies that if you are there, then you are to do the crossing. On the other hand the phrase “you must cross the street” not only means that you are required to cross the street regardless of where you are or what you might feel, but it also implies …. “you will bloody well cross the street and I am going to stand here the while with a whip in hand and make sure you do it”.

Being a Canadian and of the older generation, I find that this move to “must” is representive of how today’s society is becoming very authoritative, aggresive and hard. And we seem to be doing this because; (a) there are too many lawyers, and (b) people don’t know how to do a proper translation.

I agree that “must” can sound bossy. I believe you acknowledged that it is unambiguous. Very few people that I’ve met can parse (language / documents / context) as effectively as you demonstrate in your examples.

Anecdotally, I’ve had people fail to parse “shall” and I’ve yet to have someone complain about “must” be too harsh. When documents are potentially going to be consumed by people for whom English is a second language, I’m going to stick to the unambiguous, because it keeps working for me. I do agree with your point, I just see it as the lesser of two evils (when compared to “ambiguity risk”).

Thanks again,
Scott (@sehlhorst on Twitter)

So what if one can get 21/41 for “shall” in the translation matrix?? This may be more idictative of the way in which languages are constructed than with an inherent confusion in the use of the word “shall” in English alone.

The perceived problem with “shall” is related to the associated word “should”. If you google translate the word “should” you get the same result of “devrait” in French as for “shall”. What seems to be happening here is that the translator is selecting the conditional in conjugation. This would be correct as, “shall” does imply a predition of futurity. That is … something SHALL occur IF some other condition prevails. I would grant that this could be used as an illustration of confusion and thus a reason to use “must”. However, I think that all this ignores the importance of context. The words “shall” and “should” have particular meanings with respect to contracting. I don’t believe that there is a confusion within this context which necessitates the use of the word “must”.

… You shall do something and if you don’t then the contract is not fulfilled.

… You should do something, but if you don’t than the contract would still be fulfilled.

This doesn’t show up in translation since only the word is translated, not the context. To simply say that something should be done represents the idea that it would be done. The word “must” gets 41/41 in the matrix because it is emphatic that something must be done regardless of conditions.

I suppose in a way, my main objection to the use of the word “must” is that it is too bossy.

… You shall do something and I expect you to do it.

… You must do something and you bloody well better do it and just to make certain I am going to stand here and watch you do it.

eduard alf

I also find that confusion abounds between Must/Should/etc as ways of stating requirements and Must/Should/etc as a priority system using MoSCoW.

Interesting discussion and I sort of agree with everyone to some extent.

I was raised with a Mil-Std requirements background. We has specific rules:
- shall is compulsory and failure to deliver will kill the project.
- should is a requirement, but we can find a workaround if it is not delivered on first release.
- could is a nice to have we’d like it if there is time and money to spare (yeah, like that ever happens).
- will is a statement of fact with zero cost to deliver (i.e. it already does this).

Since moving into business and a use case centric approach, I now prefer the precondition/postcondition active voice method of writing requirements (i.e. my requirements state what the system does, not what it must do). This had the advantage of removing unnecessary words from the requirement, and priority is tracked with e requirements management tool (as it should be). It is also a nicer way to present your requirements to the tester (IMO).

All functional requirement statements can be written in the form:
‘Upon’ ‘the system’ , within .

For example:
Upon receiving a request to display the menu, the system [shall display | displays] the system menu to the customer within 2 seconds.

Interface is needed when the system interacts with more than one actor, in order to clarify who gets the results (there may be two or more outputs to several actors).
Time limit is required in order to test the requirement.

Translating into MoSCoW terminology, mandatory was “Mo” and non-mandatory was “SoW”, and C was left out of the mix. To my mind, C doesn’t seem like a requirement, just a design consideration, and belongs in a later iteration cycle, during design.

In general relativity, there is the force of attraction (gravity) and repulsion (weak force?). The net effect of these two forces is to establish a field over the system life where at some point the forces are balanced. In between is a borderland, rather than a binary border. In deterining the age of life on Earth, this borderland situation leads various estimates. Whenever you see a distinct binary, try to think in terms of a pair of forces.

Beyond the border issue is the notion of software as a media. A radio signal is a mix of a carrier wave and a (program content) carried wave. Software as a media is code carrying, in an enterprise, business policy. Sadly, the term business rule was hijacked a long time before the distinction between database rules and business rules got clearer. The carrier vs carried paradigm should help.

It is said that programmers abstract away from requirements. This statement is true in that programmers have to think of many things distant from the tasks or activities being enabled at the interface. Again, carrier vs. carried.

We subsequently reverted to everything being a *must*, with the MoSCoW words (along with estimates of effort and value, and affinity to other requirements) helping drive selection for iterations.

Our experience with user stories also led to a more clearly stakeholder-centric first-person present-tense language:
“As a call-centre agent, when the client has confirmed the order, I am prompted with associated products to cross-sell”.

For projects where the first-person nature of this construct didn’t work, we can strip it down a little more:
“When the client has confirmed the order, call-centre agents are prompted with associated products to cross-sell”.
The affirmative nature of the present tense “are” means that we don’t have to say ‘must be able to’. By the same token, when we say “call centre agents cannot override the discount rate for new clients” — we don’t have to say ‘must not be able to’.

Clearly, when the event triggering an activity is not caused by a person, then we typically resort to anthropomorphising the system:
“The document management system alerts owners of all documents left checked out for 24 hours or more”.
While we can shift the focus back onto the stakeholder involved, by redrafting to:
“As a document owner I am alerted when any of my documents are left checked out for 24 hours or more”
– or in the third-person:
“Document owners are alerted when any of their documents are left checked out for 24 hours or more”.
– this doesn’t specify what is doing the alerting. So making it stakeholder-centric is not always the clearest form.