Learn the key pieces of web development that occur long before any coding takes place. This article will explain five essential software development deliverables that ensure the release meets everyone's expectations: the site map, the requirements document, the functional specification, the technical specification and the test plan. Without these deliverables, you add enormous risk to all but the simplest web applications.

Site Map
This document guides the entire process. Microsoft Visio provides an ample set of tools to draw the relationships among all web pages and see the overall structure of the website quickly. This picture-oriented document helps the software developer and the customer identify missing modules or those that may be excluded from a project that has grown too large. This is an important document which the customer must review and approve. The graphics team will use this to identify all of the unique compositions they will create when they design the page layouts. The Project Manager uses this document to construct a schedule for the site build. The developers use this document to scope out the functionality of the web application.

Requirements Document
This document is a brief summary which simply states "what" the application must do to fulfill the need that demanded its creation. This document contains nothing about "how" the needs are fulfilled. This high level approach helps the team define the project scope and itemizes future enhancements to the web application. This document is written in terms of the business problem and how the web application proposes to solve it, therefore it ought to be easily understood by the customer. It's important for the customer to review and approve this deliverable.

Functional Specification
This document implements the previously defined requirements document. It is technology agnostic, in that the specific programming language or hardware is not defined. When properly authored, programmers using competing technologies such as Microsoft .Net and Java ought to have sufficient knowledge to build the application from the same document. For example, one document in this functional design series may describe how a user account management page ought to function. It will identify the fields (required and optional) on the web page, and the buttons used to invoke actions like insert, update and delete. It does not discuss how the functions are implemented in Microsoft .Net assemblies or Enterprise Java Beans. Therefore, this document must be reviewed and approved by the customer before any programming takes place.

Technical Specification
This is where the rubber meets the road. This document implements the functional specification. If a question about a business rule erupts at this level, the author must go back to the functional design document. This document should not define any business rules, only "how" those business rules will be implemented in a programming language. Senior level programmers with sufficient experience will author this blue print that identifies how the application will be constructed. Less experienced programmers implement these plans under the guidance of senior staff, helping reduce the cost of software development. Unlike other deliverables, this document may not be reviewed by the customer, unless they have a technical background in the specific programming language. It's much more efficient to author a technical specification in Microsoft Word, review it with the programming team and make iterative revisions than the alternative of diving into the code and not knowing quite exactly where you're headed. All carpenters and home improvement aficionados have heard the old adage "Measure twice and cut once."

Test Plan
The test plan is the most often overlooked deliverable. The test plan identifies specific examples of how the business rules will be tested. Admittedly, it is quite a chore to author the test plan, but the risks of not creating this deliverable are numerous. Suppose you spend X number of hours testing the software application without a test plan prior to its deployment. During that time, you've tried every test could think of, however nothing was documented. Then suppose in 6 months time, you make a small, yet significant enhancement to the application. You are now in the position of having to remember the original tests. Add employee turnover to this mix and you'd wish you had spent the time early on to document how the application is tested. This has the beneficial side effect of enabling a customer review process to verify all appropriate business rule tests will be executed.

There is a sufficient case for creating these documents that are essential to the software development process. Without this plan, a project has no method of measuring progress. Adhering to this plan will help maintain expectations of feature sets, cost and release dates.