Difference between revisions of "Systems Engineering and Management"

From SEBoK
Jump to navigation Jump to search
Line 1: Line 1:
This part of the SEBoK focuses on the general knowledge of ''how'' systems are engineered. It builds on [[Systems|Part 2]] which discusses ''what'' systems are. Part 3 provides a basis for the engineering of [[Product System (glossary)|product systems (glossary)]],  [[Service System (glossary)|service systems (glossary)]], [[Enterprise System (glossary)|enterprise systems (glossary)]], and [[System of Systems (SoS) (glossary)|systems of systems (glossary)]], as described in [[Applications of Systems Engineering|Part 4]]. Part 3 defines [[Systems Engineering (glossary)|systems engineering (glossary)]] and also provides an overview of the common [[Life Cycle Models|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 [[Systems Engineering Management|management]] aspects of SE are discussed.
+
This part of the SEBoK focuses on the general knowledge of ''how'' systems are engineered. It builds upon [[Systems|Part 2]], which discusses the ''what'' element of systems. Part 3 provides a basis for the engineering of [[Product System (glossary)|product systems (glossary)]],  [[Service System (glossary)|service systems (glossary)]], [[Enterprise System (glossary)|enterprise systems (glossary)]], and [[System of Systems (SoS) (glossary)|systems of systems (glossary)]], as described in [[Applications of Systems Engineering|Part 4]]. Part 3 defines [[Systems Engineering (glossary)|systems engineering (glossary)]] and also provides an overview of the common uses of [[Life Cycle Models|life cycle model]] in systems engineering (SE). This section also discusses the most commonly-used SE processes, as well as providing additional references to the common methods, tools, and techniques used within these processes. Finally, the last section of Part 3 discusses the [[Systems Engineering Management|management]] aspects of SE.
  
It is important to note that Part 3 provides an overview of how systems are engineered in a generic sense. [[Applications of Systems Engineering|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. [[Enabling Systems Engineering|Part 5]] then explains how an organization may approach utilizing these principles in a holistic manner. [[Related Disciplines|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.
+
Additionally, it is important to note that Part 3 only provides an overview of how systems are engineered in a generic sense. [[Applications of Systems Engineering|Part 4]], on the other hand, provides more specific information as to how the principles discussed in Part 3 are applied differently in consideration of  the type of system (e.g. product, service, enterprise, or system of systems (SoS)) that is being engineered. [[Enabling Systems Engineering|Part 5]] then explains how an organization may approach utilizing these principles in a holistic manner. Lastly, [[Related Disciplines|Part 6]] contains references to other related disciplines, which may be utilized in the various SE processes described in Part 3, but do not fall under the umbrella of SE.
  
 
To download a PDF of Part 3, please [http://www.sebokwiki.org/075/images/0/07/SEBoK075_Part3.pdf click here].
 
To download a PDF of Part 3, please [http://www.sebokwiki.org/075/images/0/07/SEBoK075_Part3.pdf click here].
Line 17: Line 17:
  
 
==Systems Engineering Definition==
 
==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 ([[Acronyms|INCOSE]]):
+
There is no exact community consensus on the definition of "systems engineering"; the term has many different connotations in many different domains; however, one of the more commonly recognized definitions in the field is that of the International Council on Systems Engineering ([[Acronyms|INCOSE]]):
  
 
<blockquote>''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:
 
<blockquote>''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:
Line 29: Line 29:
 
''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.''</blockquote> (INCOSE 2010, 1)
 
''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.''</blockquote> (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 ([[Acronyms|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.
+
This is the definition that is frequently referenced throughout the SEBoK. SE is the application of a traditional engineering and holistic systems thinking that works in combination''with'' domain engineering, human sciences, management, and commercial disciplines in order to support the engineering of one or more systems of interest ([[Acronyms|SoI]]). SE may also be considered as an interdisciplinary approach, governing the complete technical and managerial effort that is required to transform a set of customer needs, expectations, and constraints into a solution, as well as to continue 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==  
 
==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 [[Applying the Systems Approach|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 identifies the overall goals of any SE effort, which are: the understanding of stakeholder value, the selection of a specific need, the transformation of that need into a system, the 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 the [[Applying the Systems Approach|systems approach]] discussed in Part 2 and is used to establish a basis for the KAs in Part 3 and Part 4 of the SEBoK.  
  
 
[[File:062211_BL_Paradigm.png|thumb|center|700px|'''Figure 1. Generic Systems Engineering Paradigm.''' (SEBoK Original)]]
 
[[File:062211_BL_Paradigm.png|thumb|center|700px|'''Figure 1. Generic Systems Engineering Paradigm.''' (SEBoK Original)]]
  
On the left hand side of Figure 1, there are three [[System of Interest (SoI) (glossary)|systems of interest (glossary)]] identified in the form of a [[System Breakdown Structure (glossary) |system breakdown structure (glossary)]]. 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 Element (glossary)|system elements]] which are not further refined.
+
On the left side of Figure 1, there are three [[System of Interest (SoI) (glossary)|systems of interest (glossary)]] identified in the formation of a [[System Breakdown Structure (glossary) |system breakdown structure (glossary)]]. System of interest (SoI) 1 is broken down into its basic elements, which in this case are systems as well (SoI 2 and SoI 3). These two systems are composed of [[System Element (glossary)|system elements]] that are not refined any further.
  
On the right-hand side of the figure, each SoI has a corresponding [[Life Cycle Model (glossary)|life cycle model (glossary)]] 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 (glossary)|recursion (glossary)]] 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 chassis and a motor, and a [[Software System (glossary)|software system]] (SoI 3).  
+
On the right side of the figure, each SoI has a corresponding [[Life Cycle Model (glossary)|life cycle model (glossary)]] which is composed of the stages that are populated with processes. The function of these processes is to define the work that is 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, while others are designated to the life cycles of SoI 2 or SoI 3. The decomposition of the system illustrates the fundamental concept of [[Recursion (glossary)|recursion (glossary)]] as defined in the ISO/IEC 15288 standard; with the standard being reapplied for each SoI. It is important to point out that the stakeholder requirements may be allocated to different system elements, which may be integrated in different life cycle stages of any of the three SoIs; however, together they form a cohesive system. For example, SoI 1 may be an embedded system composed of a hardware system, SoI 2 composed of a chassis and a motor, and Sol 3 of a [[Software System (glossary)|software system]].  
  
When performing SE processes in stages, [[Iteration (glossary)|iteration (glossary)]] 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 (glossary)|concurrent]] manner within the life cycle of any of the systems of interest and concurrently among the multiple life cycles.
+
When performing SE processes in stages, [[Iteration (glossary)|iteration (glossary)]] 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 (glossary)|concurrent]] manner within the life cycle of any of the systems of interest and also 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 [[Applications of Systems Engineering|Part 4]].
 
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 [[Applications of Systems Engineering|Part 4]].
Line 55: Line 55:
 
[[File:Hierarchical_decomposition_of_a_system-of-interest_060612.jpg|thumb|center|650px|'''Figure 3. Hierarchical Decomposition of a System-of-Interest (Faisandier 2012).''' Permission Granted by Sinergy'Com.]]
 
[[File:Hierarchical_decomposition_of_a_system-of-interest_060612.jpg|thumb|center|650px|'''Figure 3. Hierarchical Decomposition of a System-of-Interest (Faisandier 2012).''' Permission Granted by Sinergy'Com.]]
  
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 SoI, system, and system element are based on the same concepts (see [[Systems|Part 2]]). Figure 4 shows an example of the recursion of life cycle processes.
+
In each decomposition layer and for each system, the [[System Definition]] processes are applied recursively because the notion of system is in itself recursive; the notions of SoI, system, and system element are based on the same concepts (see [[Systems|Part 2]]). Figure 4 shows an example of the recursion of life cycle processes.
  
 
[[File:Recursion_of_processes_on_layers_060612.jpg|thumb|center|650px|'''Figure 4. Recursion of Processes on Layers (Faisandier 2012).''' Permission Granted by Sinergy'Com.]]
 
[[File:Recursion_of_processes_on_layers_060612.jpg|thumb|center|650px|'''Figure 4. Recursion of Processes on Layers (Faisandier 2012).''' Permission Granted by Sinergy'Com.]]
Line 61: Line 61:
 
==Value of Ontology Concepts for Systems Engineering==
 
==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.
+
Ontology is the set of entities presupposed by a theory (Collins English Dictionary 2011). SE, system development in particular, 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).
+
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 applied concepts. The implementation of the activities and tasks is supported by methods and modeling techniques, which are 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 predefined concepts. Those generic data are called entities, classes, or types. Each ''entity'' is characterized by specific ''attributes'', and each attribute may have a different value. 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 that are required in order to make the relationship valid. Additional information on this subject 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 set of SE entities and their relationships form an ontology, which is also referred to as 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;
+
*the use of a standardized vocabulary, with carefully chosen names, which helps to avoid the use of synonyms in the processes, methods, and modeling techniques
*reconciliation of the vocabulary used in different modeling techniques and methods;
+
*the 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;
+
*the automatic appearance of the traceability requirements when implemented in databases, SE tools or workbenches, and the quick identification of the impacts of modifications in the engineering data set
*checks of the consistency and completeness of engineering data; etc.
+
*the continual observation of the consistency and completeness of engineering data; etc.
  
 
==Terminology: Process, Architecture and Requirement ==
 
==Terminology: Process, Architecture and Requirement ==
  
There are terms with multiple definitions used in this Part 3 and the rest of the SEBoK.  Understanding how and where they are used is important. This section will disambiguate them for different contexts within SEBoK to minimize confusion.
+
There are terms with multiple definitions used in this Part 3 and the rest of the SEBoK.  Understanding how and where they are used is important. This section will discuss them from a variety of contexts within SEBoK to help deter and minimize confusion.
  
The terms ''process'', ''architecture'', and ''requirement'' will be defined in general, partially elaborated and outlined how they are used in different parts of SEBoK for further reference.
+
The terms ''process'', ''architecture'', and ''requirement'' will be defined in general, partially elaborated upon, and outlined as to how they are used in different parts of SEBoK for further reference.
  
 
'''Process'''
 
'''Process'''
Line 82: Line 82:
 
A process is a series of actions or steps taken in order to achieve a particular end; as a verb it is the performing of the operations.  Processes can be performed by humans or machines transforming inputs into outputs.
 
A process is a series of actions or steps taken in order to achieve a particular end; as a verb it is the performing of the operations.  Processes can be performed by humans or machines transforming inputs into outputs.
  
In SEBoK processes are interpreted in several ways such as technical, lifecycle, business, or manufacturing flow processes.  Many of the Part 3 sections are structured along technical processes (e.g. design, verification), but [[Life Cycle Models]] applies the concept at the high level of a program lifecycle sequence (e.g. RUP, VEE model, etc.).
+
In SEBoK processes are interpreted in several ways, including: technical, lifecycle, business, or manufacturing flow processes.  Many of the Part 3 sections are structured along technical processes (e.g. design, verification); however, [[Life Cycle Models]] applies the concept at the high level of a program lifecycle sequence (e.g. RUP, VEE model, etc.).
 
    
 
    
[[Applications of Systems Engineering|Part 4: Applications of Systems Engineering]] and [[Enabling Systems Engineering|Part 5: Enabling Systems Engineering]] use processes referring to services and business enterprise operations.  See [[Process (glossary)]] for various interpretations of the term.  
+
[[Applications of Systems Engineering|Part 4: Applications of Systems Engineering]] and [[Enabling Systems Engineering|Part 5: Enabling Systems Engineering]] utilize processes that are related to services and business enterprise operations.  See [[Process (glossary)]] for various interpretations of this term.  
  
 
'''Architecture'''
 
'''Architecture'''
  
An architecture is the organizational structure of a system, whereby the system can be defined in different contexts.  Architecting is the art or practice of designing the structures.
+
An architecture refers to the the organizational structure of a system, whereby the system can be defined in different contexts.  Architecting is the art or practice of designing the structures.
Architectures can apply for a system, product, enterprise, or service.  For example, Part 3 mostly considers product related architectures that systems engineers create, but an enterprise architecture describes the structure of an organization.  [[Enabling Systems Engineering|Part 5: Enabling Systems Engineering]] interprets enterprise architecture as much broader than an IT system used across an organization, which is a specific instance of an architecture.  More complete definitions are in [[Architecture (glossary)]].  
+
Architectures can apply for a system, product, enterprise, or service.  For example, Part 3 mostly considers product-related architectures that systems engineers create, but enterprise architecture describes the structure of an organization.  [[Enabling Systems Engineering|Part 5: Enabling Systems Engineering]] interprets enterprise architecture in a much broader manner than an IT system used across an organization, which is a specific instance of architecture.  More complete definitions are available [[Architecture (glossary)]].  
 
   
 
   
Related to architectures are frameworks, which are ways of representing architectures.  The terms Architecture Framework and Architectural Framework both refer to the same.  Examples include DoDAF, MoDAF, NAF for representing systems in defense applications, the TOGAF open group Architecture Framework, and the Federal Enterprise Architecture Framework (FEAF) for information technology acquisition, use and disposal.  See in glossary of terms [[Architecture Framework (glossary)|Architecture Framework]] for definition and other examples.
+
Frameworks are closely related to architectures, as they are ways of representing architectures.  The terms Architecture Framework and Architectural Framework both refer to the same.  Examples includeDoDAF, MoDAF, NAF for representing systems in defense applications, the TOGAF open group Architecture Framework, and the Federal Enterprise Architecture Framework (FEAF) for information technology acquisition, use and disposal.  See the glossary of terms [[Architecture Framework (glossary)|Architecture Framework]] for definition and other examples.
  
 
'''Requirement'''
 
'''Requirement'''
  
A requirement is something that is needed or wanted, so it isn’t compulsory in all circumstances.  Requirements may refer to product or process characteristics and constraints.  Different understandings of requirements depend on process state, level of abstraction and type (e.g. functional, performance, constraint).  An individual requirement may also have multiple interpretations over time.
+
A requirement is something that is needed or wanted, but that is not compulsory in all circumstances.  Requirements may refer to product or process characteristics and constraints.  Different understandings of requirements are dependant on process state, level of abstraction, and type (e.g. functional, performance, constraint).  An individual requirement may also have multiple interpretations over time.
  
[[System Definition]] has further descriptions of requirements and their types (e.g. system requirement, stakeholder requirement, derived requirement).  It discusses how different process roles or states, levels, and the nature of requirements matter in understanding what a requirement is.  Also see [[Requirement (glossary)]].
+
[[System Definition]] has further descriptions of requirements and their types (e.g. system requirement, stakeholder requirement, derived requirement).  It discusses how different process roles/ states, levels, and the nature of requirements apply to the understanding of requirements.  Also see [[Requirement (glossary)]].
  
Furthermore, these terms are intertwined and linked in additional concepts.  For example, processes are used to generate architectures and requirements.  Processes are architectures themselves, since the activities form a structure with connections between them.  There are process and architecture requirements.  A requirement depends on the process state.  These are some of the ways the terms and concepts tie together in systems engineering.
+
Furthermore, these terms are intertwined and linked to additional concepts.  For example, processes are used to generate architectures and requirements.  Processes are also architectures themselves, since the activities form a structure with connections between them.  There are process and architecture requirements, with the requirement depending on the process state.  These are some of the ways that these terms and concepts tie together in systems engineering.
  
 
==Mapping of Topics to ISO/IEC 15288, System Life Cycle Processes==
 
==Mapping of Topics to ISO/IEC 15288, System Life Cycle Processes==
Line 117: Line 117:
 
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. 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/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.
 
ISO. 2007. ''Systems Engineering and Design.'' Geneva, Switzerland: International Organization for Standardization (ISO). ISO 10303-AP233.
Line 124: Line 124:
  
 
===Primary References===
 
===Primary References===
ISO/IEC 2008. [[ISO/IEC/IEEE 15288| Systems and Software Engineering -- System Life Cycle Processes]]. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.
+
ISO/IEC. 2008. [[ISO/IEC/IEEE 15288| Systems and Software Engineering -- System Life Cycle Processes]]. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.
  
 
INCOSE. 2011. [[INCOSE Systems Engineering Handbook | Systems Engineering Handbook]], version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE).
 
INCOSE. 2011. [[INCOSE Systems Engineering Handbook | Systems Engineering Handbook]], version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE).

Revision as of 21:20, 27 August 2012

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

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

To download a PDF of Part 3, please click here.

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:

Systems Engineering Definition

There is no exact community consensus on the definition of "systems engineering"; the term has many different connotations in many different domains; however, 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 is the definition that is frequently referenced throughout the SEBoK. SE is the application of a traditional engineering and holistic systems thinking that works in combinationwith domain engineering, human sciences, management, and commercial disciplines in order to support the engineering of one or more systems of interest (SoI). SE may also be considered as an interdisciplinary approach, governing the complete technical and managerial effort that is required to transform a set of customer needs, expectations, and constraints into a solution, as well as to continue 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 overall goals of any SE effort, which are: the understanding of stakeholder value, the selection of a specific need, the transformation of that need into a system, the 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 the systems approach discussed in Part 2 and is used to establish a basis for the KAs in Part 3 and Part 4 of the SEBoK.

Figure 1. Generic Systems Engineering Paradigm. (SEBoK Original)

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

On the right side of the figure, each SoI has a corresponding life cycle model which is composed of the stages that are populated with processes. The function of these processes is to define the work that is 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, while others are designated to the life cycles of SoI 2 or SoI 3. The decomposition of the system illustrates the fundamental concept of recursion as defined in the ISO/IEC 15288 standard; with the standard being reapplied for each SoI. It is important to point out that the stakeholder requirements may be allocated to different system elements, which may be integrated in different life cycle stages of any of the three SoIs; however, together they form a cohesive system. For example, SoI 1 may be an embedded system composed of a hardware system, SoI 2 composed of a chassis and a motor, and Sol 3 of a software system.

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 also 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 life cycle processes. 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 (Faisandier 2012). Permission Granted by Sinergy'Com.

The comprehensive 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 (Faisandier 2012). Permission Granted by Sinergy'Com.

In each decomposition layer and for each system, the System Definition processes are applied recursively because the notion of system is in itself recursive; the notions of SoI, system, and system element are based on the same concepts (see Part 2). Figure 4 shows an example of the recursion of life cycle processes.

Figure 4. Recursion of Processes on Layers (Faisandier 2012). Permission Granted by Sinergy'Com.

Value of Ontology Concepts for Systems Engineering

Ontology is the set of entities presupposed by a theory (Collins English Dictionary 2011). SE, system development in particular, 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 applied concepts. The implementation of the activities and tasks is supported by methods and modeling techniques, which are 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 predefined concepts. Those generic data are called entities, classes, or types. Each entity is characterized by specific attributes, and each attribute may have a different value. 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 that are required in order to make the relationship valid. Additional information on this subject 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, which is also referred to as 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, which helps to avoid the use of synonyms in the processes, methods, and modeling techniques
  • the reconciliation of the vocabulary used in different modeling techniques and methods
  • the automatic appearance of the traceability requirements when implemented in databases, SE tools or workbenches, and the quick identification of the impacts of modifications in the engineering data set
  • the continual observation of the consistency and completeness of engineering data; etc.

Terminology: Process, Architecture and Requirement

There are terms with multiple definitions used in this Part 3 and the rest of the SEBoK. Understanding how and where they are used is important. This section will discuss them from a variety of contexts within SEBoK to help deter and minimize confusion.

The terms process, architecture, and requirement will be defined in general, partially elaborated upon, and outlined as to how they are used in different parts of SEBoK for further reference.

Process

A process is a series of actions or steps taken in order to achieve a particular end; as a verb it is the performing of the operations. Processes can be performed by humans or machines transforming inputs into outputs.

In SEBoK processes are interpreted in several ways, including: technical, lifecycle, business, or manufacturing flow processes. Many of the Part 3 sections are structured along technical processes (e.g. design, verification); however, Life Cycle Models applies the concept at the high level of a program lifecycle sequence (e.g. RUP, VEE model, etc.).

Part 4: Applications of Systems Engineering and Part 5: Enabling Systems Engineering utilize processes that are related to services and business enterprise operations. See process for various interpretations of this term.

Architecture

An architecture refers to the the organizational structure of a system, whereby the system can be defined in different contexts. Architecting is the art or practice of designing the structures. Architectures can apply for a system, product, enterprise, or service. For example, Part 3 mostly considers product-related architectures that systems engineers create, but enterprise architecture describes the structure of an organization. Part 5: Enabling Systems Engineering interprets enterprise architecture in a much broader manner than an IT system used across an organization, which is a specific instance of architecture. More complete definitions are available architecture .

Frameworks are closely related to architectures, as they are ways of representing architectures. The terms Architecture Framework and Architectural Framework both refer to the same. Examples include: DoDAF, MoDAF, NAF for representing systems in defense applications, the TOGAF open group Architecture Framework, and the Federal Enterprise Architecture Framework (FEAF) for information technology acquisition, use and disposal. See the glossary of terms Architecture Framework for definition and other examples.

Requirement

A requirement is something that is needed or wanted, but that is not compulsory in all circumstances. Requirements may refer to product or process characteristics and constraints. Different understandings of requirements are dependant on process state, level of abstraction, and type (e.g. functional, performance, constraint). An individual requirement may also have multiple interpretations over time.

System Definition has further descriptions of requirements and their types (e.g. system requirement, stakeholder requirement, derived requirement). It discusses how different process roles/ states, levels, and the nature of requirements apply to the understanding of requirements. Also see requirement .

Furthermore, these terms are intertwined and linked to additional concepts. For example, processes are used to generate architectures and requirements. Processes are also architectures themselves, since the activities form a structure with connections between them. There are process and architecture requirements, with the requirement depending on the process state. These are some of the ways that these terms and concepts tie together in systems engineering.

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

Figure 5, below, shows the relative position of the knowledge areas (KA) of the SEBoK with respect to the processes as stated in the ISO/IEC 15288 (2008) standard.

Figure 5. Mapping of Technical Topics of Knowledge Areas of SEBoK with ISO/IEC 15288 Technical Processes. (SEBoK Original)

References

Works Cited

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

Faisandier. A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.

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

None.


< Previous Article | Parent Article | Next Article >


SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus