Systems Engineering and Management

This part of the SEBoK focuses on the general knowledge of how systems are engineered. It builds on Part 2 which discusses what systems are. Part 3 provides a basis for the engineering of product systems , service systems , enterprise systems , and systems of systems (glossary), as described in Part 4. Part 3 defines systems engineering and also provides an overview of the common life cycle model uses in systems engineering (SE). The commonly-used SE processes are also described, along with references to the common methods, tools, and techniques used within these processes. Finally, the management aspects of SE are discussed.

It is important to note that Part 3 provides an overview of how systems are engineered in a generic sense. Part 4 provides specific information on how the principles discussed in Part 3 are applied differently depending on the type of system (product, service, enterprise, or system of systems (SoS)) being engineered. Part 5 then explains how an organization may approach utilizing these principles in a holistic manner. Part 6 provides references to other/related disciplines which may be utilized in the various SE processes described in Part 3, but which do not fall under the umbrella of SE.

Knowledge Areas in Part 3

Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. Part 3 contains the following knowledge areas:

• Life Cycle Models
• Concept Definition
• System Definition
• System Realization
• System Deployment and Use
• Systems Engineering Management
• Product and Service Life Management
• Systems Engineering Standards

Systems Engineering Definition

There is no community consensus on the definition of "systems engineering"; the term has many different connotations in many different domains. One of the more commonly recognized definitions in the field is that of the International Council on Systems Engineering (INCOSE):

An interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:

• Operations
• Performance
• Test
• Manufacturing
• Cost & Schedule
• Training & Support
• Disposal

Systems engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.

(INCOSE 2010, 1)

This definition is frequently referenced throughout the SEBoK. SE is the application of a combination of traditional engineering and holistic systems thinking working with domain engineering, human sciences, management, and commercial disciplines to support the engineering of one or more systems of interest (SoI). It may also be an interdisciplinary approach governing the total technical and managerial effort required to transform a set of customer needs, expectations, and constraints into a solution, and to support that solution throughout its life cycle. Each of these perspectives is valuable for gaining a holistic view of SE.

Generic Systems Engineering Paradigm

Figure 1 identifies the general goal of any SE effort; that is, the understanding of stakeholder value, the selection of a specific need, the transformation of that need into a system product or service that provides for the need, and the use of that product or service to provide the stakeholder value. This paradigm has been developed according to the principles of a systems approach as discussed in Part 2. This paradigm was used to establish a basis for the KAs in Part 3 and Part 4 of the SEBoK.

Figure 1. Generic Systems Engineering Paradigm (Figure Developed for BKCASE).

On the left hand side of Figure 1, there are three systems of interest identified in the form of a system breakdown structure . System of interest (SoI) 1 is decomposed into its elements, which in this case are systems as well (SoI 2 and SoI 3). These two systems are composed of system elements which are not further refined.

On the right-hand side of the figure, each SoI has a corresponding life cycle model composed of stages that are populated with processes. These processes are used to define the work to be performed. Note that some of the requirements defined to meet the need are distributed in the early stages of the life cycle for SoI 1, and some to the life cycles of SoI 2 or SoI 3. This decomposition of the system illustrates the fundamental concept of recursion as defined in the ISO/IEC 15288 standard. That standard is reapplied for each SoI. It is important to note that stakeholder requirements may be allocated to different system elements, which may be integrated in different life cycle stages of any of the three SoIs, but together they form a cohesive system. For example, SoI 1 could be an embedded system composed of a hardware system (SoI 2) composed of a chasis and a motor, and a software system (SoI 3).

When performing SE processes in stages, iteration between stages is often required; e.g., in successive refinement of the definition of the system or in providing an update or upgrade of an existing system. The work performed in the processes and stages can be performed in a concurrent manner within the life cycle of any of the systems of interest and concurrently among the multiple life cycles.

This paradigm provides a fundamental framework for understanding generic SE (seen in Part 3), as well as for the application of SE to the various types of systems described in Part 4.

Applying Iteration and Recursion to Systems Engineering in the Life Cycle

