Timeline for SHALL vs. MUST in technical documents
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 5, 2021 at 8:46 | comment | added | James K | Actually I think my second answer below is a better answer. | |
| Jan 5, 2021 at 8:25 | comment | added | Elo | I think it's better to use a word like MUST repetitively than changing words. Because the word is used not only for its meaning but as a keyword in case of "quality" documents. User can recognize easily the obligation if we always use the same word for the same case (I think I join @user110774 opinion) | |
| Jan 24, 2019 at 20:11 | comment | added | Adam Tolley | Re opinions vs facts: documents like this: plainlanguage.gov/guidelines/conversational/shall-and-must point to codification of these practices to a factual degree, in which the fact is that 'MUST' is the only unchallenged term to express obligation. This is obviously a narrowly scoped example; but in the US there is guidance and a wealth of legal precedent to prefer 'MUST' over 'SHALL'. | |
| Aug 23, 2018 at 18:46 | comment | added | Ryan Jensen | I feel this answer states opinions a bit too factually; for example, this statement 'The alternatives mentioned in the RFC exist to allow for slightly more natural English avoiding the repetition of the word "must"' is unsubstantiated, and while there is nothing wrong with always using must, their is also no real problem with using shall; the chance of misunderstanding is essentially nil, it is permitted in the RFC, and even assuming the opinion that it sounds worse is generally accepted, as you said, the goal is not to write prose. | |
| Jul 13, 2018 at 7:03 | vote | accept | guest_user | ||
| Jul 12, 2018 at 14:09 | comment | added | guest_user | (I guess you can say we write the requirements for the customer's suppliers, but that would be another topic.) | |
| Jul 12, 2018 at 14:08 | comment | added | guest_user | Thank you for your answer: it makes perfect sense to me. Trying to answer your questions: let's say my company knows about multimedia systems for cars. Enough to say "if you want a radio, a car MUST have speakers". We do not build the speakers nor the multimedia systems, but draft the requirements for one. It is generally expected that cars have at least a radio, and if they follow our concept, they'll have get speakers. But if, say, they deem it too expensive/cumbersome, our "MUST" is worthless. But it cannot be a SHOULD: if they don't have speakers, the rest of the system does not work. | |
| Jul 12, 2018 at 13:50 | history | answered | James K | CC BY-SA 4.0 |