Page 27 - Anatomy of a Robot

01_200256_CH01/Bergren 4/17/03 11:23 AM Page 12
12 CHAPTER ONE
In either event, a spec document should include the following:
Description It should describe the system. To do this, just steal the proposal
description. Describe to a general audience what the project is and why it is being
done. In a few paragraphs, try to describe the entire robot. A simple graphic helps
greatly. This section is often a page or two long.
Functional spec The spec should describe how the system should behave. It
should not describe how the system must be designed or built. The design itself is
up to the design engineers. All aspects of the robot’s behavior should be described.
No repetition Do not repeat specifications in multiple sections of the document.
References Cite all sources and specifications that are part of the project by ref-
erences. It is not necessary to repeat any part of a specification that is on file along
with the spec. Use three or so words to describe the cited section and then give the
section number for the cited specification.
Technical suggestions The spec can suggest specific design engineering solu-
tions in situations where the technology is either difficult or the solution is already
known.
Commonality Group common designs together. For example, if several differ-
ent user interfaces will exist, consider a central body of user interface code and
several different interfaces to it.
Unravel the toughest problems first The easier ones will fall into place.
Identify the technical risk points and elaborate on them This is very impor-
tant since the risk items generally have the greatest chance of derailing the proj-
ect. A few words of advice: Get rid of the risk items early in the project. In any
robot project, a few risk items can bust your project wide open. They might
involve the delivery of a prime component, they might involve untested technol-
ogy, or they might involve personnel problems. Whatever is the case, make a plan
to handle the risky aspects of the project first and foremost. Once they are out of
the way, you can proceed with much more assurance and predictability.

WRITING HIGH-LEVEL DESIGN (HLD) DOCS

The design engineers have the responsibility of writing a high-level design (HLD) doc
for the robot. However, it can be skipped at the discretion of the PM. The HLD is typ-
ically between 10 and 20 pages. The PM can schedule the HLD review, distribute the
HLD to reviewers a day ahead of time, and preside over the HLD review meeting. The
HLD is a technical plan showing the way the spec requirements will be implemented in
the actual design. It should serve as the blueprint for the successful implementation of
the final design and the HLD should make it clear how the design will be accomplished.