1.M. Alford, "Structuring the dialog between system and software engineers," in Proc. 15th Southeastern Symp. System Theory, 1983, pp. 348-351 presents an approach for performing the iterative process of system design in terms of a structured dialog between systems and component engineers.

2.T. H. Athey, Systematic Systems Approach: An Integrated Method for Solving Systems Problems. Englewood Cliffs, NJ: Prentice-Hall, 1982 presents an integrated methodology for solving complex systems problems. This methodology is based on the "univer sal aspects of systems" and will aid system engineers in developing their problem-solving abilities.

3.N. R. Augustine, Augustine's Laws. New York: Amer. Inst. Aeronaut. Astronaut., 1983 sets forth "laws" which are "dedicated to the proposition that, with a better understanding of the history of past programs, one need only selectively repeat histor y in the future." In addition to providing valuable insight into problems encountered in previous system development efforts, this book is highly entertaining.

4.J. A. Baird, "How can systems engineers do systems engineering?" IEEE Tram. Aerosp. Electron. Syst., pp. 405-407, Mar. 1971 asks three questions: "What is expected of systems engineers?" "What is not expected of systems engineers?" and "What jobs c an systems engineers do and what can't they do?" One of the first steps in the system engineering process is to define the boundaries of the proposed system. Baird attempts to do this for systems engineers.

5.J. S. Baumgartner, Systems Management. Washington, DC: Bureau of National Affairs, 1979 is a collection of writings providing insight into the broad spectrum of systems management. An appreciation for the problems facing system engineering managers will help system engineers in their day-to-day design activities.

6.W. R. Beam. Command, Control and Communications Systems Engineering. New York: McGraw-Hill, 1989.

7.J. A. Bent, Applied Cost and Schedule Control. New York: Marcel Dekker, 1982 has a practical approach that will assist system engineers with limited background in cost and schedule control techniques to develop the required understanding of these e ssential concerns.

8.B. S. Blanchard and W. J. Fabrycky; Systems Engineering and Analysis. Englewood Cliffs, NJ:Prentice-Hall, 1981.

9.F. P. Brooks, Jr. The Mythical Man Month. New York:Addison-Wesley, 1982.

10.G. J. Chambers, "What is a systems engineer?" IEEE Tram. Syst., Man, Cybern., vol. SMC-15, pp. 517-521, July/Aug. 1985 presents an explanation of the functions typically performed by systems engineers in the military-industrial environment of the 1 980's. The knowledges, skills, and abilities required are examined and means for acquiring these are described.

11.P. Checkland. Systems Thinking, Systems Practice. New York:John Wiley & Sons, 1981.

12.C. W. Churchman. The Design of Inquiring Systems. New York:Basic Books, 1971.

13.K. B. De Greene, "Large technology-based systems and the need for paradigm shift," Technological Forecasting and Social Change, vol. 39, 349-362, 1991.

14.F. E. Emery (ed.). Systems Thinking (vols. 1 & 2). New York:Penquin Books, 1981.

15.R. W. House, "A morphology of technical innovation as a process," in Proc. Int. Conf. Cybernetics and Society, 1979 presents a comprehensive review of the elements of the technological innovation process. This morphology can help system engineers t o diagnose or prevent problems in the technological innovation process.

16.G. J. Klir; Architecture of System Problem Solving. New York:Plenum Press, 1985.

17.H. Ledgard, "Programmers: The amateur vs. the professional," Abacus, vol. 2, pp. 29-35, Summer 1985 provides valuable insights for system engineers who must interact with computer programmers for the first time.

18.T. Levitt, "Creativity is not enough," Harvard Business Rev., vol. 41, pp. 72-83, May/June 1963 is addressed to business managers but offers valuable advice to system engineers. It stresses the need "to distinguish between the relatively easy proces s of being creative in the abstract and the infinitely more difficult process of being innovationist in the concrete."

19.B. W. Mar, and R. N. Palmer. "Does civil engineering need system engineering?" J. of Professional Issues in Engineering, vol. 115, no. 1, 45-52, January 1989.

20.L. L. McLaughlin, "Multiple cooperating for systems engineering," in Proceedings, IEEE 1989 International Conference on Systems Engineering, 191-195, 1989.

21.Open Systems Group; Systems Behavior (3rd. ed.). New York:Harper & Row, 1981.

22.J. D. Palmer, "Large scale systems: Systems, man, and cybernetics overview," IEEE Tram. Automat. Contr., vol. AC-28, pp. 653-659, June 1983 is an overview of some of the major areas of activity in the field of large-scale systems and provides an ex cellent model for the development of a system engineer's learning plan. Forty-four references are provided in six areas: general, input-output-economic models, public system methodologies, imperative structural modeling, transportation systems, and man-ma chine systems.

23.H. Petrosk, To Engineer is Human: The Role of Failure in Successful Design. New York: St. Martin's Press, 1985 explains how dramatic engineering failure can occur and presents examples of such failures from throughout the history of man-made struct ures and systems. The Preface states that "to understand what engineering is and what engineers do is to understand how failures can happen and how they can contribute more than successes to advance - technology."

