“In the folklore of systems engineering, there are sayings, “If it isn't testable, it isn't a requirement,” and, “If it is not quantifiable, it is not testable.” I had always tended to subscribe to the particle of wisdom in these sayings. One of the many lessons that I learned from the CATIE experience, however, was that systems engineering had to be able to deal directly and purposively with what are usually considered to be strictly qualitative (unquantifiable) aspect of systems, such as quality of life, for example. The agricultural practices of these small farmers in Central America is such a large part of their lives that to change any part of their agricultural practices might be seen as diminishing their quality of life - even with respect to the color of the beans that the new practices might require. But even if we cannot deal directly with quality of life or user friendliness or enmity/sympathy, we can identify quantifiable figures of merit relating to these qualitative aspects and if we find enough figures of merit and combine them suitably, we might eventually obtain agreement that we have captured the essence of the qualitative aspect, at least as far as this particular set of stakeholders is concerned.”

—  A. Wayne Wymore

Systems Movement: Autobiographical Retrospectives (2004)

Adopted from Wikiquote. Last update June 3, 2021. History

Help us to complete the source, original and additional information

Do you have more details about the quote "In the folklore of systems engineering, there are sayings, “If it isn't testable, it isn't a requirement,” and, “If it …" by A. Wayne Wymore?
A. Wayne Wymore photo
A. Wayne Wymore 13
American mathematician 1927–2011

Related quotes

“A. D. Hall's (1962) classic account of the methodology was based on his experience with the Bell Telephone Laboratories. Hall sees systems as existing in hierarchies. In systems engineering, plans to achieve a general objective must similarly be arranged in a hierarchy, with the systems engineer ensuring the internal consistency and integration of the plans, The methodology itself ensures the optimization of the system of concern with respect to its objectives. This requires a number of steps, the most important being problem definition, choosing objectives, systems synthesis, systems analysis, systems selection, system development, and current engineering. With Hall, the system of concern is usually a physical entity.”

Mike Jackson (1951) systems scientist

Michael C. Jackson (1992) Systems Methodology for the Management Sciences. p. 74; About A.D. Hall (1962)

A. Wayne Wymore photo

“In the minds of many writers systems engineering is synonomous with component selection and interface design; that is, the systems engineer does not design hardware but decides what types of existing hardware shall be coupled and how they shall be coupled. Complete agreement that this function is the essence of systems engineering will not be found here, for, besides the very important function of systems engineering in systems analysis, there is the role played by systems engineering in providing boundary conditions for hardware design.”

A. Wayne Wymore (1927–2011) American mathematician

Source: A Mathematical Theory of Systems Engineering (1967), p. 193.

A. Wayne Wymore photo

“[In the year 1957] I have just returned from an exciting meeting of the American Society for Engineering Education where I heard a paper on the new discipline of systems engineering. It is no longer sufficient for engineers merely to design boxes such as computers with the expectation that they would become components of larger, more complex systems. That is wasteful because frequently the box component is a bad fit in the system and has to be redesigned or worse, can lead to system failure. We must learn how to design large-scale, complex systems from the top down so that the specification for each component is derivable from the requirements for the overall system. We must also take a much larger view of systems. We must design the man-machine interfaces and even the system-society interfaces. Systems engineers must be trained for the design of large-scale, complex, man-machine-social systems.”

A. Wayne Wymore (1927–2011) American mathematician

Systems Movement: Autobiographical Retrospectives (2004)

“Models are used essentially for evaluation and prediction purposes as well as for the analysis and study of the different parts of the system so that the systems engineer or designer may arrive at sound engineering decisions regarding the system design.”

Harold Chestnut (1917–2001) American engineer

Source: Systems Engineering Tools, (1965), p. 113; As cited in: Alberto Ortiz (1992, p. 12-13)

“Within the past ten years there have appeared with increasing frequency books, articles, conferences, and monograms dealing with system engineering, system analysis, system design, the systems approach, the design of systems, system theory, and problems of systems engineering. The number of publications and the stature of their authors does not allow the dismissal of the subject as a passing fad. The breadth of engineering activity involved in even a cursory examination of recent publications is of interest… It is therefore obvious that whatever Systems Engineering may or may not be, it is non-sectarian and encompasses activities that are of concern in all phases of engineering. On the other hand undergraduate college offerings akin to Systems Engineering are rather limited and even graduate programs are not extensive.”

Allen B. Rosenstein (1920–2018) American systems engineers

Source: Systems engineering and Modern Engineering Design (1965), p. 1.

“Software engineering concerns methods and techniques to develop large software systems. The engineering metaphor is used to emphasize a systematic approach to develop systems that satisfy organizational requirements and constraints.”

Hans van Vliet (1949) Dutch computer scientist

Source: Software Engineering: Principles and Practice, 2007, p. 2

“A new concept and a new method were needed. The concept from the engineering standpoint is the evolution of the engineering scientist, i. e., the scientific generalist who maintains a broad outlook. The method is that of the team approach. On large-scale-system problems, teams of scientists and engineers, generalists as well as specialists, exert their joint efforts to find a solution and physically realize it.
We are led to the concept of the system-design team, a small group of engineers or scientists, to lead a large project and organize the system effort. Such men have been variously called engineering scientists, system engineers, system analysts, or large-scale-system designers. The technique has been variously called the systems approach or the team development method. It is toward this man and his teammates that these discussions are directed. With the realization that not enough can be learned in all the required fields to make him a specialist, enough is introduced to make him aware of the language and problems of the specialist. This generalist is a new quantity in the engineering world, and his education must be begun.”

Robert E. Machol (1917–1998) American systems engineer

Source: System Engineering (1957), p. 8

“Synthesis of systems is much more difficult. Here science and engineering begin to take on aspects of art. A systems designer or planner not only must construct systems that work harmoniously individually and in tandem, he must also know a lot about the environment that the system is intended to match. Consideration of environmental factors requires foresight and experience; no one can ever foresee all the variables of importance and a choice of which to include is often a difficult one to make.”

Arthur D. Hall (1925–2006) American electrical engineer

Source: Definition of System, 1956, p. 28

“There are several world view assumptions present in enterprise engineering. The first assumption is that the enterprise can be viewed as a complex system. This is necessary because systems in organizations are systems of organized complexity. Complexity is the result of the multiplicity and intricacy of man’s interaction with other components of the system. Secondly, the enterprise is to be viewed as a system of processes. These processes are engineered both individually and holistically. The final assumption is the use of engineering rigor in transforming the enterprise. The enterprise engineering paradigm views the enterprise as a complex system of processes that can be engineered to accomplish specific organizational objectives. In the Enterprise Engineering paradigm, the enterprise is viewed as a complex system of processes that can be engineered to accomplish specific organizational objectives.”

Donald H. Liles (1947) American engineer

Source: Enterprise modeling within an enterprise engineering framework (1996), p. 993

“As is used in connection with systems engineering, a model is a qualitative or quantitative representation of a process or endeavor that shows the effects of those factors which are significant for the purposes being considered. Modeling is the process of making a model. Although the model may not represent the actual phenomenon in all respects, it does describe the essential inputs, outputs, and internal characteristics, as well as provide an indication of environmental conditions similar to those of actual equipment.”

Harold Chestnut (1917–2001) American engineer

Source: Systems Engineering Tools, (1965), p. 108; As cited in: Alberto Ortiz (1992, p. 13)

Related topics