Specifications Quality: Invest Now!

It is a well know fact that software development projects typically spend 40%-50% of their total effort on avoidable rework. Similarly but not as well know, specification development also spends a significant amount on avoidable rework.

Our objective is to convince you to use Specification Guidelines (SpecGL) by providing reasons of how SpecGL can help you or by appealing to your good conscience, that is, making you feel guilty for not using it.

The Specification Guidelines

helps ensure interoperability,
provides collected wisdom and experience from people like you
improves the specification,
shows how to do it.

SpecGL is for everyone

Specification developers: early understanding of conformance concepts, less rework or scrap means fewer errata, less burn-out of editors,
Implementers: helps to target areas of spec that are of interest, don't need to read entire specification just the parts that you will implement.
End user: gets more choices because there are interoperable solutions, specification is clearer with discernable requirements (e.g., spec for programming an API)
Test Developer: test assertions are identified, conformance is well defined
W3C Members: specifications get developed faster, can implement or use the technology sooner and faster,
W3C as a whole: reputation enhanced, recommendations created faster, cheaper, and with higher quality and reduced maintenance

Using SpecGL pays dividends

It may seem wacky to spend the precious time, but applying SpecGL in every step of the specification writing process will pay off. Early and ongoing application of SpecGL will:

uncover defects (e.g, ambiguity, holes in the specification) sooner, when they are less expensive to fix;
accelerate specification develoment by making the process more efficient and effective;
enable evaluation of the impact of important planning, design, and development decisions on specification testability;
reduce the amount of text redrafting, the number of comments to resolve, time to publication, and the number of errata after publication.

When to use SpecGL

Use SpecGL to develop a quality specification that is useful to the intended users and that is presented in an accurate, clear, complete and unbiased manner. Each guideline contributes to improving the quality of the final specification by leading you through a series of checkpoints.

Using SpecGL in the beginning to get organized: think about the scope, how the technology will be implemented, what needs to conform, ways to subdivide the technology, and ways to allow variation among implementations.
Using SpecGL as a cheat sheet while writing the specification makes sure you haven't forgotten something and for ideas on how to describe something.
Using SpecGL during document preparation as a guide to markup: to aid in navigating the document, to indicate discretionary items, and to call out requirements and test assertions.
Using SpecGL at the end of the writing process to see if you missed anything.

It's easier than you think

The use of standardized approaches, frameworks, and tools can reduce the costs associated with specification development. Over time, we hope to augment the Examples and Techniques with more tools, templates, and examples to help you implement the SpecGL principles faster and/or more easily. We also plan to work with you, as you develop your specifications, in applying the SpecGL.

Others are doing it

We are not alone. Many standards organizations are developing QA documents and incorporating QA practices. To see who these organizations are and what they are doing, we have put together a non-exhaustive list of organizations (loosely selected among those with which W3C has a liaison) called: QA in other standards bodies.