24.R. M. Pirsig, Zen and the Art of Motorcycle Maintenance. New York: Bantam, 1974 is a quality book about quality. A true appreciation for the values advanced by Pirsig would help system engineers in their efforts to design quality into new systems.

25.W. R. Rouse; and K. R. Boff. System Design: Behavioral Perspectives on Designers, Tools, and Organizations. New York:North-Holland, 1987.

26.A. P. Sage, Methodology for Large-Scale Systems. New York: McGraw-Hill, 1977 presents methodologies pertinent to the solution of complex technological and societal systems engineering problems.

27.H. Simon, The Sciences of the Artificial, 2nd ed. Cambridge, MA: MIT Press, 1981 concerns the thesis that systems (and other phenomena) are "artificial" in that "they are as they are only because of being molded, by goals or purposes, to [their] en vironment." An understanding of the concepts presented will help system engineers to develop an understanding for the "science of design."

28.T. C. Taylor (see entry B-Taylor).

29.G. Vickers. Human Systems are Different. New York:Harper & Row, 1983.

30.B. Wilson, Systems: Concepts, Methodologies, and Application. New York: Wiley, 1984 attempts to develop and clarify the concept of systems. It addresses the transfer of intellectual ideas, problem solving, and the relationship between theory and pr actice.

31.R. I. Winner, J. P. Pennell, H. E. Bertrand, and M. M. G. Slusarczuk. The Role of Concurrent Engineering in Weapons Systems Acquisition. IDA Report R-338, Institute for Defense Analysis, 1988.

1.R. W. Bailey. Human Performance: A Guide for System Designers. Englewood Cliffs, NJ:Prentice-Hall, 1982.

2.H. R. Booher (ed.). MANPRINT: An Approach to Systems Integration. New York:Van Nostrand Reinhold, 1990.

3.H. E. Price (See entry H-Price ).

4.R. Rubinstein and H. Hersh, The Human Factor: Designing Computer Systems for People. Burlington, MA: Digital Press, 1984 an easy-to-read book, will help system engineers develop an awareness of the importance of "user-centered design."

5.D. R. Towill, "Man-machine interaction in aerospace control systems," Radio Electron. Eng., vol. 50, pp. 447-458, Sept. 1980 emphasizes that optimizing the performance of man-machine systems is an interdisciplinary activity. He argues that the syst em engineering task of bringing together all the products and skills needed to optimize the performance of the man-machine system is not well understood. Towill brings together the constituent components of such systems in such a manner as to provide a fi rm foundation for the "systems engineering" aspect of design.

6.W. E. Woodson. Human Factors Design Handbook. New York:McGraw-Hill, 1981.

1.B. S. Dhillon. Life Cycle Costing. New York:Gordon and Breach Science Publishers, 1989

2.R. B. Fuld, "The fiction of function allocation," Ergonomics in Design, January 1992, pp. 20-24.

3.T. P. Hall, "Systems life cycle model," J. Syst. Manag., pp. 29-31, Apr. 1980 summarizes the sequence of a system's life cycle (system engineering, Phase 6).

4.T. M. Loughney, "Design-to-cost-A new perspective," Logistics Spectrum, pp. 16-20, Winter 1984 explains the relationship between design to cost and life cycle cost analysis. Discussion is centered around Department of Defense Directive, DODD 4345.3 , Design to Cost.

5.Michaels, Jack V., and William P. Wood. Design to Cost. New York:John Wiley & Sons, 1989. provides an excellent overall text on the subject. However, the index leaves a lot to be desired as it appears to not have been updated for the final version of the text.

6.Nielsen, J., "Traditional dialogue design applied to modern user interfaces," Comm. of the ACM, Vol. 33, No. 10, October 1990, pp. 109-118 presents several examples showing that principles for designing usable dialogues are just as important for mo dern graphical user interfaces as they are for traditional text-based interfaces.

7.T. L. Regulinski and Y. P. Gupta, "Reliability cost estimation: Managerial perspectives," IEEE Trans. Rel. , vol. R-32, pp. 276-281, Aug. 1981 discusses selected sources of uncertainties associated with reliability related life cycle costs.

8.L. L. Taylor, "Systems engineering and the total system life cost," in Proc. Int. Conf. Systems, Man, and Cybernetics, vol. 2. New York: IEEE Press, 1983, pp. 1198-1201 promotes the use of systems engineering to minimize total system life cost (TSL C). A comprehensive understanding of the concept of TSLC is essential prior to the accomplishment of system engineering, Phase 6.

1.B. S. Blanchard, "Maintainability engineering, system engineering, logistics support," Logistics Spectrum , vol. 6, pp. 18-26, Spring 1972 provides basic information essential for an understanding of maintainability principles, how maintainability integrates into system engineering and integrated logistics support, and the necessary emphasis on maintainability characteristics in product design.

2.J. de Corlieu, "Equipment availability and logistics principles," in Proc. 1977 Annu. Reliability and Maintainability Symp., pp. 462-466 investigates new approaches to logistics problems starting from the basic reason for logistics, states several principles and makes assumptions which simplify mathematical models. It is an excellent introductory essay.

3.C. L. Hwang, F. A. Tillman, and M. H. Lee (See entry O-Hwang).

