Compiled by
A. Terry Bahill and Frank F. Dean
New Mexico Weapons Systems Engineering Center
Sandia National Laboratories
Albuquerque, NM 87185-0475
Systems and Industrial Engineering
University of Arizona
Tucson, AZ 85721
Copyright © 1995 Bahill and Dean
Abstract Systems Engineering is an interdisciplinary process that ensures that the customer's needs are satisfied throughout a system's entire life cycle. This process includes
Material for this paper was gathered from senior Systems Engineers at Sandia National Laboratories and Hughes Aircraft Co. and also the following general references: Blanchard and Fabrycky (1990); Sage (1992); Chapman, Bahill and Wymore (1992); Wymore (1993); Martin (1994); IEEE P1220 (1994); Grady (1994, 1995); Hughes Aircraft Company (1994); Martin-Marietta (1994); Shishko (1995); Proceedings of the IEEE Systems, Man, and Cybernetics International Conferences; NCOSE and INCOSE Symposia and Proceedings.
An early version of this paper was published in the IEEE Systems, Man, and Cybernetics Newsletter December 1994, pp. 11-12. The most recent version is available via anonymous ftp on tuson.sie.arizona.edu at pub/WhatIsSystemsEngineering. An associated seventy color slide PowerPoint presentation will be available on Sandia National Laboratories' Systems Engineering page at http://www.sandia.gov. Comments are welcome at terry@sie.arizona.edu.
The system life cycle. The system life cycle has seven phases: (1) requirements development, (2) concept development, (3) full-scale engineering design and development, (4) manufacturing and deployment, (5) system integration and test, (6) operation, maintenance and modification, and (7) retirement, disposal and replacement. However, the system life cycle is different for different industries, products and customers. Chapman, Bahill and Wymore (1992); Wymore (1993); Kerzner (1995); Shishko (1995).
Understanding customer needs. The customer may not be aware of the details of what they need. Systems Engineers must enter the customer's environment, discover the details and explain them. Flexible designs and rapid prototyping help identify details that might have been overlooked. Talking to your customer's customer and your supplier's supplier can be very useful. The terms customer and stakeholder include anyone who has a right to impose requirements on the system: end users, operators, owners, bill payers, regulatory agencies, beneficiaries, victims, etc.
Stating the problem. This is one of the Systems Engineer's most important tasks. An elegant solution to the wrong problem is less than worthless. The word optimal should not appear in the statement of the problem, because there is no single optimal solution to complex systems problems. Most system designs have several performance and cost criteria. Systems Engineering creates a set of alternative designs that satisfy these performance and cost criteria to varying degrees. Moving from one alternative to another will usually improve at least one criterion and worsen at least one criterion, i.e. there will be trade-offs. None of the feasible alternatives is likely to optimize all the criteria (Szidarovszky, Gershon and Duckstein, 1986). Therefore, Systems Engineers must settle for less than optimality. It might be possible to optimize some subsystems, but when they are interconnected, the overall system will not be optimal. The best possible system is not that made up of optimal subsystems. An all star team might have the optimal people at all positions, but is it likely that such an all star team could beat the world champions? e.g., a Pro Bowl team is not likely to beat the Super Bowl champions. If the system requirements demanded an optimal system, data could not be provided to prove that any resulting system was indeed optimal. In general, it can be proven that a system is at a local optimum, but it cannot be proven that it is at a global optimum.
Discovering system requirements. There are two types of system requirements: mandatory and preference. Mandatory requirements insure that the system satisfies the customer's operational need.
Mandatory requirements (1) specify the necessary and sufficient conditions that a minimal system must have in order to be acceptable (They are usually written with the words shall and must.), (2) must be passed or failed, there is no middle ground (i.e. They must not use scoring functions.), and (3) must not be susceptible to trade-offs between requirements. Typical mandatory requirements might be of the following form: "The system shall not violate federal, state or local laws." Mandatory requirements state the minimal requirements necessary to satisfy the customer's need.
After understanding the mandatory requirements, Systems Engineers propose alternative candidate designs, all of which satisfy the mandatory requirements. Then the preference requirements are evaluated to determine the "best" designs. The preference requirements (1) should state conditions that would make the customer happier (They are often written with the words should and want.), (2) should use scoring functions (Chapman, Bahill and Wymore, 1992) to evaluate the figures of merit, and (3) should be evaluated with a multicriteria decision aiding technique (Szidarovszky, Gershon and Duckstein, 1986), because none of the feasible alternatives is likely to optimize all the criteria and there will be trade-offs between these requirements. Typical preference requirements might be of the following form: "The system should have high performance and low cost: the performance and cost figures of merit will be weighted equally." Sometimes there is a relationship between mandatory and preference requirements, e.g. a mandatory requirement might be a lower threshold value for a preference requirement. The words optimize, maximize and minimize should not be used in stating requirements (Grady, 1993). Quality function deployment (QFD) can help identify system requirements (Bahill and Chapman, 1993; Bicknell and Bicknell, 1994).
Defining performance and cost measures. A technical performance measurement, often called a performance figure of merit, describes the result of a test, e.g., "In this test that car accelerated from 0 to 60 in 6.5 seconds." Such measurements are made throughout the evolution of the system: based first on estimates by the design engineers, then on models, simulations, prototypes and finally on the real system.
Prescribing tests. Early in the system life cycle Systems Engineering should describe the tests that will be used to prove compliance of the final system with its requirements.
Validating requirements. Validating requirements means ensuring that the requirements are consistent and that a real-world solution can be built and tested to prove that it satisfies the requirements. If Systems Engineering discovers that the customer has requested a perpetual-motion machine, the project should be stopped.
Conducting design reviews. After the system model has been simulated and validated the requirements are reanalyzed and reformulated. This is called a preliminary design review. After the prototype has been validated the requirements are again reformulated at the critical design review. After the preproduction unit has been validated the requirements are again revised in the preproduction design review. These are the three major design reviews, but smaller reviews should be performed throughout the design process.
Exploring alternative concepts. Alternative designs should be proposed. Multicriteria decision aiding techniques should be used to reveal the best alternatives based on performance and cost figures of merit. This analysis should be redone whenever more data are available. For example, figures of merit should be computed initially based on estimates by the design engineers, Then models should be constructed and evaluated. Next simulation data should be derived. Subsequently prototypes should be measured and finally tests should be run on the final system. For the design of complex systems, alternative designs reduce project risk.
Sensitivity analyses. Sensitivity analyses can be used to point out the requirements and parameters that have the biggest effects on cost, schedule and performance. They are used to help allocate resources. Karnavas, Sanchez and Bahill (1993).
Functional decomposition. Systems engineers do functional decomposition on new systems (1) to map functions to physical components, thereby ensuring that each function has an acknowledged owner, (2) to map functions to system requirements, and (3) to ensure that all necessary tasks are listed and that no unnecessary tasks are requested. This list becomes the basis for the work breakdown structure. When analyzing (or re-engineering) an existing system, Systems Engineers do functional analysis to see what the system does in order to improve its performance (often called value engineering), and they also do functional decomposition to see what the system is supposed to do. In this manner they can describe the present state of the system and the desired (or goal) state of the system. They can then suggest how the system design can be changed. Making radical dramatic changes in the system is called re-engineering. Making small incremental changes is called total quality management. Icarus, and many flight wanna-bes after him, tried to understand how to fly by analyzing the physical components that birds used to fly: Legs, Eyes, Brain, and Wings. Using this paradigm man was not able to fly. The Wright brothers, in contrast, identified the following functions for the flight problem: Takeoff and land, Sense position and velocity, Navigate, Produce horizontal thrust, and Produce vertical lift. Once it was understood that thrust and lift were two functions, two physical components could be assigned to them. By using a propeller to produce thrust and wings to produce lift, manned flight was possible. The following Netscape specific table shows a mapping of functions to physical components.
| Function | Airplane Physical Component | Bird Physical Component |
|---|---|---|
| Takeoff and land | Wheels, skis or pontoons | Legs |
| Sense position and velocity | Vision or radar | Eyes |
| Navigate | Brain or computer | Brain |
| Produce horizontal thrust | Propeller or jet | Wings |
| Produce vertical lift | Wings | Wings |
Birds use one physical component for two functions: thrust and lift. Man had to use two physical components for these two functions. As this example shows it is perfectly acceptable to assign two or more functions to one physical component. However it would be a mistake to assign one function to two physical components.
Recently object-oriented analysis has been replacing function decomposition for re-engineering existing systems (Jacobson, Ericsson and Jacobson, 1995).
System modeling. Models will be developed for most alternative concepts that are explored. The model for the best alternative will be expanded and used to help manage the system throughout its entire life cycle. Many types of system models are used, such as physical devices, equations, block diagrams, flow diagrams, object models, and computer simulations.
System design. The overall system must be partitioned into subsystems, subsystems must be partitioned into assemblies, etc. Reusability should be considered in creating subsystems. For new designs, subsystems should be created so that they can be reused in future products. For redesign, subsystems should be created to maximize the use of existing, particularly commercially available, products. Systems engineers must also decide whether to make or buy the subsystems, first trying to use commercially available subsystems. If nothing satisfies all the requirements, then modification of an existing subsystem should be considered. If this proves unsatisfactory, then some subsystems will have to be designed. Engineers designing one subsystem must understand the other subsystems that their system will interact with. Flexibility is more important than optimality. Hardware, software and bioware must be considered. Bioware applies to humans and other biological organisms that are a part of the system. For example, in designing a race track the horses or dogs are a part of the bioware. Facilities for their care and handling must be considered, as should provisions for education, human factors, and safety. These activities are called System Design for new systems and Systems Analysis for existing systems.
Designing and managing interfaces. Interfaces between subsystems and interfaces between the main system and the external world must be designed. Subsystems should be defined along natural organizational units. When the same information travels back and forth among different subsystems a natural activity may have been fragmented. Subsystems should be defined to minimize the amount of information to be exchanged between the subsystems. Well-designed subsystems send finished products to other subsystems.
System integration. System integration means bringing subsystems together to produce the desired result and ensure that the subsystems will interact to satisfy the customer's needs. End users and engineers need to be taught to use the system with courses, manuals and training on the prototypes. Grady (1994).
Total system test. The system that is finally built must be tested to see (1) if it is acceptable, and (2) how well it satisfies the preference requirements. In order to save money, a total system test was never done on the Hubble Telescope. As a result we paid $850,000,000 to fix the undetected system error.
Configuration management. Configuration management (also called modification management) ensures that any changes in requirements, design or implementation are controlled, carefully identified, and accurately recorded. All stakeholders should have an opportunity to comment on proposed changes. Decisions to adopt a change must be captured in baseline database and reflected in system documentation. This documentation is a time frozen design containing requirements for functions, performance, interfaces, verification, testing, cost, etc. All concerned parties must be notified of changes to ensure that they are all working on the same design. The phrase requirements tracking is now being used for an important subset of configuration management.
Risk management. There are two types of risk: risk of project failure (due to cost overruns, time overruns or failure to meet performance specifications) and risk of harm (usually called personnel safety). A failure modes and effects analysis and risk mitigation must be performed. Project risk can be reduced by supervising quality and timely delivery of purchased items. Kerzner (1995).
Reliability analysis. Major failure modes must be analyzed for probability of occurrence and severity of occurrence. Kapur and Lamberson (1977): O'Connor (1991).
Total quality management. Everyone must continually look for ways to improve the quality of the system. Major tools used in this process include basic concurrent engineering, quality function deployment (QFD) and Taguchi's quality engineering techniques. Bicknell and Bicknell (1994).
Project management. Project management is the planning, organizing, directing, and controlling of company resources to meet specific goals and objectives within time, within cost and at the desired performance level. Kerzner (1995).
Documentation. All of these Systems Engineering activities must be documented in a common repository, often called the Engineering Notebook. The stored information should be location, platform, and display independent: which means any person on any computer using any tool should be able to operate on the fundamental data. Results of trade-off analyses should be included. The reasons for making critical decisions should be stated. Chapman, Bahill and Wymore (1992); Wymore (1993).
Creating Systems Engineers. The traditional method of creating Systems Engineers was to select well-organized engineers with lots of common sense and let them acquire 30 years of diverse engineering experience. But recently these traditional Systems Engineers have written books and standards that explain what they do and how they do it. So now that the tools, concepts and procedures have been formalized, in four years of undergraduate education we can teach Systems Engineers who will have performance levels 50% that of traditional Senior Systems Engineers. Ten years of systems engineering experience will improve performance to 80% and another ten years will increase it to 100%. These numbers are based on real salary data and the fallacious assumption that salary is commensurate with performance.
ANSI/ASQC Q9000, Q9001, Q9002, Q9003, Q9004, American Society for Quality Control, Milwaukee, WI, 1994.
Bahill A.T. and Chapman, W.L., "A tutorial on quality function deployment," Engr Management J, 5(3):24-35, 1993.
Bicknell, K.D. and Bicknell, B.A., The Road Map to Repeatable Success: Using QFD to Implement Changes, CRC Press, Boca Raton, 1994.
Blanchard, B.S. and Fabrycky, W.J., Systems Engineering and Analysis, Prentice-Hall, 1990.
Chapman, W.L., Bahill, A.T. and Wymore, W., Engineering Modeling and Design, CRC Press, Boca Raton, 1992.
Grady, J.O., System Requirements Analysis, McGraw Hill Inc., 1993.
Grady, J.O., System Integration, CRC Press, Boca Raton, 1994.
Grady, J.O., System Engineering Planning and Enterprise Identity, CRC Press, Boca Raton, 1995.
Hughes Aircraft Co., Systems Engineering Handbook, 1994.
Humans, Information and Technology, Proceedings 1994 IEEE International Conference on Systems, Man, and Cybernetics, San Antonio, October 2-5, 1994.
IEEE P1220 Standard for Systems Engineering, IEEE Standards Dept., NY, 1994.
Jacobson, I., Ericsson, M. and Jacobson, A., The Object Advantage: Business Process Reengineering with Object Technology, Addison-Wesley, New York, 1995.
Kapur, K.C. and L.R. Lamberson, Reliability in Engineering Design, John Wiley & Sons, New York, 1977.
Karnavas, W.J., Sanchez, P. and Bahill A.T., "Sensitivity analyses of continuous and discrete systems in the time and frequency domains," IEEE Trans Syst Man Cybernetics, SMC-23: 488-501, 1993.
Kerzner, H., Project Management: a Systems Approach to Planning, Scheduling, and Controlling, Van Nostrand Reinhold, New York, 1995.
Lamprecht, J.L., Implementing the ISO-9000 Series, Marcel Dekker, NY, 1993.
Malcolm Baldrige National Quality Award Criteria Pack, National Institute of Standards and Technology, 1994.
Martin, J. (Ed). Systems Engineering Process, AT&T ATS Engineering Standard Process, 1994.
Martin-Marietta, Systems Engineering Methodology Handbook EPI 270-01, 1994.
MIL-STD-499B, Draft Military Standard for Systems Engineering, AFSC/EN, 1992. This standard was not signed by the Department of Defense. Spokesmen said that the government should not be in the business of writing standards and therefore they would adopt standards written by professional societies.
NCOSE, Systems Engineering Process Activities, A "How To" Guide, Draft of a handbook by The National Council on Systems Engineering, 1994.
O'Connor, P.D.T., Practical Reliability Engineering, 3rd Edition, John Wiley & Sons, 1991.
Sage, A.P., Systems Engineering, John Wiley & Sons Inc., 1992.
Shishko, R. NASA Systems Engineering Handbook, SP-6105, 1995.
Systems Engineering: A Competitive Edge in a Changing World, Proceedings of the Fourth Annual Symposium of the National Council on Systems Engineering (NCOSE), August 10-12, 1994, San Jose.
Systems Engineering in the Global Market Place, Proceedings of the Fifth Annual Symposium of the National Council on Systems Engineering, July 22-26, 1995, St. Louis.
Szidarovszky, F., Gershon, M. and Duckstein, L., Techniques for Multiobjective Decision Making in Systems Management, Elsevier Science Publishers, Amsterdam, 1986.
Wymore, W., Model-Based Systems Engineering, CRC Press, Boca Raton, 1993.