Page 160 - Embedded Microprocessor Systems Real World Design

Software specifications can help clear up confusion regarding actual functional-
ity, such as how the operator interface works.

Software Specifications Outline

The following is a generic outline for software specifications:
Overview. A brief description of what the specifications cover.
Related documents. ANSI and IEEE specs. May also include a reference to the
product requirements document.
Description. A brief description of the software and what it does. Typical
sections include:

Operator interface. A detailed description of operator interaction with the
system. How a keypad is used, what screens are displayed, what keys are
locked out in which modes, and so on.
Interfaces to other systems. Includes a description of protocols used for
communication. Proprietary protocols should be spelled out in detail, with
opcodes defined, checksum/CRC methods defined, sizes of data packets
specified, and so on. Spell out things like how word-wide data is
transferred over byte-wide interfaces (LSB first or MSB first?). Standard
protocols (such as TCP/IP) can just be referenced.
Hardware controlkd. This may appear redundant since the hardware
specifications also cover it. However, the software specifications should
detail how the hardware will be controlled. Specific algorithms should be
specified. If the algorithm is very complex, it may be included in an
appendix and referenced here. Assumptions about the hardware should be
included, such as the following examples:
Does the motor controller have hardware protection against shoot-
through when the motor changes direction or must this be done in
software?
Is a software interlock required to prevent two relays from overlapping?
How much time does the software allow for the relay to open before
checking status?
To what state is the hardware assumed to be initialized?
How long is the software-generated reset pulse held?
Will the software need to insure a write recovery time for any hardware
devices?
Interrupt/task priodies. Unique requirements for priorities of interrupts or
tasks should be documented. Nested interrupt requirements should be
specified.

Software Design 141