4.R. Jager, "A systematic approach to designing for testabllity,' in 1984 Proc. Annu. Reliability and Maintainability Symp., pp. 520-524, 1984 presents a systematic approach to designing for all maintenance levels and an integrated maintenance concep t.

5.J. V. Jones. Integrated Logistics Support Handbook. Blue Ridge Summit, PA:Tab Books, 1987.

6.M. L. Locks, "System reliability analysis: A tutorial" Microelectron. Rel., vol. 18, pp. 335-345, 1978 is a tutorial in two parts. Part 1 addresses the logical concepts of reliability analysis and Part 2 discusses probability calculations based on the principles presented in Part 1. The information presented is essential for a thorough understanding of the goals of reliability and maintainability engineering.

1.A. Chapanis, "Men, machines, and models," American Psychologist, vol. XVI, no. 3, 113-131, March 1961.

2.B. L. Chapman, A. T. Bahill, and A. W. Wymore. Engineering Modeling and Design. Boca Raton, FL:CRC Press, 1992.

3.J. Gruhl, "Model validation," in Proc. Int. Conf. Cybernetics and Society, 1979, pp. 536-541 presents discussions and examples of a number of techniques that can be useful in making assessments of model validity.

4.C. J. Koomen, "Reducing model complexity in system design," in Proc. Int. Conf. Cybernetics and Society , 1979, pp. 830-833 considers the meaning of complexity in relation to system design and discusses principles of complexity reduction.

5.G. A. Mihram, "The modeling process," IEEE Tram. Syst., Man, Cybern., pp. 621-629, Nov. 1972 presents a taxonomy of 24 model categories and, in a discussion of the scientific method and the modeling process, indicates the evaluations pertinent to t he selection of a modeling medium appropriate to a particular systems study.

6.G.R. Mosard, "Modeling in systems analysis," Eng. Manag. Int., vol. 3, pp. 85-90, 1985 describes modeling in the context of systems analysis and discusses the implications of modeling with respect to systems engineering (and other disciplines).

7.H. Muller-Merbach, "Model design based on the systems approach," J. Operation Res. Soc., vol. 34, pp. 739-751, Aug. 1983 presents a systems approach supporting interdisciplinary in that it encourages participation of non-mathematicians in the model design process.

8.E. B. Roberts, "On modelling," Technological Forecasting Social Change, vol. 9, pp. 231-238, 1976 is a tutorial addressing building models, choosing a modeling approach, testing and validity checking of models, and using models.

9.A. R. Teasdale, "Methodology of modeling," Electra Tech, vol. 78, pp. 65-74, Sept. 1966 describes the proper role of modeling in systems engineering and presents the fundamental concepts essential to good modeling techniques.

1.K. Cross, "Manufacturing planning: Key to improving productivity," Ind. Eng., pp. 50-59, 1981 discusses some of the problems that production managers face when attempting to have the "right assets at the right place at the right time." An understan ding and appreciation of these problems will aid systems engineers in performing the production engineering analysis required by MIL-STD-499B.

2.R. A. Pierson, "Practical side of systems design," Production Eng., vol. 26, pp. 38-40, Dec. 1979 summarizes the advantages of using standard components in system design and presents a grouping of practical "hints" that are applicable to the design of any system.

3.P.G. Smith and D. G. Reintertsen. Developing Products in Half the Time. New York:Van Nostrand Reinhold, 1991.

1.J. E. Angus and L. E. James, "Combined hardware/software reliability models," in Proc. Annu. Reliability and Maintainability Symp., New York: IEEE Press, 1982, pp. 178-186 discusses a methodology for combining both hardware and software reliability / maintainability measures into a common reliability methodology. Their work will aid engineers trained in other disciplines to acquire an appreciation for the system approach.

2.R. Bernhard (See entry D-Bernhard).

3.B. I. Dhillon. Reliability Engineering in Systems Design and Operation. New York:Van Nostrand Reinhold., 1982.

4.A. J. Feduccia (See entry D-Feduccia).

5.N. B. Fuqua. Reliability Engineering for Electronic Design. New York:Marcel Dekker, 1987.

6.C. L. Hwang, F. A. Tillman, and M. H. Lee, "System-reliability evaluation: Techniques for complex/large systems--A review," IEEE Tram. Rel., vol. R-30, pp. 416-422, Dec. 1981 reviews the literature related to system reliability evaluation technique s for small to large complex systems.

7.M. B. Kline, "Software and hardware R & M: What are the differences?" in 1980 Proc. Annu. Reliability and Maintainability Symp., pp. 179-185 discusses both hardware and software reliability and maintenance, points out their similarities and differe nces in both conceptual and practical terms, and proposes terminology applicable to both.

8.T. F. Pliska, F. L. Jew, and J. E. Angus. Maintainability Prediction and Analysis Study. Final Technical Report, RADC-TR-78-169. Griffitts Air Force Base, NY:Rome Air Development Command, July 1978.

9.T. L. Regulinski and Y. P. Gupta (See entry K-Regulinski).

