GuidetotheSystemsEngineeringBodyof

Knowledge(SEBoK),version2.2

Part1

PleasenotethatthisisaPDFextractionofthecontentfromwww.sebokwiki.org

PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information.PDF generated at: Thu, 31 Oct 2019 15:05:46 EDT

Guide to the SystemsEngineering Body ofKnowledge, Part 1version 2.1

ContentsArticlesFront Matter 1

Letter from the Editor 1BKCASE Governance and Editorial Board 2Acknowledgements and Release History 7Cite the SEBoK 9Bkcase Wiki:Copyright 10

Part 1: SEBoK Introduction 11

SEBoK Introduction 11Introduction to the SEBoK 13

Knowledge Area: Introduction to the SEBoK 14

Scope of the SEBoK 14Structure of the SEBoK 17

Knowledge Area: Introduction to Systems Engineering 21

Introduction to Systems Engineering 21Systems Engineering Overview 23Economic Value of Systems Engineering 27Systems Engineering: Historic and Future Challenges 30Systems Engineering and Other Disciplines 34

Knowledge Area: Introduction to Systems Engineering Transformation 37

Introduction to SE Transformation 37Transitioning Systems Engineering to a Model-based Discipline 39Digital Engineering 42Set-Based Design 44Model-Based Systems Engineering Adoption Trends 2009-2018 49Systems Engineering Core Concepts 57

Knowledge Area: SEBoK Users and Uses 61

SEBoK Users and Uses 61Use Case 0: Systems Engineering Novices 63Use Case 1: Practicing Systems Engineers 67

Use Case 2: Other Engineers 70Use Case 3: Customers of Systems Engineering 74Use Case 4: Educators and Researchers 78Use Case 5: General Managers 81

ReferencesArticle Sources and Contributors 85Image Sources, Licenses and Contributors 86

1

Front Matter

Letter from the EditorHi there! Welcome to the October 2019 instantiation of the SystemsEngineering Body of Knowledge. Since version 1.0 appeared in September2012, that means the SEBoK just celebrated its 7th birthday! This release,version 2.1 is also my third release as Editor in chief. This release brings whatI hope are some exciting changes for the readers and authors.The first change I hope you notice is that we have added bylines to thosearticles for which we can track their origins. As of this release, we arerecognizing the contribution of lead authors and the additional contributingauthors. It is our hope that these contributions will be beneficial to the authorsin their professional lives - being able to prove their contributions to thisimportant knowledge base.

The next obvious change should be the way glossary bubbles have beenupdated. They are more readable now, with a grey background and black text.

Other changes include new articles on:•• Digital Engineering•• Mission Engineering•• Set Based Design•• MBSE Adoption Trends 2009-2018Additionally, we have updated content on Resilience, Human Systems Integration, and Capability Engineering. Part1 also received a wire brushing. We have also begun incorporating video. You will find a short video on the Mainpage. We are also going to begin to look at existing INCOSE YouTube channel content to look for 1-3 minute clipswe can strategically place throughout the SEBoK to add value.There is a big announcement to be made relative to the SEBoK. The IEEE Computer Society has been one of thethree stewards of the SEBoK from the beginning. They have had a seat on the Board of Governors, and haveprovided invaluable counsel. In January 2020, that stewardship will be transferred from the IEEE Computer Societyto the IEEE Systems Council. The Editorial Board looks forward to the continued support and participation of IEEE.Thank you IEEE Computer Society, and in particular to Rich Hilliard and Andy Chen.Regarding the reach of the SEBoK, there were over 29,000 visitors and 68,781 page views during the the month ofJuly 2019. That brings our total page views to over 3.45M since 2012. Top content pages in July: 1) StakeholderNeeds and Requirements, 2) Types of Models, 3) Types of Systems, 4) Systems Requirements, and 5) Reliability,Availability, and Maintainability. Top countries accessing the SEBoK in July:1.1. US2.2. India3.3. Australia4.4. United Kingdom5.5. PhilippinesLooking forward to the next release, it is my hope that those of you that enjoy working with video will think aboutcreating video content now that we have that capability. Please limit your submissions to no more than 3 minute

Letter from the Editor 2

clips, and the preferred format is mp4.I am still looking for additional authors and folks interested in taking a leadership role as editors to help manage andgrow our content for specific areas. It would be nice to add some more content in Part 6: Related Disciplines, andPart 7: SE Implementation Examples. If you would like to author an article for those sections, please reach our toNicole Hutchinson (emtnicole@gmail.com) or myself (rcloutier@southalabama.edu).That is it for now ... I hope to see you at the upcoming International Workshop being held in Torrence, CA inJanuary 2020. If you have ideas for the SEBoK, or would like to get involved, be sure to find me there and we canhave some coffee and chat. But, do not feel you have to wait until then to get involved - reach out now! Thanks foryour ongoing support.

BKCASE Governance and Editorial Board

BKCASE Governing BoardThe three SEBoK steward organizations – the International Council on Systems Engineering (INCOSE), the Instituteof Electrical and Electronics Engineers Computer Society (IEEE-CS), and the Systems Engineering Research Center(SERC) provide the funding and resources needed to sustain and evolve the SEBoK and make it available as a freeand open resource to all. The stewards appoint the BKCASE Governing Board to be their primary agents to overseeand guide the SEBoK and its companion BKCASE product, GRCSE.The BKCASE Governing Board includes:•• The International Council on Systems Engineering (INCOSE)

•• Art Pyster (Governing Board Chair), Paul Frenz•• Systems Engineering Research Center (SERC)

•• Jon Wade, Cihan Dagli•• IEEE Computer Society (IEEE CS)

•• Andy Chen, Rich HilliardPast INCOSE governors Bill Miller, Kevin Forsberg, David Newbern, David Walden, Courtney Wright, DaveOlwell, Ken Nidiffer, Richard Fairley, Massood Towhidnejad, and John Keppler. The governors would also like toacknowledge John Keppler, IEEE Computer Society, who has been instrumental in helping the Governors to workwithin the IEEE CS structure.The stewards appoint the BKCASE Editor in Chief to manage the SEBoK and GRCSE and oversee the EditorialBoard.

BKCASE Governance and Editorial Board 3

Editorial BoardThe SEBoK Editorial Board is chaired by an Editor in Chief, supported by a group of Associate Editors.

SEBoK Editor in Chief

Robert J. Cloutier

University of South Alabama

rcloutier@southalabama.edu [1]

Responsible for the appointment of SEBoK Editors and for the strategic direction and overallquality and coherence of the SEBoK.

SEBoK Managing Editor

Nicole Hutchison

Stevens Institute of Technology

nicole.hutchison@stevens.edu [2] or emtnicole@gmail.com [3]

Responsible for the the day-to-day operations of the SEBoK and supports the Editor in Chief.

Each Editor has his/her area(s) of responsibility, or shared responsibility, highlighted in the table below.

SEBoK Part 1: SEBoK Introduction

Lead Editor: Robert J. Cloutier

University of South Alabama

rcloutier@southalabama.edu [1]

Responsible for Part 1

BKCASE Governance and Editorial Board 4

SEBoK Part 2: Foundations of Systems Engineering

Lead Editor: Gary Smith

Airbus

gary.r.smith@airbus.com [4]

Assistant Editor: Dov Dori

Massachusetts Institute of Technology (USA) and Technion IsraelInstitute of Technology (Israel)

dori@mit.edu [5]

Responsible for the Representing Systems with Models knowledgearea

Assistant Editor: Duane Hybertson

MITRE (USA)

dhyberts@mitre.org [6]

Jointly responsible for the Systems Fundamentals, Systems Science andSystems Thinking knowledge areas

Assistant Editor: Peter Tuddenham

College of Exploration (USA)

Peter@coexploration.net [7]

Assistant Editor: Cihan Dagli

Missouri University of Science & Technology (USA)

dagli@mst.edu [8]

Responsible for the Systems Approach Applied to Engineered Systems knowledge areas.

SEBoK Part 3: Systems Engineering and Management

Assistant Editor: Barry Boehm

University of Southern California (USA)

boehm@usc.edu [9]

Jointly responsible for the Systems Engineering Management and LifeCycle Models knowledge areas

Assistant Editor: Kevin Forsberg

OGR Systems

kforsberg@ogrsystems.com [10]

Jointly responsible for the Systems Engineering Management and LifeCycle Models knowledge areas

Assistant Editor: Gregory Parnell

University of Arkansas (USA)

gparnell@uark.edu [11]

Responsible for Systems Engineering Management knowledge area.

Assistant Editor: Garry Roedler

Lockheed Martin (USA)

garry.j.roedler@lmco.com [12]

Responsible for the Concept Definition and System Definition knowledgeareas.

Assistant Editor: Phyllis Marbach

Incose LA (USA)

prmarbach@gmail.com [13]

Assistant Editor: Ken Zemrowski

ENGILITY

kenneth.zemrowski@incose.org [14]

Responsible for the Systems Engineering Standards knowledge area.

SEBoK Part 4: Applications of Systems Engineering

Lead Editor: Judith Dahmann

MITRE Corporation (USA)

jdahmann@mitre.org [15]

Jointly responsible for Product Systems Engineering and Systems ofSystems (SoS) knowledge areas

Assistant Editor: Michael Henshaw

Loughborough University (UK)

M.J.d.Henshaw@lboro.ac.uk [16]

Jointly responsible for Product Systems Engineering and Systems ofSystems (SoS) knowledge areas

Assistant Editor: James Martin

The Aerospace Corporation

james.martin@incose.org [17]

Responsible for the Enterprise Systems Engineering knowledge area.

BKCASE Governance and Editorial Board 5

SEBoK Part 5: Enabling Systems Engineering

Assistant Editor: Emma Sparks

Cranfield University

Jointly responsible for the Enabling IndividualsandEnabling Teams knowledge area

Assistant Editor: Rick Hefner

California Institute of Technology

Rick.Hefner@ngc.com [18]

Assistant Editor: Tim Ferris Cranfield University

Timothy.Ferris@cranfield.ac.uk [19]Assistant Editor: Bernardo Delicado

MBDA / INCOSE

bernardo.delicado@mbda-systems.com [20]

SEBoK Part 6: Related Disciplines

Lead Editor: Alice Squires

Washington State University (USA)

alice.squires@wsu.edu [21]

SEBoK Part 7: Systems Engineering Implementation Examples

Lead Author: Clif Baldwin

FAA Technical Center

cliftonbaldwin@gmail.com [22]

Responsible for Part 7: Systems Engineering Implementation Examples, which includes Case Studies and examples.

Graduate Reference Curriculum for Systems Engineering (GRCSE)

David H. Olwell

St. Martin's University (USA)

dolwell@stmartin.edu [23]

Associate Editor for SEBoK.

Graduate Student SupportWith SEBoK v. 2.1, the Governing Board has hired a graduate student to support the Editor in Chief and ManagingEditor. Madeline Haas, a master's student at George Mason University, is the current graduate student supporting theSEBoK and we gratefully acknowledge her exemplary efforts.

Interested in Editing?The Editor in Chief is looking for additional editors to support the evolution of the SEBoK. Editors are responsiblefor maintaining and updating one to two knowledge areas, including recruiting and working with authors, ensuringthe incorporation of community feedback, and maintaining the quality of SEBoK content. We are specificallyinterested in support for the following knowledge areas:•• System Deployment and Use•• Product and Service Life Management•• Enabling Businesses and Enterprises•• Systems Engineering and Software Engineering•• Procurement and Acquisition•• Systems Engineering and Specialty Engineering

BKCASE Governance and Editorial Board 6

If you are interested in being considered for participation on the Editorial Board, please visit the BKCASE websitehttp:/ / www. bkcase. org/ join-us/ or contact the BKCASE Staff directly at bkcase.incose.ieeecs@gmail.com [24].

SEBoK v. 2.1, released 31 October 2019

References[1] mailto:rcloutier@southalabama. edu[2] mailto:nicole. hutchison@stevens. edu[3] mailto:emtnicole@gmail. com[4] mailto:gary. r. smith@airbus. com[5] mailto:dori@mit. edu[6] mailto:dhyberts@mitre. org[7] mailto:Peter@coexploration. net[8] mailto:dagli@mst. edu[9] mailto:boehm@usc. edu[10] mailto:kforsberg@ogrsystems. com[11] mailto:gparnell@uark. edu[12] mailto:garry. j. roedler@lmco. com[13] mailto:prmarbach@gmail. com[14] mailto:kenneth. zemrowski@incose. org[15] mailto:jdahmann@mitre. org[16] mailto:M. J. d. Henshaw@lboro. ac. uk[17] mailto:james. martin@incose. org[18] mailto:Rick. Hefner@ngc. com[19] mailto:Timothy. Ferris@cranfield. ac. uk[20] mailto:bernardo. delicado@mbda-systems. com[21] mailto:alice. squires@wsu. edu[22] mailto:cliftonbaldwin@gmail. com[23] mailto:dolwell@stmartin. edu[24] mailto:bkcase. incose. ieeecs@gmail. com

Acknowledgements and Release History 7

Acknowledgements and Release HistoryThis article describes the contributors to the current version of the SEBoK. For information on contributors to pastversions of the SEBoK, please follow the links under "SEBoK Release History" below. To learn more about theupdates to the SEBoK for v. 2.1, please see the Letter from the Editor.The BKCASE Project began in the fall of 2009. Its aim was to add to the professional practice of systemsengineering by creating two closely related products:•• Guide to the Systems Engineering Body of Knowledge (SEBoK)•• Graduate Reference Curriculum for Systems Engineering (GRCSE)

BKCASE History, Motivation, and ValueThe Guide to the Systems Engineering Body of Knowledge (SEBoK) is a living authoritative guide that discussesknowledge relevant to Systems Engineering. It defines how that knowledge should be structured to facilitateunderstanding, and what reference sources are the most important to the discipline. The curriculum guidance in theGraduate Reference Curriculum for Systems Engineering (GRCSE) (Pyster and Olwell et al. 2015) makesreference to sections of the SEBoK to define its core knowledge; it also suggests broader program outcomes andobjectives which reflect aspects of the professional practice of systems engineering as discussed across the SEBoK.Between 2009 and 2012 BKCASE was led by Stevens Institute of Technology and the Naval Postgraduate School incoordination with several professional societies and sponsored by the U.S. Department of Defense (DoD), whichprovided generous funding. More than 75 authors and many other reviewers and supporters from dozens ofcompanies, universities, and professional societies across 10 countries contributed many thousands of hours writingthe SEBoK articles; their organizations provided significant other contributions in-kind.The SEBoK came into being through recognition that the systems engineering discipline could benefit greatly byhaving a living authoritative guide closely related to those groups developing guidance on advancing the practice,education, research, work force development, professional certification, standards, etc.At the beginning of 2013, BKCASE transitioned to a new governance model with shared stewardship between theSystems Engineering Research Center (SERC) [1], the International Council on Systems Engineering (INCOSE) [2],and the Institute of Electrical and Electronics Engineers Computer Society (IEEE-CS) [3]. This governance structurewas formalized in a memorandum of understanding between the three stewards that was finalized in spring of 2013.The stewards have reconfirmed their commitment to making the SEBoK available at no cost to all users, a keyprinciple of BKCASE.As of the end of July 2019, SEBoK articles have had over 3.4M pageviews from 1.7M unique visits. We hope theSEBoK will regularly be used by thousands of systems engineers and others around the world as they undertaketechnical activities such as eliciting requirements, creating systems architectures, or analysis system test results; andprofessional development activities such as developing career paths for systems engineers, deciding new curriculafor systems engineering university programs, etc.

Acknowledgements and Release History 8

GovernanceThe SEBoK is shaped by the BKCASE Editorial Board and is overseen by the BKCASE Governing Board. Acomplete list of members for each of these bodies can be found on the BKCASE Governance and Editorial Boardpage.

Content and Feature Updates for 2.1This version of the SEBoK was released 31 October 2019. This is a significant release of the SEBoK which includesnew articles, new functionality and minor updates throughout. The SEBoK PDF was also updated (see DownloadSEBoK PDF).For more information about this release please refer to Development of SEBoK v. 2.1.

SEBoK Release HistoryThere have been 21 releases of the SEBoK to date, collected into 13 main releases.

Main Releases• Version 2.1 - Current version. This is a significant release with new articles, new functionality, and minor updates

throughout.• Version 2.0 - This was a major release of the SEBoK which included incorporation of multi-media and a number

of changes to the functions of the SEBoK.• Version 1.9.1 - This was a micro release of the SEBoK which included updates to the editorial board, and a

number of updates to the wiki software.• Version 1.9 - A minor update which included updates to the System Resilience article in Part 6: Related

Disciplines, as well as a major restructuring of Part 7: Systems Engineering Implementation Examples. A newexample has been added around the use of model based systems engineering for the thirty-meter telescope.

• Version 1.8 - A minor update, including an update of the Systems of Systems (SoS) knowledge area in Part 4:Applications of Systems Engineering where a number of articles were updated on the basis of developments inthe area as well as on comments from the SoS and SE community. Part 6: Related Disciplines included updates tothe Manufacturability and Producibility and Reliability, Availability, and Maintainability articles.

• Version 1.7 - A minor update, including a new Healthcare SE Knowledge Area (KA), expansion of the MBSEarea with two new articles, Technical Leadership and Reliability, Availability, and Maintainability and a new casestudy on the Northwest Hydro System.

• Version 1.6 - A minor update, including a reorganization of Part 1 SEBoK Introduction, a new article on theTransition towards Model Based Systems Engineering and a new article giving an overview of HealthcareSystems Engineering, a restructure of the Systems Engineering and Specialty Engineering KA.

• Version 1.5 - A minor update, including a restructure and extension of the Software Engineering KnowledgeArea, two new case studies, and a number of corrections of typographical errors and updates of outdatedreferences throughout the SEBoK.

• Version 1.4 - A minor update, including changes related to ISO/IEC/IEEE 15288:2015 standard, three new casestudies and updates to a number of articles.

• Version 1.3 - A minor update, including three new case studies, a new use case, updates to several existingarticles, and updates to references.

• Version 1.2 - A minor update, including two new articles and revision of several existing articles.• Version 1.1 - A minor update that made modest content improvements.• Version 1.0 - The first version intended for broad use.Click on the links above to read more information about each release.

Acknowledgements and Release History 9

Wiki TeamIn January 2011, the authors agreed to move from a document-based SEBoK to a wiki-based SEBoK, and beginningwith v. 0.5, the SEBoK has been available at www.sebokwiki.org [4] Making the transition to a wiki provided threebenefits:1.1. easy worldwide access to the SEBoK;2.2. more methods for search and navigation; and3.3. a forum for community feedback alongside content that remains stable between versions.The Managing Editor is responsible for maintenance of the wiki infrastructure as well as technical review of allmaterials prior to publication. Contact the managing editor at emtnicole@gmail.com [3]

The wiki is currently supported by Ike Hecht from WikiWorks.SEBoK v. 2.1, released 31 October 2019

References[1] http:/ / www. sercuarc. org[2] http:/ / www. incose. org[3] http:/ / www. computer. org[4] http:/ / www. sebokwiki. org

Cite the SEBoKWhen citing the SEBoK in general, users must cite in the following manner:

SEBoK Editorial Board. 2019. The Guide to the Systems Engineering Body of Knowledge (SEBoK), v.2.1, R.J. Cloutier (Editor in Chief). Hoboken, NJ: The Trustees of the Stevens Institute of Technology.Accessed [DATE]. www.sebokwiki.org. BKCASE is managed and maintained by the Stevens Instituteof Technology Systems Engineering Research Center, the International Council on SystemsEngineering, and the Institute of Electrical and Electronics Engineers Computer Society.

To cite a specific article within the SEBoK, please use:SEBoK Authors. Author name(s). "Article Title." in SEBoK Editorial Board. 2019. The Guide to theSystems Engineering Body of Knowledge (SEBoK), v. 2.1 R.J. Cloutier (Editor in Chief). Hoboken, NJ:The Trustees of the Stevens Institute of Technology. Accessed [DATE]. www.sebokwiki.org. BKCASEis managed and maintained by the Stevens Institute of Technology Systems Engineering ResearchCenter, the International Council on Systems Engineering, and the Institute of Electrical and ElectronicsEngineers Computer Society.

Note that each page will include the by line (author names) for the article. If no byline is listed, please use"SEBoK Authors".

When using material from the SEBoK, attribute the work as follows:This material is used under a Creative Commons Attribution-NonCommercial ShareAlike 3.0 UnportedLicense from The Trustees of the Stevens Institute of Technology. See Stevens Terms for Publicationlocated in Copyright Information.

Cite this Page

This feature is located under "Tools" on the left menu. It provides full information to cite the specific article that youare currently viewing; this information is provided in various common citation styles including APA, MLA, andChicago.

Bkcase Wiki:Copyright 10

Bkcase Wiki:CopyrightPlease read this page which contains information about how and on what terms you may use, copy, share,quote or cite the Systems Engineering Body of Knowledge (SEBoK):

Copyright and LicensingA compilation copyright to the SEBoK is held on behalf of the BKCASE Board of Governors by The Trustees of theStevens Institute of Technology ©2019 ("Stevens") and copyright to most of the content within the SEBoK is alsoheld by Stevens. Prominently noted throughout the SEBoK are other items of content for which the copyright is heldby a third party. These items consist mainly of tables and figures. In each case of third party content, such content isused by Stevens with permission and its use by third parties is limited.Stevens is publishing those portions of the SEBoK to which it holds copyright under a Creative CommonsAttribution-NonCommercial ShareAlike 3.0 Unported License. See http:/ / creativecommons. org/ licenses/by-nc-sa/ 3. 0/ deed. en_US for details about what this license allows. This license does not permit use of third partymaterial but gives rights to the systems engineering community to freely use the remainder of the SEBoK within theterms of the license. Stevens is publishing the SEBoK as a compilation including the third party material under theterms of a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported (CC BY-NC-ND 3.0). See http:// creativecommons. org/ licenses/ by-nc-nd/ 3. 0/ for details about what this license allows. This license will permitvery limited noncommercial use of the third party content included within the SEBoK and only as part of the SEBoKcompilation. Additionally, the U.S. government has limited data rights associated with the SEBoK based on theirsupport for the SEBoK development.

AttributionWhen using text material from the SEBoK, users who have accepted one of the Creative Commons Licensesdescribed above terms noted below must attribute the work as follows:This material is used under a Creative Commons Attribution-NonCommercial ShareAlike 3.0 Unported Licensefrom The Trustees of the Stevens Institute of Technology.When citing the SEBoK in general, please refer to the format described on the Cite the SEBoK page.When using images, figures, or tables from the SEBoK, please note the following intellectual property (IP)classifications:•• Materials listed as "SEBoK Original" may be used in accordance with the Creative Commons attribution (above).•• Materials listed as "Public Domain" may be used in accordance with information in the public domain.• Materials listed as "Used with Permission" are copyrighted and permission must be sought from the copyright

owner to reuse them.

11

Part 1: SEBoK Introduction

SEBoK IntroductionThe purpose of the Guide to the Systems Engineering Body of Knowledge (SEBoK) is to provide a widely accepted,community-based, and regularly updated baseline of systems engineering (SE) knowledge. SEBoK Part 1 containsan introduction to both the discipline of SE and an introduction to the SEBoK wiki and how to use it.

Figure 1 SEBoK Part 1 in context (SEBoK Original). For more detail see Structure of the SEBoK

Part 1 also includes an introduction to some of the emerging aspects of systems engineering and a discussion of howthese are transforming the discipline. As this knowledge matures it will be migrated into the main body of theSEBoK.

SEBoK Introduction 12

Part 1 Knowledge AreasEach part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a relatedtheme. Part 1 contains the following KAs:•• Introduction to the SEBoK•• Introduction to Systems Engineering•• Introduction to SE Transformation•• Digital Engineering•• Set Based Design•• SEBoK Users and Uses

Scope and Context of the SEBoKWhile Part 1 introduces Systems Engineering knowledge areas, the remaining SEBoK content (Parts 2 – 6) focuseson domain-independent information—that which is universal to systems engineering regardless of the domain inwhich it is applied. Part 7 includes examples from real projects. These illustrate the concepts discussed elsewhere inthe SEBoK, while detailing considerations relevant to domains such as aerospace, medicine, and transportation.SE in the context of engineered systems (ES) is the primary scope for the SEBoK, though general systems conceptsare also discussed in Part 2. The SEBoK also covers considerations for the disciplines of software engineering andproject management, which are strongly intertwined with the practice of SE (see Part 6).

References

Works CitedNone

Primary ReferencesNone

< Return to Table of Contents | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

Introduction to the SEBoK 13

Introduction to the SEBoKThe SEBoK provides a widely accepted, community-based, and regularly updated baseline of systems engineering(SE) knowledge. Therefore, it is a curated body of knowledge which is updated on a semi-annual basis. This baselinestrengthens the mutual understanding across the many disciplines involved in developing and operating systems.

TopicsEach part of the SEBoK is divided into KAs (knowledge areas), which are groupings of information with a relatedtheme. The KAs in turn are divided into topics. This KA contains the following topics:•• Scope of the SEBoK•• Structure of the SEBoK

References

Works CitedNone.

Primary ReferencesINCOSE. 2015. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, FourthEdition. San Diego, CA, USA: International Council on Systems Engineering (INCOSE).INCOSE-TP-2003-002-004.INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.Sage, A. and W. Rouse (eds). 2009. Handbook of Systems Engineering and Management, 2nd ed. Hoboken, NJ,USA: John Wiley and Sons, Inc.

Additional ReferencesNone.

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

14

Knowledge Area: Introduction to theSEBoK

Scope of the SEBoKThe SEBoK is a large, curated compendium of information about systems 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 Systems contexts, that is socio-technical systems with a recognized SE life cycle,• while treating social and natural systems as relevant and important environmental considerations (see Part 2)• describes generic SE life cycle and process knowledge (see Part 3)• recognizes that SE principles can be applied differently to different types of products, services, enterprises, and

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

SEBoK PurposesOngoing studies of system cost and schedule failures (Gruhl & Stutzke 2005; Johnson 2006, GAO 2016) and safetyfailures (Leveson 2012) have shown that the failures have mostly come not from their domain disciplines, but fromlack of adequate Systems Engineering (NDIA 2003, 2006, 2016). To provide a foundation for the mutualunderstanding of SE needed to reduce these failure, the SEBoK describes the boundaries, terminology, content, andstructure of SE. In so doing, the SEBoK systematically and consistently supports six broad purposes, described inTable 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 usefulinformation 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 researchagenda.

3 Inform Interactors Inform performers in interacting disciplines (system implementation, project and enterprise management, otherdisciplines) and other stakeholders of the nature and value of SE.

4 Inform CurriculumDevelopers

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 that practicing systems engineers should possess invarious roles ranging from apprentice to expert.

Scope of the SEBoK 15

The SEBoK is a guide to the body of SE knowledge, not an attempt to capture that knowledge directly. It providesreferences to more detailed sources of knowledge, all of which are generally available to any interested reader. Noproprietary information is referenced, but not all referenced material is free—for example, some books or standardsmust be purchased from their publishers. The criterion for including a source is simply that the authors & editorsbelieved 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 tocountry, the SEBoK is written to be useful to systems engineers anywhere. The authors & editors were chosen fromdiverse locales and industries, and have refined the SEBoK to broaden applicability based on extensive globalreviews of several drafts.The SEBoK aims to inform a wide variety of user communities about essential SE concepts and practices, in waysthat can be tailored to different enterprises and activities while retaining greater commonality and consistency thanwould be possible without the SEBoK. Because the world in which SE is being applied continues to evolve and isdynamic, the SEBoK is designed for easy, continuous updating as new sources of knowledge emerge.

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

SEBoK Domain Independent ContextThe SEBoK uses language and concepts that are generally accepted for domain-independent SE. For example, thedomain-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 isdesigned 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: SystemsEngineering Implementation Examples ) consists of examples (case studies and vignettes), each set in a particulardomain 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 onthe application of SE and complement the domain-independent information elsewhere in the SEBoK. They showhow a concept works in a given domain and provide a fair opportunity for reviewers to reflect on whether there arebetter ways to capture application-dependent aspects of SE knowledge.In addition, the SEBoK will contain knowledge areas in Part 4: Applications of Systems Engineering whichexplicitly describe the domain specific language, approaches, specialized processes and tools, etc. of particularapplication domains. In this version of the SEBoK there are a limited set of domain knowledge areas.The SEBoK authors & editors recognize the value of both case studies and domain extensions, both will be expandedin later versions.

Scope of the SEBoK 16

References

Works CitedGAO, 2016. Weapon System Requirements. Detailed Systems Engineering Prior to Product Development PositionsPrograms 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: MITPress.NDIA (National Defense Industrial Association). 2003. Top 5 Systems Engineering Issues Top 5 SystemsEngineering Issues within DOD and Defense Industry Task Report. Version 9, dated 1/23/03July. Last accessed10/25/2019 from https:/ / www. aticourses. com/ sampler/ TopFiveSystemsEngineeringIssues_In_DefenseIndustry.pdf [1].NDIA (National Defense Industrial Association). 2006. Top 5 Systems Engineering Issues Top 5 SystemsEngineering Issues within DOD and Defense Industry DOD and Defense Industry: Task Report. Dated July 26-27,2006. Last accessed 10/25/2019 from https:/ / ndiastorage. blob. core. usgovcloudapi. net/ ndia/ 2006/ systems/Wednesday/ rassa5. pdf.NDIA (National Defense Industrial Association). 2016. Top Systems Engineering Issues In US Defense Industry2016. Version 7c. Last accessed 10/25/2019 from https:/ / www. ndia. org/ -/ media/ sites/ ndia/ divisions/systems-engineering/ studies-and-reports/ ndia-top-se-issues-2016-report-v7c. ashx?la=en.

Primary ReferencesNone.

Additional ReferencesNone.

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

References[1] https:/ / ndiastorage. blob. core. usgovcloudapi. net/ ndia/ 2006/ systems/ Wednesday/ rassa5. pdf

Structure of the SEBoK 17

Structure of the SEBoKThe Guide to the Systems Engineering Body of Knowledge (SEBoK) is a living authoritative guide that discussesknowledge relevant to Systems Engineering. SEBoK does not contain all of this knowledge itself, but provides astarting point and key resources to allow the reader to navigate the wider body of knowledge that exists in publishedsources. To do this SEBoK:•• Defines relevant knowledge and structures it to facilitate understanding.•• Provides short discussions of key idea, principles and concepts within that structure.•• Points to reference sources important to the discipline, which explore these ideas in more detail.In doing this it is inevitable that differences in terminology, alternative approaches and even fundamentally differentways of thinking within the knowledge will appear. SEBoK attempts were possible to provide clarity of similar oroverlapping idea, or to highlight real differences and the reasons behind them. In particular the SEBoK Glossary ofTerms contains the most used or generally agreed definitions of terms when it can, but may highlight more than onedefinition if needed to show breadth of current thinking.

SEBoK StructureFigure 1, below, gives a summary of the 7 parts of the SEBoK and how they are related.

Figure 1 Relationships between SEBoK Parts (Adcock et al. 2016).

The scope of each part and the key relationships amongst them is briefly discussed below. For a more detaileddiscussion of how this structure was evolved see (Adcock et al, 2016).

Structure of the SEBoK 18

Overview of Parts

Part 1: SEBoK IntroductionThis part explains the scope, context, and structure of the SEBoK, and of systems engineering (SE).An overview of who should use the SEBoK, and for what purpose, is followed by detailed use cases. The economicvalue, history, and relationship to other disciplines are discussed. Part 1 also contains a section which discussed thefuture evolution of the SEBoK and allows for new areas of content to be introduced before being transitioned intoother SEBoK parts.

Part 2: Foundations of Systems EngineeringThis part provides an introduction and overview of areas of knowledge which provide the foundations of SE.A discussion of the definitions and basic concepts of system is followed by an overview of the principles, concepts,methods, models and patterns of some of the key foundational areas of systems science. This includes a detailedconsideration of the foundational knowledge related to systems models and modelling.Part 2 looks in more detail at two aspects of this foundational knowledge of particular value to SE. The first is todiscuss aspects of systems knowledge related to a systems approach to complex problems and opportunities. Thisapproach provides foundations for how SE is defined and practices (see Parts 3 and 5 below). The second is todescribe the different ways in which system concepts are applied to real world concerns. The SEBoK defines anengineered system (ES) as the primary focus for the application of SE (see Part 4 below).

Part 3: Systems Engineering and ManagementThis part describes generic knowledge on the practice of SE and related management activities.Part 3 begins with the life cycle models common in SE and the general principles behind their application. It thenmoves on to SE management activities. Covering both technical activities such as requirements, architecture, test andevaluation; and management activities such as planning, measurement, risk. Next is product and service lifemanagement, a distinct area of SE management that emphasizes the entire life cycle including retirement anddisposal. An account of SE standards concludes this part.Focused on what many think of as the main body of SE, including best practices and common pitfalls, this partconstitutes a substantial proportion of the SEBoK. As already discussed, the knowledge in Part 3 is based on thesystems approach from Part 2. The links between Part 3 and the other parts of the SEBoK are discussed below.

Part 4: Applications of Systems EngineeringThis part describes how to apply SE principles to different types of system context.Part 4 focuses on four major engineered system contexts in turn: products, services, enterprises, and systems ofsystems (SoS). For each one the system abstraction, commercial relationships and application of generic SE isdescribed.The generalized contexts above should be viewed as overlapping models of how SE can be applied in different kindsof situation. Combinations of one or more of them are fully realized when applied in an application domain. Part 4currently described this application in a small number of such domains. This will be expanded in later updates. Theapplications of SE in this part describe the real world practice of SE. The generalized knowledge in both Parts 2 and3 evolves through what we learn from these applications. Part 2 includes a discussion of this relationship betweentheory and practice.

Structure of the SEBoK 19

Part 5: Enabling Systems EngineeringThis part describes how to organize to enable the success performance of SE activities.Part 4 covers knowledge at the enterprise, team, or individual level. The range of considerations extends from valueproposition, business purpose, and governance, down to competency, personal development as a systems engineer,and ethics.All of these relate to the baseline definitions of SE in Part 3, further generalized in the levels of application in Part 4.The systems approach in Part 2 should also form a foundation for this part. Since the practice of SE istransdisciplinary, Part 5 also has a link to Part 6 as discussed below.

Part 6: Related DisciplinesThis part describes the relationships between SE and other disciplines.Part 6 covers the links between SE and software engineering (SwE), project management (PM), industrialengineering and procurement. It also describes how SE is related to specialty engineering, which describes thevarious system “–ilities” (like reliability, availability, and maintainability) that SE must balance and integrate.The knowledge in this part provides an interface to other bodies of knowledge, focused on how it is linked to Parts 3,5 and 5 above.

Part 7: Systems Engineering Implementation ExamplesA set of real-world examples of SE activities forms the natural conclusion of the SEBoK. These come in two forms:case studies, which refer the reader to and summarize published examinations of the successes and challenges of SEprograms, and vignettes, which are brief, self-contained wiki articles. This part is a key place to look within theSEBoK for lessons learned, best practices, and patterns. Many links connect material in the examples to theconceptual, methodological, and other content elsewhere in the SEBoK.

AddendaThe SEBoK contains a Glossary of Terms, which provides authoritatively-referenced definitions of key terms. Thisinformation is displayed when the reader hovers the mouse pointer over a glossary term within an article. It alsocontains a list of Primary References, with additional information about each reference. Quicklinks in the left marginprovide additional background information, including a table of contents, a listing of articles by topic [1], and a list ofAcronyms.

References

Works CitedAdcock, R., Hutchison, N., Nielsen, C., 2016, "Defining an architecture for the Systems Engineering Body ofKnowledge," Annual IEEE Systems Conference (SysCon) 2016.

Primary ReferencesNone.

Additional ReferencesNone.

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

Structure of the SEBoK 20

References[1] http:/ / sebokwiki. org/ 1. 1. 1/ index. php?title=Category:Topic

21

Knowledge Area: Introduction to SystemsEngineering

Introduction to Systems EngineeringThe primary focus of the SEBoK is on the current baseline of knowledge describing the practice of domainindependent systems engineering (SE). This Knowledge Area (KA) contains topic articles which provide anoverview of SE practice and discuss its economic value, historic evolution and key relationships.

TopicsEach part of the SEBoK is divided into KAs, which are groupings of information with a related theme. The KAs inturn are divided into topics. This KA contains the following topics:•• Systems Engineering Overview•• Economic Value of Systems Engineering•• Systems Engineering: Historic and Future Challenges•• Systems Engineering and Other Disciplines

Systems EngineeringSE is a transdisciplinary approach and means to enable the realization of successful systems. Successful systemsmust satisfy the needs of its customers, users and other stakeholders. Some key elements of systems engineering arehighlighted in Figure 1 and include:•• The principles and concepts that characterize a system, where a system is an interacting combination of system

elements to accomplish a defined objective(s). The system interacts with its environment, which may includeother systems, users, and the natural environment. The system elements that compose the system may includehardware, software, firmware, people, information, techniques, facilities, services, and other support elements.

•• A systems engineer is a person or role who supports this transdisciplinary approach. In particular, the systemsengineer often serves to elicit and translate customer needs into specifications that can be realized by the systemdevelopment team.

•• In order to help realize successful systems, the systems engineer supports a set of life cycle processes beginningearly in conceptual design and continuing throughout the life cycle of the system through its manufacture,deployment, use and disposal. The systems engineer must analyze, specify, design, and verify the system toensure that its functional, interface, performance, physical, and other quality characteristics, and cost are balancedto meet the needs of the system stakeholders.

•• A systems engineer helps ensure the elements of the system fit together to accomplish the objectives of the whole,and ultimately satisfy the needs of the customers and other stakeholders who will acquire and use the system.

Introduction to Systems Engineering 22

Figure 1. Key Elements of Systems Engineering. (SEBoK Original)

ReferencesNone.

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

Systems Engineering Overview 23

Systems Engineering OverviewSystems engineering (SE) is a transdisciplinary approach and means to enable the realization of successful systems.Successful systems must satisfy the needs of their customers, users and other stakeholders. This article provides anoverview SE as discussed in the SEBoK and the relationship between SE and systems (for additional information onthis, please see Part 2).

Systems and Systems EngineeringIn the broad community, the term system “system,” may mean a collection of technical, natural or social elements, ora combination of all three. This may produce ambiguities at times: for example, does “management” refer tomanagement of the SE process, or management of the system being engineered? As with many special disciplines,SE uses terms in ways that may be unfamiliar outside the discipline. For example, in systems science and thereforeSE, “open” means that a system is able to interact with its environment--as opposed to being "closed” to itsenvironment. But in the broader engineering world we would read “open” to mean “non-proprietary” or “publiclyagreed upon.” In such cases, the SEBoK tries to avoid misinterpretation by elaborating the alternatives e.g. “systemmanagement” or “systems engineering management”.The SEBoK seeks to position SE within the broader scope of knowledge which considers systems as part of itsfoundations. To do this without attempting to re-define general systems terminology SEBoK introduces two relateddefinitions specific to SE:•• An engineered system, is a technical or socio-technical systems system which is the subject of a SE life cycle•• An engineered system is a system designed or adapted to interact with an anticipated operational environment to

achieve one or more intended purposes while complying with applicable constraints.•• An engineered system context centers around an engineered system but also includes its relationships other

engineered, social or natural systems in one or more defined environments.Since the province of SE is an engineered systems, most SE literature assumes this in its terminology. Thus, in an SEdiscussion, “system architecture” would refer to the architecture of the system being engineered (e.g., a spacecraft)and not the architecture of a natural system outside its boundary (e.g., the solar system). In fact, a spacecraftarchitecture would cover the wider system context including external factors such as changes in gravity and externalair pressure and how these affect the spacecraft's technical and human elements. Thus, the term "system architecture"more properly refers to the engineered system context. The SEBoK tries to be more explicit about this, but may stillmake these kinds of assumption when referring directly to other SE literature.An extensive glossary of terms identifies how terms are used in the SEBoK, and shows how their meanings mayvary in different contexts. As needed, the glossary includes pointers to articles providing more detail.For more about the definition of systems, see the article What is a System? in Part 2. The primary focus of SEBoKPart 3: Systems Engineering and Management, and Part 4: Applications of Systems Engineering is on how to createor change an engineered system to fulfill the goals of stakeholders within these wider system contexts. Theknowledge in Part 5: Enabling Systems Engineering and Part 6: Systems Engineering and Other Disciplinesexamines the need for SE itself to be integrated and supported within the human activity systems in which it isperformed, and the relationships between SE and other engineering and management disciplines.

Systems Engineering Overview 24

Scope of Systems Engineering within the Engineered Systems DomainThe scope of SE does not include everything involved in the engineer and management of an engineered system.Activities can be part of the SE environment, but other than the specific management of the SE function, notconsidered to be part of SE. Examples include system construction, manufacturing, funding, and generalmanagement. This is reflected in the International Council on Systems Engineering (INCOSE) top-level definition ofsystems engineering as, “A transdisiplinary and integrative approach to enable the successful realization, use, andretirement of engineered systems, using systems principles and concepts, and scientific, technological, andmanagement methods.” (Fellows 2019) Although SE can enable the realization of a successful system, if an activitythat is outside the scope of SE, such as manufacturing, is poorly managed and executed, SE cannot ensure asuccessful realization.A convenient way to define the scope of SE within engineering and management is to develop a Venn diagram.Figure 3 shows the relationship between SE, system implementation, and project/systems management. Activities,such as analyzing alternative methods for production, testing, and operations, are part of SE planning and analysisfunctions. Such activities as production line equipment ordering and installation, and its use in manufacturing, whilestill important SE environment considerations, stand outside the SE boundary. Note that as defined in Figure 3,system implementation engineering also includes the software production aspects of system implementation.Software engineering, then, is not considered a subset of SE.

Figure 3. 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., “documentingrequirements, then proceeding with design synthesis …”. (INCOSE 2012) Originally, the SEBoK authors & editorsdeparted from tradition to emphasize the inevitable intertwining of system requirements definition and system designin the following revised definition of SE:

Systems Engineering Overview 25

Systems Engineering (SE) is an interdisciplinary approach and means to enable the realization ofsuccessful systems. It focuses on holistically and concurrently understanding stakeholder needs;exploring opportunities; documenting requirements; and synthesizing, verifying, validating, andevolving solutions while considering the complete problem, from system concept exploration throughsystem disposal. (INCOSE 2012, modified)

More recently, the INCOSE Fellows have offered an updated definition of SE that has been adopted as the officialINCOSE definition:

A transdisiplinary and integrative approach to enable the successful realization, use, and retirement ofengineered systems, using systems principles and concepts, and scientific, technological, andmanagement methods.

Part 3: Systems Engineering and Management, elaborates on the definition above to flesh out the scope of SE morefully.

Systems Engineering and Engineered Systems Project Life Cycle ContextSE is performed as part of a life cycel approach. Figure 2 summarizes the main agents, activities, and artifactsinvolved in the life cycle of SE, in the context of a project to create and evolve an engineered system.

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

For each primary project life cycle phase, we see activities being performed by primary agents, changing the state ofthe ES.•• Primary project life cycle phases appear in the leftmost column. They are system definition, system initial

operational capability (IOC) development, and system evolution and retirement.•• Primary agents appear in the three inner columns of the top row. They are systems engineers, systems developers,

and primary project-external bodies (users, owners, external systems) which constitute the project environment.•• The ES, which appears in the rightmost column, may be a product, a service, and/or an enterprise.

Systems Engineering Overview 26

In each row:•• boxes in each inner column show activities being performed by the agent listed in the top row of that column•• the resulting artifacts appears in the rightmost box.Arrows indicate dependencies: an arrow from box A to box B means that the successful outcome of box B dependson the successful outcome of box A. Two-headed arrows indicate a two-way dependencies: an arrow that points bothfrom box A to box B and from box B to box A means that the successful outcome of each box depends on thesuccessful outcome of the other.For example, consider how the inevitable changes that arise during system development and evolution are handled:• One box shows that the system’s users and owners may propose changes.•• The changes must be negotiated with the systems developers, who are shown in a second box.•• The negotiations are mediated by systems engineers, who are shown in a third box in between the first two.•• Since the proposed changes run from left to right and the counter-proposals run from right to left, all three boxes

are connected by two-headed arrows. This reflects the two-way dependencies of the negotiation.An agent-activity-artifact diagram like Figure 1 can be used to capture complex interactions. Taking a more detailedview of the present example demonstrates that:• The system’s users and owners (stakeholders) 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-ShelfCOTS products, cloud services, or supply chain enablers.

•• Negotiation among these stakeholders and the system developers follows, mediated by the SEs.•• The role of the SEs is to analyze the relative costs and benefits of alternative change proposals, and synthesize

