Our embedded software applications usually involve more than one peripheral device. So we like to map out the information flow between devices, and the sequences required. When we talk with potential clients they seem to shudder when they hear the word "documentation". That is quite understandable because someone must pay for the documentation and it is usually the client.

The fact is that good program structure is a result of good embedded system design. Documented designs can be correctly scoped, reviewed, agreed upon, coded much more quickly, and less debugging is required. The bigger the job, the more reason to produce documented software design.

Applications with fewer requirements will have less documentation. Sometimes good commenting and self-commenting code is all that is needed.

Documentation is not something to be submitted to the library of congress, but something that can be referred to when writing about the system to an employee or a customer. Also, when the next software engineer, who may be your employee, comes along in 12 months time to add features to the system, at least some graphical information will be available to describe what was done.

Feature creep can be a design killer. We are not going to address the cost of errors or the cost of design changes in this article, but be aware that this cost can increase exponentially as the project progresses. It may be the difference between a highly successful project and a mediocre one.

We use three primary tools for embedded software design:

1. Data Flow Diagram
2. Flow Chart
3. Sequence Diagram

Each tool produces documentation, which can be extended into a technology transfer document and becomes the final depositary for embedded software project documentation.