Difference between revisions of "Scope of the SEBoK"

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")
 
(211 intermediate revisions by 15 users not shown)
Line 1: Line 1:
The scope of the SEBoK can be discussed in several dimensions. In general, the SEBoK is bounded by the following:
+
The SEBoK is a large, curated compendium of information about {{Term|Systems Engineering (glossary)|systems engineering}}. It:
*The SEBoK is a guide to the body of knowledge versus a stand-alone body of knowledge, providing references to detailed sources for additional information.
+
*is a guide to the body of SE knowledge which provides references to detailed sources for additional information; it is not a self-contained knowledge resource
*The SEBoK is primarily domain independent, with implementation examples providing the domain-specific context.
+
*focuses on {{Term|Engineered System (glossary)|Engineered Systems}} contexts, that is socio-technical systems with a recognized SE {{Term|Life Cycle (glossary)|life cycle}}, while treating social and natural systems as relevant and important environmental considerations (see [[Foundations of Systems Engineering|Part 2]])
*The SEBoK is focused on engineered systems (e.g. products, services, systems of systems (SoS), and enterprises), treating social and natural systems as relevant and important environmental considerations for engineered systems (please see “Scope of Systems Engineering within the Systems Domain” below). For additional discussion, please see the [[Systems|Part 2]] [[What is a System?]] article.
+
*describes generic SE life cycle and {{Term|Process (glossary)|process}} knowledge (see [[Systems Engineering and Management|Part 3]])
*The SEBoK acknowledges similarities and differences in the application of SE principles to different types of problems (please see [[Applications of Systems Engineering|Part 4 Applications of Systems Engineering]]).
+
*recognizes that SE principles can be applied differently to different types of {{Term|Product (glossary)|products}}, {{Term|Service (glossary)|services}}, {{Term|Enterprise (glossary)|enterprises}}, and {{Term|System of Systems (SoS) (glossary)|systems of systems}} (SoS) context (see [[Applications of Systems Engineering|Part 4]])
*The SEBoK acknowledges and discusses the interaction between systems engineering (SE) and other disciplines, highlighting what systems engineers need to know about these disciplines (please see [[Related Disciplines|Part 6 Related Disciplines]]).
+
*provides resources for organization support of SE activities (see [[Enabling Systems Engineering|Part 5]])
 +
*explores the interaction between SE and other disciplines, highlighting what systems engineers need to know about these disciplines (see [[Systems Engineering and Other Disciplines|Part 6]])
 +
*is domain-independent, with implementation examples to provide domain-specific context (see [[Systems Engineering Implementation Examples|Part 7]])
  
Each of these considerations is dependent upon the definition and scope of SE.  For the SEBoK, the boundaries of SE are defined below.
+
Each of these considerations depends upon the definition and scope of SE itself, which is the subject of the next section.
  
==Scope of Systems Engineering within the Systems Domain==
+
==SEBoK Purposes==
The scope of SE and the SEBoK must ``consider’’ all classes of systems, but ``focuses’’ on the domain of engineered systems. A convenient way to define the scope of engineered systems and the SEBoK is to relate it to the two other systems domains, natural systems and social systems, as shown in Figure 1 below.
 
  
[[File:Scope_SystemBoundaries.png|frame|500px|center|Figure 1. System Boundaries of Engineered Systems, Social Systems, and Natural Systems (Figure Developed for BKCASE)]]
+
Ongoing studies of system cost and schedule failures (Gruhl & Stutzke 2005; Johnson 2006, GAO 2016) and safety failures (Leveson 2012) have shown that the failures have mostly come not from their domain disciplines, but from lack of adequate Systems Engineering (NDIA 2003, 2006, 2016).  To provide a foundation for the mutual understanding of SE needed to reduce these failures, the SEBoK describes the boundaries, terminology, content, and structure of SE. In so doing, the SEBoK systematically and consistently supports six broad purposes, described in Table 1.
  