mutually satisfactory solutions.

References

Works CitedCheckland, P. 1981. Systems Thinking, Systems Practice. Hoboken, NJ, USA: Wiley.INCOSE. 2012. Systems Engineering Handbook, version 3.2.2. San Diego, CA, USA: International Council onSystems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.Fellows. 2019. INCOSE Fellows Briefing to INCOSE Board of Directors. January 2019.Rechtin, E. 1991. Systems Architecting. Upper Saddle River, NJ, USA: Prentice Hall.

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

Additional ReferencesNone.

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

Economic Value of Systems Engineering 27

Economic Value of Systems Engineering

The Increasing Value of Systems EngineeringWith traditional projects, such as railroads, reservoirs, and refrigerators, a systems engineer faced a self-containedsystem that typically had relatively stable requirements, a sound scientific base, and numerous previous precedents.As most modern systems become parts within one or more evolving systems of systems (SoS), the performance ofeffective SE now takes on an ever-higher economic value, as the systems feature a rapidly increasing scale,dynamism, interdependence, human-intensiveness, sources of vulnerability, and novelty.This is corroborated by the implementation examples in Part 7. Shortfalls in SE lead to either cancellation of alreadyexpensive systems or even more expensive systems in terms of total cost of ownership or loss of human life. Part 7presents the problems in the United States Federal Aviation Administration (FAA) Advanced Automation System(AAS), United States Federal Bureau of Investigation (FBI) Virtual Case File System, the Hubble Space TelescopeCase Study, and the Therac-25 medical linear accelerator.On the other hand, the Global Positioning System (GPS), Miniature Seeker Technology Integration Project (MSTI),and Next Generation Medical Infusion Pump Project all demonstrate that investment in thorough SE results in highlycost-effective systems. Figure 1 summarizes the analyses data by Werner Gruhl, which relates investment levels inSE to cost overruns of the United States National Aeronautics and Space Administration (NASA) projects (Stutzke2005). The results indicate that there is a general correlation between the amount invested in SE within a programand cost overruns, demonstrating the critical role of properly allocating SE resources.

Figure 1. Relation of SE Investments to NASA Program Cost Overruns (Stutzke 2005). Released by NASA HDQRT/Gruhl.

Economic Value of Systems Engineering 28

Further Quantitative Evidence of the Value of Systems EngineeringAnalysis of the effects of shortfalls in systems architecture and risk resolution (the results of insufficient SE) forsoftware-intensive systems in the 161-project Constructive Cost Model II (COCOMO™ II) database, shows astatistically significant increase in rework costs as a function of project size measured in source lines of code(SLOC): averages of 18% rework for ten-thousand-SLOC projects and 91% rework for ten-million-SLOC projects.This data has influenced many major system projects to reconsider initial underinvestment in SE (e.g., Boehm et al.2004), and well as to address “how much SE is enough” by balancing the risks of under-investing in SE against thoseof over-investing (often called “analysis paralysis”), as shown in Figure 2 (Boehm, Valerdi, and Honour 2008).

Figure 2. Risk-Balanced “How Much SE Is Enough” (Boehm, Valerdi, andHonour 2008). Reprinted with permission of John Wiley & Sons Inc. All other

rights are reserved by the copyright owner.

Typically, small projects can quickly compensate for neglected SE interface definition and risk resolution; however,as projects grow larger and have more independently-developed components, the cost of late rework negates anysavings in reduced SE effort. Additionally, medium-sized projects have relatively flat operating regions, while verylarge projects pay extremely large penalties for neglecting thorough SE. Extensive surveys and case study analysescorroborate these results.Survey data on software cost and schedule overruns in My Life Is Failure: 100 Things You Should Know to Be a Better Project Leader (Johnson 2006) indicates that the primary sources of the roughly 50% of the commercial projects with serious “software overruns” are the result of shortfalls in SE (lack of user input, incomplete requirements, unrealistic expectations, unclear objectives, and unrealistic schedules). The extensive survey of 46 government-contracted industry projects conducted by the Software Engineering Institute (SEI)/National Defense Industrial Association (NDIA) illustrated a strong correlation between higher project SE capability and higher project performance (Elm et al. 2007). Ongoing research that combined project data and survey data reported in

Economic Value of Systems Engineering 29

“Toward an Understanding of The Value of SE” (Honour 2003) and “Effective Characterization Parameters forMeasuring SE” (Honour 2010) has provided additional evidence as to the economic value of SE and further insightson critical factors the affect SE success.A calibrated model for determining “how much SE is enough”, the Constructive Systems Engineering Cost Model(COSYSMO) has been developed and is discussed in (Valerdi 2008). It estimates the number of person-months thata project needs for SE as a function of system size (i.e., requirements, interfaces, algorithms, and operationalscenarios), modified by 14 factors (i.e., requirements understanding, technology risk, personnel experience, etc.),which dictates the amount of SE effort needed. Other economic considerations of SE include the costs and benefitsof reuse (Wang, Valerdi and Fortune 2010), the management of SE assets across product lines (Fortune and Valerdi2013), the impact of SE on project risk (Madachy and Valerdi 2010), and the role of requirements volatility on SEeffort (Pena and Valerdi 2010).

References

Works CitedBoehm, B., Brown, A.W., Basili, V., and Turner, R. 2004. "Spiral Acquisition of Software-Intensive Systems ofSystems." CrossTalk. May, pp. 4-9.Boehm, B., R. Valerdi, and E.C. Honour. 2008. "The ROI of Systems Engineering: Some Quantitative Results forSoftware-Intensive Systems." Systems Engineering. 11(3): 221-234.Elm, J. P., D.R. Goldenson, K. El Emam, N. Donatelli, and A. Neisa. 2008. A Survey of Systems EngineeringEffectiveness-Initial Results (with Detailed Survey Response Data). Pittsburgh, PA, USA: Software EngineeringInstitute, CMU/SEI-2008-SR-034. December 2008.Fortune, J., and R. Valerdi. 2013. "A Framework for Systems Engineering Reuse." Systems Engineering 16(2).Honour, E.C. 2003. "Toward An Understanding of The Value of Systems Engineering." Proceedings of the FirstAnnual Conference on Systems Integration, March 2003, Hoboken, NJ, USA.Honour, E.C. 2010. "Effective Characterization Parameters for Measuring Systems Engineering." Proceedings of the8th Annual Conference on Systems Engineering Research (CSER). March 17-19, 2010. Hoboken, NJ, USA.Johnson, J. 2006. My Life Is Failure: 100 Things You Should Know to Be a Better Project Leader. Boston, MA,USA: Standish Group International.Madachy, R., and R. Valerdi. 2010. Automating Systems Engineering Risk Assessment. 8th Conference on SystemsEngineering Research, Hoboken, NJ.Pena, M., and R. Valerdi. 2010. "Characterizing the Impact of Requirements Volatility on Systems EngineeringEffort." 25th Forum on COCOMO and Systems/Software Cost Modeling, Los Angeles, CA.Stutzke, R. 2005. Estimating Software-Intensive Systems. Boston, MA, USA: Addison Wesley.Valerdi, R. 2008. The Constructive Systems Engineering Cost Model (COSYSMO): Quantifying the Costs of SystemsEngineering Effort in Complex Systems. Saarbrücken, Germany: VDM Verlag.Wang, G., R. Valerdi, and J. Fortune. 2010. “Reuse in Systems Engineering,” IEEE Systems Journal. 4(3): 376-384.

Economic Value of Systems Engineering 30

Primary ReferencesBoehm, B., R. Valerdi, and E.C. Honour. 2008. "The ROI of Systems Engineering: Some Quantitative Results forSoftware-Intensive Systems." Systems Engineering, 11(3): 221-234.Honour, E.C. 2010. "Effective Characterization Parameters for Measuring Systems Engineering." Proceedings of the8th Annual Conference on Systems Engineering Research (CSER). March 17-19, 2010. Hoboken, NJ, USA.Valerdi, R. 2008. The Constructive Systems Engineering Cost Model (COSYSMO): Quantifying the Costs of SystemsEngineering Effort in Complex Systems. Saarbrücken, Germany: VDM Verlag.

Additional ReferencesHughes, T.P. 2000. Rescuing Prometheus: Four Monumental Projects that Changed the Modern World. New York,NY: Vintage Books.Vanek, F., R. Grzybowski, P. Jackson, and M. Whiting. 2010. "Effectiveness of Systems Engineering Techniques onNew Product Development: Results from Interview Research at Corning Incorporated." Proceedings of the 20thAnnual INCOSE International Symposium. 12-15 July 2010. Chicago, IL.

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

Systems Engineering: Historic and FutureChallengesHumans have faced increasingly complex challenges and have had to think systematically and holistically in order toproduce successful responses to these challenges. From these responses, generalists have developed genericprinciples and practices for replicating success. Some of these principles and practices have contributed to theevolution of systems engineering as a discipline.

Historical PerspectiveSome of the earliest relevant challenges were in organizing cities. Emerging cities relied on functions such as storinggrain and emergency supplies, defending the stores and the city, supporting transportation and trade, providing awater supply, and accommodating palaces, citadels, afterlife preparations, and temples. The considerable holisticplanning and organizational skills required to realize these functions were independently developed in the MiddleEast, Egypt, Asia, and Latin America, as described in Lewis Mumford’s The City in History (Mumford 1961).Megacities, and mobile cities for military operations, such as those present in the Roman Empire, emerged next,bringing another wave of challenges and responses. These also spawned generalists and their ideological works, suchas Vitruvius and his Ten Books on Architecture (Vitruvius: Morgan transl. 1960). “Architecture” in Rome meant notjust buildings, but also aqueducts, central heating, surveying, landscaping, and overall planning of cities.The Industrial Revolution brought another wave of challenges and responses. In the nineteenth century, new holisticthinking and planning went into creating and sustaining transportation systems, including canal, railroad, andmetropolitan transit. General treatises, such as The Economic Theory of the Location of Railroads (Wellington1887), appeared in this period. The early twentieth century saw large-scale industrial enterprise engineering, such asthe Ford automotive assembly plants, along with treatises like The Principles of Scientific Management (Taylor1911).

Systems Engineering: Historic and Future Challenges 31

The Second World War presented challenges around the complexities of real-time command and control ofextremely large multinational land, sea, and air forces and their associated logistics and intelligence functions. Thepostwar period brought the Cold War and Russian space achievements. The U.S. and its allies responded to thesechallenges by investing heavily in researching and developing principles, methods, processes, and tools for militarydefense systems, complemented by initiatives addressing industrial and other governmental systems. Landmarkresults included the codification of operations research and SE in Introduction to Operations Research (Churchmanet. al 1957), Warfield (1956), and Goode-Machol (1957) and the Rand Corporation approach as seen in Efficiency inGovernment Through Systems Analysis (McKean 1958). In theories of system behavior and SE, we see cybernetics(Weiner 1948), system dynamics (Forrester 1961), general systems theory (Bertalanffy 1968), and mathematicalsystems engineering theory (Wymore 1977).Two further sources of challenge began to emerge in the 1960s, and accelerated in the 1970s through the 1990s:awareness of the criticality of the human element, and the growth of software functionality in engineered systems.Concerning awareness of the human element, the response was a reorientation from traditional SE toward “soft” SEapproaches. Traditional hardware-oriented SE featured sequential processes, pre-specified requirements,functional-hierarchy architectures, mathematics-based solutions, and single-step system development. A SoftSystems approach to SE is characterized by emergent requirements, concurrent definition of requirements andsolutions, combinations of layered service-oriented and functional-hierarchy architectures, heuristics-basedsolutions, and evolutionary system development. Good examples are societal systems (Warfield 1976), soft systemsmethodology (Checkland 1981), and systems architecting (Rechtin 1991 and Rechtin-Maier 1997). As withVitruvius, "architecting" in this sense is not confined to producing blueprints from requirements, but instead extendsto concurrent work on operational concepts, requirements, structure, and life cycle planning.The rise of software as a critical element of systems led to the definition of Software Engineering as a closely relateddiscipline to SE. The Systems Engineering and Software Engineering knowledge area in Part 6: Related Disciplinesdescribes how software engineering applies the principles of SE to the life cycle of computational systems (in whichany hardware elements form the platform for software functionality) and of the embedded software elements withinphysical systems.

Evolution of Systems Engineering ChallengesSince 1990, the rapidly increasing scale, dynamism, and vulnerabilities in the systems being engineered havepresented ever-greater challenges. The rapid evolution of communication, computer processing, human interface,mobile power storage and other technologies offers efficient interoperability of net-centric products and services, butbrings new sources of system vulnerability and obsolescence as new solutions (clouds, social networks, searchengines, geo-location services, recommendation services, and electrical grid and industrial control systems)proliferate and compete with each other.Similarly, assessing and integrating new technologies with increasing rates of change presents further SE challenges.This is happening in such areas as biotechnology, nanotechnology, and combinations of physical and biologicalentities, mobile networking, social network technology, cooperative autonomous agent technology, massivelyparallel data processing, cloud computing, and data mining technology. Ambitious projects to create smart services,smart hospitals, energy grids, and cities are under way. These promise to improve system capabilities and quality oflife, but carry risks of reliance on immature technologies or on combinations of technologies with incompatibleobjectives or assumptions. SE is increasingly needed but increasingly challenged in the quest to make future systemsscalable, stable, adaptable, and humane.It is generally recognized that there is no one-size-fits-all life cycle model that works best for these complex systemchallenges. Many systems engineering practices have evolved in response to this challenge making use of lean, agile,iterative and evolutionary approaches to provide methods for simultaneously achieving high-effectiveness,high-assurance, resilient, adaptive, and life cycle affordable systems;. The emergence of system of systems (SoS)

Systems Engineering: Historic and Future Challenges 32

approaches have also been introduced, in which independent system elements developed and deployed within theirown life cycle are brought together to address mission and enterprise needs.Creating flexible and tailored life cycles and developing solutions using combinations of engineered systems, eachwith its own life cycle focus, creates its own challenges of life cycle management and control. In response to thisenterprise systems engineering (ESE) approaches have been developed, which consider the enterprise itself as asystem to be engineered. Thus, many of the ambitious smart system projects discussed above are being delivered as aprogram of managed life cycles synchronized against a top down understanding of enterprise needs. It is importantthat within these approaches we create the flexibility to allow for bottom-up solutions developed by combining open,interoperable system elements to emerge and be integrated into the evolving solutions.More recently, emerging technologies such as artificial intelligence, machine learning, deep learning, mechatronics,cyberphysical systems, cybersecurity, Internet of Things (IoT), additive manufacturing, digital thread, Factory 4.0,etc. are challenging approaches to SE.Many of the challenges above, and the SE response to them, increase the breadth and complexity of the systemsinformation being considered. This increases the need for up to date, authoritative and shared models to support lifecycle decisions. This has led to the development and ongoing evolution of model-based systems engineering(MBSE) approaches.

Future ChallengesThe INCOSE Systems Engineering Vision 2025 (INCOSE 2014) considers the issues discussed above and from thisgives an overview of the likely nature of the systems of the future. This forms the context in which SE will bepracticed and give a starting point for considering how SE will need to evolve:•• Future systems will need to respond to an ever growing and diverse spectrum of societal needs in order to create

value. Individual engineered system life cycles may still need to respond to an identified stakeholder need andcustomer time and cost constraint. However, they will also form part of a larger synchronized response tostrategic enterprise goals and/or societal challenges. System life cycles will need to be aligned with global trendsin industry, economy and society, which will, in turn, influence system needs and expectations.

•• Future systems will need to harness the ever growing body of technology innovations while protecting againstunintended consequences. Engineered system products and services need to become smarter, self-organized,sustainable, resource efficient, robust and safe in order to meet stakeholder demands.

•• These future systems will need to be engineered by an evolving, diverse workforce which, with increasinglycapable tools, can innovate and respond to competitive pressures.

These future challenges change the role of software and people in engineered systems. The Systems Engineering andSoftware Engineering knowledge area consider the increasing role of software in engineered systems and its impacton SE. In particular it considers the increasing importance of Cyber-Physical Systems in which technology, softwareand people play an equally important part in the engineered systems solutions. This requires a SE approach able tounderstand the impact of different types of technology, and especially the constraints and opportunities of softwareand human elements, in all aspects of life cycle of an engineered systems.All of the challenges, and the SE responses to them, make it even more important that SE continues its transition to amodel based discipline.The changes needed to meet these challenges will impact the life cycle processes described in Part 3: SystemsEngineering and Management and on the knowledge, skills and attitudes of systems engineers and the ways they areorganized to work with other disciplines as discussed in Part 5: Enabling Systems Engineering and Part 6: RelatedDisciplines. The different ways in which SE is applied to different types of system context, as described in Part 4:Applications of SE, will be a particular focus for further evolution to meet these challenges. The Introduction to SETransformation knowledge area in SEBoK Part 1 describes how SE is beginning to change to meet these challenges.

Systems Engineering: Historic and Future Challenges 33

References

Works CitedBertalanffy, L. von. 1968. General System Theory: Foundations, Development, Applications. New York, NY, USA:George Braziller.Checkland, P. 1981. Systems Thinking, Systems Practice. Hoboken, NJ, USA: Wiley, 1981.Churchman, C.W., R. Ackoff, and E. Arnoff. 1957. Introduction to Operations Research. New York, NY, USA:Wiley and Sons.International Council on Systems Engineering (INCOSE), 2014, Systems Engineering Vision 2025 July, 2014;Accessed February 16 at http:/ / www. incose. org/ docs/ default-source/ aboutse/ se-vision-2025. pdf?sfvrsn=4Ferguson, J. 2001. "Crouching Dragon, Hidden Software: Software in DoD Weapon Systems." IEEE Software,July/August, p. 105–107.Forrester, J. 1961. Industrial Dynamics. Winnipeg, Manitoba, Canada: Pegasus Communications.Goode, H. and R. Machol. 1957. Systems Engineering: An Introduction to the Design of Large-Scale Systems. NewYork, NY, USA: McGraw-Hill.McKean, R. 1958. Efficiency in Government Through Systems Analysis. New York, NY, USA: John Wiley and Sons.Mumford, L. 1961. The City in History. San Diego, CA, USA: Harcourt Brace Jovanovich.Rechtin, E. 1991. Systems Architecting. Upper Saddle River, NJ, USA: Prentice Hall.Rechtin, E. and M. Maier. 1997. The Art of Systems Architecting. Boca Raton, FL, USA: CRC Press.Taylor, F. 1911. The Principles of Scientific Management. New York, NY, USA and London, UK: Harper &Brothers.Vitruvius, P. (transl. Morgan, M.) 1960. The Ten Books on Architecture. North Chelmsford, MA, USA: CourierDover Publications.Warfield, J. 1956. Systems Engineering. Washington, DC, USA: US Department of Commerce (DoC).Wellington, A. 1887. The Economic Theory of the Location of Railroads. New York, NY, USA: John Wiley andSons.Wiener, N. 1948. Cybernetics or Control and Communication in the Animal and the Machine. New York, NY, USA:John Wiley & Sons Inc.Wymore, A. W. 1977. A Mathematical Theory of Systems Engineering: The Elements. Huntington, NY, USA:Robert E. Krieger.

Primary ReferencesBoehm, B. 2006. "Some Future Trends and Implications for Systems and Software Engineering Processes." SystemsEngineering. Wiley Periodicals, Inc. 9(1), pp 1-19.INCOSE Technical Operations. 2007. Systems Engineering Vision 2020, version 2.03. Seattle, WA: InternationalCouncil on Systems Engineering, Seattle, WA, INCOSE-TP-2004-004-02.International Council on Systems Engineering (INCOSE), 2014, Systems Engineering Vision 2025, July 2014;Accessed February 16 at http:/ / www. incose. org/ docs/ default-source/ aboutse/ se-vision-2025. pdf?sfvrsn=4Warfield, J. 1956. Systems Engineering. Washington, DC, USA: US Department of Commerce (DoC). ReportPB111801.Warfield, J. 1976. Societal Systems: Planning, Policy, and Complexity. New York, NY, USA: John Wiley & Sons.

Systems Engineering: Historic and Future Challenges 34

Wymore, A. W. 1977. A Mathematical Theory of Systems Engineering: The Elements. Huntington, NY, USA:Robert E. Krieger.

Additional ReferencesHitchins, D. 2007. Systems Engineering: A 21st Century Methodology. Chichester, England: Wiley.The MITRE Corporation. 2011. "The Evolution of Systems Engineering." in The MITRE Systems EngineeringGuide. Accessed 8 March 2012 at [1].Sage, A. and W. Rouse (eds). 1999. Handbook of Systems Engineering and Management. Hoboken, NJ, USA: JohnWiley and Sons, Inc.

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

References[1] http:/ / www. mitre. org/ work/ systems_engineering/ guide/ evolution_systems. html

Systems Engineering and Other DisciplinesAs discussed in the Scope of the SEBoK article, there are many touch points and overlaps between systemsengineering (SE) and other disciplines. Systems engineers should have a basic understanding of the nature of theseother disciplines, and often need to understand aspects of another discipline in detail. This article describes thelandscape of disciplines that are intertwined with SE. For a closer view of the individual disciplines, see Part 6.

Engineering Disciplines Other than Systems EngineeringEngineering disciplines are mostly component-oriented and value-neutral in their intellectual content (Boehm andJain 2006). Their underlying laws and equations, such as Ohm’s Law, Hooke’s Law, Newton’s Laws, Maxwell’sequations, the Navier-Stokes equations, Knuth’s compendia of sorting and searching algorithms, and Fitts’s Law ofhuman movement, pertain to performance in a system-of-interest. They do not address how that performancecontributes to the value propositions of stakeholders.In contrast, SE is more holistic than component-oriented, and more stakeholder value-oriented than value-neutral,performance-oriented in its intellectual content. Realizing successful systems requires reasoning with stakeholdersabout the relative value of alternative realizations, and about the organization of components and people into asystem that satisfies the often-conflicting value propositions of stakeholders. Stakeholders who are critical to thesystem’s success include funders, owners, users, operators, maintainers, manufacturers, and safety and pollutionregulators.In some disciplines, the engineer evaluates and integrates design elements into a system that satisfies proxies ofvalue. The wider the scope of the SoI, the broader the set of SE skills the engineer needs.For example, an aeronautical engineer might integrate mechanical, electrical, fluid, combustion-chemical, software,and cockpit design elements into a system that satisfies proxies of value like flight range, payload capacity, fuelconsumption, maneuverability, and cost of production and maintenance. In so doing, the engineer operates partly asa systems engineer. The SoI is the aircraft itself and the engineer applies aircraft-domain expertise.However, the same engineer could participate in the engineering of passenger services, airport configurations, baggage handling, and local surface transportation options. All of these contribute to the value propositions of success-critical stakeholders. The SoIs are wider, and the engineer needs broader SE knowledge, skills, and abilities

