TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
> You're preaching to the choir, Anne. I'm looking for the thread regarding
> this, especially as it pertains to the government backing away from this
> anachronistic standard.
> On Tue, Jan 22, 2013 at 9:30 AM, Anne Robotti <arobotti -at- gmail -dot- com> wrote:
> > I personally would fight to the death if anyone tried to make me use it.
> > But that's just me....
> > Anne
> > On Tue, Jan 22, 2013 at 12:25 PM, Chris Morton <salt -dot- morton -at- gmail -dot- com>wrote:
> >> Does anyone remember a thread here sometime last year about the use of
> >> "shall" in documentation (e.g., software GUI specs)?
Audience and purpose, folks ... audience and purpose. For most audiences and purposes, I agree. But for a formal requirements document, you should adhere to the key word usage specs laid out in RFC 2119 (www.ietf.org/rfc/rfc2119.txt). It's not an anachronistic standard, it's a means of avoiding ambiguity.
That said, I'd use MUST and MUST NOT in preference to SHALL and SHALL NOT whenever possible.
Richard G. Combs
Senior Technical Writer
richardDOTcombs AT polycomDOTcom
rgcombs AT gmailDOTcom
See what's new in Doc-To-Help 2012 in a free webcast: