Difference between revisions of "Systems Engineering and Management"

From SEBoK
Jump to navigation Jump to search
m (Text replacement - "SEBoK v. 2.9, released 13 November 2023" to "SEBoK v. 2.9, released 20 November 2023")
 
(68 intermediate revisions by 9 users not shown)
Line 1: Line 1:
−
This part of the SEBoK focuses on the general knowledge of ''how'' systems are engineered. It builds upon Part 2: [[Foundations of Systems Engineering]], which discusses the need for a [[Systems Approach (glossary)]] applied to one or more [[Engineered System (glossary)]] contexts as a part of managed interventions into complex real world problems.  Part 3 provides an overview of the common uses of [[Life Cycle Models|life cycle models]] in Systems Engineering (SE) to organize the technical and none technical aspects of SE and discusses [[Systems Engineering Management]] activities. Part 3 also discusses the most commonly-used SE technical [[Processes]]; provides additional references to the common methods, tools, and techniques used in these processes
+
----
 +
'''''Lead Authors:''''' Jeffrey Carter and Caitlyn Singam
 +
----
 +
Systems Engineering and Management (SE&M) articles provide system lifecycle best practices for defining and executing interdisciplinary processes to ensure that customer needs are satisfied with a technical performance, schedule, and cost compliant solution.  The figure below depicts the context of SE&M processes and practices guidance within the SEBoK.
  
−
The commonly recognized definition of "[[Systems Engineering (glossary)|systems engineering]]" used across the SEBoK (INCOSE 2012) defines SE as an interdisciplinary approach which applies across the complete life cycle of an identified [[System-of-Interest (glossary)|System-of-Interest]].  The definition states that systems engineering “'''integrates all the disciplines and speciality groups into a team effort forming a structured development process that proceeds from concept to production to operation'''”. Thus SE is an engineering discipline concerned with all aspects of a systems life, including how we organize to do the engineering, what is produced by that engineering and how the resulting systems are used and sustained to meet stakeholder needs.
+
[[File:SEBoK_Context_Diagram_Inner_P3_Ifezue_Obiako.png|centre|thumb|600x600px|'''Figure 1: SEBoK Part 3 SE&M Context [SEBoK Original]''' for more detail see [[Structure of the SEBoK]]]]
  
−
Part 3 provides only an overview of how systems are engineered in a generic sense. [[Applications of Systems Engineering|Part 4]] provides more specific information as to how the principles discussed in Part 3 are applied differently in consideration of  [[Product System (glossary)|product systems]],  [[Service System (glossary)|service systems]], [[Enterprise System (glossary)|enterprise systems]], and [[System of Systems (SoS) (glossary)|systems of systems]] (SoS) contexts. [[Enabling Systems Engineering|Part 5]] explains how people and organizations may approach utilizing these principles as part of a holistic systems approach. [[Related Disciplines|Part 6]] contains references to other engineering and management disciplines, which work with the SE processes within a systems life cycle, but do not fall under the umbrella of SE.
+
The SE&M materials are currently being updated to provide system design practitioners with Digital Engineering [DE] and Model-Based Systems Engineering [MBSE] implementation guidance employing the Systems Modeling Language (SysML).
  
 +
* DE conducts Agile system-software development based on industry open standards by employing MBSE.
 +
* MBSE develops and integrates SysML design models with simulation capabilities for cross-domain collaboration across the lifecycle.
 +
* SysML is an industry standard graphical notation with formal semantics (meaning) to define system requirements, constraints, allocations, behavior and structure characteristics
  
−
==Knowledge Areas in Part 3==
+
==SE&M Knowledge Areas==
−
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:
+
The SE&M articles are organized into the following Knowledge Areas [KAs].
−
*[[Introduction to Life Cycle Processes]]
+
*[[Systems Engineering STEM Overview]]
−
*[[Life Cycle Models]]
+
*[[Model-Based Systems Engineering (MBSE)]]
−
*[[Concept Definition]]
+
*[[Systems Lifecycle Approaches]]
−
*[[System Definition]]
+
*[[System Lifecycle Models]]
 +
*[[Systems Engineering Management]]
 +
*[[Business and Mission Analysis]]
 +
*[[Stakeholder Needs Definition]]
 +
*[[System Architecture Definition]]
 +
*[[Detailed Design Definition]]
 +