The nature of and relationships between these system domains is discussed in [[Systems|Part 2]] of the SEBoKPart 2 considers the general nature and purpose of systems and how these ideas are used to ensure better-engineered systems. It covers this by considering:
+
{|
 +
|+ '''Table 1. SEBoK Purposes.''' (SEBoK Original)
 +
|-
 +
!#
 +
!Purpose
 +
!Description
 +
|-
 +
|1
 +
|Inform Practice
 +
|Inform systems engineers about the boundaries, terminology, and structure of their discipline and point them to useful information needed to practice SE in any application domain.
 +
|-
 +
|2
 +
|Inform Research
 +
|Inform researchers about the limitations and gaps in current SE knowledge that should help guide their research agenda.   
 +
|-
 +
|3
 +
|Inform Interactors
 +
|Inform performers in interacting disciplines (system implementation, project and enterprise management, other disciplines) and other stakeholders of the nature and value of SE.
 +
|-
 +
|4
 +
|Inform Curriculum Developers
 +
|Inform organizations defining the content that should be common in undergraduate and graduate programs in SE. 
 +
|-
 +
|5
 +
|Inform Certifiers
 +
|Inform organizations certifying individuals as qualified to practice systems engineering. 
 +
|-
 +
|6
 +
|Inform SE Staffing
 +
|Inform organizations and managers deciding which competencies practicing systems engineers should possess in various roles ranging from apprentice to expert.  
 +
|}
  
*[[Systems Thinking]] – a way of understanding complex situations by looking at them as combinations of systems.  
+
The SEBoK is a guide to the body of SE knowledge, not an attempt to capture that knowledge directly. It provides references to more detailed sources of knowledge, all of which are generally available to any interested reader. No proprietary information is referenced, but not all referenced material is free—for example, some books or standards must be purchased from their publishers. The criterion for including a source is simply that the [[Acknowledgements and Release History|authors & editors]] believed it offered the best generally available information on a particular subject.
*[[Systems Overview|Systems Science]] – a collection of disciplines that have created useful knowledge by applying systems thinking to different aspects of the system domains.
 
*[[Systems Approach]] a way of tackling real world problems which makes use of the tools of system science to enable useful systems to be engineered and used.
 
  
The systems approach requires understanding of both natural and socio-technical systems to identify and scope the engineering of system problems or opportunities.  It is critical to understand each of these system types if engineered systems are to be deployed into real world situations, achieve their assigned goals, and not adversely impact other outcomes.
+
The SEBoK is global in applicability. Although SE is practiced differently from industry to industry and country to country, the SEBoK is written to be useful to systems engineers anywhere. The authors & editors were chosen from diverse locales and industries, and have refined the SEBoK to broaden applicability based on extensive global reviews of several drafts.
  
The primary focus of the knowledge in [[Systems Engineering and Management|Part 3]] and [[Applications of Systems Engineering|Part 4]] is on how to create or change engineered systems to fulfill the goals of all relevant stakeholders within these wider system contexts. The knowledge in [[Enabling Systems Engineering|Part 5]] and [[Related Disciplines|Part 6]] includes the need for SE itself to be integrated and supported within the human activity systems in which it is performed and the relationships between SE and other engineering and management disciplines.
+
The SEBoK aims to inform a wide variety of user communities about essential SE concepts and practices in ways that can be tailored to different enterprises and activities while retaining greater commonality and consistency than would be possible without the SEBoK. Because the world in which SE is being applied continues to evolve and is dynamic, the SEBoK is designed for easy, continuous updating as new sources of knowledge emerge.
  
==Scope of Systems Engineering (SE) within the Engineered Systems (ES) Domain==
+
==SEBoK Uses==
The scope of SE does not include the entire engineered systems (ES) domain.  Activities such as system construction, manufacturing, funding, and general management are part of the SE environment, but other than the specific management of the SE function are not considered as part of SE. This is reflected in the International Council on Systems Engineering (INCOSE) top-level definition of systems engineering as, “an interdisciplinary approach and means to enable the realization of successful systems.” (INCOSE 2011)  For example, SE can enable the realization of successful systems, but cannot ensure a successful realization if the systems’ funding, implementation, and manufacturing are poorly managed and executed.
+
The communities involved with SE include its various specialists, engineers from disciplines other than systems engineering, managers, researchers, and educators. This diversity means that there is no single best way to use the SEBoK. The SEBoK includes use cases that highlight potential ways that particular communities can draw upon the content of the SEBoK, identify articles of interest to those communities, and discuss primary users (those who use the SEBoK directly) and secondary users (those who use the SEBoK with assistance from a systems engineer). For more on this, see the article [[SEBoK Users and Uses]].
 
Again, a convenient way to define the scope of SE within the ES domain is to develop a Venn diagram showing the relations among SE, system implementation, and project/systems management, as shown in Figure 2.   Activities, such as analyzing alternative methods for production, testing, and operations, are still important SE environment considerations even though they are “outside” the SE boundary.  Note that as defined in Figure 2, system implementation engineering also includes the software construction aspects of system implementation.  Software engineering, then, is not considered a subset of SE.  
 
  
[[File:Scope_BoundariesSE_PM_SM.png|thumb|600px|center|Figure 2. System Boundaries of Systems Engineering, Systems Implementation, and Project/Systems Management (Figure Developed for BKCASE)]]
+
==SEBoK Domain Independent Context==
 +
