Systems Engineering Handbook Research Articles

SYSTEM REVISITED – AGAIN

AbstractThis paper reviews the revised foundational definitions of system and systems engineering in the recently published (2023) fifth edition of the INCOSE Systems Engineering Handbook. The new INCOSE definitions derive from an earlier INCOSE Fellows' Initiative on System and Systems Engineering Definitions that began in 2016 and finally reported in 2019. After introducing the concept of system and reviewing the new definition, the paper concludes that the concept, not rooted in a single science or exemplar domain, is so pervasive as be a meta‐concept that does not have a dominant scientific definition. It proposes further work towards a more scientific definition of an engineered or artificial system – the primary interest of INCOSE – at a lower level of abstraction.While the authors define systems engineering functionally as a process or approach, we see the essence of systems engineering as abstraction. Using the more accepted metaphysical distinction between the real, virtual, and abstract, we define the output of systems engineering as an abstract (simplified symbolic) representation or model that is the basis for defining the real; firstly, the virtual representation of something not (yet) existing physically but made to appear so and, finally, the physical. Thus, we position systems engineering as the abstract phase within a three‐phase abstract‐virtual‐physical engineering design and realization process.

Systems Architecture Meta‐Model for the MagicGrid Framework

AbstractAlthough Model‐Based Systems Engineering (MBSE) might be understood and applied across diverse communities and industries differently, its fundamental principles and practices described in INCOSE Systems Engineering Handbook, are common. It is known that successful application of MBSE is impossible without a tool, language, and method as well as harmony among these three. The de‐facto standard modeling language for MBSE is Systems Modeling Language (SysML). However, SysML is only a language, and it is not aligned with terminology systems engineers use daily in their work. This paper studies SysML as the standard language to model systems, and MagicGrid as the framework to bridge the gap between Systems Engineering (SE) terminology described in the INCOSE Systems Engineering Handbook and SysML specification. It proposes a new systems engineering meta‐model to describe a common SE terminology and bind it to the SysML concepts.

How INCOSE's Certification Program has Evolved as a System of Systems

AbstractThe International Council on Systems Engineering (INCOSE) Certification program began as a subsystem of INCOSE, with only a few external entities involved. The majority of the required capabilities were carried out internally, such testing based on the INCOSE Systems Engineering Handbook. Many capabilities have since been outsourced to independent external agencies such as psychometricians and certificate providers to gain flexibility and simplify operations. As a result, the INCOSE certification program evolved from an INCOSE subsystem to a System of Systems (SoS) with component systems such as universities, exam providers, training providers, and local chapters. This paper discusses the characteristics and challenges of the INCOSE Certification program as a System of Systems, the type of a SoS that best suits the certification program, change management of the certification program, learnings from managing the certification program as a System of Systems, the System of Systems engineering application to the certification programs, and critical problems involved in the certification program's operation and management.

Human Factors in the Systems Engineering Jungle

EXTENDED ABSTRACT As holistic thinking goes, the effects of the system on the human are well-known in the HFES community. However, many practitioners have experienced the challenges of incorporating these effects into a life cycle approach. Systems engineering seeks to model, predict, and employ holistic thinking in the development of multi-part and complex systems (NASA Systems Engineering Handbook). It is posited that a systemic approach and integration of human factors (HF) would better streamline various process pieces, thus reducing life cycle costs and risks to system and human functionality in the deployed system. Systems engineering processes and human factors philosophies have run parallel and intersecting courses, but rarely are they well-integrated. Despite the demonstrated impact of consideration on operators and users early in the design process for the reduction of system life cycle costs, and on increased adoption of systems by those users – few resources and tools exist that allow practitioners to translate human factors principles into Systems Engineering. These same practitioners are often called upon as experts within a systems development process. Limited participation on integrated product teams (IPTs), constrained and niche issue studies, and late life cycle validation all contribute to the challenges of holistic system integration, eventually passing frustration on to the users. The recent introduction of Human Readiness Levels (HRLs), which provide corresponding metrics to the well-established Technology Readiness Levels (TRLs), is one critical tool that will be faciliatory for appropriate consideration of human capabilities and limitations as part of system design (ANSI- HFES 400-2021). Tools like these that can become standard practices will be invaluable for inclusion of the human element into programs of record. However, in many instances, the practical considerations of conducting engineering design are often left to the individual practitioner to figure out. While many academic resources highlight the importance of including HF into system design and development, few resources exist to support in-the-trenches development efforts. In addition, communication of the value of human systems engineering across disciplines is consistently and persistently a challenge and incorporated as part of project contracts and plans to only a limited extent. This panel explores the issue, tales from the jungle, and success stories from multiple points of view, including practitioners of Human Factors, Systems Engineers, and Academics.