*[[System Analysis]]
 
*[[System Realization]]
 
*[[System Realization]]
−
*[[System Deployment and Use]]
+
*[[System Implementation]]
−
*[[Systems Engineering Management]]
+
*[[System Integration]]
−
*[[Product and Service Life Management]]
+
*[[System Verification]]
 +
*[[System Transition]]
 +
*[[System Validation]]
 +
*[[System Operation]]
 +
*[[System Maintenance]]
 +
*System Specialty Engineering
 +
*[[Logistics]]
 +
*[[Service Life Management]]
 
*[[Systems Engineering Standards]]
 
*[[Systems Engineering Standards]]
−
See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.
+
The SE&M articles provide exemplar processes and practices which are tailorable for an engineering organization to satisfy strategic business goals and individual project objectives including:
  
−
==Generic Systems Engineering Paradigm==
+
*How engineering conducts system development
 +
*The purpose of each engineering artifact generated
 +
*How systems are integrated, and requirements verified
 +
*How new product designs are transitioned to production operations
 +
*How the resulting system is employed and sustained to satisfy customer needs
  
−
Figure 1 identifies the overall goals of any SE effort, which are: the understanding of stakeholder value; the selection of a specific need to be addressed; 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.  
+
==Systems Engineering & Management Overview==
 +
The role of Systems Engineering [SE] is to define system requirements, constraints, allocations, behavior and structure characteristics to satisfy customer needs.  The system is defined in terms of hierarchical structural elements and their behavior interactions.  The interactions include the exchange of data, energy, force, or mass which modifies the state of the cooperating elements resulting in emergent, discrete, or continuous behaviors.  The behaviors are at sequential levels of aggregation [bottoms-up] or decomposition [top-down] to satisfy requirements, constraints, and allocations. SE collaborates within an integrated product team with electrical, mechanical, software, and specialty engineering to define the subsystem and component detailed design implementations to develop a holistic technical solution.  
  
−
[[File:062211_BL_Paradigm.png|thumb|center|700px|'''Figure 1. Generic Systems Engineering Paradigm.''' (SEBoK Original)]]
+
SE has traditionally applied intuitive domain-specific practices emphasizing processes and procedures with good writing skills to manually organize information in a disparate collection of documents including textual system requirement specifications, analysis reports, system design descriptions, and interface specifications. Traditional SE is often referred to as a document-centric approach. System design practitioners have cultivated model-based techniques since the late 1990s to facilitate communications, manage design complexity, improve product quality, enhance knowledge capture and reuse. MBSE is defined as the formalized application of graphical modeling with precise semantic definitions for operational analysis, requirements definition, system design development and verification activities beginning in the conceptual phase and continuing throughout later lifecycle phases [INCOSE, 2015].  MBSE conducts system development employing an engineering ecosystem consisting of commercially available tools to create a system design model with SysML compliant semantics that represents the system requirements, constraints, allocations, behavior and structure characteristics.  The system design model provides an Authoritative Source of Truth [ASoT] for the project technical baseline with integrated end-to-end simulation capabilities to evaluate system key performance parameters in digital computing environments.  MBSE includes the creation, development, and utilization of digital design models with domain product-specific analyses including aerospace, automobile, consumer, defense, and software.
  
−
On the left side of Figure 1, there are three [[System-of-Interest (glossary)|SoI's]] identified in the formation of a [[System Breakdown Structure (glossary) |system breakdown structure]]. 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.
+
The recent adoption of DE practices [Roper, 2020] broadens the MBSE transformation based on the following principals:
  
−
On the right side of Figure 1, 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/IEEE 15288 standard; with the standard being reapplied for each SoI (ISO/IEC/IEEE 15288 2015). 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 SoI's; 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 a [[Software System (glossary)|software system]].  
+
* Agile System and Software Development to prioritize capability development and respond to evolving threats, environments, and challenges.
 +
* Modular Open System Approach [MOSA] to develop product-lines based on industry standards that can adapt to evolving customer needs with new, modified, and existing [reuse] capabilities.
 +
* Digital Engineering [DE] to develop, integrate, and employ MBSE design models with simulation capabilities to realistically emulate systems in digital computing environments for cross-domain collaboration across the system design development, verification, production, and sustainment lifecycle.
  
−
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.
+
The system design model includes functional, logical, and physical system design representations with capabilities that are integrated with electrical, mechanical, software, and specialty design disciplines for system functional and performance assessments. Design model scripts can export functional (SSS, B1, B2, B5) specifications, interface (IRS, ICD, IDD) specifications, design & requirements traceability reports, and design descriptions (SADD, SSDD, SWDD). The integrated simulations provide a digital twin with digital threads of system key performance parameters to evaluate design alternatives in digital computing environments to discover and resolve design defects before the expense of producing physical prototypes.
  
−
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]].
+
* Digital threads are analytical frameworks providing end-to-end system simulations to evaluate logical operations and key performance parameters in digital computing environments by exchanging information between different engineering modeling tools across the lifecycle.  Evaluation of the digital thread simulations ensure that requirements, interactions, and dependencies are commonly understood across engineering disciplines.  Design changes are automatically reflected in all design model usages to assess compliance, with any issue(s) flagged for corrective action.
 +
