Treating Systems of Systems as Systems

Definition: A system of systems (SoS) is itself a system with characteristics. In particular, it comprises "a collection of systems, each capable of independent operation, that interoperate together to achieve additional desired capabilities." [1]

Keywords: systems of systems (SoS)

MITRE SE Roles and Expectations. Although MITRE often plays the role of the systems engineer (SE) in a system that is part of a system, MITRE also supports the engineering of capabilities provided by a SoS. In this case, MITRE applies systems principles and systems engineering practices to the SoS as the system of interest.

Many current user capabilities depend on multiple systems working in concert to satisfy user needs. When these systems are brought together, the result is that existing systems are often used in new ways to address the combined user needs, which can sometimes be augmented by new systems designed to support the operation of the SoS. Increasingly, MITRE is called on to apply systems engineering to these systems of systems as systems in their own right.

MITRE systems engineers (SEs) are accustomed to addressing system interfaces, including external interfaces, as core parts of a system. As systems have been increasingly networked, interoperability between and among systems has become a greater focus.

This article focuses on treating systems of systems as systems and the implication for systems engineering. It addresses what is different about systems of systems and what that means for applying systems engineering to systems of systems as systems.

  • Characterizing Systems of Systems and Systems of Systems Engineering presents the key characteristics of systems of systems as systems, the main differences between applying systems engineering to individual systems and applying it to systems of systems, and some examples of different types of systems of systems in the MITRE context.
  • Sociotechnical Aspects of SoS Systems Engineering addresses the various ways systems engineering of systems of systems goes beyond technical aspects of integrating systems. It also needs to consider the social, political, and economic aspects of the systems that affect how they can be adapted for the SoS, as well as comparable aspects of the systems engineering and management processes that will affect the approach to systems engineering of the SoS.
  • Challenges of Applying Systems Engineering to Systems of Systems as Systems reviews the major challenges the SE typically faces when applying systems engineering to systems of systems, along with current thinking on approaches to addressing these challenges.
  • Core Elements of SoS Systems Engineering presents the seven core elements that characterize systems engineering for systems of systems and that provide a framework for tailoring systems engineering processes to systems of systems as systems.

Characterizing Systems of Systems and Systems of Systems Engineering

Systems of systems engineering (SoSE) is "the process of planning, analyzing, organizing, and integrating the capabilities of a mix of existing and new systems into a system-of-systems capability that is greater than the sum of the capabilities of the constituent parts" [2].

In probably the best-known writing on systems of systems, Mark Maier postulated their five key characteristics: operational independence of constituent systems, managerial independence of constituent systems, geographical distribution, emergent behavior, and evolutionary development processes [3]. Maier identified operational independence and managerial independence as the two principal distinguishing characteristics for applying the term "systems of systems." A system that does not exhibit these two characteristics is not considered an SoS, regardless of the complexity or geographic distribution of its components [4]. As shown in Table 1, this emphasis on independence of the constituent systems as a driving characteristic is consistent across various definitions used in the systems engineering community today.

Table 1. Definitions of Systems of Systems



SE Body of Knowledge

A SoS is an integration of a finite number of constituent systems which are independent and operatable, and which are networked together for a period of time to achieve a certain higher goal. (Jamshidi 2009)

INCOSE SE Handbook

[A] system-of-interest whose elements are managerially and/or operationally independent systems. These interoperating and/or integrated collections of systems produce results unachievable by the individual systems alone.

ISO 15288 SoS Annex

A system of systems is a system-of-interest whose elements are themselves systems. The composite set of systems including system of interest, enabling systems and interacting systems, constitute a system of systems... In this case it is the system of systems which becomes the system of interest.

US DoD SoS SE Guide

A set or arrangement of systems that results when independent and useful systems are integrated into a larger system that delivers unique capabilities.

When systems of systems are recognized as systems, they are categorized into four types, as shown in Table 2.

Table 2. Types of Systems of Systems




Virtual systems of systems lack a central management authority and a centrally agreed-on purpose. Large-scale behavior emerges—and may be desirable—but this type of SoS must rely on relatively invisible mechanisms to maintain it.


In collaborative systems of systems, the component systems interact more or less voluntarily to fulfill agreed-on central purposes. The internet is a collaborative system. The Internet Engineering Task Force works out standards but has no power to enforce them. The central players collectively decide how to provide or deny service, thereby providing some means of enforcing and maintaining standards.


