Difference between revisions of "Scope of the SEBoK"

Revision as of 18:21, 6 August 2012

This navigational tool is a prototype under development SEBoK 1.0. Comments are welcome for improvement.
Use [+] to expand and [-] to collapse. Clicking on a title will open that article.

{{#star:

}}

The scope of the Guide to the Systems Engineering Body of Knowledge (SEBoK) can be discussed in several dimensions. In general, the SEBoK is bounded by the following:

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.
The SEBoK is primarily domain independent, with implementation examples providing the domain-specific context .
The SEBoK is focused on engineered systems (ES) (e.g. products , services , Systems of Systems (SoS), and enterprises ), treating social and natural systems as relevant and important environmental considerations for ESs (please see “Scope of Systems Engineering within the Systems Domain” below). For additional discussion, please see the Part 2 What is a System? article.
The SEBoK acknowledges similarities and differences in the application of SE principles to different types of systems (please see Part 4, Applications of Systems Engineering).
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 Part 6, Related Disciplines).

Each of these considerations is dependent upon the definition and scope of SE. For the SEBoK, the boundaries of SE are defined below. External to the boundaries of SE and the SEBoK, the context of each is discussed with respect to the agents, activities, and artifacts involved in the SEBoK life cycle ; the life cycle of SE in the context of an ES; and SEBoK externalities with respect to domain-dependent SE.

Scope of Systems Engineering within the Systems Domain

The scope of SE and the SEBoK must ``consider’’ all classes of systems, but ``focuses’’ on the domain of ESs. Sociotechnical systems are treated as a special form of engineered systems. A convenient way to define the scope of ESs and the SEBoK is to relate it to the two other systems domains, natural systems and social systems, as shown in Figure 1 below. As an example, power generation and distribution systems are purely engineered systems, including software and human operator aspects as well as hardware aspects. Water and power safety legislation comes from the political processes of a legislature social system. The resulting water and power safety assurance and safety governance systems are sociotechnical systems involving participants working in both engineered systems and social systems.

Figure 1. System Boundaries of Engineered Systems, Social Systems, and Natural Systems. (SEBok Original)

The nature of and relationships between these system domains is discussed in Part 2, Systems of the SEBoK. Part 2 considers the general nature and purpose of systems and how these ideas are used to ensure better-ESs. It covers this by considering:

Systems Thinking – a way of understanding complex situations by looking at them as combinations of systems.
Systems Science – a collection of disciplines that have created useful knowledge by applying systems thinking and the scientific method 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 sociotechnical systems to identify and scope the engineering of system problems or opportunities . It is critical to understand each of these system types if ESs are to be deployed into real world situations, achieve their assigned goals, and not adversely impact other outcomes.

The primary focus of the knowledge in Part 3, Systems Engineering and Management and Part 4, Applications of Systems Engineering is on how to create or change ESs to fulfill the goals of all relevant stakeholders within these wider system contexts. The knowledge in Part 5, Enabling Systems Engineering and Part 6, Related Disciplines 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.

Scope of Systems Engineering (SE) within the Engineered Systems (ES) Domain

The scope of SE does not include the entire 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, general management, and manufacturing are poorly managed and executed.

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 part of SE planning and analysis functions. Such activities as production line equipment ordering and installation, and its use in manufacturing, 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 production aspects of system implementation. Software engineering, then, is not considered a subset of SE.

Figure 2. System Boundaries of Systems Engineering, Systems Implementation, and Project/Systems Management. (SEBok Original)

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:

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, modified)

Part 3, Systems Engineering and Management, elaborates on the definition above and offers additional definitions and constructs, providing further context for the other parts of the SEBoK.

Context of the SEBoK

SEBoK Life Cycle Context

Figure 3 summarizes the main agents, activities, and artifacts involved in the SEBoK life cycle. The SEBoK is one of two primary products of the Body of Knowledge and Curriculum to Advance Systems Engineering (BKCASE) Project. The other product, the Graduate Reference Curriculum in Systems Engineering (GRCSE) uses the content of the SEBoK to define a core body of knowledge (CorBoK) to be included in graduate SE curricula. The GRCSE is not a standard, but a reference curriculum to be tailored and extended to meet the objectives of each university’s graduate program.