10.B. H. Sweet, "Reliability and maintainability in the acquisition process," Defense Manag. Rev., vol. 1, pp. 126-147 explains the provisions and underlying rationale behind Department of Defense Directive 5000.x, entitled "Reliability and Maintainab ility (R & M) of Systems and Equipment." Although this paper is dated, it still contains relevant background information.

11.F. A. Tillman, and S. Chatterjee, "Availability models of maintained systems," IEEE Tram. Rel., vol. R-24, pp. 69-72, Apr. 1975 presents the concept of availability (part of system engineering, Phase 5), which includes reliability and preventive an d corrective maintenance. Tillman and Chatterjee present a system availability model which considers reliability factors and preventive and corrective maintenance.

12.J. W. Wilbur and N. B. Fuqua. A Primer for DOD Reliability, Maintainability and Safety Standards. Rome, New York:Reliability Analysis Center, RADC, Griffiss AFB, 1988.

1.P. Aiken, "Planning for requirements analysis: The strawman approach," in Proceedings of the 1987 IEEE International Conference on Systems, Man, and Cybernetics , New York:IEEE, 1987.

2.A. Borning, "Computer system reliability and nuclear war," Comm. of the ACM, Vol. 30, No. 2, 112-131, February 1987.

3.B. E. Casey and B. Dasarathy, "Modelling and validating the man-machine interface," Software-Practice and Experience, vol. 12, pp. 557-569, 1982 presents a formal model for expressing the functional requirements of the man-machine interfaces of int eractive systems. It shows how inconsistency, redundancy, and incompleteness checks against a specification, and validation of the implementation of an interface against its original requirements, can be automated.

4.G. J. Chambers and K. Manos, "Requirements: Their Origin, Format and Control." in Proceedings of the Second Annual International Symposium of the National Council on Systems Engineering, July 1992.

5.Fogle, F. R. (ed.). Proceedings of the 4th NASA Systems engineering Symposium--System Requirements: The Early Definition and Management Thereof. NASA Marshall Space Flight Center, March 18-19.

6.A. Giddings, "Compromise is bad design." Naval Engineers J., 77-78, November 1986.

7.R. M. Godfrey, "Some thoughts on engineering systems development," IEE Proceedings, vol. 137, Pt. A, no. 5, 302-308, September 1990.

8.J. O. Grady. System Requirements Analysis. New York:McGraw-Hill, 1993.

9.R. Hirschheim, and G. Schafer, "Requirements analysis: A new look at an old topic," J. Applied Systems Analysis, 15:101-118, 1988.

10.I. Hooks, "Why Johnny can't write requirements," in Proceedings, AIAA Space Programs and Technologies Conference, Huntsville, AL, 25-28, September 1990.

11.P. Loucopoulos and R. E. M. Champion, "Concept requirements specification", Software Engineering J. ,116-124, March 1990.

12.H. L. Malchow and S. R. Croopnick, "A methodology for organizing performance requirements for complex dynamical systems," IEEE Tram. Eng. Manag., vol. EM-32, pp. 10-15, Feb. 1985 presents an orderly methodology, using a top-down approach, for estab lishing performance requirements for complex systems.

13.G. T. McKee and N. P. Nissanke, "Towards a systematic approach to the design of fixation mechanisms for active perception," in Proceedings 1990 IEEE International Conference on Systems, Man and Cybernetics, 4-7, 7-9, November 1990.

14.D. T. Ross, "Guest editorial: Reflections on requirements," IEEE Trans. Software Engineering, vol. SE-3, no. 1, 2-5, January 1977.

15.R. B. Rowen, "Software project management under incomplete and ambiguous specifications," IEEE Trans. on Engineering Management, vol. 37, no. 1, 10-21, February 1990.

16.A. W. Saarinen Jr., and M. A. Hobel, "Setting and meeting requirements for quality," J. of Management in Engineering, vol. 6, no. 2, 177-185, April 1990.

17.A. P. Sage, Methodology for Large-Scale Systems. New York:McGraw-Hill, 1977.

18.T. B. Sheridan, "Designing complex technology: Understanding it as of, by, and for people," Technological Forecasting and Social Change, vol. 36, 89-97, 1989.

19.G. S. Vesilash, "Hearing the Voice of the Customer," Production, 66-68, Feb. 1989.

20.J. K. Willoughby, "Adaptations to the Systems Engineering Management process for projects with incomplete requirements," in Proceedings, 1989 IEEE Conference International Conference of Systems Engineering, 197-200.

1.D. Carlin and T. W. Planek, "Risk evaluation in industry: Methods and practice," Professional Safety , vol. 25, pp. 46-50, Mar. 1980 and pp. 29-35, Apr. 1980 presents a comprehensive tutorial-like discussion of risk assessment and evaluation. The e ssay is an excellent precursor to the paper by Sage and White below.

2.D. Cooper and C. Chapman. Risk Analysis for Large Projects: Models, Methods & Cases. New York:Wiley, 1987.

3.J. D. Hwang and J. L. Arnett, "Risk analysis," Defense Ind. Bull., vol. 6, pp. 13-16, Dec. 1970 is an excellent discussion of risk analysis as a tool. It compares risk analysis to systems analysis.

