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.
Subject:Re: The GUI shall do... From:Chris Morton <salt -dot- morton -at- gmail -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Tue, 22 Jan 2013 10:00:14 -0800
We are not writing RFCs. Our SOPs are for internal use only, but we must be
able to demonstrate to auditors that 1) we have these docs and 2) each
employee has trained on his/her required subset each year. No auditor
actually reads our SOPs for content.
Instead, I'm calling on our engineers to please write their spec docs using
present tense and to avoid *shall* at all costs!
Formal filings, such as a 510(k) for the FDA, may be different. I doubt it,
though. That's why I'm interested in dredging up that prior thread, because
I do recall once poster commenting on the "requirement" falling out of
favor with the gubmint, too.
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.
See what's new in Doc-To-Help 2012 in a free webcast: