Preface

This book is meant to be a basic text for courses in the engineering design of systems at both the upper-division undergraduate and beginning graduate levels. The book is the product of many years of consulting on numerous portions of the system development process, research into the use of systems engineering in industry, and six years of developing a course on the engineering design of systems. During the development of this book, I found that many engineers did not understand systems engineering. Even those who do may not have a good perspective on a complete and unified process for engineering a system. The desire to suppress the number of decisions being made during design is quite strong in most engineers. While engineers have learned modeling throughout their academic lives, and most have developed models during the practice of engineering, very few engineers working on systems are knowledgeable of the modeling techniques required in systems engineering. In addition, most engineers are not aware of methods for using models during the systems engineering process. As a result, I adopted the following themes in formulating this book:

1. Defining the design problem in systems engineering is one of several keys to success and can be approached systematically using engineering techniques.
2. The design problem in systems engineering is defined in terms of requirements. These requirements evolve from a high-level set of mission and stakeholders’ requirements to detailed sets of derived requirements.
3. The design process will fail if the requirements are defined too narrowly, leaving little if any room for design decisions and raising the possibility that no feasible solution exists. The design problem should be well defined and decision rich.
4. For the design problem to be well defined, the evolving sets of requirements must be complete (none missing), consistent (no contradictions), correct (valid for an acceptable solution), and attainable (an acceptable solution exists). While it is not possible at this time to state requirements mathematically and prove these properties, it is possible to develop mathematical and heuristic representations of the design problem to assist in evaluating the presence of these properties.
5. These characteristics of the requirements will not be achieved if scenarios defining how the system will be used are not elaborated in detail, the interactions among the system and other systems are not defined, and the stakeholders’ objectives are not understood. Each of these requires a different kind of modeling to be successful.
6. The design problem is not likely to be well defined if the requirements do not address every relevant phase of the system’s life cycle.
7. The design problem is not likely to be well defined if the requirements do not contain stakeholder preferences for comparing feasible designs against each other.
8. The keys to understanding many of the modeling techniques for developing requirements, defining architectures, and deriving requirements are found in discrete mathematics: set theory, relations and functions, and graph theory.
9. Integration requires a well-defined design, including a design of the qualification process for verification, validation, and acceptance. A systematic process of design provides all the necessary inputs for defining the qualification process.
10. Early validation of the evolution of the definition of the design problem needs to be pursued vigorously to ensure that the definition of the design problem does not change as the problem is defined in greater detail.
11. Qualification of the system is the key issue in integration. Qualification includes verification and validation of both the requirements and the system design, followed by the stakeholders’ acceptance. There are many methods for qualifying the system; these methods must be chosen judiciously.

The successful qualification also requires that decisions about what should be tested be made in a systematic way that balances the two conflicting objectives of not wasting resources and obtaining stakeholder acceptance.

The above themes for the methods and models in this book are fundamental to the engineering of systems that have been validated in use beginning in the twentieth century CE and are independent of and realizable using the several systems modeling standards introduced in the twenty-first century CE including the Object Management Group (OMG) Systems Modeling Language (SysML®), ISO/PAS 19450 Object-Process Methodology (OPM), and the Lifecycle Modeling Organization (LMO) Lifecycle Modeling Language (LML).

The major changes for the fourth edition reflect the emphasis on SysML to visualize system models while still keeping legacy IDEF0 diagrams to visualize systems engineering process modeling. Chapter 1 was rewritten to address the updates that were made throughout the original chapters. As SysML2 becomes available as a standard and is implemented in software tools, the SysML diagrams in the book will be revised as SysML 2.0 diagrams and will be available on the Wiley companion website. The chapter on graphical modeling techniques was removed from the book but will still be available on the Wiley companion website for this book.

The book is divided into three major parts: (1) Introduction, Overview, and Basic Knowledge, (2) Design and Integration Topics, and (3) Supplemental Topics. The first part introduces the issues associated with the engineering of a system. Next, an overview of the engineering process is provided so that readers will have a context for the more detailed material. Finally, the basic knowledge needed for the core material is presented. Homework problems are provided at the end of each chapter.

Chapter 1 defines a system, systems engineering, the life cycle of a system and then introduces systems engineering processes. This material sets the stage for the details that follow.

Chapter 2 provides an overview of the details that are to come by presenting a number of basic concepts; these concepts include an operational concept, objectives, requirements, functions, items, components, interfaces verification, validation, and acceptance. The relations among these concepts are also addressed.

Chapter 3 provides an overview of modeling and the types of modeling needed in engineering systems. Modeling methods associated with SysML are then introduced and described. While IDEF0 is not part of SysML, this topic has been kept in Chapter 3 as an important part of the modeling concepts described in this book.

Chapter 4 presents basic discrete mathematics. The purpose of discrete mathematics is to demonstrate the mathematical rigor for which systems engineering must strive and to provide a language with which we can discuss key issues. Examples of such important concepts are the distinction between a relation and a function and why this is critical for engineering a system, a partition of the elements of a set that can be applied to many systems engineering concepts (e.g., requirements), and partial orders of functional execution.

Chapter 5 extends the discussion of discrete mathematics to graph theory, so that the graphical communication structures commonly used in the engineering of systems can be seen to have substantial problems as rigorous mathematical representations. On the other hand, the difficult concepts in Chapter 4 can be effectively represented with graphs for analysis and communication.

Part 2 covers the critical material required to understand the major elements needed in the engineering design of any system: requirements, architectures (functional, physical, and allocated), interfaces, and qualification.

Requirements development is approached as a systematic process in Chapter 6. This systematic process involves the definition of an operational concept of the system (including usage scenarios), a description of the involvement of the system with other systems, and an objectives hierarchy of the stakeholders across all phases of the system’s life cycle. A partition of requirements is employed to discuss the systematic approach to defining requirements.

Definitions of the functional, physical, and allocated architectures are provided as well as the detailed methods for developing these architectures in Chapters 7–9. Chapter 7 begins with several definitions that are needed to enable a meaningful discussion of the topic. The notion of a functional architecture is defined. An emphasis is placed on process modeling in Chapter 7. However, additional material is presented in Chapter 3 and the graphical modeling techniques on the companion website on data and behavioral modeling methods, as well as other approaches for process modeling. (This material can be used while discussing Chapters 7–9.) Modeling approaches for partitioning a function into segments are discussed. Key topics are feedback and control within the functional decomposition and evaluating the architecture for shortfalls and overlaps. Chapter 7 also addresses the functionality needed for error detection and recovery as well as tracing the input/output requirements to functions and items.

Chapter 8 introduces the distinction between generic and instantiated physical architectures. The morphological box is used to demonstrate the generation of multiple instantiated physical architectures. The graphical representation of the physical architecture is discussed along with notions of centralized, decentralized, and distributed...