In a strict sense, we must know what a problem is before we can solve it.

For design projects

we require a clear reason for solving a problem, the needs, and a clear measure of when the
solution is satisfactory: the specifications. If you cannot understand the needs, it is almost
impossible to develop a useful set of specifications. If the specifications are vague and
undefined, the end of the project is a moving target that may never occur. The common
mistake at this phase is to expedite the process by leaving a few things loosely defined that
you will figure out later. Do not leave unresolved specifications.
Needs arise from a number of sources including:
Incremental improvements to existing designs
Replacements for existing designs
Speculative design

Existing designs are the result of imperfect processes. Each design includes imperfect
decisions that allow future improvement. A design in use may be adequate or need changes,
providing a motivation for subsequent design projects. Speculative designs use an open-
ended process of discovery for estimating design needs, as shown in Figure 1.8. Many of the
formal tools used in this process are within the domain of other disciplines such as
marketing and sales. Reduce the needs to a clear list of testable items, regardless of the
source of the need. Develop the detailed design specification to satisfy the customer needs.
Acceptance testing verifies that the end product meets the specification, signaling the end
of the project. Unclear specifications often delay the project completion.

It can be helpful to put the needs list on a spreadsheet with the final specifications with the
intention of refining these to specific values later. Needs typically fall into one of three
categories: (1) minimum needs, (2) assumed needs, and (3) unrecognized needs. Stated, or
minimum, needs are standard and new features that the customer considers important. For
a car, this would mean seating and dashboard electronics. Assumed needs include basic
operation, safety, and reliability. For a car this would mean the ability to drive. Customers
have unrecognized needs, such as voltage levels or compression ratios. Sometimes
customer needs include detailed specifications. Customers can provide numbers and details
used directly, or indirectly, in specification development. Customers commonly suggest
specification values that exceed the minimum required because they do not trust the design
process. However, without care these inflated values could become the requirements for the
project.

Compare the needs and specifications to verify that each need is addressed. Each of the
needs should lead to a detailed specification. Eliminate or modify specifications that do not
address a need. For unquantifiable needs ask How will I know when I have satisfied the
need? This will be very important when you want the customer to accept the design, and
pay for the work. The project expenses, and effort, will not end cleanly without a clear
specification-based acceptance process.

Although the functional requirements may contain details, it is too early to consider these as
final. Frame the design details as (1) required, (2) constraints, and (3) objectives. When the
process is complete each of these should result in a numerical value for specific acceptance
tests.

Design objectives can be clarified as a set of basic requirements and hopeful outcomes,
subject to realistic constraints. Design objectives and functional requirements are what the
design should strive for. It is best to define the ideal and acceptable values. The danger is
that when not clearly defined, the design specifications will be below or above the
requirements. Examples of well-defined objectives include the following:
Cost between $100.00 and $120.00
Provide a maximum power from 50 to 75 KW
 A maximum speed of 100 to 150 m/s
Heating time between 40 and 60 s
Design constraints are firm limits that must be met for the design to be acceptable.
Examples of these are listed below. These can be specified by the customer or by the nature
of the problem, limitations of the fabrication processes, or technology.
Must be delivered by June 15
Carcinogen levels below 10 ppm
Surface temperature below 50C
Cycle times below 3 seconds
Power levels above 5 W
A data transmission rate above 5 Mbaud

The needs worksheet shown in Figure 1.9 can be used to guide the specification
development process. These columns can be added to a specifications spreadsheet to
consolidate documents. The best source of specification details is existing designs. When
these dont exist it may be necessary to do some early conceptual design. When converting
needs to specification, approaches to consider include the following:
Find similar designs from the past, present, or future.
Examine each of the objectives and constraints and find methods for implementation.
Identify components or OEM (original equipment manufacturer) modules.
Find sources for standard components.
Determine what capabilities exist for fabrication and skills.
Ask Who can do things not possible in house?
Meeting with customers, users, or others.
Study target groups.
Locate applicable standards, e.g., SAE, IEEE, ASTM, FCC, FDA, UL, CSA, CE, BIFMA,
AGMA, JIC.
Research regulations and governing bodies, e.g., NHTSA, FCC, FDA.
Perform benchmarking with competitive designs.
ldentify technologically challenging features, e.g., Is it new? Have others used it? For
how long?

The process of defining the specifications is critical to the success of the project. A clear set
of specifications that can be measured and tested without ambiguity is ideal; anything less
may lead to problems. The following are just some of the issues that can arise when the
specifications are less than precise:
That is not what we asked for. The customer rejects the final design. This occurs when
specific acceptance tests are not defined.
We asked for feature X. A customer asks for additional features after the design work
begins. If not detailed in the specifications they have a valid argument. When this
happens it is called feature creep.
It doesnt meet quality standards. Unclear measurements can be contested and delay
the final acceptance.
We are willing to compromise. To end projects sooner the customer might be willing to
compromise on agreed specifications.

For each of the specifications, you should consider the questions in the following list. If it is
impossible to clarify a specification then it must be managed carefully. A good strategy is to
review the arbitrary specifications often with the customer and seek early approval, before
the conclusion of the project. This is especially true for requirements such as aesthetics,
user interfaces, manufacturing processes, reliability, and packaging. Consider the design of
a new computer mouse. Some of the specifications are exact, while the comfort
specification is hard to quantify. The designers should try to get the customer to give final
approval for the comfort of the mouse early in the detailed design process. The following
questions can be used to explore the specifications:
Is the specification measurable?
How will the specification be measured?
Are there formal tests that can be used?
How will the customer see that the design specifications will be met?
How many ways can the specifications be interpreted?
What are the failure criteria?
Are the numerical values and ranges clear, with units?
What are the tolerances?
How will acceptance criteria be measured? Safety, usability, etc.
How can we manage feature creep?
Can some of the specifications be made optional? If not, consider using a performance
bonus.
Are there standard tests available for a specification?

A sample spreadsheet for final specifications is shown in Figure 1.10. It emphasizes a

concrete list of specifications that will ultimately be approved by the project team and the
customer. Once approved, the list will act as a contractual agreement about acceptable
deliverables. As mentioned before, anything not clearly written will lead to confusion,
disagreement, delays, and extra costs.

Once the specifications are set, the design team can move forward with the selection of
design concepts and detailed design. Ideally the following will apply: (1) the specifications
are accepted by the project team and customer, (2) the project team will have a clear
understanding of the work required, and (3) the customer will have a clear understanding of
what they will receive. If anyone wants to change the specification, a formal process can be
used to review the changes and adjust the time and budget as needed. Failure to adhere to
the specifications results in feature creep, a common and critical problem that occurs when
specifications are poorly written or dont exist. After this phase the addition or change of any
specification will result in delays and increased costs. So regardless of how small a change
is, it will normally take longer than required, add complexity to debugging and testing, and
have unintended consequences. In other words, agreeing to add features is like giving away
profit. Look for awin-win situation where the customer gets what they want in exchange for
fair compensation.

The robot design example continues in Figure 1.11, when Hugh sends a draft of the robot
specifications to Ian. The specifications were developed by comparing robot kits available on
the Internet. The specifications include two motors, rubber tires, tank steering, plastic body,
domed top, and a 10 cm diameter body. The vague specifications are to avoid the walls, to
trace a logo, and to have logos printed on the sides. The specifications do not contain much
detail and may lead to problems later. The customer might want tasteful logos but Hugh
envisions large and bright. The logo it traces on the floor might be an out-of-date version.
These would be excellent reasons to refuse delivery of the product. Listing the target price
of $6.25 is a risky commitment before the conceptual and embodiment work has been done.