The Specification
The specification starts as a collection of ideas that describe a device or product. The specification, at the start of the design process, is balanced by the incoming test procedure at the end of the design process. The specification states what was ordered, the incoming test procedure checks that it was delivered.
Pulling together a good specification can be a bit of an art, but try starting with a loose spec - a list of ideas - then tightening up.
A good method, when dealing with professional electronics people, is to describe what a device must do, but only suggest how it may be done - this leaves the way open for the electronics people to find better ways of implementing your idea.
Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity. -- George S. Patton, "War As I Knew It", 1947
Specifications go through two phases, in the first phase they describe the product as desired, in the second phase they describe the product as required. It would be nice if the second phase was always the same as the first - but often its just not practical! The desired, or draft, specification should list separately the features that are must-haves, and the features that are bells and whistles. The production specification, with input from the electronics designer, describes the product as it is required to be produced.
Final specifications should be objective, and not terribly much open to interpretation. Where it is necessary, you should state quantitive values. For instance, if an LED is used as just an indicator on a product, it would be normal to specify just the colour, and perhaps the size. In contrast, recently one client application required that the product be continuously monitored by video camera (as an audit trail). Ideally in that application, it would be appropriate to specify the minimum indicator light output in millicandelas, and the viewing angle, so the camera could photograph the indicator correctly. For practicality, it might be better to determine these in prototype test, however, - so they would become part of the production spec, not the prototype spec.
- WIBNI
- [Bell Labs: Wouldn't It Be Nice If] n. What most requirements documents and specifications consist entirely of. -- From the MIT Jargon directory.
The production specification may occasionally have optional features in it, that can be implemented by firmware change, modification or addition of circuitry, but generally it is a contract document of what can be delivered for a certain price.
Most specifications evolve from the "desired" to the "required" - be aware of this when you look at the examples - many of them used to say things like "It would be nice if..."
Specifications are helpful, not just necessary! 
The specification for your new design is critical to its success. It provides the key document that ensures you get what you want from the design process. It provides a future reference document to describe your product. It provides a starting point for any future enhancements you want to make to your product. The specificiation forces you to commit to paper and prioritize your requirements, and establishes fixed goals for your research and development subcontractor. Review your spec carefully - It is easy enough to be misunderstood when dealing with something as technical as an electronic design.
Pohl's Law: Nothing is so good that somebody, somewhere, will not hate it. 
Design method
Write spec
Specifications
Circuit