Systems Engineering and Other Disciplines 35

to operate as a systems engineer. The aircraft-domain expertise remains needed for effective engineering of the widersystems. As discussed in (Guest 1991), most good systems engineers are “T-shaped” people, with both a workingknowledge of wider-system considerations, and a deep expertise in a relevant domain, such as aeronautical,manufacturing, software, or human factors engineering.Engineering disciplines that are intertwined with SE include software engineering (SwE), human factors engineering,and industrial engineering. SwE and SE are not just allied disciplines, they are intimately intertwined (Boehm 1994).Most functionality of commercial and government systems is now implemented in software, and software plays aprominent or dominant role in differentiating competing systems in the marketplace. Software is usually prominentin modern systems architectures and is often the “glue” for integrating complex system components.The scope of SwE includes both software SE and software construction, but does not include hardware SE. Thusneither SwE nor SE is a subset of the other. See Figure 1 in Scope of the SEBoK. For a definition of the relationshipbetween the SEBoK and the Guide to the Software Engineering Body of Knowledge (SWEBOK), which is publishedby the Institute of Electrical and Electronics Engineers (IEEE) (Bourque and Fairley 2014.) see Systems Engineeringand Software Engineering.Human factors engineering, from micro-ergonomics to macro-ergonomics, is intertwined with SE (Booher 2003;Pew and Mavor 2007). See Human Systems Integration in Part 6.Industrial engineering overlaps significantly with SE in the industrial domain, but also includes manufacturing andother implementation activities outside of SE. See Systems Engineering and Industrial Engineering in Part 6.Finally, to field a successful system, a systems engineer may need to know one or more of the many specialty fieldsin engineering, e.g., security, safety, reliability, availability, and maintainability engineering. Most of these areconsidered professional disciplines in their own right and many have their own bodies of knowledge. Forexplanations of how these disciplines relate to SE, overviews of what most systems engineers need to know aboutthem, and references within their bodies of knowledge, see Systems Engineering and Specialty Engineering in Part 6.

Non-Engineering DisciplinesSE is intimately intertwined with two non-technical disciplines: technical management (TM), and procurement andacquisition (also known as acquisition and procurement). TM often falls within the purview of a systems engineer.Many SE textbooks, competency models, and university programs include material about TM. TM is a specializationof project management (PM). SE and PM have significant common content in TM, but neither is a subset of theother. See Figure 1 in the article Scope of the SEBoK. For a definition of the relationship between the SEBoK andthe Guide to the Project Management Body of Knowledge (PMBOK), which is published by the Project ManagementInstitute (PMI) (PMI 2013), see Systems Engineering and Project Management in Part 6.Procurement and acquisition practitioners draw upon SE to determine the scope and overall requirements of thesystem to be procured or acquired. They then prepare requests for proposals and statements of work, determineevaluation criteria, and design source selection processes. Once a leading source is selected, they decide uponcontracting options that encompass payments, reviews, audits, incentive fees, acceptance criteria, procedures, and thenature of deliverables. Finally, they monitor progress with respect to plans (including those for SE), and negotiateand execute changes and corrective actions. Many of these activities amount to specialty disciplines withinprocurement and acquisition. See the article Related Disciplines in Part 6.

Systems Engineering and Other Disciplines 36

References

Works CitedBoehm, B. W. "Integrating Software Engineering and Systems Engineering." The Journal of NCOSE Vol. 1 (No. 1):pp. 147-151. 1994Boehm, B. and A. Jain. 2006. "A Value-Based Theory of Systems Engineering." Proceedings, INCOSE IS 2006.Also available at: http:/ / sunset. usc. edu/ csse/ TECHRPTS/ 2006/ usccse2006-619/ usccse2006-619. pdf.Booher, H. 2003. Handbook of Human-Systems Integration. New York, NY, USA: John Wiley & Sons Inc.Bourque, P. and R.E. Fairley (eds.). 2014. Guide to the Software Engineering Body of Knowledge (SWEBOK). LosAlamitos, CA, USA: IEEE Computer Society. Available at: http:/ / www. swebok. orgGuest, D. 1991. "The hunt is on for the Renaissance Man of computing." The Independent. London, England:September 17, 1991.INCOSE. 2011. Systems Engineering Handbook, version 3.2.1. San Diego, CA, USA: International Council onSystems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.Pew, R. and A. Mavor. 2007. Human-System Integration in the System Development Process. Washington, DC,USA: The National Academies Press.PMI. 2013. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th ed. Newtown Square,PA, USA: Project Management Institute (PMI).

Primary ReferencesBooher, H. 2003. Handbook of Human-Systems Integration. New York, NY, USA: John Wiley & Sons Inc.Bourque, P. and R.E. Fairley (eds.). 2014. Guide to the Software Engineering Body of Knowledge (SWEBOK). LosAlamitos, CA, USA: IEEE Computer Society. Available at: http:/ / www. swebok. orgGallagher, B., M. Phillips, K. Richter, and S. Shrum. 2011. CMMI For Acquisition: Guidelines for Improving theAcquisition of Products and Services, second ed. Upper Saddle River, NJ, USA: Addison Wesley.Paulk, M., C. Weber, B. Curtis, and M. Chrissis. 1995. The Capability Maturity Model: Guidelines for Improving theSoftware Process. Upper Saddle River, NJ, USA: Addison Wesley.Pyster, A. (ed.). 2009. Graduate Software Engineering 2009 (GSwE2009): Curriculum Guidelines for GraduateDegree Programs in Software Engineering. Integrated Software & Systems Engineering Curriculum Project.Hoboken, NJ, USA: Stevens Institute of Technology, September 30, 2009.Pew, R. and A. Mavor. 2007. Human-System Integration in the System Development Process. Washington, DC,USA: The National Academies Press.PMI. 2013. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th ed. Newtown Square,PA, USA: Project Management Institute (PMI).

Additional ReferencesNone.

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

37

Knowledge Area: Introduction to SystemsEngineering Transformation

Introduction to SE TransformationWhile the primary focus of the SEBoK is on the current practice of domain independent systems engineering, it isalso concerned with the future evolution of the discipline.The topics in this Knowledge Area (KA) summarize SE knowledge which is emerging and transitioning to becomepart of the practice of systems engineering, such as Model-Based Systems Engineering (MBSE). In general topicswill be introduced here and then expanded into other SEBoK KA's over time.The knowledge covered in this KA reflects the transformation and continued evolution of SE. For a summary of thecurrent and future challenges that contribute to this evolution, see Systems Engineering: Historic and FutureChallenges. This notion of SE transformation and the other areas of knowledge which it includes are discussedbriefly below.

TopicsEach part of the SEBoK is divided into Knowledge Areas (KA), which are groupings of information with a relatedtheme. The KAs in turn are divided into topics. This KA contains the following topics:•• Transitioning Systems Engineering to a Model-based Discipline•• Systems Engineering Core Concepts

Systems Engineering TransformationThe INCOSE Systems Engineering Vision 2025 (INCOSE 2014) describes the global context for SE, the currentstate of SE practice and the possible future state of SE. It describes number of ways in which SE continues to evolveto meet modern system challenges. These are summarized briefly below.Systems engineering has evolved from a combination of practices used in a number of related industries (inparticular aerospace and defense). These have been used as the basis for a standardized approach to the life cycle ofany complex system, see Systems Engineering and Management. Hence, SE practices are still largely based onheuristics. Efforts are under-way to evolve a theoretical foundation for systems engineering, see Foundations ofSystems Engineering, considering foundational knowledge from a variety sources.Systems engineering continues to evolve in response to a long history of increasing system complexity. Much of thisevolution is in the models and tools focused on specific aspects of SE, such as understanding stakeholder needs,representing system architectures or modeling specific system properties. The integration across disciplines, phasesof development, and projects continues to represent a key systems engineering challenge.Systems engineering is gaining recognition across industries, academia and governments. However, SE practicevaries across industries, organizations, and system types. Cross fertilization of systems engineering practices acrossindustries has begun slowly but surely; however, the global need for systems capabilities has outpaced the progressin systems engineering.INCOSE Vision 2025 concludes that SE is poised to play a major role in some of the global challenges of the 21st century; that it has already begun to change to meet these challenges and that it needs to undergo a more significant transformation to fully meet these challenges. The following bullet points are taken from the summary section of

Introduction to SE Transformation 38

Vision 2025 and define the attributes of a transformed SE discipline in the future:• Relevant to a broad range of application domains, well beyond its traditional roots in aerospace and defense, to

meet society’s growing quest for sustainable system solutions to providing fundamental needs, in the globallycompetitive environment.

•• Applied more widely to assessments of socio-physical systems in support of policy decisions and other forms ofremediation.

• Comprehensively integrating multiple market, social and environmental stakeholder demands against“end-to-end” life-cycle considerations and long-term risks.

•• A key integrating role to support collaboration that spans diverse organizational and regional boundaries, and abroad range of disciplines.

•• Supported by a more encompassing foundation of theory and sophisticated model-based methods and toolsallowing a better understanding of increasingly complex systems and decisions in the face of uncertainty.

•• Enhanced by an educational infrastructure that stresses systems thinking and systems analysis at all learningphases.

•• Practised by a growing cadre of professionals who possess not only technical acumen in their domain ofapplication, but who also have mastery of the next generation of tools and methods necessary for the systems andintegration challenges of the times.

Some of these future directions of SE are covered in the SEBoK. Other need to be introduced and fully integratedinto the SE knowledge areas as they evolve. This KA will be used to provide an overview of these transformingaspects of SE as they emerge. This transformational knowledge will be integrated into all aspects of the SEBoK as itmatures.

References

Works CitedInternational Council on Systems Engineering (INCOSE), 2014, Systems Engineering Vision 2025, July, 2014;Accessed February 16 at http:/ / www. incose. org/ docs/ default-source/ aboutse/ se-vision-2025. pdf?sfvrsn=4

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

Transitioning Systems Engineering to a Model-based Discipline 39

Transitioning Systems Engineering to aModel-based DisciplineSystems engineers have always leveraged many kinds of models, including functional models to supportrequirements development, simulation models to analyze the behavior of systems, and other analytical models toanalyze various aspects of the system such as reliability, safety, mass properties, power consumption, and cost.However, the discipline still relies heavily on document-based artifacts to capture much of the system specificationand design information, such as requirements, interface control documentation, and system architecture designdescriptions. This information is often spread across many different documents including text, informal drawings,and spreadsheets. This document-based approach to systems engineering suffers from a lack of precision,inconsistencies from one artifact to another, and difficulties in maintaining and reusing the information.

Model-based systems engineeringModel-based systems engineering (MBSE) is the formalized application of modeling to support systemrequirements, design, analysis, verification, and validation activities beginning in the conceptual design phase andcontinuing through development and later life cycle phases (INCOSE 2007). A distinguishing characteristic of aMBSE approach is that the model constitutes a primary artifact of the systems engineering process. The focus ondeveloping, managing and controlling a model of the system is a shift from the traditional document based approachto systems engineering, where the emphasis is on producing and controlling documentation about the system. Byleveraging the system model as a primary artifact, MBSE offers the potential to enhance product quality, enhancereuse of the system modeling artifacts, and improve communications among the systems development team. This, inturn, offers the potential to reduce the time and cost to integrate and test the system, and significantly reduce cost,schedule, and risks in fielding a system.MBSE includes a diverse set of descriptive and analytical models that can be applied throughout the life cycle, andfrom system of systems (SoS) modeling down to component modeling. Typical models may include descriptivemodels of the system architecture that are used to specify and design the system, and analytical models to analyzesystem performance, physical, and other quality characteristics such as reliability, maintainability, safety, and cost.MBSE has been evolving for many years. The term MBSE was used by Wayne Wymore in his book by this name(Wymore 1993), that provided a state-based formalism for analyzing systems in terms of their input/outputcharacteristics, and value functions for assessing utility of technology independent and technology dependentsystems. Simulations have been extensively used across Industry to provide high fidelity performance analysis ofcomplex systems. The Standard for Integration Definition for Function Modeling (IDEF0 1993) was introduced inthe 1990’s to support basic functional modeling. A modeling formalism called the enhanced functional flow blockdiagram (Long 2000) has been used to model many different types of systems. The Object Management Group(OMG) introduced the concept of a Model Driven Architecture (MDA®) (OMG 2003) that leverages astandards-based approach to modeling. The Systems Modeling Language (OMG SysML™) (OMG 2015) wasadopted by the OMG in 2006 as a general purpose systems modeling language. In addition, the Unified Profile forDoDAF and MODAF (UPDM) (OMG 2013) was adopted by the OMG in 2008 to support enterprise modeling.Several other domain specific modeling languages have been introduced as well.

Transitioning Systems Engineering to a Model-based Discipline 40

MBSE TransitionThe INCOSE Systems Engineering Vision 2025 (INCOSE 2014, pg 38) describes the current state of MBSE asfollows: 'Model-based systems engineering has grown in popularity as a way to deal with the limitations ofdocument-based approaches, but is still in an early stage of maturity similar to the early days of CAD/CAE.'SE Vision 2025 also describes a continuing transition of SE to a model-based discipline in which: 'Formal systemsmodeling is standard practice for specifying, analyzing, designing, and verifying systems, and is fully integrated withother engineering models. System models are adapted to the application domain, and include a broad spectrum ofmodels for representing all aspects of systems. The use of internet driven knowledge representation and immersivetechnologies enable highly efficient and shared human understanding of systems in a virtual environment that spanthe full life cycle from concept through development, manufacturing, operations, and support.'The transition to a more model-based discipline is not without its challenges. This requires both advancements in thepractice, and the need to achieve more widespread adoption of MBSE within organizations across industry sectors.Advancing the practice requires improvements in the modeling languages, methods, and tools. The modelinglanguages must continue to improve in terms of their expressiveness, precision, and usability. MBSE methods, suchas those highlighted in A Survey of Model-Based Systems Engineering (MBSE) Methodologies (Estefan 2008), havecontinued to evolve, but require further advancements to provide a rigorous approach to modeling a system acrossthe full system lifecycle, while being more adaptable to a diverse range of application domains. The modeling toolsmust also continue to evolve to support the modeling languages and methods, and to integrate with othermulti-disciplinary engineering models and tools in support of the broader model-based engineering effort. Themovement towards increased use of modeling standards, that are more widely available in commercial tools, andrigorous model-based methodologies, increase the promise of MBSE.Many organizations are adopting aspects of MBSE to improve their systems engineering practice, particularly sinceMBSE was introduced in the INCOSE Systems Engineering Vision 2020 in 2007. However, as indicated in the SEVision 2025, MBSE is still being applied in pockets within organizations and unevenly across industry sectors.Similar to the evolution of model-based approaches in other disciplines such as mechanical and electricalengineering, the transition occurs incrementally as the methods and tools mature.The adoption of MBSE requires a workforce that is skilled in the application of MBSE. This requires organizationsto provide an infrastructure that includes MBSE methods, tools, and training, and a commitment to deploy thiscapability to their programs As with any organizational change, this must be approached strategically to grow thiscapability and learn from their experiences.Like other engineering disciplines, the transition of systems engineering to a model-based discipline is broadlyrecognized as essential to meet the challenges associated with increasing system complexity, and achieving theproductivity and quality improvements. The SEBoK will continue to reflect the growing body of knowledge tofacilitate this transition.

Transitioning Systems Engineering to a Model-based Discipline 41

References

Works CitedEstefan, 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 athttp:/ / www. omgsysml. org/MBSE_Methodology_Survey_RevB. pdfINCOSE Technical Operations. 2007. Systems Engineering Vision 2020, version 2.03. Seattle, WA: InternationalCouncil on Systems Engineering, Seattle, WA, INCOSE-TP-2004-004-02.International Council on Systems Engineering (INCOSE), 2014,Systems Engineering Vision 2025July, 2014;Accessed February 16 at http:/ / www. incose. org/ docs/ default-source/ aboutse/ se-vision-2025. pdf?sfvrsn=4Long , James E., 2000,Systems Engineering (SE) 101, CORE ®: Product & Process Engineering Solutions , Vitechtraining materials,Vitech Corporation , Vienna, VA.Object Management Group (OMG), 2003, Model-Driven Architecture (MDA) Guide, v1.01, June 12 2003, availableat http:/ / www. omg. org/ mda/ .Object Management Group (OMG), 2015, OMG Systems Modeling Language (OMG SysML™), V1.4, OMGdocument number formal/2015-06-03, September 2015; http:/ / www. omg. org/ spec/ SysML/ 1. 4/Object Management Group (OMG), 2013, Unified Profile for DoDAF/MODAF (UPDM) OMG document numberformal/2013-08-04, August 2013, http:/ / www. omg. org/ spec/ UPDM/ 2. 1/Standard for Integration Definition for Function Modeling(IDEF0), 1993, Draft Federal Information ProcessingStandards, Publication 183, December 21, 1993.Wymore, W.,Model-Based Systems Engineering. Boca Raton, FL: CRC Press , 1993

Primary ReferencesINCOSE. 2015. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities [1], Section9.2 Model-Based Systems Engineering, version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN:978-1-118-99940-0

Additional ReferencesMBSE Wikipedia. Accessed February 16, 2015, http:/ / www. omgwiki. org/ MBSE/ doku. php

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

References[1] http:/ / sebokwiki. org/ draft/ INCOSE_Systems_Engineering_Handbook

Digital Engineering 42

Digital Engineering

Lead Author: Ron Giachetti

The US Under Secretary of Defense for Research and Development released the US Department of Defense (DoD)Digital Engineering Strategy in June 2018 describing five goals to streamline the DoD acquisition process throughthe creation of a digital thread enabling the conception, design, and development of complex weapon systems (DoD2018; Zimmerman 2017). The crux of digital engineering is the creation of computer readable models to represent allaspects of the system and to support all the activities for the design, development, manufacture, and operation of thesystem throughout its lifecycle. These computer models would have to be based on shared data schemata so that ineffect a digital thread integrates all the diverse stakeholders involved in the acquisition of new weapon systems. TheDigital Engineering Strategy anticipates digital engineering will lead to greater efficiency and improved quality of allthe acquisition activities.

Relationship with MBSEModel-based systems engineering (MBSE) is a subset of digital engineering. MBSE supports the systemsengineering activities of requirements, architecture, design, verification, and validation. These models would have tobe connected to the physics-based models used by other engineering disciplines such as mechanical and electricalengineering. One challenge remaining for digital engineering is the integration of MBSE with physics-based models.Foundation to digital engineering is the representation of the system data in a format sharable between allstakeholders (Giachetti et al. 2015; Vaneman 2018). SysML 2.0 is one of several future developments promising toprovide a representation sufficient to support digital engineering. An ontology defining the entities and relationshipsbetween them can be used to define the concepts relevant to systems engineering. Such a representation is necessaryto create the digital thread linking all the models together in a cohesive and useful manner.

Digital Engineering as a TransformationFor many organizations digital engineering represents a transformation of how they normally conduct systemsengineering (e.g., see Bone et al. 2018). The reason is most organizations conduct a document-intensive systemsengineering process. The adoption of digital engineering requires concomitant changes to how organizations performsystem engineering activities. Everything from documenting requirements, technical reviews, architecture design,and so forth would be based on the models in a digital engineering environment (Vaneman and Carlson, 2019). Thedigital thread would be the authoritative source of truth concerning the system data.

Digital TwinA digital twin is a related yet distinct concept to digital engineering. The digital twin is a high-fidelity model of thesystem, which can be used to emulate the actual system. An organization would be able to use a digital twin toanalyze design changes prior to incorporating them into the actual system.

References

Works CitedBone, M.A., M.R. Blackburn, D.H. Rhodes, D.N. Cohen, and J.A. Guerrero. 2018 "Transforming systemsengineering through digital engineering." The Journal of Defense Modeling and Simulation (2018):1548512917751873.

Digital Engineering 43

DoD. 2018. DoD Digital Engineering Strategy. Office of the Undersecretary of Defense for Research andEngineering (OUSD R&E), US Department of Defense. June 2018.Giachetti, R.E. 2015. "Evaluation of the DoDAF Meta-model's Support of Systems Engineering." ProcediaComputer Science 61 (2015): 254-260.Vaneman, W.K. 2018. "Evolving Model‐Based Systems Engineering Ontologies and Structures." Proceedings of theInternational Council on Systems Engineering (INCOSE) International Symposium, 7-12 July 2018, WashingtonDC. Symposium Proceedings vol. 28, no. 1, pp. 1027-1036.Zimmerman, P. "DoD Digital Engineering Strategy." Proceedings of the 20th Annual National Defense IndustrialAssociation (NDIA) Systems Engineering Conference, 23-26 October 2017, Springfield, VA.

Primary ReferencesBone, M.A., M.R. Blackburn, D.H. Rhodes, D.N. Cohen, and J.A. Guerrero. 2018 "Transforming systemsengineering through digital engineering." The Journal of Defense Modeling and Simulation (2018):1548512917751873.Singh, V. and K.E. Willcox. "Engineering Design with Digital Thread." AIAA Journal 56(11) (2018): 4515-4528.Zimmerman, P. "DoD Digital Engineering Strategy." Proceedings of the 20th Annual National Defense IndustrialAssociation (NDIA) Systems Engineering Conference, 23-26 October 2017, Springfield, VA.OUSD R&E,DoDDigital Engineering Strategy, (June 2018).

Additional ReferencesNone.

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

Set-Based Design 44

Set-Based Design

Lead Authors: Eric Specking, Gregory S. Parnell, and Ed Pohl

Set-based design (SBD) is a complex design method that enables robust system design by 1) considering a largenumber of alternatives, 2) establishing feasibility before making decisions, and 3) using experts who design fromtheir own perspectives and use the intersection between their individual sets to optimize a design (Singer, Doerry,and Buckley 2009). Model-based engineering (MBE)/model-based system engineering (MBSE) with an integratedframework can enable the use of SBD tradespace exploration, and for some situations (i.e. early-design stage withlow fidelity models), in near-real time (Specking et al. 2018a). This article provides insights on using model-baseddesign to create and assess alternatives with set-based design.