The ISO‐15288 technical processes, system maturity, and conceptual gaps

AbstractISO 15288 and the INCOSE Systems Engineering Handbook define technical (and other) processes but do not really explain why we need all of them. This paper formalizes the technical processes specifically in terms of the changes in maturity that each enacts and why these particular changes are necessary. This in turn clarifies the need for each process and places the processes on a sound philosophical footing.

Issues in Requirements Specification in Malaysia’s Public Sector: An Evidence from a Semi-Structured Survey and a Static Analysis

Requirement specifications (RS) are essential and fundamental artefacts in system development. RS is the primary reference in software development and is commonly written in natural language. Bad requirement quality, such as requirement smells, may lead to project delay, cost overrun, and failure. Focusing on requirement quality in the Malaysian government, this paper investigates the methods for preparing Malay RS and personnel competencies to identify the root cause of this issue. We conducted semi-structured interviews that involved 17 respondents from eight critical Malaysian public sector agencies. This study found that ambiguity, incompleteness, and inconsistency are the top three requirement smells that cause project delays and failures. Furthermore, based on our static analysis, we collected the initial Malay RS documents from various Malaysian public sector agencies; we found that 30% of the RS were ambiguous. Our analysis also found that respondents with more than 10 years of experience could manually identify the smells in RS. Most respondents chose the Public Sector Application Systems Engineering (KRISA) handbook as a guideline for preparing Malay RS documents. Respondents acknowledged a correlation between the quality of RS and project delays and failures.

The Emergent Properties of an Ethical Leadership When Aligned with the Systems Engineering Handbook and Code of Ethics

ABSTRACTIt is not easy to define leadership and the characteristics a leader must have. Some authors prefer one or another skill, but definitions are diverse. Some sources try to indicate what it means and its implications. A holistic ethical leadership model cannot be defined circularly, but it must be understood, such as a praxis.Leadership means more than its common definition; it means truth, ethics, empathy, and much more. In this case, it is of importance the definition of leadership, and in particular the ethical leadership. Also, the role of the leader is important, their education, their skills, and their influence.The need for ethical leadership in systems engineering is essential to be highlighted. The Code of Ethics of INCOSE and the Handbook do not merge the concept of leadership and ethics. That is why it is vital to show the need for alignment among both documents in terms of ethical leadership. Also, an explicit reference to this concept is needed in both documents because leadership needs to be honest, and ethics is a role to provide it.In this paper, we analyze the definitions found in the current INCOSE Code of Ethics and INCOSE Handbook regarding ethical leadership, its implications, and its application is explained and aligned to the ethical systems engineering idea. Also, examples of ethical behavior will be introduced to explain emergent properties. It will exemplify that applying ethical leadership will work in favor of the development of successful systems.

The SE Handbook: What Does It Mean to Me? A Proposal to Improve the Practical Application of the SE Handbook

