Background: I speak from the viewpoint of roughly thirty years experience, almost all of it in the defense industry (except for two years in telecom, at Nortel Networks).
Definition: A requirement is something that you are required to verify. You may verify by analysis, by demonstration, by test, by mathematical proof, or some other approved way, but you absolutely must verify that your product meets that requirement. If your product doesn't meet that requirement, or if you have not PROVEN that your product meets the requirement, you aren't done.
In the defense industry, at least, a statement in a requirements specification is considered to be a requirement if and only if it uses the word "shall". There are no exceptions whatsoever to this rule. If it said "shall", it was a requirement, if it didn't, it wasn't. Period. End of sentence, end of paragraph, end of chapter, end of book.
This makes it VERY easy to decide whether a particular statement in a requirements specification is or is not something that must be tested, or otherwise verified.
RFC2119 formalized terms of art long used for writing RFCs. At the time the original RFCs were written, long before RFC2119 was penned, the original RFC writers, who were very familiar with defense industry specification conventions, were trying very hard to avoid appearing as though they were writing requirements specifications for the net as a whole. The very name, "Request For Comments", was chosen for that specific reason, to avoid dictating to the other researchers. (Herding cats is a lot easier than herding researchers.) Hence they carefully avoided using the word "shall", and used "must" instead. The idea was the same: if you wanted to write e.g. a Telnet client, and claim it conformed to the Telnet RFCs, you were required to comply with the "must" statements.
During my short stint in telecom, I did have to read RFCs, and I did have to read and write non-RFC requirements specifications. The RFCs all used "must" to denote requirements. The requirements specifications all used "shall" for that purpose.
If I were in your shoes, and writing non-RFC requirements specifications, I'd use "shall", and only "shall", to denote requirements and only requirements, for the reasons described above. Similarly, if you're writing RFCs, use the RFC 2119 language, and incorporate RFC 2119 in your RFC as the other guy described.