Systems Engineering and Management

This part of the SEBOK concentrates upon the generic knowledge of HOW to engineer systems. It provides a basis for the engineering of product systems , the engineering of service systems , the engineering of an enterprise system as well as the engineering of systems of systems as described in Part 4.

Managing System Assets

Organizations and their enterprises must continually monitor their portfolio of system assets; that is, their value added product system and/or service system offerings as well as all of the systems that support their development or operations (often referred to as infrastructure systems). Proper management of their system assets as illustrated in the System Coupling Diagram is essential for achieving enterprise purpose, goals and missions in responding to situations.

Key to operations of an enterprise, are the decisions that are made concerning system assets. Thus, prudent change management based upon enterprise needs and the problem and opportunity situations that it encounters must be a central function of enterprise leadership and management at all levels (strategic, tactical, and operational). Changes can involve the creation of new systems, the modification of existing systems or the deletion (retiring) of systems; as well as the altering of operational parameters for systems that are in operation.

The knowledge areas of this part provide generic insight into various aspects of how to accomplish life cycle relevant changes in respect to the types of engineered systems described in Part 4.

Generic Systems Engineering Paradigm

In order to establish a basis for the Knowledge Areas of Part 3 and Part 4, the paradigm appearing in Figure 1 identifies the general goal of any Systems Engineering 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 described in the Applying the Systems Approach topic in Part 2.

On the left hand side of the figure observe that there are three Systems of Interest identified in the form of a system breakdown structure . 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 observe that each of the Systems of Interest has a corresponding life cycle model composed of stages that are populated with processes that 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 to the life cycles of SOI 2, respectively SOI 3. This decomposition of the system illustrates the fundamental concept of recursion as defined in the ISO/IEC 15288 standard. That is the standard is reapplied for each of the systems of interest.

Note that the system elements are integrated in SOI 2, respectively SOI 3 thus realizing a product or service that is delivered to the life cycle of SOI 1 for integration in realizing the product or service that meets the stated need.

Some examples that relate to this system need could be an embedded system (SOI 1) composed a hardware system (SOI 2) and a software system (SOI 3), a sub-assembly composed of a chasis and a motor, a human resource system composed of a recruitment system and a capability management system.

In performing the process work in stages, most often iteration between stages if required. For example, in successive refinement of the definition of the system or in providing an update (upgrade or problem solution) of a realized and even delivered product or service.

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 concurrent amongst the multiple life cycles.

This paradigm provides a fundamental framework for understanding generic systems engineering in Part 3 as well as for the application of systems engineering in the provisioning of the various types of systems described in Part 4.

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

Figure 1. Example of iterations of processes related to System Definition (ISO. 2003)

The complete definition of a system of interest (soi) is generally achieved considering decomposition layers of systems and of system elements . The Figure below presents a fundamental schema of a system breakdown structure.

Figure 2. Hierarchical decomposition of a system-of-interest (ISO/IEC. 2008)

In each decomposition layer and for each system, the System Definition processes are applied recursively because the notion of system is recursive; the notions of System of Interest, system, system element are based on the same concepts – see Part 2. The Figure below shows an example of recursion of three processes as defined in ISO-IEC 15288.

Figure 3. Recursion of processes on layers (ISO. 2003)

Knowledge Areas in Part 3

References

Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Citations

List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Primary References

All primary references should be listed in alphabetical order. Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ (title). Please do not include version numbers in the links.