Specifications must be understood because each is a contract between a programmer and his or her client (according to Carroll Morgan). Although precise specifications tell us how, and abstract ones tell us what, these may not be enough. We also need to explicitly specify and understand why--the purpose of the system and its design considerations. This interesting and well-written but somewhat lengthy paper convincingly argues that the knowledge of the “why” provides a foundation for intellectual manageability of the specification, that is, for understanding the rest.

The paper is based on general systems theory and includes a description of its relevant concepts. Some of them are well known outside software engineering but are still used rather sparingly in information management. These ideas include the need to know a system’s purpose in order to understand that system, to view a system from a high level of abstraction and specifically use a means-ends hierarchy, to explicitly specify the domain, to identify unstated requirements, and so on. (Many “why”s are invariants of the system or its environment, but this is not mentioned.)

The paper includes an extended example of some requirements for an aircraft collision avoidance system. Since the business domain of this system is not always explicitly specified, and the purpose of a system can be much better understood in the context of such a specification, following the example may require discovering the specifier’s assumptions. The general need to specify the purpose, scope, and policies of any system is emphasized in an international standard, the Reference Model of Open Distributed Processing [1], which is, regrettably, not mentioned in the long reference list.