Page 17 - Embedded Microprocessor Systems Real World Design

PRODUCT REQUIREMENTS
May be merged into a
single Product Specifkaton
document.
i FUNCTIONAL REQUIREMENTS

ENGINEERING SPECIFICATION
and (Immare will be
one does and how t
One ,or each ~iuopmcBss(y or each -
HARDWARE SPECIFICATIONS

FIRMWARE SPECIFICATIONS V
functional pisca ot f i m Desmtas how
the nwm IS impmed.

TEST SPEC'F'CAT'oNS Derdbes how system will be tested. Test SpecMkns
may also be required at the board or subassembly level.

Figure 1.1
Design Documentation.

System evaluation
Hardware design
Firmware design
Integration
Verification (test)
These steps are not necessarily serial. For example, if there are separate hardware
and software teams, the hardware and firmware design can proceed in parallel. The
process is not always linear-system evaluation may reveal a problem with the
selected processor, which means that step must be repeated. Last, the process is not
always this well divided. The requirements definition and functionality description,
for example, may be merged into a product specification or other customer-
required documents.
Many companies require such product specifications early in the design process.
I will not dwell on that here, as the requirements for this type of document are
specific to the company or the customer for whom the product is intended. Com-
mercial customers, to pick one example, have considerably different requirements
than the Department of Defense. The design and documentation process begins
with the next level of documentation below the product specification: the require-
ments definition.

2 Embedded Mim@rocessm Systems