Figure 3. SEBoK Life Cycle and Context: Related Agents, Activities, and Artifacts. (SEBoK Original)

The BKCASE project, led by Stevens Institute of Technology and the Naval Postgraduate School, has drawn on three primary resources. The U.S. Department of Defense (DoD) has provided the funding and includes a representative, but has not constrained or directed the project’s approach and content. The DoD Systems Engineering Research Center (SERC), a DoD university affiliated research center operated by Stevens Institute of Technology, supports BKCASE management and infrastructure and is the means by which DoD funding is delivered to the BKCASE project. The over 70 international author team members have been selected for their expertise in SE and their diversity with respect to home country (authors have come from 15 different countries), economic sector (government, industry, academia), and SE specialty area. Except for travel support in a few cases, authors have donated their time to the development of the SEBoK content.

The SEBoK content has been incrementally developed. Each of the 0.25, 0.5, and 0.75 versions has undergone an open review by all interested parties. Reviews have involved over 200 reviewers and thousands of comments each of which has been adjudicated. Upon completion of the initial SEBoK and GRCSE development in late 2012, the Institute of Electrical and Electronic Engineers (IEEE) and the International Council on Systems Engineering (INCOSE) will become the primary stewards for both the SEBoK and GRCSE. The continuing role of Stevens Institute, Naval Postgraduate School, and the SERC in SEBoK and GRCSE operations and maintenance will also evolve after 2012. Interested parties should be able to undertake development, operations, and support of additional derivative products and services, such as courseware, education, certification, and domain-specific versions of the SEBoK and GRCSE.

SE and Engineered Systems Project Life Cycle Context