AbstractThe INCOSE systems engineering (SE) handbook (Haskins, 2015) has served our discipline well for the years of its application. The authors foresee the future applicability of the contents in section 1.1 Purpose where it defines the discipline and practice of systems engineering (SE) for students and practicing professionals alike. The SE Handbook provides an authoritative reference to understand the SE discipline in terms of content and practice. Additionally, section 1.2 Application describes, while being consistent with the ISO/IEC/IEEE 15288, the handbook further elaborates on the practices and activities necessary to execute the processes, and that it is recommended that the tailoring guidelines in chapter 8 be used.With the strong baseline of defined systems engineering, Chapter 8 of the handbook addresses the Tailoring Process and Application of Systems Engineering. As of now, only 18 of the 290 handbook pages (6.2%) are dedicated to the tailoring process and applied tailoring. Section 8.2, Tailoring for Specific Product Sector or Domain Application is only afforded 5 pages (1.7% of the handbook total). The planned update of the INCOSE SE handbook offers an opportunity to enhance the practical application of the SE handbook. This paper reviews the current SE handbook structure, proposes an envisioned solution, provides a proof of concept, and discusses the recommended adjustments using a holistic systems engineering approach.

The INCOSE‐PPI Systems Engineering Tools Database – What's Coming

AbstractThe Systems Engineering Tools Database (SETDB) project is a collaboration between INCOSE and Project Performance International (PPI) to reinstate and revive the popular on‐line catalogue of tools information that was lost in a migration activity several years ago. “Walking the talk”, the project team has of course taken a systems engineering (SE) approach comprising thorough, and separate, problem definition and solution description artefacts. Thus far, a rigorous system requirements analysis activity has produced a detailed set of SETDB use cases, a description of intended use (OCD/CONUSE) and a baselined specification of requirements – all developed in close collaboration with INCOSE and PPI stakeholders. The products of that activity are presented in detail in this paper.One of the points of emphasis during development is to distinguish between the SETDB enterprise system – which comprises all that is entailed in providing the database service to its users, including computing devices, the INCOSE website, the internet, operational processes and project infrastructure – from the SETDB Information System. The SETDB Information System (SETDBIS) is the main technical solution element of the project and will exist as a subsystem of the larger SETDB system. Making this distinction ensures that all of the elements necessary to meet the SETDB stakeholder needs are identified and included in the development.The next step of the project is to use the outputs from the requirements analysis process as directives to develop the SETDB solution to deliver its initial operational capability (IOC) within the allotted project timelines. An incremental development process for the information system has been decided upon, to enable iterative improvement based on feedback from testing and demonstration to users. Mapping and alignment of the INCOSE SE Handbook Processes and PPI SE process elements to tool functionality in order to define the tool categories is a critical and challenging task. The effort to map and harmonize (where possible) systems engineering methods supported by tool functionality will result in intuitive delivery of detailed tool information to SETDB users.

The Drone System II: Availability Performance Analysis and Modeling

AbstractThis paper is the second of two papers that together provide an example of how to use the systems engineering processes outlined in the INCOSE Systems Engineering Handbook and ISO/IEC/IEEE 15288:2015 to develop a SysML system architecture from a user's statement of need and then to develop a mathematical system model for system reliability, availability, and maintainability that may be used to perform system design and cost‐effectiveness trade‐off analyses. This paper focuses on the development of an analytic Markov model that may be used to determine the operational availability that results from alternative designs for the drone system described in the first paper and the use of this model to perform a design performance analysis and a design trade‐off analysis. It also compares the results of this analytic stochastic model to a simple deterministic model.

The Drone System I: Context‐Level Architecture

AbstractThis paper is the first of two papers that together provide an example of how to use the systems engineering processes outlined in the INCOSE Systems Engineering Handbook and ISO/IEC/IEEE 15288:2015 to develop a SysML system architecture from a user's statement of need and then to develop a mathematical system model for system reliability, availability, and maintainability that may be used to perform system design and cost‐effectiveness trade‐off analyses. This paper focuses on the development of a SysML architecture for a drone system that provides surveillance and delivery services.

Value Engineering as a Specialty for Systems Engineering: Exploring Opportunities

