![]()
| Notebook section: | Specifications |
| Purpose: | Describe the functional, user interface, and technical interface requirements for your product. |
![]()
The specification documents describe what you are building. It will be used not only to guide the design, but also to provide the baseline for testing the product. Because the final specification is contractual, it cannot be altered without sign-off from all affected parties.
Look at previous projects (notebooks in OMH 250) to get ideas on specs. Here's one good example from Ottobots (2010). Of course, complex projects will have more specs than simple projects.
The draft specification may be more general than the final specification, and
may be altered more freely. The purpose of the draft specification is to provide
a framework for getting the project started. Once a prototype of the project is
in progress, the final specification will be written. The final specification
will be more specific and should be considered contractual. As an example:
Draft: The Zasnot 300 will tolerage high-voltage, short-duration spikes on its
inputs with no damage.
Final: The Zasnot 300 will tolerate electrical inputs on the main sensor
terminals of up to 5,000 V, 100mA for at least 500ms with no damage to any
internal or external components.
The final functional specification is a contractual document.
In your design matrices, several design goals and criteria were stated informally. In this section you will describe these formally in terms of specifications.
For each of the design goals from your original design matrices, plus any more that are appropriate:
Your project will typically have a few dozen specifications. The list of specification should completely describe your product. That is, any product that meets all specifications is considered an acceptable implementation. You do not have to specify issues related to user or technical interfaces in the specification section since they are included separately.
Each specification should be stated in a concise and independent sentence. Number each specification, perhaps using a structured numbering system, and give a one- or two-word title. Use "definite" language, with verbs such as "will" and "shall." Example:
2.1: Wireless Standard: The Superzombie system will have a radio system that
is compliant with the Bluetooth 2.0 standard.
2.2: Wireless Data Rate: The Superzombie system will have a Bluetooth radio
system (see 2.1) that transfers data at a rate of at least 1.0 Mbps.
2.3: Wireless Range: The Superzombie system's radio will connect at or above the
rate specified in 2.2 at a range of 30 meters or greater (open field) at least
80% of the time.
The final UI specification is a contractual document.
Specify how a user will operate your product. For each basic function (some examples: power-on, take samples, move forward) of your product, include the following:
The operation of each function should be described in detail including:
Each function will require 1-3 pages to explain the user interface.
The Technical Interface specification is a contractual document.
Describe the external analog, digital and mechanical interfaces for your product. These include anything that sends/receives analog or digital data to/from your produce to another device. Also included are any situations in which another device or part mechanically interacts with your product.
| Describe communications protocol, including any commands sent over the interface | |
| Describe signal levels for protocol |
| Describe signal characteristics | |
| Describe over-voltage, over-current, etc. protection | |
| Describe any signal conditioning needed |
| Specify how interface works (i.e. how battery cover works) | |
| Describe approximate area needed for cavities/ports/etc. |
![]()
Kevin Bolding October 17, 2011