4.I. A. Gilhooley. "Auditing system development methodology," EDPACS (U.S.A.), vol. 12, no. 1,7-84.

5.D. McComb and J. Y. Smith, "System project failure: The heuristics of risk," J. of Information Systems Management, 25-34, Winter 1991.

6.R. Robinson and L. Kunath, "Dynamic approach to risk management," Risk Manag., vol. 28, pp. 42-44, Sept. 1981 presents a model that could serve as an effective framework for putting the concepts of risk management into proper perspective.

7.W. D. Rowe. An Anatomy of Risk. New York:Wiley, 1977.

8.A. P. Sage and E. B. White, "Methodologies for risk and hazard assessment: A survey and status report," IEEE Trans. Syst., Man, Cybern., vol. SMC-10, pp. 425-446, Aug. 1980 provides an overview of various methodologies available to enable efficacio us assessment of the effects of potential risks and associated resource allocation.

1.G. C. Belev. "Guidelines for specification development," in Proceedings of the Annual IEEE Symposium on Reliability and Maintainability, 1989.

2.G. J. Chambers, "Sources, types, and preparation of military system specifications," in development.

3.________[author missing] , "Sources, types and preparation of military specifications and standards," Naval Engineer's Journal, September, 1989.

4.B. Cohen, "Justification of formal methods for systems specification," Software Microsyst., vol. 1, pp. 119-127, Aug. 1982 emphasizes the application of recent developments in computer science and mathematics and argues that systems engineers shoul d become as competent in these fields as they are expected to be in traditional mathematics and physics.

5.M. Fischer. Engineering Specification Writing Guide. Englewood Cliffs, NJ:Prentice-Hall, 1983.

6.S. D. Perone, "System definition, specification, and functional design," ASTM Standardization News, vol. 4, pp. 14-17, May 1976 provides a working set of guidelines or standard procedures for the specification, design, and implementation of compute r-automated laboratory systems. Although not rigorous, this methodology is applicable to any system development effort.

7.E. L. Peterson, "MIL-STD-499A and its application to systems engineering," Defense Syst. Manag. Rev., vol. 3, no. 2, pp. 105-108, Spring 1980 recounts the evolution of MIL-STD-499B, the source of the system engineering model used in compiling this bibliography.

8.D. C. Purdy. A Guide for Writing Successful Engineering Specifications. New York:McGraw-Hill, 1991.

9.K. Shumate and M. Keller. Software Specification and Design. New York:John Wiley & Sons, Inc., 1992.

10.L. C. Verman and H. C. Visesvaraya, "A systems approach to standardization," ASTM Standardization News, vol. 5, pp. 12-23, Feb. 1977 describes the development of standardization and the benefits to be derived from standardization.

1.H. A. Affel, Jr., "System engineering," Int. Sci. Technol., vol. 35, pp. 18-26, 79-82, Nov. 1964 provides insight into the historical development of the system engineering concept.

2.W. R. Beam. Systems Engineering: Architecture and Design. New York:McGraw-Hill, 1990.

3.C. L. Biggs, E. G. Birks and W. Atkins. Managing the System Development Process. Englewood Cliffs, NJ:Prentice-Hall, Inc.

4.Bilardo, V. J. (ed.). Proceedings of the 3rd NASA System Engineering Symposium--The Role of Systems Engineering in a Research Environment. NASA Ames Research Center, November 13-14, 1991.

5.B. S. Blanchard. System Engineering Management. New York:Wiley, 1991.

6.Blanchard, B. S., and W. J. Fabrycky. Systems Engineering and Analysis (2nd ed.). Englewood Cliffs:Prentice-Hall, 1990 presents a general overview of the process of bringing systems into being and for improving existing systems.

7.R. Bogusla. The New Utopians: A Study in Systems Design and Social Change. Englewood Cliffs, NJ:Prentice-Hall, 1965.

8.J. S. Baumgartner. Systems Management. Washington, DC:Bureau of National Affairs, Inc.

9.R. C. Booton, Jr., and S. Ramo, "The development of systems engineering," IEEE Tram. Aerosp. Electron. Syst., vol. AES-20, pp. 306-309, July 1984 describes systems engineering as "the design of the whole as distinguished from the design of the part s." Systems engineers create the architecture of the system, define the criteria for its evolution, and perform trade-off studies for optimization of the subsystem characteristics. According to these authors, the major growth of systems engineering is exp ected to be in the improvement of its tools and in the enlargement of the range of problems to which it is applied.

10.Carter D. E., and B. S. Baker. CE Concurrent Engineering: The Product Development Environment for the 1900s. New York:Addison-Wesley.

11.G. J. Chambers, "Roles of the Technical Director, the Lead System Engineer, and System Engineers during a System Design and Development Effort," Presented at a NCOSE Workshop, 25 June 1991.

12.________ [author missing], "Systems engineering management in the 21st Century," in Proceedings, 1990 IEEE International Conference on Systems, Man, and Cybernetics, 733-738, 1990.

13.W. P. Chase Management of Systems Engineering. (reprint ed.). Malabar, FL:Robert E. Kriger Publishing Company, Inc., 1984.

14.H. Chestnut, Systems Engineering Methods. New York: Wiley, 1967 is one of the classics of system engineering that belongs on every system engineer's bookshelf.

