It's something abstract. It is some "document" that establishes rules to be followed, what is expected of possible implementations. These rules may require some things and prohibit others. It is a formalization of how something should proceed. It's the law. Roughly the recipe.
It's something concrete. It's how it's actually done. It is what exists to be used. It is law enforcement. It's the cake made by someone serving what the recipe says.
It is possible to vary the recipe, but if you modify fundamental points of it, you are hurting the dish and it can no longer receive that name. Obviously in cooking it causes less problem than in computing: P
Relation between them
Of course, if the implementation does not do something that the specification forces you to have, whoever is going to use it, who must be a pattern, you will have problems. If the implementation does something extra that the specification does not prohibit, there will be no problems. But if you're going to use what was created on top of this implementation by taking advantage of the extras, you obviously will not be able to portlet to a different implementation that adheres more strictly to the specification.
In the described context the implementation is being made on top of the specification, complying with all rules established by it. The implementation can, in theory, do anything that is not forbidden by the specification.
Within the rules the implementation can and should do its best to meet the needs of its users.
If the implementation hurts a rule of the specification it can not be considered as adhering to that standard.
The specification may be more detailed or more superficial, giving more rigidity or flexibility to what the implementation can do. It can also give more ambiguity and bring problems. Specification may have bug :).
It's often harder to make a good specification than a good implementation, even though the amount of work can be the reverse.
A bad specification may make it difficult or even impossible to implement a good implementation.
Normally the specification should be simple to understand. The implementation should be good to use.
Some domains work best with an existing clear and formal specification. Others may just be an unnecessary and undesirable complicator.
Plan how you plan to implement is not a specification. At least not in the sense described.
Some implementations are considered as specification. These are informal specifications. There are pros and cons to doing this.
Specification for programming language .