Further Reading — Chapter 33: Writing for Engineering

Annotated, and limited to sources you can actually verify. Tier 1 = landmark or canonical, cited normally. Tier 2 = real, widely-used standards and ideas named without inventing edition numbers, years, or clause numbers. Where a specific standard governs your work, your employer or contract will name it—find out, and read that one.

Start here (Tier 1 — verifiable)

RFC 2119 — Key Words for Use in RFCs to Indicate Requirement Levels (IETF, S. Bradner, 1997). The short, free, foundational document behind §33.3. It defines MUST/SHALL, SHOULD, MAY and their negatives, and it's barely two pages—read the original rather than a summary. It is published by the Internet Engineering Task Force and is freely available at the IETF site (it is part of "Best Current Practice," BCP 14). Even outside internet protocols, it's the reference most teams point to when they write "keywords are to be interpreted per RFC 2119."

RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words (IETF, 2017). A one-idea clarification of RFC 2119 worth knowing: the special, normative meaning applies only when the keywords are in uppercase. Lowercase "must" or "should" is just ordinary English. This is the basis for the chapter's advice to write SHALL/SHOULD/MAY in uppercase when you mean the defined sense. Free at the IETF site.

Requirements and systems engineering (Tier 2 — real standards, named honestly)

IEEE and ISO/IEC/IEEE recommended practices for software and systems requirements. There is a family of standards that govern how to write requirements documents—a recommended practice for software requirements specifications, and joint ISO/IEC/IEEE standards covering systems-and-software requirements engineering and the requirements process. I am deliberately not giving standard numbers or years here, because they're revised and I won't risk citing a wrong one. What's worth knowing: these standards largely codify the disciplines this chapter teaches (atomic, unambiguous, verifiable, traceable requirements with defined obligation levels). When you join an engineering team, ask which standard governs your specifications and read that specific, current edition. The principles will already be familiar from this chapter.

INCOSE (the International Council on Systems Engineering) guidance on writing requirements. INCOSE is a real professional body that publishes practical guidance and a widely-used handbook on systems engineering, including well-regarded material on writing good requirements (the "characteristics of good requirements"—necessary, unambiguous, verifiable, traceable, and so on). A solid, vendor-neutral place to deepen the requirement-quality material in §33.2. Look for their current guides through incose.org rather than a specific edition cited here.

Adjacent craft (Tier 1/2 — already met in this book)

Joseph M. Williams, Style: Lessons in Clarity and Grace (Tier 1). Not an engineering book, but the most useful companion to §33.2's weak-word hunt: Williams's treatment of clarity, of putting the real action in the verb, and of cutting empty words is exactly what turns "operates efficiently across a wide range" into a stated band a thermal chamber can test. Precision in requirements is clarity with a verification method attached.

The procedural-writing sources from Chapter 22 (Tier 1/2). Because manufacturing work instructions (§33.9) are procedural writing at its most demanding, Chapter 22's further reading applies directly here—particularly material on writing testable, operator-proof steps and on the safety-signal-word conventions (the ANSI Z535 family) for placing warnings and cautions. Revisit those for the factory-floor half of this chapter.

How to use this list

If you read only one thing, read RFC 2119 (and its one-page clarifier RFC 8174)—it's short, free, foundational, and you'll use its vocabulary for the rest of your career. For requirement quality beyond obligation keywords, the INCOSE characteristics-of-good-requirements material is the best vendor-neutral next step. For the standards that formally govern your documents, don't trust any number you find secondhand (including any you might half-remember): find out which standard your team or contract actually mandates, and read that current edition. The principles in this chapter are the durable part; the standard numbers are details that change.

A note on the chapter's own honesty rule (the book's three-tier citation discipline): everywhere this chapter mentioned IEEE/ISO/IEC/IEEE or sector standards, it described what they do and told you to find the specific one—it never invented a standard number, edition, or year. Hold any engineering source you read to the same test: a real reference can be located; an invented one cannot.

Back to: Chapter 33 · Key Takeaways · Exercises · Quiz