15.Defense Systems Management College. Systems Engineering Management Guide. Washington, D.C.: U. S. Government Printing Office, 1990.

16.K. B. De Greene. Socialtechnical Systems: Factors in Analysis, Design, and Management. Englewood Cliffs, NJ:Prentice-Hall, 1973.

17.EIA. EIA Engineering Bulletin: System Engineering (SYSB-1). Electronic Industries Association, December 1989.

18.IEE. Code of Practice for Systems Engineering, IEE Draft Code of Practice--Issue A2. D. K. Hitchins, J. Boarder, and P. R. Moore (eds.). IEE (Undated).

19.C. D. Flagel, W. H. Huggins, and R. H. Roy, Eds., Operations Research and Systems Engineering. Baltimore, MD: Johns Hopkins Press, 1960 consists of a set of lectures delivered at the Johns Hopkins University early in the developmental stages of the concept of "system engineering." The initial chapters are devoted to the philosophical and historical aspects of systems engineering and operations research. These provide valuable background for those who are interested in following the development of t he system engineering concept.

20.R. A. Frosch, "A new look at systems engineering," IEEE Spectrum, pp. 24-28, Sept. 1969 gives a critical assessment of a "potential technocratic monster" and advocates a return to engineering as an art form. This advice is just as cogent today as w hen it was first offered.

21.H. Goode and R. E. Machol, Systems Engineering: An Introduction to the Design of large-Scale Systems. New York:McGraw-Hill, 1957 is the first text to address systems engineering specifically. Although some of the examples and techniques are dated, the principles presented are just as germane today as they were when first published. This is definitely a "must read" book!

22.Ground Systems Group. A Plan for System Engineering and Technical Director Personnel Development. Fullerton, CA:Hughes Aircraft Company, 29 June 1984.

23.V. J. Hajek. Management of Engineering Projects (3rd ed.). New York:McGraw Hill, 1984.

24.A. D. Hall, A Methodology for Systems Engineering. Princeton, NJ: Van Nostrand, 1962 is one of the originals on systems engineering, and as such, it is "required reading" for all system engineers.

25.G. S. Handler, G. Hammerle and W. Rucker. Navy Program Manager's Guide. Washington, D.C.:Naval Material Command, 1985.

26.D. J. Hatley and I. M. Pirbhai. Strategies for Real-Time System Specification. New York:Dorset House, 1988.

27.L. S. Hill, "Systems engineering in perspective," IEEE Trans. Eng. Manag., vol. EM-17, pp. 124-131, Nov. 1970 presents a background on the evolution of the systems engineering process and attempts to synthesize a more complete resolution than was g enerally available in the literature. Hill's work shows the relationship between systems engineering and the engineering design process. This comparison will aid in understanding the implied requirements of MIL-STD-499B.

28.S. A. Horanessian, "Research and development of a large-scale electronic system," IEEE Trans. Eng. Manag., vol. EM-22, pp. 94-101, Aug. 1975 discusses the research and development phase of system development in terms of methodology, system design c oncepts, cost effectiveness, and customer acceptance.

29.G. M. Jenkins, "The systems approach," J. Syst. Eng., vol. I, pp. 3-49, 1969 discusses the philosophy underlying a systems approach to the solution of problems. Three questions are answered: "What is systems engineering?" "What is a systems enginee r?" and "How does a systems engineer go about solving any problem?"

30.A. Kaposi and I. Pyle, "Systems are not only software," Software Engineering J., January 1993, pp. 31-39 presents a "systems approach which affords insight into the whole development process by use of a small set of concepts: systems, their propert ies, their structure, and models thereof." This paper can help to establish a common body of "system engineering" terminology and to dispel some of the parochial ideas that "My systems engineering is different than . . . . ."

31.Keys, L. K. "Systems engineering, practice prospects: A summary view," in Proc. 1989 IIE Integrated Systems Conf., Atlanta, GA, Nov. 12-15, 1989, pp. 85-91 provides "some of the history, challenges, promises and raise[s] issues on opportunity for r esearch . . . on systems engineering, life-cycle engineering, and concurrent engineering."

32.M. B. Kline and M. W. Lifson, "Systems engineering," in Cost-Effectiveness: The Economic Evaluation of Engineered Systems, I. M. English, Ed. New York: Wiley, 1968, pp. 11-32 reviews conceptual developments in systems engineering from the time of G oode and Machol's 1957 seminal work. This work provides the background necessary for understanding the evolution of MIL-STD-499B. (See also entry R-Peterson for additional background on MIL-STD-499B.)

33.J. A. Lacy. Systems Engineering Management: Achieving Total Quality. New York:McGraw-Hill, 1992.

34.R. E. Machol, Ed., Systems Engineering Handbook. New York: McGraw-Hill, 1965 is perhaps the first, and last, published system engineering handbook. Although over 20 years old, the material is still relevant, both from a practical and a historical v iewpoint. (See also entry T-Machol for an updated version of some of the material presented in this early work.)

