The importance of a good structure cannot be overstated. It is essential so that different programmers can understand how their product fits into the whole, and other teams (building interfaces or testing) and later maintainers can understand how the system is structured and where their efforts must be directed. A good design will ensure that all the elements of the structure have a similar style and operation, both visibly to the user, and under the skin to ease the work of the tester or maintainer.

The system probably will change in the future. You need to make sure that the design is sufficiently flexible so you can accommodate likely enhancements without major changes to the design. It is relatively easy to plan for changes and testing, and build assistance for these into the design. Conversely, without a proper structure, re-testing may be almost impossible and future changes very difficult.

The design documentation defines the structure and relationship of the build tasks. It defines the standards and guidelines which the programmers must follow. It explains how the different modules relate together, and how to interface between them. In some cases, you won t want to produce detailed specifications for every program. Instead you can define a template for all the related modules (e.g. all the simple reports), and then just document a few specifics in each case, all in the design documentation. In other cases, there will be complex separate specifications, but the design report...