Chapter 3: Writing the Project Definition
Constraints: limitations imposed on the design by the client, regula-
tors, or other stakeholders (in some cases, these design constraints
will not apply to the project deliverable).
Users and stakeholders: those who will use, produce, market, install,
maintain, or in other ways interact with the product; also, those in the
larger community who will be affected by the product.
Requirements and specifications: the needs that the users and stake-
holders want the design to fulfill, and the measurable values associ-
ated with those needs. Engineers translate requirements into
specifications as part of the design process.
A project definition goes by a variety of names in the engineering workplace.
“User requirements,” “functional requirements and constraints,” “engineering
specification,” and “the spec” are just a few of these terms.
Whatever it is called, the project definition is a living document
the creation of the design itself. Although common sense may suggest other-
wise, you don’t write the document first and then create the design. Instead,
the document evolves along with your research and testing. The initial version
typically has a first-draft mission statement, a general description of the final
deliverable, perhaps a few client constraints, and some broad user require-
ments, such as “easy to install.” As you learn more about users, your project
definition will become more detailed, specific, and focused. For example, an
early version of a project definition documenting the design of an innovative