* Digital twins are authoritative representations of physical systems including the digital thread end-to-end connections with all the data, models, and infrastructure needed to define and optimize a system’s lifecycle digitally. Digital twins enable project team collaboration, system simulation functional performance assessments, design change impact evaluations, and product-line management reuse libraries
  
−
==Applying Iteration and Recursion to Systems Engineering in the Life Cycle==
+
MBSE enhances the ability to capture, analyze, share, and manage authoritative information associated with the complete specification of a product compared to traditional document-based approaches. MBSE provides the capability to consolidate information in an accessible, centralized source, enabling partial or complete automation of many systems engineering processes, and facilitating interactive representation of system components and behaviors.  The legacy SE&M materials are all impacted by the adoption of MBSE practices, and the SEBoK is updating its materials accordingly to reflect best practices and principles in an integrated model-based engineering environment.  The updated materials to specify system behavior and structure characteristics with traceability to the associated requirements are organized in accordance with the ISO/IEC/IEEE-15288:2015 ''Systems Lifecycle Processes'' Standard shown in the figure below.
  
−
The concept of iteration is also applied to 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]] KA.
+
[[File:15288_Standard_Outline_-_Model.png|thumb|center|750px|'''Figure 2.''' ISO/IEC/IEEE-15288:2015 Standard Outline (SEBoK Original)]]
  