The SEBoK uses language and concepts that are generally accepted for domain-independent SE. For example, the domain-independent conceptual foundations of SE are elaborated in [[Foundations of Systems Engineering|Part 2: Foundations of Systems Engineering]]. However, each of the numerous domains in which SE is practiced — including telecommunications, finance, medicine, and aerospace — has its own specialized vocabulary and key concepts. Accordingly, the SEBoK is designed to show how its domain-independent material relates to individual domains in two ways. 
  
Traditional definitions of SE have emphasized sequential performance of SE activities, e.g., “documenting requirements, then proceeding with design synthesis…”. (INCOSE 2011) The SEBoK authors have emphasized the inevitable intertwining of system requirements definition and system design in the following revised definition of SE:
+
Firstly, by means of examples that tell stories of how SE is applied in particular domains. [[Systems Engineering Implementation Examples|Part 7: Systems Engineering Implementation Examples]] ) consists of examples (case studies and vignettes), each set in a particular domain such as aerospace, medicine, or software, and featuring vocabulary and concepts special to that domain. There are similar vignettes in some of the [[SEBoK Users and Uses|Use Cases]] in Part 1. These examples demonstrate the effect of domain on the application of SE and complement the domain-independent information elsewhere in the SEBoK. They show how a concept works in a given domain and provide a fair opportunity for reviewers to reflect on whether there are better ways to capture application-dependent aspects of SE knowledge.
  
<blockquote>Systems Engineering (SE) is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal. (INCOSE 2011) </blockquote>
+
In addition, the SEBoK will contain knowledge areas in [[Applications of Systems Engineering|Part 4: Applications of Systems Engineering]] which explicitly describe the domain specific language, approaches, specialized processes and tools, etc. of particular application domains. In this version of the SEBoK, there are a limited set of domain knowledge areas.
  
[[Systems Engineering and Management|Part 3 of the SEBoK]], elaborates on the definition above and offers additional definitions and constructs, providing further context for the other parts of the SEBoK.
+
==References==
 +
 
 +
===Works Cited===
 +
GAO. 2016. ''Weapon System Requirements. Detailed Systems Engineering Prior to Product Development Positions Programs for Success''. Government Accounting Office Report to Congressional Committees. 
 +
 
 +
Gruhl, W. and Stutzke, R. 2005.  "Werner Gruhl analysis of SE investments and NASA overruns," in R. Stutzke, ''Estimating Software-Intensive Systems''. Boston, MA, USA: Addison Wesley, page 290.  
  
