Page 159 - Embedded Microprocessor Systems Real World Design

occurred. If a problem with the mechanical components or the condition of the
items processed caused a lot of corrections, throughput went down until things
stabilized again. The processes no longer were independent, but that was necessary
to prevent positive feedback.
By now, some readers are pointing out that these two software processes were
not truly independent, and that is true. They were coupled, but only through the
mechanical characteristics of the system, and that kind of problem can be very
difficult to isolate.

Software Specifications

The software specifications tend to be the one document that is never produced
or is produced at the end of the project and in a hurry. This is for several reasons:
1. There is no “customer” for the software specs like there is for the hardware
specifications. The hardware specs are needed in some form so the software can
be written, but there often is no corresponding user for equivalent software
information.
2. The software often is the last part of the project started, and it often starts late.
The software engineers may be late because a previous project ran late, and the
rest of the project may have had changes right up to the very end. Since func-
tional changes often are implemented in software, it is difficult to finish the code
while the project is still in a state of flux.
3. Tools are available that document a software design from flowchart through
release. If you can describe the actual software as you go, why not just use that
for documentation?
Since there often is no downstream “user” for the software specification, what
are the reasons to create one? Who will read it? The following list presents a number
of reasons:
The software specifications serve as an overview of the code for the software
engineer who must maintain it. This is important if the code is maintained by
someone other than the person who wrote it. After a year or so, it will also become
important to the person who wrote the code.
On a multiprogrammer project, software specifications help coordinate the
effort.
Software specifications are useful for design reviews and for checking that the
software functionality matches up with the hardware capability.
Software specifications can uncover oversights and conflicts in the preceding
documents (hardware specs, requirements, and so on).

140 Embedded Microprocessor Systems