Whilst every project and every client is different, I am convinced there are general principles for both design and documentation that can be applied to any project. The only differences will be the emphasis each receives as dictated by the project specifics.

1. Start with a Product Specification. You need to write down right from the start the product functional and performance requirements. If nothing else, in Jan's case that defines what version 0.1 is supposed to be. This document can be subject to changes reflected in its issues number and the changes can be clearly defined in the document itself.

2. Divide the project into stages. Each stage must have defined goals. Each stage should have a project plan which defines what needs to be done to achieve the stated goals, how long it will take to achieve, the resources needed and any inputs needed from the client. Give the client a copy so he knows what to expect and when and also what his responsibilities are.

3. Use a Day Book for each project. Write down all your technical thoughts, calculations, circuit diagrams, code fragments, test results etc in it. Never hand it to the client. The day book is a Design Document.

4. Write a Design Specification. This is the design response to the Product Specification. It says how the design will achieve the functional and performance requirements.

5. Write a Test Specification. This says how you are going to verify that the design meets the requirements.

6. Document the details of the design as they occur. Much of this will already exist in the Day Book but with software this means, as Erik says, in the code itself.

I have never met a client that did not appreciate a professional approach as outlined above.

I still use a Day Book even though I am now retired.

Ian