Scope of the SEBoK

The scope of the 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 (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 Part 2 What is a System?) article.
• The SEBoK acknowledges similarities and differences in the application of SE principles to different types of problems (please see 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 Part 6).

Each of these considerations is dependent upon the definition and scope of SE. For the SEBoK, the boundaries of SE are defined below.

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 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.

Figure 1. System Boundaries of Engineered Systems, Social Systems, and Natural Systems (Figure Developed for BKCASE)

The nature of and relationships between these system domains is discussed in Part 2 of the SEBoK. Part 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:

• 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 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 primary focus of the knowledge in Part 3 and 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 Part 5 and 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.

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

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 2010) 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.

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.

Traditional definitions of SE have emphasized sequential performance of SE activities, e.g., “documenting requirements, then proceeding with design synthesis…”. (INCOSE 2010) 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)

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.

Domain Independence

There are domain-independent foundations for SE such as the concepts elaborated in 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 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.

References

Citations

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

No primary references have been identified for version 0.5. Please provide any recommendations on primary references in your review.

Additional References

Labran, A., J. W. Moore, P. Bourque, R. Dupuis, and L. L. Tripp. 2004. SWEBOK: Guide to the software engineering body of knowledge: 2004 version. Los Alamitos, CA; Tokyo, Japan: IEEE Computer Society Press.

ASCE. 2008. Civil engineering body of knowledge for the 21st century: Preparing the civil engineer for the future, 2nd edition. Reston, VA, USA: American Society of Civil Engineers.

Boehm, B., Valerdi, R., and E. Honour. 2008. The ROI of Systems Engineering: Some Quantitative Results for Software-Intensive Systems. Systems Engineering, Volume 11, Issue 3, April, pp. 221-234.

Honour, E.C. 2004. Understanding the value of systems engineering. INCOSE Int Sympos, Toulouse, France.

Johnson. J. 2006. My Life Is Failure. The Standish Corporation.

PMI 2008. A guide to the project management body of knowledge (PMBOK guide). 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI).

---

Article Discussion

[Go to discussion page]

<- Previous Article | Parent Article | Next Article ->