By Brian Terrell

Last week, I promised to continue a series on CodePartners' software development methodology. Over the last 12 years or so, we worked hard to help more than 500 companies use software automation to increase their revenues, decrease their costs, or achieve some other measurable business objective. For example, we helped companies automate so that they could expand into a new market by opening a warehouse in a neighboring state. This touches all three objectives: increased revenues, decreased costs, and the achievement of the objective of opening a distribution center in a new market. A consistent development process helps achieve excellent results, and that process begins with the Requirements Analysis and is followed by the Design Document.

A Design Document takes the Requirements Analysis and expands on the overall goal of narrowing the gap between what the client or prospect knows about their needs and their business and what we know. We need to become familiar with the issues of our client company's business and challenges as quickly as possible. The more we understand, the better we can help. A Design Document removes any doubt of whether or not we are making progress towards this goal. It is one thing to nod my head and say "...yeah, I got it..." and yet another thing to express that in the form of a Design Document.

A Design Document is a technical document. It includes wireframes, which visually demonstrate what the user interface forms should look like. In addition, we'll develop and document the user interface style, which governs the colors, controls and other characteristics over the user interface so that the end user will see consistency throughout the application. Also, the business workflow and database schema should be well developed in the Design Document so that the architectural questions on how the application will meet the objectives expressed in the Requirements Analysis are answered before a developer writes a line of code. The process to be automated, the underlying architecture of how the application will be constructed, and what the user will see...these are the questions a properly written Design Document answers.

Finally, the Design Document represents the raw material for the developers to estimate the time and effort we need to turn the customer's desires, needs, and ideas into a finished product. In fact, the software developers take the Design Document to begin drafting the Statement of Work. Check back in a week or two to learn more about how the Statement of Work builds further on the Requirements Analysis and the Design Document in the CodePartners' software development lifecycle!