Engineering Systems in the Context of Systems of Systems


Definition: Engineering systems in the context of systems of systems describe the considerations to be addressed in the engineering of systems at each stage of the system life cycle.

Keywords: architecture, concept development requirements, systems engineering, systems of systems,

MITRE SE Roles and Expectations: MITRE regularly supports sponsors in the engineering of new systems and system upgrades. In this role, it is important to recognize the larger system of systems context where the systems will be deployed and ensure that the impacts of this larger context are explicitly considered in the engineering of the systems from concept through deployment.

Today, few systems stand alone. When we engineer new products or services, we must also factor in the effect of the system context, from systems conceptualization through to end of life. At each step in the system life cycle, important aspects of the SoS environment should be factored into decisions about the system being engineered. The consideration of context is not new to systems engineering, but the emphasis has increased in today's complex, interconnected world.

The SEG's section SE Life-Cycle Building Blocks describes the major activities that constitute how a MITRE systems engineer (SE) orchestrates the complete development of a system, from need, through operations, to retirement. It highlights the specific questions an SE should address to ensure that the key SoS considerations have been addressed so that the system, when deployed, will operate effectively to meet broader user needs.

Concept Development

"This first phase is concerned with transforming a user's expression of an operational need into a well-defined concept of operations, a high-level conceptual definition, and a set of initial operational requirements." [1]

Starting with the early concept, it is important to consider the context in which a system will be employed. This means that at concept development, the larger business or operational context must be understood. This understanding can be achieved by asking the following questions:

  • Has the operational or business context been described?
    • Is there an understanding of how any new system would fit into current operations (modularity)?
    • Have constraints imposed on the candidate solutions by the collection of systems been identified?
  • Have non-material approaches and factors of the collection of systems (e.g., personnel, training, operations, other) been considered?
  • Have the affected external stakeholders or systems/infrastructure been identified? This includes both:
    • Systems/services on which the new or upgraded system depends
    • Systems/services that depend on the new or upgraded system
  • Have interfaces with, or required changes to, current/legacy systems or infrastructure been identified?
    • Is there an understanding of how resource changes will be received in associated systems, infrastructure, or non-material factors (i.e., are they flexible or rigid)?

At concept development, a clear and early understanding of the SoS context and its potential impact on system requirements and dependencies will provide a solid basis for developing a system that will meet users' needs. Understanding SoS context constraints, and identifying potential interface and infrastructure changes allow for organizational negotiations and agreements to be put in place. It also allows for timely analysis of whether changes should be implemented and identifies where changes can best be implemented before a system concept is selected. Considering non-material factors early provides sufficient lead time to address cross-organizational enablers such as resources, organization impact, training, personnel multi-role postings, and recruitment focus.

Requirements Engineering

"In this phase, detailed system requirements are elicited from the user and other stakeholders, the requirements are further analyzed and refined, and plans and processes for managing the requirements throughout the rest of the system life cycle are developed." [1]

Engineering requirements need to consider the larger context in which the system will be employed. These considerations, which users or stakeholders may or may not provide, could impact the usability of the systems if not included. In particular, requirements engineering in the SoS context should address these questions:

  • Is there an updated description of how the users will conduct the operation, including:
    • How will the system be used in conjunction with other systems?
    • Is this description captured in the user statement of need?
  • What added (implied) requirements does the SoS context impose on the system? What is the significance of these requirements? Some examples of implied requirements include:
    • Information exchange/management (e.g., network, bandwidth, information needs)
    • Physical requirements (e.g., size, power limits)
    • Electronic requirements (e.g., signature, interference)
    • Protocols and standards
  • What are the external dependencies and interfaces for the system? Have they been reflected in the requirements?
    • Do the owners of these systems acknowledge these dependencies?
    • Will the new system impact these systems, and if so, to what degree? Have these interactions been addressed?
  • Have these dependencies been reviewed to identify impacts on the system requirements? Have the results of this review been included in the statement of requirements?
    • Potential focused reviews could include constraints, coherence (including reuse and evolution considerations), system attributes, interfaces or interactions with other systems, or other design considerations.
  • For considerations that involve interactions with other systems, have the specifications been negotiated with the others involved? Have costs associated with the external systems been incorporated into the cost estimates for these external systems?
    • This could include costs to upgrade, planning costs, and costs of integration and test.
  • Are there plans to monitor progress in addressing cross-system dependencies to allow for timely identification of changes or delays that could result in added costs?
  • Have the schedules for the external systems, including the sequence of events and associated dependencies, been considered in the system planning and scheduling?

Maintaining a clear, updated understanding of the system's context and its potential impact on system requirements and dependencies is critical to ensuring a full set of requirements because dependencies can be critical to system success in meeting user needs. Identifying where other systems are key to a system's success and establishing early commitments for cooperation can provide the basis for successful collaboration throughout development. A clear approach to addressing these external considerations in the system technical plans, including schedules and costs, is key to ensuring that they will be addressed as an integral part of the systems engineering process.

