A general dictionary definition of specification would run something like:
``A specification is a detail of design or materials for work to be undertaken"
For example, in the field of Engineering this might be a set of Technical Drawings, complete with dimensions, tolerances, parts lists and so on. In Britain this type of specification would have to be produced to the British Standard BS308.
As an exercise, you might like to form your own opinion before reading on as to what others have defined a software specification to be. Here then are some of the textbook definitions that have been given in the past:
All these are consistent views of the nature of a specification. Read in isolation, they are simplistic, and to attempt a better answer we must provide some background to the question `What is a Software Specification?'.
In the context of software engineering, there are several acknowledged phases which developers may pass through on route to a final, fully operational implementation, as suggested by the third answer above. The feasibility stage, in fact, is usually the first, in which the question being raised is `does a problem admit a computationally feasible solution?', or more specifically `does a problem allow a computationally feasible solution within the time, money, equipment and any other resource constraints that may be present?'.
Assuming a computational solution is feasible, one has to capture the requirements of the solution. This is a bit like restating the problem, but at this stage it is probably phrased in a language which is problem oriented, and one which the `customers' can understand. If the customers are part of a business enterprise then the requirement phase may involve both a capture of the current system (which could be a payroll, accounting, or bookings system for example) as well as a statement of the new system's requirements. If the customers are the software developers themselves, as is often the case in technical or system software, an explicit requirement phase might not even occur.
The next step, provided the requirements are agreed upon, is to attempt to construct a system model which satisfies these requirements. In the case of a commercial system, the system model may then be an evolution of the old system. The fundamental change here is from a form which is assertive (what you want) to one which is constructive (how you will get it). The problem, initially expressed as a set of requirements, is turned into a solution in the form of a system model. The first model will be necessarily abstract, and will carry through many of the requirements as properties and constraints on the model. Nevertheless, it will embody some commitments to structuring of the final implementation, and include some computational concepts (such as input/output and data flow). In other words, what we have is a top level design.
So what has happened to the Specification? Have we missed out a stage? The answer is that specification is not really a particular stage in software development; eliciting requirements and transforming these into a design may involve `specification' at various stages. Some staged models of software development do include the phases `Requirements Specification' and `Design Specification' to emphasis this point. The requirements refer to needs, the design to models that should satisfy the needs - a specification can be a precise statement of the needs, or even of the model to be constructed to fulfil them.
In this text you may sometimes find the word `definition' used interchangeably with specification. This is not surprising, since a `definition' is something which is supposed to be precise and complete, two of the qualities we desire for software specifications. Also, there must be must be something whole and integrated about a specification - it must be more that just a piecemeal re-statement of the requirements. In essence, it should form a `theory' of which designs are possible models. It should also have a major characteristic of a good theory - one should be able to use it to predict the final system's behaviour. This means that the specification should pin things down that hitherto had been left open, and should throw up incompletenesses in the requirements.
Our discussion has lead to an answer, which, it must be said, is more an ideal than a definition:
A specification is a precise, unambiguous and complete statement of the requirements of a system (or program or process), written in such a way that it can be used to predict how the system will behave.