−
[[File:Ex_Itera_of_processes_related_to_Sys_Def_AF_052312.png|thumb|center|650px|'''Figure 2. Example of Iterations of Processes Related to System Definition (Faisandier 2012).''' Permission Granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
+
Figure 3 depicts a generic example of the model-based system design process. The approach is consistent with INCOSE’s Systems Engineering Handbook guidance with the addition of a system design model repository to manage the project technical baseline. The MBSE design process is independent of any specific design methodology (e.g., structured analysis, object orientated, etc.) employed. Each design model element has a single definition with multiple instantiations on various diagrams depicting system structure and behavior characteristics including traceability to the associated requirements. The model-based design process may be tailored for projects dependent on the domain-area, development, and lifecycle approaches.
  
−
The comprehensive definition of a SoI is generally achieved using decomposition layers and [[System Element (glossary)|system elements (glossary)]]. Figure 3 presents a fundamental schema of a system breakdown structure.
+
[[File:Model-Based_System_Design_Process_Part3.png|thumb|center|600px|''Figure 3: Model-Based System Engineering Process.'' (SEBoK Original)]]
  
−
[[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. All other rights are reserved by the copyright owner.]]
+
Product domain-area system design knowledge and expertise are still mandatory with the implementation of an MBSE approach, which employs integrated modeling tools instead of legacy drawing tools (e.g., Powerpoint, Visio), textual-based specifications (e.g., DOORS), and engineering analysis reports and design descriptions (Word).  
  
−
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 [[Foundations of Systems Engineering|Part 2]]). Figure 4 shows an example of the recursion of life cycle processes.
+
The SE&M model-based system design guidance enables a multi-disciplinary team to manage a project’s technical baseline within a single, consistent, and unambiguous system design model.  The integrated MBSE design model contains system functional and logical representations with the physical detailed design implementation to specify, analyze, design, and verify that requirements are satisfied.  The guidance defines conventions for developing design models to specify system behavior and structure characteristics with traceability to the project’s requirements.  The design models provide a digital authoritative source of truth information repository for a project’s technical baseline. Model simulation with test cases facilitate initial design verification in digital computing environments to discover and resolve design defects before incurring the expense of producing physical prototypes.
  
−
[[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. All other rights are reserved by the copyright owner.]]
+
MBSE practices transform SE from the current document-based approach to employing computer aided design tools comparable to the evolution of the EE, ME, SW, and SP disciplines years ago.  The value-added benefit is employment of integrated modeling tools instead of traditional static drawing tools [e.g., PowerPoint, Visio] for product development, integration, and verification across the system lifecycle. 
 +
The SE&M model-based system design guidance provides MBSE best practices for implementing a digital engineering strategy to develop system design models for specifying and simulating behavior / structure characteristics with traceability to the associated requirements based on the following principles:
 +
#Develop, integrate, and employ digital system design models for cross-domain collaboration throughout the product lifecycle [i.e., engineering development, production, and sustainment].
 +
#Manage product-lines based on industry open standards with libraries of customized variants adapted for customers with new, modified, and existing [reuse] system design capabilities.
 +
#Maintain a digital authoritative source of truth information repository for each product variant’s approved technical baseline throughout the product lifecycle to facilitate collaboration and inform decision making.
 +
#Conduct model simulations with verification test cases to evaluate system behavior and structure in digital computing environments to discover design defects before the expense of producing physical prototypes.
 +
#Define digital threads of technical key performance parameters and synchronize information across SE, EE, ME, SW, and SP design modeling tools to ensure system requirements, interactions, and dependencies are commonly understood.  Design changes are automatically reflected in all model usages across engineering discipline tools and assessed for compliance, with any issue(s) flagged for corrective action.
 +
#Utilize “Agile” development processes to provide consistent methods for developing system design models and identifying digital threads for data synchronization across engineering disciplines within the integrated model-based engineering environment.
  
−
==Value of Ontology Concepts for Systems Engineering==
+
The SE&M model-based system design approach has a theoretical scientific foundation based on the system phenomenon defined by Hamilton’s Principle: a system is composed of hierarchical elements which interact by exchanging data, energy, force, or mass to modify the state of cooperating elements resulting in emergent, discrete, or continuous behaviors at progressive levels of aggregation or decomposition as shown in Figure 4. 
  
−
Ontology is the set of entities presupposed by a theory (Collins English Dictionary 2011). Systems engineering, and system development in particular, is based on concepts related to mathematics and proven practices. A SE ontology can be defined considering the following path.
+
[[File:The_System_Phenomenon.png|thumb|center|750px|''Figure 4: The System Phenomenon – Hamilton’s Principle.'' (SEBoK Original)]]
  
−
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 (glossary)|(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).
+
==References==
 +
===Citations===
 +
OMG Systems Modeling Language [SysML®] Standard – v1.6, November 2019
  
−
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 ISO 10303 standard (ISO 2007). There are many benefits to using an ontology. The ontology allows or forces:
+
INCOSE. 2015. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]] - A Guide for System Life Cycle Processes and Activities'', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
  
−
*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
+
Roper, W. 2020. ‘’There is No Spoon: The New Digital Acquisition Reality.’’ Arlington, VA: US Space Force, US Air Force, Assistant Secretary of the Air Force. 07 October 2020. Accessed May 25, 2023. Available at https://software.af.mil/wp-content/uploads/2020/10/There-Is-No-Spoon-Digital-Acquisition-7-Oct-2020-digital-version.pdf.
−
*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.
 
  
−
Throughout Part 3, there are discussions of the ontological elements specifically relevant to a given topic.
+
ISO/IEC/IEEE 15288:2015. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organization for Standardization / International Electrotechnical Commissions / Institute for Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.
  
−
==Terminology: Process, Architecture and Requirement ==
+
Schindel, B. 2016. “Got Phenomena? Science-Based Disciplines for Emerging Systems Challenges,” International Council on Systems Engineering (INCOSE), 2016 INCOSE International Symposium Proceedings, Edinburgh, Scotland.
  
−
There are terms with multiple definitions used in Part 3 and the rest of the SEBoK.   Understanding how and where they are used is important. This section discusses them from a variety of contexts to minimize confusion.
+
Schindel, B. 2018. “The System Phenomenon, Hamilton’s Principle, and Noether’s Theorem as a Basis for System Science,” International Council on Systems Engineering (INCOSE), 2018 INCOSE International Workshop Proceedings, Torrance, California.
  
