5

Engineering Specifications and

Requirements

5.1 Introduction: delivering on a promise

Earlier chapters describe how engineers attempt to capture design work

in text. In particular, Chapter 3 shows how the germ of a design idea
is often recorded in proposal documents. Within these documents, it is
the technical description of the engineers' design intent that provides a
reference point for the drafting of requirements specifications. Promises
need to be converted into deeds. Engineers need to revisit the proposed
solution to ensure the company delivers what was promised and fulfils
its contractual obligations. It may happen that, on returning to the
proposed solution, engineers actually improve on the original design
and find they change it radically. Whatever course they take, the fact
remains that the proposal provides the impetus for writing specifica-
tions that, in turn, specify the product or products that are part of the
solution.
In textual terms, however, there are two fundamental differences
between proposal and specification documents: communicative func-
tion and cost considerations. First, communicative function is a key
consideration; there is no persuasive intent in the writing of specifica-
tions and requirements, whereas persuasion underpins every aspect of
writing in proposals. The solution put forward in a proposal undergoes
a sort of writing metamorphosis that takes place through a series of
writing, design, testing, and manufacture phases. Eventually, the solu-
tion is transformed into something tangible that can be used by the
customer. Using specifications to transform (sometimes vague) ideas
into a physical product is the main purpose of this post-proposal stage,
with functionality being a key concern. Second, specifications and

92
H. E. Sales, Professional Communication in Engineering
© H. E. Sales 2006
 Engineering Specifications and Requirements 93

requirements have financial value and have the potential to generate

income for the company. Proposal writing, on the other hand, is an
expensive activity for any company, let alone those in engineering, and
for the motor, aerospace, and defence industries, the costs are huge.
With proposal writing, a company makes financial outlays on document
production in the full knowledge that it will have to count its losses if
the proposal loses. So, it takes a financial gamble when deciding to bid
for a project, and will deem the money to have been well spent, obvi-
ously, if it wins. Documents that specify the product, on the other hand,
that is, specifications and requirements, are regarded by companies (and
engineers) as having monetary worth, because they receive payments
from the customer when these documents are produced. They earn
income for the company whenever they have been deemed to have
been satisfactorily completed in the eyes of the customer. This is a signi-
ficant consideration indeed for companies, cash-strapped or not. As one
engineer put it: 'These are documents that the customer sees, checks
against criteria, and pays lumps of money for.' In the case of very large
documents, a company may receive payments on completion of each
section.

5.2 What are specifications and requirements?

5.2.1 Clarifying terms

Drafting specifications and requirements is a fundamental engineering
activity. Whether it is a hardware or software system, the engineer
aims to describe its functions and physical features in documents called
specifications or requirements specifications. These are read by the customer
and engineer colleagues concerned with designing, testing, and manu-
facturing the product, providing evidence that the design work, and
all the scientific and mathematical testing that this involves, has been
done, and done properly. Specs, as engineers usually refer to these docu-
ments in their talk, are hefty tomes, often comprising several hundred
pages, their weightiness a reflection of the engineers' weeks of toil spent
specifying in detail every possible feature of the product as clearly and
unambiguously as possible.
Specifications, and the more detailed requirements, are descriptions of a
special technical kind. Put simply, they are an attempt to describe the
design for those who will later use the specifications to convert them
into the product itself. The spec has to be sufficiently precise and detailed
for the product to be built and tested from it alone, and this detail