ABSTRACTValue Engineering is a so‐called specialty engineering activity within Systems Engineering according to the INCOSE Systems Engineering Handbook [INCOSE, 2015], but what makes Value Engineering a ‘specialty,’ and what can it offer Systems Engineers? In this article three Value Engineering concepts are described, which are the pillars of Value Engineering: 1) the definition of value, 2) the use of multi‐disciplinary workshops, and 3) the application of function diagramming with the FAST method. Each of these concepts is explained and ideas are put forward how to incorporate them in more commonly used Systems Engineering processes. Our findings show that Systems Engineering and Value Engineering are not mutually exclusive, but offer outstanding concepts to improve designers’ goals. With this article, we hope to inspire the Systems Engineering and Value Engineering communities to further explore and experiment together.

Trade‐off Analytics: Creating and Evaluating the Tradespace

ABSTRACTThe INCOSE Corporate Advisory Board documented the need for a guidebook on best practices for trade studies. They wanted a book that covered the system lifecycle and aligned with INCOSE process guidance (ISO/IEC 15288, Systems Engineering Handbook, and the “Systems Engineering Body of Knowledge”). The INCOSE Decision Analysis Working Group supported the book project. Members of the Decision Analysis Working Group began by writing the decision management sections of the Systems Engineering Handbook and the “Systems Engineering Body of Knowledge” (SEBoK). We decided to develop a textbook in the Wiley Systems Engineering and Management Series to meet this need (note: the authors provide all proceeds from sale of the textbook directly to the INCOSE Foundation). Our goal was to describe and illustrate sound trade‐off analysis techniques to identify value and risk to help decision makers make the necessary trade‐offs to provide affordable systems that meet performance and schedule objectives. We recruited sixteen leading systems engineering experts with significant academic and industry experience. The textbook audience is undergraduate students (systems engineering, industrial, engineering management, other engineering); graduate students (systems, industrial, engineering management, other engineering); and professional systems engineers, project managers, and engineering managers. The textbook can also be used as a professional reference. Wiley offers a 25% discount to INCOSE Corporate Advisory Board members.

I Don't Need Requirements – I Know What I'm Doing! Usability as a Critical Human Factor in Requirements Management

AbstractThe INCOSE Systems Engineering Handbook Version 4.0 lists the word “process” 1,597 times, yet the word “people” only 65 times. This paper argues that human aspect (people) considerations are similarly underrepresented in requirements management (RM), and that RM focuses mainly on processes and products (tools). This is also reflected in the ISO/IEC/IEEE 29148:2011 abstract that refers to “provisions for the processes and products related to the engineering of requirements …”. The paper makes the case that due to the lack of human aspect considerations many requirements specifications do not meet the definition of usability, where requirement specification users can achieve their objectives with effectiveness, efficiency, and satisfaction.The consumer behavior theory suggests that if (requirements specifications) consumption is made too difficult, then consumers will want to move on to things they actually find satisfying (e.g. design, implementation, testing). By providing requirements specifications that are not readily usable to consumers, an additional processing burden is placed on them, and consumers might succumb to the temptation to cut the requirements analysis phase short. Combined with overconfidence, this may result in requirements consumers to move on, stating: “I have done this before. I don't need requirements. I know what I'm doing!”. This paper will identify the underlying root cause, and propose a method to introduce usability into the requirements management process, making the process more practical and convenient for the requirements consumer, and as a result, achieve better project performance.

Overview of an Emerging Standard on Architecture Processes – ISO/IEC 42020

AbstractA new, emerging standard on architecture practices is under development as ISO/IEC 42020. This paper provides an overview of the key concepts in this standard and the rationale for these ideas. The standard defines six architecture‐related processes: governance, management, conceptualization, evaluation, elaboration, and enablement. These are comprised of 37 activities, having five to eight tasks specified for each activity. It is expected that these processes will be incorporated into the next version of INCOSE's Systems Engineering Handbook and in the Guide to the Systems Engineering Body of Knowledge. This standard can be used as a foundation for organizational training and guidebooks on architecture management and development.