35.P. K. M'Pherson, "Systems engineering: An approach to whole-system design," Rad. Electron. Eng., vol. 50, pp. 545-558, Nov./Dec. 1980 presents an overview of the evolution of systems methodologies beginning with operations research and including sy stems analysis, systems engineering, and servo-mechanism theory. The identification of "factors inducing problems of complexification" is particularly valuable.

36.National Council on Systems Engineering. Systems Engineering for the 21st Century. Proceedings of the Second Annual International Symposium of the National Council on Systems Engineering (NCoSE), Seattle, WA, July 20-22, 1992.

37.National Council on Systems Engineering. Systems Engineering in the Workplace. Proceedings of the Third Annual International Symposium of the National Council on Systems Engineering (NCoSE), Arlington, VA, July 26-28, 1993.

38.A. V. Oppenheim, A. S. Willsky, and I. T. Young. Signals and Systems. Englewood Cliffs, NJ:Prentice-Hall, Inc., 1983 presents the elements essential to understanding basic characteristics of typical input and output signals and performing a system analysis. Understanding the treatment of various signals types will allow systems engineers to not only perform a system analysis but to effectively evaluate analysis tools under consideration.

39.T. G. Peck, "Worldwide systems engineering," IBM Systems J., vol. 24, nos. 3/4, 182-188, 1985.

40.G. Pellegrinetti, "Examining the System concept-A professional's viewpoint," Specifying Eng., pp. 82-83, Feb. 1982, pp. 136-139, May 1982 is an essay on systems concepts, less formal than other sources, but providing valuable insights into the syst em engineering process. These insights are all the more cogent as they come from a viewpoint outside of academia or the aerospace industry.

41.This reference info (S-15a) is currently missing (?) presented an overview of the systems engineering process and discusses how it could be applied, possibly, to solving complex social problems.

42.D. G. Raheja. Assurance Technologies. New York:McGraw-Hill, Inc., 1991.

43.E. Rechtin, "Systems engineering--But isn't that what I've been doing all along?" Astronautics and Aeronautics, Vol. 6, June 1968, pp. 70-74.

44.A. B. Rosenstein, "Systems engineering and modern engineering design," in Proceedings, Annual Meeting of the American Ceramic Society, April 1966, pp. 1-9.

45.A. M. Ruskin, "Project Management and Systems Engineering: A marriage of convenience," PMNetwork , 38-41, July 1991.

46.A. P. Sage, "Systems engineering: Fundamental limits and future prospects," Proc. IEEE, vol. 69, pp.158-166, Feb. 1981 describes presently perceived limits in systems engineering along with contemporary and projected future efforts to reach, circum vent, or ameliorate the effects of these limits.

47.S. M. Shinners, Techniques of Systems Engineering. New York: McGraw-Hill, 1967 is one of the last to focus on hardware-oriented systems rather than data-oriented systems.

48.S. E. Stephanou, "Semantic problems in Systems engineering," in Proc. Int. Systems Engineering, vol. 2. Lafayette, IN: Purdue Univ., 1972, pp. 338-343 will help system engineers when reading the literature on the semantic problems Stephanou highlig hted in 1972 which still plague the field of system engineering (see also entry T-Ackoff).

49.R. T. Stevens. Operational Test and Evaluation: A Systems Engineering Process. New York:Wiley, 1979.

50.Weinberg, G. M., Quality Software Management, Volume 1: Systems Thinking. New York:Dorset House, 1992 provides the first requirement for development of quality software (or any system): learning to think correctly. Weinberg provides guidelines for thinking about problems, solutions, and quality. This is volume 1 of a 3-volume series.

51.A. W. Wymore. A Mathematical Theory of System Design. Tucson, AZ:SANDS, draft, May 1987.

52._________ author missing(?). Putting Systems to Work. New York:John Wiley, .......(?)

1.R. L. Ackoff, "Towards a system of system concepts, Management Sci., "vol.17, pp 661-671, 1971 attempts to organize the concepts and terms used to talk about systems (see entry S-Stephanou).

2.K. Balkus and E. E. McClure, "Toward a general systems formulation," in Progress in Cybernetics and Systems Research, vol. 1, R Trappi and F. de P. Hanika, Eds. Washington, DC: Hemisphere, 1975, pp. 84-92 provides a starting point for development of a "general, concise and integrated explanation of the system issue from systems formulation to its spatial and relational structure." The authors argue that an effective system formulation should be suitable for applications and for the cultivation of th e intellect.

3.R. Boguslaw. The New Utopians: A Study in Social Change. Englewood Cliffs, NJ:Prentice-Hall, 1965.

4.P. B. Checkland, "The development of systems thinking by systems practice--A methodology from an action research program," in Progress in Cybernetics and Systems Research, vol. 2, R. Trappi and F. de P. Hanika, Eds. Washington, DC: Hemisphere, 1975, pp. 279-283 defines a methodology as intermediate in status between a "philosophy" and a "technique or method." An understanding of these distinctions will aid system engineers to develop their understanding of system theory.

5.H. Chestnut, "Information requirements for systems understanding," IEEE Trans. Syst. Sci. Cybern., vol. SSC-6, pp. 3-12, Jan. 1970 categorizes the basic information requirements for describing systems as 1) structure, the interrelationships of the system's parts; 2) distinguishing qualities, what differentiates the system from other structures of a similar form or nature; and 3) magnitude, probability, and time. Chestnut argues that knowledge of these parameters could prevent unnecessary duplicatio n of effort and more efficient use of hardware and software.

