In computer science, formal specifications are mathematically based techniques whose purpose are to help with the implementation of systems and software. They are used to describe a system, to analyze its behavior, and to aid in its design by verifying key properties of interest through rigorous and effective reasoning tools. These specifications are formal in the sense that they have a syntax, their semantics fall within one domain, and they are able to be used to infer useful information.
In each passing decade computer systems have become increasingly more powerful and as a result they have become more impactful to society. Because of this, better techniques are needed to assist in the design and implementation of reliable software. Established engineering disciplines use mathematical analysis as the foundation of creating and validating product design. Formal specifications are one such way to achieve this in software engineering reliability as once predicted. Other methods such as testing are more commonly used to enhance code quality.
Testing finds errors (or bugs) in the implementation. It is best to find these as early as possible because the farther along in a project a bug is found, the more costly it is to fix. The idea with formal specifications is to minimize the creation of such errors. This is done by reducing the ambiguity of informal system requirements. By creating a formal specification, the designers are forced to make a detailed system analysis early on in the project. This analysis will usually reveal errors or inconsistencies that exist in the informal system requirements. As a result the chance of subtle errors being introduced and going undetected in complex software systems is reduced. Finding and correcting these kinds of errors early in the design stage will help to prevent expensive fixes that may arise in the future.
Testing and QA contribute to more than 50% of the total development cost of some projects; through the use of formal specifications certain testing processes may be automated leading to better and more cost-effective testing.
Given such a specification, it is possible to use formal verification techniques to demonstrate that a system design is correct with respect to its specification. This allows incorrect system designs to be revised before any major investments have been made into an actual implementation. Another approach is to use provably correct refinement steps to transform a specification into a design, which is ultimately transformed into an implementation that is correct by construction.
It is important to note that a formal specification is not an implementation, but rather it may be used to develop an implementation. Formal specifications describe what a system should do, not how the system should do it.
A good specification must have some of the following attributes: adequate, internally consistent, unambiguous, complete, satisfied, minimal 
A good specification will have:
- Constructability, manageability and evolvability
- Powerful and efficient analysis
One of the main reasons there is interest in formal specifications is that they will provide an ability to perform proofs on software implementations. These proofs may be used to validate a specification, verify correctness of design, or to prove that a program satisfies a specification.
A design (or implementation) cannot ever be declared “correct” on its own. It can only ever be “correct with respect to a given specification”. Whether the formal specification correctly describes the problem to be solved is a separate issue. It is also a difficult issue to address, since it ultimately concerns the problem constructing abstracted formal representations of an informal concrete problem domain, and such an abstraction step is not amenable to formal proof. However, it is possible to validate a specification by proving “challenge” theorems concerning properties that the specification is expected to exhibit. If correct, these theorems reinforce the specifier's understanding of the specification and its relationship with the underlying problem domain. If not, the specification probably needs to be changed to better reflect the domain understanding of those involved with producing (and implementing) the specification.
Formal methods of software development are not widely used in industry. Most companies do not consider it cost-effective to apply them in their software development processes. This may be for a variety of reasons, some of which are:
- High initial start up cost with low measurable returns
- Limited scope 
- Not cost-effective
- This is not entirely true, by limiting their use to only core parts of critical systems they have shown to be cost-effective
- Low-level ontologies
- Poor guidance
- Poor separation of concerns
- Poor tool feedback
Formal specification techniques have existed in various domains and on various scales for quite some time. Implementations of formal specifications will differ depending on what kind of system they are attempting to model, how they are applied and at what point in the software life cycle they have been introduced. These types of models can be categorized into the following specification paradigms:
- History-based specification 
- behavior based system histories
- assertions are interpreted over time
- State-based Specification 
- behavior based on system states
- series of sequential steps, (e.g. a financial transaction)
- languages such as Z, VDM or B rely on this paradigm 
- Transition-based specification 
- behavior based on transitions from state-to-state of the system
- best used with a reactive system
- languages such as Statecharts, PROMELA, STeP-SPL, RSML or SCR rely on this paradigm 
- Functional specification 
- specify a system as a structure of mathematical functions
- OBJ, ASL, PLUSS, LARCH, HOL or PVS rely on this paradigm 
- Operational Specification 
- early languages such as Paisley, GIST, Petri nets or process algebras rely on this paradigm 
In addition to the above paradigms there are ways to apply certain heuristics to help improve the creation of these specifications. The paper referenced here best discusses heuristics to use when designing a specification. They do so by applying a divide-and-conquer approach.
The Z notation is an example of a leading formal specification language. Others include the Specification Language(VDM-SL) of the Vienna Development Method and the Abstract Machine Notation (AMN) of the B-Method. In the Web services area, formal specification is often used to describe non-functional properties  (Web services Quality of Service).
Some tools are:
For implementation examples, refer to the links in Software Tools section.
- Algebraic specification
- Formal methods
- Specification (technical standard)
- Software engineering
- Specification language
- Hierons, R. M.; Krause, P.; Lüttgen, G.; Simons, A. J. H.; Vilkomir, S.; Woodward, M. R.; Zedan, H.; Bogdanov, K.; Bowen, J. P.; Cleaveland, R.; Derrick, J.; Dick, J.; Gheorghe, M.; Harman, M.; Kapoor, K. (2009). "Using formal specifications to support testing". ACM Computing Surveys 41 (2): 1. doi:10.1145/1459352.1459354.
- Gaudel, M. -C. (1994). "Formal specification techniques". Proceedings of 16th International Conference on Software Engineering. pp. 223–223. doi:10.1109/ICSE.1994.296781. ISBN 0-8186-5855-X.
- Lamsweerde, A. V. (2000). "Formal specification". Proceedings of the conference on the future of Software engineering - ICSE '00. p. 147. doi:10.1145/336512.336546. ISBN 1581132530.
- Sommerville, Ian (2009). "Formal Specification". Software Engineering. Retrieved 3 February 2013.
- Nummenmaa, Timo; Tiensuu, Aleksi; Berki, Eleni; Mikkonen, Tommi; Kuittinen, Jussi; Kultima, Annakaisa (4 August 2011). "Supporting agile development by facilitating natural user interaction with executable formal specifications". ACM SIGSOFT Software Engineering Notes 36 (4): 1–10. doi:10.1145/1988997.2003643.
- van der Poll, John A.; Paula Kotze (2002). "What design heuristics may enhance the utility of a formal specification?". Proceedings of the 2002 annual research conference of the South African institute of computer scientists and information technologists on Enablement through technology. SAICSIT '02: 179–194.
- S-Cube Knowledge Model: Formal Specification