System Architecture and Design

"The architecture will be the foundation for further development, integration, testing, operation, interfacing, and improvement of the system as time goes on. … A complete and comprehensive description of what and how the system is expected to perform has been developed along with an architectural representation to guide the actual design and development of the hardware, software, and interfaces." [1]

Architecting and designing a system to operate in an operational or business environment depends on addressing the dependencies and interactions with external systems, including systems infrastructure. Ideally, these will be reflected in the system requirements and specifications. It is important that these requirements be instantiated in the architecture and the design, in coordination with the owners of the external systems. The types of questions to be addressed at this point include:

  • Have any changes in how the users will conduct the operation or use the system throughout the system's life cycle been considered in the architecture and design?
  • Has the architecture and design considered the constraints imposed on the system by the SoS context? What is the significance of these constraints? Considerations include:
    • Information exchange/management (e.g., network, bandwidth, information needs)
    • Physical requirements (e.g., size, power limits)
    • Electronic requirements (e.g., signature, interference)
    • Protocols and standards
  • Have architecture and design features that involve interactions with other systems (e.g., interfaces, new or changed functionality in other systems) been negotiated with the others involved?
  • When technical trade-offs need to be made for this system, how are the impacts on the SoS/mission thread, or system coherence with the broader system (enterprise), considered?
  • Have plans been implemented to monitor progress in addressing cross-system dependencies, allowing for timely identification of changes or delays that could result in added costs?
  • Have the schedules for the external systems, including the sequence of events and associated dependencies, been considered in the plans for implementing the architecture and design?
  • Are there potential internal interfaces that may need to be exposed in the future to support evolving SoS needs?
  • What management arrangements have been made with other systems that impact this system? Have these arrangements been implemented?           

Ensuring that the system architecture and design effectively factor in the SoS considerations as reflected in the system requirements is critical. Specific attention needs to be paid to this key step, which will define the actual capabilities of the system to operate in the SoS environment where the system will be employed.

Systems Development, Integration, and Test and Evaluation

"During the design and development phase, all of the system's subsystems are complete. In the system integration phase, the system's components and its interfaces with other systems are integrated into an operational whole. … It is now necessary to test." [1]

Addressing SoS considerations in the concept, requirements, and architecture and design phases will lay the foundation for successful integration and testing, which will ensure that the system operates effectively in the context where it will be employed. The system is tested to see if it fulfills the users' needs (verification) and all the defined requirements (validation).

Implementation, Operations and Maintenance, and Transition

"Finally, to ensure a successful transition of the system into the field, plans, and procedures must be developed for operations and maintenance." [1]

The major focus for SoS considerations at this stage is the periodic reviews typically conducted of fielded systems. These "in-service" reviews are conducted to provide feedback on:

  • How well the system delivers an acceptable capability to the user
  • Whether the performance is acceptable to the user
  • How well the system is positioned to meet emerging or future user needs

To address SoS considerations in these reviews, several useful questions include:

  • Has the business or operational context for use of the system changed since the system was fielded? If so, how do the changes affect how the system needs to work with other systems?
  • If the operational context of the system has changed, how do these changes affect the system? This includes:
    • Physical requirements (e.g., size, weight, cooling, power limits)
    • Electronic requirements (e.g., signature, interference)
    • Environmental requirements (e.g., safety, environment, chemical, biological, radiological, and nuclear)
    • Information exchange/management (e.g., security, network, bandwidth, information needs, security)

The answers to these questions provide the basis for changes or upgrades to fielded systems to ensure that they continue to operate effectively in their dynamic business and operational environments.

Best Practices and Lessons Learned

Best practices have been documented in by an international group under The Technical Cooperation Program (TTCP), an international organization that collaborates in defense scientific and technical information exchange, program harmonization and alignment, and shared research activities for five nations. The material in this section reflects the recommended practices in the TTCP guide.

References and Resources

  1. From the SEG's SE Life-Cycle Building Blocks topic introduction article.

Additional References and Resources

Brooks, P., 2015, "Enterprise and the Technology Environment," NATO Systems of Systems Lecture Series, 2015, SCI276 Lecture Series, CSO.

Dahmann, J., K. Baldwin, A. Jakobsen, and D. Bertrand, 2015, "," Paper presented at IEEE International Systems Conference, May 2015, Vancouver, CA. Accessed November 21, 2017.

The Technical Cooperation Program, August 2014, "," Technical Report TR- JSA/TP4-1-2014, August 2014. Accessed November 21, 2017.

U.S. Department of Defense, January 2017, . Accessed November 21, 2017.

Publications

Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Questions?
Contact the SEG Team