Figure 4 summarizes the main agents, activities, and artifacts involved in the life cycle of SE, in the context of a project to create and evolve an ES. For each primary project life cycle phase of system definition , system initial operational capability (IOC) development, and system evolution and retirement, it shows the activities being performed by the primary agents (the systems engineers, the systems developers, and the primary project-external bodies (users , owners, external systems) constituting the project environment, in creating the evolving states of the ES, which may be a product, service, and/or enterprise.

Figure 4. SE and Engineered System Project Life Cycle Context: Related Agents, Activities, and Artifacts. (SEBoK Original)

The semantics of the boxes and arrows in Figure 4 are that the boxes in the center three columns show activities being performed by the relevant agents in the column, while the boxes in the right-hand column are the resulting artifacts. An arrow going from box A to box B means that the successful outcome of box B depends on the successful outcome of box A. In some cases in Figure 4, there are two-way dependencies, as in the handling of the inevitable changes that arise during system development and evolution.

For example, the system’s users and owners may propose changes to respond to competitive threats or opportunities , or to adapt to changes imposed by independently evolving external systems, such as Commercial-off-the-Shelf COTS products, cloud services, or supply chain enablers. These require negotiation among these stakeholders and the system developers, in which the SEs play a key role in analyzing the relative costs and benefits of alternative change proposals, and in synthesizing mutually satisfactory solutions.

Domain Independence Context

SE is practiced in numerous domains such as telecommunications, finance, medicine, and aerospace. Each of these domains will have its own specialized vocabulary and key domain concepts. The language and concepts contained in the SEBoK are intended to be what is generally accepted for domain-independent SE. For example, there are domain-independent foundations for SE such as the concepts elaborated in Part 2, Systems of the SEBoK. For the SEBoK, the main body is domain-independent. In order to show how the domain-independent material relates to different domains, several case studies and vignettes demonstrating the effect of domain on the application of SE complement the domain-independent information. Initial versions of the case studies and vignettes are provided in Part 7, Systems Engineering Implementation Examples, and also in some of the Use Cases in Part 1. The examples 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 expect that additional examples will be added during the evolution of the SEBoK.

References

Works Cited

INCOSE. 2012. Systems Engineering Handbook, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.

Primary References

INCOSE. 2012. Systems Engineering Handbook, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.

Additional References

Sage, A. and W. Rouse (eds). 1999. Handbook of Systems Engineering and Management. Hoboken, NJ, USA: John Wiley and Sons, Inc.

< 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

@@ Line 1: / Line 1: @@
 {{Star|{{#linktree:2|Domain (glossary)|Context (glossary)|Engineered System (ES) (glossary)|Product (glossary)|Acronyms|Service (glossary)|Enterprise (glossary)|Systems of Systems (SoS) (glossary)|Social System (glossary)|Natural System (glossary)|Systems Engineering (SE) (glossary)|Boundary (glossary)|Life Cycle (glossary)|Sociotechnical system (glossary)|Scope (glossary)|Purpose (glossary)|System (glossary)|Problem (glossary)|Opportunity (glossary)|Stakeholder (glossary)|Environment (glossary)|Implementation (glossary)|Project (glossary)|Boundary (glossary)|Engineering (glossary)|Software (glossary)|Requirement (glossary)|Synthesis (glossary)|Design (glossary)|Holistic (glossary)|Verification (glossary)|Validation (glossary)|Solution (glossary)|Disposal (glossary)|Concept (glossary)|Threat (glossary)|Cost (glossary)|Opportunity (glossary)|System Definition (glossary)|User (glossary)}}}}
-The scope of the Guide to the Systems Engineering Body of Knowledge [[Acronyms|(SEBoK)]] can be discussed in several dimensions. In general, the SEBoK is bounded by the following:
+The scope of the Guide to the Systems Engineering Body of Knowledge (SEBoK) can be discussed in several dimensions. In general, the SEBoK is bounded by the following:
 *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.
-*The SEBoK is primarily [[Domain (glossary)|domain (glossary)]] independent, with implementation examples providing the domain-specific [[Context (glossary)|context (glossary)]].
+*The SEBoK is primarily domain independent, with implementation examples providing the domain-specific context .
-*The SEBoK is focused on [[Engineered System (glossary)|engineered systems (glossary)]] [[Acronyms|(ES)]] (e.g. [[Product (glossary)|products (glossary)]], [[Service (glossary)|services (glossary)]], [[Systems of Systems (SoS)]], and [[Enterprise (glossary)|enterprises (glossary)]]), treating [[Social System (glossary)|social (glossary)]] and [[Natural System (glossary)|natural (glossary)]] systems as relevant and important environmental considerations for ESs (please see “Scope of Systems Engineering within the Systems Domain” below). For additional discussion, please see the Part 2 [[What is a System?]] article.
+*The SEBoK is focused on engineered systems (ES) (e.g. products , services , Systems of Systems (SoS), and enterprises ), treating social and natural systems as relevant and important environmental considerations for ESs (please see “Scope of Systems Engineering within the Systems Domain” below). For additional discussion, please see the Part 2 What is a System? article.
-*The SEBoK acknowledges similarities and differences in the application of SE principles to different types of [[Systems|systems]] (please see Part 4, [[Applications of Systems Engineering]]).
+*The SEBoK acknowledges similarities and differences in the application of SE principles to different types of systems (please see Part 4, Applications of Systems Engineering).
-*The SEBoK acknowledges and discusses the interaction between [[Systems Engineering (glossary)|systems engineering (glossary)]] [[Acronyms|(SE)]] and other disciplines, highlighting what [[Systems Engineer (glossary)| systems engineers (glossary)]] need to know about these disciplines (please see Part 6, [[Related Disciplines]]).
+*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 Part 6, Related Disciplines).
-Each of these considerations is dependent upon the definition and scope of SE. For the SEBoK, the boundaries of SE are defined below.  External to the [[Boundary (glossary)|boundaries (glossary)]] of SE and the SEBoK, the [[Context (glossary)|context (glossary)]] of each is discussed with respect to the agents, activities, and artifacts involved in the SEBoK [[Life Cycle (glossary)|life cycle (glossary)]]; the life cycle of SE in the context of an ES; and SEBoK externalities with respect to domain-dependent SE.
+Each of these considerations is dependent upon the definition and scope of SE. For the SEBoK, the boundaries of SE are defined below. External to the boundaries of SE and the SEBoK, the context of each is discussed with respect to the agents, activities, and artifacts involved in the SEBoK life cycle ; the life cycle of SE in the context of an ES; and SEBoK externalities with respect to domain-dependent SE.
 ==Scope of Systems Engineering within the Systems Domain==
-The [[Scope (glossary)|scope]] of SE and the SEBoK must ``consider’’ all classes of systems, but ``focuses’’ on the domain of ESs. [[Sociotechnical System (glossary) |Sociotechnical systems (glossary)]] are treated as a special form of engineered systems. A convenient way to define the scope of ESs and the SEBoK is to relate it to the two other systems domains, natural systems and social systems, as shown in Figure 1 below.
+The scope of SE and the SEBoK must ``consider’’ all classes of systems, but ``focuses’’ on the domain of ESs. Sociotechnical systems are treated as a special form of engineered systems. A convenient way to define the scope of ESs and the SEBoK is to relate it to the two other systems domains, natural systems and social systems, as shown in Figure 1 below.   As an example, power generation and distribution systems are purely engineered systems, including software and human operator aspects as well as hardware aspects.  Water and power safety legislation comes from the political processes of a legislature social system.  The resulting water and power safety assurance and safety governance systems are sociotechnical systems involving participants working in both engineered systems and social systems.
 [[File:Scope_SystemBoundaries.png|frame|500px|center|'''Figure 1. System Boundaries of Engineered Systems, Social Systems, and Natural Systems.''' (SEBok Original)]]
-The nature of and relationships between these system domains is discussed in Part 2, [[Systems]] of the SEBoK. Part 2 considers the general nature and [[Purpose (glossary)|purpose (glossary)]] of [[System (glossary)|systems (glossary)]] and how these ideas are used to ensure better-ESs. It covers this by considering:
+The nature of and relationships between these system domains is discussed in Part 2, Systems of the SEBoK. Part 2 considers the general nature and purpose of systems and how these ideas are used to ensure better-ESs. It covers this by considering:
+*Systems Thinking – a way of understanding complex situations by looking at them as combinations of systems.
+*Systems Science – a collection of disciplines that have created useful knowledge by applying systems thinking and the scientific method 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.
-*[[Systems Thinking]] – a way of understanding complex situations by looking at them as combinations of systems.
+The systems approach requires understanding of both natural and sociotechnical systems to identify and scope the engineering of system problems or opportunities . It is critical to understand each of these system types if ESs are to be deployed into real world situations, achieve their assigned goals, and not adversely impact other outcomes.
-*[[Systems Science]] – a collection of disciplines that have created useful knowledge by applying systems thinking and the scientific method to different aspects of the system domains.
-*[[Systems Approach Applied to Engineered Systems | Systems Approach]] – a way of tackling real world [[Problem (glossary)|problems (glossary)]] 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 [[Sociotechnical System (glossary)|sociotechnical systems]] to identify and scope the engineering of system [[Problem (glossary)|problems (glossary)]] or [[Opportunity (glossary)|opportunities (glossary)]]. It is critical to understand each of these system types if ESs are to be deployed into real world situations, achieve their assigned goals, and not adversely impact other outcomes.
+The primary focus of the knowledge in Part 3, Systems Engineering and Management and Part 4, Applications of Systems Engineering is on how to create or change ESs to fulfill the goals of all relevant stakeholders within these wider system contexts. The knowledge in Part 5, Enabling Systems Engineering and Part 6, Related Disciplines 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 primary focus of the knowledge in Part 3, [[Systems Engineering and Management]] and Part 4, [[Applications of Systems Engineering]] is on how to create or change ESs to fulfill the goals of all relevant [[Stakeholder (glossary)|stakeholders]] within these wider system contexts. The knowledge in Part 5, [[Enabling Systems Engineering]] and Part 6, [[Related Disciplines]] 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.
 ==Scope of Systems Engineering (SE) within the Engineered Systems (ES) Domain==
-The scope of SE does not include the entire ES domain. Activities such as system construction, manufacturing, funding, and general management are part of the SE [[Environment (glossary)|environment (glossary)]], 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 ([http://www.incose.org 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 (glossary)|implementation (glossary)]], and manufacturing are poorly managed and executed.
+The scope of SE does not include the entire 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, general management, and manufacturing are poorly managed and executed.
-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 (glossary)|project (glossary)]]/systems management, as shown in Figure 2. Activities, such as analyzing alternative methods for production, testing, and operations, are part of SE planning and analysis functions. Such activities as production line equipment ordering and installation, and its use in manufacturing, are still important SE environment considerations even though they are “outside” the SE [[Boundary (glossary)|boundary (glossary)]]. Note that as defined in Figure 2, system implementation [[Engineering (glossary)|engineering (glossary)]] also includes the [[Software (glossary)|software (glossary)]] production aspects of system implementation. Software engineering, then, is not considered a subset of SE.
+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 part of SE planning and analysis functions. Such activities as production line equipment ordering and installation, and its use in manufacturing, 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 production 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.''' (SEBok Original)]]
-Traditional definitions of SE have emphasized sequential performance of SE activities, e.g., “documenting [[Requirement (glossary)|requirements (glossary)]], then proceeding with design [[Synthesis (glossary)|synthesis (glossary)]]…”. (INCOSE 2011) The SEBoK authors have emphasized the inevitable intertwining of system [[Requirement (glossary)|requirements (glossary)]] definition and system [[Design (glossary)|design (glossary)]] in the following revised definition of SE:
+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:
-<blockquote>Systems Engineering (SE) is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on [[Holistic (glossary)|holistically (glossary)]] and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, [[Verification (glossary)|verifying (glossary)]], [[Validation (glossary)|validating (glossary)]], and evolving [[Solution (glossary)|solutions (glossary)]] while considering the complete problem, from system [[Solution (glossary)|concept (glossary)]] exploration through system [[Disposal (glossary)|disposal (glossary)]]. (INCOSE 2011, modified) </blockquote>
+</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, modified) </blockquote>
-Part 3, [[Systems Engineering and Management]], elaborates on the definition above and offers additional definitions and constructs, providing further context for the other parts of the SEBoK.
+Part 3, Systems Engineering and Management, elaborates on the definition above and offers additional definitions and constructs, providing further context for the other parts of the SEBoK.
 ==Context of the SEBoK==
 ===SEBoK Life Cycle Context===
-Figure 3 summarizes the main agents, activities, and artifacts involved in the SEBoK life cycle.  The SEBoK is one of two primary products of the Body of Knowledge and Curriculum to Advance Systems Engineering [[Acronyms|(BKCASE)]] Project [http://www.bkcase.org/].  The other product, the Graduate Reference Curriculum in Systems Engineering [[Acronyms|(GRCSE)]] [http://www.bkcase.org/grcse-05/] uses the content of the SEBoK to define a core [[Body of Knowledge (glossary)|body of knowledge]] ([[Acronyms|CorBoK]]) to be included in graduate SE curricula.  The GRCSE is not a standard, but a reference curriculum to be tailored and extended to meet the objectives of each university’s graduate program.
+Figure 3 summarizes the main agents, activities, and artifacts involved in the SEBoK life cycle. The SEBoK is one of two primary products of the Body of Knowledge and Curriculum to Advance Systems Engineering (BKCASE) Project. The other product, the Graduate Reference Curriculum in Systems Engineering (GRCSE) uses the content of the SEBoK to define a core body of knowledge (CorBoK) to be included in graduate SE curricula. The GRCSE is not a standard, but a reference curriculum to be tailored and extended to meet the objectives of each university’s graduate program.
 [[File:P1_Scope_and_Con_SEbok_LC_and_Cont_Related_Agents_BB.jpg|400px|thumb|center|'''Figure 3. SEBoK Life Cycle and Context: Related Agents, Activities, and Artifacts.''' (SEBoK Original)]]
-The BKCASE project, led by Stevens Institute of Technology and the Naval Postgraduate School, has drawn on three primary resources. The U.S. Department of Defense (DoD) [http://www.defense.gov/] has provided the funding and includes a representative, but has not constrained or directed the project’s approach and content. The DoD Systems Engineering Research Center (SERC) [http://www.sercuarc.org/], a DoD university affiliated research center operated by Stevens Institute of Technology [http://www.stevens.edu], supports BKCASE management and infrastructure and is the means by which DoD funding is delivered to the BKCASE project. The over 70 international author team members have been selected for their expertise in SE and their diversity with respect to home country (authors have come from 15 different countries), economomic sector (government, industry, academia), and SE specialty area.  Except for travel support in a few cases, authors have donated their time to the development of the SEBoK content.
+The BKCASE project, led by Stevens Institute of Technology and the Naval Postgraduate School, has drawn on three primary resources. The U.S. Department of Defense (DoD) has provided the funding and includes a representative, but has not constrained or directed the project’s approach and content. The DoD Systems Engineering Research Center (SERC), a DoD university affiliated research center operated by Stevens Institute of Technology, supports BKCASE management and infrastructure and is the means by which DoD funding is delivered to the BKCASE project. The over 70 international author team members have been selected for their expertise in SE and their diversity with respect to home country (authors have come from 15 different countries), economic sector (government, industry, academia), and SE specialty area. Except for travel support in a few cases, authors have donated their time to the development of the SEBoK content.
+The SEBoK content has been incrementally developed. Each of the 0.25, 0.5, and 0.75 versions has undergone an open review by all interested parties. Reviews have involved over 200 reviewers and thousands of comments each of which has been adjudicated. Upon completion of the initial SEBoK and GRCSE development in late 2012, the Institute of Electrical and Electronic Engineers (IEEE) and the International Council on Systems Engineering (INCOSE) will become the primary stewards for both the SEBoK and GRCSE. The continuing role of Stevens Institute, Naval Postgraduate School, and the SERC in SEBoK and GRCSE operations and maintenance will also evolve after 2012. Interested parties should be able to undertake development, operations, and support of additional derivative products and services, such as courseware, education, certification, and domain-specific versions of the SEBoK and GRCSE.
-The SEBoK content has been incrementally developed.  Each of the 0.25, 0.5, and 0.75 versions has undergone an open review by all interested parties. Reviews have involved over 200 reviewers and thousands of comments each of which has been adjudicated. Upon completion of the initial SEBoK  and GRCSE development in late 2012, the Institute of Electrical and Electronic Engineers (IEEE) [http://www.ieee.org/index.html] and the International Council on Systems Engineering (INCOSE) [http://www.incose.org/] will likely become the primary stewards for both the SEBoK and GRCSE. The continuing role of Stevens Institute, Naval Postgraduate School, and the SERC in SEBoK and GRCSE operations and maintenance will also be decided in 2012. Interested parties should be able to undertake development, operations, and support of additional derivative products and services, such as courseware, education, certification, and domain-specific versions of the SEBoK and GRCSE.
 ===SE and Engineered Systems Project Life Cycle Context===
-Figure 4 summarizes the main agents, activities, and artifacts involved in the life cycle of SE, in the context of a project to create and evolve an ES.  For each primary project life cycle phase of [[System Definition (glossary)|system definition (glossary)]], system initial operational capability [[Acronyms|(IOC)]] development, and system evolution and retirement, it shows the activities being performed by the primary agents (the systems engineers, the systems developers, and the primary project-external bodies ([[User (glossary)|users (glossary)]], owners, external systems) constituting the project environment, in creating the evolving states of the ES, which may be a product, service, and/or enterprise.
+Figure 4 summarizes the main agents, activities, and artifacts involved in the life cycle of SE, in the context of a project to create and evolve an ES. For each primary project life cycle phase of system definition , system initial operational capability (IOC) development, and system evolution and retirement, it shows the activities being performed by the primary agents (the systems engineers, the systems developers, and the primary project-external bodies (users , owners, external systems) constituting the project environment, in creating the evolving states of the ES, which may be a product, service, and/or enterprise.
+[[File:P1_Scope_and_Con_SE_and_Eng_Sys_Proj_LF_BB.jpg|600px|thumb|center|'''Figure 4. SE and Engineered System Project Life Cycle Context: Related Agents, Activities, and Artifacts.''' (SEBoK Original)]]
-[[File:P1_Scope_and_Con_SE_and_Eng_Sys_Proj_LF_BB.jpg|600px|thumb|center|'''Figure 4. SE and Engineered System Project Life Cycle Context: Related Agents, Activities, and Artifacts.''' (SEBoK Original)]]
+The semantics of the boxes and arrows in Figure 4 are that the boxes in the center three columns show activities being performed by the relevant agents in the column, while the boxes in the right-hand column are the resulting artifacts. An arrow going from box A to box B means that the successful outcome of box B depends on the successful outcome of box A. In some cases in Figure 4, there are two-way dependencies, as in the handling of the inevitable changes that arise during system development and evolution.
-The semantics of the boxes and arrows in Figure 4 are that the boxes in the center three columns show activities being performed by the relevant agents in the column, while the boxes in the right-hand column are the resulting artifacts.  An arrow going from box A to box B means that the successful outcome of box B depends on the successful outcome of box A.  In some cases in Figure 4, there are two-way dependencies, as in the handling of the inevitable changes that arise during system development and evolution.
+For example, the system’s users and owners may propose changes to respond to competitive threats or opportunities , or to adapt to changes imposed by independently evolving external systems, such as Commercial-off-the-Shelf COTS products, cloud services, or supply chain enablers. These require negotiation among these stakeholders and the system developers, in which the SEs play a key role in analyzing the relative costs and benefits of alternative change proposals, and in synthesizing mutually satisfactory solutions.
-For example, the system’s users and owners may propose changes to respond to competitive [[Threat (glossary)|threats (glossary)]] or [[Opportunity (glossary)|opportunities (glossary)]], or to adapt to changes imposed by independently evolving external systems, such as Commercial-off-the-Shelf [[Acronyms|COTS]] products, cloud services, or supply chain enablers.  These require negotiation among these stakeholders and the system developers, in which the SEs play a key role in analyzing the relative [[Cost (glossary)|costs (glossary)]] and benefits of alternative change proposals, and in synthesizing mutually satisfactory solutions.
 ===Domain Independence Context===
-SE is practiced in numerous domains such as telecommunications, finance, medicine, and aircraft. Each of these domains will have its own specialized vocabulary and key domain concepts.  The language and concepts contained in the SEBoK are intended to be what is generally accepted for domain-independent SE.   For example, there are domain-independent foundations for SE such as the concepts elaborated in Part 2, [[Systems]] of the SEBoK. For the SEBoK, the main body is domain-independent. In order to show how the domain-independent material relates to different domains, several case studies and vignettes demonstrating the effect of domain on the application of SE complement the domain-independent information. Initial versions of the case studies and vignettes are provided in Part 7, [[Systems Engineering Implementation Examples]]. The examples 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 expect that additional examples will be added during the evolution of the SEBoK.
+SE is practiced in numerous domains such as telecommunications, finance, medicine, and aerospace. Each of these domains will have its own specialized vocabulary and key domain concepts. The language and concepts contained in the SEBoK are intended to be what is generally accepted for domain-independent SE. For example, there are domain-independent foundations for SE such as the concepts elaborated in Part 2, Systems of the SEBoK. For the SEBoK, the main body is domain-independent. In order to show how the domain-independent material relates to different domains, several case studies and vignettes demonstrating the effect of domain on the application of SE complement the domain-independent information. Initial versions of the case studies and vignettes are provided in Part 7, Systems Engineering Implementation Examples, and also in some of the Use Cases in Part 1. The examples 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 expect that additional examples will be added during the evolution of the SEBoK.
 ==References==
 ===Works Cited===
-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.
+INCOSE. 2012. ''Systems Engineering Handbook'', version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.
 ===Primary References===
-No primary references have been identified for version 0.75.  Please provide any recommendations on primary references in your review.
+INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]'', version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.
 ===Additional References===
-No additional references have been identified for version 0.75.  Please provide any recommendations on additional references in your review.
+Sage, A. and W. Rouse (eds). 1999. ''Handbook of Systems Engineering and Management''. Hoboken, NJ, USA: John Wiley and Sons, Inc.
 ----