Page 42 - Embedded Microprocessor Systems Real World Design

Input requirements (What size bottles does it use? What sizes of paper
can it handle? How big or how small can the block of steel be that
goes into the input hopper?)
Capacity (How many blocks of steel or bottles or pieces of paper can it
handle at a time?)
Error handling (What happens if the operator puts in too many bottles
or a block of steel that is too heavy? What happens if power goes off
halfway through the process?)
Weight (usually applies only to large or portable products)
Size (Does it have to fit through a standard door or on a standard
elevator? In a standard briefcase?)
Safety requirements (Does it have to operate in standing water with
no danger of electrocution? Does it need a safety mat to stop the
robotic arm when a person steps inside the fence? Are there
rotating mechanisms that must be covered or stopped when a
door is opened? Must the operator be protected from high
temperatures?)
External interfaces (interfaces to external systems, like a 100 base-T
Ethernet interface to a computer network or an IRDA interface to
transfer data to and from a PC)

Note that there may be other requirements as well, such as media requirements,
customer versus field engineer maintenance items, and the like. However, since we
are concentrating on embedded systems, these requirements are outside the scope
of this outline.
Finally, there is an additional type of requirement that deserves mention but that
is outside the scope of this book. These requirements may be called “business
requirements.” These include such things as the requirement that the product have
all the features of competitor’s product X or that certain features be left off so the
product won’t compete with sister product Y. Like all requirements, these are some-
times hard to quanq, but they do filter down to the design requirements at some
point.
In a complex design, it is often useful to include, with each requirement, a
description of what drives that requirement. A requirement for an RS232 serial
interface may be needed because the product must interface to product XYZ. If
product XYZ becomes obsolete, or if another interface is used instead, that require-
ment can be deleted. Similarly, if someone suggests that the I2S232 be removed,
the original requirement to include it can be traced back to its source, and you can
determine whether the requirement is still valid. The connection between require-
ments and their source can be documented in an appendix. As mentioned earlier,
this can be beneficial in finding the real requirements.

System Design 27