Acknowledged systems of systems have recognized objectives, a designated manager, and resources. However, the constituent systems retain their independent ownership, objectives, funding, development, and sustainment approaches. Changes in the systems are based on collaboration between the SoS and the system.


Directed systems of systems are those in which the integrated SoS is built and managed to fulfill specific purposes. It is centrally managed during long-term operation to continue to fulfill those purposes, as well as any new ones the system owners might want to address. The component systems maintain an ability to operate independently, but their normal operational mode is subordinated to the central managed purpose.

These types are based on the authority relationships between the systems and the SoS. In a directed SoS, all constituent systems fall under the authority of the SoS. They may have been developed independently with different stakeholders without knowledge of the SoS, but at the time the SoS is recognized, there is an SoS organization with authority over the constituent systems. At the other end of the spectrum, a virtual SoS has no top-down authority structure or single stated purpose, but like the internet, for example, is based on broad agreements, often driven by protocols and standards. Acknowledged and collaborative systems of systems are the most typical in the MITRE environment. In an acknowledged SoS, there is an SoS-level authority with responsibility for accomplishing the SoS capability objectives, but without control over the constituent systems. A collaborative SoS lacks a top-down authority; instead, the SoS is based on agreement among the constituents that working toward the SoS objectives will benefit them. Most actual systems of systems are some combination of these four, although typically one type dominates.

Why are these four types useful? The nature of the authority relations affects how systems engineering can be implemented. A typical misunderstanding in applying systems engineering to systems of systems is taking a top-down approach to SoS architecting and design, expecting that the technical decisions of the SoS can be dictated to the constituents. Even in a directed SoS, this approach can be problematic. If the constituents have been developed independently for other purposes and continue to support their original users, top-down technical decisions need to factor in the technical characteristics of the constituents and are often best developed with the cooperation of the constituent systems' managers and engineers. In other types of systems of systems, because the SoS does not have direct authority over the constituents, it is even more important to consider how the constituents can participate in SoS decisions that impact them.

The Importance of the SOS Environment

Beyond types, systems can take many forms, based in part on the nature of the SoS environment and on the degree to which the systems in the SoS are new or are in service and are being leveraged for a new need. Understanding the nature of the SoS is an important element in tailoring systems engineering to a particular SoS problem area.

Systems of systems can range from relatively straightforward networked technical systems to large, complex enterprises whose constituent systems may be organizations. Figure 1 shows examples across a spectrum of systems of systems.

Figure 1. Various Forms of Systems of Systems

MITRE customers face SoS issues across this spectrum, which highlights the sociotechnical components of systems of systems discussed in more detail in the next section. In the MITRE context, technical systems of systems are seen in areas such as air defense and sensor nets for border control. MITRE sociotechnical systems of systems include C systems, Medicaid, and broader US-VISIT applications. Finally, MITRE enterprise examples are growing to include areas such as healthcare and veterans affairs.

Systems of systems in the federal defense environment can be found in various domains. As shown in Figure 2, end-to-end missions, such as missile defense or satellite communications, are systems of systems that comprise multiple warfighting platforms working together in what has been called a kill chain, effects chain, or mission thread. In federal civilian agencies, the analog is end-to-end processes that require both hardware and software systems. This is the case for areas such as air traffic management and decennial Census operations. Military platform systems, which host other communications, sensor, mission, and weapons systems, are another typical form of SoS. Finally, networked information systems, to support command and control and other enterprise IT-based capabilities, are prevalent, and are typically one element of both mission and platform-based systems of systems. In some civilian agencies like the Federal Aviation Administration or the Department of Homeland Security, you may see similar SoS domain examples, whereas in others, IT-based systems of systems will dominate. Although each domain has specific considerations, some considerations apply across the board.

Figure 2. Domains of Systems of Systems in Defense

Implications for Systems Engineering of Systems of Systems

Characteristics of systems of systems, which differentiate systems of systems from new systems providing a specific product or service, affect the way product-based systems engineering approaches can be applied to systems of systems. When SEs conversant with systems engineering for systems begin to work with systems of systems as systems, understanding these differences and their impacts is important. Table 3 compares systems engineering for product systems and systems of systems and shows that the independence of the constituents from the SoS affects almost all aspects of systems engineering, including management, operational objectives, implementation, and finally, engineering and test and evaluation.

Table 3. Comparison of Systems and Systems of Systems [5]