IntroductionSBD analyzes sets of alternatives instead of single solutions. Sets are “two or more design points that have at leastone design option in common” (Specking et al. 2018b) or “the range of options for a design factor” (Singer et al.2017). A design factor is a “solution parameter, characteristics, or relationship that influences the design at thesystem level.” (Singer et al. 2017) Systems engineers should develop sets determining the design factors andseparating the design factors into set drivers or set modifiers. Set drivers are “fundamental design decisions thatdefine the system characteristics that enable current and future missions”, while set modifiers are “design decisionsthat are ‘added on’ to the system and can be modified to adapt for new missions and scenarios” (Specking et al.2018b).SBD is not the best design method for every situation. SBD is particularly useful in early-stage design and if theproject contains the following attributes:•• A large number of design variables,•• Tight coupling among design variables,•• Conflicting requirements,•• Flexibility in requirements allowing for trades, or• Technologies and design problems not well understood – learning required for a solution (Singer et al. 2017)In early-stage design, SBD helps inform requirements analysis and assess design decisions. (Parnell et al. 2019)Quantitative SBD requires an integrated, MBE environment to assess the effects of constraining and relaxingrequirements on the feasible tradespace. For example, Figure 2 demonstrates the effects of constraining or relaxingrequirements of an unmanned aerial vehicle case study with all of the explored designs in orange, the tradespaceeffected by non-requirement constraints (e.g. physics with requirements relaxed to not affect the tradespace) in blue,the original UAV feasible tradespace in yellow, and the relaxed (black)/constrained (red) tradespaces.

Set-Based Design 45

Figure 1. Effects of Requirements on the UAV's Feasible Tradespace (Parnell et al. 2019, used with permission)

The tornado diagram, seen in Figure 3 shows results of a one requirement at a time analysis. This makes it easy tosee how the constraining/relaxing each individual requirement effects the feasible tradespace. Figure 3 shows thatthe requirements “Detect Human Activity at Night” and “Detect Human Activity in Daylight” have the greatestimpact on the feasible tradespace.

Figure 2. UAV Case Study Results of One-by-One Requirement Analysis (Parnell et al. 2019, used with permission)

Changing the requirements does not always translate to finding improved designs. The individual one requirement ata time analysis scatterplot provides important information, as seen in an example illustration in Figure 4. It isimportant to carefully analyze the Pareto Frontier created by each change (represented by a different color) andcompare it the Pareto Frontier of the original analysis. If the original requirement level produces better alternatives,

Set-Based Design 46

then it does not make sense to change (constrain or relax) the requirement.

Figure 3. Effect on Feasible Tradespace by Changing Most Sensitive UAV Requirement (Specking et al. 2019, used with permission)

Additionally, using SBD can add value to the overall project and team. Some of the advantages include:•• enables reliable, efficient communications,•• allows much greater parallelism in the process, with much more effective use of subteams early in the process,•• allows the most critical, early decisions to be based on data, and•• promotes institutional learning. (Ward et al. 1995)

System Analyst Set-Based Design Tradespace Exploration ProcessFigure 4 illustrates SBD as a concept for system design and analysis. This SBD illustration contains 5 distinctcharacteristics:1.1. start by determining the business/mission needs and system requirements;2. use the business/mission needs and system requirements to perform design and analysis techniques throughout

time in the exploratory, concept, and development stages of the system’s life cycle;3.3. perform design and analysis concurrently as much as possible;4.4. inform requirement analysis by using feasibility, performance, and cost data; and5.5. consider a large number of alternatives through the use of sets and slowly converge to a single point solution.

(Specking et al. 2019)

Set-Based Design 47

Figure 4. SBD Conceptual Framework for Systems Design (Specking et al. 2019, used with permission)

SBD is a social-technical process and should involve input and interactions from several teams, but Figure 6provides a SBD tradespace exploration process for system analysts. (Specking et al. 2019) This process is especiallyuseful to perform early-stage design and is an eight step process (Specking et al. 2018b). The system analyst starts byanalyzing the business/mission needs and system requirements. Systems engineers use this information, along withmodels and simulations developed by themselves or provided by systems and subsystem teams, to develop anintegrated model. Systems engineers include requirements to assess feasible and infeasible alternatives using thisintegrated model. They explore the tradespace by treating each design decision as a uniform (discrete or continuous)random variable. An alternative consists of an option from every design decision. Systems engineers then use theintegrated model to evaluate each alternative and to create the feasible tradespace. Monte Carlo simulation is onemethod that enables a timely alternative creation and evaluation process. The created tradespace will consist ofinfeasible and feasible alternatives based upon the requirements and any physics based performance models andsimulations. Systems engineers should work with the appropriate stakeholders to inform requirements when thetradespace produces a significantly small number of or no feasible alternatives. In addition to feasibility, systemsengineers should also analyze each design decision by using descriptive statistics and other analyses and dataanalytics techniques. This information provides insights into how each design factor influences the feasibletradespace. Once the tradespace contains an acceptable number of alternatives, it is then classified by sets. This is anessential part of SBD. If the set drivers or design factors are not known, system engineers should view the tradespaceby each design decision for insights. Systems engineers should use dominance analysis and other optimizationmethods to find optimal or near optimal alternatives based upon the measures of effectiveness. Systems engineersshould explore the remaining sets for additional insights on the feasible tradespace and the requirements. The finalpart of this process is to select one or more sets to move to the next design-stage. It should be noted that this processcontains cycles. At any part of this process, systems engineers should use the available information, such as fromtradespace exploration or set evaluation, to inform requirement analysis or update the integrated model. Additionally,the systems engineer should update the integrated model with higher fidelity models and simulations as they becomeavailable. The key is to have the “right” information from the “right” people at the “right” time.

Set-Based Design 48

Figure 5. System Analysts SBD Tradespace Exploration Process(Specking et al. 2019, used with permission)

References

Works CitedParnell, G.S., E. Specking, S. Goerger, M. Cilli, and E. Pohl. 2019. “Using Set-Based Design to Inform SystemRequirements and Evaluate Design Decisions.” Proceedings of the 29th Annual International Council on SystemsEngineering (INCOSE) International Symposium, 20-25 July 2019, Orlando, FL.Singer, D.J., N. Doerry, and M. E. Buckley. 2009. “What Is Set-Based Design?” Naval Engineers Journal. 121(4):31–43.Singer, D., J. Strickland, N. Doerry, T. McKenney, and C. Whitcomb. 2017. “Set-Based Design.” SNAME T&RBulletin SNAME (mt) Marine Technology Technical and Research Bulletin.

Specking, E., C. Whitcomb, G. Parnell, S. Goerger, E. Kundeti, and N. Pohl. 2018a. “Literature Review: Exploringthe Role of Set-Based Design in Trade-off Analytics.” Naval Engineers Journal. 130 (2): 51-62.Specking, E., G. Parnell, E. Pohl, and R. Buchanan. 2018b. “Early Design Space Exploration with Model-BasedSystem Engineering and Set-Based Design.” IEEE Systems. 6(4): 45.Specking, E., G. Parnell, S. Goerger, M. Cilli, and E. Pohl. 2019. "Using Set-Based Design to Inform SystemRequirements and Evaluate Design Decisions." Proceedings of the 29th Annual International Council on SystemsEngineering (INCOSE) International Symposium, 20-25 July 2019, Orlando, FL.Ward, A., I. Durward Sobek, J. C. John, and K. L. Jeffrey. 1995. “Toyota, concurrent engineering, and set-baseddesign.” in Engineered in Japan: Japanese Technology-management Practices. Oxford, England: Oxford UniversityPress. pp. 192–216.

Set-Based Design 49

Primary ReferencesNone.

Additional ReferencesNone.

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

Model-Based Systems Engineering AdoptionTrends 2009-2018

Lead Author: Rob Cloutier

The MBSE Initiative was kicked off at the INCOSE International Workshop (IW) in 2007 at the Albuquerque, NM,USA Embassy Suites. There was approximately 45 INCOSE members for this first meeting, held the two dayspreceding IW.Surveys were conducted in 2009, 2012, 2014, and 2018, and 2019 to better understand the adoption trends ofmodel-based systems engineering.

IntroductionModel-based systems engineering (MBSE) is not a new concept. Wymore (1993) published the seminal work on thetopic. This book presents the mathematical theory behind MBSE. Since that time, engineering has made significantmovement from text-based approaches using office-based tools (e.g. Harvard Graphics, Microsoft PowerPoint,Microsoft Visio, etc.) to an interconnected set of graphical diagrams. These diagrams are generally created in a toolwith a specialized graphical user interface.Today aerospace engineers no longer use drafting boards to create their drawings – they use computer aided design(CAD) tools. Likewise, software engineers seldom use EMACS or Vi (text editors), instead, they use software GUIsthat allow them to code, check syntax, compile, link, and run their software all in a single environment.Broadly speaking, a {{TermModel_(glossary) can be thought of as a facsimile or abstraction of reality. To this end,even a requirements document can be considered a model – it represents what a real system should do in performingits mission or role. While systems engineering has used models for a very long time, MBSE is the systemsengineering migration to computer-based graphical user interfaces to perform our analysis and design tasks just asour other engineering brethren have moved to computer-based graphical user interfaces.A discussion of available tools is beyond the scope of this article, and not the practice of the SEBoK to review orpromote specific tool offerings. However, it is fair to state that current MBSE tools fall into three broad categories:1) Functional decomposition tools that use IDEF0 (also called IPO) diagrams, N2 diagrams, functional flow blockdiagrams, etc., 2) Object-oriented tools that implement the Object Management Group’s Systems ModelingLanguage (SysML), and 3) Mathematical modeling tools.This migration for systems engineering might have begun in the late 90’s. The INCOSE INSIGHT publication proclaimed that MBSE was a new paradigm (INSIGHT 1998). Cloutier (2004) addressed the migration from a waterfall systems engineering approach to an object-oriented approach on the Navy Open Architecture project. At that time, SysML did not exist, and the teams were using the Unified Modeling Language (UML) that was predominately a software modeling tool. Zdanis & Cloutier (2007a, 2007b) addressed the use of activity diagrams

Model-Based Systems Engineering Adoption Trends 2009-2018 50

instead of sequence diagrams for systems engineering based on the newly released SysML. In 2009, the INCOSEINSIGHT publication proclaimed MBSE was THE new paradigm (INSIGHT 2009).

ApproachIn 2009 a survey was commissioned by the Object Management Group (OMG) with the intent of informing theSysML Working Group on necessary changes to SysML since its first release [Cloutier & Bone 2010). That surveyfocused on process more than adoption. Beginning in 2012, INCOSE has commissioned three more surveys tounderstand adoption trends and obstacles. The survey instrument remained relatively unchanged for 2012, 2014, and2018 (Cloutier 2015, Cloutier 2019a). In January of 2019, the Jet Propulsion Lab (JPL) conducted an MBSEWorkshop (Cloutier 2019b). A survey of those participants was conducted, and the intent of the questions was toaugment knowledge gained from the 2018 survey. The table below shows the number of respondents in each of thesurveys.

Table 1. MBSE Survey Purposes and Responses (SEBoK Original)

Year Survey Purpose Responses

2012 INCOSE MBSE Initiative 134

2014 INCOSE MBSE Initiative 205

2018 INCOSE MBSE Initiative 661

2019 JPL MBSE Workshop 98

Responses and Response DemographicsEach survey was sent to a diverse group of MBSE practitioners. Table 2 shows that of the 661 responses for the 2018survey, 410 indicated their country of origin. This international representation is similar to all surveys conducted.

Table 1. MBSE Survey Purposes and Responses (Cloutier 2019, used with permission)

Country Responses Country Responses

USA 197 Israel 4

United Kingdom 52 Singapore 3

France 30 China 2

Germany 28 New Zealand 2

Australia 20 Poland 2

Netherlands 19 Russia 1

Japan 8 Romania 1

Canada 6 Turkey 1

Italy 6 Columbia 1

Sweden 6 Norway 1

South Africa 5 South Korea 1

Switzerland 4 UAE 1

Brazil 4 Belarus 1

India 4

Model-Based Systems Engineering Adoption Trends 2009-2018 51

As part of the demographics, Figure 1 shows the represented industries. Because the “Other” category was so large,the data was analyzed to better understand Figure 2.

Figure 1. Industries Represented in the 2018 MBSE Survey. (Cloutier 2019a, used with permission)

Figure 2. "Other" Industries Represented in the 2018 MBSE Survey. (Cloutier 2019a, used with permission)

The 2018 survey indicated that there seems to be an increased application of MBSE in traditionally civil engineeringindustries – specifically energy, infrastructure, and transportation (Figure 2) One of the most interesting aspects ofthe 2018 survey is the finding that MBSE is being applied in the early phases of systems engineering, and less so inthe later phases as shown in Figure 3.

Model-Based Systems Engineering Adoption Trends 2009-2018 52

Figure 3. MBSE is More Likely to be Used in Early Stages of Systems Engineering (Cloutier 2019a, used with permission)

This was confirmed by the JPL question “Where do we believe MBSE holds the most promise?” Figure 4 shows that76% of the responses indicated System/subsystem architecting, 42% thought requirements analysis, and 39%believed early conceptualization (note: the question allowed for multiple answers).

Figure 4. JPL Workshop Response Regarding "Where MBSE Holds the Most Promise" (Coutier 2019b, used withpermission)

Model-Based Systems Engineering Adoption Trends 2009-2018 53

Figure 5. JPL Workshop Response Regarding "Is Your Modeling Experience Valued by Management?" (Coutier 2019b,used with permission)

When asked whether the JPL survey respondents believed that their systems modeling experience is recognized as avalued skill supporting career growth of systems engineers in my organization, just over 50% believed managementvalued their experience. A smaller number, 21%, believed their modeling experience was not valued (Figure 5).

Key Adoption TrendsThe remainder of this article is going to look at some of the trends identified across the surveys, from 2009 to 2018.Figure 6 shows that MBSE is moving from a defense and space dominated practice into other industries as discussedin Figure 4.

Figure 6. Shift of MBSE Adoption in New Industries (Cloutier 2019a, used with permission)

Model-Based Systems Engineering Adoption Trends 2009-2018 54

Model-based systems engineering seems to be expanding in influence in that it is not just in the purview of thesystems engineers. While systems and software engineers find value in MBSE practices, Figure 6 demonstrates thatthe customer is finding value in MBSE practices. It is also interesting that software engineers perceived value ofMBSE is declining from survey to survey.

Figure 7. Perceived Value of MBSE Practices to Different Project Segments (Cloutier 2019a, used with permission)

Model-Based Systems Engineering Adoption Trends 2009-2018 55

Figure 8. Inhibitors to the Successful Adoption of MBSE within an Organization/Company (Cloutier 2019a, used with permission)

Figure 8 demonstrates that availability of MBSE skills, cultural and general resistance to change have continued toincrease. Lack of perceived value reflects the findings in Figure 6 – software and hardware engineers are not seeingthe value of MBSE.

ConclusionsSurveys conducted between 2012 and 2018 demonstrate that MBSE practices are spreading beyond traditionalDefense and Space domains. Most MBSE practitioners are finding MBSE is most useful in the early project phasesof conceptualization, requirements analysis, and systems architecting. There continues to be a skills shortage, yetcompanies/organizations are providing less training to improve MBSE skills. Both systems engineers, systemsengineering management, and the systems engineering customer are finding value to using models to performsystems engineering.

References

Works CitedCloutier, R. 2004. "Migrating from a Waterfall Systems Engineering Approach to an Object Oriented Approach –Lessons Learned." ICSE and INCOSE Region II Conference, 15 September 2004, Las Vegas, NV.Cloutier, R. and M. Bone. 2010. "Compilation of SysML RFI- Final Report: Systems Modeling Language (SysML)Request For Information." OMG Document: syseng/2009-06-01. Report date: 02/20/2010. Retrieved from http:/ /www. omgwiki. org/ OMGSysML/ lib/ exe/ fetch. php?media=sysml-roadmap:omg_rfi_final_report_02_20_2010-1.pdf on 10/24/2019Cloutier, R. 2015. "Current Modeling Trends in Systems Engineering." INSIGHT, A Publication of the InternationalCouncil on Systems Engineering (INCOSE). Volume 18, Issue 2.

Model-Based Systems Engineering Adoption Trends 2009-2018 56

Cloutier, R. 2019a. "2018 MBSE Survey Results." Proceedings of the 2019 INCOSE MBSE Workshop, presented atthe INCOSE 2019 International Workshop, 26-29 January 2019, Torrance, CA.Cloutier, R. 2019b. "2019 JPL MBSE Survey Results." Presented at the 2019 Jet Propulsion Lab (JPL) MBSEWorkshop, January 2019, Pasadena, CA.INSIGHT. 1998. Model-Based Systems Engineering: A New Paradigm. A Publication of the International Councilon Systems Engineering (INCOSE). Volume 1, Issue 3.INSIGHT. 2009. Special Edition on Model-based Systems Engineering: The New Paradigm. A Publication of theInternational Council on Systems Engineering (INCOSE). Volume 12, Issue 4.Wymore, W. 1993. Model-Based Systems Engineering. Boca Raton, FL: CRC Press.Zdanis, L. and R. Cloutier. 2007. "The Use of Behavioral Diagrams in SysML." Hoboken, NJ: Stevens Institute ofTechnology. Proceedings of the Conference on Systems Engineering Research (CSER) 2007, 14-16 March 2007,Hoboken, NJ, USA. ISBN 0-9787122-1-8.Zdanis, L. and R. Cloutier. 2007. "The Use of Behavioral Diagrams in SysML." IEEE Long Island Systems,Applications and Technology Conference, Farmingdale, NY, 2007, pp. 1-1. doi: 10.1109/LISAT.2007.4312634

Primary ReferencesBone, M. and R. Cloutier. 2010. "The Current State of Model Based Systems Engineering: Results from the OMG™SysML Request for Information 2009." Proceedings of the 8th Conference on Systems Engineering Research(CSER), 17-19 March 2010, Hoboken, NJ. http:/ / www. omgsysml. org/ news-articles. htmCloutier, R. and M. Bone. 2012. "MBSE Survey 2." Presented at the International Council on Systems Engineering(INCOSE) International Workshop, 21-24 January 2012, Jacksonville, FL.Cloutier, R. 2019a. "2018 MBSE Survey Results." Proceedings of the 2019 INCOSE MBSE Workshop, presented atthe INCOSE 2019 International Workshop, 26-29 January 2019, Torrance, CA.Cloutier, R. 2019b. "2019 JPL MBSE Survey Results." Presented at the 2019 Jet Propulsion Lab (JPL) MBSEWorkshop, January 2019, Pasadena, CA.

Additional ReferencesBatarseh, O., L. McGinnis, J. Lorenz. 2012. “MBSE Supports Manufacturing System Design.” Proceedings of the22nd Annual International Council of Systems Engineering (INCOSE) International Symposium, 9-12 July 2012,Rome Italy. Paper ID: 2950Kernschmidt, K., B. Vogel-Heuser. 2013. "An interdisciplinary SysML based modeling approach for analyzingchange influences in production plants to support the engineering." Proceedings of the 2013 IEEE InternationalConference on Automation Science and Engineering (CASE), 17-20 Aug. 2013. pp.1113-1118. doi:10.1109/CoASE.2013.6654030Gulan, S., S. Johr, R. Kretschmer, S. Rieger, M. Ditze. 2013. “Graphical Modelling meets formal methods."Proceedings of the 11th IEEE International Conference on Industrial Informatics (INDIN), 29-31 July 2013.pp.716-721. doi: 10.1109/INDIN.2013.6622972Hoffmann, H. 2012. "Streamlining the development of complex systems through model-based systems engineering,"Proceedings of the 2012 IEEE/AIAA 31st Digital Avionics Systems Conference (DASC), 14-18 Oct. 2012.pp.6E6-1,6E6-8. doi: 10.1109/DASC.2012.6382404Paredis, C.J.J., Y. Bernard, R.M. Burkhart, H.P. de Koning, S. Friedenthal, P. Fritzson, N.F. Rouquette, W. Schamai.2010. "An overview of the SysML-Modelica transformation specification." Proceedings of the 2010 InternationalCouncil on Systems Engineering (INCOSE) International Symposium, 11-15 July 2010, Chicago, IL.

Model-Based Systems Engineering Adoption Trends 2009-2018 57

Pihlanko, P., S. Sierla, K. Thramboulidis, M. Viitasalo. "An industrial evaluation of SysML: The case of a nuclearautomation modernization project." Proceedings of the 18th IEEE Conference on Emerging Technologies & FactoryAutomation (ETFA), 10-13 September 2013. pp.1-8. doi: 10.1109/ETFA.2013.6647945Ramos, A.L., J.V. Ferreira, J. Barcelo. "Model-Based Systems Engineering: An Emerging Approach for ModernSystems." IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews. 42(1):101-111,Jan. 2012. doi: 10.1109/TSMCC.2011.2106495

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

Systems Engineering Core Concepts

Purpose and Uses of the Systems Engineering Concept ModelThe Systems Engineering Concept Model (SECM) captures the concepts that are referred to in the SystemsEngineering Body of Knowledge. The SECM provides a means to evaluate the consistency and coverage across thebroad set of Systems Engineering concepts, and can facilitate communication to better understand and evolve theseconcepts. Although the primary reference for the SECM was the SEBoK, the concepts were cross-checked againstother industry references including ISO/IEC/IEEE 15288:2015 and the INCOSE Systems Engineering HandbookVersion 4, enabling the SECM to be used to evaluate, understand, and evolve the concepts in these references aswell. A small team developed the SECM to support the requirements for the next generation of the OMG SystemsModeling Language (OMG SysML™) to ensure SysML is consistent with the three leading industry standards.

SECM ApproachA concept model, called the Concept Map, was developed by the original SEBoK team prior to release of the SEBoKv1.0 in 2012, and was used to support integration of the initial concepts across the SEBoK topic areas. The ConceptMap included a concept model, and a mapping of the concepts to the glossary terms and to the sections of theSEBoK.The SECM captures the Systems Engineering concepts and their relationship that are contained in today’s SEBoK.The small subset of UML constructs and symbols, shown in Figure 1, are used to represent the SECM model. Thechoice of notations is intended to balance simplicity, understandability, and precision.

Figure 1 Concept Relationships used in the SECM. (SEBoK Original)

Figure 2 below shows a usage of these constructs and symbols when applied to a simple example of a Car. Thisdiagram shows that a Car is kind of a Vehicle, and that the Driver drives the car (a reference relationship), and thatthere are four wheels that are parts of the Car.

Systems Engineering Core Concepts 58