The concept of iteration is also applied for processes. Figure 2 below gives an example of iteration in three processes as defined in ISO/IEC 15288. The processes in this example are further discussed in the System Definition Knowledge Area.

Figure 2. Example of iterations of processes related to system definition (ISO/IEC 2003,p. 21, Figure 12) Source available at http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=33898

The complete definition of a SoI is generally achieved using decomposition layers and system elements . Figure 3 presents a fundamental schema of a system breakdown structure.

Figure 3. Hierarchical decomposition of a system-of-interest (ISO/IEC 2008) Source available at http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43564

In each decomposition layer and for each system, the System Definition processes are applied recursively because the notion of a system is recursive; the notions of a SoI, system, and system element are based on the same concepts (see Part 2). Figure 4 shows an example of the recursion of three processes as defined in ISO/IEC 15288.

Figure 4. Recursion of processes on layers (ISO/IEC 2003, p.20, Figure 11) Source available at http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=33898

Value of Ontology Concepts for Systems Engineering

Ontology is the set of entities presupposed by a theory (Collins English Dictionary). SE, and in particular system development, is based on concepts related to mathematics and proven practices. A SE ontology can be defined considering the following path.

SE provides engineers with an approach based on a set of concepts (i.e., stakeholder, requirement, function, scenario, system element, etc.) and generic processes. Each process is composed of a set of activities and tasks gathered logically around a theme or a purpose. A process describes “what to do” using the concepts. The implementation of the activities and tasks is supported by methods and modeling techniques, composed themselves of elementary tasks; they describe the “how to do” of SE. The activities and tasks of SE are transformations of generic data using the predefined concepts. Those generic data are called entities, classes, or types. Each entity is characterized by specific attributes, and each attribute can get different values. All along their execution, the activities and tasks of processes, methods, and modeling techniques exchange instances of generic entities according to logical relationships. These relationships allow the engineer to link the entities between themselves (traceability) and to follow a logical sequence of the activities and the global progression (engineering management). Cardinality is associated with every relationship, expressing the minimum and maximum number of entities in order to make the relationship valid. Additional information may be found in Engineering Complex Systems with Models and Objects (Oliver, Kelliher, and Keegan 1997).

The set of SE entities and their relationships form an ontology, also often called an engineering meta-model. Such an approach is used and defined in the standard (ISO 2007). There are many benefits to using an ontology. The ontology allows or forces

• the use of a standardized vocabulary, with carefully chosen names that avoid the use of synonyms in the processes, methods, and modeling techniques;
• reconciliation of the vocabulary used in different modeling techniques and methods;
• the automatic appearance of the traceability of requirements when implemented in databases, SE tools or workbenches, and also the quick identification of the impacts of modifications in the engineering data set;
• checks of the consistency and completeness of engineering data; etc.

Readers are encouraged to read the "ontology" discussions embedded within articles in Part 3. Reviewer comments regarding ontology are encouraged as they will be particularly helpful for the development of version 1.0 of the SEBoK.

Mapping of Topics to ISO/IEC 15288, System Life Cycle Processes

Figure 2, below, shows the relative position of the Technical Knowledge Areas (KA) of the SEBoK with respect to the processes as stated in the ISO/IEC 15288 (2008) standard.

Figure 2. Mapping of technical topics of Knowledge Areas of SEBoK with ISO/IEC 15288 Technical Processes (Figure Developed for BKCASE)

References

Works Cited

Collins English Dictionary, s.v. "Ontology." 2011.

INCOSE. 2011. Systems Engineering Handbook, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE).

ISO/IEC. 2003. Systems Engineering — A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC 19760:2003 (E).

ISO/IEC 2008. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute for Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008.

ISO. 2007. Systems Engineering and Design. Geneva, Switzerland: International Organization for Standardization (ISO). ISO 10303-AP233.

Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering Complex Systems with Models and Objects. New York, NY, USA: McGraw-Hill.

Primary References

ISO/IEC 2008. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.

INCOSE. 2011. Systems Engineering Handbook, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE).

Additional References

No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.

---

< Previous Article | Parent Article | Next Article >