6.S. Cornack, "The structure of the systems paradigm," in Progress in Cybernetics and Systems Research, vol. 4, 139-148, 1978.

7.C. Eden and IL Graham, "Hallway to infinity: Systems theorizing for the practitioners?" J. Operational Res. Soc., vol. 34, pp. 723-728, Aug. 1983 compares and contrasts the rational theorizing about system design to the nonrational process of imple mentation. They propose a position halfway between these two extremes that is based upon reflection on experience, using system theory as a framework for thinking rather than a guide for action.

8.D. O. Ellis, and F. J. Ludwig. Systems Philosophy. Englewood Cliffs, NJ:Prentice-Hall, 1962.

9.F. E. Emery (ed.). Systems Thinking (vols. 1 & 2). New York, Penguin Books, 1981.

10.W. W. Gasparski, "Systems methodology--Its nature, structure and applications. Some remarks," in Progress in Cybernetics and Systems Research, vol. 2, IL Trappi and F.de P. Hanika, Eds. Washington, DC: Hemisphere, 1975, pp. 3O8-32O presents some insights into system methodology from a point of view slightly different from that of most American writers. Gasparski's "methodology model" is particularly useful for building an understanding from which to evaluate other methodologies.

11.V. Hubka and W. E. Eder. Theory of Technical Systems: A Total Concept Theory for Engineering Design. New York:Springer-Verlag, 1988.

12.E. Laszlo. Introduction to Systems Philosophy: Toward a New Paradigm of Contemporary Thought. New York:Gordon & Breach, 1972.

13.________(? author missing) , "The case for system's philosophy, " Metaphilosophy, vol. 3, no. 2, 123-150, April 1972.

14.R. E. Machol and R. F. Miles, Jr., "The engineering of large-scale systems," in Systems Concepts: lectures on Contemporary Approaches to Systems, R. F. Miles, Jr., Ed. New York:Wiley, 1973, pp. 33-50 is a review and update of material originally pr esented in MachoI's System Engineering Handbook (see entry S-Machol).

15.R. F. Miles, Jr., "Introduction to systems concepts," in Systems Concepts: lectures on Contemporary Approaches to Systems, F. Miles, Jr., Ed. New York: Wiley, 1973, pp. 1-11 states that "systems engineering is good engineering" and that it is "more a change in emphasis than a change in content." The change places more emphasis on defining goals, relating system performance to defined goals, developing alternatives and decisi on criteria, modeling systems for analysis and on controlling implementation and operation.

16.G. A. Miller, "The magical number seven, plus or minus two," Psychological Review, vol. 63, no. 2, xx - xx, March 1956.

17.J. D. Palmer (see entry I-Palmer).

18.I. W. Sandberg, "A perspective on system theory," IEEE Trans. Circuits Syst., vol. CAS-31, pp. 88-103, Jan. 1984 discusses the origins and history of system theory from the mathematical point of view.

19.Weinberg, G. M. An Introduction to General Systems Thinking. New York:John Wiley, 1975.

20.B. Wilson (see entry I-Wilson).

21.A. W. Wymore, Systems Engineering Methodology for Interdisciplinary Teams. New York: Wiley, 1976 presents a system engineering methodology in a highly structured academic manner. Extensive use is made of mathematical terminology and symbolism. This sometimes obscures the highly valuable information in the text.

1.H. Chestnut. Systems Engineering Tools. New York:John Wiley, 1965.

2.H. Eisner, Computer-Aided System Engineering. New York:Prentice-Hall, 1988.

3.________ (? author unknown), "CASE: Computer Aided Systems Engineering for C3I systems," Signal, 15-21, July, 1984.

4.M. D. Rychener, "Expert systems for engineering design," Expert Systems, vol. 2. no. 1, 30-44, January 1985.

5.Shishko, R. Catalog of JPL System Engineering Tools and Models (JPL D-8060). NASA/Caltech Jet Propulsion Laboratory, 1990.

6.________ (ed.)(? ed. unknown). Proceedings of the Fifth NASA Systems engineering Symposium--Integrated Systems Engineering Tools: Current Capabilities and Future Directions. NASA/Caltech Jet Propulsion Laboratory, February 26-27, 1993.

7.A. Ruskin., System Development at JPL: An Overview of the JPL System Development Management Guide (D-5000). NASA/Caltech Jet Propulsion Laboratory, November 16, 1990 was prepared to improve system development at JPL by:

Establishing comparable benchmarks among projects Standardizing selected aspects of system development

D-5000 approaches "system" as a hierarchy of subsystems, sub-subsystems, etc. and applies systems engineering at all seven-phases (their model) of system development. JPL sees the role of systems engineering as being that of delivering to management a fu lly developed, certified system that meets user requirements. This includes such activities as: defining requirements, developing alternative designs, allocating performance margins and allowances, supporting supersystem development (resolving interface problems), overseeing subsystem engineering, and coordinating system certification.