The most deadly thing in software is the concept ... that you are going to specify what you are going to do, and then do it. And that this is where most of our troubles come from. Ross, Garmisch.
What happens is that specifications of software are regarded as functional specifications ... It is my belief that anybody who is responsible for the implementation of a piece of software ... must specify the design, the form. Sharp, Rome.
No matter how precisely you try to specify a system, once you have built it you find it isn't exactly what is wanted. Oestreicher, Rome.
... the admission of shortcomings is the primary condition for improvement. Dijkstra, Garmisch.
Abstract
The notion of “specification” plays a key role in the developing science of computing. It is typically considered to be the keystone in the software development process. However, there is no single, generally agreed meaning of “specification” that bears close scrutiny. Instead there is a variety of different, although partially interlocking and overlapping interpretations of the term.
We catalogue this varietal profusion and attempt to lay bare both the sources and consequences of each major alternative. We attempt to present the full range of possibilities, and the biases inherent in each style of interpretation.
We believe that there is a pressing need for clarification of the meaning of “specification” (and several other important terms), especially in view of the fact that so many practitioners and theoreticians assume, erroneously, that a clear meaning already exists (even though they might disagree as to what it is). In particular, we feel that a more general awareness of the difficulties that currently attach to this key concept may go some way towards bridging (if not actually healing) the rift that currently exists between the engineering and scientific aspects of computing.
This is a preview of subscription content, log in via an institution to check access.
Similar content being viewed by others
References
P. Abrahams (1988), ‘Specifications and Illusions’,CACM 31(5), pp. 480–481.
C. Chang (1990), ‘Let's Stop the Bipolar Drift’,IEEE Software, May 1990, p. 4.
E. Chikofsky and J.H. Cross (1994), ‘Reverse Engineering’, inEncyclopedia of Software Engineering, New York: Wiley, pp. 1077–1084.
E.W. Dijkstra (1975), ‘Correctness Concerns and, Among Other Things, Why They are Resented’,Proc. Internat. Conf. on Reliable Software, SIGPLAN Notices 10(6), pp. 546–550.
E.W. Dijkstra (1989), ‘On the Cruelty of Really Teaching Computing Science’,CACM 32(12), pp. 1398–1404 and p. 1414.
J.H. Fetzer (1988), ‘Program Verification: the Very Idea’,CACM 31(9), pp. 1048–1063.
G. Fischer (1992), ‘Domain-Oriented Design Environments’,Proc. 7 Knowledge-Based Software Engineering Conference, McLean, VA, September, 20th–23rd, pp. 204–213.
S.I. Gallant (1988), ‘Connectionist Expert Systems’,CACM 31(2), pp. 152–169.
A.P. Galton (1993), ‘On the notions of specification and implementation’, in C. Hookway and D. Peterson (eds.),Philosophy and Cognitive Science, Cambridge University Press.
D. Ince (1990), ‘Z and System Specification’, in D. Ince and D. Andrews (eds.),The Software Life Cycle, London: Butterworths, pp. 260–277.
J.C. Knight and N.G. Leveson (1986), ‘An Experimental Evaluation of Independence in Multiversion Programming’,IEEE Transactions on Software Engineering, SE-12(1).
B. Meyer (1985), ‘On Formalism in Specifications’,IEEE Software 2(1), pp. 6–26.
D. Michie (1991), ‘Methodologies from Machine Learning in Data Analysis and Software’,The Computer Journal 34(6), pp. 559–565.
P. Naur, B. Randell and J.N. Buxton (eds.). (1976),Software Engineering Concepts and Techniques, Proceedings of NATO Science Committee sponsored conferences on software engineering, Garmisch, Germany, Oct. 7–11, 1968 and Rome, Italy, Oct. 27–31, 1969. New York: Petrocelli/Charter.
P. Naur (1982), ‘Formalization in Program Development’,Bit 22, pp. 437–453.
D.A. Nelson (1992), ‘Deductive Program Verification (a Practitioner's Commentary)’,Minds and Machines 2, pp. 283–307.
D. Partridge (1986),Artificial Intelligence: Applications in the Future of Software Engineering, Chichester: Ellis Horwood.
D. Partridge and N. Sharkey (1994), ‘Use of Neural Computing in Multi-version Software Reliability’, in F. Redmill and T. Anderson (eds.),Proceedings of the Second Safety-Critical Systems Symposium, London: Springer-Verlag, pp. 224–235.
C.R. Rich and R.C. Waters (1988), ‘Automatic Programming: Myths and Prospects’,IEEE Computer 21(8), pp. 40–51.
W. Swartout and R. Balzer (1983), ‘On the Inevitable Intertwining of Specification and Implementation’,CACM 25(7), pp. 438–440.
R.C. Waters (1989), ‘Programming in the Year 2009’, in Preprints of the Int. Workshop on AI and Software Engineering, Dept. of Computer Science, University of Exeter, pp. 1–5.
Author information
Authors and Affiliations
Rights and permissions
About this article
Cite this article
Partridge, D., Galton, A. The specification of “specification”. Mind Mach 5, 243–255 (1995). https://doi.org/10.1007/BF00974746
Issue Date:
DOI: https://doi.org/10.1007/BF00974746