Once completed, however, this document became the final authority for all questions regarding functionality of what the customer wanted. Although your development organization might not bring you into contact with an end user, you still aren't off the hook for ensuring clear communications and complete functional descriptions. The reason I'm devoting so much time to this nontechnical concept is that I've seen more embedded designs fail due to inadequate communication than inadequate technical expertise. In the case of the microscope, the customer was patient enough to go through the process to ensure we got the design right. Such isn't always the case.
Some customers are under pressures that make that repetitive process impractical.
To see what I mean, consider a situation when a client wanted a design for an antenna-position readout system. Making tradeoffs Once you've finalized a design you're ready to address two issues that, in my mind are inseparable. In an embedded system, hardware and software can't exist without each other. By taking this general approach, you can modify the product's design with only a software change. Over a 3- year development effort the software underwent 49 major changes that caused the program size to triple, but the only hardware change I ever made was to add one wire.