==Domain Independence==
+
Johnson, J. 2006. ''My Life Is Failure: 100 Things You Should Know to Be a Better Project Leader''. Boston, MA, USA: Standish Group International.
There are domain-independent foundations for SE such as the concepts elaborated in [[Systems|Part 2]] of the SEBoK. These concepts apply across such diverse application domains as telecommunications, finance, medicine, and aircraft. Yet, some aspects of SE knowledge are domain-dependent. Vocabulary, for example, certainly varies across domains.  The language contained in the SEBoK is intended to be what is generally accepted for SE.
 
  
For SEBoK version 0.5, the main body is domain-independent. Several case studies and vignettes demonstrating the effect of domain on the application of SE complement this information. Initial versions of the case studies and vignettes are provided in [[Systems Engineering Implementation Examples|Part 7]]. The examples provided demonstrate how a concept would work in a given domain and provide a fair opportunity for reviewers to reflect on whether there are better ways to capture application-dependent aspects of SE knowledge. The authors recognize that including many more case studies would add significantly to the value of the SEBoK and intend to develop additional examples for version 1.0.
+
Leveson, N. 2012. ''Engineering a Safer World: Systems Thinking Applied to Safety''. Cambridge, MA, USA: MIT Press, NDIA (National Defense Industrial Association). 2003. ''Top 5 Systems Engineering Issues within DOD and Defense Industry: Task Report''. Version 9, released 1/23/03. Available at: [https://ndiastorage.blob.core.usgovcloudapi.net/ndia/2006/systems/Wednesday/rassa5.pdf https://www.aticourses.com/sampler/TopFiveSystemsEngineeringIssues_In_DefenseIndustry.pdf]. Accessed October 25, 2019.
  
==References==
+
NDIA (National Defense Industrial Association). 2006. '' Top 5 Systems Engineering Issues within DOD and Defense Industry DOD and Defense Industry: Task Report''. Version 8a, released July 26-27, 2006. Available at: https://ndiastorage.blob.core.usgovcloudapi.net/ndia/2006/systems/Wednesday/rassa5.pdf. Accessed October 25, 2019.
  
===Citations===
+
NDIA (National Defense Industrial Association). 2016. ''Top Systems Engineering Issues In US Defense Industry 2016''. Version 7c. Available at: https://www.ndia.org/-/media/sites/ndia/divisions/systems-engineering/studies-and-reports/ndia-top-se-issues-2016-report-v7c.ashx?la=en. Accessed October 25, 2019.
INCOSE. 2011. ''Systems Engineering Handbook'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.
 
  
===Primary References===
+
===Primary References===  
No primary references have been identified for version 0.5.  Please provide any recommendations on primary references in your review.
+
None.
  
 
===Additional References===
 
===Additional References===
No additional references have been identified for version 0.5.  Please provide any recommendations on additional references in your review.
+
None.
  
 
----
 
----
====Article Discussion====
+
<center>[[Introduction to the SEBoK|< Previous Article]] | [[Introduction to the SEBoK|Parent Article]] | [[Structure of the SEBoK|Next Article >]]</center>
  
[[{{TALKPAGENAME}}|[Go to discussion page]]]
+
[[Category:Part 1]]
 +
[[Category:Introduction to the SEBoK]]
  
<center>[[SEBoK 0.5 Introduction|<- Previous Article]] | [[SEBoK 0.5 Introduction|Parent Article]] | [[Structure of the SEBoK|Next Article ->]]</center>
+
<center>'''SEBoK v. 2.9, released 20 November 2023'''</center>
 
 
==Signatures==
 
--[[User:Dholwell|Dholwell]] 03:49, 13 September 2011 (UTC) core edit
 
[[Category:Part 1]]
 

Latest revision as of 22:56, 18 November 2023

The SEBoK is a large, curated compendium of information about systems engineeringsystems engineering. It:

  • is a guide to the body of SE knowledge which provides references to detailed sources for additional information; it is not a self-contained knowledge resource
  • focuses on Engineered SystemsEngineered Systems contexts, that is socio-technical systems with a recognized SE life cyclelife cycle, while treating social and natural systems as relevant and important environmental considerations (see Part 2)
  • describes generic SE life cycle and processprocess knowledge (see Part 3)
  • recognizes that SE principles can be applied differently to different types of productsproducts, servicesservices, enterprisesenterprises, and systems of systemssystems of systems (SoS) context (see Part 4)
  • provides resources for organization support of SE activities (see Part 5)
  • explores the interaction between SE and other disciplines, highlighting what systems engineers need to know about these disciplines (see Part 6)
  • is domain-independent, with implementation examples to provide domain-specific context (see Part 7)

Each of these considerations depends upon the definition and scope of SE itself, which is the subject of the next section.

SEBoK Purposes

Ongoing studies of system cost and schedule failures (Gruhl & Stutzke 2005; Johnson 2006, GAO 2016) and safety failures (Leveson 2012) have shown that the failures have mostly come not from their domain disciplines, but from lack of adequate Systems Engineering (NDIA 2003, 2006, 2016). To provide a foundation for the mutual understanding of SE needed to reduce these failures, the SEBoK describes the boundaries, terminology, content, and structure of SE. In so doing, the SEBoK systematically and consistently supports six broad purposes, described in Table 1.

Table 1. SEBoK Purposes. (SEBoK Original)
# Purpose Description
1 Inform Practice Inform systems engineers about the boundaries, terminology, and structure of their discipline and point them to useful information needed to practice SE in any application domain.
2 Inform Research Inform researchers about the limitations and gaps in current SE knowledge that should help guide their research agenda.
3 Inform Interactors Inform performers in interacting disciplines (system implementation, project and enterprise management, other disciplines) and other stakeholders of the nature and value of SE.
4 Inform Curriculum Developers Inform organizations defining the content that should be common in undergraduate and graduate programs in SE.
5 Inform Certifiers Inform organizations certifying individuals as qualified to practice systems engineering.
6 Inform SE Staffing Inform organizations and managers deciding which competencies practicing systems engineers should possess in various roles ranging from apprentice to expert.

The SEBoK is a guide to the body of SE knowledge, not an attempt to capture that knowledge directly. It provides references to more detailed sources of knowledge, all of which are generally available to any interested reader. No proprietary information is referenced, but not all referenced material is free—for example, some books or standards must be purchased from their publishers. The criterion for including a source is simply that the authors & editors believed it offered the best generally available information on a particular subject.

The SEBoK is global in applicability. Although SE is practiced differently from industry to industry and country to country, the SEBoK is written to be useful to systems engineers anywhere. The authors & editors were chosen from diverse locales and industries, and have refined the SEBoK to broaden applicability based on extensive global reviews of several drafts.

The SEBoK aims to inform a wide variety of user communities about essential SE concepts and practices in ways that can be tailored to different enterprises and activities while retaining greater commonality and consistency than would be possible without the SEBoK. Because the world in which SE is being applied continues to evolve and is dynamic, the SEBoK is designed for easy, continuous updating as new sources of knowledge emerge.

SEBoK Uses

The communities involved with SE include its various specialists, engineers from disciplines other than systems engineering, managers, researchers, and educators. This diversity means that there is no single best way to use the SEBoK. The SEBoK includes use cases that highlight potential ways that particular communities can draw upon the content of the SEBoK, identify articles of interest to those communities, and discuss primary users (those who use the SEBoK directly) and secondary users (those who use the SEBoK with assistance from a systems engineer). For more on this, see the article SEBoK Users and Uses.

SEBoK Domain Independent Context

The SEBoK uses language and concepts that are generally accepted for domain-independent SE. For example, the domain-independent conceptual foundations of SE are elaborated in Part 2: Foundations of Systems Engineering. However, each of the numerous domains in which SE is practiced — including telecommunications, finance, medicine, and aerospace — has its own specialized vocabulary and key concepts. Accordingly, the SEBoK is designed to show how its domain-independent material relates to individual domains in two ways.

Firstly, by means of examples that tell stories of how SE is applied in particular domains. Part 7: Systems Engineering Implementation Examples ) consists of examples (case studies and vignettes), each set in a particular domain such as aerospace, medicine, or software, and featuring vocabulary and concepts special to that domain. There are similar vignettes in some of the Use Cases in Part 1. These examples demonstrate the effect of domain on the application of SE and complement the domain-independent information elsewhere in the SEBoK. They show how a concept works in a given domain and provide a fair opportunity for reviewers to reflect on whether there are better ways to capture application-dependent aspects of SE knowledge.

