Nothing frustrates your product expectations as much as an ill-defined or non-existent design specification.
Let's see what happens when you have no real design specification:
Do the developers understand what they're supposed to be building? If a developer is so confident of her or his unique skills, the end result is almost always (in the case of software) sloppy code that frustrates schedulers, defeats testers, and confuses customers. Other than this, there’s no problem…
How can Quality Assurance (QA) testers test a product for which few, if any, real specifications exist? After all, testing is to ensure that the product satisfies the design goals.
How can anyone adequately describe a product developed with poor specifications? This is more critical than who (a manager, developer, or tech writer) writes it or the individual’s writing skills.
Poor Customer Satisfaction
Your enterprise depends upon customers; customers depend upon their ability to use your products. If customers cannot understand how to use your product, they’ll find another that they can use.
Can Tommy Code This?
Remember the example of an arm that I use in my article about Requirements Analysis? The requirements should include:
- There must be a minimum of one appendage, designated “arm,” allowing the body to use an attached “hand”
- The “arm” must be operated independently of, or in concert with, other “arms”
- Each “arm” must permit at least a 90° arc of motion top-to-bottom
- Each “arm” must include two parts joined by a control unit, termed “elbow”
…and so forth.
The design specifications detail how each of these requirements will be fulfilled. An individual requirement may result in hundreds of individual specifications and each specification must be correlated to its unique requirement.
The resulting matrix allows developers, testers, and technical writers to understand the full scope of the design from individual elements to modules to the whole unit.
I help design staffs develop solid, usable, and accurate specifications!