System of Systems Capability to Requirements

Given an existing set of interconnected, independent systems, often referred to as a system of systems (SoS), one of the key activities according to the United States Department of Defense Systems Engineering Guide for Systems of Systems is “translating SoS capability objectives into high-level SoS requirements”. Capability engineering starts with understanding the desired capability and identifying various options for achieving that capability, technically assessing the various alternatives, then further evaluating the most viable alternatives in terms of capability performance, cost, and schedule. This paper provides additional guidance for translating capability objectives into requirements; defines SoS engineering methods, processes, and tools that might support this activity; and illustrates how the methods, processes, and tools would be used and integrated to support SoS engineering using an example SoS. Introduction Given an existing set of interconnected, independent systems, often referred to as a system of systems (SoS), one of the key activities according to the DoD Systems Engineering Guide for Systems of Systems [1] is Translating SoS Capability Objectives into High-Level SoS Requirements. According to the DoD SoS guidebook: When a formal SoS is first identified, the systems engineering team is called upon to understand and articulate the technical-level expectations for the SoS. SoS objectives are typically couched in terms of needed capabilities, and the systems engineer is responsible for working with the SoS manager and users to translate these into high-level requirements that can provide the foundation for the technical planning to evolve the capability over time. To accomplish this, the SoS SE team needs to understand the nature and the dynamics of the SoS both to appreciate the context for SoS expectations and to anticipate areas of the SoS that are most likely to vary in implementation and change over time. The SoS systems engineer has a continuous active role in this ongoing process of translating capability needs into technical requirements and identifying new needs as the situation changes and the SoS evolves. The DoD SoS guidebook further discusses this activity in more detail: At the outset of an SoS effort, one of the first tasks facing the SoS manager and systems engineer is to develop a basic understanding of the expectations for the SoS and the core requirements for meeting these expectations. In an SoS, objectives are often stated in terms of broad capabilities. The SoS systems engineer and manager review objectives and expectations on a regular basis as the SoS evolves and changes occur in user needs, the technical and threat environments, and other areas. The SoS SE team also provides feedback to the manager and stakeholders on the viability of meeting SoS objectives, particularly given the results of other SoS SE core elements. This SoS SE core element involves codifying the SoS capability objective, which may be stated at a high level, leaving the task of clarifying and operationalizing the objectives and expectations to the SoS manager, systems engineer, and stakeholders. The following examples illustrate the type of capability objectives an SoS might have:  Provide satellite communications (MILSATCOM)  Provide global missile defense (BMD)  Provide a single view of the battle space for all customers (SIAP) Once the SoS establishes the capability objective (often based upon desired operational tasks and missions), the SoS SE team defines the functions required to provide the capability and the variability in the user environment which will impact the different ways these functions will be executed. The articulation of objectives may be somewhat general at the outset, but as the SoS and SE processes mature, the objectives become more focused and they may change. ‘Reference missions’ or ‘use cases’ can be developed to evaluate the operational utility of the SoS and derive requirements that directly address usability of the SoS in the operational environment. Working with the SoS manager, users, and stakeholders, the systems engineer plays an important role in articulating capability objectives. This activity provides the systems engineer with a broader understanding of priorities and relationships, and that understanding will be useful in the further development and management of requirements. The product of this element is a set of requirements ready for incorporation to a future functional baseline for the SoS. Within this core element the systems engineer develops a broad understanding of the context and drivers for the SoS. Beyond the specific functionality needs, it is very important for the systems engineer to have a good understanding of the motivation for the SoS, particularly the need to be more responsive to the increasing change tempo of the battle space, be it cyberspace, non-nation state terrorism, or health care management for veterans. Because SoS tend to evolve over time, the systems engineer needs to understand and continue to track the dynamics of change as they influence the SoS objectives and expectations. This provides the drivers for the SoS SE element ‘monitoring and assessing change’; in effect, it provides the context to help the systems engineer anticipate the type of changes and variability the SoS will need to address over time. As illustrated in figure 1, capability engineering starts with understanding the desired capability and identifying various options for achieving that capability. Initial capability engineering is typically done by assessing available resources and assets to identify existing functions from which the new capability can be composed (AF SAB report), followed by a gap analysis for each alternative identified. Finally, each alternative is further evaluated in terms of capability performance, cost, and schedule resulting in information that can be used to support the trade decision. Figure 1. Overview of Translating Capabilities into Requirements. The goal of this research effort was to:  Provide additional guidance for translating capability objectives into requirements  Define SoS engineering (SoSE) methods, processes, and tools (MPTs) that might support this activity  Illustrate how the SoSE MPTs would be used and integrated to support SoS engineering using Regional Area Crisis Response SoS (RACRS) example While many of the techniques and methods described here are not new, they are used in ways tailored to support SoS and SoSE analyses and integrated together through a process to support capability-torequirements engineering in a more rigorous, repeatable manner, resulting in meaningful information about alternatives that can be used to support a final decision on how the capability will be implemented. The MPTs described here are illustrated using a notional example, the Regional Area Crisis Response System (RACRS), described in [2]. This example has been developed to support research using actual systems in the public domain that are employed to respond to regional crisis situations [2]. RACRS Background The motivation for RACRS, as described in [2], is based upon recent catastrophes that have happened in recent years within the United States: hurricane Katrina, devastating fires in California, powerful earthquakes in the western United States, and tornadoes in the Midwest United States. Early responders to these incidents found that communications between the different local agencies was difficult at best and often not integrated. When state and federal agencies became involved, the communications problems escalated. As a result, efforts have been initiated to establish a way to better integrate the needed agencies in response to a given incident. The goal is that the agencies will generally operate on their own outside of the SoS, then quickly be able to dynamically reconfigure and join the regional SoS as needed, typically in response to an incident. Overview of Capability-to-Requirements MPTs The Capability-to-Requirements process is illustrated in figure 2. This figure identifies techniques and methods that can be used to support the engineering activities associated with each step. Figure 2. Capabilities-to-Requirements Tools to Support Engineering Activities. The following sections describe each of the tools and how they are used in the capability-torequirements engineering process. UML Object Models Several UML object models are used to understand the SoS and its constituent systems as well as to identify/understand single system functions that can be used to develop new capabilities and to assess and define the various options for implementing a new capability. These models begin with “black box” models to understand the SoS and its constituents at a high level and evolve to “white box” models that capture the internal information about the constituent systems needed to understand options for various SoS capabilities. These SoS models, described in [2], include: Black box models a. Context diagrams: Identifies systems of interest in the SoS from selected system viewpoints as well as who and what will interact and what types of information will be passed. b. Use case diagrams: Describe how the SoS capabilities of interest work. These diagrams can be used to model the “as is” SoS capabilities as well as alternative “to be” options for the new capability. c. Sequence diagrams: Illustrates the sequence of requests and responses that flow within the SoS environment for capabilities of interest. White box models: a. Constituent system entities: Describes the key functions and single system capabilities that can be performed by the single system. b. Interface entities: Describes the each interface in the SoS and the information that goes over that interface. c. Input/Output (I/O) entities: Describes the details of each data element type that goes over the various interfaces. Responsibility/Dependability Modeling Re