Figure 2 Example of Relationships betweenConcepts (SEBoK Original)

The SECM is presented in a series of diagrams that generally represent concepts for particular knowledge areas andtopics in the SEBoK, and also include references to glossary terms in the SEBoK.The approach used to capture the SECM content from the SEBoK is described in the following steps:1.1. A topic within a SEBoK knowledge area is selected and the text is evaluated to identify key Systems Engineering

concepts2.2. From the sentences containing the concepts, the subjects, i.e. the concepts, and the predicate, i.e. the relationship

between concepts, are identified. The predicate is a statement that says something about the subject3.3. A search is conducted for this concept in other areas of the SEBoK, and the accompanying text, is evaluated to

further refine the concept and its relationships to other concepts.4.4. The definition of the concept in the SEBoK glossary, if available, is evaluated.5.5. The use and definition of this concept in the other two industry references is evaluated.6.6. The concept and a derived definition from the above evaluation are added to the SECM.7.7. The discovered relationships between the concepts are added to the model and to the relevant diagrams. The

diagrams group related concepts often associated with a SEBoK Knowledge Area or Topic.8.8. As new contributions are made to the SEBoK, this approach can be used to identify new concepts and

relationships, and add them to the SECM.

Introduction to Core ConceptsThe SECM was developed independently of the BKCASE project to support the evolution of the SysML standard.These models can be used to identify inconsistencies and/or areas requiring additional coverage within the SEBoK tosupport future updates.The Core Concept Diagram shown in Figure 3 provides a high level view of the some of the key concepts presentedin the SEBoK. It should be emphasized that this figure is intended to be a representative interpretation of the currentSEBoK without modifying or adding concepts, and no claim of the completeness of the SEBoK concepts is made.The colors correspond to logical groupings of concepts.

Systems Engineering Core Concepts 59

Core SEBoK Concepts. (SysML Roadmap SECM. Used with permission)

A brief description of the core concepts model is provided below.A Systems Engineer is a role within an Organization that practices the Engineering Discipline of SystemsEngineering (SE), and is qualified by a set of SE Competencies. Systems Engineering integrates other Disciplines tosupport the Life Cycle Model. The Life Cycle Model is composed of life cycle Stages that typically includeconceptual, realization, production, support, utilization and retirement stages (not shown). Each life cycle Stagerefers to Life Cycle Processes that produce various kinds of Work Products. The Life Cycle Processes evolve theSystem-of-Interest (SoI).There are many kinds of systems including natural systems, social systems, and technological systems (not shown).Systems that are created by and for people are referred to as Engineered Systems. An Engineered System whose lifecycle is under consideration is referred to as a System-of-Interest (SoI).A System-of-Interest is part of a broader System Context, which also includes an Environment. The Environmentconsists of other open systems (not shown) that can influence the SoI. Systems are composed of System Elements,and have Behavior and Properties. Systems can exhibit Emergence and Complexity.Systems Engineering uses a System Approach which applies established system Principles. Systems Science is aninterdisciplinary field of science that studies complex systems and helps define and update the Principles that areapplied by the System Approach, which is used by the discipline of Systems Engineering.

Systems Engineering Core Concepts 60

References

Works CitedISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland:International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electricaland Electronics Engineers. ISO/IEC/IEEE 15288:2015.INCOSE. 2015. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0SysML Roadmap: Systems Engineering Concept Model Workgroup (SECM) [OMG SysML Portal] http:/ / www.omgwiki. org/ OMGSysML/ doku. php?id=sysml-roadmap%3Asystems_engineering_concept_model_workgroup

Primary ReferencesISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland:International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electricaland Electronics Engineers. ISO/IEC/IEEE 15288:2015.INCOSE. 2015. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0

Additional ReferencesNone

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

61

Knowledge Area: SEBoK Users and Uses

SEBoK Users and UsesThe users and uses described in this article were identified based on the six SEBoK purposes described in theSEBoK Introduction.Users can either be primary (those who use the SEBoK directly) or secondary (those who use the SEBoK withassistance from a systems engineer). Indicative, but not exhaustive, sets of example uses are shown in Tables 1 and 2below.

New to SEBoK or Systems Engineering?The list of users and use cases below allow someone who has come to the SEBoK with a particular focus to identifyquickly where to focus their reading. If you are completely new to systems engineering or have no clear view of howit is covered in the SEBoK you should use Use Case 0 below to orient yourself and learn the basics before looking atthe other use cases:•• Use Case 0: Systems Engineering Novices

Primary UsersPrimary users are those who use the SEBoK directly, as shown in Table 1. Hyperlinks in the second column link tothe associated use case, where one has been written. The use cases are listed at the end of the topic, and may also beseen here. [1]

Table 1. Primary SEBoK Users and Common Uses. (SEBoK Original)

# Users Uses

1 Practicing Systems Engineersranging from novice through expert

•• Taking on a new SE role in a project; preparing by finding references for study•• Expanding SE expertise and specialization; preparing by finding references for study•• Seeking to understand the principles of SE; seeking the best references to elaborate on those principles•• Reviewing a project or mentoring a new SE performer; seeking to understand what best practices to

look for•• Pursuing professional development through study of SE topics, including new developments in SE

2 Process engineers responsible fordefining or implementing SEprocesses

•• Maintaining a library of SE process assets; seeking to understand which SE process models andstandards are most relevant

•• Tailoring a process for a specific project; seeking to learn how others have tailored processes, or how aspecific application domain affects tailoring

• Measuring the effectiveness of an organization’s SE processes; seeking to learn how others have donethat

•• Defining standards for a professional society or standards organization

3 Faculty Members • Developing a new graduate program in SE, and deciding what core knowledge all its students mustmaster; the user should consult the Graduate Reference Curriculum for Systems Engineering(GRCSE™) in conjunction with the SEBoK

•• Developing a new SE course; seeking to identify course objectives, topics, and reading assignments•• Incorporate SE concepts in courses or curricula focused on engineering disciplines other than SE

4 GRCSE authors •• As members of the GRCSE author team, deciding what knowledge to expect from all SE graduatestudents

• See Graduate Reference Curriculum for Systems Engineering (GRCSE™) (Pyster et al. 2015)

SEBoK Users and Uses 62

5 Certifiers • Defining a company’s in-house SE certification program; seeking to understand what others have done,how such programs are typically structured, and how to select the knowledge that each person seekingcertification should master

•• Defining certification criteria for a professional society or licensure program

6 General Managers, OtherEngineers, developers, testers,researchers

• Mastering basic vocabulary, boundaries, and structure of SE; seeking a few primary references•• Learning what the scope of SE is, relative to the General Manager role•• Learning what the role of the systems engineer consists of, relative to others on a project or in an

organization•• Learning to effectively perform a general manager role on an SE integrated product team

7 Customers of Systems Engineering •• Providing resources to and receiving artifacts from systems engineers•• Seeking to better understand what to ask for, how to request it, how much to pay for it, and how to

judge the quality of what is received

8 SE managers •• Evaluating possible changes in team processes and tools proposed by systems engineers on variousteams; seeking independent information with which to evaluate the proposals

•• Hiring systems engineers, and developing competency-based job descriptions

9 SE researchers •• Looking for gaps are in SE knowledge to help guide a research agenda•• Getting familiarize with a research topic; seeking the most important articles about the topic

Secondary UsersSecondary users are those who use the SEBoK with assistance from a systems engineer, as shown in Table 2.

Table 2. Secondary SEBoK Users and Common Usages. (SEBoK Original)

# Users Uses

1 Human resourcedevelopmentprofessionals

•• Supporting the hiring and professional development of systems engineers

2 Non-technical managers •• Augmenting understanding of central concerns with information about relevant SE topics; e.g., a contractingmanager might want to better understand SE deliverables being called out in a contract

3 Attorneys, policy makers •• Defining the impact of SE performance on central concerns; e.g., understanding the liability of a systems engineerfor errors in judgment on a project, or the limitations of SE in guaranteeing the success of a project againstactions of sponsors, managers, or developers

List of Use CasesAt this time not every class of user has a use case developed. To illustrate the major uses, the following use cases areincluded:• Use Case 1: Practicing Systems Engineers. This covers the first set of users from Table 1.• Use Case 2: Other Engineers. This covers the second and sixth sets of users from Table 1.• Use Case 3: Customers of Systems Engineering. This covers the seventh set of users from Table 1.• Use Case 4: Educators and Researchers. This covers the third, fourth, and ninth sets of users from Table 1.• Use Case 5: General Managers. This covers the sixth and eighth sets of users from Table 1.While not exhaustive, the use cases show the utility of the SEBoK in various applications and contexts.

SEBoK Users and Uses 63

References

Works CitedNone.

Primary ReferencesNone.

Additional ReferencesNone.

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

References[1] http:/ / sebokwiki. org/ draft/ Case_Studies

Use Case 0: Systems Engineering NovicesSome users of the Systems Engineering Body of Knowledge (SEBoK) may be new to the field. This article providesrecommended readings for such a user.

Learn the Basic TermsAs discussed in the Introduction to the SEBoK, there are four key terms that you should first understand whenlearning about systems engineering (SE):• A system is “a collection of elements and a collection of inter-relationships amongst the elements such that they

can be viewed as a bounded whole relative to the elements around them. Open Systems exists in an environmentdescribed by related systems with which they may interact and conditions to which they may respond. While thereare many definitions of the word “system,” the SEBoK authors believe that this definition encompasses most ofthose which are relevant to SE.

• An engineered system is an open system of technical or sociotechnical elements that exhibits emergent propertiesnot exhibited by its individual elements. It is created by and for people; has a purpose, with multiple views;satisfies key stakeholders’ value propositions; has a life cycle and evolution dynamics; has a boundary and anexternal environment; and is part of a system-of-interest hierarchy.

• Systems engineering is “an interdisciplinary approach and means to enable the realization of successful(engineered) systems”. It focuses on holistically and concurrently understanding stakeholder needs; exploringopportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions whileconsidering the complete problem, from system concept exploration through system disposal.

• A systems engineer is “a person who practices systems engineering” as defined above, and whose systemsengineering capabilities and experience include sustained practice, specialization, leadership, or authority over SEactivities. These activities may be conducted by any competent person regardless of job title or professionalaffiliation.

Use Case 0: Systems Engineering Novices 64

Get an OverviewThe next step for someone new to SE is get an overview of the discipline. Part 1: SEBoK Introduction contains fourarticles particularly helpful to one new to SE.• The article Systems Engineering Overview frames systems engineering inside the larger topic of ‘Systems

Science.’• The article Economic Value of Systems Engineering makes the business case for investing in systems engineering

as a way to reduce total ownership cost.• The article Systems Engineering and Other Disciplines discusses briefly how systems engineers and other

engineers interact as together they develop complex systems.• Finally, the article Systems Engineering: Historic and Future Challenges gives a quick history of the discipline

and discusses what lays ahead.

Learn about SystemsEngineering is often described as the application of science to develop new products or systems. Part 2: Foundationsof Systems Engineering describes some of the underlying systems principles that form the foundation for systemsengineering.• The Knowledge Area on Systems Fundamentals contains five articles. What is a System? is recommended for a

new user.• The Knowledge Area on Systems Science presents two articles on its history and approaches. Both are

recommended.• The Knowledge Area on Systems Thinking has four articles. The first, What is Systems Thinking?, is

recommended on a first reading.• One of the most important current research and practice areas of SE is Model Based Systems Engineering

(MBSE). The Knowledge Area Representing Systems with Models provides the foundation for MBSE. The firstthree of the five articles in the KA are recommended.

Learn how the Systems Approach is Applied to Engineered SystemsThe Knowledge Area Systems Approach Applied to Engineered Systems describes how systems science and systemsthinking lead to the practice of systems engineering. All eight articles are recommended.•• Overview of the Systems Approach•• Engineered System Context•• Identifying and Understanding Problems and Opportunities•• Synthesizing Possible Solutions•• Analysis and Selection between Alternative Solutions•• Implementing and Proving a Solution•• Deploying, Using, and Sustaining Systems to Solve Problems•• Stakeholder Responsibility•• Applying the Systems Approach

Use Case 0: Systems Engineering Novices 65

Explore the Methods of Systems EngineeringThe SEBoK uses a life-cycle framework to describe the processes that comprise systems engineering. Part 3: SE andManagement contains the plurality of the content of the SEBoK in eight knowledge areas. A new user should befamiliar with the introductions to each of these Knowledge Areas, and should read further in those KAs of interest.•• Life Cycle Models•• Concept Definition•• System Definition•• System Realization•• System Deployment and Use•• Systems Engineering Management•• Product and Service Life Management•• Systems Engineering Standards

Explore the Applications of Systems EngineeringThe SEBoK partitions the body of knowledge between methods and areas of application. Areas of application areclassified as:•• Product Systems Engineering•• Service Systems Engineering•• Enterprise Systems Engineering•• Systems of Systems (SoS)A new user should read the introduction to Part 4: Applications of Systems Engineering and to the four knowledgeareas listed above. The reader’s interests can then suggest which further reading should be done.

Read Case StudiesFinally, the new user should scan the case studies and vignettes in Part7: SE Implementation Examples and read afew of those in areas that appeal to the reader. This will help reinforce the fundamentals as well as illustrate thepractice of SE.The following case studies are included:•• Successful Business Transformation within a Russian Information Technology Company•• Federal Aviation Administration Next Generation Air Transportation System•• How Lack of Information Sharing Jeopardized the NASA/ESA Cassini/Huygens Mission to Saturn•• Hubble Space Telescope Case Study•• Global Positioning System Case Study•• Medical Radiation Case Study•• FBI Virtual Case File System Case Study•• MSTI Case Study•• Next Generation Medical Infusion Pump Case Study

Use Case 0: Systems Engineering Novices 66

For Later ReadingPart 6: Related Disciplines contains a broad selection of Knowledge Areas and Topics that describe how systemsengineers work with other disciplines. The Knowledge area on SE and Software Engineering is particularlyimportant, as modern systems get much of their functionality from software.Part 5: Enabling Systems Engineering has KAs describing how individuals, teams, and organizations can develop topractice effective systems engineering.A person new to SE should become familiar with several references that are beyond that SEBoK. They include theINCOSE Handbook, several standards (listed in Relevant Standards), and the main journals of systems engineering(including but not limited to Systems Engineering, the Journal of Enterprise Transformation, and Systems, Man, andCybernetics).

References

Works CitedNone.

Primary ReferencesNone.

Additional ReferencesNone.

Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

Use Case 1: Practicing Systems Engineers 67

Use Case 1: Practicing Systems EngineersBoth for the entry-level systems engineer learning the discipline of systems engineering (SE), and the moreexperienced systems engineer seeking the knowledge required to accomplish a work activity, the SEBoK serves as aprimary information source and a quick, comprehensive reference for SE information.What these system engineers find in the SEBoK includes:•• definitions of terms,•• explanations of basic concepts and principles,•• useful discussions of topics,•• references to articles and textbooks that cover topics in-depth, and•• pointers to additional sources.

How Systems Engineers Use TopicsResearching SE-related subjects, identifying educational resources, and connecting with individuals or organizationswhich offer specialized expertise are all part of the job for the practicing systems engineer. The time available to theSE for these activities can be quite limited. The SEBoK is designed to ease the pressure on the systems engineer inthis situation, in several ways:•• Because its content is based on research, proven practices, and emerging knowledge, the SEBoK makes

high-quality information available to the systems engineer right away.•• Being composed of articles of 2000 words or less in most cases, the SEBoK enables the systems engineer to

quickly get an overview of relevant topics.•• By providing primary references, each topic offers a direct route to more detailed information.•• Even greater detail, breadth, and a sense of what's relevant in the SE literature are available through the additional

references each topic provides.•• Since the SEBoK sources have been reviewed and vetted by a team of experts, the SEBoK helps the systems

engineer avoid less reliable information which can be hard to eliminate within Internet search results.•• The systems engineer who needs to connect with educators and researchers can find relevant names and

institutions in SEBoK topics and references.Systems engineers using the SEBoK may choose one or more of several approaches:• searching on keywords or article names, using the text field, Search [1] button, and Go [2] button at the top right of

each SEBoK page• scanning the Quick Links, Outline (where the table of contents is located), or Navigation indexes that appear at

the left of each SEBoK page, and following links from there to articles that seem likely to be of interest•• searching on keywords using an Internet search engine•• reading through one or more of Parts 1 through 7 in sequenceReading the SEBoK in sequence is especially suitable for the practicing engineer who is new to SE, or is enrolled inan SE-related training course. For this engineer, SE (or some aspect of it) is a subject to be learned comprehensively.This is made easier by navigation links from each article to the previous, next, and parent articles as found in theTable of Contents.For practicing systems engineers, having the SEBoK makes it possible to gain knowledge more quickly and reliablythan they would otherwise. The goal is to spend less time searching for and compiling new information fromdisparate sources and more time getting work done.For a team of practicing engineers, the gap in knowledge between more- and less-experienced engineers can be a major obstacle. The SEBoK serves as a tool for the team to build a framework of agreed-upon definitions and perspectives. The consistency of such a framework enhances communication across the team. New teams, especially,

Use Case 1: Practicing Systems Engineers 68

can benefit from bridging the gap between legacy and more-recently-acquired knowledge. For more information, seeEnabling Teams in Part 5.

How Systems Engineers Use Implementation ExamplesThe SEBoK is written, for the most part, independent of any particular domain of practice. By design, parts 1 though6 focus on the discipline of SE and not the numerous domains where SE can be applied.This lack of domain-specific content is partly offset by Part 7, Systems Engineering Implementation Examples,which consists of case studies and examples drawn from a number of domains where SE is applied. Each exampledemonstrates the impact of a particular application domain upon SE activities. Examples are generally most useful tothe systems engineer when they are aligned with the domain in which the he or she is working, but sometimes ideasfrom an example in one domain can be usefully applied to situations in another.

Example: Model-Based Systems Engineering PractitionersFor practitioners of model-based systems engineering (MBSE), the Representing Systems with Models knowledgearea is of central importance within the SEBoK.Academic faculty who use the SEBoK to support curriculum development and assessment can refer to the sameknowledge area to ensure that their curricula accurately cover the languages and/or methodologies such as SystemModeling Language (SysML) and Object-Process Methodology (OPM).SE researchers, too, can adopt an MBSE approach, making their research products more formal and rigorous bybasing them on models.In MBSE, models of systems support system life cycle activities, including requirements engineering, high-levelarchitecture, detailed design, testing, usage, maintenance, and disposal.

Vignette: Systems Engineering for Medical DevicesTara Washington has worked as a engineer for the HealthTech medical device company for seven years. Besidescontinuing to improve her strong software skills, she has shown an aptitude for systems thinking. To betterunderstand the products that her software supports, Tara has taken courses in electrical engineering, mechanicalengineering, and physiology. The coursework has helped her to perform effectively as a software system analyst onthe SE teams of her last two projects.HealthTech’s Research Division proposes a new concept for a highly programmable radiation therapy device thatmonitors the effects of the radiation on various parts of the body and adjusts the parameters of the radiation dosageto maximize its effectiveness, subject to a number of safety constraints. The software-intensiveness of the deviceleads Tara’s project manager to recommend her as the lead systems engineer for the design and development of theproduct.Tara welcomes the opportunity, knowing that she possesses enough domain knowledge to take the lead SE role.Even so, she realizes that she has picked up SE skills mainly by intuition and needs to build them up moresystematically. Tara begins to consult some of HealthTech’s lead systems engineers, and to study the SEBoK.After reading the SEBoK Introduction, Tara feels that she has a solid overview of the SEBoK. Tara finds that thenext topic, Scope and Context of the SEBoK, outlines the key activities that she expects to lead, along with otherswhich will require her to collaborate with systems developers and project and systems management personnel.The same topic identifies those parts of the SEBoK that Tara needs to study in preparation for her lead systemsengineer role:• SE concepts, principles, and modeling approaches in Part 2 (Representing Systems with Models knowledge area

(KA))

Use Case 1: Practicing Systems Engineers 69

• life cycle processes, management, technical practices, in Part 3 (Systems Engineering and Management KA)• approaches for specifying, architecting, verifying and validating the hardware, software, and human factors

aspects of the product, as well as common pitfalls to avoid and risks to manage, also in Systems Engineering andManagement

• guidelines for the systems engineering of products, in Part 4: Applications of Systems Engineering, includingreferences

• SE knowledge, skills, abilities, and attitudes (KSAAs) needed for a project in Part 5: Enabling SystemsEngineering including references

• specialty engineering disciplines that may be key to the project’s success, in Part 6: Related DisciplinesTara's awareness of the deaths caused by the Therac-25 radiation therapy device motivates her to study not only theSafety Engineering topic in Part 6, but all of its key references as well.While reading about SE life cycle process models in Systems Engineering and Management in Part 3, Tara notes thereference to the Next Generation Medical Infusion Pump Case Study in Part 7. This case study strikes Tara as highlyrelevant to her medical-device work, and she observes that it is organized into phases similar to those used atHealthTech. From the case study, Tara gains understanding of how a project such as hers would progress: byconcurrently evaluating technology opportunities, by discovering the needs of various device stakeholders such aspatients, nurses, doctors, hospital administrators, and regulatory agencies, and by working through increasinglydetailed prototypes, specifications, designs, plans, business cases, and product safety analyses.The case study mentions its source: Human-System Integration in the System Development Process [3] (Pew andMavor 2007), published by the U.S. National Research Council. Tara obtains this book. In it, she finds numerousgood practices for human-systems needs analysis, organizational analysis, operations analysis, prototyping, usabilitycriteria formulation, hardware-software-human factors integration, process decision milestone review criteria, andrisk management.As a result of her SEBoK-based study, Tara feels better-qualified to plan, staff, organize, control, and direct the SEportion of the HealthTech radiation therapy device project and to help bring the project to a successful conclusion.

SummaryIn the SEBoK, practicing engineers have an authoritative knowledge resource that can be accessed quickly to gainessential high-level information, and to identify the best references for in-depth study and research into SE topicswhen an individual’s initial level of understanding is not adequate to get the job done.The SEBoK is also a resource for practicing engineers who teach, as well as those taking training courses.

References

Works CitedPew, R. and A. Mavor. 2007. Human-System Integration in the System Development Process: A New Look.Washington, DC, USA: The National Academies Press.

Use Case 1: Practicing Systems Engineers 70

Primary ReferencesNone.

Additional ReferencesNone.

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

References[1] http:/ / www. mediawiki. org/ wiki/ Help:Searching[2] http:/ / meta. wikimedia. org/ wiki/ Help:Go_button[3] http:/ / www. nap. edu/ catalog. php?record_id=11893

