The first step in delivering a great application is creating a solid design specification document.

Without a complete, unambiguous design specification document, you could be setting yourself up for costly rewrites.

Developers prefer to work with design documents that include sample screen shots, detailed descriptions of each function, database layouts, and report layouts. If there are not enough details it should be a policy to respond in writing with a breathtaking number of questions.

Writing a design specification is more of an art, something to be learned, more than something that can be taught. It is a struggle to come up with one document that fits the needs of both the developers and the business people. Keep in mind that the whole design document the business people won’t understand it all.

That is why there is a need to create two design documents: a broad-based description for the business people and a detailed document for the developers. Some developers want as many details as possible. Others want a broad-based design spec. They just want to know what functions the application needs to perform, and they like to fill in the details themselves.

First, we need to start off the document with a high-level description of the functional design: Basically, here’s what the application is going to do. When the business people sign off on that general description, a second file should be created which will have more details, if necessary, for the developers, and ask for their buy-in.

The extra details aren’t always necessary if the developer has been involved in the process since the initial discussions. Getting the developer involved early on gives him a feel for the business people’s needs and scope of the project from the beginning.

You also want to avoid situations where the developer comes back to a project lead and says, ‘You should have asked me before you told the customer we could do this!’

Developer/PM - Do's and Dont's

• Do not get bogged down in the details.
• Put together a great design specification to provide the road map for the process.
• Meet with development team regularly. Let them know you’re following up on their issues.
• Keep the design specification document updated.
• But don’t jump in and try to do everything yourself.
• Customer sign-offs are a must

Customer/Business People

The external customer has to sign design specification indicating they agree to everything in the document, and there are two reasons for that.

One is to cover your [bases], which is always important. Two, if you sign something, you’re going to read it. I don’t know how many times I’ve handed a design document to a customer who says, ‘Oh yeah, that looks good.’ Then you deliver the application and the customer says, ‘Where’d that come from?’ You say, 'It’s right here in the document,' and the customer says, ‘Well, I never read that thing!’

I think that a great design specification document should be extremely detailed -- down to the level of what each function does and what result is expected after each action.

Details required for QA testing

Quality assurance team should meet with the developers and review the first draft of the design document, line by line.

A detailed design spec can make life easier for everyone involved in quality assurance. For starters, it’s easier to write a test plan from a good design spec. That, in turn, makes the testing easier, particularly if the person doing the testing isn’t the one who wrote the test plan.