Aspect of Environment


Acknowledged System-of-Systems

Management & Oversight

Stakeholder Involvement

Clearer set of stakeholders

Stakeholders at both system level and SoS level, including system owners with competing interests and priorities. In some cases, the system stakeholder has no vested interest in the SoS; all stakeholders may not be recognized.


Aligned program management and funding

Added levels of complexity due to management and funding for both the SoS and individual systems. The SoS does not have authority over all the systems.

Operational Environment

Operational Focus

Designed and developed to meet operational objectives

Called on to meet a set of operational objectives using systems whose objectives may or may not align with the SoS objectives.



Aligned with acquisition milestones and documented requirements, program has a systems engineering plan

Added complexity due to multiple system life cycles across acquisition programs, involving legacy systems, developmental systems, new developments, and technology insertion. Typically, they have stated capability objectives upfront that may need to be translated into formal requirements.

Test & Evaluation

Test and evaluation of the system is generally possible

Testing is more challenging due to the difficulty of synchronizing across multiple systems' life cycles, given the complexity of all the moving parts and potential for unintended consequences.

Engineering & Design Considerations

Boundaries & Interfaces

Focuses on boundaries and interfaces for the single system

Focus is on identifying systems that contribute to the SoS objectives and enabling the flow of data, control, and functionality across the SoS while balancing needs of the systems.

Performance & Behavior

Performance of the system to meet specified objectives

Performance across the SoS satisfies SoS user capability needs while balancing needs of the systems.

Sociotechnical Aspects of SoS Systems Engineering

Important general considerations for systems engineering applied to systems of systems are its sociotechnical aspects. Even for technical systems of systems, bringing together systems and their engineering teams into a new environment has sociotechnical implications.

Constituent systems in most systems of systems, particularly in-service systems, bring with them their own stakeholders, users, own objectives and priorities, and engineering development processes, as well as their own operating processes. So when you bring the systems together into an SoS, these all need to be considered.

Operating Processes

In an SoS that includes systems already in operation, the impacts of the constituent systems' operating processes on the architecture and design of the SoS need to be considered. How will the systems operation be affected with the implementation of the SoS? For example, in integrating multiple IT systems into an enterprise information capability, it is important to understand current needs and constraints on the constituent systems to ensure that any proposed SoS architecture accommodates continuing uses and identifies new considerations (e.g., privacy) raised with the integration across the systems. Bringing existing systems into a new environment involves social, economic, and political (legal) considerations.

Development and Engineering Approaches of the Systems and SoS

In an SoS that includes systems already in place, the approach to systems engineering needs to consider the development/engineering approaches of the systems and their impacts. Considerations include the state of development of the constituents (e.g., in development, fielded, evolving), their development or life-cycle approaches, and their development schedules. These can all place limits on the architecture of the SoS and will introduce complexity if different constituent systems are on different development timelines, making it difficult to synchronize across the SoS. Different systems using different "style[s] of development" (as described for plan-based versus agile in Boehm and Turner [6]) can also challenge the SoS engineering process, particularly when the SE teams for different constituents have very different ideas about appropriate development approaches.

Systems of Systems as Sociotechnical Systems

Finally, in some cases the SoS itself may be sociotechnical, comprising people, organizations, and processes, as well as their technical systems. Very often, addressing enterprise issues requires assessing how different independent organizations work together as systems to achieve broader objectives, such as effective, affordable healthcare or transportation. In these cases, viewing the enterprise itself as a sociotechnical SoS can be important to an effective systems engineering approach.

Challenges of Applying Systems Engineering to Systems of Systems as Systems

The INCOSE SoS Working Group identified set of common challenges, called "SoS Pain Points," facing SEs applying systems engineering to systems of systems [7]. These pain points reflect the types of challenges found in the MITRE systems engineering environment.

SoS Authorities

Given the characteristics of systems of systems, it is not surprising that the lack of a central SoS authority for management and systems engineering is a core challenge for systems of systems engineering (SoSE). Very often, MITRE customers are calling for a cross-cutting, enterprise capability that requires action across different independent organizations. Developing the right set of agreements and relationships to create the environment of cooperation across systems to meet SoS objectives can be one of the largest challenges. From a technical perspective, this means that a broader set of technical options for SoS architecture and design needs to be considered, and the needs and technical characteristics of the constituent systems need to be factored into SoS options and trades because they can significantly affect the viability of an SoS initiative.


