Most of engineering is based on physical laws that are easily expressible as simple equations. All the rest of each topic is simply a treatment of details about those principles and how they can be applied to practical use. Consequently, the material can usually be organized in a logical manner so it's easy to learn and remember. Specification writing doesn't work that way; it's a hard subject to teach because it draws on so many diverse topics--project management, engineering practice, law, civics, grammar, word usage, and even philosophy. Hence, the subject matter does not integrate well into an easily comprehensible whole like we're accustomed to dealing with in engineering. No matter how you try to organize it, all you have is a lot of disconnected facts. The correct order of presentation is almost impossible to determine. Becoming familiar with such a body of knowledge through on-the-job experience usually takes a bright person many years, and keeping it all in mind while drafting a document is very difficult, indeed.
In keeping with the nature of the material, this guide is a collection of short articles. It is written by an experienced U.S. Government engineer to an audience of fellow engineers. The intent is to help both newcomers to the field and those who sometimes prepare informal specifications, but don't prepare them often enough to maintain the high levels of knowledge and skill they really need to do the job right. Earlier versions of this guide were embedded in a software package I made for engineers to use while they were actually drafting specifications. This HTML version was adapted from that on-line package so it can reach a larger audience. Since more memory space is available for this version, and the HTML format imposes fewer constraints, the articles have been expanded from their original content. They still, however, specifically addresses the types of errors I have seen repeatedly in drafts of training-device specifications written by Government engineers