In addition, the SEBoK will contain knowledge areas in Part 4: Applications of Systems Engineering which explicitly describe the domain specific language, approaches, specialized processes and tools, etc. of particular application domains. In this version of the SEBoK, there are a limited set of domain knowledge areas.

References

Works Cited

GAO. 2016. Weapon System Requirements. Detailed Systems Engineering Prior to Product Development Positions Programs for Success. Government Accounting Office Report to Congressional Committees.

Gruhl, W. and Stutzke, R. 2005. "Werner Gruhl analysis of SE investments and NASA overruns," in R. Stutzke, Estimating Software-Intensive Systems. Boston, MA, USA: Addison Wesley, page 290.

Johnson, J. 2006. My Life Is Failure: 100 Things You Should Know to Be a Better Project Leader. Boston, MA, USA: Standish Group International.

Leveson, N. 2012. Engineering a Safer World: Systems Thinking Applied to Safety. Cambridge, MA, USA: MIT Press, NDIA (National Defense Industrial Association). 2003. Top 5 Systems Engineering Issues within DOD and Defense Industry: Task Report. Version 9, released 1/23/03. Available at: https://www.aticourses.com/sampler/TopFiveSystemsEngineeringIssues_In_DefenseIndustry.pdf. Accessed October 25, 2019.

NDIA (National Defense Industrial Association). 2006. Top 5 Systems Engineering Issues within DOD and Defense Industry DOD and Defense Industry: Task Report. Version 8a, released July 26-27, 2006. Available at: https://ndiastorage.blob.core.usgovcloudapi.net/ndia/2006/systems/Wednesday/rassa5.pdf. Accessed October 25, 2019.

NDIA (National Defense Industrial Association). 2016. Top Systems Engineering Issues In US Defense Industry 2016. Version 7c. Available at: https://www.ndia.org/-/media/sites/ndia/divisions/systems-engineering/studies-and-reports/ndia-top-se-issues-2016-report-v7c.ashx?la=en. Accessed October 25, 2019.

Primary References

None.

Additional References

None.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.9, released 20 November 2023