Without a preset, top-level authority, and given diversity across constituents and SoS considerations, effective SoS leadership can be critical to the success of an SoS. Unless an individual or organization takes a holistic view of the SoS, it can be difficult to bring the constituents into a forum where they can work together to address SoS capabilities needs. As the operator of multiple federally funded research and development centers, MITRE is well positioned to take a leadership role in SoS initiatives, employing our strong technical perspective and ability to work across government programs and agencies, and with industry and our international partners.

Constituent Systems Perspectives

A significant technical and organizational challenge in an SoS is balancing the demands of a new SoS with the ongoing and established needs of existing constituent systems. Systems developed independently for specific user needs may not be technically structured to participate as constituents in an SoS. This is especially true if independent systems are continuing to meet the needs of the current users and therefore may have a strong commitment to the current users and limited technical development resources. SoS SEs need to understand the key elements of the constituent systems and their environment and factor them into the technical and engineering approach for the SoS.

Capabilities and Requirements

An SoS typically addresses a set of cross-cutting user needs and capabilities through the effective use of functions or services provided by a set of systems. A challenge facing SEs is capturing the needed capabilities in such a way that the potential constituent systems' support to these capabilities can be analyzed and assembled to meet SoS needs. This typically means that SoS needs are defined in terms of high-level capability objectives, which are met by systems often requiring changes in the system requirements to meet SoS capability objectives. In this case, the SoS becomes in a sense a user of the constituent system and is adding to the system requirements. Treating the SoS needs as high-level capability needs leaves open a wide range of possible approaches to meeting these needs that detail SoS requirements. Because many systems of systems must leverage existing systems as much as possible, it is advantageous to allow for a variety of alternatives to achieving SoS objectives, while allowing for the constraints the constituent systems impose.

Autonomy, Interdependencies, and Emergence

In general, the goal of an SoS is to create emergent behavior—that is, new capabilities not available from the constituent systems acting independently. The challenge facing SEs, especially in an SoS whose constituent systems are themselves mature, complex systems, is assembling systems to deliver SoS capabilities without leading to other unintended and undesirable emergent behavior. Though systems may be autonomous from the ownership and operational perspectives, interdependencies among the systems need to be considered in the SoS architecture and design if the SoS is to be sufficiently robust against the inevitable changes in the constituents. How to architect and evolve an SoS in light of constituent system autonomy, independence, and emergence is a major challenge.

Testing, Validation, and Learning

In an SoS where systems maintain their own asynchronous development schedules, the SoS SE faces challenges in integration, validation, and testing. New system changes may be introduced on a somewhat ongoing basis, and it may not be possible to test even sets of systems prior to delivery of new constituent system capability. In a large operational SoS, testing the SoS in full can be impractical. This situation challenges the SE to develop approaches to architecting the SoS to minimize the impacts of changes in one part of the SoS on other parts and other systems; assess the risk of changes in systems, including monitoring the constituent system plans for any proposed changes before they cause SoS disruptions; and collect data to analyze SoS effects from a wide variety of sources, including modeling and simulation, system testing, and operations, to learn about SoS behavior over time when traditional approaches to test and evaluation are not applicable.

SoS Principles

Finally, the INCOSE Pain Points project identified the lack of a set of SoS principles that can be used as the basis for future SoS systems engineering initiatives. As SoS systems engineering becomes more widely practiced, a growing set of systems engineering community activities provide forums for developing and sharing SoS systems engineering experiences, lessons learned, and tenets that contribute to the larger SoS systems engineering body of knowledge. Additions to the ISO IEC 15288 Systems Engineering Life Cycle Processes (June 2015) address systems of systems. The SoS knowledge area of the Systems Engineering Body of Knowledge is dedicated to tracking the state of the practices in SoS systems engineering with regular updates. Within MITRE, SEs can gather and share SoS experiences and approaches through the systems engineering technical center and the SoS capability Action Team and provide them to the broader systems engineering community through this Systems Engineering Guide and online SoS toolkits.

Core Elements of SoS Systems Engineering

In view of the preceding SoS characteristics and their implications for SoS systems engineering, a set of core elements that characterize the application of systems engineering to systems of systems have been developed (DoD SoS SE Guide). Although they came from the defense community, they tend to apply more broadly.