Use Case 2: Other EngineersThe realization of successful complex systems requires experts from many disciplines to work together. This makesthe SEBoK useful to engineers with backgrounds in biomedical, civil, electrical, chemical, civil, materials,mechanical, software, and many other engineering disciplines.Studying the SEBoK enables engineers from disciplines other than systems engineering (SE) to•• see why good systems engineering practice must involve multiple disciplines,•• appreciate a broader view of systems beyond their specialties,•• understand how their contributions fit into the larger systems picture, and•• prepare to solve more difficult and encompassing problems.In many cases, engineers who study systems engineering as a supplement to their area of specialization find theirprofessional value enhanced when they put the new knowledge into practice.

Use of TopicsFor engineers from non-SE backgrounds, each part of the SEBoK contributes something to the experience oflearning about systems engineering.• Part 1 provides an overview both of systems engineering and of the SEBoK itself• Part 2 highlights the areas of systems knowledge most relevant to systems engineering, providing a foundation for

the theory and practice of systems engineering as explained in Parts 3, 4 and 5• Part 3 includes the knowledge areas of Life Cycle Models, System Definition, System Realization, and System

Deployment and Use, all highly important when approaching study of SE from another discipline.• Also in Part 3, Systems Engineering Management includes such relevant topics as risk management,

measurement, configuration management, and quality management.• Part 4 identifies the SE activities for four kinds of engineered systems, namely products, services, enterprises, and

systems of systems (SoS).• The primary references and glossary terms — not just the content — for a given type of system are essential

reading for an engineer developing or modifying a system of that kind.• Part 5, especially Team Capability, explains how systems engineers and other types of engineers fit into the larger

picture of enabling individuals and teams to perform systems engineering activities, and into the larger picture ofsystems engineering organizational strategies.

Use Case 2: Other Engineers 71

• Part 6 is key for engineers from non-SE backgrounds.• Within Part 6, Systems Engineering and Project Management should be of interest to almost all readers, while

Systems Engineering and Software Engineering and Systems Engineering and Specialty Engineering arenaturally most essential for engineers in the respective disciplines.

• Part 7 illustrates how systems engineering practices, principles, and concepts are applied in real settings, andcontains much universally-useful insight

Engineers may be tempted to skip over knowledge areas or topics which sound more like management thanengineering stories, for example Systems Engineering Management in Part 3 or Part 5. This temptation should beresisted, because these topics are actually about how SE orchestrates the efforts of multiple disciplines, notmanagement in the administrative sense.Finally, the extensive lists of references throughout the SEBoK provide a basis for further readings.

Vignette: Software EngineerJose Wilks is an entrepreneurial software engineer who wants to learn more about systems engineering principlesapplied to embedded systems for advanced document identification and verification. He wants to implement bestpractices in developing highly secure systems for real-time image processing and forensic verification of documents.His company provides a rapid, secure and cost-effective solution for verifying the authenticity of identification,travel, and financial documents, with technology that runs on proprietary tablet computers for portable and fixedlocations.Jose is knowledgeable about computer hardware engineering, low-level interfaces between hardware and software,and the related tradeoffs in embedded devices. His company has developed research prototypes, but without thestringent security requirements for actual field usage linked to government identification databases. The fewexperimental units which have been sold have fared well in limited testing, but Jose wants to expand into markets forgovernment agencies, law enforcement departments and the private sector. To make headway into those diversemarkets, he will need to confront abundant new constraints and challenges.Jose begins his study of SE by skimming the SEBoK Introduction and the Scope and Context of the SEBoK to get anoverview of the SEBoK contents. As he reads, he sometimes refers to the Software Engineering Body of Knowledge(SWEBoK) (Bourque and Fairley 2014), which Jose already knows from his many years of experience on softwareprojects. In the SEBoK, Jose is looking for nuggets of knowledge and pointers that can help his enterprise expand.Here are his notes:• Part 3: Systems Engineering and Management has concepts that are new to us and that may work. Extra

system-level verification and validation (V&V) gates identified in Life Cycle Models can be incorporated incompany processes, and the references can help with implementation details. There is also material aboutsystem-wide procedures beyond software V&V, and about where to find testing and regulation standards used byvarious government entities. Together with the traditional software testing already in place, these processes couldensure conformity to the regulations and expedite the product's approval for use.

• Though the system concept is proven, the company must still convince potential buyers of the system's financialbenefits while demonstrating that all security criteria are satisfied. To do that, we must understand the needs ofthe stakeholders better. In expressing system requirements and benefits, we need to start using the terminology ofusers, corporate/government purchasers, and regulatory agencies. Stakeholder Needs and Requirements isrelevant here. The company needs to quantify expected return on investment (ROI) for its products.

• System Realization addresses our broader V&V concerns. We need to demonstrate the measures we are taking toboost reliability of system performance. The standard models and measures for system reliability described in theSEBoK are new to us — now staff must develop tests to quantify important attributes. We may want to modelreliability and system adherence to regulations using a form of model-based systems engineering (MBSE). Wecan learn more about this from the references.

Use Case 2: Other Engineers 72

• Systems Engineering Management makes it clear that new configuration management (CM) and informationmanagement (IM) procedures need to be adopted for federal database controls and integrity. We can use thereferences in Systems Engineering Standards to learn how to define processes and develop test cases.

• Part 5: Enabling Systems Engineering makes a convincing case that having the right people for a new systemsengineering culture is critical. We should probably hire a systems engineer or two to augment our engineeringdepartment expertise.

• Our application must deal with private data concerns, and Part 7: Systems Engineering Implementation Examples,the FBI Virtual Case File System Case Study could help us avoid pitfalls that have hurt others in similarsituations. We can put this in context based on Security Engineering in Part 6: Related Disciplines, and thenfollow up with further study based on the references.

Now Jose feels that he is better prepared to adapt his processes for new system lifecycles and environments, and thathe can see a clear path through the morass of agencies and regulations. His priorities are to quantify the valueproposition for his technology innovations, make inroads into new markets, and strengthen his staff for the long-termenterprise.

Vignette: Mechanical EngineerCindy Glass is a mechanical engineer whose experience in the petroleum industry has focused on large-scale oilextraction equipment in the field. Now Cindy is tasked with helping to manage the development of new offshore oilplatforms featuring robotic technology and computer networks. This calls for incorporating SE principles from dayone to cope with the systems considerations, which are broader than anything in Cindy's previous experience.Some of the drilling is to be done with remote-controlled, unmanned underwater vehicles (UUVs). Along withsafety, which was always a major concern, cybersecurity now takes center stage. Hostile state actors, “hacktivists,” orothers could cause havoc if they succeed in taking control of the remote vehicles or other infrastructure.Unfortunately, software system implementation is completely new to Cindy, who realizes that this entails dealingwith many more engineering disciplines and dimensions of system constraints than she previously encountered.Cindy is accustomed to implementing minor design changes in existing equipment, with automation and safetyguidelines already in place. Now she is starting from scratch, with the earliest stages of the platform lifecycle. WhileCindy understands tradeoffs involving mechanical sub-systems like rigs and drilling materials, she now must nowbroaden her system analysis to include new environmental constraints and system security.Cindy consults the SEBoK and discovers that for her effort to understand system design with many "-ilities," SystemRealization is a good starting point and its references should provide the in-depth information she needs.The project lifecycle requires pursuing several major activities concurrently:•• engineering platform sub-components•• evaluating technology opportunities•• understanding the needs of all stakeholders inside and outside the company•• progressing through increasingly detailed prototypes, working slices of software, system specifications, designs,

plans, business cases, and, security and safety analyses of the platform architecture and its operations.To understand how to manage such a project lifecycle, Cindy turns to Part 3: Systems Engineering and Management.The planning section provides detailed advice for starting out. Cindy expects to conduct her management activitieson a rigorous basis, to consider the interfaces between the engineering specialties, and to produce a project plan thatcalls for a broad set of integrated management and technical plans.Being new to the software development world, Cindy reads The Nature of Software and Key Points a SystemsEngineer Needs to Know about Software Engineering, and consults the SWEBoK [1] for references on softwareengineering.

Use Case 2: Other Engineers 73

These readings show Cindy how closely systems engineering and software engineering are intertwined. For example,they remind her to include security specialists at both the software level and the systems level from the beginning.From her initial plunge into study of the SEBoK, Cindy has gained an appreciation of the wide range of systemconstraints she must account for, and the many engineering disciplines she must work with as a result. She plans toconsult the references in the SEBoK on each unfamiliar subject that she encounters throughout the architecting,design, development and deployment of the new platforms.

SummaryEngineers from disciplines other than systems engineering benefit from the insights about SE principles that theSEBoK provides. Studying the knowledge areas highlighted in this use case and the sources to which their referencespoint can help such engineers become more interdisciplinary. Ultimately, they can consider broadening their workresponsibilities, rendering them more valuable to their employers and society.

References

Works CitedBourque, P. and R.E. Fairley (eds.). 2014. Guide to the Software Engineering Body of Knowledge (SWEBOK). LosAlamitos, CA, USA: IEEE Computer Society. Available at: http:/ / www. swebok. org

Primary ReferencesNone.

Additional ReferencesNone.

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

References[1] http:/ / www. computer. org/ portal/ web/ swebok

Use Case 3: Customers of Systems Engineering 74

Use Case 3: Customers of Systems EngineeringCustomers of systems engineering (SE) provide resources to SE organizations and individuals, and receive SEproducts and services in return. They are among the stakeholders for a system-of-interest (SoI). They and otherstakeholders express needs and expectations for results that system engineers provide.Although their main SE activity is helping to define the system, customers must take account of all life cycle aspects.The better they understand the activities that systems engineers perform, the better customers know what to request,how to request it, how much to pay for it, and how to judge the quality and value of the results of systemsengineering. In short, what customers need to grasp is how systems engineers participate in the realization ofengineered systems resulting in products, services, enterprises, and systems of systems (SoS).The SEBoK assists the customers of systems engineering by providing a broad, comprehensive treatment of theconcepts, principles, theory, and practice related to systems in general and SE in particular. Its references informcustomers about books and articles that provide important perspectives on systems and SE.Customers of SE include:•• sponsors of internal SE organizations•• organizations that maintain long-term customer-domain relationships with external SE organizations, and•• organizations that outsource SE functions to general-purpose SE organizations.The two vignettes below show how the SEBoK can assist SE customers. In one, the customer of an internal,corporate SE organization leads the transition to a mobile supply chain management system. In the other, thecustomer of a mixture of customer-domain and other SE organizations presides over the SE of acatastrophe-response sSoS, which entails integration over multiple domains.

Use of TopicsFor customers of SE, most parts of the SEBoK offer immediately relevant knowledge about SE.Part 1:•• explains the relationship between SE, system development, and project management,•• summarizes overall trends in the rate of growth of systems interdependency, complexity, assurance levels, and

pace of change, and of the evolving nature of integrated hardware-software-human systems, and•• provides pointers to other parts of the SEBoK of interest to customers.Part 3:• explains evolving system life cycle models and their elements, indicating which elements are SE-intensive (see

Life Cycle Models),•• provides overall perspectives on customer participation in SE activity,•• identifies customer influence points on SE activity, and• explains how customers can express their concerns in the form of needs, expectations, and requirements (see

System Definition).Part 4:•• explains how the SE function varies by class of system product, service, enterprise, and systems of systems

engineering).Part 6:•• explains how SE relates to project management, procurement and acquisition, and specialty engineering for such

customer-intensive specialties as safety, security, maintainability, usability, and affordability.Part 7:

Use Case 3: Customers of Systems Engineering 75

•• provides case studies and examples to illustrate how the parts have been used in similar situations, presentingsuccesses to emulate and failures to avoid.

If there is a central theme here, it is that the quality of customer input is critical. That is because the systems engineerevaluates customer input, then uses it in formulating an approach to defining and realizing the system. Part 3addresses this, explaining that the customer should expect the systems engineer to provide:• a well-architected product, service, enterprise, or system of systems that meets customer needs and expectations

(again, this depends on high quality input from stakeholders — see System Definition)• a managed life cycle model from the customer need and requirements to the delivered product, service, enterprise

or system of systems (see Life Cycle Models)• verification that the system-of-interest (SoI) meets the needs and requirements of the stakeholders, and• validation that the final result, when deployed in an operational environment, provides the value added that was

desired are critical to systems engineering (see System Realization and System Deployment and Use).

Implementation ExamplesGood examples provide a basis for deeper understanding. In Part 7, the SEBoK provides summaries of andreferences to full case studies and examples. These are linked back to the appropriate areas of the SEBoK and amatrix is provided that shows the primary areas of the SEBoK addressed by each example. Readers can use thematrix to find case studies and examples- and through these, references - that relate to their concerns.

Vignette: Mobile Supply Chain ManagementBarbara Bradley is the Director of Supply Chain Management Systems for a large manufacturing company. Hermain area of expertise is transportation logistics. She has led the evolution of a highly successful corporate supplychain management system based on desktop and mainframe technology, more by making incremental strategicchoices than by applying formal SE.Now, many of her suppliers and distributors adopt mobile devices and cloud services and Barbara sees that her owncompany must do the same. The company's status quo approach of incremental, ad hoc choices is clearly inadequatefor a technology transition of this magnitude. Not only that, but the company must evolve to the new mode ofoperation while providing continuity of service to the supply chain stakeholders.Barbara decides that these challenges require formal SE. As a first step, she plans to put together a Next-GenerationSupply Chain Management System integrated product team (IPT). Members of the IPT will include Barbara's supplychain experts, her supply-chain success-critical stakeholders, and the corporate SE organization.Barbara has never used the corporate SE organization before, and wants to better understand an SE organization’soverall capabilities and modes of operation. She turns to the SEBoK for answers to the questions about SE that areon her mind:•• How do we maintain continuity of service while pursuing incremental development?

•• What choices about life cycle models can make this possible?•• What is the role of the customer in defining systems of interest (SoIs)?

•• How do we provide guidance to the customer in expressing needs, concerns, and requirements?•• What is the role of the customer at early decision milestones?

•• How do we ensure that results of our interaction with the customer include well-architected products andthorough development plans, budgets, and schedules?

•• What is the role of the customer in product acceptance, specifically when we verify stakeholder requirements andwhen we validate the final result?

Barbara seeks the answer to one question in Part 4: Applications of Systems Engineering:

Use Case 3: Customers of Systems Engineering 76

•• Given that a supply chain management system combines product, service, enterprise, and SoS views, how do weunderstand what goes into all those views, and keep the overall picture clear?

Barbara's final question is addressed in Part 6: Systems Engineering and Other Disciplines:•• How do we integrate SE and software engineering (SwE)?Once in command of the answers to these questions, Barbara is ready to lead the IPT in analyzing, negotiating, anddefining an approach that is satisfactory to all of the success-critical stakeholders. By having the IPT members readthe portions of the SEBoK that she has found most valuable, Barbara begins to build a shared vision within the IPT.As the IPT defines a Next-Generation Supply Chain Management System and prepares the transition from the oldsystem to the new, the SEBoK is an important tool and resource.

Vignette: Catastrophe-Response System of SystemsAhmed Malik is the Information Systems Division General Manager in his country’s Department of NaturalResources. The country suffers frequent wildfires that destroy crops, forests, villages, and parts of cities, and alsocause problems with emergency care, crime prevention, and the water supply.During a recent catastrophic wildfire, personnel responsible for firefighting, crime prevention, traffic control, watersupply maintenance, emergency care facilities, and other key capabilities found themselves unable to communicatewith each other. As a result, the Minister for Natural Resources has been tasked with improving the country’scatastrophe response capabilities, and has named Ahmed as the SE customer lead for this effort.The Minister suggests that Ahmed organize a workshop to scope the problem and explore candidate solutions to thecommunications problems. Ahmed invites the various actors involved in catastrophe response — medical, insurance,and news media organizations from both public and private sectors. He also invites SE organizations with SoSexperience.Ahmed has strong experience in information SE, but none in the development of SoSs. To come up to speed in hisrole as the SE customer lead, Ahmed turns to the SEBoK Part 3: Systems Engineering and Management. To betterunderstand the challenges of SoS SE, he studies the SoS knowledge area in Part 4, and its references. Ahmed alsoschedules meetings with the leading SoS SE provider organizations, who are eager to tell him about theircapabilities. Overall, Ahmed looks for both guidance and pointers to candidate solution sources in the SEBoK.Thus prepared, Ahmed structures the workshop to address three key challenges:•• mutual understanding of organization roles, responsibilities, and authority•• summary analyses of previous catastrophe response communication gaps and needs•• candidate solution capabilities in communications, data access, geolocation services, public emergency warning

systems, coordinating evacuation procedures, architectural connector approaches for improving interoperability,and sharable models for evaluating alternative solution approaches.

The workshop brings the primary organizations involved in catastrophe responses together with the most capableSoS SE provider organizations. The results of their discussions provide Ahmed and his Minister with sufficientinformation to prepare a phased plan, budget, and schedule for incremental development of improved catastropheresponse capabilities, beginning with simple interoperability aids and analysis of architecture alternatives forperformance, scalability, and feasibility of evolution from the initial simple fixes. The plan is then iterated with thekey stakeholders, and converged to a common-consensus approach for achieving strong, credible earlyimprovements and a way forward to a much more scalable and cost-effective catastrophe-response SoS.This vignette is based on the Regional Area Crisis Response SoS (RACRS) in (Lane and Bohn 2010).

Use Case 3: Customers of Systems Engineering 77

SummaryFor the customers of SE, the SEBoK provides both general and specific knowledge that will help users gainimportant insight in relating to systems engineers. Key to this is learning about life cycles, the definition of SoIs, andhow to provide guidance in expressing needs, concerns, and requirements. Further, customers need to know what toexpect as a result of SE activities in the form of well-architected products, services, enterprises, or systems ofsystems and a managed life cycle. The results of verification of stakeholder requirements and the validation of thefinal result in respect to fulfilling the user needs are vital.

References

Works CitedLane, J. and T. Bohn. 2010. Using SySML to Evolve Systems of Systems. Los Angeles, CA, USA: USC CSSETechnical Report. USC-CSSE-2010-506.

Primary ReferencesINCOSE. 2011. Systems Engineering Handbook, version 3.2.2. San Diego, CA, USA: International Council onSystems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.Jamshidi, M. (ed.) 2009. Systems of Systems Engineering - Principles and Applications. Boca Raton, FL, USA: CRCPress.Sage, A., and Rouse, W. (eds.) 1999. Handbook of Systems Engineering and Management. Hoboken, NJ, USA: JohnWiley and Sons, Inc.U.S. Department of Defense. 2008. Systems Engineering Guide for System of Systems, version 1.0. Arlington, VA:U.S. Department of Defense. Accessed 18 April 2013, available at: http:/ / www. acq. osd. mil/ se/ docs/SE-Guide-for-SoS. pdf.

Additional ReferencesP. Bourque and R.E. Fairley (eds), Guide to the Software Engineering Body of Knowledge, Version 3.0, IEEEComputer Society, 2014; Available at http:/ / www. swebok. org

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

Use Case 4: Educators and Researchers 78

Use Case 4: Educators and ResearchersFor educators or researchers, the SEBoK should be used together with GRCSE (Graduate Reference Curriculum forSystem Engineering). The SEBoK is a guide to the knowledge that constitutes the system engineering domain, whileGRCSE [1] “describes a program for a professional master’s degree focused on developing student ability to performsystems engineering tasks and roles” (Pyster et al. 2012).An educator, for purposes of this use case, is a university faculty member or a professional trainer. Educators use theSEBoK and the GRCSE to develop curricula or courses focused on systems engineering (SE) generally, ondomain-centric systems engineering, or on another engineering discipline that touches on SE. The SEBoK andGRCSE are means to assure accuracy, completeness, and effective assessment at all levels, from lessons throughobjectives.A researcher, for purposes of this use case, is a person actively contributing to the body of SE knowledge.

The Use of TopicsEducators can use SEBOK topics and their primary and additional references as:•• assigned readings for courses,•• supplemental references for student research, and•• content for curriculum development.Educators can also use the concepts, perspectives, and references to develop or refine course objectives and thetechniques for assessing them.Researchers can use SEBoK topics and their primary and additional references to learn about the state of the art inthe subject areas of interest, for summaries of the literature, and to look for opportunities to advance those areas byfurther research.A good course or research topic should reflect multiple perspectives, which the SEBoK provides. As well, catalogingthe wide diversity in accepted practices across SE is an important function of the SEBoK from the researcher'sperspective.For both educators and researchers, the fact that the SEBoK provides both primary and additional references in eachtopic is useful. So is the fact that the SEBoK is a wiki, which allows frequent updates to keep pace with the dynamicevolution of the systems engineering domain. See Acknowledgements and Release History.

Implementation ExamplesGood examples make for good teaching. The Systems Engineering Implementation Examples in the SEBoK consistof relatively in-depth case studies and shorter examples, which are linked back to appropriate areas of the SEBoK. Amatrix shows which SEBoK topics are addressed by each case study or vignette.Each case study in the SEBoK is actually a summary of an original case found in the SE literature, and isaccompanied by a reference to the full, published case study. Case study summaries or examples from the SEBoKmay be incorporated in curricula.

Use Case 4: Educators and Researchers 79

EducatorUniversity faculty may use the SEBoK and GRCSE to develop:•• a complete SE curriculum,•• a single course in systems engineering, either for use in an SE curriculum, or in a curriculum that belongs to some

other discipline, or•• assessment criteria for curricula or courses.Likewise, professional trainers use the SEBoK to develop training material, or to evaluate or update existing trainingcourses.Both faculty and trainers pursue professional development, in the form of SE study, using the SEBoK.

