Definition of each change and elucidation of the flow of code. Pictures say a thousand words. Do not type paragraphs of text in a document. 90 percent of documents are never read just because the amount of effort to convey the information is insane. Pictures do speak a thousand words. Compress - its is quality over quantity.

Class diagrams depicting the exact signature of the class indicating all accessors/mutators, methods, members, along with input and output specifications will ensure that a glance will suffice to depict the work that needs to be done. Of course, subtleties like including descriptive (Hungarian Naming Convention) method and member names will make the class diagrams themselves more readable than having to insert notes into your diagrams, which frankly take us back to the problem of wordy documents.

Behavioral modeling is a very complex aspect. From a developer / architect's perspective, process flow diagrams, use case diagrams and flowcharts are no match for what a sequence diagram can do. A sequence diagram depicts Object lifetimes, Order of instantiation and order of invocation, which without any words, depicts how your program will work. Again, this document will not teach you UML. There are a lot of web sites that attempt to teach UML. I learnt from some of the best folks back at Rational, but standards and specifications are subjective. If you and I follow the same standard, we can communicate. So the goal is to ensure that you have a standard, and that all the members on your team adhere to that standard. And if you are going to take the effort to come up with a standard, using the existing UML 2.0 standard should make your task much easier.

Here is a list of artifacts that would greatly benefit design:

• Code Documentation - Tools like Rational SODA or nDoc or Doxygen can actually generate comments right from your code comments into CHM or HTML format. Generate the documentation and put it out on a link on your company's intranet server or development portal. If you dont have one, set one up. The include the link to the documentation in your design document. Dont paste pages of class library definitions in a word document. That is painfully redundant and then when you start emailing stuff around, it thins the line between a bad practice and a crime.
• Class Diagrams and Sequence Diagrams. Both go hand in hand
• E-R diagrams for database artifacts is critical
• Also, make sure that you sufficiently document your error handling and any special enumerations and constants that are specific to your process flow.