−
The terms ''process'', ''architecture'', and ''requirement'' are fundamental to topics within SE; below, they are defined in general, partially elaborated upon, and outlined as to how they are used in different parts of SEBoK for further reference.
+
===Primary References===
 +
INCOSE. 2015. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]] - A Guide for System Life Cycle Processes and Activities'', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
  
−
===Process===
+
ISO/IEC/IEEE. 2015. [[ISO/IEC/IEEE 15288| Systems and Software Engineering -- System Life Cycle Processes]]. Geneva, Switzerland: International Organization for Standardization / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2015.
  
−
A [[Process (glossary)|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.
+
===Additional References===
−
 
+
U.S. DOD. 2018. ‘’Digital Engineering Strategy.’’ Arlington, VA: Office of the Deputy Assistant Secretary of Defense for Systems Engineering. June 2018.
−
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. rational unified process (RUP), Vee model, etc.).
 
−
 
 
−
[[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===
+
Wasson, C. 2006. System Analysis, Design, and Development – Concepts, Principles, and Practices.’’ Hoboken, NJ: John Wiley & Sons.
  
−
An [[Architecture (glossary)|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.
+
Madni, A. M. and Sievers, M. 2018. ''Model‐based systems engineering: Motivation, current status, and research opportunities'', Systems Engineering. 2018; 21: 172– 190. <nowiki>https://doi.org/10.1002/sys.21438</nowiki>
−
 
 
−
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)]].
 
−
 
−
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 (glossary)|Architecture Framework]] for definition and other examples.
 
−
 
 
−
===Requirement===
 
−
 
 
−
A [[Requirement (glossary)|requirement]] is something that is needed or wanted, but may not be compulsory in all circumstances. Requirements may refer to product or process characteristics or constraints. Different understandings of requirements are dependent on process state, level of abstraction, and type (e.g. functional, performance, constraint). An individual requirement may also have multiple interpretations over time.
 
−
 
 
−
Requirements exist at multiple levels of enterprise or system with multiple levels abstraction.  This ranges from the highest level of the enterprise capability or customer need to the lowest level of the system design.  During the Concept Definition, as the enterprise identifies new capabilities that are desired, the business or mission analysis develops a high level set of mission requirements that reflect the problem space perspective.   As the solution space is explored and solution classes are characterized, stakeholder needs are developed and transformed into stakeholder requirements (user perspective).  After the solution class has been determined and the specific solution is sought, during the System Definition the stakeholder requirements are transformed into system requirements (solution perspective).  As the system definition recursively defines the lower level detail of the solution, requirements are defined with lower level of abstraction.  At the highest level, the ideal requirement is implementation-independent, and therefore not specific to a solution, allowing for a range of possible solutions. At the lowest level, requirement statements may become more specific to the selected solution.  Thus, requirements need to be defined at the appropriate level of detail for the level of the entity to which it applies. See the article [[Process Synopsis]] for further detail on the transformation of needs and requirements from the enterprise to the lowest system element.
 
−
 
 
−
Concept Definition has further descriptions of business or enterprise and stakeholder needs and requirements.  It discusses how the new capability for the business or enterprise is defined as part of the understanding of the problem space.  It also discusses the development of the stakeholder needs and their transformation into requirements from the user perspective. 
 
