**1. Introduction**

In the past twenty years, US DoD has been undergoing three major transformations concerning the way to (i) fight, (ii) conduct business, and (iii) collaborate with allied countries. These transformations have led to significant changes in US DoD acquisition process, moving away from requirement-based to capability-based acquisition, the adaptation of the Joint Capability Integration & Development System (JCIDS) and Systems-of-Systems perspective in the design and build of future space systems [1–6]. **Figure 1** illustrates the key differences between the requirement-based and capability-based approaches. The red dotted line shown in **Figure 1** denotes the area of responsibility between the US Government (USG)1 and its selected contractor. For requirement-based, the US DoD is responsible for (i) defining the reference system architecture, architecture performance attributes (APAs) and associated key performance parameters (KPP), and architecture trade-space, and (ii) developing Level-A specifications (spec) that can potentially

<sup>1</sup> Practically, USG team refers pre-Milestone A acquisition activities as the pre-award phase in the US Department of Defense (DoD) acquisition life cycle.

#### **Figure 1.**

*Description of requirement-based and capability-based approaches.*

achieving optimum KPP within the defined trade-space. A selected defense contractor is responsible for using the Level A spec to derive lower level requirements (subsystems and components), design and build the system.

Unlike requirement-based approach, the capability-based approach requires USG to define user objectives and provide required capabilities for meeting warfighter needs. As shown in **Figure 1**, USG is also responsible for providing technical objectives and goals documents along with the Initial Capability Document (ICD)2 that presents APAs, required capabilities, threshold, and objective criteria for meeting the required capabilities. On the other hand, a selected contractor is responsible for defining the architecture trade space and developing appropriate "TBD" documents for the derivation of Level A spec using the USG's ICD and inputs (e.g., evolving adversary threats, existing US DoD systems' capabilities, etc). The "TBD" documents shown in **Figure 1** are dependent on the acquisition phase. The "TBD" document can be a Capability Development Document (CDD) or a Revised-CDD3 . Like requirement-based approach, the selected contractor is also responsible for the (i) flow-down of Level A spec to lower level requirements, and (ii) design and build of the systems. For some defense system acquisition programs, USG also provides Technical Requirement Document (TRD) or System Requirement Document (SRD) along with the ICD to help the selected contractor concentrates on specific operational use cases, APAs and KPPs.

Designing a system for operation in complex Systems-of-Systems environment requires a good understanding of the types of systems-of-systems that the designed system would be operated in. There are three types of Systems-of-Systems, namely, Type 1: A family of System-of-Systems that provides similar core services, e.g., communication services - But each system provides different core service types, e.g., non-secure FDMA vs. secure TDMA communication services; Type 2: An integration of many families of System-of-Systems, when combined, this type of system provides unique Systems-of-Systems capabilities at the enterprise level (i.e., integrated level) - An example of this complex system is a combination of a family

<sup>2</sup> Per JCIDS process, the required system capabilities are usually provided in ICD.

<sup>3</sup> Formerly known as Capability Production Document.

#### *Systems-of-Systems MS&A for Complex Systems, Gaming and Decision for Space Systems DOI: http://dx.doi.org/10.5772/intechopen.100007*

of communications Systems with a family of Global Position Satellite systems; and Type 3: An integration of many heterogenous, independent but interrelated types of systems with each system providing distinctive core services.

As pointed out in [7], most of current professional papers, technical reports and System-of-Systems standards considered integration of (i) many systems of the same type of systems together, which is identical to Type 1, and (ii) many different types of systems as a system consisted of many systems and referred to as Systemof-Systems, which is identical to Type 3. In this chapter, we focus our discussion on Type 2, since existing System-of-Systems engineering standards and current MS&A approaches can be directly applied to Type 1 and Type 3 but not Type 2.

This chapter presents advanced concepts on systems-of-systems MS&A approaches to support capability-based acquisition of defense space systems. The MS&A frameworks and processes presented here are emphasized on the systemsof-systems architecture trade support phase of the US DoD defense acquisition life cycle. In addition, it addresses systems-of-systems MS&A frameworks, processes, models and tools using game theoretical modeling and DSS for developing optimum acquisition strategy to acquire complex systems. The complex systems discussed in this chapter are mainly focused on defense space systems, but they can be extended to any systems-of-systems for civilian and commercial applications.

The chapter is organized as follow: (i) Section 2 presents an advanced capabilitybased MS&A framework, including processes and required MS&A tools, to support US DoD acquisition life cycle from the system architecture design phase to sustainment phase; (ii) Section 3 describes a MS&A approach supporting architecture design and analysis of complex systems using systems-of-systems perspective; (iii) Section 4 provides a MS&A approach for acquisition strategy development and optimization supporting pre-award phase; (iv) Section 5 describes existing available systems-ofsystems MS&A models and tools supporting the pre-award phase of the acquisition life cycle; and (v) Section 6 concludes the chapter with a conclusion and way-forward.