Seven core elements characterize systems engineering for systems of systems and provide a framework for tailoring systems engineering processes to systems of systems as systems. These elements are implemented when an SoS is first created, and they persist as the SoS evolves and changes in the larger environment impact the SoS and systems' objectives, performance, and development approaches because most systems of systems exist over an extended time and evolve to address these changes.

  1. Begin with an understanding of SoS capability objectives. Systems engineering is an approach to meeting user needs, so the starting point for SoS systems engineering is understanding the capability objectives for the SoS. In the past, there has been a focus on "interoperability" without a good understand of the end to be achieved, but a shared understanding of what the SoS is intended to achieve provides the basis to assess options and make design systems trades.
  2. Assess the extent to which these capability objectives are being addressed. Almost all systems of systems start with an existing capability. Therefore, it is important to measure the degree to which the current capability is meeting the SoS objectives, and if not, why not, and to identify the gaps and their sources. This provides the capability baseline for SoS systems engineering.

It can be tempting to look at an SoS from a clean-sheet or greenfield perspective, and wonder, "If I were starting fresh, how would I design a system to meet the SoS capability needs?" This may be possible; however, it is critical to understand the current state of the SoS as a point of departure for evaluating options, including the degree to which the current situation is meeting user needs.

  1. Understand the systems that contribute to the SoS and their relationships. In most cases today, affordability is forcing consideration of reusing or repurposing current systems. When operating in an SoS, it is important to clearly understand the systems that are currently supporting the SoS capability and those that are considered as candidates for the SoS. This includes not only the technical characteristics of the system (functionality/services, performance, interfaces, etc.), but also the organizational and programmatic characteristics (who owns the system, who are the key users and stakeholders, current funding, short- and long-term objectives including the relationship to SoS objectives), and the development context (in development or in service, development process and cycle, etc.). These nontechnical aspects of the system can be as important to the systems engineering for the SoS as the technical capabilities.
  2. Develop an architecture for the SoS that acts as a persistent framework for SoS evolution. Probably the most import technical element of SoS systems engineering is the development of the SoS architecture. The SoS architecture addresses the concept of operations for the SoS and describes the functions/services, relationships, and dependencies of constituent systems, the end-to-end functionality and data flow, as well as the interfaces and communications among the systems in the SoS. In developing the architecture, the SE identifies options, makes design trades, and provides feedback when there are barriers to achieving balance between the SoS and users' needs and system constraints. The SoS architecture may be implemented over time because introducing a new architecture to an existing set of systems will require changes to the systems. Once in place, this architecture provides the persistent framework for evolution of the systems and their functionality to improve the ability of the SoS to provide user capabilities. Ideally, an SoS architecture is based on open systems and loose coupling that impinges on the systems as little as possible, accommodating the needs of systems themselves, which may call for changes independent of the SoS and its demands.
  3. Evaluate SoS requirements and solution options considering both the SoS and constituent systems. Gaps in the SoS ability to meet capability objectives may be addressed either by changes in the SoS architecture through changes in the systems that make up the SoS or by changes in the functionality/services or performance of the constituent systems. Particularly if the systems continue to support their original user needs (or other SoS capabilities), determining the changes in the systems to meet SoS needs will need to be done cooperatively with the systems. This is certainly the case when the SoS does not have authority over the systems, but even if the SoS is directed, the SEs for the systems will have the best understanding of what changes can be made in the systems to both support user needs and satisfy the system requirements.
  4. Orchestrate enhancements to the SoS, monitoring and integrating changes made in the systems to improve the performance of the SoS. In an SoS, any new development is typically done by the systems. Even when new infrastructure is developed and fielded to support SoS assembly and operations, this is in effect a new system that will have requirements, architecture, design, etc., just like other systems in the SoS. The role of the SoS SE is to monitor and facilitate the developments by the systems and address issues and risks, as well as coordinate any integration or testing actions involved with the changes.
  5. Monitor and assess (anticipate) the impact of external changes on the SoS. One of the major sources of risk to an SoS is in changes made to the systems that impact the SoS. This means that it is important for the SoS SE to develop mechanisms to track the plans of key constituent systems and asses their impact on the SoS. This may be done in an SoS or other enterprise forum. In some cases, it can be most effective if the SoS systems engineering team participates in the configuration management forums for the systems that are most critical to the SoS.

Lessons Learned and Best Practices