−
 
 
−
[[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)|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 KA's of the SEBoK with respect to the processes outlined in the ISO/IEC/IEEE 15288 (ISO/IEC/IEEE 15288 2015) standard.  As shown, all of the major processes described in ISO/IEC 15288 are discussed within the SEBoK, though the organization of topics may differ.
 
−
 
 
−
[[File:Mapping_of_tech_topics_SEBoK_with_ISO_IEC_15288techPro_060612.jpg|thumb|center|600px|'''Figure 5. Mapping of Technical Topics of Knowledge Areas of SEBoK with ISO/IEC/IEEE 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. 2012. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities'', version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
 
−
 
 
−
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 Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E).
 
−
 
 
−
ISO/IEC/IEEE. 2015. ''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:2015.
 
−
 
 
−
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===
 
−
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
 
−
 
 
−
ISO/IEC/IEEE. 2015. [[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:2015.
 
−
 
 
−
===Additional References===
 
−
Bell Telephone Laboratories. 1982. ''Engineering and Operations in the Bell System''. Murray Hill, NJ: Bell Telephone Laboratories.
 
  
−
Fortescue, P.W., J. Stark, and G. Swinerd. 2003. ''Spacecraft Systems Engineering''. New York, NY, USA: J. Wiley.
+
Estefan, J. 2008. ''A Survey of Model-Based Systems Engineering (MBSE) Methodologies'', rev, B. Seattle, WA: International Council on Systems Engineering.  INCOSE-TD-2007-003-02. Accessed April 13, 2015. Available at http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf.  
  
 
----
 
----
−
<center>[[Applying the Systems Approach|< Previous Article]] | [[SEBoK Table of Contents|Parent Article]] | [[Introduction to Life Cycle Processes|Next Article >]]</center>
+
<center>[[Applying the Systems Approach|< Previous Article]] | [[SEBoK Table of Contents|Parent Article]] | [[Systems Engineering STEM Overview|Next Article >]]</center>
  
−
{{DISQUS}}
+
<center>'''SEBoK v. 2.9, released 20 November 2023'''</center>
  
−
[[Category: Part 3]][[Category:Part]]
+
[[Category: Part 3]]
 +
[[Category:Part]]

Latest revision as of 23:42, 18 November 2023

Lead Authors: Jeffrey Carter and Caitlyn Singam

Systems Engineering and Management (SE&M) articles provide system lifecycle best practices for defining and executing interdisciplinary processes to ensure that customer needs are satisfied with a technical performance, schedule, and cost compliant solution. The figure below depicts the context of SE&M processes and practices guidance within the SEBoK.

Figure 1: SEBoK Part 3 SE&M Context [SEBoK Original] for more detail see Structure of the SEBoK

The SE&M materials are currently being updated to provide system design practitioners with Digital Engineering [DE] and Model-Based Systems Engineering [MBSE] implementation guidance employing the Systems Modeling Language (SysML).

  • DE conducts Agile system-software development based on industry open standards by employing MBSE.
  • MBSE develops and integrates SysML design models with simulation capabilities for cross-domain collaboration across the lifecycle.
  • SysML is an industry standard graphical notation with formal semantics (meaning) to define system requirements, constraints, allocations, behavior and structure characteristics

SE&M Knowledge Areas

The SE&M articles are organized into the following Knowledge Areas [KAs].

The SE&M articles provide exemplar processes and practices which are tailorable for an engineering organization to satisfy strategic business goals and individual project objectives including:

  • How engineering conducts system development
  • The purpose of each engineering artifact generated
  • How systems are integrated, and requirements verified
  • How new product designs are transitioned to production operations
  • How the resulting system is employed and sustained to satisfy customer needs

Systems Engineering & Management Overview

The role of Systems Engineering [SE] is to define system requirements, constraints, allocations, behavior and structure characteristics to satisfy customer needs. The system is defined in terms of hierarchical structural elements and their behavior interactions. The interactions include the exchange of data, energy, force, or mass which modifies the state of the cooperating elements resulting in emergent, discrete, or continuous behaviors. The behaviors are at sequential levels of aggregation [bottoms-up] or decomposition [top-down] to satisfy requirements, constraints, and allocations. SE collaborates within an integrated product team with electrical, mechanical, software, and specialty engineering to define the subsystem and component detailed design implementations to develop a holistic technical solution.

SE has traditionally applied intuitive domain-specific practices emphasizing processes and procedures with good writing skills to manually organize information in a disparate collection of documents including textual system requirement specifications, analysis reports, system design descriptions, and interface specifications. Traditional SE is often referred to as a document-centric approach. System design practitioners have cultivated model-based techniques since the late 1990s to facilitate communications, manage design complexity, improve product quality, enhance knowledge capture and reuse. MBSE is defined as the formalized application of graphical modeling with precise semantic definitions for operational analysis, requirements definition, system design development and verification activities beginning in the conceptual phase and continuing throughout later lifecycle phases [INCOSE, 2015]. MBSE conducts system development employing an engineering ecosystem consisting of commercially available tools to create a system design model with SysML compliant semantics that represents the system requirements, constraints, allocations, behavior and structure characteristics. The system design model provides an Authoritative Source of Truth [ASoT] for the project technical baseline with integrated end-to-end simulation capabilities to evaluate system key performance parameters in digital computing environments. MBSE includes the creation, development, and utilization of digital design models with domain product-specific analyses including aerospace, automobile, consumer, defense, and software.

The recent adoption of DE practices [Roper, 2020] broadens the MBSE transformation based on the following principals:

  • Agile System and Software Development to prioritize capability development and respond to evolving threats, environments, and challenges.
  • Modular Open System Approach [MOSA] to develop product-lines based on industry standards that can adapt to evolving customer needs with new, modified, and existing [reuse] capabilities.
  • Digital Engineering [DE] to develop, integrate, and employ MBSE design models with simulation capabilities to realistically emulate systems in digital computing environments for cross-domain collaboration across the system design development, verification, production, and sustainment lifecycle.

The system design model includes functional, logical, and physical system design representations with capabilities that are integrated with electrical, mechanical, software, and specialty design disciplines for system functional and performance assessments. Design model scripts can export functional (SSS, B1, B2, B5) specifications, interface (IRS, ICD, IDD) specifications, design & requirements traceability reports, and design descriptions (SADD, SSDD, SWDD). The integrated simulations provide a digital twin with digital threads of system key performance parameters to evaluate design alternatives in digital computing environments to discover and resolve design defects before the expense of producing physical prototypes.

  • Digital threads are analytical frameworks providing end-to-end system simulations to evaluate logical operations and key performance parameters in digital computing environments by exchanging information between different engineering modeling tools across the lifecycle. Evaluation of the digital thread simulations ensure that requirements, interactions, and dependencies are commonly understood across engineering disciplines. Design changes are automatically reflected in all design model usages to assess compliance, with any issue(s) flagged for corrective action.
  • Digital twins are authoritative representations of physical systems including the digital thread end-to-end connections with all the data, models, and infrastructure needed to define and optimize a system’s lifecycle digitally. Digital twins enable project team collaboration, system simulation functional performance assessments, design change impact evaluations, and product-line management reuse libraries

MBSE enhances the ability to capture, analyze, share, and manage authoritative information associated with the complete specification of a product compared to traditional document-based approaches. MBSE provides the capability to consolidate information in an accessible, centralized source, enabling partial or complete automation of many systems engineering processes, and facilitating interactive representation of system components and behaviors. The legacy SE&M materials are all impacted by the adoption of MBSE practices, and the SEBoK is updating its materials accordingly to reflect best practices and principles in an integrated model-based engineering environment.  The updated materials to specify system behavior and structure characteristics with traceability to the associated requirements are organized in accordance with the ISO/IEC/IEEE-15288:2015 Systems Lifecycle Processes Standard shown in the figure below.

Figure 2. ISO/IEC/IEEE-15288:2015 Standard Outline (SEBoK Original)

Figure 3 depicts a generic example of the model-based system design process. The approach is consistent with INCOSE’s Systems Engineering Handbook guidance with the addition of a system design model repository to manage the project technical baseline. The MBSE design process is independent of any specific design methodology (e.g., structured analysis, object orientated, etc.) employed. Each design model element has a single definition with multiple instantiations on various diagrams depicting system structure and behavior characteristics including traceability to the associated requirements. The model-based design process may be tailored for projects dependent on the domain-area, development, and lifecycle approaches.

Figure 3: Model-Based System Engineering Process. (SEBoK Original)

Product domain-area system design knowledge and expertise are still mandatory with the implementation of an MBSE approach, which employs integrated modeling tools instead of legacy drawing tools (e.g., Powerpoint, Visio), textual-based specifications (e.g., DOORS), and engineering analysis reports and design descriptions (Word).

The SE&M model-based system design guidance enables a multi-disciplinary team to manage a project’s technical baseline within a single, consistent, and unambiguous system design model. The integrated MBSE design model contains system functional and logical representations with the physical detailed design implementation to specify, analyze, design, and verify that requirements are satisfied. The guidance defines conventions for developing design models to specify system behavior and structure characteristics with traceability to the project’s requirements. The design models provide a digital authoritative source of truth information repository for a project’s technical baseline. Model simulation with test cases facilitate initial design verification in digital computing environments to discover and resolve design defects before incurring the expense of producing physical prototypes.

MBSE practices transform SE from the current document-based approach to employing computer aided design tools comparable to the evolution of the EE, ME, SW, and SP disciplines years ago. The value-added benefit is employment of integrated modeling tools instead of traditional static drawing tools [e.g., PowerPoint, Visio] for product development, integration, and verification across the system lifecycle. The SE&M model-based system design guidance provides MBSE best practices for implementing a digital engineering strategy to develop system design models for specifying and simulating behavior / structure characteristics with traceability to the associated requirements based on the following principles:

  1. Develop, integrate, and employ digital system design models for cross-domain collaboration throughout the product lifecycle [i.e., engineering development, production, and sustainment].
  2. Manage product-lines based on industry open standards with libraries of customized variants adapted for customers with new, modified, and existing [reuse] system design capabilities.
  3. Maintain a digital authoritative source of truth information repository for each product variant’s approved technical baseline throughout the product lifecycle to facilitate collaboration and inform decision making.
  4. Conduct model simulations with verification test cases to evaluate system behavior and structure in digital computing environments to discover design defects before the expense of producing physical prototypes.
  5. Define digital threads of technical key performance parameters and synchronize information across SE, EE, ME, SW, and SP design modeling tools to ensure system requirements, interactions, and dependencies are commonly understood. Design changes are automatically reflected in all model usages across engineering discipline tools and assessed for compliance, with any issue(s) flagged for corrective action.
  6. Utilize “Agile” development processes to provide consistent methods for developing system design models and identifying digital threads for data synchronization across engineering disciplines within the integrated model-based engineering environment.

The SE&M model-based system design approach has a theoretical scientific foundation based on the system phenomenon defined by Hamilton’s Principle: a system is composed of hierarchical elements which interact by exchanging data, energy, force, or mass to modify the state of cooperating elements resulting in emergent, discrete, or continuous behaviors at progressive levels of aggregation or decomposition as shown in Figure 4.

Figure 4: The System Phenomenon – Hamilton’s Principle. (SEBoK Original)

References

Citations

OMG Systems Modeling Language [SysML®] Standard – v1.6, November 2019

INCOSE. 2015. Systems Engineering Handbook - A Guide for System Life Cycle Processes and Activities, version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.

Roper, W. 2020. ‘’There is No Spoon: The New Digital Acquisition Reality.’’ Arlington, VA: US Space Force, US Air Force, Assistant Secretary of the Air Force. 07 October 2020. Accessed May 25, 2023. Available at https://software.af.mil/wp-content/uploads/2020/10/There-Is-No-Spoon-Digital-Acquisition-7-Oct-2020-digital-version.pdf.

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

Schindel, B. 2016. “Got Phenomena? Science-Based Disciplines for Emerging Systems Challenges,” International Council on Systems Engineering (INCOSE), 2016 INCOSE International Symposium Proceedings, Edinburgh, Scotland.

Schindel, B. 2018. “The System Phenomenon, Hamilton’s Principle, and Noether’s Theorem as a Basis for System Science,” International Council on Systems Engineering (INCOSE), 2018 INCOSE International Workshop Proceedings, Torrance, California.

Primary References

INCOSE. 2015. Systems Engineering Handbook - A Guide for System Life Cycle Processes and Activities, version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.

ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2015.

Additional References

U.S. DOD. 2018. ‘’Digital Engineering Strategy.’’ Arlington, VA: Office of the Deputy Assistant Secretary of Defense for Systems Engineering. June 2018.

Wasson, C. 2006. System Analysis, Design, and Development – Concepts, Principles, and Practices.’’ Hoboken, NJ: John Wiley & Sons.

Madni, A. M. and Sievers, M. 2018. Model‐based systems engineering: Motivation, current status, and research opportunities, Systems Engineering. 2018; 21: 172– 190. https://doi.org/10.1002/sys.21438

Estefan, J. 2008. A Survey of Model-Based Systems Engineering (MBSE) Methodologies, rev, B. Seattle, WA: International Council on Systems Engineering. INCOSE-TD-2007-003-02. Accessed April 13, 2015. Available at http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf.

< Previous Article | Parent Article | Next Article >
SEBoK v. 2.9, released 20 November 2023
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Systems_Engineering_and_Management&oldid=70192"