When introducing the system design process to relative newcomers, it is often a concern that much time is spent on "Requirements" and not "Programming" or otherwise "Building" a system.
After this is carefully explained, the next question often becomes "why are you saying "shall" all the time?"
"It seems too formal or even archaic."
Lets look at the alternatives.
The Internet Society publishes many standards and proposed standards as RFCs (requests for comment) and uses the words should and must.
RFC 2119 provides these definitions, including the use of all-caps:
For various reasons, the negative versions of these definitions are not often used and we do not use them here. The principal reason is that evidence of absence (the widget does not sing) is difficult or impossible to prove.
One of the key purposes of a list of "shall" statements is in demonstrating that the system successfully accomplishes all the requirements in the list. This is proven by testing each requirement. This is the motivation for making requirements simple and testable.
A useful requirement has the property that you easily convert it into a test for compliance, either by demonstration, analysis of measurements, or by observation of some property of the system.
In conversation, "should" has the connotation that there is an option, that somehow you make your intentions clear, try to achieve them, and might quite possibly fail in spite of your best intentions.
"Must" is an imprecation, a directive, an order made with some authority. It is also indicating intent, and the intention describes the future and the next steps. The RFC 2119 definition is less tolerant (it includes "shall" as a synonym) but it is inconsistent with standard English usage which includes "importance".
"Shall" however brooks no opposition, tolerates no excuses and reveals a positive expectation on the inevitability of the outcome.
"Shall" invokes authority and also assumes the feasibility of the statement and capability of the implementor. This is very important to system designers: that feasibility is presumed.
"Shall" is the strongest of the three choices, and is therefore often considered somewhat unfriendly! There are no excuses for missing a shall.
I think this is the reason so few people use this word in conversation.
The legal world has slightly different definitions, and of course this is of interest for composing and interpreting contract language.
California law includes this definition:
“(a) "Shall" means action which is necessary to achieve compliance and no alternative courses of action are acceptable to achieve compliance.” Cal. Code Regs. tit. 2 § 13
Surprisingly, "shall" has some controversial aspects to it in Australian, British and Canadian law. This is called the ABC rule. If you have too much time to spare, search Google for application of the ABC rule in drafting legislation.
The short version is that "shall" is the same as "has a duty to." But the ABC rule holds that legal drafters cannot be trusted to use the word "shall" under any circumstances!
We system designers don't agree, of course.
For use in engineering documents, "shall" seems to be well-defined and has been for a long time. We'll continue to use this in spite of the influences of other groups, like, you know, lawyers.
(You may also find it instructive to ask Google to "define should" and follow the myriad of links that result!)