You are on the first page of several describing the electronics design procedure.
For the global picture, see our design method overview.
There will always be some variation of procedure from company to company, but this basic model is used - it has been tested and refined over many years.
It is solid and reliable.
It just works.
For every small rule or side note here, there was a failure. Either a whole project failed, or a PCB did not work, or a day, week or month was wasted. Later, someone went back, and worked out how to make sure it did not happen again - and the procedure improved. You will have to choose which method you use for new projects - whether it will be the text book method or not. It is much more enticing to be able to label a new project as simulated, virtualised, fast-tracked, modularised, concurrent development.
This method is "just old". It doesn't get much press. It just works.
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. If it all seems just too hard, you could try calling AirBorn and speaking to a development engineer. Or, you could just take it a little more light heartedly, to start. It seems that when we are most critical, it is hardest to write out ideas, when we are most creative, we get more than we need. Start off with the creative, then refine your ideas as you proof read.
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, one client application required that the product be continuously monitored as part of a video surveillance frame (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.
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" - but be aware of this when you look at the examples - many of them used to say things like "It would be nice if..."
WIBNI[Bell Labs: Wouldn't It Be Nice If] n. What most requirements documents and specifications consist entirely of. -- From the MIT Jargon directory.
Pohl's Law: Nothing is so good that somebody, somewhere, will not hate it.