A summary of the good practice for SoSE is provided in NATO Lecture Series SCI276-09: Good Practice in Systems of Systems Engineering (SoSE) by Professor Michael Henshaw of Loughborough University.

In his lecture, Henshaw outlines the following good practices for SoSE [8]:

  • Ensure that participants in the SoS recognize that it is an SoS, as opposed to a single system. This can be achieved through education and encouraging critical thinking.
  • Encourage a service-based view of the SoS; this will help with understanding how systems of systems realize capabilities and will also support better identification of options for reconfiguration to meet changing circumstances.
  • Understand which type of SoS is under consideration. This is essential for understanding authority and, hence, decision-making structures in the SoS. It is also important from the point of view of understanding where ownership of risk resides in the SoS.
  • Focus on relationships between systems; this is the SoS perspective, in which the SoS SE is concerned with interactions between systems rather than the inner working of the constituent systems.
  • Both formal and informal relationships are present in an SoS; trust is an important aspect of operating systems of systems. It is a significant issue with regard to the management of information on which decisions are based.
  • Share information with other participants to give them situational awareness. It is important that participants in different parts of the SoS have a shared understanding of its operation. It is good practice to ensure that the status of your system and what its next actions will be are communicated to other system owners who will be affected by the operation of your system.
  • Recognize that many issues for systems of systems are nontechnical (i.e., social, political, economic, etc.). Much of the good practice for SoSE is focused on the nontechnical aspects—not because the technical aspects are unimportant, but because it is the nontechnical aspects that mainly give rise to failures and unexpected emergent behaviors.
  • Thoroughly understand the extant SoS, including well-documented and up-to-date architecture. To make decisions about reconfiguring the SoS to meet prevailing conditions, it is essential that the behavior of the extant SoS be understood, so that appropriate reconfiguration options can be considered and the resultant emergent behaviors can be predicted, or at least anticipated.
  • Build constituent systems on the basis of modular architecture because this makes changes easier to implement and may allow more rapid reconfiguration.
  • Use an open architecture approach whenever feasible. Open architectures enable commercial, technical, and operational agility in an SoS.
  • Use open standards to reduce the risk of interoperability problems between constituent systems. Reuse systems and solutions wherever possible (including architecture patterns); deploy tried and tested solutions to reduce risks, reduce the costs (associated with new developments), and reduce diversity so that reconfiguration can be achieved rapidly.

References and Resources

  1. U.S. Department of Defense, 2008, Guide to Systems Engineering for Systems of Systems. Accessed November 21, 2017.
  2. T. Saunders, et al, "United States Air Force Scientific Advisory Board Report on System of Systems Engineering for Air Force Capability Development," SAB-TR-05-04, July 2005.
  3. Maier, M., January 2013, Architecting Principles for Systems of Systems, INCOSE IW MBSE workshop slides.
  4. SEBoK, v 1.8.
  5. DoD, Systems Engineering Guide for Systems of Systems, 2008, p. 11.
  6. Boehm, B., and R. Turner, 2004, Balancing Agility and Discipline: A Guide for the Perplexed, Boston: Addison-Wesley.
  7. Dahmann, J., 2014 "Systems of systems pain points," Presented at INCOSE International Symposium, Las Vegas, NV, p. 7.
  8. Henshaw, M., "Good practice in systems of systems engineering (SoSE)," 2015, NATO Systems of Systems Lecture Series, SCI276 Lecture Series, CSO.

Additional References and Resources

Checkland, P. B., 1981, Systems Thinking, Systems Practice. Chichester, West Sussex, England, UK: John Wiley & Sons, Ltd.

Hubbard, E-M., C. E. Siemieniuch, M. A. Sinclair, and A. Hodgson. 2010. "Working towards a holistic organisational systems model." Presented at 5th Int. Conf. Systems of Systems Engineering (SoSE), June 22-24, 2010, Loughborough, UK.

INCOSE Vision 2025.

Rhodes, D. H., A. M. Ross, and D. J. Nightingale, 2009, Architecting the system of systems enterprise: Enabling constructs and methods from the field of engineering systems, Proceedings of Systems Conference, 3rd Annual IEEE, pp. 190–195.

Tannenbaum, S. I., E. Salas, and J. A. Cannon-Bowers, 1996, Promoting Team Effectiveness, in Handbook of Work Group Psychology, edited by M. A. West, Chichester, West Sussex, England, UK: John Wiley & Sons, Ltd.


Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Contact the SEG Team