Leveraging tradeoff, bridging the gap among disciplines

AbstractThe systems analysis process builds on decisions rooted in results from quantitative tradeoff studies. A consensus on its activities is widely shared and documented by norms and handbooks: ISO/IEC/IEEE 15288:2015, INCOSE Systems engineering handbook.2015 and NASA handbook.2007. Nonetheless, the development of methodologies supporting traceability between the systems analysis process and the other systems engineering processes is still an open area of research, especially within the framework of model‐based approaches. As a result, documents justifying architecture choices are still produced by consolidating data manually; and what is more, data evolution is also verified manually. Such time‐consuming tasks have no real added value but are potential sources of error. Tooling the capitalization of the tradeoff data—including the rationales based on parameter values and their evolutions from project milestone to project milestone—would significantly facilitate the production and integrity of the documentation of architecture justification. This article reports on the results of our research in this direction.

Defensibility: Legal Liabilities of Acts and Omissions in the Practice of Systems Engineering

AbstractSystems Engineers assigned to projects spend a majority of their time on technical and technical management processes. In order to produce balanced system solutions, systems engineers rely on specialty engineering activities (informally known as the “ilities” because many of them end in “ilty”) to trade performance requirements with non‐functional requirements (also known as quality attributes). The INCOSE Systems Engineering Handbook Fourth Edition (INCOSE, 2015) lists 14 “ilities” including affordability, reliability, and usability.This paper introduces defensibility, an additional “ility” that attempts to balance the legal aspects of the system and its development effort. Professional legal liabilities stem from two primary sources: acts and omissions. Breaches of acts arise when an activity has been done, but it was done poorly or an improper action was taken based on the situation. Breaches of omissions arise when an activity was not done that should have reasonably been done under the circumstances. This paper explores both of these liabilities in the context of systems engineering and provides practical advice on how individuals and companies can better protect themselves. This paper is an attempt to show practitioners how defensibility may play a role in their designs and how they may be drawn into the adjudicatory process around disputes over their work or the work of others.

The Path to Version 0.75 of the Proposed INCOSE Systems Engineering Competency Framework

AbstractThis paper describes the efforts and results so far to evolve the INCOSE Competency Framework to the next stage: Version 0.75. This paper describes how the proposed framework has been aligned with a number of other frameworks, competency models, bodies of knowledge and initiatives. These include but are not limited to the DoD's Better Buying Power 3.0 Implementation Plan, the Defense Acquisition University Competency Model, the US Navy's Systems Engineering Competency Career Model, the new INCOSE Systems Engineering Handbook Fourth Edition and the Systems Engineering Professional Certification Program. This paper also describes current efforts to develop an initial draft Role Definition Guide that will describe the typical roles that systems engineers may assume. The paper concludes by exploring all the remaining coordination activities and other actions required to successfully develop and publish Version 0.75 and eventually Version 1.0.

Architecture Definition ‐‐ A New Process in the ISO International Systems Engineering Standard

AbstractThe ISO international standard on systems engineering practices has lacked a process for architecture definition that was separate from the process for system design definition. It had a process called architectural design, which was not deemed to properly cover the full purpose and scope of architecture definition. There were a number of reasons why architecture and design needed to be separated into different processes in the standard. This paper provides the reasons for this approach and describes the new Architecture Definition process in the updated standard that was published in 2015. It is expected that this process will be incorporated into the next version of INCOSE's Systems Engineering Handbook and in the Guide to the Systems Engineering Body of Knowledge.

Exploring the Role of Design in Systems Engineering

AbstractThe paper explores the role of design in systems engineering. It reviews the treatment of design in systems engineering in general and in the Systems Engineering Handbook in particular, and concludes that design is the missing dimension in systems engineering. It provides a review of salient viewpoints from research in design that can enhance the understanding of the design dimension in system engineering.