Vignette: Curriculum and Course DevelopmentA university designates a faculty team to investigate the feasibility of developing a graduate degree in SE.Results of preliminary feasibility analysis (including evaluating the market, competing degree programs, and so on)are encouraging. The faculty team then begins to design the program, by identifying:•• program constituents•• potential objectives, outcomes and entrance requirements, based on review of GRCSE•• one half of the of the curriculum content, based on review of the typical curriculum architecture (GRCSE chapter

5) and the core body of knowledge (CorBoK) (chapter 6) of GRCSE and•• the other half of the curriculum content based on review the SEBoK (Parts 2 through 7) .According to the GRCSE, 50% of the total knowledge conveyed in a graduate program should be based on theCorBoK, to assure a common foundation among programs offered at different institutions. At the same time,restricting the CorBoK to no more than 50% encourages a healthy variety in those programs.Once these steps are complete, the overall architecture and the content and the scope of the curriculum are defined.Now the faculty designs the courses themselves, defining in turn:•• the prerequisites for each course•• the overall course sequencing for the curriculum, based on the course prerequisites•• the objectives and goals for each course and•• the expected outcomes of each course.Finally, the faculty is ready to develop the content for each individual course.Defining course content is done based on topics in the SEBoK that cover the subject of the course.Using primary and additional references as much as the topics themselves, the faculty responsible for course designdefine:•• the scope of the course content•• the course coverage, that is, what within the course content scope is actually taught in the course.Given the scope and coverage, the next and final step is to develop the course material.A professional trainer designing the training material performs the same kinds of activities. To customize the trainingcourse for a specific industry or customers, the trainer may integrate domain-specific content as well.

Use Case 4: Educators and Researchers 80

ResearcherResearchers use SEBoK topics and their primary and additional references to learn about the state of the art in thesubject areas of topics, and to look for opportunities to advance those areas by further research.

Vignette: Software Engineering ResearchWilliam McGregor, a software engineer, wants to learn more about software intensive systems (SIS). Initially,William wants to answer the question: Do the activities and practices used to develop SIS represent specialtreatments of standard activities and practices?William has already reviewed the SWEBoK and its primary references extensively for an answer to his question. Inthe course of his research, William learns about the SEBoK and decides to look there, too.William finds no specific discussion of the SIS within the SEBoK. As he looks through the SEBoK, though, herealizes that there are activities throughout the system development life cycle which can be adapted or customizedfor the development of SIS. Accordingly, William decides to replace his original question with two new ones: (a)what best practices are applied throughout the software development life cycle and (b) how can those practices beadapted to SISs?William now focuses on Part 3 to learn about the system development life cycle, and identify development activitiesand practices that he can customize for software intensive systems.

SummaryEducators use the SEBoK as a framework or a resource which helps them:•• determine what subject matter should be included in a new curriculum•• identify gaps in an existing curriculum and craft plans to address those gaps, and•• design individual courses.The case studies and vignettes in the SEBoK may be used by educators in the classroom.To develop curricula at the program level, educators should use the SEBoK in tandem with the GRCSE.Researchers use the SEBoK to learn about the state of the systems engineering discipline, and to look foropportunities to advance that state by further research.

References

Works CitedBloom, B.S., M.D. Engelhart, E.J. Furst, W.H. Hill, and D.R. Krathwohl. 1956. Taxonomy of Educational Objectivesthe Classification of Educational Goals Handbook I: Cognitive Domain. London, UK: Longman Group Ltd.

Primary ReferencesPyster, A., D.H. Olwell, T.L.J. Ferris, N. Hutchison, S. Enck, J.F. Anthony, D. Henry, and A. Squires (eds). 2015.Graduate Reference Curriculum for Systems Engineering (GRCSE™), version 1.1. Hoboken, NJ, USA: TheTrustees of the Stevens Institute of Technology ©2015. Available at: http:/ / www. bkcase. org/ grcse-2/ .

Use Case 4: Educators and Researchers 81

Additional ReferencesNone.

< Previous Article | Parent Article | Next Article >SEBoK v. 2.1, released 31 October 2019

References[1] http:/ / www. grcse. org

Use Case 5: General ManagersGeneral managers preside over system development projects, system acquisitions, product lines, systems of systems(SoSs), and commercial and government organizations. For general managers, the SEBoK serves as a primaryinformation source and quick, comprehensive reference for systems engineering information.In particular, the SEBoK helps the general manager understand:•• the boundaries and synergies among systems engineering (SE), systems development, project management (PM),

and life cycle support•• how those boundaries and synergies are likely to evolve with increasing use of evolutionary development, lean

and agile methods, and systems that provide purchased services as opposed to salable products•• how to best balance a mix of hardware, software, human factors, domain, and specialty-area systems engineers

and•• how an organization can evolve to take advantage of the trend towards cross-discipline systems engineers.

Use of TopicsFor general managers, most parts of the SEBoK offer immediately relevant knowledge about SE.Part 1:•• explains the relationship between SE, system development, and project management•• summarizes overall trends in the nature of systems interdependency, complexity, assurance levels, and pace of

change•• describes the evolving nature of integrated hardware-software-human systems and•• provides pointers to other parts of the SEBoK of interest to general managers.Part 3:• explains evolving system life cycle models and their elements, indicating which elements are SE-intensive (see

Life Cycle Models) and•• provides overall guidance on the management of SE activity.Part 4:•• explains how the SE function varies by class of system product, service, enterprise, and systems of systems

engineering).Part 5:•• explains SE governance and competence development.Part 6:•• explains how SE relates to software engineering, project management, industrial engineering, procurement and

acquisition, and specialty engineering for such specialties as safety, security, maintainability, and usability.

Use Case 5: General Managers 82

Part 7:•• provides case studies and vignettes to illustrate how the parts have been used in similar situations in successes to

emulate and failures to avoid.

Vignette: Emerging Nation Satellite SystemTom Lee is General Manager for Telecommunications in a ministry of a large emerging nation. The governmentdoes not have much existing capability for developing capital-intensive infrastructure projects. The governmentdecides to use a major investment in technology as a vehicle to develop national enterprise capabilities.To accomplish this, the minister assigns Tom to lead a project to develop a national satellite system fortelecommunications and earth resources observation. Tom understands that this is a very complex system, anddecides to do some background research. During this research, Tom discovers the SEBoK and decides that is may bea useful resource.Tom first reads:• Part 1 for an overview and pointers to relevant sections of Parts 3 through 6,• portions of Part 3, Part 4, Part 5, and Part 6 to learn about the life cycle, nature, scope, and management aspects of

enterprise SE,• the successful satellite system case studies in Part 7 (Global Positioning System, Miniature Seeker Technology

Integration spacecraft) for approaches to emulate, and• the satellite system case study in Part 7 which describes development and integration problems (Hubble Space

Telescope) for pitfalls to avoid.Tom continues by carefully reading Part 5. He realizes that he must develop simultaneously individuals, teams, andthe enterprise. The knowledge areas (KAs) from Part 5 give useful background. For this project, Tom enlists both aproven multi-national satellite SE company and some of his brightest aerospace systems engineers. Tom expects hislocal systems engineers to learn from the SE company, and he plans to use them as the core group of the nationalsatellite system as it ultimately develops and operates.He realizes that correct problem definition and requirements setting will be critical first steps. He carefully reads theConcept Definition and System Definition KAs. As his team develops the Stakeholder Needs and Requirements andthe System Requirements, he makes sure they follow good practices as listed in the SEBoK. Once architecturaldesigns have been proposed and approved, he requires his team to perform cost-benefit tradeoff analyses ofalternative solutions.Thus prepared, Tom is confident that he can formulate and execute a successful approach.

Vignette: Commercial Safety Equipment CompanyMaria Moreno is General Manager at Safety First Equipment Company, specialists in hardware-intensive safetyequipment. Maria’s background is in electromechanical systems. Safety First is highly successful, but beginning tolose market share to competitors who offer software-intensive capabilities and user amenities.Maria is preparing an initiative to make Safety First into a leading software-intensive safety equipment provider. Shedecides to make the SEBoK a primary resource for gathering concepts and insights for the initiative. She begins byskimming through all of Parts 1 through 6, both to become familiar with the SEBoK itself and to start organizing herthoughts on SE.Now Maria is ready to focus on subjects of prime importance to her task. Here are those subjects, listed with theplaces in the SEBoK where she find information about them.In Systems Engineering and Software Engineering in Part 6:•• the nature of software•• differences between hardware and software architectures and practices and

Use Case 5: General Managers 83

•• key aspects of managing software teams.In the article Human Systems Integration in the Systems Engineering and Specialty Engineering knowledge area,also in Part 6:•• the SE of user amenities.In the Next Generation Medical Infusion Pump Case Study in Part 7:•• the software aspects of safety practices, such as software fault tree analysis and failure modes and effects analysis

and•• overall approaches for concurrent engineering of the hardware, software, and human factors aspects of

safety-critical equipment.In the Medical Radiation Case Study in Part 7:•• hardware-software pitfalls to avoid in safety-critical equipment.Maria chose the last two items from among the case studies in Part 7 because being safety-critical, they containlessons directly applicable to her initiative at Safety First.With this framework of concepts and practical information in place, Maria begins assembling a core team of SafetyFirst systems engineers, complemented by external experts in software and human factors engineering. Maria wantsthe team to begin by developing a shared vision. To that end, she asks them to read the portions of the SEBoK thatshe has found most valuable in assessing the challenges of transitioning Safety First into a leadingsoftware-intensive, user-friendly safety equipment provider.

SummaryFor the general manager whose organization includes systems engineers, the relationship between SE, systemsdevelopment, project management, and life cycle support is a central concern. The SEBoK provides insights andguidance about this and other aspects of SE principle and practice, and explains the role of SE in a variety ofmanagement challenge areas and application domains.The SEBoK complements the general management guidance available in sources such as the PMBOK® Guide (PMI2013).

References

Works CitedPMI. 2013. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th ed. Newtown Square,PA, USA: Project Management Institute (PMI).

Primary ReferencesPMI. 2013. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th ed. Newtown Square,PA, USA: Project Management Institute (PMI).

Additional ReferencesP. Bourque and R.E. Fairley (eds), Guide to the Software Engineering Body of Knowledge, Version 3.0, IEEEComputer Society, 2014; Available at http:/ / www. swebok. orgBooher, H. 2003. Handbook of Human-Systems Integration. New York, NY, USA: John Wiley & Sons Inc.Hooks, I.F. and K. Farry. 2000. Customer Centered Products: Creating Successful Products Through SmartRequirements Management. New York NY, USA: AMACON/American Management Association.

Use Case 5: General Managers 84

Pew, R. and A. Mavor. 2007. Human-System Integration in the System Development Process. Washington, DC,USA: The National Academies Press.

< Previous Article | Parent Article | Next Article(Part 2) >SEBoK v. 2.1, released 31 October 2019

Article Sources and Contributors 85

Article Sources and ContributorsLetter from the Editor  Source: https://www.sebokwiki.org/d/index.php?oldid=57764  Contributors: Apyster, Bkcase, Cnielsen, Dholwell, Eleach, Kguillemette, Radcock, Rcloutier, Smenck2,Wikiexpert

BKCASE Governance and Editorial Board  Source: https://www.sebokwiki.org/d/index.php?oldid=57626  Contributors: Apyster, Bkcase, Cnielsen, Dhenry, Kguillemette, Radcock, Rcloutier,Smenck2

Acknowledgements and Release History  Source: https://www.sebokwiki.org/d/index.php?oldid=57682  Contributors: Apyster, Asquires, Bkcase, Cnielsen, Ddori, Dhenry, Dholwell, Eleach,Janthony, Jgercken, Kguillemette, Nicole.hutchison, Radcock, Rcloutier, Smenck2, Smurawski, Wikiexpert

Cite the SEBoK  Source: https://www.sebokwiki.org/d/index.php?oldid=57684  Contributors: Apyster, Bkcase, Cnielsen, Dholwell, Kguillemette, Smenck2

Bkcase Wiki:Copyright  Source: https://www.sebokwiki.org/d/index.php?oldid=57613  Contributors: Apyster, Bkcase, Cnielsen, Dhenry, Kguillemette, Radcock, Smenck2, Wikiexpert

SEBoK Introduction  Source: https://www.sebokwiki.org/d/index.php?oldid=57078  Contributors: Afaisandier, Apyster, Araher, Bkcase, Cnielsen, Dhenry, Dholwell, HP.deKoning, Janthony,Jgercken, Kguillemette, Nicole.hutchison, Radcock, Rcloutier, Smenck2, Smurawski, WikiWorks, WikiWorks753, Wikiexpert, Zamoses

Introduction to the SEBoK  Source: https://www.sebokwiki.org/d/index.php?oldid=57080  Contributors: Bkcase, Radcock, Rcloutier, WikiWorks753

Scope of the SEBoK  Source: https://www.sebokwiki.org/d/index.php?oldid=57450  Contributors: Apyster, Araher, Bkcase, Cnielsen, Dhenry, Dholwell, Groedler, Janthony, Jgercken,Nicole.hutchison, Radcock, Rcloutier, Skmackin, Smenck2, Smurawski, WikiWorks, WikiWorks753, Wikiexpert, Zamoses

Structure of the SEBoK  Source: https://www.sebokwiki.org/d/index.php?oldid=57351  Contributors: Apyster, Araher, Bkcase, Dhenry, Dholwell, Janthony, Jgercken, Nicole.hutchison,Radcock, Rcloutier, Sfriedenthal, Skmackin, Smenck2, WikiWorks, WikiWorks753, Wikiexpert, Zamoses

Introduction to Systems Engineering  Source: https://www.sebokwiki.org/d/index.php?oldid=57084  Contributors: Bkcase, Radcock, Rcloutier, WikiWorks753

Systems Engineering Overview  Source: https://www.sebokwiki.org/d/index.php?oldid=57360  Contributors: Apyster, Bkcase, Cnielsen, Dhenry, Dholwell, Radcock, Rcloutier, Smenck2,WikiWorks, WikiWorks753

Economic Value of Systems Engineering  Source: https://www.sebokwiki.org/d/index.php?oldid=56681  Contributors: Apyster, Araher, Asofer, Bkcase, Cnielsen, Dhenry, Dholwell, Eleach,Janthony, Radcock, Rvalerdi, Smenck2, Smurawski, WikiWorks753, Wikiexpert

Systems Engineering: Historic and Future Challenges  Source: https://www.sebokwiki.org/d/index.php?oldid=57354  Contributors: Apyster, Araher, Bkcase, Cnielsen, Dhenry, Dholwell,Janthony, Jgercken, Radcock, Rcloutier, Smenck2, WikiWorks, WikiWorks753, Wikiexpert

Systems Engineering and Other Disciplines  Source: https://www.sebokwiki.org/d/index.php?oldid=57326  Contributors: Apyster, Araher, Asquires, Bkcase, Cnielsen, Dhenry, Dholwell,Janthony, Jgercken, Kguillemette, Nicole.hutchison, Rcloutier, Skmackin, Smenck2, WikiWorks, WikiWorks753, Wikiexpert, Zamoses

Introduction to SE Transformation  Source: https://www.sebokwiki.org/d/index.php?oldid=57026  Contributors: Bkcase, Radcock, WikiWorks753

Transitioning Systems Engineering to a Model-based Discipline  Source: https://www.sebokwiki.org/d/index.php?oldid=57319  Contributors: Bkcase, Radcock, WikiWorks, WikiWorks753

Digital Engineering  Source: https://www.sebokwiki.org/d/index.php?oldid=57751  Contributors: Bkcase

Set-Based Design  Source: https://www.sebokwiki.org/d/index.php?oldid=57817  Contributors: Bkcase

Model-Based Systems Engineering Adoption Trends 2009-2018  Source: https://www.sebokwiki.org/d/index.php?oldid=57831  Contributors: Bkcase

Systems Engineering Core Concepts  Source: https://www.sebokwiki.org/d/index.php?oldid=57499  Contributors: Bkcase, WikiWorks, WikiWorks753

SEBoK Users and Uses  Source: https://www.sebokwiki.org/d/index.php?oldid=57046  Contributors: Apyster, Araher, Asquires, Bkcase, Cnielsen, Dhenry, Dholwell, Jgercken, Kguillemette,Nicole.hutchison, Radcock, Skmackin, Smenck2, WikiWorks, WikiWorks753, Wikiexpert, Zamoses

Use Case 0: Systems Engineering Novices  Source: https://www.sebokwiki.org/d/index.php?oldid=57476  Contributors: Bkcase, Cnielsen, Dholwell, Radcock, WikiWorks, WikiWorks753

Use Case 1: Practicing Systems Engineers  Source: https://www.sebokwiki.org/d/index.php?oldid=57334  Contributors: Apyster, Araher, Bkcase, Dhenry, Dholwell, Janthony, Jgercken,Radcock, Rmadachy, Smenck2, WikiWorks, WikiWorks753, Wikiexpert

Use Case 2: Other Engineers  Source: https://www.sebokwiki.org/d/index.php?oldid=57359  Contributors: Apyster, Araher, Bkcase, Cnielsen, Dhenry, Dholwell, Jgercken, Rmadachy,Smenck2, WikiWorks, WikiWorks753, Wikiexpert

Use Case 3: Customers of Systems Engineering  Source: https://www.sebokwiki.org/d/index.php?oldid=57308  Contributors: Apyster, Araher, Bkcase, Dhenry, Dholwell, Jgercken, Radcock,Rmadachy, Smenck2, WikiWorks, WikiWorks753, Wikiexpert

Use Case 4: Educators and Researchers  Source: https://www.sebokwiki.org/d/index.php?oldid=57438  Contributors: Apyster, Araher, Asquires, Bkcase, Cnielsen, Dhenry, Dholwell, Jgercken,Radcock, Rmadachy, Smenck2, Smurawski, WikiWorks, WikiWorks753, Wikiexpert

Use Case 5: General Managers  Source: https://www.sebokwiki.org/d/index.php?oldid=57435  Contributors: Apyster, Araher, Asquires, Bkcase, Dhenry, Dholwell, Jgercken, Rmadachy,Smenck2, Smurawski, WikiWorks, WikiWorks753, Wikiexpert

Image Sources, Licenses and Contributors 86

Image Sources, Licenses and ContributorsFile:Rob_Sm for Web.jpg  Source: https://www.sebokwiki.org/d/index.php?title=File:Rob_Sm_for_Web.jpg  License: unknown  Contributors: RcloutierFile:RobSignature2.jpeg  Source: https://www.sebokwiki.org/d/index.php?title=File:RobSignature2.jpeg  License: unknown  Contributors: BkcaseFile:Hutchison profilephoto.png  Source: https://www.sebokwiki.org/d/index.php?title=File:Hutchison_profilephoto.png  License: unknown  Contributors: -File:SEBoK Navigation Introduction.PNG  Source: https://www.sebokwiki.org/d/index.php?title=File:SEBoK_Navigation_Introduction.PNG  License: unknown  Contributors: BkcaseFile:SEBoK Navigation Structure.PNG  Source: https://www.sebokwiki.org/d/index.php?title=File:SEBoK_Navigation_Structure.PNG  License: unknown  Contributors: BkcaseFile:SE_Key_Concepts.jpeg  Source: https://www.sebokwiki.org/d/index.php?title=File:SE_Key_Concepts.jpeg  License: unknown  Contributors: Bkcase, Smenck2, SmurawskiFile:Scope_BoundariesSE_PM_SM.png  Source: https://www.sebokwiki.org/d/index.php?title=File:Scope_BoundariesSE_PM_SM.png  License: unknown  Contributors: Bkcase, Smenck2,SmurawskiFile:P1_Scope_and_Con_SE_and_Eng_Sys_Proj_LF_BB.jpg  Source: https://www.sebokwiki.org/d/index.php?title=File:P1_Scope_and_Con_SE_and_Eng_Sys_Proj_LF_BB.jpg  License:unknown  Contributors: Smenck2, SmurawskiFile:NASA Image Part 1.png  Source: https://www.sebokwiki.org/d/index.php?title=File:NASA_Image_Part_1.png  License: unknown  Contributors: Smenck2, SmurawskiFile:P1_EconValueSE_RiskBalancedfig2_BB.jpg  Source: https://www.sebokwiki.org/d/index.php?title=File:P1_EconValueSE_RiskBalancedfig2_BB.jpg  License: unknown  Contributors:Smenck2, SmurawskiFile:SEBok SBD Figure1.gif  Source: https://www.sebokwiki.org/d/index.php?title=File:SEBok_SBD_Figure1.gif  License: unknown  Contributors: -File:SEBok SBD Figure2.gif  Source: https://www.sebokwiki.org/d/index.php?title=File:SEBok_SBD_Figure2.gif  License: unknown  Contributors: -File:SEBok SBD Figure3.gif  Source: https://www.sebokwiki.org/d/index.php?title=File:SEBok_SBD_Figure3.gif  License: unknown  Contributors: -File:SEBok SBD Figure4.gif  Source: https://www.sebokwiki.org/d/index.php?title=File:SEBok_SBD_Figure4.gif  License: unknown  Contributors: -File:SEBoK_SBD_Figure5.jpg  Source: https://www.sebokwiki.org/d/index.php?title=File:SEBoK_SBD_Figure5.jpg  License: unknown  Contributors: -File:MBSE Trends Figure 1.png  Source: https://www.sebokwiki.org/d/index.php?title=File:MBSE_Trends_Figure_1.png  License: unknown  Contributors: -File:MBSE Trends Figure 2.png  Source: https://www.sebokwiki.org/d/index.php?title=File:MBSE_Trends_Figure_2.png  License: unknown  Contributors: -File:MBSE Trends Figure 3.png  Source: https://www.sebokwiki.org/d/index.php?title=File:MBSE_Trends_Figure_3.png  License: unknown  Contributors: -File:MBSE Trends Figure 4.png  Source: https://www.sebokwiki.org/d/index.php?title=File:MBSE_Trends_Figure_4.png  License: unknown  Contributors: -File:MBSE Trends Figure 5.png  Source: https://www.sebokwiki.org/d/index.php?title=File:MBSE_Trends_Figure_5.png  License: unknown  Contributors: -File:MBSE Trends Figure 6.png  Source: https://www.sebokwiki.org/d/index.php?title=File:MBSE_Trends_Figure_6.png  License: unknown  Contributors: -File:MBSE Trends Figure 7.png  Source: https://www.sebokwiki.org/d/index.php?title=File:MBSE_Trends_Figure_7.png  License: unknown  Contributors: -File:MBSE Trends Figure 8.png  Source: https://www.sebokwiki.org/d/index.php?title=File:MBSE_Trends_Figure_8.png  License: unknown  Contributors: -File:SE Core Concept Relationships.PNG  Source: https://www.sebokwiki.org/d/index.php?title=File:SE_Core_Concept_Relationships.PNG  License: unknown  Contributors: BkcaseFile:SE Core Concept Relationships Example.PNG  Source: https://www.sebokwiki.org/d/index.php?title=File:SE_Core_Concept_Relationships_Example.PNG  License: unknown Contributors: BkcaseFile:Core SEBoK Concepts.PNG  Source: https://www.sebokwiki.org/d/index.php?title=File:Core_SEBoK_Concepts.PNG  License: unknown  Contributors: Bkcase