An Overview of Systems Engineering
-The Art of Managing Complexity-

Cory R.A. Hallam

Abstract

Systems Engineering has emerged as a distinct professional discipline in the past half century in response to the ever-increasing complexity of new products and systems. This paper provides a brief overview of the discipline and the role of the Systems Engineer.

Introduction

The term Systems Engineering (SE) is a generic term that describes the application of structured engineering methodologies to the design and creation of complex systems. While there has been great discussion about the term "system", it can be argued that from the point of view of the System Engineer, a system is a collection or set of "parts" that work together to perform a particular function. These parts can be in the form of hardware, software, or liveware, and in themselves may be considered systems. The system definition is essentially relative to the perspective of the individual who views the system. The discipline of Systems Engineering focuses on the coordination of all of the disciplines, tasks, and activities necessary to develop the total system.

Unlike traditional engineering disciplines, such as hydraulics engineering, structural engineering, or electrical engineering, Systems Engineering is not governed by a set of fundamental mathematical relations based on physical properties. In essence, it has not traditionally been a strict laboratory-based form of engineering. It has emerged from a need to deal with the ever-increasing complexity of system development projects, and emerged as a collection of best-practices for managing the development of complex engineering systems. Given the ad-hoc assemblage of many of these best-practices in their early years, the past several decades has seen the application of modeling and simulation tools to the development of processes that optimize system development in multivariate system requirements space - a process that historically was an emergent property of multiple iterations in managing, designing, and creating complex systems. The current state of affairs in System Engineering seems to support the notion that Systems Engineering ultimately attempts to formalize the process of tracing and managing customer requirements from conceptual design through to system development and operation.

Historical Basis for Modern System Engineering

The field of System Engineering as we know it emerged from the post World War II (WWII) military-industrial-academic complex that was embroiled in an accelerating weapons race with the former Soviet Union. While many pre-WWII systems were designed, built and implemented in a succession of steps with relatively few decision makers affecting the technical design and development of the system, post WWII military projects were inherently more complex involving exponentially increasing numbers of disciplinary experts and increasing layers of interacting systems of systems.  The foundation of System Engineering, as it is known today, emerged from this era via the  Atlas Intercontinental Ballistic Missile (ICBM) Program.

Prior to the Atlas ICBM program, the U.S. Air Force (Army Air Corp in earlier years) dealt with prime airframe contractors who were responsible for designing an aircraft to military specifications and managing all of the subcontractors necessary for delivering on the contract. This led to an environment of airframe-centric military platforms that senior Air Force officials became accustomed to purchasing and managing on a 1-to-1 basis with the prime. Ultimately, this resulted in a limited number of military weapons system options, as the decision of using an airframe platform was essentially never questioned. When the time came for the development of an ICBM in the early 1950's, the Air Force was again poised to choose an airframe manufacturer and pursue a prime contractor relation.

The U.S. Air Force Assistant Secretary for Research and Development (R&D), Trevor Gardner, was tasked with heading the USAF Strategic Missile Evaluation Committee, later called the Teapot Committee. This committee had the task of evaluating the numerous strategic missile development efforts in the U.S., primarily as a means to eliminate repetition of development efforts in the country. However, with a group of very scientifically oriented academics on the committee, many from Caltech, it quickly began assessing the capability of airframe prime contractors to develop a system that would require significant electronic and computational capabilities. The ICBM would indeed be a complex system, the likes of which had never been developed. It was the recommendation of the Teapot committee in 1954 to a young General with the Western Development Division of the Air Force Research and Development Command, Bernard Schriever, that ultimately changed the organizing principles of managing system development contracts - there would be a System Engineering contractor staffed by "unusually competent" scientists and engineers to direct the technical and management control over all elements of the program.

With a group of intellectually gifted scientists and engineers, the company of Ramo-Wooldridge, a company with prior experience in electronics systems, was contracted to lead the system engineering of the Atlas program in conjunction with Shriever. Noteworthy is the fact that Simon Ramo, a Ph.D. from Clatech and co-founder of Ramo-Woooldridge, often served as the chair of the Teapot Committee. At the height of the Atlas program, there were over 18 000 scientists, engineers and technicians, and a total of 70 000 people from 22 industries involved in the program, which included 17 contractors, 200 subcontractors, and over 500 hundred military officers. Ramo and his staff helped establish System Engineering as a discipline by creating an organization dedicated to the scheduling and coordinating of activities for subcontractor R&D, test, integration, assembly, and operations.

The coordination element of the System Engineering approach was further driven by a tight schedule that required concurrent development of designs, subsystems, manufacturing and test facilities, command and control systems, and training mechanisms. To do this effectively required highly developed management tools to ensure the success of concurrent and mutually dependent activities, the lack of which would lead to "concurrent failure". These management and organizational tools dealt with managing interfaces and boundaries between disciplines, subsystems, and people, of which the process was often more difficult and complex than solving specific technical problems. However, through trial and error, the team developed the quantitative tools and methodologies that formed the basis for interdisciplinary trade studies and decision aids that now populate the field of System Engineering.  Based on the success of the Atlas program, academics and social scientists of the 1960's codified and rationalized the best practices observed in the military-industrial-academic programs into management science and System Engineering that resulted in articles, books, and eventually university and professional courses on the subject.

The System Engineer

In many respects, the System Engineer is similar to the general practitioner in medicine, an individual who is able to grasp the issues of importance by looking at the whole system, and delegating responsibility for handling each issue to the appropriate specialist or team of specialists. While not necessarily called the "System Engineer", anyone who is responsible for the design and implementation of a total system based on a set of customer requirements is acting as a System Engineer. The role of the System Engineer is thus one of a manager that possesses and uses a set of formal tools that structure the system development process. In fact, the adoption of international standards for System Engineering has resulted from the appearance of requirements for certain process adherence guidelines in military and government system development contracts in the past few decades.
The primary concern in all literature on Systems Engineering is the customer, or more specifically, customer requirements and constraints. All System Engineering processes begin with the collection and documentation of customer requirements. These requirements are formally established as the basis for the system development, and more importantly, are methodologically tracked from the time they are created until the system is operated. There is essentially a paper trail of documentation and decision tools that describe or demonstrate the source of any system design choice to specific customer requirements. Unlike typical "push" design methodologies that are based on the premise of "build it and they will come", System Engineering processes are more of a "pull" system that has the customer driving the design requirements and parameters that most directly affect the performance of the system. It is the role of the System Engineer to work within these parameters and orchestrate a development process that delivers the value desired by the customer.

The System Engineering Methodology

At the highest level, the System Engineering methodology focuses on several major steps including (1) problem statement, (2) identification of objectives and requirements documentation, (3) concept generation, (4) analysis of alternatives and trade studies, (5) selection of primary concept, (6) system creation, including decomposition, design, development, integration, verification and validation, and (7) system operation and life cycle disposal. These steps are typically orchestrated in a manner that intellectually decomposes the problem into subsystem and eventually component-level "chunks" that can be handled by individual engineers. The system is then physically reconstructed from its individual components into subsystems and eventually integrated into a complete system. Plans are created by the System Engineer to ensure that the subsystems and overall system perform as designed (verification) and ultimately meet the desired intent of the customer (validation) by performing the desired function.

Standards for System Engineering have emerged from many sources, and first appear in military standards in the late 1960's. A standard is a document that establishes engineering and technical requirements for products, processes, procedures, practices, and methods, and has either been decreed by authority, or adopted by consensus. Typically, government and military Systems Engineering standards have been decreed by authority, while commercial standards (i.e. ISO, EIA, SAE, and IEEE) have been adopted by consensus. However, the development of both decreed and adopted standards for System Engineering have been interdependent and mutually influential in their evolution. These standards now form the basis for many system development contracts, and act to ensure that the customer's needs are satisfactorily met.

The Future of the Field

The field of Systems Engineering has emerged from a collection of best practices in system development project management to formal degrees that are now provided in educational institutions. AT MIT, for example there are graduate degrees in "Systems Design and Management", and interdepartmental educational organizations such as the "Engineering Systems Division", all aimed at creating leaders whom have many of the skills one would associate with a Systems Engineer. There are numerous research groups around the world who focus on creating Systems Engineering tools and decision aids for process management and optimization. The International Committee on Systems Engineering (INCOSE) acts as a focal point for communicating the development of this work via publications and conferences.
While it is arguable that Systems Engineering is not a simple input/output function into which a set of requirements are entered and a system design emerges, it does provide the framework for managing and creating systems that meet customer needs in a manner that attempts to maximize the customer's value as measured via cost, time, and performance metrics. Systems Engineering will thus continue to survive and evolve as a professional discipline given the ever-increasing complexity of the distributed systems being created in an information age.

References

1. Blanchard, B. (1991). Fundamentals of Systems Engineering. 
2. Brooks, F., ( 1995 ). The Mythical Man Month: Essays on Software Engineering,  2nd Ed.
3. Buhr, R., (1984). Systems Design with ADA. 
4. Chambers, G., (1985). "What is a systems engineer?" IEEE Trans. Syst., Man, Cybern., vol. SMC-15, pp. 517-521, July/Aug. 1985.
5. Gandoff, M.,(1990).  Systems Analysis and Design.
6. Grady, J. (1994). System Integration, CRC Press.
7. Grolier’s Interactive Encyclopedia (1997).
8. Hall, D. (1962). A Methodology for Systems Engineering.
9. Hino, K., (1965). "A standardized approach to systems engineering," Signal, pp. 41-42, Dec. 1965.
10. International Council on Systems Engineering (INCOSE) web pages (2001), http:\\www.incose.org, October 2001.
11. Kezner, H., (1984).  Project Management: A System Approach to Planning, Scheduling and Controlling, 2nd ed.
12. Maier, M.W., Rechtin, E. (2000). The Art of System Architecting (2nd Ed.)
13. Quality Function Deployment Implementation Manual (1989), Version 3.9, American Supplier Institute.
14. Sage, A., (1977).  Systems Engineering Methodology and Applications 
15. Truxal, J., (1972) Introductory Systems Engineering
16. Ulrich, K.T., Eppinger, S.D. (2000).  Product Design and Development (2nd Ed.). McGraw-Hill