The Engineering Design Of Systems - PDF Free Download (2024)

THE ENGINEERING DESIGN OF SYSTEMS

THE ENGINEERING DESIGN OF SYSTEMS MODELS AND METHODS Second Edition

DENNIS M. BUEDE

A JOHN WILEY & SONS, INC., PUBLICATION

Copyright r 2009 by John Wiley & Sons, Inc. All rights reserved. Published by John Wiley & Sons, Inc., Hoboken, New Jersey. Published simultaneously in Canada. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750 8400, fax (978) 750 4470, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748 6011, fax (201) 748 6008, or online at http://www.wiley.com/go/permission. Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and speciﬁcally disclaim any implied warranties of merchantability or ﬁtness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of proﬁt or any other commercial damages, including but not limited to special, incidental, consequential, or other damages. For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762 2974, outside the United States at (317) 572 3993 or fax (317) 572 4002. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com. Library of Congress Cataloging in Publication Data: Buede, Dennis M. The engineering design of systems: models and methods/Dennis M. Buede. 2nd ed. p. cm. (Wiley series in systems engineering and management) Includes bibliographical references and index. ISBN 978 0 470 16402 0 (cloth) 1. Systems engineering. 2. Engineering design. 3. System design. I. Title. TA168.B83 2009 620.001u171 dc22 2008022812 Printed in the United States of America 10 9 8 7 6

5 4 3

2 1

In memory of my Mother and Father

Contents

Preface Part 1 Chapter Chapter Chapter Chapter Chapter

Introduction, Overview, and Basic Knowledge 1 2 3 4 5

Introduction to Systems Engineering Overview of the Systems Engineering Design Process Modeling and SysML Modeling Discrete Mathematics: Sets, Relations, and Functions Graphs and Directed Graphs (Digraphs)

1 3 49 73 104 122

Part 2

Design and Integration

149

Chapter Chapter Chapter Chapter Chapter Chapter

6 7 8 9 10 11

151

Part 3

Supplemental Topics

Chapter 12 Chapter 13

Requirements and Deﬁning the Design Problem Functional Architecture Development Physical Architecture Development Allocated Architecture Development Interface Design Integration and Qualiﬁcation

Graphical Modeling Techniques Decision Analysis for Design Trades

211 252 284 319 341 373 375 401

vii

viii

CONTENTS

Appendix A: Outline of Systems Engineering Documents

451

Appendix B: IDEF0 Model of the Engineering of a System

455

Glossary

475

References

487

Historical References

499

Index

502

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 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 that do may not have a good perspective on a complete and uniﬁed 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 life, 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. Deﬁning 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 deﬁned 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 deﬁned too narrowly, leaving little if any room for design decisions and raising the possibility ix

PREFACE

6. 7.

10.

11.

12.

that no feasible solution exists. The design problem should be well deﬁned and decision rich. For the design problem to be well deﬁned, 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. The characteristics of the requirements will not be achieved if scenarios deﬁning how the system will be used are not elaborated in detail, the interactions among the system and other systems are not deﬁned, and the stakeholders’ objectives are not understood. Each of these requires a different kind of modeling to be successful. The design problem is not likely to be well deﬁned if the requirements do not address every relevant phase of the system’s life cycle. The design problem is not likely to be well deﬁned if the requirements do not contain stakeholder preferences for comparing feasible designs against each other. The keys to understanding many of the modeling techniques for developing requirements, deﬁning architectures, and deriving requirements are found in discrete mathematics: set theory, relations and functions, and graph theory. Integration requires a well-deﬁned design, including a design of the qualiﬁcation process for veriﬁcation, validation, and acceptance. A systematic process of design provides all of the necessary inputs for deﬁning the qualiﬁcation process. Early validation of the evolution of the deﬁnition of the design problem needs to be pursued vigorously to ensure that the deﬁnition of the design problem does not change as the problem is deﬁned in greater detail. Qualiﬁcation of the system is the key issue in integration. Qualiﬁcation includes veriﬁcation 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. Successful qualiﬁcation also requires that decisions about what should be tested be made in a systematic way that balances the two conﬂicting objectives of not wasting resources and obtaining stakeholder acceptance.

The major changes for the second edition are descriptions of The Object Management Group’s Systems Modeling Language (OMG SysMLt) and the introduction of new terminology. SysML is introduced in Chapter 1, deﬁned in

PREFACE

some detail in Chapter 3, and referenced in other chapters. The major changes in terminology were motivated by suggestions from readers to be less focused on speciﬁc application domains. Originating requirements has become stakeholders’ requirements. Originating Requirements Document has become Stakeholders’ Requirements Document. The operational architecture has become the allocated architecture. New material has been added in Chapter 1 to enhance the introduction of the engineering of systems. Additional material in Chapter 1 describes different types of systems and outlines the various attributes of the value provided by systems engineering. Minor changes have been made to several other chapters as well. Finally, I have added a large selection of historical references for systems engineering. The book is divided into three major parts: (1) Introduction, Overview, and Basic Knowledge; (2) Design and Integration Topics; and (3) Supplemental Topics. The ﬁrst part provides an introduction to 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, basic knowledge needed for the core material is presented. Homework problems are provided at the end of each chapter. Chapter 1 deﬁnes 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 veriﬁcation, 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 the 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 difﬁcult concepts in Chapter 4 can be effectively represented with graphs for analysis and communication.

xii

PREFACE

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 qualiﬁcation. Requirements development is approached as a systematic process in Chapter 6. This systematic process involves the deﬁnition 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 for deﬁning requirements. Deﬁnitions of the functional, physical, and allocated architectures are provided as well as the detailed methods for developing these architectures in Chapters 7 through 9. Chapter 7 begins with several deﬁnitions that are needed to enable a meaningful discussion of the topic. The notion of a functional architecture is deﬁned. An emphasis is placed on process modeling in Chapter 7. However, additional material is presented in Chapters 3 and 12 on data and behavioral modeling methods, as well as other approaches for process modeling. (This material can be used while discussing Chapters 7 through 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 the 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 architectures. Finally, fault-tolerant architectures are described. Chapter 9 deﬁnes the allocated architecture and discusses the allocation of functions to components, the tracing and derivation of requirements, the analysis of activation and control structures, and the conduct of various analyses (risk, performance, and trade-off). Chapter 10 characterizes interfaces; discusses the functions associated with interfaces in several contexts (communications systems and software design); describes interface architectures; and discusses interface design as it impacts system performance as part of the design process. Finally, qualiﬁcation of the system (Chapter 11) during integration requires the understanding of the stakeholders’ needs and the qualiﬁcation methods that are typically used. Deciding what to test and how to test it is critical in this phase of the development process. All of the topics in Chapters 6 to 11 are addressed in a rigorous and systematic manner, consistent with the general, practical application of systems engineering in industry. Homework exercises are provided on each of these topics from Part 2 for several real but simple systems that are familiar to all students: an automatic teller machine (ATM), an air bag, and the OnStar system of Cadillac. A case

PREFACE

xiii

study is available over the web to give the students a sample of the solutions to the homework. Readers are encouraged to access a limited version of a commercial system engineering software product (CORE) to enhance the conduct of these homework exercises and the educational mission of this book. Finally, two additional key topics are introduced in the third part: methods for data, process, and behavior modeling and decision analysis. Chapter 12 addresses the topics of data modeling, process modeling, and behavior modeling. Many alternate approaches for each of these modeling areas are described in detail so that teachers using this text can substitute the material most relevant to their program for the IDEF0 process modeling in Chapter 3. (A few minutes of IDEF0 instruction will be required in any course because of the extensive use that I have made of an IDEF0 model of the systems engineering process in Appendix B.) Chapter 13 presents the key topics of decision analysis as an integrative way of supporting the many decisions that are part of the design and integration of a system. These decision analytic topics include the development and quantiﬁcation of values (objectives, value functions, and trade offs), and the modeling of uncertainty regarding facts. The homework problems and the case study of the elevator are deﬁned with the express purpose of having the student demonstrate the level of understanding necessary to perform the engineering activities described in the book. In developing these homework exercises I have taken the position that demonstrating an ability to discuss how to do systems engineering is a necessary but not a sufﬁcient level of understanding. The CORE software (that is appropriate for use with this book is available via the web: http:// www.vitechcorp.com) takes the tedium out of performing these systems engineering activities as well as reinforcing the basic concepts behind the activities. The case material related to an elevator system can be downloaded from the following web site: http://www.theengineeringdesignofsystems.com. Many of the ideas for this book have originated with Alexander Levis. I have beneﬁted greatly from my conversations with him. Jim Long introduced me to much of the systems engineering process and has since provided many thoughtprovoking concepts and ideas since we ﬁrst met in 1991. Ron Howard guided me through the Ph.D. process and provided me with a wonderful foundation in decision analysis. This foundation in decision analysis is at the heart of the methods proposed in this hook. I have worked on several consulting over the last 20 years with Terry Bresnick; Terry’s comments and questions have helped shape much of my thinking on the application of decision analysis to the engineering design of a system. Andrew Sage has seen several drafts of the book and provided many very useful comments, including suggestions for its title. Many faculty members who taught from the ﬁrst edition have provided useful comments that led to improvements. Sanford Friedenthal and Abe Meilich were kind enough to review portions of the original manuscript when it was near completion. Both Sandy and Abe provided very valuable comments for improving the quality of the material

xiv

PREFACE

and its presentation. Sandy has given me a great deal of information and encouragement to include the SysML material in this second edition. Several colleagues at George Mason University and Stevens Institute of Technology have provided many useful comments and suggestions. I wish to thank Kathryn Laskey, William Miller, and Mike Pennotti. Several students and teaching assistants have contributed to sections of these notes. Cathy Brown provided a substantial extension of the requirements for the elevator case study. John Van Ormer extended the physical architecture of the elevator. Jahan Araghi extended my initial case study on the ATM as part of his Master’s project. Tong Zhang and Parham Pasha provided some examples on sets, relations, and graphs. Christine Salter provided extensive support in addressing topics that needed revision, developed solutions for homework problems, and provided solution material for the OnStar and ATM problems. Several student groups provided material on which the air bag case is based. Meg Giordana and Barry Liner provided extensive comments on the qualiﬁcation material. Tim Parker developed two case studies for use in Chapters 8 and 9: the FBI Fingerprint Identiﬁcation System and the WideArea Augmentation System of the Federal Aviation Administration. Steve Charbonneau provided interesting insights about state charts as part of his M.S. Thesis. The SYST 520 class at George Mason University during the spring of 1998 provided many extensive and useful comments on an early draft of the ﬁrst edition. I wish to thank all of these individuals, as well as many others with whom I have conversed on these topics, for stimulating me to complete this effort. One of the most difﬁcult aspects of writing this book has been to decide which material to include and which to leave out. There is still a great deal more to be said on the topics covered in this book and on some additional topics that were not included. More importantly, there is still a great deal more to discover, at least on my part. DENNIS M. BUEDE Reston, Virginia November 2008

Part

Introduction, Overview, and Basic Knowledge

Chapter

Introduction to Systems Engineering

1.1

INTRODUCTION

A system is commonly deﬁned to be ‘‘a collection of hardware, software, people, facilities, and procedures organized to accomplish some common objectives.’’ The stakeholders for the system hold these objectives. Never forget that the system being addressed by one group of engineers is the subsystem of another group and the supersystem of yet a third group. The objective of the engineers for a system is to provide a system that accomplishes the primary objectives set by the stakeholders, including those objectives associated with the creation, production, and disposal of the system. To accomplish this engineering task, the engineers must identify the system’s stakeholders throughout the system’s life cycle and deﬁne the objectives of all of these stakeholders. These objectives typically address the triad of cost, schedule, and performance — cheaper, faster, and better. A major characteristic of the engineering of systems is the attention devoted to the entire life cycle of the system. This life cycle has been characterized as ‘‘birth to death,’’ and ‘‘lust to dust.’’ That is, the life cycle begins with the gleam in the eyes of the users or stakeholders, is followed by the deﬁnition of the stakeholders’ needs by the systems engineers, includes developmental design and integration, goes through production and operational use, usually involves reﬁnement, and ﬁnishes with the retirement and disposal of the system. Ignoring any part of this life cycle while engineering the system can lead to sufﬁciently negative consequences, including failure at the extreme. In The Engineering Design of Systems: Models and Methods, Second Edition. By Dennis M. Buede Copyright r 2009 John Wiley & Sons, Inc.

INTRODUCTION TO SYSTEMS ENGINEERING

particular, developing a system that has not adequately addressed the stakeholders’ needs leads to failures such as the ‘‘highway to nowhere’’ near San Francisco, which was stopped by political pressure brought to bear by homeowners on the surrounding hills overlooking the bay. The view of the bay that these homeowners enjoyed and thought was an associated right of the property they owned would have been blocked by the highway. Similar commercial failures that did not consider the needs of the stakeholders in sufﬁcient detail include the personal computers IBM PC Jr. and the Apple LISA. This is not to say that the adherence to methods and models put forth in this book or any other will guarantee success or even the absence of failure. Rather the methods and models proposed here do attend to the entire life cycle of the system and provide a process that makes sense, can be tailored to various levels of detail as dictated by the complexity of the system being addressed, and attend to all of the details that many engineers during years of practice in systems engineering have determined to be useful. The concepts of design and integration are critical to the methods addressed in this chapter and the book. The word design is used by many professions (artists, architects, all disciplines of engineering) and is claimed by each. The American Heritage Dictionary [Berube, 1991] deﬁnes design as: de sign (di zin’) v. signed, -signing, -signs. tr. 1. To conceive in the mind; invent: designed his dream vacation. 2. To form a plan for: designed a marketing strategy for the new product. 3. To have a goal or purpose; intend. 4. To plan by making a preliminary sketch, outline, or drawing. 5. To create or execute in an artistic or highly skilled manner. intr. 1. To make or execute plans. 2. To create designs. n. 1. A drawing or sketch. 2. The invention and disposition of the forms, parts, or details of something according to a plan. 3. A decorative or artistic work. 4. A visual composition; pattern. 5. The art of creating designs. 6. A plan; project. 7. A reasoned purpose; intention. 8. Often designs. A sinister or hostile scheme: He has designs on my job. y

All but the third and eighth deﬁnitions for the noun usage will apply at various times during the course of this book. Design during the engineering of a system as discussed in this book is the preliminary activity that has the purpose of satisfying the needs of the stakeholders, begins in the mind of the lead engineer but has to be transformed into models employing visual formats in a highly skilled manner for success to be achieved. While this book addresses the engineering methods and models used during the design process, there is always an element of artistry that is required for the design process and the system to be successful. Integration brings all of the detailed elements of the overall design together through a process of testing (or qualiﬁcation) to achieve a valid system for meeting the needs of the stakeholders. Engineers of appropriate disciplines perform integration according to the speciﬁcations deﬁned by the design of the system’s engineers. The integration process involves testing or qualiﬁcation of both the elements of the system and the system itself to ensure that the system meets the ultimate needs of the stakeholders.

1.2

OVERVIEW OF THE ENGINEERING OF SYSTEMS

This chapter ﬁrst provides an overview of the issues and process associated with the engineering of a system. This overview addresses the phases of the system’s life cycle, describes the importance of performing the engineering of a system well, provides a deﬁnition for the engineering of a system, introduces the key process model for the engineering of a system called the Vee model, describes the richness of decisions that are inherent in the engineering process, and discusses the diversity of expertise required for this engineering process. Section 1.3 describes process models that have been adopted by the software engineering community. Architectures play a key role in the engineering of systems and are introduced next. Requirements, Section 1.7, play a major role in the engineering of a system because they serve the role of deﬁning the engineering design problem and capturing the key information needed to describe design decisions. The life cycle of the system is next examined in more detail. Finally, the Vee model for engineering a system is described in more detail. The key method addressed in this chapter is the process used to perform the engineering of systems. Supplementing this discussion of the engineering method are discussions of the key concepts needed to understand the method at an introductory level. This method is presented as a process model; models and modeling are discussed in detail in Chapter 3 so the reader is asked to accept the notion of the process discussion as a discussion of a model until more detail on models can be provided in Chapter 3.

1.2

OVERVIEW OF THE ENGINEERING OF SYSTEMS

The development process in systems engineering is commonly viewed [Forsberg and Mooz, 1992; Lake, 1992] as a decomposition (or design) process followed by a recomposition (or integration) process (see Sidebar 1.1). During the decomposition process, the stakeholders’ requirements are analyzed and deﬁned in engineering terms and then partitioned into a set of speciﬁcations (or specs) for several segments, elements, or components. It is critical that this design process be broad in perspective so that nothing is left out and every contingency is considered. Systems engineers must be ‘‘big picture’’ people. Depth is only achieved by much iteration through the design process, as many as are needed until the system’s speciﬁcations are sufﬁciently detailed for individual conﬁguration items (CIs) to be built or purchased. This design process deﬁnes what the system must do, how well the system must do it, and how the system should be tested to verify and validate the system’s performance. To do this the systems engineers must maintain a very clear focus on the objectives that the system’s stakeholders (users, owners, manufacturers, maintainers, trainers, etc.) have deﬁned for the system. One of many possible representations of the life cycle of a system is shown in Figure 1.1, beginning with the identiﬁcation of the need for the system and progressing through the retirement of the system. Some of the phases of the life

INTRODUCTION TO SYSTEMS ENGINEERING

Identification of Need

Production & Manufacturing

Concept Definition

Retirement Training

Preliminary System Design

System Integration

Deployment Operation Maintenance

Detailed Configuration Item Design

Refinement Time

FIGURE 1.1 Phases of the system life cycle.

cycle are accomplished in parallel, as the diagram tries to depict; exactly which phases occur in parallel depends upon the type of system, the organization, and the context. For additional detail see Driscoll [2007]. As shown in Figure 1.1, design includes the preliminary system design as well as parts of the identiﬁcation of need and concept deﬁnition. Parts of the identiﬁcation of need and concept deﬁnition include the development of a basic idea and the ﬁrst embodiment of the idea; these two initial activities are often called invention and are usually not part of the engineering of a system. Invention has a heavy technological and scientiﬁc focus. The last portions of the identiﬁcation of need and concept design phases, plus preliminary system design, address the initial or follow-on commercialization of the idea based upon a speciﬁc statement of stakeholders’ needs.

SIDEBAR 1.1 The term systems engineering dates back to Bell Telephone Laboratories in the 1940s [Schlager, 1956; Hall, 1962; fa*gen, 1978]. fa*gen [1978] traces the concepts of systems engineering within Bell Labs back to early 1900s and describes major applications of systems engineering during World War II. RCA used the ‘‘systems approach’’ during the research and development of the electronically scanned, black and white television [Engstrom, 1957]. In 1943 the National Defense Research Committee established a Systems Committee with Bell Laboratories support to guide a project called C-79, the ﬁrst task of which was to improve the communication system of the Air Warning Service. An unpublished chapter on systems engineering in the Bell system suggested that the ﬁrst use of the phrase ‘‘systems engineering’’

1.2

OVERVIEW OF THE ENGINEERING OF SYSTEMS

within the Bell system was in a memo in the summer of 1948. Systems engineering was identiﬁed as a unique function in the organizational structure of Bell Laboratories in 1951. Involvement in the earliest intercontinental ballistic missile (ICBM) program, starting with Atlas, is the most well-known of early systems engineering activities. Hall [1962] asserts that the ﬁrst attempt to teach systems engineering as we know it today came in 1950 at MIT by Mr. Gilman, Director of Systems Engineering at Bell. The ﬁrst book on Systems Engineering was written by Goode and Machol in 1957, titled System Engineering – An Introduction to the Design of Large-Scale Systems. Hall [1962] deﬁned systems engineering as a function with ﬁve phases: (1) system studies or program planning; (2) exploratory planning, which includes problem deﬁnition, selecting objectives, systems synthesis, systems analysis, selecting the best system, and communicating the results; (3) development planning, which repeats phase 2 in more detail; (4) studies during development, which includes the development of parts of the system and the integration and testing of these parts; and (5) current engineering, which is what takes place while the system is operational and being reﬁned. The RAND Corporation was founded in 1946 by the United States Air Force and created systems analysis, which is certainly an important part of systems engineering. The Department of Defense entered the world of systems engineering in the late 1940s with the initial development of missiles and missiledefense systems [Goode and Machol, 1957]. Paul Fitts addressed the allocation of the system’s functions to the physical elements of the system in the late 1940s and early 1950s [Fitts, 1951]. There is special bibliography at the back of the book devoted to historical references.

The products of the design process serve as the inputs to the hardware and software design of detailed conﬁguration item (CI) design. The CIs then reenter the systems engineering process during system integration for integration testing, veriﬁcation, and validation. Further adjustments to the design occur during the reﬁnement phase. The life-cycle phases associated with the engineering of the system are shaded in Figure 1.1. The term concurrent engineering simply means that the systems engineering process should be done with all of the phases (and their associated requirements) of the system life cycle in mind [Prasad, 1996]. This notion of concurrent engineering is a key concept addressed in this book. The importance of systems engineering is highlighted by examining a generally accepted relationship between the phases of the system life cycle

INTRODUCTION TO SYSTEMS ENGINEERING

and the commitment versus the incursion of costs. The time associated with the system’s life cycle is plotted on the x-axis; note the time increments are notional and should not be interpreted as equal to the relative length of the four stages being addressed. See Prang [1992] for an illustration based on computer boards. (Prang is also referenced in Scheiber [1995].) Figure 1.2 shows the major phases of the system life cycle on the horizontal axis. The curves represent the cost committed, based upon engineering design decisions, and the cost incurred, based upon actual expenditures. As can be seen, about 80% of the cost of the system is committed by the end of design and integration, while only about 20% of the actual cost for the system has been spent. Obviously, mistakes made in the front end of the system life cycle can have substantially negative impacts on the total cost of the system and its success with the users and bill payers. There have been many deﬁnitions of systems engineering put forward since the 1950s when systems engineering became a profession. Table 1.1 provides several of these deﬁnitions. There are two important trends to note over the 20-year span of these deﬁnitions. First, the role of management in the systems engineering process is made explicit in the deﬁnitions from the 1990s. Second, the three pillars of engineering success (cost, schedule, and technical

Cost 100% Cost Committed Cost Incurred

80%

60%

40%

20%

0% Conceptual Detailed & Preliminary Design & Design Integration

Construction or Production

Use, Refinement & Disposal

Time

FIGURE 1.2 Cost commitment and incursion in the system life cycle.

1.2

OVERVIEW OF THE ENGINEERING OF SYSTEMS

TABLE 1.1 Definitions of Systems Engineering Source Mil Std 499A, 1974

Sailor, 1990

Sage, 1992 Forsberg & Mooz, 1992 Wymore, 1993

Mil Std 499B draft, 1993

INCOSEa, 1996 a

Definitions of Systems Engineering The application of scientiﬁc and engineering efforts to: (1) transform an operational need into a description of system performance parameters and a system conﬁguration through the use of an iterative process of deﬁnition, synthesis, analysis, design, test, and evaluation; (2) integrate related technical parameters and ensure compatibility of all related, functional, and program interfaces in a manner that optimizes the total system deﬁnition and design; (3) integrate reliability, maintainability, safety, survivability, human, and other such factors into the total technical engineering effort to meet cost, schedule, and technical performance objectives. Both a technical and management process; the technical process is the analytical effort necessary to transform an operational need into a system design of the proper size and conﬁguration and to document requirements in speciﬁcations; the management process involves assessing the risk and cost, integrating the engineering specialties and design groups, maintaining conﬁguration control, and continuously auditing the effort to ensure that cost, schedule, and technical performance objectives are satisﬁed to meet the original operational need. The design, production, and maintenance of trustworthy systems within cost and time constraints. The application of the system analysis and design process and the integration and veriﬁcation process to the logical sequence of the technical aspect of the project life cycle. The intellectual, academic, and professional discipline the primary concern of which is the responsibility to ensure that all requirements for a bioware/hardware/software system are satisﬁed throughout the life cycle of the system. An interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and life cycle balanced set of system people, product, and process solutions that satisfy customer needs. Systems engineering encompasses: (a) the technical efforts related to the development, manufacturing, veriﬁcation, deployment, operations, support, disposal of, and user training for system products and processes; (b) the deﬁnition and management of the system conﬁguration; (c) the translation of the system deﬁnition into work breakdown structures; and (d) development of information for management decision making. An interdisciplinary approach and means to enable the realization of successful systems.

INCOSE is the International Council on Systems Engineering, a professional society of systems engineers. INCOSE’s definition of a system is an interacting combination of elements, viewed in relation to function.

INTRODUCTION TO SYSTEMS ENGINEERING

performance) from the 1970s evolve to concerns over the life cycle, namely concurrent engineering. The American Heritage Dictionary [Berube, 1991] deﬁnes engineering as: The application of scientiﬁc and mathematical principles to practical ends such as the design, construction, and operation of efﬁcient and economical structures, equipment, and systems.

The following deﬁnitions of engineering and the engineering of systems are adopted here: Engineering: discipline for transforming scientiﬁc concepts into cost-effective products through the use of analysis and judgment. Engineering of a System: engineering discipline that develops, matches, and trades off requirements, functions, and alternate system resources to achieve a cost-effective, life-cycle-balanced product based upon the needs of the stakeholders. Figure 1.3 shows the design and integration process as a ‘‘Vee’’ with the emphasis of this model of the engineering process for a system being on the activities that the engineers perform. The left or decomposition side of the Vee

Understand User Requirements, Develop System Concept and Validation Plan

Demonstrate and Validate System to User Validation Plan

Integrate System and Perform System Verification to Performance Specifications

Develop System Performance Specification and System Validation Plan

. . .

Expand Performance Specifications into CI “Design-to” Specifications and CI Verification Plan

Assemble CIs and Perform CI Verification to CI “Design-to” Specifications

Design Engineering

Inspect “Build-to” Documentation

Inte

n itio pos com nd a ion it fin

Evolve “Design-to” Specifications into “Build-to” Documentation and Inspection Plan

gra t an ion alif d icat ion

Systems Engineering

Fab, Assemble and Code to “Build-to” Documentation Time

FIGURE 1.3 Systems engineering ‘‘Vee’’ (after Forsberg and Mooz [1992]).

1.2

OVERVIEW OF THE ENGINEERING OF SYSTEMS

coincides with the three phases at the beginning of the life cycle from Figure 1.1. Time proceeds from left to right in Figure 1.3, just as it did in Figure 1.1. The process is initiated at the top left of the Vee with the deﬁnition of the operational need of the stakeholders. The focus of the decomposition and deﬁnition process (or design) is the movement from an operational need to system-level requirements to speciﬁcations for each component to the speciﬁcations (or specs) for each CI. Since time is moving from left to right in Figure 1.3, parallel work on high- and low-level design activities is not only permitted but encouraged. The iterative nature of this design process, from high-level issues such as stakeholders’ requirements to low-level issues such as component and CI design, is accomplished by moving vertically in the Vee over short increments of time. This vertical movement during the design process is critical to success and has been observed in studies of expert designers [Guindon, 1990]. Note, this Vee model does not emphasize the interaction with the stakeholders even though that interaction is assumed to occur in order to enable the engineering processes depicted in the Vee model. The horizontal line, drawn just under the middle intersection of the Vee in Figure 1.3, depicts the hand off of the ﬁnal products of the design process, the CI specs, to the discipline (or design) engineers, those engineers whose orientation is electrical, mechanical, chemical, civil, aerospace, computer science, and the like and whose job it is to produce a physical entity. This dividing line can be drawn higher or lower to signify decreasing or increasing overlap between design and integration activities. As the dividing line is drawn in Figure 1.3, the sloping lines of the middle portion of the Vee can be extended until they meet the dividing line, with the resulting very modest overlap between design and integration. If the dividing line is raised above the intersection of the sloping lines of the Vee, there would be no intersection of design and integration. This complete separation of design and integration is often sought in practice to enhance contractual relationships between procurer and supplier of the system; however, this separation negatively impacts the schedule and cost associated with the development of the system. There is signiﬁcant integration and qualiﬁcation activity that should take place during design, as is discussed in Chapter 11. In many systems engineering activities the horizontal dividing line between systems engineering and the discipline engineers is drawn signiﬁcantly lower than shown in Figure 1.3. The right-hand side of the Vee depicts the integration and qualiﬁcation activities of the engineering of a system. Integration involves the assembly of the CIs into components, the assembly of lower level components into higher level components, and the assembly of high-level components into the system. All of this assembly involves testing (or qualiﬁcation) of the newly assembled system elements to determine whether the assembled element meets the set of requirements (or spec) that the design phase had established for that element; this qualiﬁcation is called veriﬁcation. Finally, after the system is veriﬁed against the system requirements, the system must be validated. After validation, the stakeholders determine whether the system is acceptable. Naturally,

INTRODUCTION TO SYSTEMS ENGINEERING

TABLE 1.2 Racecar Example of Requirements and Tests Operational Need or Mission Requirements Partially Validated by Operational Test (Proven by Real World Experience) Win the Indianapolis 500

System Level Requirements Verified by System Level Tests

Component Level Requirements Verified by Component Level Tests

. Top speed of X mph.

. Engine horsepower of x

. Acceleration in all . Pretrial average speed of

215 mph. . Average speed in the ‘‘500’’ of 190 mph.

directions, ‘‘g g’’ space . Average standard pit time of Y sec.

Btu. . Body’s drag coefﬁcient

of y . Range per tank of gas of

z mi.

there are problems throughout this process that require modiﬁcations to be made either to the design of the elements of the system or to the requirements that were developed during design. Recall that time is running from left to right in Figure 1.3; the Vee process allows for the low level of veriﬁcation of CIs to be happening in parallel with some high-level validation and even acceptance activities. A sample of the movement from operational need to CI specs is given for a race car in Table 1.2. The ﬁrst column states the operational need or mission requirement: Win the Indianapolis 500. Associated with this need are stakeholders’ requirements concerning the pretrial average speed and the average speed during the race with the expected number of yellow ﬂags and pit stops (note the numbers in Table 1.2 are notional and are not accurate reﬂections of race conditions). System-level requirements can then be derived that are more meaningful during engineering. As an example, the key system-level requirement involves the g-g space of a vehicle [Milliken and Milliken, 1995]. Race cars, when driven by experienced drivers, are always changing velocity in speed or direction. (Recall that speed is the velocity you are traveling in your direction of travel. But when traveling around a curve, you also have a component of velocity perpendicular to your direction of travel.) Therefore the acceleration ability of the car in both longitudinal and lateral directions (see Fig. 1.4) is critical in the design process. Figure 1.4 portrays the g-g curve for a single car driven by three racers (charts a-c); the bottom right space (chart d) is the inferred g-g space of the vehicle. Finally, each of these system-level requirements is ‘‘ﬂowed down’’ to component-level requirements, such as the engine’s horsepower and the drag coefﬁcient of the body of the race car. (Note the true values of these parameters are closely guarded secrets of racing teams.) This process continues until the requirements for CIs are deﬁned, establishing a hierarchy of requirements, from mission or need down to the CIs. The system integration process starts during the decomposition and deﬁnition (or design) process. As part of design, the integration and qualiﬁcation

1.2

OVERVIEW OF THE ENGINEERING OF SYSTEMS

FIGURE 1.4 ‘‘g g’’ design region for a racecar (from Milliken and Milliken [1995]).

plans are developed. The purpose of qualiﬁcation is the veriﬁcation and validation of the system’s design. Veriﬁcation addresses the following question: Does the component, element, segment, or system meet its requirements, or have we built the component, y, system right? On the other hand, validation, which is often combined with acceptance testing, demonstrates that the system satisﬁes the users’ needs, or have we built the right system? Note, as veriﬁcation moves farther from the CIs and closer to the system, it is not possible to conduct enough testing to prove anything statistically. Demonstration is often

INTRODUCTION TO SYSTEMS ENGINEERING

the best that can be done. It is expected, though not desired, that there will be issues and problems that arise as part of this qualiﬁcation process. Decisions must be made concerning relaxation of requirements versus design changes to speciﬁc CIs and components. During the design phase, integration activities should be planned to maximize the effectiveness of qualiﬁcation within the resources and time available. These planned activities are then carried out during integration, with adaptations as needed. There should have been some thought given during design about what the most likely adaptations would be so that the integration phase has sufﬁcient, built-in ﬂexibility. To be successful the engineering design of systems must embrace the notion that many decisions are made during the development process. This is not a controversial position to take. However, adopting the notion that these decisions should be made via a rational, explicit process is not consistent with much of the current practice in the engineering of systems. Table 1.3 lists a sample of the many categories of development decisions. Chapter 13 provides a method for addressing these decisions. An important philosophical point in decision making is that decisions have to be made with the best information available at the time, realizing that the outcomes associated with the decision remain uncertain when the decision is made. Therefore, distinguishing between a good decision and a good outcome is important. The material in this book will also distinguish between the level of detail needed to make decisions in the engineering of a system and the level of detail needed to ensure proper implementation of the system’s components and CIs. In order to accomplish this difﬁcult job of engineering a system, people with many different specialties must be involved on the systems engineering team. The stakeholders are central to the success of this effort and need to be represented on the systems engineering team. Discipline engineers with knowledge of the technologies associated with the system’s concept are needed to provide the expertise needed for design and integration decisions throughout development. Discipline engineers not only come from traditional engineering ﬁelds such as electrical, mechanical, and civil but also from the social sciences to address psychological, informational, physical, and cultural issues. In addition, systems engineers who model and estimate system-level parameters such as cost and reliability fall in the category of discipline engineers. Analysts skilled in modeling and simulation, more and more of which is done on the computer rather than with scaled-down mock-ups of the system, are also important members of this team. Engineers skilled in the processes (or methods) of systems engineering form the nucleus of this collection of skills. These processes and associated models are the nucleus of this book. Finally, managers that are in charge of meeting cost and schedule milestones need to be present. These ﬁve disciplines are depicted in the Venn diagram in Figure 1.5. Sidebar 1.2 describes Joe Shea, who was hired by the National Aeronautics and Space Administration (NASA) in 1961 to take charge of systems engineering for the Ofﬁce of Manned Space Flight.

1.2

OVERVIEW OF THE ENGINEERING OF SYSTEMS

TABLE 1.3 Sample of Decisions Made during System Design Development Phase Conceptual Design

Examples of Decisions in Systems Engineering . Should a conceptual design effort be undertaken? . Which system concept (or mixture of technologies) should be

the basis of the design? . Which technology for a given subsystem should be chosen? . What existing hardware and software can be used? . Is the envisioned concept technically feasible, based on cost,

schedule and performance requirements? . Should additional research be conducted before a decision is

made? Preliminary Design

. Should a preliminary design effort be undertaken? . Which speciﬁc physical architecture should be chosen from . .

Full scale Design

. . . .

Integration and Qualiﬁcation

. . . . . .

Product Reﬁnement

. . . .

several alternatives? To which physical resource should a particular function be allocated? Should a prototype be developed? If so, to what level of reality? How should validation and acceptance testing be structured? Should a full scale deign effort be undertaken? Which conﬁguration items should be bought instead of manufactured? Which detailed design should be chosen for a speciﬁc component given that one or more performance requirements are critical? What is the most cost effective schedule for implementation activities? What issues should be tested? What equipment, people, facilities should be used to test each issue? What models of the system should be developed or adapted to enhance the effectiveness of integration? How much testing should be devoted to each issue? What adaptive (fallback testing in case of a failure) testing should be planned for each issue? Should a product improvement be introduced at this time? Which technologies should be the basis of the product improvement? What redesign is best to meet some clearly deﬁned deﬁciency in the system? How should the reﬁnement of existing systems be implemented given schedule, performance and cost criteria?

INTRODUCTION TO SYSTEMS ENGINEERING

Management Domain/ Stakeholders

SE Process Technology (Engineering Disciplines)

Modeling, Simulation, Analysis

FIGURE 1.5 Expertise required on the engineering team for a system.

SIDEBAR 1.2 ‘‘It was 1943 when he graduated (from high school), wartime, and Shea heard about a special Navy program that would send him to college. y Then the Navy sent him to M.I.T., and after that to the University of Michigan. y For the next several years Shea moved back and forth between Michigan, where he eventually obtained his engineering doctorate, and Bell Labs. It was an educational odyssey that took him from engineering mechanics to electrical engineering to theoretical mathematics to physics to inertial guidance. ‘‘The nouns change hut the verbs remain the same’’ became one of Shea’s sayings as he went from one specialty to another. Then in 1956 Shea found out how it all ﬁt together. At the age of twenty-nine, Shea was named systems engineer for the radio guidance project connected with the Titan I. ‘‘I didn’t know what ‘systems engineer’ meant,’’ Shea said, but he learned quickly, traveling around to the subcontractors on the Titan I, becoming a member of the small fraternity of engineers who were coming of age in this new ﬁeld. At night after work they gather at a bar near the plant where they had been working that day. They didn’t even drink that much, Shea recalled, they were so busy talking — about testing, grounding, vibrational spectrums, weights, stability, electrical interfaces, guidance equations, all the myriad elements of the system that some lucky guy, like a systems engineer, got to orchestrate. By 1959 Shea had acquired enough of a reputation within the ballistic missile fraternity for General Motors to hire him to run the advanced development operation for its A.C. Sparkplug Division, which was trying

1.3

APPROACHES FOR IMPLEMENTING SYSTEMS ENGINEERING

to wedge its way into the missile business. Shea was in charge of preparing a proposal for the inertial guidance contract for the Titan II. After the proposal won, Shea went back to administering the advanced development ofﬁce. But a year later, in September 1960, the contract he had won was six months behind and Shea was called away to rescue it. Shea began to discover that he had a knack for leading. His was not a gentle style, but if he was tough on people who fell short, he was generous and loyal to those who didn’t. y It didn’t make any difference what your specialty was. Shea’s maxim was that if you understood it, you could make him understand it — and once he did, you never had to explain it again. The only problem was keeping up. It was about this time that Shea discovered the uses of what he would come to call his ‘‘controlled eccentricity.’’ When he was still at Bell, his wife had bought him a pair of red socks as a joke. One day in a meeting he absent mindedly put his feet up on the table, getting some laughs and loosening up the meeting. So Shea started wearing red socks, not all the time, but to important meetings. Eventually the socks were accepted as a good-luck charm to wear to presentations. Even senior management at General Motors, where putting one’s feet on a desk was discouraged and wearing red socks was unthinkable, got used to the idea. y Armed with his red socks and his puns and an emerging sense of how good he was getting to be at this sort of engineering, Shea set out to rescue the lagging Titan contract. He moved into the plant, and for ﬁve days a week, all three shifts, he was there, catching catnaps on a cot set up in his ofﬁce. It was a pattern he would repeat later, during Apollo. The reasons were partly motivational — people work harder when they see the boss working all three shifts. ‘‘But it also lets you ﬁnd out everything that’s going on,’’ Shea said. ‘‘Things I’d ﬁnd out at night, I’d get corrected during the daytime.’’ Shea began handing out red socks as an award for good performance. His enthusiasm and energy were infectious. Shea pulled it off, making up the six months. [Murray and Cox, 1989, pp. 121–123].

1.3

APPROACHES FOR IMPLEMENTING SYSTEMS ENGINEERING

We have just provided a description of what happens inside the process associated with the design of an engineered system and are about to describe several approaches for organizing that process. But let us step back a minute to look at the bigger picture, as summarized in Figure 1.6. The system that we have been tasked to design exists in a broader system, called the meta-system. This meta-system contains other systems and is purposefully pursuing some objectives. There is likely a sustainment system that is part of this meta-system

INTRODUCTION TO SYSTEMS ENGINEERING

FIGURE 1.6 Characterizing the broader systems’ design problem (after Martin [2004]).

that is providing supplies and support to one or more of the systems that comprise the meta-system. Some group has identiﬁed a problem with the achievement of the objectives being attained by the meta-system and has tasked a development system (organization) to design a system that will replace or upgrade one or more of the systems in the meta-system. In order to understand how to design this new or upgraded system, the people in the development system must understand the meta-system or they will have little chance of success. Understanding the metasystem includes the interaction between the system to be replaced and other systems in the meta-system as well as the context or environment in which that meta-system operates. We will refer many times in this book to the creation of meta-system (or mission) requirements and an operational concept as approaches to achieving this understanding of the meta-system. At some later time, after the meta-system has gone through many changes for which the development system must be tracking and making adjustments, the designed system will be deployed and become an operational system within the changed meta-system ﬁrst studied. Not only will the context of the metasystem have changed but many of the systems inside the meta-system will have changed. In fact, there may well be other development systems working on some of these other systems in the meta-system, including the sustainment

1.3

APPROACHES FOR IMPLEMENTING SYSTEMS ENGINEERING

system. The introduction of the operational system may in fact introduce new problems into the meta-system. Such potential problems should be imagined as part of the development process and avoided or minimized via the design. A ﬁnal caution to the reader is that the development system (an organization of systems engineers and other engineers and experts) must design itself to have any chance of success. This design of the development system must emphasize adaptability to the inevitable change going on in the meta-system as described in Figure 1.6 as well as another meta-system in which the development system exists. The Traditional, Top-Down Systems Engineering (TTDSE) process has evolved from the 1950s. Software engineers have evolved several approaches, starting with a waterfall process, moving to spiral development and currently focused on object-oriented design. Object-oriented (OO) software design gained popularity in the early 1990s shortly after object-oriented programming languages became available. 1.3.1

TTDSE

TTDSE (described in the overview in Section 1.2 and shown in Figure 1.7) is a process for systems engineering that begins a thorough analysis of what the problem is that needs to be solved; this is usually done with an analysis of the current meta-system (the system of interest and its peers (external systems)) performing one or more missions for the primary stakeholders. The result of this analysis is a statement of the problem to be solved. Based on this statement of the problem to be solved, several potential, competing concepts for implementing the system of interest are deﬁned; this set of concepts should initially include a very broad range of ideas, some of which are relatively inexpensive while others are very expensive. Next there will be an analysis of the competing concepts, resulting in the selection of the most favorable concept for implementation. Note this analysis could really be many analyses. (This book does not address the problem deﬁnition and evaluation of concepts. This material is covered by most texts on problem solving for deﬁning the problem to be solved. See Checkland [1981], Klir [1985], and Warﬁeld [1990]. Decision analysis (Chapter 13) addresses the evaluation of concepts.) On the basis of this selection, an operational concept and system-level requirements are deﬁned for that solution concept. These two products (operational concept and system-level requirements) are a statement of the problem being solved. Next, a layered (or onion peeling) iterative process begins for creating an architecture, deriving requirements, and reﬁning the needed test system and associated data collection requirements. This layered process can have as many layers as are needed; the bottom layer addresses the conﬁguration items (CIs) that the discipline engineers will design. Each layer repeats the same process (deﬁned in detail in Chapters 6 to 10 of this book). Systems engineers commonly perform a great deal of analysis and modeling during each layer of this process; trade studies are often conducted to examine alternate ways to

INTRODUCTION TO SYSTEMS ENGINEERING

Meta-system analysis; Concept selection

System V,V &A

System Definition

n sig n De tio m iva ion ste Der finit Sy e A ents e D V& m ur V, eqie iect R rch A

Subsystem Definition

FIGURE 1.7

Component Definition CI Definition

System analysis; Upgrade selection

V, Re V&A Ar quir Te ch em sti n ite ctu ents g re Mo Adju dif stm ica en tio t n

Subsystem Verification Component Verification CI Verification

Discipline Engineering Design

Traditional, Top Down Systems Engineering (TTDSE).

proceed or solutions that optimize some objective (e.g., cost, reliability, weight) while minimizing the impact on all other objectives. Once the CIs have been designed and delivered for integration, the veriﬁcation, validation, and acceptance testing process begins. Each layer of the decomposition process is veriﬁed against the associated derived requirements. During the process requirements may be adjusted or the architecture and design of the system may be modiﬁed as needed. At the system level, validation against the concept of operations and acceptance testing (as deﬁned by the stakeholders) is conducted. Chapter 11 deﬁnes this process. If a positive result is obtained, the system is deployed and systems engineering continues by analyzing the usage of the system for needed modiﬁcation and selecting upgrades that will be implemented in the future. The actual upgrading of the system should follow the same process as deﬁned by the Vee-like structure in Figure 1.7. TTDSE is primarily a process for designing the many pieces of a system in such a way that many different organizations can be tasked to design one or several pieces and all of the pieces can be integrated easily and effectively to achieve the desired system. Other references for TTDSE are Blanchard and Fabrycky [1998], Hatley and Pirbhai [1988], Sage [1992], and Wymore [1993]. 1.3.2

The Waterfall Model of Software Engineering

One of the earliest concepts of the software engineering process was called the ‘‘waterfall’’ model by Boehm [1976], but introduced by Royce [1970]. The waterfall model (Fig. 1.8) is characterized by the sequential evolution of typical life-cycle phases, allowing iteration only between adjacent phases. The waterfall model is known and discussed throughout the software and systems engineering communities and was the basis for Military Standard 2167A for software development. The major problem with the waterfall process is that iteration between phases that are widely separated is all too common. 1.3.3

The Spiral Model of Software Engineering

The spiral model (Fig. 1.9), developed in the 1980s [Boehm and Papaccio, 1988] and then modiﬁed several times [Boehm, 1986, 1988], addressed the need to

1.3

APPROACHES FOR IMPLEMENTING SYSTEMS ENGINEERING

Systems Requirements

Software Requirements

Preliminary Design

Detailed Design

Coding and Debugging

Integration and Testing

Operations and Maintenance

FIGURE 1.8 Waterfall model.

shorten the time period between the users’ statement of requirements and the production of a useful product with which the users could interact. Too many systems and software implementations were being produced and rejected because the development life cycle took too long; valid requirements at the beginning the cycle were no longer valid at the time of delivery. In addition, new systems were degraded because the vestiges of learning about the system domain tainted the early designs. The spiral model has four major processes, starting in the top left of Figure 1.9 and moving clockwise: design, evaluation and risk analysis, development and testing, and planning with stakeholder interaction and approval. These four processes are repeated as often as needed. The radial distance to any point on the spiral is directly proportional to the development cost at that point. The spiral model views requirements as objects that need to be discovered, thus putting requirements development in the last of the four phases as part of planning. The early emphasis is on the identiﬁcation of objectives, constraints, and alternate

INTRODUCTION TO SYSTEMS ENGINEERING

Cumulative Cost Progress through phases Evaluate Alternatives; Identify and Resolve Risks Determine Objectives, Alternatives, and Constraints

Risk Analysis

Risk Analysis Risk Analysis

review

1st Prototype

Commitment Partition

2nd Prototype

3rd Prototype

Operational Prototype

Models Benchmarks Requirements Operational Simulations Plan Concept Software Requirements Detailed Development Software Design Requirements Plan Product Validation Design Code Integration Design Validation Unit Test and Test Plan and Verification Integration and Test Plan Next Acceptance Phases Test Develop and Verify Implementation Next Level Product

FIGURE 1.9

Spiral model.

designs. These objectives and constraints become the basis for the requirements in the fourth step. There is also a major emphasis on evaluation and risk analysis as part of the management activities. This management activity is to identify which requirements are most important to discover early in order to minimize problems associated with cost, schedule, and performance. The development effort is composed of prototyping activities, which provide mock-ups of the software or system that will enable the stakeholders to deﬁne their requirements. This third step ends with evaluation and testing. The fourth step involves documenting requirements gleaned from the intense prototyping interaction with the users during the current trip around the spiral and planning the next trip around the spiral. The number of iterations around the spiral is variable and deﬁned by the software or systems engineers. The ﬁnal cycle integrates the stakeholders’ needs into a tested and operational product. Shortly after the spiral model was introduced, various authors [e.g., Boar, 1984] spoke of rapid prototyping as a development process. The rapid prototyping process is meant to produce early, partially operational prototypes. The use of these operational prototypes by stakeholders generates new and improved requirements, as well as provides the stakeholders with increased functionality via early releases of the system. Thus one could view rapid

1.4

MODELING APPROACHES FOR SYSTEMS ENGINEERING

prototyping through the spiral process model in which the prototypes were partially operational. 1.3.4

Object-Oriented Design

OO design followed from object-oriented programming in the 1970s. OO design is a bottom-up process that begins by deﬁning a set of objects that need to be part of the system in order to achieve the system-level functionality desired. Objects are thought to be basic building blocks that can perform functions (methods) and contain information. Key properties of OO design are inheritance and information hiding. Inheritance means that a general object can be specialized by adding special characteristics; the specialized object will ‘‘inherit’’ all of the properties (methods and data) not overridden by the specialization. Information hiding means that an object does not need to know how another project is producing the information being sent to it, just what that information is. Systems engineers had referred to this idea as modularity for years. Besides being the basic building blocks of a system, objects are seen to promote reusability, testability, and maintainability. For more information see Ambler [1997].

1.4

MODELING APPROACHES FOR SYSTEMS ENGINEERING

Modeling techniques for designing systems were created as early as the early 1950s. These techniques addressed the connection of system components, the decomposition of system functions, and dynamic behavior of the system. The Uniﬁed Modeling Language (UML) was created by several of the OO gurus who had developed their own approaches to modeling and decided an integrated approach was needed. The US Department of Defense (DoD) Architecture Framework (DoDAF) was developed within the Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (C4ISR) community and then extended to all of DoD. The Object Management Group’s Systems Modeling Language (OMG SysMLt) was deﬁned using UML 2.0 and moves the TTDSE process towards a goal desired by many of a model-based version of systems engineering. 1.4.1

Modeling Approaches for TTDSE

The ﬁrst modeling approach of TTDSE was the block diagram. Each block represented a system component. Lines between the blocks represented the exchange of information, energy, or physical entities. Next, N-squared (N2) diagrams were created to capture a high level view of the ﬂow of information, energy and physical entities among the components at a given level of abstraction for the system (see Lano [1990]). Next, the N2 diagram was transformed to a functional perspective, the components being exchanged for

INTRODUCTION TO SYSTEMS ENGINEERING

major system functions. Function ﬂow block diagrams were then developed to capture the dynamics of the system’s behavior. Meanwhile, software designers were creating data ﬂow diagrams to model software systems. Manufacturing designers were creating the Structured Analysis and Design Technique (SADT) which was later transformed into Integrated Computer-Aided Manufacturing (ICAM) Deﬁnition or IDEF0. Data ﬂow diagrams, N2 charts, and IDEF0 diagrams all capture the same basic time-lapsed ﬂow of information, energy, and physical items among functions. State transition diagrams (or state machines) were developed and enhanced by several engineering disciplines to capture dynamic behavior; these techniques have been applied for some TTDSE efforts. Finally, Petri nets have been developed to model the dynamics of systems. Many TTDSE practitioners use some subset of these modeling techniques. All of these techniques are covered in later chapters of this book. 1.4.2

UML

UML is a speciﬁcation language for modeling objects that is approved by the Object Manage Group. UML 2 was adopted in 2004 and is often described as a graphical modeling language. Critical ideas underlying object-oriented modeling are multiple views at varying levels of abstraction, object, class, inheritance, and extensibility. All useful approaches to systems and software engineering use modeling approaches that enable modeling a system at multiple levels of abstraction. An object is a basic building block of OO programming that can receive messages, process data, and then send messages to other objects. An object can be viewed as a component or actor that has the resources to receive, process, and send data. A class in object-oriented terminology is a grouping of related variables or functions; this is a key to addressing a system at multiple levels of abstraction. Inheritance (now often called generalization) is the process of creating instances of a class based upon specializations of class parameters; this is often the key to software reuse. Extensibility is a way of extending the UML modeling language. For example, stereotypes permit extending elements of UML to a speciﬁc problem domain. UML 2.0 contains 13 different diagram categories that can be aggregated into three diagram types; see Table 1.4. Structure diagrams address those issues or elements that are part of the system being modeled. Concepts for structure diagrams include actor, attribute, class, component, interface, object, and package. Behavior diagrams examine the activities that must happen in the system being modeled. Behavior diagram concepts include activity, event, message, method, operation, state, and use case. Interaction diagrams (considered by some to be a subset of behavior diagrams) address the ﬂow of data and control among the elements in the system being modeled. Concepts for interaction diagrams include aggregation, association, composition, depends, and generalization (or inheritance). Some important ideas in UML are the use case diagram, which is a high level view of the use cases; the class diagram, which describes the relationship

1.4

MODELING APPROACHES FOR SYSTEMS ENGINEERING

TABLE 1.4 Diagram Types for UML 2.0 Structure Diagrams Class Component Composite structure Deployment Object Package

Behavior Diagrams Activity State Machine Use case

Interaction Diagrams Collaboration Communication Interaction overview Sequence diagram Timing

between structural elements of the system and the external domain; and a set of object diagrams that are more deﬁnitive than the class diagram about the structural elements of the system and their relationships over time. Sequence diagrams are a representation of scenarios or use cases, something that traces back decades. The key design elements are the software objects. The use case diagram and sequence diagrams deﬁne the requirements in a qualitative way; there are seldom any quantitative performance requirements and there are no non-functional requirements. Similarly, there is no top level functional analysis; each object contains operations that can be performed and data that can be used for those operations. UML is primarily a graphical modeling language for creating abstractions or generalizations so that the resulting software system will be more ﬂexible and adaptable. This UML process is more of a bottom-up design process in which the components of the software are derived from more speciﬁc software objects that are designed to be adapted from existing code or coded from scratch. Useful references on UML are Ambler [2004] and Eriksson and Penker [1998]. Software engineers believe the appropriate model of their design is the code itself so very little modeling and analysis is performed during this process.

1.4.3

DoDAF

The DoDAF provides three integrated views needed for a system architecture; each of the three views is composed of subviews using graphical, tabular, and textual descriptions. A data model is deﬁned that deﬁnes entities and relationships among the data elements that are part of these integrated views. This effort began in 1995, produced version 1 and 2 of the C4ISR Architectural Framework in 1996 and 1997 (respectively), and yielded version 1 of the DoDAF in 2003. The Ministry of Defence (MOD) of the United Kingdom and the North Atlantic Treaty Organization (NATO) have adopted similar architecture frameworks: MODAF and NAF, respectively. The three top-level views are operational, systems, and technical. The operational view addresses the organizational and human context in which the system will be utilized. The systems view switches to the physical and

INTRODUCTION TO SYSTEMS ENGINEERING

functional world, starting outside the system and moving inside the system. The technical view addresses standards and conventions. Each of three views has a number of products, which are subviews for that higher level view that capture a subset of the entities and relationships relevant to the view. It is important to conceive of the DoDAF as containing a central database of all the entities and relationships. Each product of each view is then a representation of a subset of that central database. The developers of the DoDAF strove to create a structure that would work for any type of system. Unfortunately, that produced a framework that is too complex and extensive for any speciﬁc system. References include Levis and Wagenhals [2000] and Dam [2006]. 1.4.4

SysML

There has been a push among some systems engineers for an approach to systems engineering that is less text-based and therefore more model-based. The arguments against text-based processing are its inefﬁciencies for ﬁnding errors and stress points, testing both performance and timing behavior in one or more competing designs, and providing actionable information for trade studies and design reviews. Ultimately, there is a need to examine performance issues and conduct tests before the ﬁrst prototype is completed. Software engineers, for the most part, seem to have no problem with waiting until the code is written to ﬁnd out that there are major timing and latency problems. Hardware has traditionally taken much longer to redesign so systems engineers prefer to get the bad news early. This emphasis has led to model-based systems engineering efforts, the most visible of which is SysML. SysML is a visual modeling language that was adapted from UML 2.0 and enhances the traditional top-down systems engineering process. SysML extends the modeling language of traditional, top-down systems engineering; this extension should make the traditional approach to systems engineering less prone to errors and more efﬁciently implemented. Table 1.5 shows which UML 2.0 diagrams have been dropped (strikethrough), adopted (new), or modiﬁed (modiﬁed) for SysML. The ﬁrst thing to notice in Table 1.5 is that there is a new column for requirements with a single diagram type. The column with the most changes is the ﬁrst column for structure diagrams. Here the class diagram has been renamed to capture two different concepts associated with the physical architecture: block deﬁnition and internal block connectivity of parts. A new diagram, the parametric diagram, was created for modeling performance. The package diagram was kept as is from UML 2.0. Within the category of behavior diagrams, the activity diagram has been modiﬁed while the state machine and use case diagrams have been kept as is. Finally, most of the interaction diagrams have been dropped; the only remaining interaction diagram is the sequence diagram. The implication of these changes is that SysML places much greater emphasis on behavior compared to interaction than UML does. These diagram concepts will be introduced in later chapters of this book.

1.5

INTRODUCING THE CONCEPT OF ARCHITECTURES

TABLE 1.5 Diagram Types for SysML Structure Diagrams

Behavior Diagrams

Interaction Diagrams

Requirement (new)

Class renamed to be Block Deﬁnition Internal Block Component Composite structure Deployment Object Package Parametric Design (new)

Activity (modiﬁed) State Machine Use case

Collaboration Communication Interaction overview Sequence diagram Timing

Requirement (new)

The real challenge for SysML (and every other model-based approach) is to include easily understood descriptions of the system design and the associated requirements for non-engineering stakeholders. References for SysML are Bock [2006] and Friedenthal et al. [2008]. 1.5

INTRODUCING THE CONCEPT OF ARCHITECTURES

Levis [1993] has deﬁned an analytical systems engineering process (for the left side of the Vee process) that begins with the system’s operational concept and includes the development of three separate architectures (functional, physical, and allocated) as part of this decomposition. The functional (or logical) architecture deﬁnes what the system must do (i.e., the system’s functions and the data that ﬂows between them). The physical architecture represents the partitioning of physical resources available to perform the system’s functions. The allocated architecture (see Fig. 1.10) is the mapping of functions to resources in a manner that is suitable for discrete-event simulation of the system’s functions and is analogous to Alford’s [1985] approach with behavior diagrams. Figure 1.10 suggests that the functional and physical architectures are developed independently of each other and then combined to form the allocated architecture. This suggestion is inaccurate; the two architectures are developed in parallel but with close interaction to ensure that the allocated architecture is meaningful when the functional and physical architectures are combined. Chapters 7, 8, and 9 address these three architectures and their development in detail and discuss the interactive development of them. Critical to this multiple-architecture approach is the balancing of information among them. Three separate models must be developed to be complete: data, process, and behavior models. The functional architecture includes the ﬁrst two (data and process) models and the initial behavioral model, as discussed in Chapter 7. The behavioral model should be ﬁnished and exercised as part of the allocated architecture; see Chapter 9. Each of these three models must be integrated to deﬁne the three architectures properly.

INTRODUCTION TO SYSTEMS ENGINEERING

Operational Concept

Functional Architecture

Physical Architecture

Allocated Architecture

FIGURE 1.10 [1993]).

Architecture development in the engineering of a system (after Levis

Figure 1.11 shows an organization chart representation of a physical architecture of the F-22 ﬁghter. Note that this physical architecture includes more than the F-22; the training and support systems are included as well. For a life-cycle balanced (concurrent engineering) deﬁnition of the F-22, the physical architecture should have been decomposed, as shown in Figure 1.12. Graphical techniques, such as Figures 1.11 and 1.12, are invaluable because they serve as an excellent communication medium; communication is one of the most important functions of systems engineers. A physical architecture subdivides the problem into manageable parts, permitting and encouraging an iterative process and providing excellent documentation. Figure 1.13 depicts the systems engineering design process in terms of requirements and architectures in a similar manner as the waterfall process, a

F-22 Weapon System

Avionics Systems

Utilities & Subsystems

Electronic Warfare

co*ckpit Systems

Vehicle Management System

Controls & Displays

Navigation, Identification

Radar

FIGURE 1.11

Support

Training

Vehicle

Processing

Inertial Reference System Stores Management

Sample physical architecture (F 22 Type A Spec) (from Reed [1993]).

1.5

INTRODUCING THE CONCEPT OF ARCHITECTURES

XYZ Weapon System

Operational System

Manufacturing System

Design & Integration System

Avionics Systems

Deployment System Training System

Utilities & Subsystems

Electronic Warfare

Refinement System

Controls & Displays Processing

FIGURE 1.12

Vehicle Management System

co*ckpit Systems

Navigation, Identification

Radar

Retirement System

Inertial Reference System Stores Management

Life cycle physical architecture.

sequential decomposition of requirements and the allocated architecture (functions mapped to physical resources) by moving from left to right and top to bottom. New students often ask the question, ‘‘What is the difference between a requirement and a speciﬁcation?’’ A requirement is one of many statements that constrain or guide the design of the system in such a way that

Stakeholders’ Need

System Design

Stakeholders’ Requirement

System Allocated Architecture Segment Specs

Segment Design

Element Design

Segment Allocated Architectures Element Specs

Element Allocated Architectures Component Specs

FIGURE 1.13

Component Design

Component Allocated Architectures CI Specs

Design decomposition of architectures and specs.

INTRODUCTION TO SYSTEMS ENGINEERING

the system will be useful to one or more of its stakeholders. A speciﬁcation is a collection of requirements that completely deﬁne the constraints and performance requirements for a speciﬁc physical entity that is part of the system. The systems engineering design process involves deﬁning all of the system’s requirements and then bundling them by segmenting and reﬁning into a speciﬁcation for each of the system’s segments, elements, components, and CIs.

1.6

REQUIREMENTS

Requirements for a system address the needs and objectives of the stakeholders. Just as there is a hierarchy associated with the physical components of the system, there is a hierarchy of requirements. At the top of the hierarchy are mission requirements, which relate to needs associated with missions or activities that are important to one or more groups of stakeholders. These mission requirements typically involve the interaction of several systems, one or more of which include individuals or groups of people and are therefore stated in the context of the operation of the system in question with these other systems, called the meta-system or supersystem or system of systems. Mission requirements represent stakeholder preferences for the increased ability to perform their activities with the introduction of the system in question at a lower cost arid in a faster time than the existing capability. Stakeholders’ requirements are statements by the stakeholders about the system’s capabilities that deﬁne the constraints and performance parameters within which the system is to be designed. Systems engineers take these highlevel, stakeholders’ requirements and derive a consistent set of more detailed engineering statements of requirements as the design progresses. For the purposes of this introduction requirements are divided into constraints and performance indices. Some constraints are simple, for example, the system must be painted a speciﬁc shade of green. Other constraints are the minimally acceptable level associated with a performance requirement. A performance requirement deﬁnes a desired direction of performance associated with an objective of the stakeholders for the system. For an elevator system (which is used throughout this book), a performance requirement might be to minimize passengers’ waiting time. For any performance requirement there must also be a minimum acceptable performance constraint or threshold and a design goal associated with the index; this threshold dictates that no matter how wonderful a design’s performance is on other objectives, performance below this threshold on this requirement makes the design unacceptable. This is a very strong statement of needs, and so minimal acceptable thresholds must be established very carefully. Every major organization, governmental or commercial, has established its own guidelines for system or product development. The names and organizations of the several requirements documents vary somewhat but cover similar material. Table 1.6 summarizes the common major requirements documents

1.6

REQUIREMENTS

TABLE 1.6 Typical Requirements Documents Document Titles Problem Situation or Mission Element Need Statement, and Systems Engineering Management Plan (SEMP)

Document Contents . Deﬁnition of stakeholders and their relationships . Stakeholders’ description of the problem and its

context . Description of the current system . Deﬁnition of mission requirements . Deﬁnition of the systems engineering

Stakeholders’ Need or Stakeholders’ Requirements Document (StkhldrsRD)

. . .

. .

System Requirements Document (SysRD)

. . . . .

System Requirements Validation Document

. .

management structure and support tools for developing the system Deﬁnition of the problem needing solution by the system (including the context and external systems with which the system must interact) Deﬁnition of the operational concept on which the system will be based Creation of the structure for deﬁning requirements Description of the requirements in the stakeholders’ language in great breadth but little depth Trace of every requirement to a recorded statement or opinion of the stakeholders Description of trade offs between performance requirements, including cost and operational effectiveness Restatement of the operational concept on which the system will be based Deﬁnition of the external systems in engineering terms Restatement of the operational requirements in engineering language Trace of every requirement to the previous document Justiﬁcation of engineering version of the requirements in terms of analyses, expert opinions, stakeholder meetings Description of test plan for each requirement Documents analyses to show that the requirements in the SysRD are consistent, complete and correct, to the degree possible Demonstrates that there is at least one feasible solution to the design problem as deﬁned in the SysRD

INTRODUCTION TO SYSTEMS ENGINEERING

that are produced during the beginning of the design phase. The Problem Statement (or Mission Element Need Statement in the military) gets the process rolling and identiﬁes a problem for which a solution in the form of a system (new or improved) is needed. This document supports and documents a decision-making process to start a system development effort. The Systems Engineering Management Plan (SEMP) then deﬁnes the systems engineering development system. Stakeholders’ requirements are found in the Stakeholders’ Requirements Document (StkhldrsRD). This document is produced with or by the stakeholders and is written in their language(s). Systems engineers need to be involved in a substantial way in this activity, although not all systems engineers share this view. Experience has shown that if this document is left to the stakeholders, the document will be very incomplete. The systems engineers can play a major facilitation role among the various groups of stakeholders as well as bring an assortment of tools to bear on a difﬁcult problem, the creation of this document. These tools (a major focus of this book) ensure a greater completeness and consistency. The methods and tools presented here are equally applicable in the rest of the systems engineering process. The systems engineer then begins restating and ‘‘deriving’’ requirements in engineering terms, called system requirements, so that the systems engineering design problem can be solved. This derivation of the StkhldrsRD becomes the Systems Requirements Document (SysRD). It is critical that the requirements in all of these documents address ‘‘what’’ and ‘‘how well’’ the system must perform certain tasks. Requirements do not provide solutions but rather deﬁne the problem to be solved. The Systems Requirements Validation Document deﬁnes requirements associated with the veriﬁcation, validation, and acceptance of the system during integration. These requirements are high-level requirements that state the needs of the stakeholders for qualifying the design of the system. These requirements form the basis of the problem deﬁnition for creating the qualiﬁcation system that will be used during integration. In addition to deﬁning the high-level qualiﬁcation requirements, this document should demonstrate that if the systems engineering process continues, an acceptable solution is possible. Unfortunately, this ‘‘existence proof’’ of a feasible solution is seldom produced in practice, leading to a major downfall of many systems engineering efforts. Namely, the realization many months (or years) later that not all of the requirements can be satisﬁed, and the stakeholders must relax the requirements that the engineers promised could be met. Systems engineers have always desired to demonstrate the importance of requirements and getting the requirements right, for example, complete, consistent, correct. In the mid-1970s three organizations (GTE [Daly, 1977], IBM [fa*gan, 1974], and TRW [Boehm, 1976]) conducted independent studies of software projects. These studies addressed the relative cost to ﬁx a problem based upon where in the system cycle the problem was found. Boehm [1981] and Davis [1993, p. 25] compared the results of the three studies (see the ﬁrst

1.7

SYSTEM’S LIFE CYCLE

TABLE 1.7 Comparison of the Relative Cost to Fix Software in Various Life Cycle Phases Source

Boehm (1981) Hoffman (2001) Cigital (2003) Rothman (2000) Rothman Case B (2000) Rothman Case C Rothman (2002) Pavlina (2003) McGibbon (2003) Mean Median

Phase Requirements Issue Found Requirements

Design

1 1 1

5 3 3 5

1 1

20 10 5 7.3 5

1 1

Code 10 5 7 33 10 10 45 100 25.6 10

Test 50 37 51 75 40 40 250 1000 50 177 50.5

row of Table 1.7). The costs have been normalized so that the relative cost to repair an average problem found in the coding phase is 10 units. These results stood for twenty years. The next eight rows of Table 1.7 show results from recent studies, summarized in Haskins et al. [2004]. As can be seen, the results have held up well. Getting the requirements right is a very difﬁcult task, and therefore a task that is fraught with errors. An error that is caught during requirements development can be ﬁxed for about 10% of the cost associated with an error caught during coding. Errors caught during maintenance in the operation of the system cost about 20 times that of an error caught during coding and 200 times the cost of an error caught during requirements development. Unfortunately, many of these errors are not caught until late in the life cycle, causing the expenditure of signiﬁcant money.

1.7

SYSTEM’S LIFE CYCLE

There are many ways to deﬁne a system’s life cycle. However, the common phases associated with a system are development, manufacturing, deployment, training, operations and maintenance, reﬁnement, and retirement. Systems engineers have activities in all of these phases, but the primary phases of concern to the systems engineers are development and reﬁnement. Stakeholders use and maintain the system in the operation and maintenance phase. A common mistake is to envision these phases as distinct and separate in time. In fact, it is common (though not required) to have four distinct periods: development only, pre-initial operational capability development and testing, operational use and reﬁnement, and retirement. All but the ﬁrst period have multiple phases occurring in parallel, as shown in Figures 1.14 to 1.17.

INTRODUCTION TO SYSTEMS ENGINEERING

Stakeholders Guidance & Approvals

Documents & Money

Design & Integration Documents

Develop System ABC

People & Tools

Development System

FIGURE 1.14

Development period.

Stakeholders Specifications

Guidance & Approvals Documents & Money

Manufacture System ABC

Deploy System ABC

Develop System ABC

Documents

Manufactured, Deployed & Tested Items People & Tools Development System

Train O/M of System ABC

Facilities, People, & Equipment Manufacturing System

Deployment System

Training System

FIGURE 1.15 Period of pre initial operational capability.

1.7

SYSTEM’S LIFE CYCLE

Stakeholders Guidance & Approvals

Specifications Documents & Money

Refine System ABC

Manufacture System ABC Manufactured Items Facilities, People, & Equipment Training Items

Deploy System ABC

Needs Deployed Items

Use System ABC

Train O/M of System ABC

Manufacturing System

Documents

Trained O/M Facilities, People, & Equipment Deployment System

People & Tools

Training System

Refinement System

FIGURE 1.16 Period of operational use and refinement.

Stakeholders

Specifications

Needs

Use System ABC

Decommissioned ABC’s

Laws & Regulations Transported, Decommissioned ABC’s

Deploy System ABC

ABC

Retire System ABC

People & Tools

Deployment System

Retirement System

FIGURE 1.17 Retirement period.

Waste Materials

INTRODUCTION TO SYSTEMS ENGINEERING

In the development period the systems engineering team receives resources from the bill payer and begins the development of the system. This period involves heavy interaction with the stakeholders as the requirements process is begun, and the architectures and models for simulation and analysis are initiated. However, this period ends when the manufacturing, deployment, and training teams begin preparation for the system. Development, manufacturing, deployment, and training activities are pursued concurrently during the second period, after concurrent design occurred in the ﬁrst period. Speciﬁcations ﬂow from the development process to the other three. Manufactured, deployed, and training equipment ﬂow to development for testing. Interaction continues with the stakeholders as ﬁnal testing occurs, leading to the acceptance of the system by the stakeholders. This period ends just as the ﬁrst operational systems are being delivered to the users. The third period begins as users receive the ﬁrst operational items. This period also contains continued production of the system, as well as deployment

Strategic Check

5 Control Document

Controlling Cycles

Profitability? Feasibility? Effort? Risks?

Translation of Requirements into Abstract Specs

Determination of Customer Desire

Verification Cycles

Improvement of Technologies & External Resources

Control Document

1 Modeling form, function Prototyping

CUSTOMER

Creation of Abstract Solution

fit, function

2 Pilot Tests form, fit, function Delivery & Sales

Coordination of External Resources

Translation into Manufacturable Solution

1 3

Realization Order Processing

Control Document

FIGURE 1.18 Cycle model of systems Engineering (after Wenzel et al. [1997]).

1.7

SYSTEM’S LIFE CYCLE

of and training on the system. Reﬁnement of the design begins here. Manufactured items are sent to the deployment system, which delivers them to users. One of the most difﬁcult problems to solve adequately from the perspective of the users is how to deploy upgraded items while the existing items are being phased out. Training items are sent to the training system (if needed), which produces trained operators and maintainers (O/M). Users and maintainers provide feedback about what they like and do not like, which is used during the reﬁnement phase to make changes to the design, leading to upgrades of the system. Finally, the bill payer of the system decides when the useful life of the system is over, beginning the initiation of the last period. The retirement phase may take considerable time. As the system is removed from service, the deployment system is used to transport the system from users to retirers. Note that this retirement process can be very orderly, as is the case with military systems. Alternatively, the retirement can be user-driven, as is the case with most commercial products such as cars and computers. Wenzel et al. [1997] describe the cycle model (see Fig. 1.18) which attempts to capture many of the issues discussed in this chapter. The cycle model stresses ﬁve cycles that include the elements of design and integration that have already been discussed as well as the management aspects of systems engineering. Table 1.8 describes these cycles in some detail. The ﬁrst cycle satisﬁes the key elements of stakeholder satisfaction, beginning with the determination of the need and ending with the delivery of the system to satisfy those needs. The development functions on this ﬁrst cycle include requirements development and creation of the system design. The second cycle (veriﬁcation) addresses the modeling, prototyping, and testing that must be part of the development process; these cycles within the veriﬁcation cycle enable the requirements and the solution to be reﬁned and veriﬁed. The third cycle enables management to insert technologies and external resources into both the development and the manufacturing processes to improve the chances of stakeholder satisfaction,

TABLE 1.8 The Cycles of the Cycle Model Design and Integration Cycles 1. Core Cycle: Realization of stakeholder needs, followed by requirements development, design, manufacturing and product delivery. 2. Veriﬁcation Cycle: Analysis, simulation, prototyping, integration and testing.

Management Cycles 3. Technologies and External Resources Cycle: Insertion of the appropriate technologies and resources into the systems engineering process. 4. Controlling Cycle: Conﬁguration management of the design process and multiple product releases and updates. 5. Strategic Check Cycle: Management assessment and approval of product development.

INTRODUCTION TO SYSTEMS ENGINEERING

subject to the constraints faced by management. The controlling cycle provides conﬁguration management throughout development and enables product releases and updates throughout the system’s life cycle. Finally, top-level management and stakeholder review and approval are included in the ﬁnal cycle.

1.8

DESIGN AND INTEGRATION PROCESS

Recall the design and integration Vee as identiﬁed by Forsberg and Mooz [1992]. The Vee model deﬁnes ﬁve major functions for the design or decomposition phase, as shown in Figure 1.19. Note that these functions must be repeated for each stage of the decomposition process. A modiﬁcation of the more detailed design functions, as put forth by Forsberg and Mooz [1992], is shown in Figure 1.20. This ﬁgure also shows how the Forsberg and Mooz [1992] functions are grouped to be comparable to the ﬁve analytical systems engineering functions. The ﬁve detailed functions that comprise the design phase must address up to ﬁve different dimensions of data; see van den Hamer and Lepoeter [1996]: (1) system variants when the system is a member of a product family (e.g., personal computers, automobiles); (2) system versions when the system is a product that evolves over time (e.g., operating systems); (3) views of the system (e.g., data,

Define the Design Problem Develop Functional Architecture Design Physical Architecture

Develop Allocated Architecture Obtain Approval & Document

FIGURE 1.19

Five major functions of the engineering design of a system.

Document Seg/CI design as approved baseline for next lowest level

Develop the Op’l Concept for the Sys,Seg,CI under analysis

(Chapter 6)

Define the Design Problem

yes

Allocate requirements to functions

Develop interfaces between Seg/CIs

(Chapter 10)

Plan test & integration of Seg/CIs

(Chapter 11)

Develop Allocated Architecture

Define the required functional performance by quantitative analysis

Define the required behavior in a functional interaction diagram

Develop Functional Architecture (Chapter 7)

FIGURE 1.20 Detailed functions of systems engineering design.

Obtain approval of boundary, objectives, concept of ops, requirements, physical solution, & test plan

Obtain Approval & Document

Define the problem, the system/segment/CI Boundary, & the objectives

Higher Level Requirements & Constraints from Approved Baseline

(Chapter 9)

Allocate functions to Seg/CIs, derive requirements

Evaluate candidate physical solutions & select best based upon objectives & requirements

Define candidate physical solutions

Develop Physical Architecture (Chapter 8)

INTRODUCTION TO SYSTEMS ENGINEERING

process); (4) hierarchical detail or onion peels (e.g., system, subsystem); and (5) status of the data (e.g., stable and approved versus tentative or draft). For many systems ﬁve modeling views [Karangelen and Hoang, 1994] are critical for capturing the totality of a system: environment, data or information, process, behavior, and implementation. The environmental view captures the system boundary, the operational concept, and the objectives of the system’s performance. The data or information view addresses the relationships among the data elements that cross the system’s boundary and those that are internal to the system; this view can be critical for information and software systems but incidental to mechanical systems. The process view examines the functionality of the system and is used to create the functional architecture. The behavior view addresses the control structures in which the system’s functions are embedded. The implementation view examines the marriage of the physical architecture with the process and behavior views; the allocated architecture represents the implementation view. In later chapters these views and the tools that are used to execute them will be addressed. Figure 1.21 shows a modiﬁcation of the Forsberg and Mooz [1992] integration functions. Most of this activity is dedicated to the veriﬁcation that the integrated components, elements, and segments meet the derived requirements (speciﬁcations) of the systems engineering process. The ﬁnal iteration of the integration functions is devoted to the validation of the system: Is this system the system the stakeholders wanted? Will they accept the system?

Verification Requirements and Constraints from Approved Baseline

CI to be verified

Inspect and test to verification requirements to prove readiness for integration with next assembly

Integrate with next CI and repeat verification process

Deficiencies

Yes

Identify and fix correctable deficiencies

Yes

Modify approved technical baseline to incorporate deviation

Correctable

Yes

Document uncorrectable deficiencies

Redesign

For uncorrectable deficiencies, confirm no impact to integration and get deviation approval from buyer

FIGURE 1.21 Functions of the systems engineering integration process.

1.9

TYPES OF SYSTEMS

The answer to these questions are substantially determined by the extent to which the systems engineers have kept the stakeholders involved throughout the process. The greater the involvement, the more the stakeholders understand what trade offs were made and why. There are four primary methods for testing the system to complete the veriﬁcation and validation process: instrumented test using calibrated equipment, analysis and simulation using equations and computers, demonstration or functional test using human judgment, and examination of documentation using human judgment. As integration moves from CIs and approaches the system level, human judgment must be relied upon more and more because the cost of instrumented testing on the system as a whole is prohibitive.

1.9

TYPES OF SYSTEMS

There are many possible ways to categorize systems: natural vs. man-made closed vs. open static vs. dynamic simple vs. complex reactive vs. nonreactive precedented vs. unprecedented safety-critical vs. not safety-critical high reliability vs. not high reliability high precision vs. not high precision human-centric vs. nonhuman high durability vs. not high durability Yet the process described in this book should work for all ‘‘man-made’’ systems, with some tailoring. Clearly, a great deal more engineering and systems engineering is required for an unprecedented system (the Shuttle) than for a precedented one (new automobile). Magee and de Weck [2004] propose a two-dimensional classiﬁcation structure of systems that was derived from the work of several other authors. The two dimensions include the character (energy, matter, etc.) of the major output of the system as well as the type of operation or process being employed to produce this major output. The major outputs of Magee and de Weck were broadened to include: Matter (M): physical objects, including organisms that exist unconditionally Energy (E): stored work that can be used to power a process in the future

INTRODUCTION TO SYSTEMS ENGINEERING

TABLE 1.9 System Classification by Magee and de Weck (2004) Major Process of Operand Transform or Process Transport or Distribute Store or House Exchange or Trade Control or Regulate

Major Output Matter

Energy

Information

Value

Manufacturing Plant Package Delivery Company Dam Internet Auction Company Health Care Company

Power Plant

Computer Chip

Mint

Power Grid System

Telecommunication Network

Banking Network

Dam Energy Market

Public Library News Agency

Energy Agency

International Standards Organization

Bank Stock Trading Market Mondtary Regualtor

Information (I): anything that can be considered an informational object Value (Monetary) (V): monetary and intrinsic value object used for exchange Magee and de Weck [2004] also broadened the list of operands or process manipulators to include: Transformation Systems: transform objects into new objects Distribution Systems: provide transportation, i.e., change the location of objects Storage Systems: act as buffers in the network and hold/house objects over time Market Systems: allow for the exchange of objects mainly via the value layer Control Systems: seek to drive objects from some actual state to a desired state Table 1.9 provides an example for each of the 20 combinations in the Magee and de Weck structure.

1.10

THE VALUE OF SYSTEMS ENGINEERING

There is very little empirical data about the value being added by systems (and software) engineering. Cook [2000] paints a very bleak picture (Table 1.10). True success is achieved only 20% of the time; complete failure occurs 30–40%

1.10 THE VALUE OF SYSTEMS ENGINEERING

TABLE 1.10

Summary of Systems and Software Engineering Success and Failure

U.K. Ministry of Defence Top 25 programs slipped 35 40 mo. on average 10% of projects missed key technical requirements

U.K. Civil information Technology 10 20% met success criteria 40 50% late, over budget, or did not meet technical goals 40% failed or were abandoned

U.S. Civil Information Technology 16% project success 53% project challenged

31% project cancelled

of the time. Honour [2006] provides a very tentative summary of a few, macrolevel metrics: . . . . .

Better technical leadership correlates to program success Better/more systems engineering correlates to shorter schedules by 40% or more, even in the face of greater complexity Better/more systems engineering correlates to lower development costs by 30% or more Optimum level of systems engineering is about 15% of a total development program Programs typically operate at about 6% systems engineering

Signiﬁcantly more research is required at both the macro and micro levels of the impact of good versus bad systems engineering on cost, schedule, and performance across the system’s life cycle. Note when there are no systems engineers assigned to a project, systems engineering is still being done, albeit poorly. How can systems engineering add value to the development, ﬁelding, and upgrade of a system? First, seeking the deﬁnition of the right problem to solve and then seeking the right solution to that problem requires both a systematic and creative process. The type of process that has proven successful at optimizing proﬁts in manufacturing would be the opposite end of the spectrum from that needed for systems engineering. In manufacturing the product is welldeﬁned and the process is focused on reﬁning this product to improve its quality and reduce its cost, both of which are very measurable. In systems engineering we are searching for a deﬁnition of the problem and an appropriate solution, little of which is easily measured. Adding to the complexities of this environment are multiple segments of the stakeholders (several types of users, maintainers, suppliers, and billpayers, as well as potential victims) having very different ideas of the problem and the preferred solution. In addition, there are

INTRODUCTION TO SYSTEMS ENGINEERING

various disciplines of engineers vying to provide the solution; the best solution often involves some integration across the solution space deﬁned by the engineering disciplines. Systems engineers typically resolve the issues of conﬂicting desires among stakeholders and competing designs among engineering disciplines through trade studies. Central to these trade studies are the objectives (conﬂicting though they may be) of the stakeholders and alternate design solutions nominated by the members of the systems engineering team. A second contribution made by systems engineers is to serve as a communication interface among the various segments of stakeholders, the various disciplines of engineers, and between the stakeholders and engineers. This interface task includes deﬁning an appropriate language for all to use (at least within the conﬁnes of this project) so that understanding can happen and agreement can be achieved. While this contribution seems almost trivial, the value added here can be huge. Show stoppers are those issues in the deﬁnitions of the problem and solution, which if not resolved could dramatically end the project or cause an inopportune failure in the future. Examples are the incorrect shape of the primary mirror of the Hubble telescope (case study at the end of this chapter), insufﬁcient ‘‘error checking’’ software in the Ariane 5 launch system (case study at the end of Chapter 11), and the insufﬁcient requirements for the Air Bag Safety Restraint system (case study at the end of Chapter 6) that would have saved many lives. Part of the value of systems engineering is ﬁnding and ﬁxing these show stopper issues before they cause problems. Almost any testing of the primary mirror of the Hubble telescope would have found a problem. Determining the potential for buffer overﬂows of unprotected (error checked) data ﬁelds on Ariane 5 could have been easily determined by examining the new trajectories planned for Ariane 5. Imagining the devastation of air bags on small children during slow speed accidents that would not otherwise be life threatening is part of what systems engineering is all about. It is well known in the systems and software engineering literature [Boehm, 1981; Haskins et al., 2004] that the earlier one ﬁnds a ﬂaw in the design the less money it takes to ﬁx the error; see Table 1.7. Finding and ﬁxing errors in the design when the design is quite abstract, incomplete and in ﬂux is the fourth element of value adding associated with systems engineering. A key part of this value-adding element is setting up measurement processes and feedbackcontrol loops so that progress can be checked and determined to be in or out of bounds so that changes can be made quickly and cost-effectively. Risk reduction is the ﬁnal way in which systems engineers add value. Risk issues are those characteristics of design alternatives that produce great uncertainty about whether a speciﬁc solution can meet deﬁned levels of performance within the objectives hierarchy of the stakeholders. High risk issues involve substantial uncertainty that a minimally acceptable level of performance will not be achieved. Moderate risk issues may have less uncertainty of meeting the minimally acceptable performance level or greater uncertainty of attaining a desired level of performance above the minimum

1.11 SUMMARY

acceptable. Systems engineers are supposed to identify these high and moderate risk issues and develop risk mitigation design alternatives. For example the Hubble telescope team decided to have a second primary mirror built by a subcontractor in case the prime contractor’s primary mirror was ﬂawed. Unfortunately, they did not require even a minimum amount of testing of the prime contractor’s primary mirror.

1.11

SUMMARY

Engineering involves the practice of applying scientiﬁc theories to the development, production, deployment, training, operation and maintenance, reﬁnement, and retirement of a system or product and its parts. The engineering discipline that addresses the creation of a system that meets the needs of deﬁned stakeholders is systems engineering. The engineering of a system involves both the design of the system’s components and conﬁguration items (CIs) and the integration of those CIs and components into a qualiﬁed system acceptable to the stakeholders across the life cycle of the system. The Vee model of the engineering of a system deﬁnes the design and integration processes of TTDSE and form the basis for this book. These processes are iterative. Design starts as a top-down process and is analogous to peeling an onion to uncover the speciﬁcations associated with increasingly detailed components of the system. However, the trade offs and decisions associated with the design process are so complex and intertwined that there is signiﬁcant movement between low-level and high-level design issues. The key to successful design is the isolation of design decisions using sound engineering principles so that this movement between low- and high-level design issues is consistent with the needs of the development process. There are logical arguments for decreasing development costs by spending the money to conduct a reasonable, systematic engineering effort of the total system. Multiple types of architectures are introduced to differentiate between what the system does (its functions) and what the system is (its resources) and how the functions are allocated to the resources to enhance the cost-effectiveness of the system in the eyes of the stakeholders. The functional and physical architectures are developed in parallel to enhance the integration of them into the allocated architecture. Requirements are used to deﬁne the design problem being solved at various levels of detail. Mission requirements deﬁne the problem in terms most meaningful to the stakeholders, terms that relate to enabling the stakeholders to accomplish tasks better, faster, and cheaper. Stakeholders’ requirements are the next level of detail that constrain speciﬁc characteristics of the system so as to achieve the mission requirements. Derived requirements relating to the system and speciﬁc components are even more detailed constraints upon the system. In addition to the requirements related to the system, qualiﬁcation

INTRODUCTION TO SYSTEMS ENGINEERING

system requirements must be developed to address the veriﬁcation, validation, and acceptance of the system during integration. The integration process receives less attention than the design process and is often viewed as the yin (weaker, passive side) of development, design being the yang (stronger, active side). However, integration cannot be passive after an active design process. Rather, design and integration must proceed in harmony; integration, if done well, actually improves as well as checks the design process. There are at least ﬁve ways that good systems engineering adds value. First, deﬁning the problem clearly and well and then ﬁnding a good solution that balances the needs of varying segments of stakeholders and the multiple engineering disciplines. Second, systems engineers serve as a communication interface among stakeholders and engineers. Finding showstoppers that are present in the design and getting them ﬁxed is the third value adding element. Finding design errors early when these errors are still relatively cheap to ﬁx is the fourth. Fifth, systems engineers help identify high risk elements of the design and develop risk mitigation strategies.

CASE STUDY: HUBBLE TELESCOPE TESTING DECISIONS Lyman Spitzer of Princeton University (1946) suggested that a telescope in space would eliminate the atmospheric effects that blurred images seen on Earth. The National Academy of Sciences proposed launching a telescope into space in 1972. NASA began the Hubble Space Telescope in 1977. After many project mishaps, the Hubble was ready to be launched in 1986. However, the explosion of the shuttle Challenger delayed the launch by 4 years. In April of 1990 the Hubble was launched; on May 20 the moment of truth arrived. At ﬁrst the scientists were thrilled with the data that was arriving from space; after further work though the scientists noticed a spherical aberration. The Hubble was providing a resolution of three times that available with telescopes on the ground, but the originating requirement for Hubble had been ten times Earth-based telescopes. In June 1993 the shuttle Endeavor carried a repair team to the hobbled Hubble. The astronauts spent three days of painstaking efforts to install a corrective ‘‘contact lens,’’ replace the original WideField and Planetary Camera, and replace the original solar panels to eliminate jitter twice each orbit as the satellite crossed from daylight to darkness. These repairs cost over $50 million. When the ﬁrst images from Hubble were examined, the scientists knew that Hubble needed some adjustment. Several focusing tests were proposed. The telescope was taken completely out of focus and then brought slowly back into focus; this is a common approach to check for errors in any optical device. Meanwhile another scientist wrote a software program to simulate the images from a telescope with a spherical

1.11 SUMMARY

aberration in its mirrors. The test images were amazingly similar to the simulated images, leading to a devastating conclusion. The Hubble telescope is a two-mirror reﬂecting telescope, a special type of Cassegrain telescope called a Ritchey-Chretien telescope. The primary mirror (96 inches) and secondary mirror were to be hyperbolic in shape; the manufacturing process is to grind the mirror as close as possible to this shape and then polish the mirror to remove all possible aberrations within the speciﬁed tolerances. During the grinding and polishing process, tests were conducted with a computer-controlled optical device, a reﬂective null corrector consisting of two small mirrors and a tiny lens. Unfortunately, the spacing between the lens and the mirrors was off by 1.3 millimeters. The aberration, 0.001 arcseconds from the design speciﬁcation, resulted in an error 100,000 times the size of the desired 1/50 the wavelength of light. Why was a mistake this large not detected? Photos taken during the manufacturing process in 1981 showed the ﬂaw, but the ﬂaw was not noticed in the photos or other testing. A knife-edge test was conducted on the main mirror. This sophisticated and complex test produced results showing that the null corrector results were incorrect. Either PerkinElmer (the prime contractor) thought these results invalid and did not report them to NASA, or NASA managers ignored them on the grounds that the knife-edge test results were not correct. Two other tests could have been conducted but were not. Eastman-Kodak was a competing contractor and had built an identical primary mirror. The primary mirrors could have been swapped and the null corrector tests rerun. The second test was an end-to-end test conducted on the assembled mirrors and other components. This test was deemed too expensive; NASA claimed the test would have cost more than $100 million but soon had to back down when independent estimates were 10 times lower, and the Air Force could possibly have conducted tests using existing equipment. This testing situation was aggravated and explained by management conﬂicts and mistakes within NASA and by cost overruns. NASA devised a management structure that included two centers, Goddard and Marshall. Marshall was given primary responsibility even though Goddard had more experience in systems of this type. Lockheed Aerospace was awarded the prime contract. Eastman-Kodak and PerkinElmer competed for the job of the primary mirror. Eastman-Kodak had more experience, but Perkin-Elmer provided a lower bid. EastmanKodak was given a contract to produce a back up primary minor, a risk mitigation strategy that could have been proven very insightful if the ﬂaw in the Perkin-Elmer mirror had been detected. [Feinberg, 1990; Petersen and Brandt, 1995; Sinnot, 1990].

INTRODUCTION TO SYSTEMS ENGINEERING

PROBLEMS 1.1 Compare and contrast the waterfall, spiral, cycle, and Vee models of the systems engineering process. In particular, what (e.g., functions performed, time sequence of functions, outputs produced, interaction with stakeholders) is the same in each of these processes and what is different? Are there some categories of systems for which one process would be better than the others? Use outside references to gain more information on the waterfall and spiral models. 1.2 Describe your personal experience with a system whose capability disappointed you. In your opinion, was this disappointment a design mistake made by the system’s designers or the result of a trade-off decision that had to be made during the system’s design? For example, a keyboard that is too small to be as usable as you would like on a laptop computer is the result of a trade-off decision. However, a keyboard with a poor touch for typing is a design mistake. Consider the following examples: 1.3 More often than desired, engineers are required to estimate quantities related to some aspect of a system because the necessary data is not available. Systems engineers often have to estimate quantities related to the meta-system. There has been quite a bit of attention to estimation in K-12; a common example is to estimate the number of gas stations in the 48 continental states of the United States. a) How would you go about this? What are several ways to estimate this quantity? Besides information about how many people there are in the U.S. or how many cars there are in the U.S., what other information do you know that might be related to the number of gasoline stations? b) Search the web and make a list of ways that other people have tackled this problem. Does this list give you any new ideas? What are they?

Chapter

Overview of the Systems Engineering Design Process

2.1

INTRODUCTION

This chapter provides a quick tour of many of the major concepts found in Chapters 6 to 11. This tour is quite valuable as part of an academic course on the engineering of systems because this chapter provides the context for the detailed discussion to follow. However, the advanced reader may wish to skip this chapter. Section 2.2 addresses the processes for design and for integration and qualiﬁcation. Included here are deﬁnitions for key terms such as system, function, and external system. Section 2.3 describes many of the key concepts of the design and integration processes. Included in the design process are the concepts of operational concept, external system diagram, objectives hierarchy, requirements, functions, items, components, and interfaces. Veriﬁcation, validation, and acceptance are discussed as part of the integration and qualiﬁcation process. Finally, Section 2.4 introduces the software product CORE, which is a systems engineering tool used in selected portions of this book to enable the student to practice and learn the many engineering concepts discussed here.

2.2

DESIGN PROCESS

This section begins by deﬁning some key terms that set the stage for discussing the engineering of a system. Then a more detailed discussion of the two legs of The Engineering Design of Systems: Models and Methods, Second Edition. By Dennis M. Buede Copyright r 2009 John Wiley & Sons, Inc.

OVERVIEW OF THE SYSTEMS ENGINEERING DESIGN PROCESS

the Vee process, design and integration (and qualiﬁcation), are presented in more detail than in Chapter 1. 2.2.1

Key Terms

As part of this overview of the design process, we must establish some important deﬁnitions: System: set of components (subsystems, segments) acting together to achieve a set of common objectives via the accomplishment of a set of tasks. System Task or Function: set of functions that must be performed to achieve a speciﬁc objective. Human-Designed System A specially deﬁned set of segments (hardware, software, physical entities, humans, facilities) acting as planned via a set of interfaces, which are designed to connect the components, to achieve a common mission or fundamental objective (i.e., a set of specially deﬁned objectives), subject to a set of constraints, through the accomplishment of a predetermined set of functions. System’s External Systems: set of entities that interact with the system via the system’s external interfaces. Note in Figure 2.1, the external systems can impact the system and the system does impact the external systems. The system’s inputs may ﬂow from these external systems or from the context, but all of the system’s outputs ﬂow to these external systems. The external systems, many or all of which may be legacy (existing) systems, play a major role in establishing the stakeholders’ requirements. System’s Context: set of entities that can impact the system but cannot be impacted by the system. The entities in the system’s context are responsible for some of the system’s requirements. See Figure 2.1. Context External Systems

System are impacted by “System” impacts, but not impacted by, “System”

FIGURE 2.1 Depiction of the system, external systems, and context.

2.2

2.2.2

DESIGN PROCESS

Design

As discussed in Chapter 1, design includes decomposition and deﬁnition of both the requirements, or statement of the design problem, and the architectures, functional and physical representations of the system. The allocated architecture addresses which physical resources of the system are going to perform which functions, but also includes a mapping of all of the requirements to the physical resources of the system. As well as addressing the system that must be operational for users, the design process should address all relevant systems needed during the life cycle of this system: the development system, of which the systems engineers are part; the manufacturing system, if needed; the deployment system, if needed; any training systems that are needed; a reﬁnement system for system upgrades; and the retirement system, if needed. Finally, the qualiﬁcation systems for each of these systems need to be addressed. There are eight functions below that capture the complete systems engineering process. The ﬁrst two (0a and 0b) are performed at the very beginning and are really part of a general problem solving process. The last six functions (1–6) are the focus of this book and are considered the core repetitive functions of the systems engineering design process: 0a Deﬁne the problem to be solved 0b Deﬁne and evaluate alternate concepts for solving problem 1. Deﬁne the system level design problem being solved 2. Develop the system functional architecture 3. Develop the system physical architecture 4. Develop the system allocated architecture 5. Develop the interface architecture 6. Deﬁne the qualiﬁcation system for the system All eight of these functions are shown in Table 2.1 with their major inputs and outputs. Chapters 6 through 11 address the last six functions, respectively. As can be seen by the respective inputs and outputs of these functions, these last six functions cannot be conducted in series but have to be concurrent. The resource that performs these functions is the systems engineering team. The ﬁrst of the repetitive design functions has to create a deﬁnition of the problem being solved for which the next ﬁve develop a set of designs (across the system’s life cycle). The seven functions that comprise this ﬁrst design function, deﬁning the design problem (stakeholders’ requirements), are: 1. 2. 3. 4.

Develop operational concept Deﬁne system boundary with external systems diagram Develop system objectives hierarchy Develop, analyze, and reﬁne requirements (stakeholders’ and system)

OVERVIEW OF THE SYSTEMS ENGINEERING DESIGN PROCESS

TABLE 2.1 Functions of the Design Process Design Function Deﬁne Problem To Be Solved

Develop and Evaluate Alternate Concepts for Solving Problem

Deﬁne System Level Design Problem Being Solved Develop System Functional Architecture Develop System Physical Architecture Develop System Allocated Architecture

Develop Interface Architecture Develop Qualiﬁcation System for the System

Major Inputs

Major Outputs

Concerns and Complaints by Stakeholders Available Data from Stakeholders Ideas for Concepts from All Interested Parties Objective Hierarchy & Value Parameters for Meta System Stakeholders’ Inputs Operational Concept

Deﬁnitions of Measures of Effectiveness and Desired Ranges Constraints Recommended Concept(s)

Stakeholders’ Requirements Operational Concept Stakeholders’ Requirements Stakeholders’ Requirements Functional Architecture Physical Architecture Interface Architecture Draft Allocated Architecture Stakeholders’ Requirements Systems Requirements

Functional Architecture

Stakeholders’ Requirements

Physical Architecture Allocated Architecture

Interface Architecture Qualiﬁcation System Design Documentation

5. Ensure requirements feasibility 6. Deﬁne the test system requirements 7. Obtain approval of system documentation These seven functions are shown with their major inputs and outputs in Table 2.2. There is an important distinction between the stakeholders’ requirements and the system requirements. Stakeholders’ requirements are those requirements that the system’s stakeholders agree deﬁne their needs. As such, the stakeholders’ requirements are written in the common language of the stakeholders (e.g., English, Chinese). The system requirements are a translation of the stakeholders’ requirements into the appropriate engineering terminology (e.g., foot-pounds, bits, and decibels). Chapter 6 presents more detail about this process. The detailed processes for developing the functional, physical, allocated, and interface architectures are not presented here because many of the concepts for

2.2

DESIGN PROCESS

TABLE 2.2 Functions of the System-Level Design Problem Design Function Develop Operational Concept

Deﬁne System Boundary with External Systems Diagram Develop System Objectives Hierarchy Develop, Analyze and Reﬁne Requirements (Stakeholders’ and System) Ensure Requirements Feasibility Deﬁne the Test System Requirements Obtain Approval of System Documentation

Major Inputs Stakeholders’ Inputs Objective Hierarchy & Value Parameters for Meta System Recommended Concept Operational Concept

Operational Concept Stakeholders’ Inputs Operational Concept System Boundary, Inputs & Outputs Objectives Hierarchy Stakeholders’ Inputs Stakeholders’ & Systems Requirements SE Team’s Inputs Stakeholders’ & Systems Requirements Stakeholders’ Inputs Stakeholders’ & Systems Requirements

Major Outputs Operational Concept System Concept Input output traces Meta system MOEs System Boundary, System’s Inputs and Outputs System level Objectives Hierarchy Stakeholders’ & Systems Requirements

Design Feasibility

Test System Requirements

Stakeholders’ & System Requirements Documents

these architectures are not appropriate for this overview. The decomposition of the last function of design, developing the qualiﬁcation system for the system, is a replication of the design process for the system but with the focus on the elements of the qualiﬁcation system. The design process, as presented here, is not a formal process in the sense that success can be proved, designs can be proved to be correct, and so forth. Some researchers have developed formal processes, primarily in software engineering. These formal processes have not succeeded in software development and are relatively rare in the engineering of systems. An example of such a formal process for engineering design is Suh’s [1990] axiomatic design process. Suh deﬁnes two major concepts — functional requirements and design parameters. He posits two axioms: (1) independence axiom: maintain the independence of the functional requirements and (2) information axiom: minimize the information content of the design. While Suh introduces hierarchical decomposition in his axiomatic process, there is not sufﬁcient richness of concepts in his process to handle the complexity of the engineering issues associated with the development of a system. First, as will be discussed in Chapter 6, functional requirements are a

OVERVIEW OF THE SYSTEMS ENGINEERING DESIGN PROCESS

derived entity that have no inherent meaning to the stakeholders; input and output requirements are statements that relate to stakeholders needs. Second, Suh’s process does not provide a sufﬁcient process to develop and enable validation of the requirements. Finally, the interaction of functions, components, and interfaces, as described in this book but is missing in some richness in Suh’s approach, is needed to deal with the generation and analysis of design options, as well as guide the qualiﬁcation of the system in terms of the stakeholders’ needs.

2.2.3

Integration and Qualification

The second half of the Vee model, integration and qualiﬁcation, is primarily a bottom-up process that comprises integrating the most basic building blocks of the system and verifying that these lower level components meet the speciﬁcations, or sets of requirements, that were developed for them during design. However, before this integration and veriﬁcation process begins, a validation of the requirements development process should take place to attempt to demonstrate that the low-level design solutions are still consistent with the stakeholders’ needs. At the end of qualiﬁcation come the important steps of validating that the system that has been designed and veriﬁed does in fact agree with the operational concept and is acceptable to the stakeholders. The stakeholders include the bill payer, the users, the maintainers and supporters,

TABLE 2.3 Functions of the Integration and Qualification Process Design Function Conduct Early Validation

Conduct Integration and Veriﬁcation Testing

Conduct System Validation Testing

Conduct System Acceptance Testing

Major Inputs Stakeholders’ Inputs Operational Concept Stakeholders’ Requirements Derived Requirements Conﬁguration Items (CIs) Components Derived Requirements Veriﬁed System Stakeholders’ Requirements Stakeholders’ Inputs Validated System Acceptance Test Plan Stakeholders’ Inputs

Major Outputs Validated Requirements Validated Operational Concept

Veriﬁcation Testing Document Veriﬁed Components and System Validation Testing Document Validated System Acceptance Testing Document Accepted System

2.3

KEY SYSTEMS ENGINEERING CONCEPTS

the manufacturers, the trainers, the deployers, the reﬁners, and the retirers. The integration and qualiﬁcation process can be divided into four segments: 1. 2. 3. 4.

Conduct Conduct Conduct Conduct

early validation integration and veriﬁcation testing system validation testing system acceptance testing

Table 2.3 presents these four functions that comprise integration and qualiﬁcation with their major inputs and outputs. Each of these functions is described in more detail in Chapter 11.

2.3

KEY SYSTEMS ENGINEERING CONCEPTS

This section provides a detailed discussion of key constructs for design and integration. An operational concept, external system diagram, objectives hierarchy, and requirements are the essential elements of the deﬁnition of the design problem. Functions and items comprise the functional (or logical) architecture. Components are the building block for the physical architecture. Interfaces combined with the functional and physical architectures are key to understanding the allocated architecture. Qualiﬁcation is veriﬁcation, validation, and acceptance during integration. Figure 2.2 provides an entity relation diagram showing many of these concepts (or entities) and their relationships. 2.3.1

Operational Concept

An operational concept is a vision for what the system is (in general terms), a statement of mission requirements, and a description of how the system will be used. A set of scenarios describes how the system will be used by deﬁning the system’s interaction with other systems. For example, the operational concept for an elevator system may begin with a description of cars that carry people and equipment moving vertically in shafts. The mission requirements would discuss the desired times that passengers would wait from the time they requested service until they arrived at their destination. Next, the operational concept would use scenarios such as those in Table 2.4 to deﬁne how the elevator would be used during the elevator’s operational phase. 2.3.2

External Systems Diagram

Deﬁning the boundaries of a system is critical but often neglected. An external systems diagram is used to establish the bounds of the system and communicate the results of this bounding process. This diagram can be created from the

OVERVIEW OF THE SYSTEMS ENGINEERING DESIGN PROCESS

Context

Purpose

operates in ha a has

External Systems

performs

operates in interacts with via items

Life Cycle

ha a has

System

performs Function

built from

lin links

performs receives, transforms, send

Components

performs Item

is a

Physical Entity

links Interface

carries

is a

Energy

Information Entity

FIGURE 2.2 Many of the concepts and their relationships.

scenarios in the operational concept for the system and should he completely consistent with those scenarios. Figure 2.3 shows an external systems diagram for the operational phase of the elevator using IDEF0, which is an acronym based on the following word phrase: Integrated Deﬁnition for Function Modeling. (IDEF0 will be presented in detail in the next chapter.) The systems are shown as arrows entering the bottom of each box, their functions are verb phrases in the boxes, and their inputs, controls, and outputs are shown as labels on lines entering from the left, entering from the top, and exiting from the right of the boxes, respectively. Many other process and dynamic modeling techniques can be used to draw and represent the system’s boundaries, some of which are presented in Chapter 12. On the basis of this diagram, the system is bounded by the deﬁnition of all of the inputs (and controls) that enter the system, as well as the outputs that the system must produce. The characteristics of these inputs and outputs can be described, thus ﬁnishing the deﬁnition of the boundary of the system.

2.3

KEY SYSTEMS ENGINEERING CONCEPTS

TABLE 2.4 Sample Operational Concept Scenarios for an Elevator 1) Passengers (including mobility, visually and hearing challenged) request up service, receive feedback that their request was accepted, receive input that the elevator car is approaching and then that an entry opportunity is available, enter the elevator car, request a ﬂoor, receive feedback that their request was accepted, receive feedback that the door is closing, receive feedback about the ﬂoors at which the elevator is stopping, receive feedback that an exit opportunity is available at the desired ﬂoor, and exit the elevator with no physical impediments. 2) Passenger enters the elevator car, as described in 1, but ﬁnds an emergency situation before an exit opportunity is presented, and notiﬁes the police or health authorities using communication equipment that is part of the elevator. Elevator maintenance personnel create an exit opportunity. 3) A maintenance person needs to repair an individual elevator car; the maintenance person places the elevator system in ‘‘partial maintenance’’ mode so that the other cars can continue to pick up passengers while the car(s) in question is (are) being diagnosed, repaired, and tested. After completion, the maintenance person places the elevator system in ‘‘full operation’’ mode.

2.3.3

Objectives Hierarchy

The objectives hierarchy of a system contains a hierarchical representation of the major performance, cost, and schedule characteristics that the stakeholders will use to determine their satisfaction with the system. For example, stakeholders evaluate an elevator system on the basis of the time spent waiting from their arrival at the elevator until they are delivered at their desired ﬂoor. Stakeholders are also concerned about the quality of the ride and the availability of the elevator services. The stakeholder, who is responsible for the building in which the elevator is located, is concerned about the monthly operating cost of providing the elevator services. See Figure 2.4 for a sample objectives hierarchy for the operational phase of the elevator. 2.3.4

Requirements

Requirements were deﬁned in Chapter 1. Chapter 6 will address how to use the operational concept and external systems diagram, as well as the objectives hierarchy, to develop the stakeholders’ requirements. For now, the four categories of requirements (input/output, technology and system-wide, tradeoff, and test) are assumed; these deﬁnitions will be expanded and motivated in Chapter 6. 1. Input/output requirements: include (a) inputs, (b) outputs, (c) external interface constraints, and (d) functional requirements. 2. Technology and system-wide requirements: consist of requirements that address (a) technology to be incorporated into the system, (b) the suitability (or ‘‘-ilities’’) of the system, (c) cost of the system, and (d) schedule issues (e.g., development time period, operational life of the system).

NODE:

A-1

Passengers Needing Elevator Services

Repair Parts

Passengers in Elevator System

Emergency Support A-0

Elevator System

Provide Elevator Services

Request for Floor & Exit Support

Request for Emergency Support & Emergency Message

Passenger Characteristics

A-12

Passenger Environment

Request for Elevator Service & Entry support

DATE: 05/24/99 REV:

ModifiedElevator Configuration & Expected Usage Patterns

NUMBER:

Building

A-14

Provide Structural Support

P.1

Electric Power & Emergency Communication Response

Emergency Messages

None

DATE CONTEXT:

Building Regulations

Emergency Communication

Maintenance Personnel

Service, Tests & Repairs

A-13

Maintain Elevator Operations

Diagnostic & Status Messages

Structural Support, Alarm Signals & Building Environment

WORKING READER DRAFT RECOMMENDED PUBLICATION Maintenance Quality Standards

Acknowledgment that Request Was Recieved & Status Information

FIGURE 2.3 External systems’ diagram for operational use of an elevator.

TITLE: External Systems Diagram for Operational Phase

Passengers

Elevator Entry/Exit Opportunity

Elevator Exit Opportunity

A-11

Use Elevator Services

Passengers' Needs

NOTES: 1 2 3 4 5 6 7 8 9 10

AUTHOR: Dennis Buede PROJECT: Elevator Case Study

Request Elevator Services

Elevator Entry Opportunity

USED AT: George Mason Univ.

2.3

KEY SYSTEMS ENGINEERING CONCEPTS

Operational Objectives

Monthly Operating Costs $1,500 - $1,000, Wt = 0.1

Operational Performance Objectives, Wt = 0.9

Time in System Objectives, Wt = 0.35

Average Wait (Routine) 35 - 27 sec, Wt = 0.3 Average Wait (Priority) 35 - 30 sec, Wt = 0.35 Average Transit Time 90 - 60 sec, Wt = 0.35 Ride Quality Objectives, Wt = 0.30

Max'm Acceleration 1.5 - 1.25 m/s2, Wt = 0.3 Max'm Accel'n Change 2 - 1.5 m/s3, Wt = 0.5 Floor Leveling Error 0.7 - 0.3 cm., Wt = 0.2 Availability Objectives, Wt = 0.35

Operational MTBF 1 - 1.5 yrs, Wt = 0.5 Operational MTTR 8 - 4 hrs, Wt = 0.5

FIGURE 2.4 Fundamental objectives hierarchy for operational phase of elevator.

3. Trade-off requirements: are algorithms to enable the engineers of the system to conduct (a) performance trade offs, (b) cost trade offs, and (c) cost–performance trade offs. 4. System qualiﬁcation requirements: have four primary elements: (a) how the test data for each of the ﬁrst categories of requirements will be obtained, (b) how the test data will be used to determine that the real

OVERVIEW OF THE SYSTEMS ENGINEERING DESIGN PROCESS

TABLE 2.5 Sample Elevator Requirements for the Operational Phase 4.3 Stakeholders’ Requirements 4.3.5 Operational Phase Requirements. 4.3.5.1 Input/Output Requirements. 4.3.5.1.1 Input Requirements. 4.3.5.1.1.1 Emergency Support Inputs. 4.3.5.1.1.1.1 The system shall support manual overrides. 4.3.5.1.1.1.2 The elevator system shall allow passengers with a designated pass key to assume complete control of an elevator car. 4.3.5.1.2 Output Requirements. 4.3.5.1.2.1 Passenger Environment Outputs. 4.3.5.1.2.1.1 The elevator car shall have adequate illumination. 4.3.5.1.4 Functional Requirements. 4.3.5.1.4.1 The elevator shall accept passenger requests and provide feedback. 4.3.5.1.4.2 The elevator shall move passengers between ﬂoors safely and comfortably. 4.3.5.1.4.3 The system shall control elevator cars efﬁciently. 4.3.5.1.4.4 The system shall enable effective maintenance and servicing. 4.3.5.2 System wide & Technology Requirements. 4.3.5.2.1 The system MTBF shall be greater than 1 year. The design goal is 1.5 years. Failure is deﬁned to be a complete inability to carry passengers. 4.3.5.2.2 The system MTTR shall be less than 8 hours. The design goal is 4 hours. Repair means the system is returned to full operating capacity.

system conforms to the design that was developed, (c) how the test data will be used to determine that the real system complies with the stakeholders’ requirements, and (d) how the test data will be used to determine that the real system is acceptable to the stakeholders. These requirements categories are relevant to each phase of the system’s life cycle discussed above. For now consider Table 2.5 to be an example of the input/output and system-wide requirements for the operational phase of an elevator. Note that these examples of requirements are shown in an outline or hierarchical format. Also note that the real requirements — those statements that start with ‘‘The Elevator system shally’’— are at the bottom of the hierarchy. Every entry of the hierarchy that has another level below it is not really a requirement, but a group of requirements. 2.3.5

Functions

A function is a transformation process that changes inputs into outputs. A system is modeled as having a single, top-level function that can be decomposed into a hierarchy of subfunctions. The system’s top-level function transforms all

2.3

KEY SYSTEMS ENGINEERING CONCEPTS

of the inputs to the system into all of the outputs of the system. See Figure 2.5 for the elevator example using IDEF0. This system function can be taken directly from the external systems diagram. The top-level function is decomposed into subfunctions as part of the development of the functional architecture. Each subfunction transforms a subset of the inputs from the outside (plus some other internally generated inputs) into a subset of the outputs (plus some other internally generated outputs). This decomposition cannot be found in a book or dictated by the stakeholders; the decomposition is a product of the engineers of the system and is part of the architectural design process that is attempting to solve the design problem established by the requirements. The decomposition can be carried as deeply as needed to deﬁne the transformations that the system must be able to perform. Figure 2.6 shows the ﬁrst-level decomposition of the elevator system function using IDEF0. 2.3.6

Items

Items are the inputs that are received by the system, the outputs that are sent by the system to other systems, and the inputs that are generated internally to the system and sent to other parts of the system to assist in the transformation process for which the system is responsible. Items can be physical entities that have mass and energy, or items can be information that are somehow transformed into items with mass or energy to be transmitted from one physical element to another. The external inputs and outputs of the elevator are shown in Figure 2.5. Both the external and internal items of the elevator, at the ﬁrst level of functional decomposition, are shown in Figure 2.6. 2.3.7

Components

A component of a system is a subset of the physical realization (and the physical architecture) of the system to which a subset of the system’s functions have been (will be) allocated. A component could be the integration of hardware and software, a speciﬁc piece of hardware, a speciﬁc segment of the system’s software, a group of people, facilities, or a combination of all of these. As with the requirements and functions, there is often a hierarchical structure to the components that comprise the system. The ﬁrst level decomposition of the elevator into components is shown in Figure 2.7. 2.3.8

Interfaces

An interface is a connection resource for hooking to another system’s interface (an external interface) or for hooking one system’s component to another (an internal interface). Interfaces have inputs, produce outputs, and perform functions. An interface can be as simple as a wire or conveyor belt or as sophisticated as a global communication system (which is a system in its own right).

NODE:

A-0

Service, Tests & Repairs

Electric Power & Emergency Communication Response

TITLE:

Request for Emergency Support & Emergency Message

Elevator System

PROVIDE ELEVATOR SERVICES

Request for Elevator Service & Entry support

DATE: 05/24/99 REV:

READER

Top

DATE CONTEXT:

Emergency Support

Elevator Entry/Exit Opportunity

P. 2

Emergency Communication

Diagnostic & Status Messages

Acknowledgment that Request Was Recieved & Status Information

Passenger Environment

Modified Elevator Configuration & Expected Usage Patterns

NUMBER:

Structural Support, Alarm Signals & Building Environment

WORKING DRAFT RECOMMENDED PUBLICATION

FIGURE 2.5 Top-level function for the elevator.

Provide Elevator Services

Request for Floor & Exit Support

NOTES: 1 2 3 4 5 6 7 8 9 10

AUTHOR: Dennis Buede PROJECT: Elevator Case Study

Passenger Characteristics

USED AT: George Mason Univ.

NODE:

Service, Tests, & Repairs

Passenger Characteristics

Electric Power & Emergency Communication Response

TITLE:

Elevator Cars Component Elevator System

WORKING DRAFT RECOMMENDED PUBLICATION

Elevator Position & Direction

Structural Support, Alarm Signals & Building Environment

Sensed Malfunctions

MOVE PASSENGERS BETWEEN FLOORS

Assignments for Elevator Cars

PROVIDE ELEVATOR SERVICES

Elevator Control Component

CONTROL ELEVATOR CARS

Configuration Controls

Modified Elevator Configuration & Expected Usage Patterns

DATE: 05/24/99 REV:

Diagnostic Queries

NUMBER:

P. 3

Diagnostic & Status Messages

Elevator Entry/Exit Opportunity

Passenger Environment

Temporary Modification to Elevator Configuration

Emergency Support

Emergency Communication

Acknowledgment that Request Was Recieved & Status Information

DATE CONTEXT:

Maintenance & Service Component

ENABLE EFFECTIVE MAINTENANCE & SERVICING

READER

FIGURE 2.6 First-level decomposition of the elevator system function.

Passenger Interface Component

Electric Power

Digitized Passenger Requests

Request for Elevator Service & Entry support

ACCEPT PASSENGER REQUESTS & PROVIDE FEEDBACK

Request for Floor & Exit Support

NOTES: 1 2 3 4 5 6 7 8 9 10

AUTHOR: Dennis Buede PROJECT: Elevator Case Study

Request for Emergency Support & Emergency Message

George Mason Univ.

USED AT:

OVERVIEW OF THE SYSTEMS ENGINEERING DESIGN PROCESS

Elevator System Passenger Interface Component

Elevator Control Component

Elevator Cars Component

Maintenance & Service Component

FIGURE 2.7 Physical architecture of the elevator system.

2.3.9

Verification

As discussed in Chapter 1, veriﬁcation addresses whether the system was built right. In practical terms, veriﬁcation is the determination that each conﬁguration item (CI), component, and the system meets the requirements for it during the design phase. These requirements will be input/output or technology/ system-wide requirements. Inspection, testing, analysis and simulation, or demonstration can establish this veriﬁcation. Inspection and testing are most common at the CI level. Demonstration and analysis/simulation are most common at the system level.

2.3.10

Validation

Validation addresses whether the right system has been developed. Validation gets back to the illusive needs of the stakeholders. One aspect of validation that should be performed during the design phase of development attempts to demonstrate the design problem is evolving properly from a high-level statement in the operational concept that correctly reﬂects the needs of the stakeholders to scenarios, stakeholders’ requirements, system requirements, component requirements, and CI requirements. Stated another way this early validation of the design problem demonstrates as completely as possible that the design problem as deﬁned by a large set of requirements for all of the CIs is the same design problem as reﬂected in the operational concept and the minds of the stakeholders. Validation during the integration and qualiﬁcation phase demonstrates that the system that was designed and has been integrated meets the needs of the stakeholders as deﬁned by the operational concept. Validation of the system stops short of the needs of the stakeholders because that will be addressed by the acceptance of the design by the stakeholders.

2.3.11

Acceptance

The ﬁnal step of integration and qualiﬁcation is acceptance by the stakeholders; do the stakeholders feel that the system as designed is acceptable? This conclusion allows the stakeholders to compare the system to their own needs and decide whether they will accept the system. The job of the engineers of the

2.4

INTRODUCTION TO SysML

system during acceptance testing is to construct the proper set of test activities and test equipment and facilities to provide the information needed by the stakeholders for making their decision.

2.4

INTRODUCTION TO SysML

As described in Chapter 1, SysML is a visual modeling language for conducting systems engineering. Sections 2.2 and 2.3 have introduced you to some of the key terms and basic process for performing Traditional, Top-Down Systems Engineering (TTDSE). Figure 2.8 shows the processes of TTDSE associated with the left-hand side of the Vee model on the left hand side of the ﬁgure. Included with these process elements of TTDSE are modeling activities that should utilize a graphical modeling language. The right-hand side of Figure 2.8 shows the diagram types of SysML. Double-headed arrows in Figure 2.8 show which modeling elements from TTDSE are addressed by which diagram types of SysML. Naturally there are many to many-to-many and many-to-one relations shown. There are also three modeling activities in TTDSE that are not supported by SysML (requirements taxonomy; creativity; and the morphological box for physical architecture alternatives and risk and trade studies). Each of these topics is addressed in Chapters 6, 8, and 13, respectively. Also,

TTDSE (1st edition of Eng’g Design of Systems) Defining the Problem Being Solved Operational Concept & External Systems Diagram

Concept, Meta-system MOEs Input-output Traces Objectives Hierarchy Requirements Taxonomy Requirements relations Defining the Functional Architecture IDEF0 (or other technique) Defining the Physical Architecture Creativity & Morphological box Block diagram

SysML Use Case Diagram

Sequence Diagram

Activity Diagram State Machine Diagram Requirements Diagram Internal Block Diagram

Defining the Allocated Architecture Allocating functions to components Creating relations among all elements Conducting performance analyses Performing risk and trade studies

Defining Interfaces Creating interface relations

Block Definition Diagram Parametric Diagram Package Diagram

FIGURE 2.8 Comparison of TTDSE and SysML.

OVERVIEW OF THE SYSTEMS ENGINEERING DESIGN PROCESS

there are two diagram types (use case and package) in SysML that are not related to the elements of TTDSE from the ﬁrst edition of this book; these two diagram types will be covered in Chapter 3. This ﬁgure should convey to you that SysML is a nearly complete and welldesigned, interconnected set of visual modeling diagrams that enable a substantial improvement in model-based systems engineering. All elements of the design process that we cover in this book are covered. Since the test system is another system, SysML can be equally applied to the design and operation of the test system, just as it can be applied to the design of the systems engineering system of engineers, domain experts, technologists, and managers.

2.5

USE OF CORE (SYSTEMS ENGINEERING TOOL)

Part of the educational material provided with this book is an academic version of a system engineering tool called CORE. (You may download the academic version of CORE from http://www.vitechcorp.com.) The rest of this chapter provides an overview of concepts embedded in CORE. Instructions for using the tool can be obtained in the user’s manual and guided tour available with CORE. At its simplest, CORE is comprised of classes (e.g., requirements, functions, items), examples or elements of those classes (e.g., speciﬁc requirement), and relations. The most basic user activities of CORE are entering and editing elements of the classes and establishing relations between elements of classes. Other important activities include viewing products of the design data, saving your work, and obtaining reports that document the design contained in the database. The automated tutorial demonstrates these functions for a collection management system as a sample problem. 2.5.1

Classes

Table 2.6 lists the classes in CORE 2.0. These classes contain both the major elements of the systems engineering design process that are discussed in this chapter as well as a number of supporting classes. For a given system, the job of the engineers of the system is to deﬁne speciﬁc elements of the system for each of these major classes (e.g., stakeholders’ requirements, functions, components, and items). 2.5.2

Relations

As part of the engineering design process, requirements must be related to functions and components using the specify relation, functions allocated to components, and inputs and outputs assigned to interfaces. Table 2.7 deﬁnes the relations available in CORE to deﬁne relationships within the design and integration classes. These relations are fully compatible with the mathematical

2.5

USE OF CORE (SYSTEMS ENGINEERING TOOL)

TABLE 2.6 Systems Engineering Classes in CORE Class Category Component

Deﬁned Term Document

Domain Set Function

Interface Issue Item Link Requirement

Resource

Risk State/Mode

Veriﬁcation Requirement

Definition of the Class A general purpose element that can be used to represent such concepts as Version Number, Element Classiﬁcation, etc. A physical entry that can represent the system; a subsystem or further decomposition of the system, including a conﬁguration of a component; or an external system or the meta system. An acronym or special term that needs to be deﬁned as part of the requirements process. A source/authorization for information from stakeholders entered into the system description database or reported from the database. The number of iterations or replications in a control structure. A process that accepts one or more inputs (items) and transforms them into outputs (items). A function should have a completion criterion for each exit. The logical connection between parts of the system’s architecture. A problem (as well as its resolution) with any element in the system’s design. Physical entities or data that ﬂows within and between functions. An item is an input to or output from a function. The physical implementation of an interface. A requirement extracted from the source documentation for a system, or a reﬁnement of a higher level requirement. Requirements should be reﬁned until only a single, testable statement of a system’s feature remains. A characteristic (e.g., power, channels, instructions processed per second) of one or more components that are used, captured, or generated and can be depleted during the operation of the system. The uncertainty of attaining/achieving a product performance level or program milestone. Sometimes used as the highest level functional breakout to deﬁne a set of functions that system performs at a point in time, e.g., startup, normal operation, recovery operations, shut down. The requirement to be met by the qualiﬁcation system, the level at which it must be met, the method of qualiﬁcation, and current qualiﬁcation status.

deﬁnition of relations in Chapter 4 and can be depicted graphically by directed graphs as discussed in Chapter 5. For each relation there is an opposing relation that reverses the direction of the relation. Table 2.7 shows the relations (and their opposing relations in parentheses) and deﬁnes each relation by identifying which class is on the left side (tail of the arrow) and which class is on the right side (head of the arrow).

OVERVIEW OF THE SYSTEMS ENGINEERING DESIGN PROCESS

TABLE 2.7 Common Systems Engineering Relations Relation (Opposing Relation) ‘‘is part of’’; examples include reﬁnes (requirements) decomposes (functions, items) built from (components) (‘‘is a superset of’’) ‘‘input to’’ (‘‘inputs’’) ‘‘output from’’ (‘‘outputs’’) ‘‘triggers’’ (‘‘triggered by’’) ‘‘deﬁned by’’ (‘‘deﬁnes’’) ‘‘built from’’ (‘‘built in’’)

‘‘exhibited by’’ (‘‘exhibits’’) ‘‘allocated to’’ (‘‘performs’’)

‘‘speciﬁes’’ (‘‘speciﬁed by’’)

‘‘transfers’’ (‘‘transferred by’’) ‘‘comprises’’ (‘‘comprised of’’)

Definition

Application

The left side is a subset of the right side. For example, the requirement on the left side incorporates the one on the right, the function on the left side is decomposed by the one on the right.

Hierarchies of requirements, functions, items, components.

The item on the left side is an input to the function on the right side. The item on the left side is an output from the function on the right side. The item on the left side triggers the activation of the function on the right side. The state/mode on the left side is deﬁned by the function on the left side. The left side (system or component) is comprised of the system or component on the right side. The state/mode on the left side is exhibited by the component on the right side. The function on the left side is being assigned to the component on the right side for the purpose of execution. The requirement on the left side speciﬁes the function, state/ mode, item, component, interface or link on the right side. The link on the left side transfers the item on the right side. The link on the left side comprises the interface on the right side.

Development of the functional architecture Development of the functional architecture Development of the functional architecture Development of the functional architecture Development of the physical architecture

Development of the physical architecture Development of the operational architecture

Development of the functional and operational architectures Development of the interface architecture Development of the interface architecture (Continued)

2.5

USE OF CORE (SYSTEMS ENGINEERING TOOL)

TABLE 2.7. Continued Relation (Opposing Relation)

Definition

‘‘connects to’’ (‘‘connected to’’)

The link on the left side connects to the component or system on the right side. The interface on the left side joins the component on the right side.

‘‘joins’’ (‘‘joined to’’)

Application Development of the interface architecture Development of the interface architecture

One subtlety that has been ignored so far is the relating of requirements to functions and items, or the system. Input/output requirements are deﬁned in such a way that each such requirement should be directly relatable to both speciﬁc functions and items. Technology and system-wide requirements are those requirements that cannot be related to speciﬁc functions or items but must be satisﬁed by the system. As a result each input/output requirement is traced to (or speciﬁes) the lowest level function that receives the relevant input or produces the relevant output, all of the functions that are above that function in the functional decomposition, and the item directly relevant to that requirement. (Note that the third category of input/output requirements is function requirements; these requirements specify the top-level system function because they deﬁne the decomposition of that function.) Similarly, each technology and system-wide requirement speciﬁes the system. Relating requirements to functions and the system through the specify relation is important because this activity initiates the process of creating a set of requirements for the system to satisfy and provides the material for subsets of the requirements to be associated with speciﬁc components. These subsets of requirements become the speciﬁcations that each CI design team must meet. (Note that the requirements related to functions ultimately are assigned to the system and its components when each function is allocated to one or more components for execution.)

2.5.3

Documents

CORE enables you to design your document. However, the outline of the document that will be used throughout this book is the System Description Document (SDD), which can be found under the reports available from version 1.2 of CORE. This SDD outline (see Table 2.8) contains an initial section in which a general description of the system would be provided; the operational concept would be found here if CORE captured this material. The stakeholders’ requirements are found in Section 2. Section 3 of the SDD is for the requirements that are constraints; the approach taken here is to include all

OVERVIEW OF THE SYSTEMS ENGINEERING DESIGN PROCESS

TABLE 2.8 Outline of System Description Document 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

Primary System/Component Description Originating (Stakeholders’) Requirements Design Constraints Performance Requirements Issues & Decisions Risks Functional Behavior Models Item Dictionary Resources Components Interfaces Requirements Traceability Matrix

requirements as part of the stakeholders’ requirements so Section 3 can be deleted. The section on performance objectives is for the objectives hierarchy. Section 5 enables the systems engineering team to capture the design issues and decisions, which are usually addressed as part of the allocated architecture. Risk management is addressed in Section 6; this is the place that key uncertainties are deﬁned and the potential impact of bad outcomes deﬁned. The functional architecture is deﬁned in Section 7 as both a process model and behavioral model; CORE uses an N2 model for the system’s process and a function ﬂow block diagram model for the system’s behavior (both of these models are covered in Chapter 12). The item dictionary (or data model) is found in Section 8. The physical architecture is deﬁned in Section 9, and the interfaces that are derived from the combination of the item dictionary and the physical architecture are deﬁned in Section 10 of the SDD. The logical and physical interfaces developed by the system engineering team are described in Section 11. Section 12 provides a cross reference of requirements with the selected test methods that will be used for qualiﬁcation. Section 13 provides a requirements speciﬁcation matrix that associates functions and components with the stakeholders’ requirements.

2.6

SUMMARY

This chapter has given deﬁnitions and provided discussions on the most important concepts in the engineering of systems. The operational concept of the system provides the theme for the system as viewed by the stakeholders and deﬁnes scenarios depicting how its users will employ the system and how the system will interact with other systems. The external systems diagram deﬁnes

PROBLEMS

the interaction in terms of inputs and outputs with other systems and is consistent with the operational concept. The objectives hierarchy of the system lays out the performance, cost, and schedule objectives that the stakeholders have for the system; this objectives hierarchy provides a satisfaction index for the stakeholders for alternate system designs. The requirements of the system provide constraints and performance ranges for the system in terms of inputs and outputs, and its system-wide and technology-related characteristics. The requirements also state the trade offs that the stakeholders are willing to make in the development of the system and the constraints and performance ranges associated with testing the system. These ﬁrst four concepts deal with deﬁning the design problem. Three additional concepts (functions, components, and interfaces) are part of the design process. Functions are those activities performed by the system (and all other systems) to transform inputs into outputs. Components are the resources of the system that perform the system’s functions. Interfaces connect components; external interfaces connect components of the system to components of other systems, and internal interfaces connect components of the system, to each other. Throughout this entire process, from the operational concept through requirements, it is important to remember that the engineers have to concern themselves with more than just the operational system that the users of the system want, but also the systems relevant to every stage of the life cycle of the system (e.g., the development system, manufacturing system, the retirement system). This chapter described how to read an IDEF0 diagram; IDEF0 is a process modeling technique that will be described in detail in the next chapter and used throughout this book. The software product CORE that will be used extensively in this book was described in terms of its classes and the relationship between those classes for systems engineering. CORE’s data structure is based upon a data modeling technique called entity–relationship (ER) diagrams and is discussed in more detail in Chapter 12. PROBLEMS 2.1 Use the requirements in Table 2.5 to deﬁne the elevator’s requirements. Use the IDEF0 models in Figure 2.4 and 2.5 to deﬁne the functional decomposition of the elevator system and to identify the external inputs and outputs, as well as those that are internally generated and consumed. Use the organization chart in Figure 2.6 to deﬁne the physical decomposition of the elevator components. Enter all of the above information on the elevator as the system into CORE: enter the requirements shown in Table 2.5, enter the functions shown in Figure 2.4 and 2.5, enter the items shown in Figure 2.5, and enter the components shown in Figure 2.6 as elements of the

OVERVIEW OF THE SYSTEMS ENGINEERING DESIGN PROCESS

corresponding classes. Then establish the relevant relations associated with Table 2.7. These relations include hierarchies for the requirements and functions as well as the system with its components. Use the ‘‘specify’’ relation to connect the requirements to the appropriate function, item or system, designate items as inputs or outputs of the relevant functions and allocate each function to the system or appropriate component.

Chapter

Modeling and SysML Modeling

3.1

INTRODUCTION

This chapter serves two major purposes: describes models and their role in the engineering of systems and introduces several modeling techniques associated with SysML. The modeling techniques introduced in this chapter are use case diagrams, sequence diagrams, IDEF0 (Integrated Deﬁnition for Function Modeling), enhanced Function Flow Block Diagrams (EFFBDs), block diagrams, and parametric diagrams. IDEF0 is a process modeling technique that is not part of SysML but will be utilized throughout this book. Models, abstractions of reality, are critical in the engineering of systems. These models start as very high level representations that address what needs the system should meet and how, then progressively deﬁne how the system will meet these needs. These models contain increasingly more mathematical and physical details of the system as the design portion of the development phase ends. The various engineering disciplines create even more detailed mathematical and physical representations of the conﬁguration items (CIs) before the ﬁnal prototype of each CI is produced for testing and integration. During the qualiﬁcation of the system design, these CI prototypes are tested with a test system that itself is comprised of many models of the system’s components, other systems and the context with which the system interacts, models of scenarios that depict how the system will be used, and analysis and simulation models for creating and analyzing the test results. In fact, models are so pervasive in the engineering of systems that engineers must always remind themselves not to confuse reality with the models of reality that are being created, tested, and used. The Engineering Design of Systems: Models and Methods, Second Edition. By Dennis M. Buede Copyright r 2009 John Wiley & Sons, Inc.

MODELING AND SysML MODELING

Every modeling technique is a language used to represent some part of reality so that some question can be answered with greater validity than could be obtained without the model. All languages have a set of symbols or signs, known as semantics, that are used like we use letters and numbers to form expressions. Similarly, every language has a syntax that deﬁnes proper ways of combining the symbols to form thoughts and concepts. Section 3.2 summarizes the descriptive versus normative purposes of models and then categorizes models as physical, quantitative, qualitative, and mental. SysML is a modeling language that is a modiﬁcation of the Uniﬁed Modeling Language (UML) for software engineering. SysML matches somewhat closely with the Traditional Top-Down Systems Engineering (TTDSE). In Section 3.3 we will introduce SysML, including use case and sequence diagrams for high level metasystem interactions, IDEF0 for process or activity modeling, EFFBDs for dynamic behavior modeling, and block diagrams for the structural modeling and parametric models for modeling equations. Note SysML also addresses requirements but uses textual representations of the requirements. Chapter 6 of this text addresses textual representations of requirements. Use case diagrams capture the various systems that comprise the metasystem, one of which is the system of interest. The use case diagram also identiﬁes a number of scenarios in which the systems in the use case diagram interact during the relevant life cycle phase of the system of interest. Each of these scenarios is then deﬁned in more detail in a sequence diagram. Section 3.4 deﬁnes these diagrams and gives examples. Process models address how outputs are transformed from inputs via some function, activity, or task. There are numerous process modeling techniques in use today, one of which is IDEF0. Other process modeling techniques (data ﬂow diagrams and N2 charts) are described in Chapter 12. Process models are graphical representations that provide qualitative descriptions to explain how inputs are transformed into outputs. These process models can be used at both shallow and detailed levels of abstraction. IDEF0, presented in Section 3.5, is a popular modeling technique because it has a rich and standardized semantics and syntax. Function ﬂow block diagrams (FFBDs) and enhanced FFBDs (EFFBDs) are part of SysML for capturing dynamic behavior in a representation that can be simulated. EFFBDs are discussed in Section 3.6. Block diagrams are used within SysML to capture the interconnections between pairs of components within the physical architecture so that interfaces between these pairs of components can be deﬁned. Section 3.7 presents this material. Requirements diagrams are introduced in Section 3.8. Parametric diagrams, used to capture variable relationships in systems of equations for simulating system performance, are discussed in Section 3.9. Exercise Problem 3.1 introduces a process model of the TTDSE process using IDEF0 model. Selected pages of this IDEF0 model will be used in Chapters 6 through 11 to describe the methods that comprise this engineering process.

3.2

MODELS AND MODELING

A model is any incomplete representation of reality, an abstraction. Models can be physical representations of reality. A subscale aircraft is used in a wind tunnel to test the aerodynamics of the real aircraft; this subscale aircraft does not contain the instrument panel used by the pilot or the seats in which passengers sit because they are not relevant (we think) for testing the aerodynamics of the aircraft. Similarly, models can be mathematical. A random number generator can be used to model the propensity of a coin to turn up heads or tails in a ﬂip. Similarly, we can develop either an analytic or a simulation model of an aircraft’s aerodynamics or an information system’s response to user inputs. The wind tunnel data taken from the physical model of the aircraft can be used to reﬁne the simulation data. The simulation data can be used to guide additional wind tunnel tests. Qualitative models are also quite useful. The set of requirements for a system is an example of a qualitative model that serves as a model of the system’s performance and capabilities. Finally, each of us has a number of mental models that we use in everyday life. However, in every case the essence of a model is the question or set of questions that the model can reliably answer for us. Before describing the types of models, discussing the types of questions that can be answered is important. The questions can be divided into three categories: descriptive (or predictive), normative, and deﬁnitive. A deﬁnitive model addresses the question of how should an entity be deﬁned; this is the major category of questions that will he addressed in this book. The focus is building a deﬁnition of how the system is being designed, in terms of its inputs and outputs, functions, and resources. A descriptive model attempts to predict answers to questions for which the truth may or may not be obtained in the future. Descriptive models are the most commonly used in science and engineering. Executable models, which will be discussed in Chapter 12, are descriptive models because they are predicting the behavior of the system’s design in speciﬁc situations given the modeled design deﬁnition of the system. Normative models address how individuals or organizational entities ought to think about a problem and guide decision making. A normative model for decision making, in particular deciding about the engineering of a system, is developed in Chapter 13. Every modeling technique requires a language to establish a representation of reality. Models should be used to provide an answer to one or more questions; these answers should provide greater validity or insight than is possible without the model. Any language has semantics, a set of symbols or signs, which form the basis of representations in the language. In addition, every language has a syntax that deﬁnes proper ways of combining the symbols to form thoughts and concepts. Deﬁnitive models require a rich language, both in terms of semantics and syntax, since these models are used to establish an interpretation of some aspect of reality and communicate that interpretation to a broad range of people and

MODELING AND SysML MODELING

possibly computers. This language must be understandable to its audience. Unfortunately, richness and understandability often conﬂict with each other. That is, making a modeling language richer usually makes it less understandable. A third aspect, formality, is useful for proving that certain characteristics exist or do not exist; formality tends to conﬂict with both richness and understandability. Descriptive models are measured by their power or richness for addressing a wide range of problems, understandability to both wide and narrow audiences, and accuracy or precision with which they can be used to deﬁne the relevant entity. Descriptive models can sometimes be tested as to their predictive accuracy in various situations. This predictive accuracy must be understood by those using the descriptive model because the ability to predict accurately in the situation in which the model is being used cannot be known exactly. Nonetheless, talking about descriptive models as being right or wrong is fruitless — all models are wrong. Rather, the model’s usefulness in terms of predictive accuracy in general and the cost of building and using the model are very relevant. Normative models, on the other hand, cannot be tested but are judged on their understandability and appeal across all disciplines in which they can be used. A normative model for making decisions cannot be tested because the world can never be examined in the same conditions with and without the use of the normative model. Rather, the normative model is tested by decision makers based upon the model’s ability to reﬂect the intuitions of the decision makers or provide logical arguments that refute this intuition. One possible taxonomy of models is shown in Table 3.1. This taxonomy begins by breaking models into physical, quantitative, qualitative, and mental models. A physical model represents an entity in three-dimensional space and can be divided into full-scale mock-up, subscale mock-up, breadboard, and electronic mock-up. Full-scale mock-ups are usually used to match the interfaces between systems and components as well as to enable the visualization of the physical placement of elements of the system. The design of the Boeing 777 replaced the physical mock-ups with a very detailed threedimensional electronic mock-up. Subscale models are commonly used to examine a speciﬁc issue such as ﬂuid ﬂow around the system. A breadboard is a board on which electronic or mechanical prototypes are built and tested; this phrase was legitimized in dictionaries in the mid-1950s but is not used as much now. Quantitative models provide answers that are numerical; these models can be either analytic, simulation, or judgmental models. Simulation models can be either deterministic or stochastic, as can analytic and judgmental models. Similarly, these models can be dynamic (time varying) or static snapshots (e.g., steady state). An analytic model is based upon an underlying system of equations that can be solved to produce a set of solutions; these solutions can be developed in closed form. Simulation methods are used to ﬁnd a numeric solution when analytic methods are not realistic, such as when friction in some form is introduced as an element of the model. When the equations involve the

3.2

MODELS AND MODELING

TABLE 3.1 Taxonomy of Models Model Categories

Model Subcategories

Physical

Full scale mockup Subscale mock up Breadboard

Quantitative

Analytic Simulation Judgmental Symbolic Textual Graphic Explanation Prediction Estimation

Qualitative

Mental

Typical Systems Engineering Questions How much? How often? How good? Do they match? How much? How often? How good? What needs to be done? How well? By what? All of the above!

movement through time of a number of variables, we say the simulation is dynamic, involving differential or difference equations. However, a simulation need not involve time; the model may address spatial issues. Simulations that include uncertainty are often called ‘‘Monte Carlo’’ simulations; Monte Carlo simulations involve the repetitive solution of the same set of equations based upon different samples of the underlying probability distributions for the uncertainty speciﬁed in the equations. Judgmental models provide representations of real-world outcomes based solely on expert opinions. Explicit judgmental models are not used as often as the other types discussed here, but many analysts have found them to be an extremely useful precursor to other quantitative modeling activities. Qualitative models provide symbolic, textual, or graphic answers. Symbolic models are based on logic or set theory, samples of which are provided in Chapter 4. Textual models are based in verbal descriptions; many models of the social sciences use textual models in which a model is described in one or more paragraphs. Many requirements documents in systems engineering are examples of textual models of the system’s ultimate performance. Graphical models use either elements of mathematical graph theory or simply artistic graphics to represent a hierarchical structure, the ﬂow of items or data through a system’s functions, or the dynamic interaction of the system’s components. This use of artistic graphics as a modeling approach is often given the pejorative name of ‘‘view graph’’ engineering. Most engineers view graphical models as one step above textual models. If graphical models can be based on mathematical graph theory, then these qualitative models can be powerful additions to the systems engineers’ toolkit. Finally, we need to address the mental models that we all carry around inside of us as abstractions of thought. The concept of a mental model arose in at least

MODELING AND SysML MODELING

three separate communities relatively independently. Craik [1943] introduced mental models to cognitive psychology as our foundation for reason and prediction. Little was done with Craik’s concept of a mental model until the early 1980s when Johnson-Laird [1983] and Gentner and Stevens [1983] published two books on the subject. The research in cognitive psychology has moved from the question of whether people do have mental models to the question of how best to capture and utilize these mental models for educational and other pursuits. The second ﬁeld in which mental models became popular and useful was that of manual control, comprised of both psychologists and engineers. Early authors in the manual control ﬁeld [Veldhuyzen and Stassen, 1977; Jagacinski and Miller, 1978; Rasmussan, 1979] addressed the use of mental models by system operators for controlling and predicting system performance. The third ﬁeld to adopt mental models [Alexander, 1964; Pennington, 1985] is our ﬁeld of engineering and architectural designers. Alexander [1964] discussed mental pictures as representations of the problem deﬁnition and alternate solutions. Do you have a mental model of the street network in your neighborhood, of your residence? Engineers need to develop a mental model of the system on which they are working to be successful. Modelers who are developing qualitative, quantitative, or physical models clearly have to develop a mental model of the model they are developing. The advantage of these non-mental models is that there is a much clearer communication mechanism; mental models fall down in beneﬁt in terms of enabling communication among people. People engaged in the same conversation may have a very different mental model but due to the imprecise nature of natural language they often feel that they can agree with each other at the end of a conversation even though their models of reality are quite different.

SIDEBAR 3.1 It is tempting to think that a quantitative model is more objective than a mental model and, by extension, that a more complex quantitative model is more objective than a less complex quantitative model. Certainly more complex models are more explicit than less complex models. Also the data inputs to these complex models are more speciﬁc and objective appearing. However, we must always remember that any quantitative model is developed via a mental process of one or more people and is the product of their mental models. Therefore, it is a mistake to ascribe objectivity to models. Complex mathematical models often have subjective assumptions throughout their equations and data.

This book emphasizes the qualitative aspects of systems engineering. As a result, this chapter introduces the qualitative modeling approaches in SysML

3.2

MODELS AND MODELING

and IDEF0. The next two chapters introduce the mathematics of set theory and graph theory, which should provide some mathematical underpinnings and limitations of these modeling approaches. Chapter 13 introduces decision analysis as the quantitative method for framing the design decisions discussed throughout this book. The purpose in developing a model is to answer a question or set of questions better than one can without the model. Often models are used to check each other; non-mental models should always be used to check mental models. This checking process is a two-way street; each model can be assumed to have certain strengths (answers known to be valid within some degree of accuracy or precision). These strengths can be used to help verify the abilities of the other model. Ultimately, a model is developed to provide answers in an area for which we feel we cannot get reliable answers any other way. However, we are commonly looking for more than just an answer; we want to understand ‘‘why’’ the answer is what it is, that is, obtain insight into how the real world works. Qualitative models are typically created to achieve agreement among individuals (shared visions) and to communicate that agreement to other people. Quantitative and physical models are better mechanisms to provide insight. The more speciﬁc a question or set of questions is that a model has to answer; the easier it is to develop a model that can be useful. Models that are expected to answer a wide range of questions or generic questions well are the most difﬁcult to develop and the least likely to provide insight into the logic for the answer. The easiest questions to answer are those for which we are looking for a relative comparison of alternate options: Which aircraft design weighs the most? How much more does one design weigh than another? The hardest questions involve providing an absolute answer: How much does this aircraft weigh? The most effective process for developing and using a model is to begin by deﬁning the questions the model should be able to answer. (This is analogous to deﬁning the requirements for a system.) Then the model should be developed, tested, and reﬁned. The model should be validated, shown to be answering the right questions. Finally, there should be some veriﬁcation process to show that the model is providing the right answers for known test cases. Now we are ready to use the model for unknown test cases. Often, there may be existing models that we believe are appropriate for use. In this case we should again begin by deﬁning the questions to be answered. Then we can decide which model to use, perhaps with some enhancements. There should again be a period of veriﬁcation for the chosen model in relevant cases before usage begins. The incorrect approach to modeling is to begin by building or revising a favorite model before we know what questions need to be answered. People enthralled with the modeling process rather than the question answering process employ this approach far too often. Modeling enthusiasts are more interested in the intrinsic properties of the model than with the model’s ability to answer important questions. Note the more complex the model, the harder it is to obtain that insight we are seeking as to why the answer is what it is. This is

MODELING AND SysML MODELING

why many experienced model builders opt for the most parsimonious (simplest) model that will provide a reasonably accurate answer. Before using a model, it is important to establish the validity of the model. Model validity is difﬁcult to establish and must ﬁrst be deﬁned. Recall from Chapter 1 that a system’s validity addresses whether we have built the right system. By extension model validity concerns whether we have built the right model. Validity of a model has several dimensions: conceptual, operational, and data. Conceptual validity addresses the model representation, that is, the theories employed, the assumptions made. Conceptual validity addresses whether the model’s structure is appropriate to answer the questions being asked. For a qualitative model conceptual validity is the most important. For a quantitative model the operational validity is key; that is, does the model’s output behavior represent that of the real world for the questions being asked. Finally, data validity addresses whether the appropriate inputs were employed in building, testing, and using the model. Data validity for a qualitative model addresses whether the right individuals were involved in creating the model and whether they obtained access to the best set of information about the real world during the creation process. For quantitative models, the selection of a modeling technique may ride on what type of information will be available for running the model. When input data is scarce, judgmental models are often selected. In summary, establishing a model’s validity has to be tied to the model’s ability to answer the questions that the model was designed to address. Models have many potential uses in systems engineering: creation of a shared vision, speciﬁcation of the shared vision, communication of the shared vision, testing the shared vision, estimation or prediction of some quantitative measure associated with the system and selection of one design option over other design options. The shared vision could be the inputs and outputs of the system, the system’s requirements, the system’s architecture, or the test plan for validating the system’s design. As can be seen, all but the last two uses involve a qualitative activity. This is the basis for emphasizing the use of qualitative models as adjuncts to our mental models in this book. Quantitative models remain important, but qualitative models are not given their due value in engineering.

3.3

SysML MODELING

In Table 1.5 there were four topic areas deﬁned for SysML modeling [Friedenthal et al., 2008]: structure, behavior, interaction, and requirements. This is the decomposition provided by the Object Management Group, Inc. (OMG), which produced the speciﬁcation for SysML. Another way of viewing these categories that is more consistent with the organization of this book would be: 1. meta-system modeling with use case and associated sequence diagrams as well as requirements relations with requirements diagram

3.3

SysML MODELING

2. behavior modeling of the system’s activities or processes (including both static and dynamic modeling) using activity and state machine diagrams 3. structural modeling of the system’s components including block deﬁnition and internal block diagrams 4. parametric modeling of performance characteristics of the system 5. the process and structure of that the systems engineering team is taking using package diagrams Section 3.4 will introduce use case diagrams and sequence diagrams. This material is presented in terms of the very important modeling of the system’s interaction with other systems (or the meta-system) that is often not done. Chapter 6 will revisit this material and provide more context about how to use these diagrams. Systems and software engineers have devised many ways to model processes or activities, at all levels of granularity — meta-system, system, through components. The activity or process modeling category within SysML includes state machines, a new modeling technique that combines some properties of Petri nets (see Chapter 12) and control ﬂow diagrams as well as EFFBDs. Not directly mentioned are the standard static, time-lapsed representations of dynamic processes such as IDEF0, data ﬂow diagrams, and N2 charts. This text will continue to stress the value of static modeling techniques such as IDEF0 as a stepping stone for getting to the more complex behavior models, as well as for capturing the inputs and outputs that are passed from function to function in the behavioral model. The process modeling approach primarily employed in this book is IDEF0, which is described in Section 3.5. The SysML framers did include state–machine models and activity diagrams (otherwise called extended function ﬂow block diagrams or EFFBDs). State-machine models are discussed in Chapter 12. EFFBDs are described in detail here in Section 3.6. Table 3.2 provides a categorization of process models into static and dynamic, as well as into SysML versus non-SysML approaches. Chatper 12 covers most of the techniques not addressed here in Chapter 3. Chapter 7 will return to this material and provide a process for building these types of models. TABLE 3.2 Representation of process modeling techniques Static View SysML

Non-SysML

Data ﬂow diagrams Control ﬂow diagrams N2 diagrams IDEF0 diagrams

Dynamic View State machines Activity diagrams EFFBDs FFBDs Behavior diagrams Petri Nets Statecharts ROOMcharts

MODELING AND SysML MODELING

Structural modeling diagrams (block deﬁnition and internal block) are described and illustrated in Section 3.7. These diagrams have a long history in systems engineering and have ﬁnally been formally deﬁned and standardized by SysML. Chapter 8 will provide more detail on how to build these kinds of models. Systems engineers have historically built many types of performance models of their system design so as to estimate ﬁnal performance capabilities of the design prior to fabrication of the initial prototypes. Chapter 9 introduces the types of performance modeling commonly used in the engineering of systems.

3.4

META-SYSTEM MODELING

In order to describe a modeling language we have to describe the way in which the language is used to communicate to its readers/listeners. To describe a language we need to identify the semantics (signs and symbols) and the syntax (composition of signs and symbols) of that language. The following deﬁnitions for semantics and syntax are taken from The American Heritage Dictionary [Berube, 1991]. Semantics: study of relationships between signs and symbols and what they represent. Syntax: way in which words are put together to form phrases and sentences. This and each of the following sections will describe the semantics of the language tool. The syntax will then be described formally or via examples. It is critical that there be a team of engineers and domain experts that is performing the systems engineering process. This team can create a huge problem for itself by diving right into the design of the system without ﬁrst learning about the other systems with which the focus of the design activity is to interact. This is probably the most common and most major problem encountered in the engineering of systems. Chapter 6 introduces the operational concept, which includes scenarios or use cases that are supposed to describe how the system interest will interact with humans and other systems throughout its life cycle. It is in the operational concept that the use case diagram and many sequence diagrams would be used to describe these scenarios. Developing these sequence diagrams is a major part of getting ready to develop the system’s requirements. This section provides the fundamental semantics and syntax for using use case diagrams, sequence diagrams and requirements diagrams within SysML. The purpose of the use case diagram is to provide a higher level of how all of the individual use cases or usage scenarios combine within the operational concept to describe how the stakeholders think the system will be operated.

3.4

META-SYSTEM MODELING

This use case diagram originated in software engineering and is now commonly employed within the engineering of systems. The semantics of a use case diagram contains: 1. 2. 3. 4.

labeled stick ﬁgures for each class of humans or external systems labeled ovals to deﬁne each use case solid lines connecting stick ﬁgures and ovals labeled dashed lines connecting ovals

The syntax is that there is a diagram for each relevant phase of the system’s life cycle, (e.g., operations, training). For a given phase of the life cycle, the appropriate classes of humans (e.g., operators, maintainers) and other external systems are each given a stick ﬁgure. Then all of the possible interaction sequences among the system and these classes of humans and external systems are categorized and labeled as ovals. These interaction sequences are later deﬁned one at a time in a sequence diagram. Actually there is a signiﬁcant amount of iteration between the ﬁrst draft of the use case diagram, the deﬁning of individual sequence diagrams, the improvement of the use case diagram, and so on. Figure 3.1 provides an example of a use case diagram for an elevator. The stick ﬁgures are (1) passenger class of humans, (2) maintenance workers, (3) building personnel, (4) a centralized service center including humans and other technology assets, and (5) the building. The high level operational scenario is of course to use and maintain the elevator. There are four extensions of this basic scenario: responding to a ﬁre, keeping the doors open, rescuing people from a stopped elevator, and ensuring that the load on the elevator is within a safe range. These extensions provide more detail about the basic scenario in speciﬁc situations that may or may not occur. There are two other ovals on this use case diagram for updates to the basic scenario that must always be present: providing electric power and maintaining a comfortable environment. Finally, there is one use case (ﬁx the elevator) that does not involve passengers. In fact, this would be a basic scenario with extensions and inclusions if we were designing a real elevator. For each labeled oval in the use case diagram there should be a sequence diagram that deﬁnes the interactions among it and the other systems (including people, facilities, etc.) that the use diagram depicts as relevant. The semantics of a sequence diagram are:

a labeled vertical line a labeled horizontal arrow that connects two or more vertical lines

One labeled vertical line represents the system of interest. Each vertical line represents an external system with which the system interacts (exchanges inputs

MODELING AND SysML MODELING

Fix Elevator

Respond to Fire > Passenger

Take Elevator >

Keep Doors Open

Maintenance Person

Rescue from Stopped Elevator

Building Personnel

Ensure Safe Weight Level

Centralized Service Center Maintain Comfortable Environment

Provide Electric Power

FIGURE 3.1

Building

Exemplary use case diagram.

and outputs) during the use case. There must be at least two vertical lines. Time is assumed to go from the top to the bottom of the vertical lines. The labeled horizontal arrows represent the ﬂow of items (information, energy, or physical entities) between the systems that the horizontal arrows connect. These items move in the direction of the arrow. The syntax of sequence diagrams dictates that earlier ﬂows in the use case appear above later ﬂows, but time is not represented in appropriately scaled time units. Figure 3.2 provides a simple example for an elevator system in which a potential passenger calls an elevator to go up or down. One contentious issue in sequence diagrams is what the labels of the horizontal arrows should represent. Many authors and practitioners label the arrows with the function being performed by the system of interest. In this book we adopt the convention of labeling the horizontal arrows with a name that represents the item being transferred from one system to another. The reason for this convention will be described in detail in Chapter 6 and is associated with the contention that functional requirements should be written about inputs and outputs rather than functions. Finally, SysML provides a basic representation for deﬁning requirements and a broad set of representations for relating requirements to other requirements and system concepts. Rather than detail this part of SysML, we will use the capabilities in CORE that were described in Chapter 2.

3.5

STATIC BEHAVIORAL PROCESS MODELING WITH IDEF0

Passenger

Elevator 1: Up Service Request 2: Feedback that request was received 3: Feedback that car is on the way 4: Feedback that door is opening 5: Entry Opportunity 6: Floor Request 7: Feedback that request was received 8: Feedback that door is closing 9: Feedback about floor where stopped 10: Feedback that door is opening 11: Exit Opportunity

FIGURE 3.2 Exemplary sequence diagram.

3.5

STATIC BEHAVIORAL PROCESS MODELING WITH IDEF0

While IDEF0 was not included in SysML as a modeling technique, it will continue to be used throughout this book. First, it provides a very useful graphical representation of the interaction of the functional and physical elements of a system. IDEF0 is deﬁnitely not a sufﬁcient modeling representation for the engineering of systems since it is not precise enough to deﬁne a unique dynamic representation of the system’s design. In fact, it is not even a necessary modeling language since other languages have been successfully used for decades in its place. However IDEF0 has gained wide acceptance and standardization and also has been used successfully for decades as an approach to start the modeling process. The IDEF acronym comes from the U.S. Air Force’s Integrated ComputerAided Manufacturing (ICAM) program that began in the 1970s. IDEF is a complex acronym that stands for ICAM Deﬁnition. The number, 0, is appended because this modeling technique was the ﬁrst of many techniques developed as part of this program. More recently the U.S. Department of Commerce [National Institute of Standards and Technology (NIST)] has issued Federal Information Processing Standard (FIPS) Publication 183 [1993a] that

MODELING AND SysML MODELING

deﬁnes the IDEF0 language and renames the acronym, Integrated Deﬁnition for Function Modeling. The roots of IDEF0 can be traced to the structured analysis and design technique (SADT), developed and tested by Doug Ross at SofTech, Inc. from 1969 to 1973. A sample of the modeling languages developed as part of the IDEF family follows. IDEF0: a major subset of SADT; focus is a functional or process model of a system IDEF1: focus is an informational model of the information needed to support the functions of a system IDEF1X: focus is a semantic data model using relational theory and an entity– relationship modeling technique IDEF2: focus is a dynamic model of the system IDEF3: focus is both a process and object state-transition model of the system

3.5.1

IDEF0 Semantics or Elements

An IDEF0 model is comprised of two or more IDEF0 pages. The two semantical elements of an IDEF0 page are functions and ﬂows of material, energy, or information. A function or activity is represented by a box and described by a verb-noun phrase and numbered to provide context within the model (see Figure 3.3). A function in this context is a transformation that turns inputs into outputs. Inputs to be transformed into outputs enter the function box from the left, controls that guide the transformation process enter from the top, mechanisms (physical resources that perform the function) enter from the bottom, and outputs leave from the right. A ﬂow of material, energy or data is represented by an arrow or arc that is labeled by a noun phrase (see Figure 3.4). The label is a noun phrase and represents a set or collection of elements deﬁned by the noun phrase. The label is connected to the arrow by an attached line, unless the arc leaves the page, in which case the label is placed on the appropriate edge of the page.

Verb...noun phrase A#

FIGURE 3.3

Syntax for an IDEF0 function.

3.5

STATIC BEHAVIORAL PROCESS MODELING WITH IDEF0

noun-phrase

FIGURE 3.4 Syntax for an IDEF0 flow of material or data.

3.5.2

IDEF0 Diagram Syntax

An IDEF0 model has a purpose and viewpoint and is comprised of two or more pages, each page being a syntactical element of the model. The IDEF0 model:

Answers deﬁnitive questions about the transformation of inputs into outputs by the system. Establishes the boundary of the system on the context page. This boundary is explicated, if needed, as a meta description. Has one viewpoint; the viewpoint is the vantage or perspective from which the system is observed. Is a coordinated set of diagrams, using both a graphical language and natural language.

The A-0 page is the context diagram, which deﬁnes the inputs, controls, outputs, and mechanisms (ICOMs) for the single, top-level function, labeled A0. The context page establishes the boundaries of the system or organization being modeled by deﬁning the inputs and controls entering from external systems and the outputs being produced for external systems. Other pages in the IDEF0 model represent a decomposition of a function on a higher page, with the exception of the external system diagram page, which is described later. The number of subfunctions for any IDEF0 function is limited to six, or possibly seven, for purposes of a readable display on a page. The decomposition of a parent function preserves the inputs, controls, outputs, and mechanisms of the parent. There can be no more, no less, and no differences. Every function must have a control. An input is optional. Functional boxes are usually placed diagonally on the page with the more control-oriented functions being on the top left and the functions responsible for producing the major outputs being on the bottom right. Arcs are decomposable, just as functions are. Feedback is modeled by having an output from a higher numbered function on a page ﬂow upstream as a control, input, or mechanism to a lower numbered function. Arc decomposition and joining are necessary to minimize the number of arcs on the upper pages of a model, enhancing the readability or communicability. Arc decomposition and joining are handled by branching and joining, respectively. The labeling conventions for joins and branches are shown in Figure 3.5. If an arc is labeled before a branch and not labeled after the arc branches into

MODELING AND SysML MODELING

A means A A

A means

A A

means B

A means B

A∪B B

FIGURE 3.5 Labeling conventions for branches and joins.

two or more segments (as shown on the ﬁrst of four examples in Figure 3.5), then the arc before the branch carries on after the branch. Similarly, if an arc is labeled after two or more arcs join (see the second example in Figure 3.5), then the label after the join also applies to the arcs before the join. If the label before a branch (after a join) does not apply to one or more of the arcs after the branch (before the join) then the arcs that deviate must have their own label. These labels of the exception branches have to be subsets of the labels before the branch (after the join), as shown in the bottom two examples of Figure 3.5. Three different types of feedback are possible within an IDEF0 page: control, input, and mechanism. (The general topic of feedback will be discussed in more detail in Chapter 7.) Feedback in an IDEF0 diagram enables data or physical resources to be sent against the ﬂow, down and to the right, so that closed-loop control can be used to improve key performance issues. The semantical protocols for showing these three types of feedback are shown in Figure 3.6. A control arc indicating feedback must go up and over the functions involved, coming down on the function for which it is a control. Input feedback is indicated by an arc that goes down and under the functions involved, coming up and into the function for which it is an input from the left. Finally, mechanism feedback must also be achieved by an arc that goes down and under the function for which it is a mechanism. A major difﬁculty with IDEF0 models is determining whether an item should be an input or control. The primary distinction is that inputs are items that are transformed or consumed in the functional process associated with the production of its outputs. Controls, on the other hand, are not transformed or consumed, but rather are information or instructions that guide the functional

3.5

STATIC BEHAVIORAL PROCESS MODELING WITH IDEF0

label up & over Control Feedback

Input Feedback label down & under Mechanism Feedback

down & under

label

FIGURE 3.6 Feedback semantics within an IDEF0 page.

process. Typical examples of controls are a blueprint and recipe instructions (e.g., bake at 3751F for one hour, use a 9.5- by 12-inch baking pan). Nonetheless, there are many times when it is very difﬁcult to determine whether an item is an input or control. In these cases, the decision is the author’s, with the provision that every function must have at least one control while inputs are optional. Readers of an IDEF0 model are often surprised to see a function with a control and output, but no input. This seems to suggest a counterexample to the conservation of mass and energy in physics. Remember though that outputs of a function in an IDEF0 model do not have to have mass or energy but can be information. A common example of a function that can produce an output without an input is a function that produces a time mark for other parts of the system. This function receives a control whenever the time mark is needed and uses its timekeeping resources to produce the time mark as an output.

3.5.3

IDEF0 Model Syntax

An IDEF0 model is a functional decomposition of the top-level, or A0, function. The decomposition is a hierarchy, as shown in Figure 3.7. The function numbers are shown on the right and the corresponding IDEF0 page numbers are shown on the left. The function that is being decomposed is the parent, while the functions decomposing it are called its children. The node numbering process deﬁnes the tree. The node numbering convention as shown in Figure 3.7 is summarized in Table 3.3.

MODELING AND SysML MODELING

Page #’s

Function #’s A-11

A-1

A-0

A-12

A-13

A-0 A0

A1, A3

A11

A12

A33

A13

A31 A32

A331 A332

A33 A34

A333 A334 A335

FIGURE 3.7 IDEF0 functional decomposition.

As an example of this decomposition process, the A0 page, shown in Figure 3.8, deﬁnes the decomposition of the A0 function by three functions in this case. Note there are two inputs, three controls, three outputs, and one mechanism for the function A0; each of these ICOMs is given a generic label to emphasize the conservation of ICOMs. On the decomposition of A0 into Al, A2, and A3, there are again two external inputs, three external controls, three external outputs, and an external mechanism. Note that I1, C2, C3, and M1 branch on this A0 page. In addition, the joining of outputs from Al and A2 produces 02. A number of internal items are produced, some of which branch and join. IDEF0 models can also address the interaction of the system with other systems. This interaction is modeled on the A-1 page, which takes the A0 function and places it in context with other systems or organizations. This representation is often critical to understand the relationship of the system being addressed to the system’s outside world and establishing the origination of inputs and controls and the destination of outputs. An IDEF0 model also has a data dictionary. An IDEF0 model should have a glossary page that deﬁnes the special words and acronyms in the labels and

TABLE 3.3 IDEF0 Page Hierarchy Page Number(s) A 1 A 0 A0 A1, A2, y A11, A12, y, A21, y y

Page Content Ancestor or External System Diagram Context or System Function Diagram (contains A0) Level 0 Diagram with ﬁrst tier functions speciﬁed Level 1 Diagrams with second tier functions speciﬁed Level 2 Diagrams with third tier functions speciﬁed y

3.5

STATIC BEHAVIORAL PROCESS MODELING WITH IDEF0

Transform I1 & I2 into O1, O2 & O3 as determined by C1, C2 & C3 using M1

I1 I2

O1 O2 O3 A0

I1.1

Transform I1.1 into O1 & O2.1 as determined by C1 & C2 using M1.1 A1

O1 O2.1

Transform O2.1 & I1.2 into O2.2 as determined by C2, C3 & O1 using M1.2 A2

I1.2

Transform I2 into O3 as determined by C2 & C3 using M1.3 A3

I2 M1.2 M1.1

O2.2

M1.3

FIGURE 3.8 Functional decomposition in an IDEF0 model. Showing the preservation of inputs, controls, outputs, and mechanisms.

functions of the model. The data dictionary deﬁnes the arc decompositions. These decompositions reﬂect the arc branches and joins in the model. The dictionary also describes which functions use/produce which data elements.

3.5.4

IDEF0 Advanced Concepts

Advanced concepts to be discussed in this section are loops, tunneling, functional activation rules, exit rules, and call arrows. IDEF0 allows the use of loops to show memory storage and feedback (see Figure 3.9). A loop is showing that there is feedback involved in the

MODELING AND SysML MODELING

Memory Storage label

label Memory Feedback

FIGURE 3.9 Memory semantics in IDEF0.

decomposition of the function shown with the loop. Usually the loop is not needed because the feedback will be seen on the decomposition. If the function is not going to be decomposed, it may be wise to show the loop. There are very few instances in which a loop is appropriately shown. Tunneling is a technique within IDEF0 to hide an input, control, output, or mechanism in part of the model. The use of parentheses around either the head or tail of an arrow depicts a tunnel in IDEF0. Parentheses around the head of an arrow that is entering a functional box indicates that the input, control, output, or mechanism associated with that arrow will not be seen on the decomposition of that function; that is, the ICOM is going underground and may or may not reappear. If the ICOM does reappear, it will have parentheses around its tail to depict that it is exiting the ground. The rationale for tunneling is that certain ICOMs are not particularly relevant for understanding the functional model at speciﬁc levels of detail and therefore should not clutter up these pages of the model. Each function is activated when sufﬁcient inputs and controls are present to produce the relevant outputs, given those inputs and controls. This functional activation is typically deﬁned as a set of rules. A rule is a set of ‘‘if y, then y‘‘statements, or pre-conditions and post-conditions. Boolean algebra is used to specify these rules. These activation rules are embedded in each function; a ‘‘for exposition only,’’ or EEO page, is often used to articulate the activation rules of a particular function or sets of functions. For each function there are one or more exit criteria that determine when the function has completed its execution. Typically, the exit criterion is associated with the production of one or more outputs. If more than one output may be produced by a given function, then it is critical to state the exit criteria. The ﬁnal advanced concept is that of a call arrow. A call arrow is an arrow that breaks all of the rules of ICOMs that have been presented so far and is seldom used in the author’s experience. The call arrow exits the bottom of an activity’s box and points toward the bottom of the page; see FIPS Publication

3.6

DYNAMIC BEHAVIORAL PROCESS MODELING WITH EFFBDS

183 [1993a] for an example. The label attached at the end of the call arrow signiﬁes another box that may be part of the IDEF0 model, or part of another IDEF0 model. The call arrow is indicating that there is no decomposition of the activity from which the call arrow is exiting, but that there is a decomposition of the activity at the box associated with the label of the call arrow. The advantage of the call arrow is that fewer pages need to be part of the IDEF0 model if several of the boxes have the same decomposition. 3.5.5

Systems Engineering Use of IDEF0 Models

A major emphasis in this book is the development of a functional architecture for the system that deﬁnes what functions the system must perform to transform the system’s inputs into its outputs. An IDEF0 model, minus the mechanisms, can be used to deﬁne the functional architecture. As part of the development of the allocated architecture the system’s functions are allocated to the system’s components and CIs. This allocation of functions is captured by adding the mechanisms to the functional architecture, producing a description of the allocated architecture.

3.6

DYNAMIC BEHAVIORAL PROCESS MODELING WITH EFFBDS

Function ﬂow block diagrams (FFBDs) were traditionally used in conjunction with N2 diagrams as the original approach to functional decomposition in systems engineering. (In this book we are substituting IDEF0 for N2 diagrams; N2 diagrams are covered in Chapter 12 for the interested reader.) Later FFBDs were extended and enhanced to become EFFBDs. The extended FFBDs added more types of dynamic control logic. The enhanced FFBDs included some items into the models for better explication and understanding. This section ﬁrst presents the full set of control logic of EFFBDs. Then shows how the items will be added. An EFFBD model contains all of the information in an IDEF0 model plus sufﬁcient information to create a unique discrete event simulation of the dynamic behavior of the system. This is quite an added beneﬁt over the IDEF0 model, but it also requires additional sophistication to create. The view adopted here is that the IDEF0 model is a stepping stone to the completed EFFBD model for beginning systems engineers. Many experienced systems engineers can skip the IDEF0 model and create the EFFBD directly. However there are many other experienced systems engineers who view the IDEF0 modeling process as an important learning and communication process for the stakeholders. An EFFBD model has pages just as an IDEF0 model does. In fact, one could take an IDEF0 model, add control logic to each page, and end up with an EFFBD model. So the EFFBD model provides a hierarchical decomposition of the system’s functions with a control structure that dictates the order in which

MODELING AND SysML MODELING

the functions can be executed at each level of the decomposition. The control structure and arrival sequence of ‘‘triggers’’ (special control inputs) determines this order. This makes the syntax and semantics of an EFFBD model identical to that of an IDEF0 model. The only semantical difference between an IDEF0 and EFFBD page is that the EFFBD has control symbols and lines that are not present in IDEF0. These control symbols and lines will be the main emphasis of this section. In the original, or basic, FFBD syntax there were four types of control structure that were allowed: series, concurrent, selection, and multiple-exit function. A set of functions deﬁned in a series control structure (see Figure 3.10) must all be executed in that order. In fact, the second function cannot begin until the ﬁrst function is ﬁnished, and so on. (Note that in the diagrams shown in this chapter the two nodes at each end with missing center panels on the top and bottom of the functional rectangles are functions that are outside of the decomposition of the system function.) Control passes from left to right in FFBDs along the arc shown from outside (depicted by a function in a box with broken top and bottom lines) and activates the ﬁrst function. When the ﬁrst function has been completed (i.e., the function’s exit criterion has been satisﬁed), control passes out of the right face of the function and into the second function, and so on. (Note that the little solid squares in the upper left corner of functions 1 and 2 are a software construct of CORE that indicate the function has been further decomposed.) The concurrent structure (Figure 3.11) allows multiple functions to be working in parallel, thus this structure is sometimes called ‘‘parallel.’’ However, the concurrent structure should not be confused with the concepts of parallel in electric circuits or redundant systems. Essentially control is activated on all lines exiting the ﬁrst AND node and control cannot be closed at the second AND node until all functions on each control line entering this second AND are completed. This control structure is almost always appropriate for the external systems diagram; the external systems typically act concurrently with each other and the system in which we are interested. The concurrent control structure is also common for the ﬁrst level functional decomposition of the system function. A selection structure and a multiple-exit function achieve essentially the same purpose: the possibility of activating one of several functions. The multiple-exit function (see Figure 3.12) achieves this by having a function placed at the fork of the selection process to make the selection explicit; this is the preferred approach to the selection structure.

1 Ref.

Perform Design Activities

2 Perform Integration Activities

FIGURE 3.10 A series function flow block diagram.

Ref.

3.6

DYNAMIC BEHAVIORAL PROCESS MODELING WITH EFFBDS

1.1 Perform System Level Design Activities 1.2 Ref.

AND

Perform Subsystem Level Design ...

2 AND

Perform Integration Activities

1.3 Perform Component Level Design ...

FIGURE 3.11 A concurrent control structure in an FFBD.

When the selection function has been completed, one of the two or more emanating control lines is activated. Each control line can have zero, one, two, or more functions on it. Additional control structures, such as concurrent, can be placed on any of these exiting control lines. Once all of the functions on the activated line have ﬁnished execution, control passes through the closing OR node. Each exit criterion for the control lines exiting the multiple-exit function appears has a label on the control line. (Note there is an exit criterion for every function with only one exit but the exit criterion is not commonly shown on the exiting control line. The engineer may add a label for this purpose if desired.) For the selection construct, which is an exclusive or, the ﬁrst OR node passes control to one of the exiting control lines in a manner that is unspeciﬁed on the diagram. This control line stays active until the set of functions on that control line are completed; control then passes through the second OR node. Figure 3.9 would be a selection construct if the AND nodes were OR nodes. Since the passing of control at the ﬁrst OR node is not deﬁned on the diagram, the author strongly recommends the use of a multiple-exit function instead of the selection control construct. Additional control structures have been added to FFBDs to form what are called enhanced FFBDs: iteration, looping, and replication. See Sidebar 3.2 for a comparison of FFBD control constructs to structured programming. Looping (Figure 3.12) is the repetition of a set of functions, based upon a speciﬁc criterion. The loop control structure begins with an LP control node and ends with a second LP node, as shown in Figure 3.12. The exit criterion for a loop is shown on the line that closes the two LP nodes. In the loop structure it is possible to exit the loop if the appropriate criterion has been satisﬁed.

MODELING AND SysML MODELING

SIDEBAR 3.2: STRUCTURED PROGRAMMING AND FFBD CONSTRUCTS These constructs are quite analogous to those of structured programming, which began in the late 1950s and early 1960s with people such as Bohm, Dijkstra, Jacopini, and Warnier [De Marco, 1979]. Initially, the goal of structured programming was to deﬁne programming control structures that enhanced readability and improved testing. However, the goal evolved to deﬁne the control structures that would enable proving the correctness of an algorithm. While correctness proofs are still a goal, it was clear to these early investigators that program simplicity was critical. An intermediate goal to a correctness proof became the identiﬁcation of the minimum set of logical constructs that would be sufﬁcient to write any program. Bohm and Jacopini [1966] showed that only two constructs are necessary beyond the obvious series processing construct: ‘‘if-then-else’’ and ‘‘do-while.’’ The if-then-else construct is the equivalent of the multiexit function in FFBDs for situations in which a function does not need to be repeated. For repetitive activities that ﬁt within if-then-else, the looping control structure is used. The iteration control structure is the same as the do-while programming construct. The other FFBD control structures are needed for implementation-peculiar issues of a system: Concurrent structures represent multiple resources of the system performing different functions simultaneously, and replication represents multiple resources performing the same function simultaneously.

Iteration is the repetition of a set of functions, as often as needed to satisfy some domain set; this domain set must be deﬁned based upon a number or an interval. The iteration control structure begins with an IT control node and ends with a second IT node, see Figure 3.12. The domain set for the iterative repetition is shown on the line closing the two IT nodes. Finally, replication is the repetition of the same function concurrently using identical resources. This repetition is shown using the stacked paper icon; the reader can see an example of this in the section of Chapter 12 on behavior diagrams. This control structure is appropriate for certain physical designs and some functional architectures. In general FFBDs and EFFBDs do not show the inputs and outputs for functions. However, the SysML examples of EFFBDs do show at least a subset of the most important inputs and outputs, bringing the diagrams closer to IDEF0 diagrams. Remember, IDEF0 has no way to capture the dynamic information that EFFBDs do.

FIGURE 3.12

Selection and multiple-exit functions in an FFBD.

3.7

MODELING AND SysML MODELING

STRUCTURAL MODELING OF THE SYSTEM’S COMPONENTS

Systems engineers have been using block diagrams since the beginning of systems engineering. However there has been no standardization of how to construct these block diagrams, no uniform syntax and semantics. SysML has provided a much needed syntax and semantics. A block is some element within the spectrum from meta-system down to conﬁguration item (CI). Each element represents a set of resources (people, hardware, software, etc.) that can be used to perform one or more functions as inputs are transformed into outputs. The purpose of the block diagram is to display which blocks are connected to others based on either a hierarchical relationship or on a peer to peer basis. Block deﬁnition diagrams represent hierarchical relationships such as how one block is composed of several other blocks. Internal block diagrams show which blocks within a higher level block are connected to each other via interfaces. The semantics for the block deﬁnition diagram include a labeled rectangle to deﬁne blocks, a labeled connector with a diamond on one end and an arrow head on the other to show the hierarchical relationships. Figure 3.13 shows these two syntactic elements. Note the full SysML semantics [Friedenthal et al., 2008] includes many other elements, but these two are the basic ones that will be used later in Chapter 8. Figure 3.14 shows the syntax of a block deﬁnition diagram for the elevator system and its subsystems that was discussed in Chapter 2. The semantics of an internal block diagram (see Figure 3.15) include a labeled rectangle for the speciﬁc blocks that compose the higher level block that is the subject of the diagram, small unlabeled blocks on the boundary of the larger labeled blocks to deﬁne the connection between the block and the interface to another block, and unlabeled lines to show the interfaces or ports

Name of Component

Name of subcomponent Number of multiplicities

Number of multiplicities

The labeled rectangle represents a component (from meta-system to CI) of the system with the name of the component inside the rectangle. The labeled connector shows a decomposition relationship (from the end with the diamond to the end with no diamond). An abbreviated name of the component that is lower in the hierarchy is often shown at the end with no diamond.

Note “number of multiplicities” means the number of components that are associated with the component on each end of the connector. If the multiplicity is1 at either end, the multiplicity is commonly left blank. Sample multiplicities include 0..1(zero to one), 0..*(zero to many),1..* (one to many), 1..n (one to n),n (exactly n).

FIGURE 3.13 Semantic elements of a block definition diagram.

3.7

STRUCTURAL MODELING OF THE SYSTEM’S COMPONENTS

Hallway Passenger Interface

Elevator System c1

Elevator Controller

car

Elevator Car 1..*

Maintenance and Service

FIGURE 3.14 Exemplary block definition diagram (syntax) for an elevator.

Name of Component

The labeled rectangle represents a component (from meta-system to CI) of the system with the name of the component inside the rectangle. The unlabeled connector shows a connection relationship between two components that comprise a higher level component. A port associated with the component and the connector, designating the connection of the two.

FIGURE 3.15

Semantic elements of the internal block diagram.

100

MODELING AND SysML MODELING

: Elevator Car [1..*]

: Elevator Controller

: Hallway Passenger Interface

: Maintenance and Service

FIGURE 3.16

Exemplary internal block diagram for subsystems of an elevator system.

that connect blocks. Again, there are more elements of the semantics for an internal block diagram but these will sufﬁce for an introduction. Figure 3.16 shows an internal block diagram showing the interface connections among the subsystems of the elevator.

3.8

REQUIREMENTS MODELING

SysML also includes diagrams for requirements modeling. These diagrams show the requirements taxonomy being used by the systems engineering team. Far too many systems engineering teams do not have a requirements taxonomy so this feature of SysML should dramatically improve the practice of systems engineering. Chapter 6 of this book covers one possible requirements taxonomy. In addition, SysML includes diagrams for showing the relationships established by the systems engineering team between each requirements and speciﬁc system functions, components, items (inputs and outputs of functions), and interfaces. Establishing these kinds of relationships was covered in the previous chapter as part of learning how to use CORE so it will not be repeated here.

3.9

PERFORMANCE MODELING

SysML uses a combination of block deﬁnition and parametric diagrams to enable the systems engineer to deﬁne performance and trade off models for use as part of the design process. The semantics of the block deﬁnition diagrams for performance modeling is not quite the same as that for block diagrams, see Figure 3.17. A rectangle, called a constraint block, is used to deﬁne each major variable for which an equation or constraint is deﬁned. Besides the name of the variable appearing in the rectangle, the constraint equation appears inside the delimiters – {y}. In addition, a list of parameters used in the equation with their mathematical abbreviations is shown in the rectangle below a separating

3.9

Name of Constraint Variable {constraint equation} -------------------- ----------- ------ ------ ------- -parameters

PERFORMANCE MODELING

101

The labeled rectangle represents a constraint variable for use in defining the equations in the parametric diagram.

The unlabeled connector shows a decomposition relationship (from the end with the diamond to the end with no diamond).

FIGURE 3.17 Semantic elements for the block definition diagram used for perfor mance modeling.

line. The same sort of connecting line is used to show decomposition as in the block diagram case. Multiplicities are not needed. Figure 3.18 shows an example of a partial fundamental objectives hierarchy for a hypothetical elevator system.

FIGURE 3.18 Exemplary block definition diagram for the fundamental objectives hierarchy of an elevator system.

102

MODELING AND SysML MODELING

The labeled round tangle represents a constraint, as defined by an equation, that is needed in the performance model.

Name of Constraint & Associated Equation

The labeled rectangle represents an input variable that is needed as part of one of the constraint equations.

Name of Input Variable Needed in Constraint Equation

The labeled connector shows a connection relationship between two concepts, either constraints or input variables. A port associated with a constraint equation for a variable from another concept.

FIGURE 3.19

Semantic elements for the parametric diagram.

The second SysML diagram used as part of specifying a performance model is called a parametric diagram. The parametric diagram contains roundtangles for the variables with equations and rectangles for the input variables associated with those equations. Regular lines are used to connect the concepts in the roundtangles and rectangles. Finally, a small rectangle is used to show connecting ports for the roundtangles. These connecting ports are associated with variables being used in the equation. Figure 3.19 shows the semantics of the parametric diagram.

3.10

SUMMARY

The role of qualitative modeling in the engineering of systems is essential. This chapter introduced modeling, purposes of models, and categories of models and discussed how engineers use models in the engineering of a system. Models are used to answer questions for which better answers are needed than currently exist; each modeling technique has its own language of symbols and conventions for combining symbols into higher level concepts. A model is an abstraction of reality; models were characterized for the purposes of this book as mental, qualitative, quantitative, and physical. Each type of model has its advantages in terms of the types of questions that it answers best, as well as the development and operational costs for the model. SysML’s diagrams were introduced. The meta-system approaches of use case diagrams and sequence diagrams were described and illustrated for the elevator system that will be used throughout this book to illustrate the engineering of a system. Next, IDEF0, a commonly used process modeling technique, was introduced and described in sufﬁcient detail so that the reader should not only be able to

PROBLEMS

103

read an IDEF0 model authored by someone else but will be able with additional practice to develop IDEF0 models on her or his own. This process modeling technique was introduced here because this book concentrates on the methods to be used in the engineering of systems, and some process modeling technique is needed to describe these methods. IDEF0 has the advantage of being a good communication tool as well as having a standardized syntax and semantics that do not vary by organization and discipline. Enhanced Function Flow Block Diagrams (EFFBDs) were described next as a way to capture the dynamic execution of functions within the system. EFFBDs have a general set of control structures that overlay the functional decomposition in an IDEF0 model to capture the unique dynamics envisioned within the system. Next the block diagram semantics and syntax introduced by SysML were presented for both block deﬁnition diagrams and internal block diagrams. The former shows the decomposition of the physical architecture. The second shows the interface connections within a speciﬁc decomposition of a component. Finally the new concept of parametric diagrams to deﬁne the performance modeling being done within the engineering of the system is presented.

PROBLEMS 3.1 Reproduce the IDEF0 diagrams of the process for engineering a system in Appendix B using CORE. You must pay attention to details of content as well as format. Both will be graded very carefully. 3.2 Create an FFBD diagram in CORE for each page of the IDEF0 model in Appendix B using CORE. Write a justiﬁcation for the control logic of each diagram. 3.3 Describe at least three ways to estimate how much storage space would be needed if all of the emails sent during a 24 hour period from all of the people in the United States to anyone else in the United States were intercepted.

Chapter

Discrete Mathematics: Sets, Relations, and Functions

4.1

INTRODUCTION

Chapter 4 introduces material from the ﬁeld of discrete mathematics. Much of this chapter will be review material (e.g., sets and functions) for most readers. The concepts of sets, relations, and functions are deﬁned, discussed, and illustrated. A function, with which almost everyone is familiar, is shown to be a specialization of a relation, which in turn is a specialization of a set. There are some key concepts introduced here that will be referred to in many of the succeeding chapters. For example, we will be discussing requirements and requirements documents in Chapter 6. Many system-level requirements documents are very large, larger than they need to be. These large system-level requirements documents can contain thousands and even tens of thousands of requirements. Examples might include:

The system shall be able survive attacks from another computer system. The system shall be able survive buffer overﬂow attacks from another computer system. The system shall be able to survive stack-based buffer overﬂow attacks from another computer system. The system shall be able to survive stack-based buffer overﬂow attacks from an internal employee. The system shall be able to survive buffer overﬂow attacks against its operating system.

The Engineering Design of Systems: Models and Methods, Second Edition. By Dennis M. Buede Copyright r 2009 John Wiley & Sons, Inc.

104

4.1

INTRODUCTION

105

The system shall be able to survive buffer overﬂow attacks against its application programs. The system shall be able to survive buffer overﬂow attacks originating in emails. The system shall be able to survive buffer overﬂow attacks while connected to web sites on the Internet. And more of the same.

In Chapter 6 we will present an approach to writing such requirements and make the point that only one or a few of the above requirements should be in the system-level requirements document. We will use the concept of a partition, introduced and deﬁned here in Chapter 4, to make this case. A partition, based on the set theory introduced in this chapter, ensures that the requirements are not overlapping and are complete. Satisfying the non-overlapping part will be relatively easy, but it is amazing how often it happens in practice. Achieving the completeness is a goal that is seldom, if ever, achieved. But there are approaches based on a partition that can help. Many requirements documents contain duplicate, triplicate, and higher copies of requirements. Over time some of these copies of requirements get changed while others do not, resulting in inconsistent requirements such as happened on the Space Shuttle for operations in ambient temperatures, resulting in part in the explosion of the Challenger in 1986. Getting the concept of a partition of a set is key to many aspects of systems engineering. In Chapter 7 we will discuss functions that systems perform in transforming their inputs into their outputs. When we have this discussion, you should remember the deﬁnition of a mathematical function, which we cover here in Chapter 4. What you may not have learned previously is the concept of a mathematical relation, which is a weaker concept than that of a mathematical function. In order to perform mathematical analyses of our system’s functional architecture we will need eventually to be able to satisfy the mathematical deﬁnition of a function, not simply a relation, provided in this chapter. We will also need to recognize that we are dealing with relations when we are dealing with higher level functions of a system. Ensuring that our functional decomposition is a partition will arise again and again. As part of the discussion of functional architectures in Chapter 7, we will be talking about decomposing higher level functions into sets of lower level functions. (Note the word set has been used again.) The mathematical concept of composition is deﬁned here in Chapter 4 and discussed relative to hierarchical decomposition; mathematical composition will be shown to be a very limited representation of the functional modeling described in Chapter 7. Two advanced concepts, power set and partial ordering, are introduced in this chapter. These concepts have great usefulness to the theoretical development of the engineering of systems, most of which is beyond the scope of this book but elements of which are discussed in Chapters 6, 7, and 9. The interested

106

DISCRETE MATHEMATICS: SETS, RELATIONS, AND FUNCTIONS

reader is referred to Mott et al. [1986] and Rosen [1995] for more details on set theory. Larsen and Buede [2002] provide a mathematical structure for performing early validation of requirements using many of the set theory concepts presented in this chapter. Section 4.2 introduces the general concept of a set and then discusses special characteristics of sets, including operations on sets, the partition of a set, and the power set of a set. Section 4.3 deﬁnes relations in terms of sets. In particular, important characteristics of relations are deﬁned. The partial ordering on a set is introduced and illustrated. Section 4.4 discusses functions and the composition of functions. There are no models introduced in this chapter, but all of this material is critical in understanding the development of models, as well as the power and limitations of models. Software engineers often make much more use of the discrete mathematics presented here than do the engineers of systems, but the material has the same richness and importance to engineers of systems and should be utilized to a fuller degree in the future. In addition, having a grasp of this material is essential to carrying on a conversation about architectures with many software engineers. I have seen systems engineers lose important and valid arguments to software engineers because the systems engineers were not equipped to understand what the software engineers were saying.

4.2

SETS

A set is a collection of well-deﬁned objects, called elements or members. These elements or members are said to belong to the set. Sidebar 4.1 deﬁnes the mathematical symbols used in these and other deﬁnitions.

SIDEBAR 4.1 GLOSSARY OF MATHEMATICAL SYMBOLS

A e D g + , -,. 3

is an element of is not an element of is a subset of is a proper subset of is not a subset of is a superset of is a proper superset of intersection union implies if and only if

4.2

6¼ U U A ’ ( D

| B,: 4 3

SETS

107

is not equal to the null set the universal set the complement of A for all there exists such that given that not (negation) and or

Examples of sets are:

An interval of numbers [7, 21] The students in SYST 520 at George Mason University during the spring semester of 1996 The categories of inputs to elevator The possible states or outcomes that a particular input to the elevator can take The functions of an ATM (automated teller machine)

4.2.1

Writing Set Membership

A set is denoted by capital letter A, B, X, Y, with the exception of sets that are functions, which will be denoted by a lowercase italic, letter. Members are also denoted by lowercase letters: a, b, x, y. The mathematical expression of set membership is x 2 A : x is an element of A x2 = A or : ðx 2 AÞ : x is not an element of A

4.2.2

Describing Members of a Set

There are at least ﬁve ways to describe the members of a set. 1. A is the set of elements, x, that satisﬁes the property (or predicate), p(x). A={x|p(x) is true} (braces are the common delimiter of a set’s deﬁnition). The property p(x) must be well-deﬁned, that is, able to be determined by means of rules. One test of such a property is called the

108

DISCRETE MATHEMATICS: SETS, RELATIONS, AND FUNCTIONS

clairvoyant’s test — a clairvoyant is able to predict the future or describe the past/present perfectly. Is the property or rule deﬁned sufﬁciently well that the clairvoyant can answer the question? For example, the property ‘‘Is tall’’ does not meet the clairvoyant’s test, but the property ‘‘is taller than 6 feet 3 inches’’ does. 2. Complete enumeration is the listing of all of the members of the set. A1 ¼ f0; 1; 2; 3; 4g A2 ¼ fstudent1 ; student2 ; . . . student31g 3. Use the characteristic function of the mA ðxÞ ¼

1 0

for x ¼ 0; 1; 2; 3; 4 otherwise

where mA(x) is the characteristic function of set A for elements, x, in the set, U, of all elements. For conventional (crisp, nonfuzzy) sets, mA(x) may only take the values 0 for nonmembers or 1 for members. 4. Use recursive deﬁnition: A={xi+1=xi+1, i=0, 1, 2, 3; where x0=0}. Here A is deﬁned by a recursive formula. 5. Use one or more set operators such as union, intersection, and complement. These operations should be familiar to most readers and will be deﬁned shortly.

4.2.3

Special Sets

U: the universal set or set of all possible members. U: the null set, a set with no elements. F and {F} are not the same. F has no elements, while {F} has one.) We can write F={xAU | x 6¼ x}. Singleton set: a set with only one element. Finite set: a set with a ﬁnite number of distinct elements. Inﬁnite set: a set with an inﬁnite number of distinct elements. For example: A1={1, 2, 3, 4, y, 101} is ﬁnite, A2={1, 2, 3, 4,y,} is inﬁnite, and A3={x, {1, 2}, y, {z}} may be ﬁnite or inﬁnite. The ﬁniteness of A3 depends on whether x and y are ﬁnite or inﬁnite. (Note {1,2} and {z} are sets, but each is only one element of A3. Also note that z is not an element of A3, but {z} is.) Subsets or set inclusion: if A and B are two sets, and if every element of A is an element of B, then A is a subset of B, ADB. If A is a subset of B, and if B has

4.2

SETS

109

B A

FIGURE 4.1 Set inclusion.

at least one element that is not in A, then A is a proper subset of B, A B. See Figure 4.1. Equality of sets: if A and B are sets, and A and B have precisely the same elements, then A and B are equal, A=B. The following properties follow from the above deﬁnitions: ADA; a set is a subset of itself. FDA, ADU. The null set is a subset of every set; every set is a subset of the universal set. If F 6¼ A, then F A. If a set is not the null set, then the null set is a proper subset of the set. If ADB and BDA, then A=B. If two sets are subsets of each other, then they are equal. If ADB and BDC, then ADC. Set inclusion is transitive, a property that we will formally deﬁne later. 4.2.4

Operations on Sets

The following operations are performed on sets: Absolute complement, A: Let ADU. A¼ fx jx 2 = Ag ðNote F ¼ U; U¼F; A ¼ AÞ See Figure 4.2. Relative complement of A with respect to B, B A: Let A and B be sets, B A={x|xAB and xeA}. The relative complement is also called set difference. See Figure 4.3. Union of A and B, A,B: A,B={x | xAA or xAB or both}.

FIGURE 4.2 Absolute complement.

110

DISCRETE MATHEMATICS: SETS, RELATIONS, AND FUNCTIONS

u B

B-A

FIGURE 4.3 Relative complement.

Intersection of A and B, A-B: A-B={x | xAA and xAB}. (Note A and B are called disjoint if A-B=F. See Figure 4.4. Boolean sum (symmetrical difference), A+B or ADB: A þ B ¼ fxjx 2 A or x 2 B; but not bothg ¼ ðA BÞ [ ðB AÞ The following properties of the above set operations can be easily derived: 1. 2. 3. 4.

A,F=A, and A-F=F. A,U=U, and A-U=A. Idempotent: A,A=A, and A-A=A Associative: ðA [ BÞ [ C ¼ A [ ðB [ CÞ ðA \ BÞ \ C ¼ A \ ðB \ CÞ

5. Commutative: A,B=B,A, and A-B=B-A 6. Distributive: A [ ðB \ CÞ ¼ ðA [ BÞ \ ðA [ CÞ A \ ðB [ CÞ ¼ ðA \ BÞ [ ðA \ CÞ 7. DeMorgan’s Laws: ðA [ BÞ ¼ A \ B, and ðA \ BÞ ¼ A [ B

u A A∩B

FIGURE 4.4 Set intersection.

4.2

SETS

111

Example Use DeMorgan’s laws to prove that the complement of ðA \ BÞ \ ðA [ BÞ \ ðA [ CÞ is ðA [ BÞ [ ðA \ ðB [ CÞÞ. Solution: Starting with ðA \ BÞ \ ðA [ BÞ \ ðA [ CÞ, note that ðA [ BÞ \ ðA [ CÞ is the same as A [ ðB \ CÞ.

Step 1: Making this substitution, we want to ﬁnd the complement ðA \ BÞ \ ðA [ ðB \ CÞÞ. Step 2: By DeMorgan’s law, the complement of an intersection is the union of set complements. So this can be written as ðA \ BÞ [ ðA [ ðB \ CÞÞ. Step 3: Again, the complement of an intersection is the union of the set complements. So this can be written as ðA [ BÞ [ ðA [ ðB \ CÞÞ. Step 4: Also by DeMorgan’s law, the complement of a union is the intersection of the set complements. So this can be written as ðA [ BÞ [ ðA \ ðB \ CÞÞ. Step 5: Again, the complement of an intersection is the union of the set complements. This yields ðA [ BÞ [ ðA \ ðB [ CÞÞ. QED

4.2.5

Partitions

A partition on a set A is a collection P of disjoint subsets of A whose union is A. For a collection Bi (i=1, 2, y, n) to be a partition P of A: 1. BiDA for i=1, 2, y, n. 2. Bi-Bj=F for i 6¼ j. 3. for any xAA, xABi for some i; (alternatively B1,B2,y,Bn) The concept of a partition (Fig. 4.5) is the most basic and far-reaching mathematical concept to our development of systems engineering. We will talk

B1 B3

B3 B4

B4 Partition of A

FIGURE 4.5

Not a Partition of A

Set partition.

112

DISCRETE MATHEMATICS: SETS, RELATIONS, AND FUNCTIONS

about the importance of creating a partition of the system’s requirements, and a partition of the system’s function, and a partition of the system’s physical resources. This is just the beginning.

4.2.6

Power Set

The power set of a set A is denoted, P(A). The power set is the set of all sets that are subsets of A. Mathematically, the power set is the family (or set) of sets such that XDA3XAP(A), or P(A)={X | XDA}. 1. Let A0=F, P(F)={F}, [where A0 is a set with zero elements and P(A0) has one element]. 2. Let A1={a}; P(A1)={F, A1}={F, {a}} [where A1 is a set with one element and P(A1) has two elements]. 3. Let A2={a, b}; P(A2)={F, {a}, {b}, {a, b}} [where A2 is a set with two elements and P(A2) has four elements]. How many elements does the power set of a set of An have? Theorem If An is a set with n elements, then P(An) has 2n elements. Proof We will use mathematical induction. For n=0, 1, 2, 3, y, let S(n) be the statement: If An is a set with n elements, then P(An) has 2n elements. i. First show that if A0 has 0 elements, then P(A0) has 20=1 element. A ¼ F; PðAÞ ¼ fFg ii. Assume S(k) is true and then show that S(k+1) is true. Let Ak+1 be a set with k+1 elements. Deﬁne B to be a proper subset of Ak+1 with k of Ak+1’s elements: Akþ1 ¼ fa1 ; a2 ; . . . ; ak ; akþ1 g B ¼ Ak ¼ fa1 ; a2 ; . . . ; ak g So Akþ1 ¼ fakþ1 g [ B: Therefore, every subset of Ak+1 either contains ak+1, or it does not. 1. If a subset does not contain ak+1, then it is a subset of B, and we know there are 2k subsets of B, by induction. 2. If a subset does contain ak+1, then it is the union of a subset of B and ak+1. There must be 2k of these since there are 2k subsets of B. So there are 2k+2k=2k(1+1)=2k 2=2k+1 subsets of Ak+1 or 2k+1 elements of P(Ak+1).

4.3

RELATIONS

113

The concept of a power set has many potential uses in systems engineering. For example, the power set of system inputs is an upper bound on the test sequences required to test the system exhaustively. 4.3

RELATIONS

This section deﬁnes relations using the concepts of ordered pairs and Cartesian products. Important properties of relations are deﬁned, followed by deﬁnitions of partial orderings and equivalence relations. 4.3.1

Ordered Pairs and Cartesian Products

An ordered pair is (x, y) if xAA, yAB. A Cartesian product, A B, is deﬁned over two sets, A and B, such that A B={(a, b) | aAA and bAB}. That is, the Cartesian product of two sets is the set of all possible ordered pairs of those two sets. The following are examples of Cartesian products: 1. A={1}, B={2}: A B={(1, 2)} and B A={(2, 1)} 6¼ A B. 2. X={students of SYST 520 during the spring semester of 1996}={S1, S2, y, S31}, Y={A, B, C}: X Y={(S1, A), (S1, B), (S1, C), y , (S31, A), (S31, B), (S31, C)} An ordered n-tuple is deﬁned to be A1 A2 ? An={(a1, a2,y, an) | aiAAi, i=1, 2, y , n}, where (a1, a2,y, an). 4.3.2

Unary and Binary Relations

A unary relation on a set A relates elements of A to itself and is a subset, R, of A A. R is usually described by a predicate that deﬁnes the relation. Examples are r,=,W, ‘‘taller than,’’ and ‘‘older than.’’ If a1 and a2 A A, we write (a1, a2) A R, which means that a1 R a2 or a1 ‘‘is related to’’ a2. A binary relation is a relation R that relates elements of A to elements of B and is a subset of A B. The domain of R, written as ‘‘dom R,’’ is deﬁned as: dom R={x | xAA and (x, y)AR for some yAB}. The range of R, written as ‘‘ran R,’’ is deﬁned as: ran R={y | yAB and (x, y)AR for some xAA}. Again (a1, b1)AR3a1 R b1. Example Let R be the relation from A={1, 3, 5, 7} to B={1, 3, 5}, which is deﬁned by ‘‘x is less than y.’’ Write R as a set of ordered pairs.

Solution: R={(x, y) | xAA, yAB, xoy} R={(1, 3), (1, 5), (3, 5)}

114

DISCRETE MATHEMATICS: SETS, RELATIONS, AND FUNCTIONS

Recall the relations within and between systems engineering classes that were discussed in Chapter 2. The hierarchy of requirements was deﬁned by the relation ‘‘incorporates’’ in moving from the top of the requirements hierarchy to the bottom; ‘‘incorporated in’’ was the relation that moved from bottom to top. The relation ‘‘is decomposed by’’ moved from the top of the functional decomposition to the bottom; ‘‘decomposes’’ moves in the opposite direction. The physical hierarchy of a system and its components used the relation ‘‘is built from’’ in moving from top to bottom and ‘‘is built in’’ for moving from bottom to top. Binary relations included the tracing from requirements to functions or the system, the performance of functions by the system and its components, and inputs and outputs of items for functions. The relation ‘‘is traced to’’ was used for the binary relations of input/output stakeholders’ requirements being mapped to functions and for system-wide/technology requirements being mapped to the system. The binary relation for the system and components being related to functions used the relation ‘‘pertains.’’ The relations ‘‘inputs’’ and ‘‘outputs’’ addressed functions being related to items. To discuss the properties of unary relations, some additional information is needed concerning the possible ways to prove an implication. An implication is an ‘‘If y, then y’’ statement, which is commonly written as ‘‘If p is true, then q is true’’ or ‘‘p-q.’’ There are eight common methods for proving implications of this form. 1. Trivial proof: Show that q is true independently of the truth of p. 2. Vacuous proof: By mathematical convention, whenever p is false, p-q is true. The vacuous proof involves showing that p is false. This method is key to understanding the full implications of the properties of unary relations that are discussed below. 3. Direct proof: Assume that p is true and use arguments based upon other known facts and logic to show that q must be true. 4. Indirect proof: Use direct proof of the contrapositive of p-q. The contrapositive of a true implication is known to be true; the contrapositive of p-q is Bq-Bp (or q is false implies p is false). Here we assume q is false and prove via logic and known facts that p must be false. 5. Contradiction-based proof: DeMorgan’s laws can be used to show that p-q is equivalent to B(p4(Bq)), that is, the statement ‘‘p is true and q is false’’ is false. Proof by contradiction starts by assuming that (p4(Bq)) is true and then proving, based on this assumption, that some known truth must be false. If the only weak link in the argument is the assumption of ( p 4 (Bq)), then this assumption must be wrong. 6. Proof by cases: If p can be written in the form of p1 or p2 or y or pn ( p13p23y3pn), then p-q can be proven by proving p1-q, p2-q, y, pn-q as separate arguments. 7. Proof by elimination of cases is an extension of the method above: Recall from the second method that p-q is equivalent to [ (p3q)4(Bp)], that is

4.3

RELATIONS

115

(p and q are true) or (p is false). Now p can be partitioned into a set of cases as done in 6 and attacked one at a time. 8. Conditional proof: If we are to prove p-(q-r), we can prove the equivalent (p4q)-r. 4.3.3

Properties of Unary Relations on A

The seven properties discussed here are reﬂexive, irreﬂexive, symmetric, antisymmetric, asymmetric, transitive, and intransitive. 1. Reﬂexive: x R x for all xAA, e.g., equality, r, Z. 2. Irreﬂexive: xR = x for all xAA, for example, greater than, is the father of. 3. Symmetric: If x R y, then y R x ’x, yAA, for example, equality, is spouse of. Note if x R = y for all x and y in A, then the relation is symmetric by a vacuous proof. 4. Antisymmetric: If x R y and y R x, then x=y ’x, yAA, for example, equality, r, Z. Note if there is no situation in which ‘‘x R y and y R x’’ is true, then the relation is antisymmetric by vacuous proof. 5. Asymmetric: If x R y, then y R = x ’x, yAA, e.g., o, >. 6. Transitive: If x R y and y R z, then x R z ’x, y, zAA, for example, r, Z,=,W. This property is the most difﬁcult to grasp. If there is no situation in which ‘‘x R y and y R z,’’ then the relation is transitive by vacuous proof. 7. Intransitive: If for some x, y, zAA, it is true that x R y, y R z, but x R = z, the relation is considered intransitive. Example Let L be the set of lines in the Euclidean plane and let R be the relation on L deﬁned by ‘‘x is parallel to y.’’ Is R a reﬂexive relation? Why? Is R a symmetric relation? Why? Is R a transitive relation? Solution: 1. This question reduces to whether a line is parallel to itself. If the deﬁnition of parallel is having no points in common (everywhere equidistant), then a line cannot be parallel to itself because the two lines have every point in common. So R is not a reﬂexive relation. 2. R is a symmetric relation. Consider each xAL. x will have an inﬁnite number of yAL which satisfy the parallel relationship. Each such y is in turn parallel to x. Thus, (x, y)AR for all x and y that are parallel, and (y, x)AR, so the relation is symmetric. 3. R is a transitive relation. Again, consider (x, y)AR and (y, z)AR; x will be parallel to z, so x R z and R is transitive for all x, y, zAL. Example Let F be the set of functions in the functional decomposition for a system. Let R be the relation on F deﬁned by ‘‘is decomposed by.’’ Is R a

116

DISCRETE MATHEMATICS: SETS, RELATIONS, AND FUNCTIONS

reﬂexive relation? Why? Is R a symmetric relation? Why? Is R a transitive relation? Solution: 1. R is not a reﬂexive relation because a function does not decompose itself. 2. R is not a symmetric relation because if f1 decomposes f0, then f0 cannot decompose f1. 3. R is not a transitive relation. The function f0 is decomposed by f1, f2 and f3, and f1 is decomposed by f11, f12 and f13. However f0 is not decomposed by f11, f12 or f13. 4.3.4

Partial Ordering

A relation R on A is a partial ordering if R is reﬂexive, antisymmetric, and transitive. Examples of partial orderings are Z or r on the real number line, or + or D on P(A). Examples of nonpartial orderings are o or Won the real number line, or on P(A). (Both of these are asymmetric and antisymmetric.) 4.3.5

Equivalence Relations

A relation R on a set A is an equivalence relation if R is reﬂexive, symmetric, and transitive. An example of an equivalence relation is equality. 4.4

FUNCTIONS

This section deﬁnes functions and discusses the composition of functions.

4.4.1

Definitions

Let A and B be two nonempty sets. We write a function f as f : A-B and say that f maps every element of A (the domain) to one and only one element of B (the range). If (a, b)Af, then element b is the image of element a under f. Note that a function can map elements of A onto itself, f : A-A. A function f from A to B is a relation such that (a) dom f=A (i) f is deﬁned for each element of A, aAA. (ii) ((a, b) where bAB for each element of A, aAA. (b) if (a, b) A f and (a, c)Af, then b=c; that is, f is single-valued, or no element of A is related to two elements of B. A function is called one-to-one or injective if (a, b)Af and (c, b)Af implies a=c. That is, no two elements of A can be mapped into the same element of B by f.

4.4

FUNCTIONS

117

A function f : A-B is onto or surjective if and only if the range of f=B, that is, f is deﬁned for every bAB. If a function is both one-to-one and onto (or bijective), then the relation f 1 is single-valued and maps every element of B onto some element of A; f 1 is therefore a function, called the inverse function. Example If A={1, 2, 3, 4} and B={a, b, c, d}, determine if the following functions are one-to-one or onto. (a) f ¼ fð1; aÞ; ð2; aÞ; ð3; bÞ; ð4; dÞg (b) g ¼ fð1; dÞ; ð2; bÞ; ð3; aÞ; ð4; aÞg (c) h ¼ fð1; dÞ; ð2; bÞ; ð3; aÞ; ð4; cÞg Solution: (a) f is NOT one-to-one since f 1 ðaÞ ¼ f1; 2g. f is NOT onto since f 1 ðcÞ ¼ F. (b) g is NOT one-to-one since g 1 ðaÞ ¼ f3; 4g. g is NOT onto since g 1 ðcÞ ¼ F. (c) h is one-to-one since all elements of B correspond to unique elements in A. h is onto since every element of B has some pre-image in A. So we have progressed mathematically from sets to relations to functions. FunctionsDRelationsDSets, or a function is a relation is a set. As systems engineers we will focus on functional architectures. We will represent the functions of the system as relations or functions in graph-like structures. The underlying theory is set theory. 4.4.2

Composition

Let R be a relation from A to B, and S be a relation from B to C. (a, c) is an element of the composition of R and S, (denoted R S or R S) if and only if there is an element bAB such that a R b and b S c. That is, a and c must be linked together by b; a is mapped to b and b is mapped to c. (Note that some authors write the composition of R and S as S R so be careful.) The composition of functions is deﬁned in the same way as the composition of relations. Example Assume R and S are relations from A to A. If A={1, 2, 3, 4}, R={(1, 2), (2, 3), (3, 4), (4, 2)}, and S={(1, 3), (2, 4), (4, 2), (4, 3)}, then compute R S, S R and R R. Solution: R S={(1, 4), (3, 2), (3, 3), (4, 4)}.

118

DISCRETE MATHEMATICS: SETS, RELATIONS, AND FUNCTIONS

(1, 2) from R is composed with (2, 4) from S (this is written (1, 2) (2, 4) ) and yields (1, 4). (1, 2) from R cannot be composed with any of the other elements of S because they do not begin with a 2. (3, 4) (4, 2)=(3, 2). (3, 4) (4, 3)=(3, 3). (4, 2) (2, 4)=(4, 4). S R={(1, 4), (2, 2), (4, 3), (4, 4)}, which is not equal to R S. R R={(1, 3), (2, 4), (3, 2), (4, 3)}. As systems engineers we will employ functional decomposition to develop the functional architecture. Composition is the mathematical property from which decomposition derives its name. However, as discussed in Chapter 7, composition is only applicable to functional decomposition in limited situations.

4.5

SUMMARY

This chapter began with the introduction of a set, the foundation of a branch of mathematics called discrete mathematics. A great deal of terminology was introduced to deﬁne special sets such as the universal and null sets and operations on sets. During the discussion of sets, the concept of partition was deﬁned. The partition is perhaps the most important mathematical concept introduced in this chapter for application in this book. A partition is a subdivision of a set into subsets, which contain no common members, and yet the union of the subsets contains every element of the original set. In future chapters requirements will be partitioned, functional decompositions will be deﬁned to be partitions, and the physical decomposition will be deﬁned to be a partition. The power set of a set is the set of all subsets of that set. This notion of a power set is not exploited fully in this book but will become key to the future development and application of mathematics to the engineering of systems. The next major section of this chapter dealt with relations and the key properties associated with relations. A relation is a set of ordered pairs; the elements of the ordered pairs come from one or two sets. If the functions of a system are not fully deﬁned in terms of inputs, then these system functions are, in fact, mathematical relations. Functions are relations that satisfy certain properties; a function maps every element of the domain of the function to some element of the range, but does not map any element of its domain to more than one element of the range. One-to-one and onto properties of functions were also discussed. Finally the composition of functions was deﬁned.

PROBLEMS

119

PROBLEMS 4.1 Deﬁne the students enrolled in this class during this semester as a set, S. a. Specify a partition of S into 2 subsets. b. Specify a partition of S into 3 subsets. c. Specify a partition of S into 5 subsets. 4.2 Let A1={1, 3, 5, 7, 9, 11}, A2={2, 6, 9, 11}, A3={2, 4, 6, 9, 11}. Show that: a. A1+A2=(A1A2),(A2A1) b. A1,(A2-A3)=(A1,A2)-(A1,A3) 4.3 Prove that the following relations are true in general: a. A1+A2=(A1A2),(A2A1) b. A1,(A2-A3)=(A1,A2)-(A1,A3) 4.4 Let R be a relation from A to B and deﬁned ‘‘x is at least twice as big as y.’’ Write R as a set of ordered pairs for a. A={1, 3, 5, 7} and B={2, 3, 4, 6} b. A={0, 1} and B={0, 1} c. A={1, 2, 3, 4, 5, 6, 7} and B={3, 6} 4.5 Let R be relation from A to B where ‘‘x is greater than or equal to y squared.’’ Then deﬁne R as a set of ordered pairs for the following: a. A={1, 2, 3, 4, 5}, B={1, 2, 3, 4, 5} b. A={25}, B={5, 6, 7} 4.6 There are three families deﬁned by the sets A, B, and C; each family has a dad, mom and three kids: A={Dad, Mom, Doris, Bill, Tom} B={Dad, Mom, Doris, Daisy, Debbie} C={Dad, Mom, Bill, Bob, Biff} Consider the relations ‘‘is the spouse of,’’ ‘‘is the brother of,’’ and ‘‘is the blood relative of.’’ (Hints: I am not the brother of myself. Two people are blood relatives if they share the blood of a common ancestor, who may or may not be part of sets A, B, or C. I am the blood relative of myself. Biff is a male.) Identify which of these relations satisfy which of the seven properties of unary relations for each of the three sets by placing a yes or no in the empty cells of the following table.

Intransitive

Transitive

Asymmetric

Anti-symmetric

Symmetric

Irreflexive

DISCRETE MATHEMATICS: SETS, RELATIONS, AND FUNCTIONS

Reflexive

120

‘‘is the spouse of ’’ on A ‘‘is the brother of ’’ on A ‘‘is the blood relative of ’’ on A ‘‘is the spouse of ’’ on B ‘‘is the brother of ’’ on B ‘‘is the blood relative of ’’ on B ‘‘is the spouse of ’’ on C ‘‘is the brother of ’’ on C ‘‘is the blood relative of ’’ on C

4.7 Let R be a relation from A to B and S be a relation from B to C. a. Find R S for A={1, 3, 5, 7}, B={1, 2, 4, 5, 7}, C={1, 2, 3, 4, 5, 6}, R={(1, 2), (3, 4), (5, 2), (7, 4)} and S={(1, 2), (2, 4), (4, 3), (7, 5)}. b. Are any of these relations R, S, R S functions? One-to-one functions? One-to-one and onto functions? 4.8 If A1={1, 2, 3, 4} and A2={1, 4, 9, 25}, determine if the following functions that map A1 onto A2 are one-to-one, onto, or both one-toone and onto. a. f1={(1, 1), (2, 4), (3, 4), (4, 25)} b. f2={(1, 1), (2, 4), (3, 25), (4, 25)} c. f3={(1, 1), (2, 4), (3, 9), (4, 25)} 4.9 Develop two relations R (from A to B) and S (from B to C) that have to do with people. Show the result of R S. 4.10 Let R and S be relations from A-A, where A={1, 2, 3, 4} and: R={(1, 1), (2, 2), (3, 3), (1, 2), (2, 3), (1, 3), (2, 1), (3, 1), (3, 2)} S={(2, 3), (1, 2), (2, 1), (3, 1), (1, 3)} a. Find if these relations are symmetric, reﬂexive, and transitive. b. Find R S, S R and R R. 4.11 Let A be a set of three colors: {red, blue, green}. What are the elements of the power set of A?

PROBLEMS

121

4.12 Let SIBLINGS={Andrea, Bobby, Catherine, David, Eric}. Find the elements of the power set of SIBLINGS, P(SIBLINGS). 4.13 Show that the P{Andrea, Bobby} is a subset of the P(SIBLINGS) from Problem 4.12. 4.14 Prove that for any two sets A and B, (P(A)-P(B))=P(A-B). 4.15 Find two sets A and B that show (P(A),P(B)) 6¼ P(A,B). 4.16 Prove that for any two sets A and B, (P(A),P(B))DP(A,B). 4.17 Prove that the seven properties of set operations in Section 4.2.4 are true.

Chapter

Graphs and Directed Graphs (Digraphs)

5.1

INTRODUCTION

This chapter introduces the mathematics of graph theory, the formal representation of a relation (or function) among elements of a set or a pair of sets. The concept of a relation discussed in this chapter is the same concept introduced in Chapter 4. A graph in mathematics is a set of nodes and a set of edges between pairs of those nodes; the edges are ordered or nonordered pairs, or a relation, that deﬁnes the pairs of nodes for which the relation being examined is valid. As an example, the people working as systems engineers on a project could be the members of a set. One relation deﬁned over this set could be ‘‘works for.’’ Another relation could be ‘‘respects.’’ The edges can either be undirected or directed; directed edges depict a relation that requires the nodes to be ordered while an undirected edge deﬁnes a relation in which no ordering of the edges is implied. The ‘‘works for’’ and ‘‘respects’’ relations would be examples of ordered relations. An example of an undirected relation would be ‘‘sits next to.’’ A graph enables us to visualize a relation over a set, which makes the characteristics of relations such as transitivity and symmetry easier to understand. The reader will hopefully comprehend the power of visualizing mathematical concepts, as enabled by mathematical graph theory, by the end of reading this chapter.

The Engineering Design of Systems: Models and Methods, Second Edition. By Dennis M. Buede Copyright r 2009 John Wiley & Sons, Inc.

122

5.1

INTRODUCTION

123

There is a great deal of terminology associated with graph theory; most of the basics are introduced in this chapter. Notions such as paths and cycles are key to understanding the more complex and powerful concepts of graph theory. There are many degrees of connectedness that apply to a graph; understanding these types of connectedness enables the engineer to understand the basic properties that can be deﬁned for the graph representing some aspect of his or her system. The concepts of adjacency and reachability are the ﬁrst steps to understanding the ability of an allocated architecture of a system to execute properly. In addition to aiding in the visualization of relations, graph theory is the basis of many modeling languages. However, there are many more modeling languages, such as IDEF0, that look like graphs but which have no underlying mathematics. The material presented in this chapter is necessary but not sufﬁcient to be able to detect when a modeling language with graphical representations has a mathematical basis or not. For example, understanding the seven properties of unary relations presented in this chapter will enable the reader to detect key assumptions such as transitivity being made or assumed by a modeling language. Similarly, understanding the difference between a partial order and a total order will give the reader an appreciation of the restrictions and power of a modeling language. A speciﬁc example of the use of some of the key concepts in this chapter relates to total and partial orders of elements of a set based upon the relation deﬁned over the set. When a relation induces a total order, the elements of the set over which the relation is deﬁned can be numbered from 1 to n. However, the concept of a partial order suggests that there is more than one possible order from 1 to n of the set’s elements that is consistent with the relation. There are a number of applications of a partial order in systems engineering. For example, the set of functions being executed by the system’s components can often be executed in more than one sequence. Understanding the many partial orders of functional execution is key to developing test plans to verify the system’s performance characteristics. The interested reader is referred to Goodaire and Parmentar [1998], Harary [1972], and Harary et al. [1965] for more details on graph theory. Shin and Levis [2003] provide a performance prediction model based upon a creative application of Petri nets, which is a graph theoretic modeling language based on set theory. Another speciﬁc example of the use of concepts from this chapter relates to the power of hierarchies in the engineering of systems; hierarchies for requirements, functions, and physical components are discussed in Chapter 2. In graph theory a hierarchy is represented as a directed tree. This chapter introduces the terminology associated with trees in graph theory. The state-of-the-art practice in the engineering of systems is to use a number of graphical concepts that have various amounts of grounding in mathematics as communication mechanisms. The challenge for the future is to develop additional modeling techniques that have signiﬁcantly more grounding in

124

GRAPHS AND DIRECTED GRAPHS (DIGRAPHS)

mathematics while maintaining the quality of the communication among the stakeholders and the engineers in the various disciplines. The software engineering community has been moving in this direction for at least 15 years. The systems engineering community has just started this trek with SysML.

5.2

TERMINOLOGY

A graph, G, is a pair of sets, V(G) and E(G). V(G) = {n1, n2, y, nN} is the set of vertices or nodes. E(G) = {eij}D(V(G) V(G)) is a relation that deﬁnes the set of edges that are unordered, not necessarily distinct pairs of nodes. V(G) is a ﬁnite, nonempty set; E(G) may be empty and is a subset of the Cartesian product of V(G) with itself. Due to the undirected nature of the edges in a graph, the edges represent symmetric relations such as ‘‘____ is next to ____’’, ‘‘____ is the sibling of ____’’, ‘‘____ is married to ____.’’ Due to the symmetry the order in which the nodes are placed does not matter. The following Konigsberg bridge problem is one of the earliest known graph theory problems (See Sidebar 5.1). Euler’s graph of the Konigsberg bridge problem is known as a multigraph, in which two or more edges connecting the same nodes is possible. This graph is also known as a simple graph because there are no loops. A loop is an edge connecting a node to itself, eii. A directed graph or digraph, G, is a pair of sets, V(G) and E(G); V(G) = {n1, n2, y, nN} is the set of vertices or nodes. V(G) is again a ﬁnite, nonempty set; E(G) = {eij} is a subset of V V or ordered pairs of nodes; eij is said to be from ni to nj. Again E(G) may be empty. The edges in a digraph represent antisymmetric or asymmetric relations. Examples are ‘‘____ is a parent of ____’’ and ‘‘____ is higher than ____.’’ Here the order in which the nodes are placed in the blanks does matter. Examples include Markov chains and Program Evaluation Review Technique (PERT) charts. Figure 5.1 shows a sample digraph for the relation ‘‘is the parent of.’’ Nodes that are connected by a directed edge are often discussed in terms of parent and child. The node at the tail of the edge is often called the parent and the node at the arrow of the edge is called the child. The deﬁnitions of loop and simple digraph are the same as above. A multigraph digraph requires multiple copies of eij for the same i and j in E(G). The presence of eij and eji are not sufﬁcient for G to be a multigraph digraph. Cardinality of a set A = |A|=the number of elements of A. Note, the cardinality of f is 0. If A has n elements, then P(A) has cardinality is 2n. Order of G = |V(G)|= the number of nodes of G. Size of G = |E (G )|= the number of edges of G.

5.2

TERMINOLOGY

125

SIDEBAR 5.1: THE KONIGSBERG BRIDGE PROBLEM In the 1700s the inhabitants of Konigsberg in eastern Prussia were entertained by a puzzle involving seven bridges over the Pregel River. The puzzle posed by mathematicians was whether it was possible to start at any one of the four distinct parcels of land (A, B, C, or D) and ﬁnd a tour that crossed every bridge once and only once in such a way that the tourer ends up at the same parcel of land from which the tour began. L. Euler, the Swiss mathematician, proved that such a tour could not be done, and in 1736 gave precise conditions for when such a tour could be deﬁned for any system of interconnected bridges. A

D 6

C 7

The following graph is a mathematical representation that Euler created as part of his mathematical proof. The parcels of land are the nodes and the bridges are the edges. Would it be possible to deﬁne a graph for this problem in which the bridges were nodes and the parcels were edges? A 1

2 4

B 5

6 C

D 7

126

GRAPHS AND DIRECTED GRAPHS (DIGRAPHS)

Terah

Nahor

Hanan

Abram

Milchah

Sarai

Isaac

Bethuel

Rebecca

Jacob

Esau

FIGURE 5.1 Sample directed graph for ‘‘is the parent of.’’

The incidence of edges (Fig. 5.2) is deﬁned as: (a) eij is incident on ni and nj in a graph and (b) eij is incident from ni to nj in a digraph. Degree of node ni= the number of edges connected to ni in a graph, deg(ni). Out degree of node ni= the number of edges incident from (or exiting) ni in a digraph, degG (ni). In degree of node ni= the number of edges incident to (or entering) ni in a digraph, deg+ G (ni). Adjacency – two nodes ni and nj are said to be adjacent if eij or ejiAE(G). If V = {n1, n2, y, nN} is the set of nodes of an undirected graph G, then N X

degðni Þ ¼ 2jEðGÞj:

i¼1

FIGURE 5.2 Samples of incidence.

5.3

FIGURE 5.3

PATHS AND CYCLES

127

Sample bipartite graph.

If G is a digraph, then N X

degG ðni Þ ¼

i¼1

N X

degþ G ðni Þ ¼ jEðGÞj:

i¼1

Edge labeling of a graph or digraph G is a function f: E(G)-D, where D is a domain of labels. Node labeling of a graph or digraph G is a function f: V(G)-D, where D is a domain of labels. Recall from Chapter 3 that IDEF0 (Integrated Deﬁnition for Function Modeling) uses edge and node labeling. A bipartite graph is a graph (digraph) whose set of nodes can be partitioned into two sets A and B such that no edge connects a node in A to another node in A and, similarly, no edge connects a node in B to another node in B. See Figure 5.3. Is the family tree in Figure 5.1 a bipartite graph?

5.3

PATHS AND CYCLES

A walk in a digraph is a sequence of one or more nodes {n0, n1, y, nk} and zero or more edges {e01, e12, y, ek 1,k}. See Figure 5.4. A walk may revisit the same node more than once. A walk is closed if its initial and end vertices are the same; otherwise it is open. A walk is nontrivial if it has one or more edges. A path is a walk in which each node is distinct (i.e., there are no repeats), except possibly the end nodes. See Figure 5.4. Note since the nodes cannot repeat, the edges cannot repeat.

FIGURE 5.4 Digraph with a walk (d b a c d e), closed walk, path, and a cycle (a c d b).

128

GRAPHS AND DIRECTED GRAPHS (DIGRAPHS)

d c

FIGURE 5.5 Digraph with 2 cycles (a b c and c d e) and a circuit (c a b c d e c).

A trail is a walk in which each edge is distinct. Note the same node may be revisited more than once. A closed trail is a circuit. A circuit is a nontrivial walk with no repeated edges and whose endpoints are the same. Figure 5.5 has a circuit: a, b, c, d, e, c, a. A cycle is a circuit in which all of the nodes are distinct except the ﬁrst and last. See Figures 5.4 and 5.5. The nodes a, c, d, b in Figure 5.4 are a cycle. This cycle could be deﬁned as (d, b, a, c) or (b, a, c, d) or (c, d, b, a) as well, but there is only a single cycle in this graph. A nondirected walk (or semiwalk) in a digraph is a sequence of one or more nodes {n0, n1, y, nk} and zero or more edges {e10 or e01, e21 or e12, y, ek,k 1 or ek 1,k}. A semiwalk can travel the wrong way on a directed edge. A semipath (or chain) is a semiwalk in which each node is distinct, again with the possible exception of the end nodes. See Figure 5.6. A semicircuit is a nontrivial semiwalk in which the ﬁrst and last nodes are the same and no edges are repeated. A semicycle is semicircuit in which the only repeated nodes are the ﬁrst and last. See Figure 5.6. A digraph is acyclic if there exists no subgraph that is a cycle. By now most readers are probably wondering how these deﬁnitions are going to be useful. The vocabulary provided by these deﬁnitions is very useful in describing when a graph has the seven unary characteristics (e.g., reﬂexivity, transitivity) from Section 4.3.3. In addition, there are other concepts that will be introduced in this chapter that have general applicability to the engineering of a system, for which this vocabulary will also be useful.

FIGURE 5.6 Digraph with a semipath (b a c d e) and semicycle (d b a c).

5.5

5.4

ADJACENCY AND REACHABILITY

129

CONNECTEDNESS

Another vocabulary that proves very useful is connectedness. A pair of nodes in a digraph is weakly connected if there is a semipath between them, for example, nodes b and c in Figure 5.6. The nodes are unilaterally connected if there is a path between them, for example, all of the pairs of nodes in Figure 5.6 except b and c. Finally, the nodes are strongly connected if there is a path in both directions. No pair of the nodes in Figure 5.6 is strongly connected; every pair of nodes in Figure 5.5 is strongly connected. Note a pair of nodes that is strongly connected is also weakly and unilaterally connected. A digraph is weakly (unilaterally, strongly) connected if every pair of nodes in the graph is weakly (unilaterally, strongly) connected. The digraph in Figure 5.6 is weakly connected because of the weak connection between nodes b and c. The digraph in Figure 5.4 is unilaterally connected because node e is unilaterally connected with the other four nodes, even though each of the other four nodes is strongly connected to each of the other three. The digraph in Figure 5.5 is strongly connected. The digraphs in Figures 5.1 and 5.3 are weakly connected. A pair of nodes is disconnected if there is no path or semipath between them. A digraph is disconnected if one of its nodes is disconnected from any other node of the graph. A graph is connected if it is not disconnected. All of the digraphs presented so far are connected. 5.5

ADJACENCY AND REACHABILITY*

The adjacency matrix of a graph G, A(G), provides a mathematical representation of which nodes in a digraph are adjacent to each other. Recall that a relation from N(G) to N(G) is deﬁned by the edges of G, E(G). So in fact, A(G) is a description of the relation E(G) from N(G) to N(G). AðGÞ ¼ aij is an N N Boolean matrix where N is the order (number of nodes) of G. ( aij ¼

1 0

if if

eij 2 EðGÞ eij 2 = EðGÞ

Note a Boolean matrix is one whose elements are 0 or 1. The row sums of A(G) give the out-degrees of the associated node; the column sums give the indegrees. If G is not a digraph but a graph, A(G) will be a symmetric matrix. * Advanced material.

130

GRAPHS AND DIRECTED GRAPHS (DIGRAPHS)

A node nj of G is said to be reachable from node ni of G if there exists a path from ni to nj in G. The reachability matrix, R(G), is a Boolean matrix that indicates which nodes can be reached from which other nodes. RðGÞ ¼ rij is an N N Boolean matrix where N is the order of G. To compute R(G) we ﬁrst compute A, A2, A3, y, A|E(G)| 8 > < 1 if i ¼ j k rij ¼ 1 if aðkÞ ij 40 for some A > : 0 otherwise Node ni is reachable from node nj if rij = 1. R(G) is also called the transitive, reﬂexive closure of E(G) because R(G) is deﬁned to be a reﬂexive relation that adds the edges necessary to make E(G) a transitive relation. R(G) is sometimes denoted R*(G). h i The transitive closure, R +(G), is deﬁned to be Rþ ðGÞ¼ rþ ij , where ( ðkÞ 1 if aij 40 for some Ak ¼ rþ ij 0 otherwise

Note in this case the reﬂexivity of the transitive closure is determined by the reﬂexivity of E(G). The distance between two nodes is the smallest number of edges between the nodes on any path connecting the two nodes. The distance matrix, D(G), reﬂects these numbers. DðGÞ ¼ dij is an N N matrix where N is the order of G. 8 0 if i ¼ j > > > >k if nj is reachable from ni ; k is the exponent < ðkÞ dij ¼ of the first Ak in which aij 40 > > > > : 1 if there is no path from n to n i j

5.6

UNARY RELATIONS AND DIGRAPHS

Now directed graphs will be used to visualize the seven properties of unary relations that were introduced in Chapter 4.

5.6

UNARY RELATIONS AND DIGRAPHS

131

A Sample Reflexive Relation

A Sample Irreflexive Relation

FIGURE 5.7

Reflexive and irreflexive relations.

Reﬂexivity: 8x; x R x: That is, all nodes must have loops. The top of Figure 5.7 shows a reﬂexive relation. Irreﬂexivity: 8x; xR = x: That is, no nodes can have loops. The relations shown in the digraphs of Figures 5.1 and 5.3 through 6 are irreﬂexive. The bottom of Figure 5.7 shows an irreﬂexive relation. Note digraphs can depict relations that are neither reﬂexive nor irreﬂexive when some of the nodes have loops and others do not. Symmetry: 8x; y ; if x R y ; then y R x: That is, there must be a cycle between any two nodes that are adjacent to each other. There is no limitation about arcs besides this. The relations shown in the digraphs of Figures 5.4, 5.5, and 5.6 are not symmetric. The relation in the digraph shown in Figure 5.8 is symmetric. Antisymmetry: 8x; y ; if x R y and y R x; then x ¼ y: That is, there cannot be a cycle between any two nodes that are adjacent to each other. Again, there is no limitation about arcs besides this one; so cycles containing three or more nodes can exist. Any node can have a loop. The digraphs in Figure 5.1 and 5.3 through 5.6 show antisymmetric relations; the relation in the digraph shown in Figure 5.8 is not. Asymmetry: 8x; y ; if x R y; then yR = x: That is, there can be no cycle between any two nodes, and there can be no loops. Asymmetric relations must be

FIGURE 5.8

Digraph of a symmetric relation.

132

GRAPHS AND DIRECTED GRAPHS (DIGRAPHS)

irreﬂexive. Again cycles among three or more nodes are allowed. The relations in the digraphs shown in Figures 5.1 and 5.3 through 5.6 are asymmetric; the digraph in Figure 5.8 shows a relation that is not.

Note a relation that is irreﬂexive but in which no node is adjacent to any other node (completely disconnected) is symmetric, antisymmetric, and asymmetric due to the vacuous proof in Chapter 4. Transitivity: 8x; y; z if x R y and y R z; then x R z: This condition only applies to triplets of nodes and requires that there be a semicycle among the three nodes in the triplet. (Note the ﬁrst and third node in a triplet can be the same, in which case there must be cycle between the two nodes and loops at each node.) A relation to which this condition, or left-hand side, is not applicable (i.e., the ‘‘if condition’’ is never satisﬁed) will be transitive. Figure 5.9 shows a transitive relation: dRa aRb dRb dRa

and aRb dRb, and bRe aRe, and bRe dRe, and aRe dRe.

Intransitivity: for some x, y, z, if x R = z; then x R y and y R z: Relations are either transitive or intransitive. Cycles may exist in transitive relations; but note that a transitive relation with cycles that contains three or more nodes means that there must be a cycle between every pair of nodes that is part of the cycle, resulting in a symmetric relation with loops for the subset of nodes in the cycle. The relation in Figure 5.8 is symmetric but not transitive because aRb and bRa, but a is not related to a; the same applies for nodes b and c. Figure 5.10 shows the transitive version the relation of Figure 5.8; the loops are added at each node. It should be obvious that it is easier to use a directed graph to visualize the properties of unary relations than the mathematical expressions discussed in

FIGURE 5.9 Digraph of a transitive relation.

5.7

ORDERING RELATIONS

133

FIGURE 5.10 Transitive version of the digraph in Figure 5.8.

Chapter 4. Likewise, graphical techniques for visualizing functional relationships together with inputs and outputs are much more comprehensible than purely written or tabular methods for most people. ‘‘A picture is worth a 1000 words.’’

5.7

ORDERING RELATIONS*

Relation R is a partial order on set A when R is reﬂexive, antisymmetric, and transitive on the set A. In this case A is called a partially ordered set, or POSET, written [A; R]. Therefore a relation that is a partial order cannot have any cycles. As discussed in the previous section, a relation that is transitive and has cycles must have pairs of nodes that are symmetric. If any pair of nodes in a relation is symmetric, then the relation cannot be antisymmetric. Two elements a1 and a2 in A are said to be comparable under R if either a1 R a2 or a2 R a1. Otherwise the elements are incomparable. If every pair of elements is comparable, then [A; R] is totally ordered. A Hasse diagram is an undirected graph of the relations between the elements of a partially ordered set. See Figure 5.11. Each element of A is represented as a node. Reﬂexivity is not represented in the Hasse diagram, thereby eliminating all loops from the graph. Edges that are required by the transitivity property are also omitted; that is, any edge that depicts a shorter path to another node than some other combination of edges is deleted. To draw a Hasse diagram, we place the nodes on a piece of paper such that ai is below aj if ai R aj. We connect ai to aj with an undirected edge if and only if ai R aj and there is no ak such that ai R ak and ak R aj. Figure 5.12 provides a second example of a Hasse diagram and the resulting partial orderings of A. If there is only one node at the top of the Hasse diagram and only one node at the bottom, then the poset is called a lattice. That is, with the transitivity property in force there must be one and only one element, the upper bound or a of A, such that a R ai ’i, and a second element, the lower bound or z of A, such that ai R z ’i. * Advanced material.

134

GRAPHS AND DIRECTED GRAPHS (DIGRAPHS)

Relation R on A a

making R a partial order

making a Hasse diagram possible orderings of elements of A

a, b, c, d a, c, b, d

FIGURE 5.11 Partial order on a set A, Hasse diagram, and partial orderings of A.

R = “divides evenly” on A = {1, 2, 3, 4, 6, 9}

The relation is transitive. Reflexive arcs are dropped for ease of display. 4

2 3 3

Making R a Hasse diagram

6 2

FIGURE 5.12

16 possible orderings of elements of A: 1, 2, 3, 4, 6, 9 1, 2, 3, 4, 9, 6 1, 2, 3, 6, 4, 9 1, 2, 3, 6, 9, 4 1, 2, 3, 9, 4, 6 1, 2, 3, 9, 6, 4 1, 2, 4, 3, 6, 9 1, 2, 4, 3, 9, 6

1, 3, 2, 4, 6, 9 1, 3, 2, 4, 9, 6 1, 3, 2, 6, 4, 9 1, 3, 2, 6, 9, 4 1, 3, 2, 9, 4, 6 1, 3, 2, 9, 6, 4 1, 3, 9, 2, 4, 6 1, 3, 9, 2, 6, 4

Second Hasse diagram example.

5.9

5.8

TREES

135

ISOMORPHISMS*

Two graphs, G1 = (V1, E1) and G2 = (V2, E2), are isomorphic if there exists a one-to-one and onto function, f, such that f: V1-V2 and f preserves adjacency. That is, E2 = {( f (v), f (w)) | (v, w) A E1}. Note that ‘‘___ is isomorphic to ___’’ is an equivalence relation. An isomorphism f from G1 to G2 is not necessarily unique. Some necessary properties for G1 and G2 to be isomorphic are: (1) |V(G1)| = |V(G2)|, (2) þ |E(G1)| = |E(G2)|, and (3) if n1 A V(G1), then degþ G1 ðn1 Þ ¼ degG1 ð f ðn1 ÞÞ and degG1 ðn1 Þ ¼ degG1 ð f ðn1 ÞÞ. 5.9

TREES

A tree is a graph G with no loops in which there is a unique, simple (no loops), nondirected path (or semipath in the case of a digraph) between each pair of nodes. Figure 5.13 shows a graph that is a tree. A rooted tree is a tree in which there is a designated ‘‘root’’ node. In a graph, the root node must have a degree of 1. In Figure 5.13 nodes a, c, and j could be root nodes. In a directed tree, the root node must have no parents, or an in degree of 0. In Figure 5.14, in the left digraph nodes a and c could be root nodes; in the right digraph only node a can be root node. A directed tree is a rooted tree in which there is a (directed) path from the root to every other node. Note that the tree in Figure 5.13 is not a directed tree because the graph is not a digraph. The right-hand digraph in Figure 5.14 is a directed tree in which node a is the root. The left-hand graph is a tree because there exists a semipath from every node to every other node; that is, the graph is weakly connected. The graph is not a directed tree because there is not a path from any root (a or c) to every other node. Note the following statements are consistent with the above deﬁnitions: 1. A simple nondirected graph G is a tree if and only if G is connected and contains no cycles. 2. A tree with n nodes has exactly n1 edges. 3. A graph G is a tree if and only if G has no cycles and |E(G)| = |V(G)|1. A directed tree is a graphic representation of a partition, the fundamental construct of our requirements, functional and physical decompositions. 5.9.1

Spanning Trees*

A graph H is a subgraph of a graph G if V(H) D V(G) and E(H) D [E(G) (V(H) V(H))]. That is, the nodes in the subgraph must be a subset of the * Advanced material.

136

GRAPHS AND DIRECTED GRAPHS (DIGRAPHS)

FIGURE 5.13 Sample tree.

nodes in the graph, and the edges in the subgraph must be a subset of those in the graph, with the added stipulation that all of the edges are connected to two nodes, one on each end of the edge. Graph H is a proper subgraph of G if V(H) 6¼ V(G). A graph H is a spanning subgraph of G if H is a subgraph of G and V(H) = V(G). So a spanning subgraph cannot be a proper subgraph. Let W be a subgraph of G. The subgraph induced by W is the subgraph H of G in which V(H) = V(W) and E(H) = [E(G) - (V(W) V(W))]. That is, H, the subgraph of G induced by W, contains all of the edges of G that are consistent with the nodes of W. A subgraph H of a graph G is called a spanning

j Nondirected Tree

FIGURE 5.14

Directed Tree

Sample nondirected and directed trees.

5.9

TREES

137

tree of G if (a) H is a tree and (b) V(H) = V(G). A spanning tree that is a directed tree is a directed spanning tree. 5.9.2

Directed Trees

Two nodes, n1 and n2, in a digraph G are quasi-strongly connected if there exists a node n3 such that there is a path(s) from n3 to n1 and from n3 to n2. The path from n3 to n2 can pass through n1. Digraph G is a quasi-strongly connected digraph if and only if there is at least one node, r, in G such that there exists a path from r to all of the remaining nodes of G. See Figure 5.15. Let G be a digraph with |V(G)|W1. Then the following statements are equivalent: (1) G is a directed tree. (2) There is a node r in G such that there exists a unique path from r to every node in G. (3) G is quasi-strongly connected and G – (any edge) is not quasi-strongly connected. (4) G is quasi-strongly connected and contains a node r such that the in degree of r is 0 and the in degree of every other node in G is 1. The height of a directed tree is the length of the longest path. The height of the directed tree in Figure 5.14 is 8. A directed tree has levels. Level 0 is associated with the root of the directed tree. The ﬁrst level of the directed tree contains all nodes adjacent to the root, or the children of the root. The second level contains the children of all nodes in level 1, and so on. See Figure 5.16. Note that a directed tree need not be symmetric, that is, reach the same level along every path. 5.9.3

Forest

A directed forest is a collection of directed trees. See Figure 5.17. Forests are important in systems engineering as we practice concurrent engineering.

FIGURE 5.15

Quasi strongly connected digraph.

138

GRAPHS AND DIRECTED GRAPHS (DIGRAPHS)

Level 0

Level 1

Level 2

Level 3

Level 4

FIGURE 5.16

Levels of a directed tree.

Recall from Chapter 1 that we must be concerned not only with the system that will be used during the operational phase but also with the development, manufacturing, training, deployment, reﬁnement, and retirement systems. The concurrent requirements form a requirements forest.

5.10

FINDING CYCLES AND SEMICYCLES IN A GRAPH

In very large digraphs it will not always be apparent that there are cycles or semicycles. To ﬁnd the cycles, remove all barren nodes (nodes without children) and border nodes (nodes without parents). Continue this process until there are no remaining barren or border nodes. If there are any nodes remaining, then

FIGURE 5.17 Sample directed forest.

5.11

REVISITING IDEF0 DIAGRAMS

139

there are one or more cycles and the remaining nodes are part of at least one of the cycles. To ﬁnd the semicycles in a digraph, ﬁrst replace all of the directed arcs with non-directed arcs. Then remove all nodes of degree 1. Continue this process until there are no remaining nodes of degree 1. If there are any nodes remaining, then there are one or more semicycles, and the remaining nodes are part of at least one of the semicycles.

5.11

REVISITING IDEF0 DIAGRAMS

At a superﬁcial level IDEF0 diagrams resemble the digraphs that we have been discussing. On any IDEF0 page there are nodes, depicted as boxes, and arcs. All of the boxes and edges are labeled as discussed earlier in this chapter. However, we need not look too deep to see some major discrepancies between digraphs and a page of an IDEF0 model. The inputs, controls, outputs, and mechanisms (ICOMs) coming from external sources to the page are not nodes but labels on the edges. These edges, associated with the external ICOMs, do not have a node at one of their ends; this never happened in a digraph since an edge depicted a relation between two elements of a set A and all of the elements of A were shown in the graph. As mentioned in the previous paragraph, each edge on the IDEF0 diagram is labeled. While there can be labels on the edges in digraphs, all of the digraphs presented in this chapter had none. In a digraph each edge represents the fact that a single relation exists between each pair of connected nodes, aRb. Each node in the IDEF0 diagram is called a function and is named consistently with our understanding of a function, namely a transformation. Yet, digraphs represent a speciﬁc relation, which may be a mathematical function if certain conditions are satisﬁed (see Chapter 4). The relation, or function, in a digraph is represented by the edges, not the nodes. At an even deeper level, each label on the edge of an IDEF0 arrow actually represents a set of possible items that can become an input, control, or output of the relevant function. All of the possible inputs and controls entering a function must then be represented by n-tuple of the Cartesian product across all input and control arrows entering that function. Similarly, the Cartesian product represents all possible outputs of a function across all output arrows exiting a function. So, there are, in fact, many important differences between a digraph and a page of an IDEF0 diagram. A number of people have attempted to transform an IDEF0 model into a bipartite graph. The ﬁrst step is to turn the arc labels into nodes of a second type, say circles. The IDEF0 diagram (without mechanisms) in the top of Figure 5.18 is converted into a bipartite graph in the bottom of Figure 5.18. Each label is replaced by a circular node. Each external label is connected by the edge entering or leaving the appropriate function. The new nodes for I12 and C12 are now connected by two edges; one going into the new node and one

140

GRAPHS AND DIRECTED GRAPHS (DIGRAPHS)

Transform I1 into I12 and C12 in accordance with C1

C12 I12

Transform I12 into O1 in accordance with C12

Transform I1 into I12 and C12 in accordance with C1

C12

I12

Transform I12 into O1 in accordance with C12 A2

FIGURE 5.18 ICOM labels converted to nodes.

coming out of the new node. We have now satisﬁed the basic requirements of a bipartite graph; there are two types of nodes and no edge connects two nodes of the same type. There are, in essence, two types of edges; those that connect boxes to circles (outputs of the function in the box) and those that connect circles to boxes (inputs to the function in the box). However, there are two remaining problems. First, IDEF0 differentiates between arcs entering a function from the top and left. There is no provision for such differentiation in digraphs. Other process modeling techniques in Chapter 12 do not differentiate between inputs and controls; it is necessary to drop this distinction between inputs and controls, as is done in Petri nets, which is the only graph-theoretic modeling tool discussed in Chapter 12. Second, there is a problem with branches and joins. There is no analogous construct in graph theory. To solve this problem a function must be inserted at each branch to accomplish a divide or copy, and at each join to accomplish a paste. See Figure 5.19.

5.12

SUMMARY

141

Transform I1 into I12 and C12 in accordance with C1

C12 O1a I12 & O1a

Transform I12 into O1 in accordance with C12

I12

O1 O1b

Transform I1 into I12&O1a C12 in accordance with C1 A1

C12 Divide I12&O1 a into I12 and O1a

I12&O1a

O1a

Paste O1a together with O1b A4

I12

Transform I12 into O1b in accordance with C12 A2

O1b

FIGURE 5.19 IDEF0 page with divide and paste functions added.

With all of these workarounds, IDEF0 remains a static snapshot of a dynamic process. There are potentially inﬁnite dynamic models that can be created from each IDEF0 model. The information that separates the proper dynamic model from the rest of the possible dynamic models is not in the IDEF0 model but remains in the mental model of the creator of the IDEF0 model. If a team (which is most common) creates the IDEF0 model, it is possible, even likely, that each team member has a mental model of a different dynamic representation of the static IDEF0 model. This is why creating a dynamic model from the IDEF0 representation is so important; the communication process among the systems engineering team must be carried as far as possible. 5.12

SUMMARY

A graph consists of a set of nodes and a set of edges. The edges deﬁne a relation over the set of nodes. The relation can require an order of the nodes in which case the edges are directed; directed graphs are the most applied in the engineering of systems. Bipartite graphs are a special form of a directed graph in which there are two types of nodes, and the edges cannot connect nodes that are the same type.

142

GRAPHS AND DIRECTED GRAPHS (DIGRAPHS)

Sequences of nodes in a graph can be deﬁned by the terms walk, path, trail, circuit, and cycle. Graphs can be connected or disconnected; there are variations of connectedness, ranging from weakly to strongly. Nodes that are not adjacent to each other in a graph can be reachable via a path in the graph. This notion of reachability can be critical if attaining some output requires the execution of a set of functions, but the set of functions is not part of a reachable set. The properties of reﬂexivity, irreﬂexivity, symmetry, antisymmetry, asymmetry, transitivity, and intransitivity were deﬁned in Chapter 4 and then redeﬁned in terms of graphs in this chapter. Visualizing these relations provides a much greater understanding of their meaning and ability to detect their absence or presence in a graph. Partial orders of the elements of a set were deﬁned as alternative orders of the nodes based upon the relation deﬁned over the nodes. The Hasse diagram was deﬁned and illustrated for ﬁnding the partial order on the set and then enumerating the possible partial orders. Trees and several variations of trees were introduced as a special form of a graph. A directed tree describes the notion of a hierarchical decomposition. Hierarchies of requirements, functions, and components were discussed in Chapter 2 and will be revisited in Chapters 6 through 11. These hierarchies must be partitions (as deﬁned in Chapter 4) and can be represented as directed trees. Finally the IDEF0 process modeling technique was revisited and discussed in terms of mathematical graph theory. The reasons why an IDEF0 model is not a directed graph were discussed, as well as the difﬁculty associated with turning an IDEF0 model into a graph.

PROBLEMS 5.1 For the following graph, G1: a

PROBLEMS

143

a. b. c. d.

Find |V(G1)| and |E(G1)|. Write the relation depicted by G1 as a set of ordered pairs. Deﬁne the adjacency matrix of G1. What is the out degree of each node of G1? What is the in degree of each node of G1? e. Could G1 be a bipartite graph? If no, why? If yes, what is the partition into two subsets of nodes that makes this a bipartite graph? f. Is the relation depicted here reﬂexive? irreﬂexive? symmetric? antisymmetric? asymmetric? transitive? intransitive? g. What arcs (if any) would you have to add to this relation to make it transitive

5.2 For the following graph, G2: a

a. Write the relation depicted by G2 as a set of ordered pairs. b. Deﬁne the adjacency matrix of G2. c. Could G2 be a bipartite graph? If no, why? If yes, what is the partition into two subsets of nodes that makes this a bipartite graph? d. *Is there a cycle in G2? How many? e. *Is there a semicycle in G2? Which nodes are included? f. Is the relation depicted here reﬂexive? irreﬂexive? symmetric? antisymmetric? asymmetric? transitive? intransitive? g. What arcs (if any) would you have to add to this relation to make it transitive? h. *Delete the arc from g to a and draw a Hasse diagram for G2. Why must we delete the arc from g to a before we can draw a Hasse * Advanced assignment.

144

GRAPHS AND DIRECTED GRAPHS (DIGRAPHS)

diagram? Deﬁne at least 10 different node orderings consistent with this Hasse diagram. 5.3 a. Develop a directed graph for the relation ‘‘_____ has defeated ____.’’ using the following won/lost records of the two 1993 Super Bowl teams. Create a single node for each team and an arc for each defeat. Note this will be a multigraph. Buffalo Bills (BB) Schedule BB

Dallas Cowboys (DC) Schedule

NEP

NYG

GBP

NYJ

SFF

NEP

NYG

KCC

LAR

NYJ

NYG

LAR

GBP

KCC

SFF

SUPER

b. Is this directed graph reﬂexive? irreﬂexive? transitive? asymmetric? c. *There will be cycles in the graph created in part (a). Break these cycles by eliminating arcs in favor of the two Super Bowl teams; that is, if there is a cycle between a Super Bowl team and another team, eliminate the arc showing that the Super Bowl team was defeated by

* Advanced assignment.

PROBLEMS

145

the other team. Assume the resulting relation is a partial order and draw a Hasse diagram of the relation. 5.4 For the following adjacency matrix: a

a. Draw the graphical representation, G4, that is deﬁned by the adjacency matrix. b. Find |V(G4)| and |E(G4)|. c. Write the relation depicted by G4 as a set of ordered pairs. d. What is the out degree of each node of G4? What is the in degree each node of G4? e. Could G4 be a bipartite graph? If no, why? If yes, what is the partition into two subsets of the nodes that makes G4 a bipartite graph? f. Which of the seven properties (reﬂexive, irreﬂexive, transitive, intransitive, symmetric, asymmetric, antisymmetric) does this relation satisfy 5.5 *Drop the arc from b to c in Figure 5.15 and draw a Hasse diagram for the resulting graph. How many orderings of the nodes in the digraph are consistent with this Hasse diagram? 5.6 There are three families deﬁned by the sets A, B, and C; each family has a dad, mom, and three kids: A = {Dad, Mom, Doris, Bill, Tom} B = {Dad, Mom, Doris, Daisy, Debbie} C = {Dad, Mom, Bill, Bob, Biff} Consider the relations ‘‘is the spouse of,’’ ‘‘is the brother of,’’ and ‘‘is the blood relative of.’’ (Hints: I am not the brother of myself. Two people are blood relatives if they share the blood of a common ancestor, who may or may not be part of sets A, B, or C. I am the blood relative of myself.) * Advanced assignment.

146

GRAPHS AND DIRECTED GRAPHS (DIGRAPHS)

Intransitive

Transitive

Asymmetric

Anti-symmetric

Symmetric

Irreflexive

Reflexive

Create a digraph for each of the three relations on each of the three sets. Identify which of these relations satisfy which of the seven properties of unary relations for each of the three sets by placing a yes or no in the empty cells of the following table.

5.7 A city street snapshot is shown in the ﬁgure. Note there are streets with arcs on them indicating one-way streets. The streets with double-headed arcs are two-way streets. There are 11 intersections, labeled 1 through 11.

PROBLEMS

147

a. Draw a directed graph that represents this street system. (Hint: Use a node to represent street intersections.) b. Is this digraph quasi-strongly connected? If not, what is the minimum number of arcs that must be added and what nodes must they connect to make it quasi-strongly connected? If yes, why? c. If you think the digraph in part (a) is quasi-strongly connected, draw a directed spanning tree for it. If you do not think the digraph in part (a) is quasi-strongly connected, add arcs so that it is and then draw a directed spanning tree for it. d. What is the height of the tree that you have drawn? 5.8 For the set of all possible relations, create a partition using combinations of the properties symmetric, antisymmetric, and asymmetric where each subset in the partition cannot be empty. As an example, a partition of all relations using the properties reﬂexive and irreﬂexive would be: (reﬂexive relations), (irreﬂexive relations), (relations that are neither reﬂexive nor irreﬂexive). Note the subset of relations that are both reﬂexive and irreﬂexive is left out because this combination is impossible. 5.9 Consider an IDEF0 model in which the function A0 has two inputs (I1 and I2), three controls (C1, C2, and C3) and three outputs (O1, O2, and O3). The IDEF0 function, A0, can be considered a relation that maps elements of D = (I1 X I2 X C1 X C2 X C3) into elements of P = (O1 X O2 X O3). The 5-tuple for inputs and controls to A0 and the 3-tuple for outputs are used because each input, control, and output represents a set of possible inputs, controls, or outputs, respectively. The n-tuples deﬁne all possible combinations of inputs and outputs, respectively. Under what restrictions is A0 a function? Why?

Part

Design and Integration

Chapter

Requirements and Defining the Design Problem

6.1

INTRODUCTION

Requirements are the cornerstone of the systems engineering process: Stakeholders’ requirements provide operational statements by the stakeholders concerning their needs; derived requirements enable the engineers of systems to partition the design problem into components that can be worked in parallel while maintaining design control through the requirements partition and the interfaces between the components; derived requirements enable the veriﬁcation of the conﬁguration items and components during the qualiﬁcation activity during development; and stakeholders’ requirements provide the means for validating the system’s design during qualiﬁcation. Requirements do not just show up on the systems engineer’s desk. Obtaining ‘‘good’’ requirements is critical to the successful engineering of a system [Blum, 1992, pp. 68–81; Davis, 2005, pp. 3–39]. The systems engineer must work hard with the stakeholders of the system to develop the requirements. Fortunately, there is a tried and true method with some valuable modeling techniques that can be used in this effort. There are few references that provide a coherent view of the systems engineering process for developing stakeholders’ requirements for a system, including a deﬁnition of how these requirements might be usefully characterized to aid the generation process. Grady [1993] provides an excellent discussion of what requirements are, how requirements should be written one at a time and in documents, and how requirements should be allocated. Faulk et al. The Engineering Design of Systems: Models and Methods, Second Edition. By Dennis M. Buede Copyright r 2009 John Wiley & Sons, Inc.

151

152

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

[1992] describe a software engineering method for real-time requirements that has many of the characteristics that are important. Crowe et al. [1996] adapt the method of Faulk et al. [1992] to software-intensive systems; however this adaptation is incomplete because software engineering assumes systems engineers are their interface to the stakeholders. However, no reference found by the author discusses systematically how requirements should be developed and how such constructs as the operational concept, prototyping, objectives hierarchy, and external systems diagram can be used in this process. This chapter (an expansion of Buede [1997]) deﬁnes such a process that is consistent with most systems engineering practice. This chapter begins by discussing what requirements are. Deﬁnitions that are key to putting a system in its context with external systems and the environment are provided next. Section 6.4 deﬁnes the process or method by which requirements are developed. A discussion of various categories of requirements found in the literature of systems engineering are then discussed, followed by the partition of requirements that will be used in this book. The proposed outline for a stakeholders’ requirements document that addresses all phases of the system’s life cycle is provided in Section 6.7. The literature on requirements has proposed a number of characteristics that deﬁne either a sound individual requirement or a set of sound requirements; these characteristics of sound requirements are given in Section 6.8. The convention for writing requirements is discussed in Section 6.9. Sections 6.10 to 6.13 describe in detail the portions of the process for developing requirements: deﬁning the operational concept for each phase of the system’s life cycle, creating an external systems diagram for each phase of the life cycle, establishing an objectives hierarchy for each phase of the life cycle, and conducting prototyping and usability testing to analyze the potential requirements in each phase of the life cycle. Section 6.14 provides a detailed discussion of the four segments of the requirements partition for each phase of the life cycle: the input/output requirements, the system-wide and technology requirements, the trade-off requirements, and the qualiﬁcation requirements. Finally, the issue of managing requirements during the development of a system is discussed. The focus of this chapter is the method for deﬁning requirements for a system and all of the systems associated with each phase of the system’s life cycle. There are seven activities associated with this method: developing the operational concept; deﬁning the system boundary; developing an objectives hierarchy; developing, analyzing, and reﬁning the requirements (including prototyping and usability testing); ensuring requirements feasibility; deﬁning the qualiﬁcation system requirements; and obtaining approval of the requirements. Several models are introduced to support the process for deﬁning requirements. A qualitative model, an input/output trace, is described for deﬁning a scenario that is part of the system’s operational concept. An application of IDEF0 (Integrated Deﬁnition for Function Modeling) modeling is described

6.2

REQUIREMENTS

153

for deﬁning the process of a system’s interaction with other (external) systems; this external system diagram deﬁnes all of the inputs and outputs associated with the system. A hierarchical decomposition of the objectives for a system is another example of a qualitative model used in this requirements deﬁnition process. The exit criterion for this initial activity in the engineering of a system is the approval of the requirements document by the stakeholders. Often the engineers of a system are focused on obtaining this approval as quickly as possible, often without deﬁning all of the requirements suggested in this chapter. The trade-off and qualiﬁcation requirements are missing from most requirements documents. The contention of this chapter is that the real exit criterion of the requirements deﬁnition process is the approval by the stakeholders of the acceptance plan for the system. If the acceptance plan is afﬁrmed, then all of the other portions of the requirements document are presumed to he deﬁned in acceptable detail.

6.2

REQUIREMENTS

Many authors have deﬁned the term requirement. The list below provides several deﬁnitions that highlight key concepts (the italics are the author’s). Sailor [1990]: identiﬁable capabilities expressed as performance measurables of functions that the system must possess to meet the mission objectives. MIL-STD 499B [Military Standard, 1993]: identiﬁes the accomplishment levels needed to achieve speciﬁc objectives. Chambers and Manos [1992]: the attributes of the ﬁnal design that must be a part of any acceptable solution to the design problem. Grady [1993]: an essential attribute for a system or an element of a system, coupled by a relation statement with value and units information for the attribute. Davis [2005]: an externally observable characteristic of a desired system. The requirements for a system set up standards and measurement tools for judging the success of the system design. These requirements should be viewed hierarchically. At the top are mission-level requirements that establish how the stakeholders will beneﬁt by introducing the system in question into the supersystem of the system. These mission requirements relate to objectives of the stakeholders that are deﬁned in the context of the supersystem, not the system itself. For example, Boeing identiﬁed two primary mission requirements when starting on the Boeing 777 commercial aircraft: trip cost per seat and total trip cost. Each airline company that purchases a 777 is the meta-system that most inﬂuences an aircraft company during the development phase.

154

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

Stakeholders’ requirements are developed next in the context of these mission requirements and should focus on the boundary of the system. If the stakeholders’ requirements are deﬁned internally to the system, the risk of having design statements embedded in the requirements goes up substantially. A major emphasis of this chapter is that the stakeholders’ requirements should be as design independent as possible. Boeing’s stakeholders’ requirements for the 777 included such topics as liftable weight of the aircraft at speciﬁed conditions, the empty weight of the aircraft, the drag force on the aircraft for certain speciﬁed ﬂight conditions, and the fuel consumption of the aircraft at certain speciﬁed ﬂight conditions. As discussed in Chapter 1 system requirements are a translation (or derivation) of the stakeholders’ requirements into engineering terminology. Once this translation occurs, the derivation process of requirements continues. Recall from Chapter 1 that the goal of the design process is to create a system speciﬁcation that can be developed into speciﬁcations for the system’s components, which are then segmented into speciﬁcations for the system conﬁguration items (CIs). As a result the design process creates two hierarchies of requirements as shown in Figure 6.1. The stakeholders’ requirements are produced in conjunction with the stakeholders of the system, based upon the operational needs of these stakeholders. Some systems engineers believe the systems engineering process begins when the Stakeholders’ Requirements Document (StkhldrsRD) arrives; however the position taken here and supported by Pragmatic Principle 1 [De Foe, 1993] of the International Council on Systems Engineering (INCOSE) is that the systems engineers must be involved with the stakeholders to have any hope of producing a useful StkhldrsRD; note italicized items. In fact, the process described in this chapter is focused on methods and models for developing a valid and complete StkhldrsRD.

Mission Requirements

Stakeholders’ Requirements

System Requirements

Component Requirements

Derived Requirements

CI Requirements

FIGURE 6.1 Requirements hierarchies.

6.2

REQUIREMENTS

155

The Systems Requirements Document (SysRD), which is derived from the StkhldrsRD, is a translation from the language of stakeholders to the language of engineers. The system’s requirements are traced directly from the stakeholders’ requirements. Note the term stakeholder is used in the above discussion in place of the more common term user. This is to emphasize the fact that there are usually multiple categories of users of a system: owner and/or bill payer, developer, producer or manufacturer, tester, deployer, trainer, operator, user, victim, maintainer, sustainer, product improver, and decommissioner. Each stakeholder has a signiﬁcantly different perspective of the system and the system’s requirements. If one perspective is singled out as the only appropriate one, the developers of the system will miss key information, and the system will be viewed negatively or as a failure from the other perspectives. The systems engineering process for creating a system design is decision rich. That is, the systems engineer is searching via a great deal of analysis and experience to ﬁnd a very good (optimum is usually not possible to determine) solution that satisﬁes all of the mandatory requirements of the stakeholders and delivers as much performance as possible within the guidelines of cost and schedule. This search process involves making many decisions about the system’s physical character (or resources) and allocations of functions to resources that are usually only revisited if absolutely necessary. This search process occurs as the top-down onion-peeling process of systems engineering occurs. Figure 6.1 shows derived requirements at the component level (which may be several layers of the onion) and the CI (or bottom) level. Chapters 7 through 10 will describe this process of architecture development and creation of appropriate derived requirements, supported by analysis and judgment. To continue the story of the Boeing 777, Boeing created requirements for a major subsystem of the 777 — the engine. These derived requirements for the engine included the weight of the engine (derived from the weight of the empty aircraft), the thrust of the engine at speciﬁed conditions (derived from the liftable weight of the aircraft), the drag of the engine at speciﬁed conditions (derived from the drag of the aircraft), and the fuel consumption of the engine at speciﬁed conditions (derived from the fuel consumption of the aircraft). A major impediment to this design process being successful is the overconstraint of the solution space by the stakeholders’ requirements. The systems engineers job is to work with the stakeholders to deﬁne the stakeholders’ requirements so as to make sure that there is signiﬁcant design freedom within these requirements and that many feasible designs exist. Stakeholders and (all too often) engineers are willing to constrain the requirements space very tightly without fully understanding or appreciating the potential value of the design options that they are eliminating. The stakeholders’ requirements process deﬁned in this chapter takes explicit account of this need to have and deﬁne a large tradable region in design space for the systems engineers to search with quantitative techniques utilizing the priorities of the stakeholders.

156

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

Pragmatic Principle 1 [DeFoe, 1993] Know the Problem, the Customer, and the Consumer 1. Become the ‘‘customer/consumer advocate/surrogate’’ throughout the development and ﬁelding of the solution. 2. Begin with a validated customer (buyer) need — the problem. 3. State the problem in solution-independent terms. 4. Know the customer’s (or buyer’s) mission or business objectives. 5. Do not assume that the original statement of the problem is necessarily the best, or even the right one. 6. When confronted with the customer’s need, consider what smaller objective(s) is/are key to satisfying the need, and from what larger purpose or mission the need drives; that is, ﬁnd at the beginning the right level of problem to solve. 7. Determine customer priorities (performance, cost, schedule, risk, etc.). 8. Probe the customer for new product ideas, product problem/shortfalls, identiﬁcation of problem ﬁxes. 9. Work with the customer to identify the consumer (user) groups that will be affected by the system. 10. Use a systematic method for identifying the needs and solution preferences of each customer group. 11. Don’t depend on written speciﬁcations and statements of work. Face-toface sessions with the different customer/consumer groups are necessary. 12. State as much of each need in quantiﬁed terms as possible. However, important needs for which no accurate or quantiﬁed measure exists still must be explicitly addressed. 13. Clarify each need by identifying the power and limitations of current and projected technology relative to the customer’s larger purpose, the environment, and ways of doing business.

6.3

DEFINITIONS

Before discussing the process for developing stakeholders’ requirements, the deﬁnitions presented in Chapter 2 are reviewed. A system is a set of components (subsystems, segments) acting together to achieve a set of common objectives via the accomplishment of a set of tasks. A system task or function is a set of functions that must be performed to achieve a speciﬁc objective. A human-designed system is (a) a specially deﬁned set of segments (hardware, software, physical entities, humans, facilities) acting as planned (b) via a

6.4

STAKEHOLDERS’ REQUIREMENTS DEVELOPMENT: DEFINING THE DESIGN PROBLEM

157

Context External Systems

System are impacted by “System” impacts, but not impacted by, “System”

FIGURE 6.2 Depiction of the system, external systems, and context.

set of interfaces, which are designed to connect the components, (c) to achieve a common mission or fundamental objective (i.e., a set of specially deﬁned objectives), (d) subject to a set of constraints, (e) through the accomplishment of a predetermined set of functions. The external systems [Levis, 1993] of a system are a set of entities that interact with the system via the system’s external interfaces. Note in Figure 6.2, the external systems can impact the system and the system does impact the external systems. The system’s inputs may ﬂow from these external systems or from the context, but all of the system’s outputs ﬂow to these external systems. The external systems, many or all of which may be legacy (existing) systems, play a major role in establishing the stakeholders’ requirements. The context [Levis, 1993] of a system is a set of entities that can impact the system but cannot be impacted by the system. The entities in the system’s context are responsible for some of the system’s requirements. See Figure 6.2. Wieringa [1995] uses the phrase ‘‘universe of discourse’’ to label the context and external systems that part of the world about which the system registers data and controls behavior.

6.4 STAKEHOLDERS’ REQUIREMENTS DEVELOPMENT: DEFINING THE DESIGN PROBLEM Developing a good and complete set of requirements is very difﬁcult. First, we have to ﬁgure out what topics we should be writing requirements about. These topics for the system-level requirements should all be at the same level of granularity, a level of granularity that is consistent with the system-level and not the meta-system or subsystems. To facilitate deﬁning these topics we will introduce the concepts of an operational concept, external systems diagram, and objectives hierarchy.

158

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

After we determine what the topics of the requirements conversation are going to be, we can start writing speciﬁc requirements. Now we have to determine what we want to say in that requirement. What is the threshold we are going to set for the minimum level of acceptable achievement? Here we will talk about prototyping, analysis, elicitation, and usability testing. Next the requirements should be analyzed to determine that at least one feasible solution exists. A common problem is that we have deﬁned thousands of requirements and together they are so constraining that there is no solution with enough performance at a low enough cost and a quick enough schedule. Often it is very difﬁcult to determine that there is a feasible solution so this step is skipped. Typically the selected design proves to be insufﬁcient for 5 to 20 requirements, meaning it was not a feasible solution. Late in the design process systems engineers are confronted with the problem of should we search for a new design or accept the fact the current design cannot meet all of the requirements. The last step before approval should be deﬁning qualiﬁcation or test requirements that are appropriate for the level of requirements being deﬁned. When deﬁning system-level requirements these qualiﬁcation requirements should address how will system-level veriﬁcation and validation be done. So the seven functions of this stakeholders’ requirements development process are: 1. 2. 3. 4. 5. 6. 7.

Develop operational concept Deﬁne system boundary with external systems diagram Develop system objectives hierarchy Develop, analyze, and reﬁne requirements (stakeholders’ and system) Ensure requirements feasibility Deﬁne the qualiﬁcation system requirements Obtain approval of system documentation

These seven functions are shown in an IDEF0 diagram in Figure 6.3. This diagram is taken from the IDEF0 model of the process for engineering a system in Appendix B. To deﬁne this process fully, the ﬁrst three functions must be deﬁned in meaningful terms to justify their presence and provide explicit inputs to the fourth function. The last three functions are important but follow-on from the development of the StkhldrsRD. The resource that performs these functions is the systems engineering team; this resource is not shown in Figure 6.3 to improve the readability of the IDEF0 diagram. The operational concept is prepared from the perspective of the stakeholders of the system and describes how these stakeholders expect the system to ﬁt into their world that contains a number of external systems and has a certain context. The objectives of each stakeholder group are suggested here. The operational concept deﬁnes the system and external systems in very general terms (often as a block diagram) and establishes a use case diagram and the

159

NOTES: 1 2 3 4 5 6 7 8 9 10

Objectives Hierarchy

NODE:

A111

Define System-Level Design Problem

P. 6

Stakeholders' & System Requirements

Stakeholders' Requirements Issues

Originating & System Requirements, Objectives Hierarchy, Boundary & Qualification System Requirements

System-level Operational Concept

DATE CONTEXT:

Approval or Disapproval

NUMBER:

FIGURE 6.3 IDEF0 diagram of the system-level design process.

TITLE:

Stakeholders' & System Requirements

A1117

Obtain Approval of Requirements Documentation

Qualification System Requirements

Qualification Constraints

READER

Proven Requirements Feasibility

A1115

A1114

Allocated Architecture Changes to Requirements

Objectives Hierarchy

Proven Requirements Infeasibility

A1116

Define Qualification System Requirements

Qualification System Issues

Ensure Requirements Feasibility

A1113

Develop System Objectives System Hierarchy Boundary &

A1112

Define System Boundary with an External Systems

Engineers' Requirements Issues

Develop, Analyze and Refine Requirements

A1111

System Boundary

Requirements Issues

Stakeholders' Constraints

WORKING DRAFT RECOMMENDED PUBLICATION

Lower Layer Changes to Requirements

Design Changes

Stakeholders' Jurisdiction

Develop Operational Concept

Stakeholders' Uses

DATE: 05/24/99 REV:

Stakeholders' Objectives

AUTHOR: Dennis Buede PROJECT: Engineering Design of a System

Inputs of Stakeholders

USED AT: GMU Systems Engineering Program

160

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

associated usage scenarios as sequence diagrams. These usage scenarios describe ways in which the stakeholders will use the system as well as interactions between the system and other systems. These scenarios deﬁne inputs to and outputs of the system. In addition, the operational concept includes the mission requirements for the system. The second step, creating the external systems diagram, makes the boundaries between the system and external systems clear, leaving no doubt in anyone’s mind where the system starts and stops. The development of this diagram and the explication of the system’s boundaries are nearly always harder than most people expect. As part of deﬁning the system’s boundaries, all of the inputs to and outputs of the system are established, as well as the external system or context with which each input and output is associated. The third step clariﬁes the objectives of the stakeholder groups and formulates a coherent set of objectives for the system. Again, the output of this step looks like it could have been created in a few hours, but generally takes days if not weeks. Each objective is part of the value system of one or more stakeholders for determining their satisfaction with the system. Naturally these objectives conﬂict with each other in the sense that gaining value on one objective (e.g., availability) means it will be necessary to give up value on another objective (e.g., cost). The creation of the stakeholders’ requirements, followed by the translation of these requirements into system requirements, is the fourth step. The stakeholders’ requirements are created by an analysis of the operational concept for system functions, an exhaustive examination of the system’s inputs and outputs, the speciﬁcation of interfaces of the external systems with which the system must interact, a thorough examination of the system’s context and operational concept for system-wide and technology constraints, a detailed discussion with the stakeholders to understand their willingness to trade-off a wide range of non-mandatory but desirable system features, and the complete speciﬁcation of qualiﬁcation requirements needed to verify and validate the system’s capabilities from the stakeholders perspectives. Often a simulation model that depicts some or all of the interaction between the system and one or more other external systems is developed. These simulation models often address timing issues, speciﬁc performance issues, reliability or availability, safety and security, or quality of inputs and outputs. Cost analyses of a system should be done with the context in which the system is going to operate in mind. An important tool used during requirements development is prototyping, the development of replicas of the parts of the system. For user interfaces this prototyping is particularly important because users often do not know what is possible with new technology or how they might use this new technology effectively. For prototyping of user interfaces to be effective some form of usability testing is commonly used to determine how the users function with the prototype. Before proceeding too far into the design process, these requirements must be examined to ensure that a feasible design exists that meets the requirements.

6.5

REQUIREMENTS CATEGORIES

161

For example, building a supersonic transport aircraft that has a production cost of $1000 is not possible. While this simple, exaggerated example illustrates the problem, in practice the development of hundreds, or even thousands, of requirements makes the test for feasibility quite difﬁcult. The sixth step is the development of requirements for the qualiﬁcation system needed to verify and validate the resulting system. This involves the development of input/output requirements for the qualiﬁcation system, as well as system-wide requirements. Trade-off requirements are also needed for the qualiﬁcation system. Finally, the qualiﬁcation system must also be qualiﬁed. Finally, the stakeholders must approve the requirements documents. This approval process works best when the stakeholders are actively involved in and understand the previous steps. Before deﬁning and discussing requirements, noting that requirements must be developed for each phase of the system’s life-cycle is important. The lifecycle phases used in this book are: 1. 2. 3. 4. 5. 6. 7.

Development (design and integration) Manufacturing or production Deployment Training Operations, maintenance, and support Reﬁnement Retirement

There is a strong correlation between the stakeholders and the life-cycle phases. These seven functions should be applied to each stakeholder group and phase of the system’s life cycle. Note that some of these phases may not be relevant for some systems. Most of the discussion from here on out will focus on the operations, maintenance, and support phase, but keep in mind that all phases of the life cycle should be addressed. Table 6.1 discusses who is involved in this requirements generation process and what their roles are.

6.5

REQUIREMENTS CATEGORIES

Many authors have categorized requirements. Here are some of the oftendiscussed categories: 1. Speciﬁcation Level Stakeholders’, Derived, Implied and Emergent: Stakeholders’ requirements, derived from operational needs, are those top-level statements deﬁned in language that is understandable to the stakeholders, leaving substantial room for design ﬂexibility. Stakeholders’ requirements should deﬁne the essence of the stakeholders’ needs sufﬁciently clearly for

162

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

TABLE 6.1 Roles and Responsibilities during Requirements Generation Who has the right to have a stakeholders’ requirement?

What does one call a requirer? Who must respond to the requirer(s) having a requirement and how?

By what criteria does the Systems Requirements Team respond?

How does one know that the requirement is ‘‘right?’’

How are these requirements conveyed to the people who get involved once a requirer has enunciated a requirement?

What does the Systems Requirements Team do next?

Any individual/organization with a need involved in the development (design and qualiﬁcation), production, deployment, training, operation, maintenance, support, reﬁnement, decommissioning of and payment for the system. Customer or stakeholder System’s requirements team, a collection of stakeholders and systems engineers. Response is acceptance, request for clariﬁcation, or rejection. This team establishes the external systems diagram and fundamental objectives hierarchy of the system, and then determines if the requirement ﬁts within the scope of the system’s boundary and fundamental objective. Stakeholders’ requirements also have to be assessed for the proper level of abstraction. A requirement should not be too strategic (mission oriented) or means (or solution) oriented. There is no right or wrong, only acceptable or unacceptable at this time. Over time, some of the stakeholders’ requirements will change. The system’s requirements team documents the collection of stakeholders’ requirements. This stakeholders’ requirements document (StkhldrsRD) is distributed to the stakeholders and systems engineers. Included in this document is a discussion of the operational concept of the system and the external systems and context associated with the system, that is, how each stakeholder expects to interact with the system. By reviewing the stakeholers’ requirements document each stakeholder can see how the requirement s/he suggested ﬁts into the envisioned operation of the system, and can judge whether this vision makes sense from her/his perspective. The system’s stakeholders’ requirements team remains active throughout the (Continued)

6.5

REQUIREMENTS CATEGORIES

163

TABLE 6.1. Continued system’s life cycle. During design there will be many occasions when the system’s stakeholders’ requirements must be reviewed and modiﬁed. These occasions will diminish in frequency once the system is deployed, but the requirements process is still critical as requirements changes and system modiﬁcations are envisioned, agreed to, developed and ﬁelded.

the stakeholders to be completely satisﬁed with whatever system results from the systems engineering process. Derived requirements are those requirements deﬁned by the systems engineering team in engineering terms during the design process. Derived requirements are needed to complete the design to sufﬁcient detail for the speciﬁcation to be delivered to the design teams responsible for the physical conﬁguration items of the system. Implied requirements are those requirements not speciﬁcally identiﬁed in the StkhldrsRD but that can be inferred based upon information in the StkhldrsRD. Emergent requirements are those requirements that are not even hinted at in the StkhldrsRD but whose presence is made known by stakeholders later in the systems engineering process. These last two sets of requirements are to be avoided if possible by a sound and systematic stakeholders’ requirements development process. 2. Performance Requirements Versus Constraints. Performance requirements: deﬁne on some index that establishes a range of acceptable performance from a minimum acceptable threshold to a design goal. Constraints simply rule out certain possible designs; for example, the system must be painted a speciﬁc shade of green. A performance requirement deﬁnes a desired direction of performance; for an elevator system (which is used throughout this book as an example), a performance requirement might be to ‘‘minimize passengers’ waiting time during peak periods.’’ For any performance requirement there must also be a minimum acceptable performance constraint or threshold associated with the index, beyond which designs with such poor performance are not feasible (e.g., average passengers’ waiting time during peak periods shall be less than 35 seconds). Often there is also a maximum threshold or goal on the performance index that states the stakeholders do not noticeably value performance beyond this point (e.g., average passengers’ waiting time during peak periods need not be less than 27 seconds). 3. Application — System Versus Program: System requirements relate to characteristics of the system’s performance (in the broadest sense). Program

164

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

requirements relate to the ﬁrst life-cycle phase of the systems engineering process and usually address the treatment of the cost and schedule for this phase. Program requirements relate either to the programmatic tasks that must be performed, programmatic trade offs among cost and schedule, and programmatic products associated with the systems engineering process (e.g., the Up & Down Elevator Corporation shall own full rights to the design data of the elevator). 4. Functional, Interface, or System-wide Requirements: Functional requirements relate to speciﬁc functions (at any level of abstraction) that the system must perform while transforming inputs into outputs. As a result, a functional requirement is a requirement that can be associated with one or more of the system’s outputs. Interface requirements are usually constraints that deﬁne the reception of inputs and transmission of outputs between the system and the system’s environment. System-wide requirements (often called ‘‘-ilities’’) are characteristics of the entire system; examples include availability, reliability, maintainability, durability, supportability, safety, trainability, testability, extensibility (growth potential), and affordability (e.g., operating cost).

6.6

REQUIREMENTS PARTITION

There is great value in having a structure for various types of requirements. If the requirements are listed in random order in a requirements document, it is nearly impossible to be sure that a given requirement is not addressed multiple times in that single requirements document. It is also difﬁcult to ﬁnd a speciﬁc requirement in a large document. There are other beneﬁts of a requirements structure, especially if the structure is a partition. A partition is a structure that has subcategories that are mutually exclusive, meaning a requirement can only be put in one category. A partition also needs to be exhaustive, meaning every requirement has some category that is appropriate for it. By creating such a partition, it is easy to review the partition to ensure that there as many requirements in that category as expected and every requirement in the category is appropriate for that category. The partition that is introduced here has both a vertical spectrum and a horizontal spectrum. The vertical spectrum was introduced in Figure 6.1, which shows two vertical levels of requirements written for the stakeholders and three or more levels of derived requirements written for the engineers. The horizontal spectrum addresses the life cycle as well as categories of requirements within each phase of the life cycle. The life-cycle steps or phases include development, production, operations, etc.; recall Figure 6.1. The categories of requirements within each phase of the life cycle are discussed next. Wymore [1993] identiﬁes six types of system design requirements: input/ output, technology and system-wide, performance trade-off, cost trade-off,

6.6

REQUIREMENTS PARTITION

165

cost–performance trade-off, and test. These six types of requirements are condensed into four categories: input/output, technology and system-wide, trade-off, and qualiﬁcation (test). From a concurrent engineering perspective each requirements category should be used to address the relevant system (e.g., development system, manufacturing system) in each phase of the system’s life cycle (development, production, deployment, training, operation and maintenance, reﬁnement and retirement). Table 6.2 provides examples of various types of requirements; these examples have been collected from a wide variety of sources. 1. Input/output requirements: include sets of acceptable inputs and outputs, trajectories of inputs to and outputs from the system, interface constraints imposed by the external systems, and eligibility functions that match system inputs with system outputs for the life-cycle phase of interest. Clearly there are a number of requirements in this category during the operations phase of the life cycle. However, the system may have inputs and outputs in all portions of the system’s life cycle (e.g., training stimulations, standardized internal interfaces for product improvement); if so, the requirements for these activities would be found in this category in the appropriate life-cycle phase. This category is partitioned into four subsets: (a) inputs, (b) outputs, (c) external interface constraints, and (d) functional requirements. Input requirements state what inputs the system must receive and any performance or constraint aspects of each. Output requirements state what outputs the system must produce and any performance aspects; Table 6.2 provides an extensive list of possible performance issues for the outputs of any system, segmented by quality, quantity, and timeliness. External interface requirements deal with limitations placed upon the receipt of inputs and transmission of outputs by the interfaces of the external systems; see Table 6.2. Functional requirements can be endless unless organized; the functional requirements proposed here are the two to seven functions that are the ﬁrst-level decomposition of the system’s function. The very strong position being taken here is that the input and output requirements are the key to deﬁning the needs of the stakeholders in terms that they can understand. Stakeholders in each phase of the system’s life cycle can relate to quantity, quality, and timing aspects of the outputs delivered by the system under question and the ability to deal with quantity, quality, and timing of inputs. The engineers of the system develop the system’s functions during the design process. This development of a functional architecture (see Chapter 7) is a very valuable means for dealing with the complexity of the engineering problem. But the stakeholders should not care a whit about the functions being performed by the system as long as they are happy with the characteristics of the inputs being consumed and the outputs being produced by the system. The concept of having a major section of requirements devoted to the functions of the system is misguided and guaranteed not to elicit the needs of the stakeholders.

166

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

TABLE 6.2 Exemplary Requirement Dimensions Requirements Category Input or Output Performance

Undesired or Unexpected Inputs Interface Constraint

Suitability or Quality Issues of the System

Costs for Various Life Cycle Phases

Schedule for Various Life Cycle Phases

Exemplary Requirement Dimensions Quality of an output Accuracy (or precision) Correctness (or conﬁdence, error rate) Security (or perishability, survivability) Quantity of an output Intensity, Size, or Distance Number per unit time (throughput, velocity) Coverage (area or volume served by outputs) Timing of outputs Response time (timeliness, time to create an output) Update frequency Availability Unexpected or undesired inputs and appropriate response Bounds on expected inputs and appropriate response Required format of an input or output as deﬁned by the interface Timing constraint associated with an interface Physical form or ﬁt of an interface Usability Weight of the system Form (volume) and ﬁt (dimensions) of the system Survivability of the system Availability, reliability, maintainability of the system Supportability of the system Safety of the system Security Trainability of the system Testability of the system Extensibility (expected changes/growth potential) of the system Affordability (or operating and maintenance cost) of the system Development cost Production cost (manufacturability) of the system Deployment and training costs of the system Decommissioning cost of the system Development period Manufacturing time for each unit Training time to reach proﬁciency by category of user Deployment period Durability (or operational life) of the system

6.6

REQUIREMENTS PARTITION

167

2. Technology and system-wide requirements: consist of constraints and performance index thresholds (e.g., the length of the operational life for the system, the cost of the system in various life-cycle phases, and the system’s availability) that are placed upon the physical resources of the system. Many of the requirements from each phase of the system’s life cycle are found in this category because these requirements speciﬁcally relate to the physical manifestation of the system. This category can be partitioned into four subsets: (a) technology, (b) suitability and quality issues, (c) cost for the relevant system (e.g., development cost, operational cost), and (d) schedule for the relevant life-cycle phase (e.g., development time period, operational life of the system). 3. Trade-off requirements: are algorithms for comparing any two alternate designs on the aggregation of cost and performance objectives. These algorithms can be divided into (a) performance trade offs, (b) cost trade offs, and (c) cost–performance trade offs. The performance trade-off algorithm deﬁnes how the relative performance of any two alternate designs can be compared in terms of the system’s performance objectives. These performance objectives are deﬁned within the input/output and non-cost system-wide requirements. The performance trade-off algorithm speciﬁcally deﬁnes how the performance parameters are to be compared to each other. The cost trade-off algorithm deﬁnes how the relative cost of any two alternate designs can be compared across all cost parameters (life-cycle phases) of interest to the stakeholders. Note dollars spent at different times may not be comparable by present value computations when there are different bill payers at different times. Finally, the cost–performance trade offs deﬁne how performance objectives should be traded with cost objectives. These trade-off algorithms could be based upon many different mathematical logics; indeed many have been proposed. The strong position taken in this book is that these trade-off algorithms must be based upon the value preferences of the stakeholders. Decision analysis provides a normative basis for these preference judgments and algorithms, as described in detail in Chapter 13. For applications of these decision analysis techniques (value curves and swing weights) see Buede and Bresnick [2007], Buede and Choisser [1992], Daniels et al. [2001], Ross et al. [2004], Thurston and Carnahan [1993], Walton and Hastings [2004]. The ideal approach for quantifying the trade-off preferences of the stakeholders would be to obtain these preferences as statements of ‘‘willingness-to-pay’’ (in terms of money for development effort) for enhanced performance and decreased cost in each of the other life-cycle phases. To make these statements of ‘‘willingness-to-pay’’ operationally meaningful, the appropriate contractual arrangements must be established that would permit the transfer of payments based upon the stated payment preferences. In addition, a warranty system must be established that requires the developers to stand behind their developmental phase claims of performance attainment during the remaining phases of the system’s life cycle. For example, if a

168

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

performance claim made during the development phase is not achieved during the operational phase, the developer would have to make a warranty payment to the stakeholders. Although this entire approach is known and obviously will work, the approach has never been used to the author’s knowledge. In fact, users are quite cynical about the performance claims made by developers during the development phase. 4. System qualiﬁcation requirements: address the needs to qualify the system as being designed right, the right system, and an acceptable system. There are four primary elements: a. Observance: state which qualiﬁcation data for each input/output and system-wide requirement will be obtained by (i) demonstration, (ii) analysis and simulation, (iii) inspection, or (iv) instrumented test. b. Veriﬁcation Plan: state how the qualiﬁcation data will be used to determine that the real system conforms to the design that was developed. c. Validation Plan: state how the qualiﬁcation data will be used to determine that the real system complies with the stakeholders’ performance, cost, and trade-off requirements. d. Acceptance Plan: state how the qualiﬁcation data will be used to determine that the real system is acceptable to the stakeholders. Note the qualiﬁcation requirements associated with the ﬁrst objective deﬁne the basis for the requirements for the suite of qualiﬁcation systems (e.g., simulations, instrumented test equipment) needed for the system under development. Having technology/system-wide requirements that limit the ﬂexibility to develop new test equipment is common. This requirements’ partition provides a solid basis and set of guidelines for guaranteeing that the system’s requirements are complete, consistent, unique, comparable, and modiﬁable. (These terms will be deﬁned a little later.) Success is not certain with this basis and guidelines but is greatly enhanced over current industry practice. Figure 6.4 traces the origins of the performance requirements to the objectives hierarchy by showing that the objectives hierarchy deﬁnes the performance parameter requiring nonpoint requirements. These performance parameters can fall within the categories of input, output, ‘‘-ilities,’’ cost, and schedule requirements. The thresholds and goals for these tradable requirements are deﬁned as part of the input, output, ‘‘-ilities,’’ cost, and schedule requirements. The algorithms that deﬁne the tradable space over these performance parameters are documented in the performance, cost, and cost– performance trade-off requirements. The performance, cost, and cost–performance trade-off requirements combine to deﬁne the iso-value lines in the tradable space; these iso-value lines will be the basis for all design trade offs. If every set of requirements contained the information deﬁned by Wymore [1993], there would be far fewer problems in system development efforts. Very few

6.7

STAKEHOLDERS’ REQUIREMENTS DOCUMENT (StkhldrsRD)

169

Requirement Partition by Life-Cycle Phase Input/Output

Technology & System-Wide

Trade Off

System Qualification

Input

Technology

Cost Trade-offs

Data for all qualification

Output

"-ilities"

Performance Trade-offs

Verification Plan

Functions

Cost

Cost−Performance Trade-off

Validation Plan

External Interfaces

Schedule

Acceptance Plan

Thresholds & Goals

Objectives Hierarchy

Trade Space

FIGURE 6.4 Objectives hierarchy, requirements partition, and trade space.

requirements documents contain performance, cost, and cost–performance trade-off requirements as deﬁned by Wymore. These elements should be deﬁned in the stakeholders’ requirements document from the stakeholders’ perspective; otherwise the systems engineers must guess at the ultimate trade offs of the stakeholders; the ability of engineers to do a complete and effective job of guessing iso-value trade offs is questionable at best.

6.7

STAKEHOLDERS’ REQUIREMENTS DOCUMENT (StkhldrsRD)

The format for an StkhldrsRD (Fig. 6.5) should include sections for a brief overview of the system, references to relevant documents from which the stakeholders’ requirements have been traced, and the requirements. The requirements should be organized by life-cycle phase. Within each life-cycle phase requirements from the four segments of the above taxonomy should be developed. The life-cycle phases are being called out explicitly to highlight the criticality of the concurrent engineering nature of the design problem.

170

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

Stakeholders’ Requirements Document

1.0 System Overview 2.0 Applicable Documents 3.0 Requirements 3.1 Development Phase (Programmatic) Requirements 3.1.1 Input/Output Requirements for Development ... 3.1.4 Qualification Requirement for Development 3.2 Manufacturing Phase Requirements ... 3.3 Deployment Phase Requirements ... 3.4 Training Phase (if present) Requirements ... 3.5 Operational Phase Requirements 3.5.1 Input/Output Requirements for Operations 3.5.1.1 Input Requirements for Operations 3.5.1.2 Output Requirements for Operations 3.5.1.3 External Interface Requirements for Operations 3.5.1.4 Functional Requirements for Operations 3.5.2 System-wide/Technology Requirements for Operations 3.5.3 Trade-off Requirement for Operations 3.5.4 Qualification Requirement for Operations 3.6 System Improvement/Upgrade Phase Requirements ... 3.7 Retirement Phase Requirements ... 3.8 Overall Trade-Off Requirement Appendix A. Operational Concepts by Phase Appendix B. External System Diagrams by Phase

FIGURE 6.5 Outline of stakeholders’ requirements document.

The designs of the life-cycle systems needed to obtain an operational system are not that straightforward. Requirements in one phase of the life cycle will often have a major impact on the design of a system in another phase. For example, a requirement that the manufacturing system be operational by a speciﬁed date precludes many interesting designs of the operational system. This interaction of requirements and design options across life-cycle phases is a major contributing factor to failure in the real world; in addition, this interaction makes the concept of formulating the design problem as an optimization problem nonsensical to practitioners. Rather, the segregation of requirements by life-cycle phase is meant to aid in attaining the desired attributes (e.g., complete, consistent) of requirements discussed in Table 6.3 of the next section. Given the organization of the StkhldrsRD shown in Figure 6.5, an overall tradeoff requirement (Section 3.8 of the StkhldrsRD) that addresses

6.9

WRITING REQUIREMENTS

171

comparisons across life-cycle phases is needed to enable coherent evaluations of design options.

6.8

CHARACTERISTICS OF SOUND REQUIREMENTS

A number of authors [Frantz, 1993; Davis, 1993; Mar, 1994] have developed various numbers of attributes for requirements. The literature is not in total agreement about the meaning of these attributes. Table 6.3 is the result of a detailed examination of the literature. The characteristics are divided into those that are related to individual requirements and those relevant to groups of requirements. In any systems engineering effort, as many correct requirements must be developed as possible; these correct requirements should be veriﬁable. In addition, as many incorrect requirements should he eliminated as possible. In summary, the requirements document should contain a complete, consistent, comparable, design independent, modiﬁable, and attainable statement of the design problem.

6.9

WRITING REQUIREMENTS

Certain procedures have been developed [Grady, 1993; Hooks, 1994] for writing requirements. These procedures guide requirements writers toward the achievement of the above attributes. First, a set of terms has been developed. Speciﬁcally, a statement of a requirement includes the use of the word ‘‘shall’’ to indicate the limiting nature of a requirement; statements of fact use ‘‘will’’; and goals use ‘‘should.’’ The requirements statement shall include a subject (the relevant life-cycle system), the word ‘‘shall,’’ a relation statement (e.g., less than or equal to), and the minimum acceptable threshold with units. Data clarifying the terms in the requirement can also be added. Examples of appropriate grammar are: The system shall provide the customer a receipt at the end of each transaction. The receipt shall contain Bank Name, Account Number, Date and Time of Day, Type of Transaction, Account Balance at the end of the Transaction, and Automatic Teller Location Code Number. The system shall stop the ﬂow of liquid hydrogen in 0.5 seconds or less. The liquid stopping time is measured from the time the control signal for stopping is received until the ﬂow through reaches zero.

It is important to avoid compound predicates and negative predicates: The system shall ﬁt y, weigh y, cost y (this causes traceability problems). The system shall not y (attempt to turn this into a positive statement of what the system shall do).

172

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

TABLE 6.3 Attributes of Requirements Individual Requirement Attributes 1) unambiguous every requirement has only one interpretation 2) understandable the interpretation of each requirement is clear to those selected to review the requirement 3) correct the requirement states something required of the system, as judged by the stakeholders 4) concise no unnecessary information is included in the requirement 5) traced each stakeholders’ requirement is traced to some document or statement of the stakeholders 6) traceable each derived requirement must be traceable to a higher level requirement via some unique name or number 7) design independent each requirement does not specify a particular solution or a portion of a particular solution 8) veriﬁable a ﬁnite, cost effective process can be deﬁned to check that the requirement has been attained Attributes of the Set of Requirements 9) unique requirement(s) is(are) not overlapping or redundant with other requirements 10) complete (a) everything the system is required to do throughout the system’s life cycle is included, (b) responses to all possible (realizable) inputs throughout the system’s life cycle are deﬁned, (c) the document is deﬁned clearly and self contained, and (d) there are no ‘‘to be deﬁned’’ (TBD) or to be reviewed (TBR) statements; completeness is a desired property but cannot be proven at the time of requirements development, or perhaps ever 11) consistent (a) internal no two subsets of requirements conﬂict and (b) external no subset of requirements conﬂicts with external documents from which the requirements are traced 12) comparable the relative necessity of the requirements is included 13) modiﬁable changes to the requirements can be made easily, consistently (free of redundancy) and completely 14) attainable solutions exist within performance, cost and schedule constraints 15) organized grouped according to a hierarchical set of concepts, such as life cycle and categories.

Similarly, the ‘‘and/or’’ colloquialism is inappropriate because ‘‘and/or’’ provides the designer with a choice; be speciﬁc about whether you mean ‘‘and’’ or ‘‘or.’’ The requirement should not start with an ‘‘If y’’statement. Conditions under which the requirement is true should be placed at the end of the requirement. Ambiguous terms are a plague on requirements. Common verbs that are not speciﬁc enough include ‘‘maximize’’ and ‘‘minimize’’ because the system is

6.10

OPERATIONAL CONCEPT

173

seldom operating in an environment in which optimization is possible. ‘‘Accommodate’’ is another example of a vague verb. Adjectives are a major source of ambiguity; examples include ‘‘adaptable,’’ ‘‘adequate,’’ ‘‘easy,’’ ‘‘ﬂexible,’’ ‘‘rapid,’’ ‘‘robust,’’ ‘‘sufﬁcient,’’ ‘‘supportable,’’ and ‘‘user-friendly.’’ Requirements should start with the system of interest, be followed by a verb phrase starting with the word ‘‘shall’’, be followed by an object that describes an input, output, etc., and end (if necessary) with conditions under which the previous was true. Examples include: The development system shall receive inputs from stakeholders. (Input requirement) The manufacturing system shall have a scrap page rate that is less than x%. The design goal is 0.7x%. (Output requirement) The deployment system shall accept boxes of x ft3 or less. The design goal is 0.5 ft3. (Input requirement) The training system shall complete training in x hours per student or less. The design goal is 0.9x hours. (Output requirement) The operational system shall have an operational life of x years or more. The design goal is 2x years. (System-wide schedule requirement) The reﬁnement system shall be compatible with the following new technologies (x, y, z) for the central processing unit. (Input requirement) The retirement system shall retire units for less than $x each. (System-wide cost requirement)

6.10

OPERATIONAL CONCEPT

An operational concept [Lano, 1990a] is a vision for what the system is (in general terms), a statement of mission requirements, and a description of how the system will be used. Hooks and Farry [2001] describes the operational concept as a ‘‘day in the life of your product.’’ This operational concept is an opportunity to create a vision that is shared among all of the stakeholders for the really major interactions of people and things with the system of interest. The shared vision is from the perspective of the system’s stakeholders, addressing how the system will be developed, produced, deployed, trained, operated and maintained, reﬁned, and retired to overcome some operational problem and achieve the stakeholders’ operational needs and objectives. The development of the operational concept serves the purpose of obtaining consensus in the written language of the stakeholders about what needs the system will satisfy and the ways in which the system will be used. Remember that there is a system for each phase of the system’s life cycle and that an operational concept is needed for each of the systems. By describing how the system will be used, the operational concept is providing substantial

174

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

(but incomplete) information about the system’s interaction with other systems and the context of the system. Figure 6.6 shows the three primary choices that were considered by the National Aeronautics and Space Administration (NASA) engineers in determining an operational concept for landing on the moon during the 1960s [Brooks et al., 1979; Murray and Cox, 1989]. The NASA engineers called these concepts modes and started out favoring the direct ascent from Earth to moon and back to Earth. However, calculations concerning the thrust required for this concept quickly proved that the concept was infeasible. As a result the second and third concepts (Earth rendezvous and lunar rendezvous) were deﬁned and explored in detail. Werner von Braun had previously developed the concept of staged rockets for lifting payloads into Earth orbit; with staged rockets the weight that is no longer relevant can be shed. The same concept applied to Earth and lunar rendezvous. Many teams conducted calculations and simulations of these two concepts over several years, focusing primarily on cost (using energy as a surrogate) and safety. The ﬁnal results estimated that the lunar orbit rendezvous concept was almost $1.5 billion cheaper and had a 6- to 8-month shorter timeline for landing on the moon. There was some controversy at the end about which was safest; many engineers felt they were about equal with respect to safety, each having different strengths and weaknesses.

Direct Ascent: Earth-Earth Orbit -Moon-Earth

Earth

Moon

Earth Orbit Rendezvous: Earth-Earth Orbit-MoonEarth Orbit-Earth

Earth

Moon

Lunar Orbit Rendezvous: Earth-Earth Orbit-Lunar OrbitMoon-Lunar Orbit-Earth

Moon

Earth

FIGURE 6.6 Alternate operational concepts for Apollo’s moon landing.

6.10

OPERATIONAL CONCEPT

175

The operational concept includes a collection of scenarios as described in a use case diagram (see Fig. 3.1). One or more scenarios are needed for each group of stakeholders in each relevant phase of the system’s life cycle. The use case diagram is used to provide a ‘‘big picture’’ of how the individual scenarios relate to each other in deﬁning how the system is to be employed. Each scenario addresses one way that a particular stakeholder(s) will want to use, deploy, and ﬁx the system; the scenario deﬁnes how the system will respond to inputs from other systems in order to produce a desired output. Included in each scenario are the relevant inputs to and outputs from the system and the other systems that are responsible for those inputs and outputs. The scenario should not describe how the system is processing inputs to produce outputs. Rather, each scenario should focus on the exchange of inputs and outputs by the system with other systems. It is critical that this shared vision be consistent with the collection of scenarios comprising the operational concept. Hunger [1995] uses the phrase ‘‘mission analysis’’ for the development of the operational concept. The collection of scenarios in the operational concept includes sortie missions (or scenarios) and life missions, both from the perspective of the stakeholders. Sortie missions are scenarios that describe how the system will be used during the operational phase, capturing the reasons the system has for existing. The life missions address the nonoperational, lifecycle aspects of the system, resulting in scenarios for each life-cycle phase and some that cross life-cycle phases. Hunger has suggested using time lines to better deﬁne these system scenarios (or sorties as he calls them). The mission requirements of the system are the key statements of the needs of the stakeholders in the context of the stakeholders and other systems with which the system interoperates. These mission requirements are stated in terms of the measures relevant to enabling the stakeholders to meet some missions important to the stakeholders. For example, a major mission requirement for the Apollo moon landing was ‘‘bringing the astronauts home alive.’’ Within the elevator case study the output requirements were divided into average wait for service and average transit time. The mission requirement would be average time from request for service until service was completed. In software engineering, Jacobson [1992, 1995] proposed the creation of use cases to capture the interactions between people (users) of the software system, as well as among other systems; users and external systems are called actors. The concept of use cases was embraced so thoroughly by many software engineers that co*ckburn [1997a,b] documents 18 different deﬁnitions of a use case. These deﬁnitions of use cases vary along four dimensions: purpose, contents, plurality, and structure. co*ckburn [1997a,b] adopts the same deﬁnition for each of the four dimensions that Jacobson put forth. The purpose of use cases is to support the development of requirements; the contents are consistent prose; the plurality is that each use case contains multiple scenarios (as deﬁned in this book for the operational concept); and the structure of the use cases is semiformal. A use case is developed around a speciﬁc goal; goal is synonymous with desired output of the system. The use case contains one main

176

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

scenario and as many variations around that scenario as are meaningful. For our elevator system, variations may relate to the types of people using the elevator system, for example, blind people, deaf people, small children, people in wheelchairs. So far a collection of use cases is very consistent with a collection of scenarios as deﬁned for the operational concept. However, a number of authors [Jacobson, 1995; Eriksson and Penker, 1998] illustrate the use case with statements of functions that the system and actors are performing, rather than the ﬂow of information and physical entities between the system and the actors. As stressed so far in this chapter, the focus during the development should be on deﬁning requirements related to inputs and outputs of the system and not on the functions of the system and functional requirements. There is quite a bit of confusion and sloppiness in discussions of use cases on this issue; several of the authors [co*ckburn, 1997a,b; Eriksson and Penker, 1998] are really clear that the system should be treated as a black box with no visibility into functions, yet the functions show up in the discussion and diagrams documenting the use cases [see Jacobson, 1995; Eriksson and Penker, 1998]. The emphasis in this book has been on deﬁning all aspects of the life-cycle system. Consistent with Hunger’s [1995] concept for sortie and life missions, the engineers for a system should develop scenarios for the system of interest in every phase of the life cycle. There should be scenarios and mission requirements for the development, manufacturing, training, deployment, reﬁnement, and retirement phases unless one or more of these phases is not relevant. To generate these scenarios, start with the key stakeholder, the operator/ user, and generate a number of simple scenarios. Then scenario generation is expanded to other stakeholders while staying simple. Finally, complexity is added to all scenarios for each stakeholder, explicitly addressing atypical weather situations, failure modes of external systems that are relevant, and identifying key failure modes, constraints, standards, and external system interfaces that the system should address in every phase of the life cycle. In all scenarios the focus should be on what the stakeholders and external systems do and not on how the systems accomplish their tasks. The system of interest should be viewed as a black box; that is, the system’s internals are blacked out, leaving only the inputs and outputs to the system. Table 6.4 shows sample operational concept scenarios for an elevator. There are some common operating scenarios for nearly every system: Initialization of the system Normal steady state operation in standard operating modes of the system for all possible contexts (environments) in which the system may be placed (e.g., extreme cold, outer space) . Extremes of operations due to high and low peaks of the external systems in each standard operating mode in each context . Standard maintenance modes of the system . .

6.10

OPERATIONAL CONCEPT

177

TABLE 6.4 Sample Operational Concept Scenarios for an Elevator 1) Passengers (including mobility, visually and hearing challenged) request up service, receive feedback that their request was accepted, receive input that the elevator car is approaching and then that an entry opportunity is available, enter elevator car, request ﬂoor, receive feedback that their request was accepted, receive feedback that door is closing, receive feedback about what ﬂoor at which elevator is stopping, receive feedback that an exit opportunity is available, and exit elevator with no physical impediments. 2) Passengers are receiving transportation in the elevator system when a ﬁre breaks out in the building; building alarm system sends signal to elevator system to stop elevator cars at the nearest ﬂoor, provide exit opportunity, and sound a ﬁre alarm. Passengers leave elevator cars. Elevator cars are reactivated by special access available to maintenance personnel after the building is re opened. 3) Passengers are entering (exiting) an elevator car when doors start to shut; passengers can stop doors from shutting and continue to enter (exit). 4) Elevator car stops functioning. Passengers in the elevator car push an emergency alarm that notiﬁes building personnel to come and help them. Passengers use a phone system in the elevator car to call a centralized service center and report the problem to the people that answer. Elevator maintenance personnel arrive and create an exit opportunity. 5) Too many passengers enter an elevator car and the weight of passengers in the elevator car exceeds a preset safety limit; the elevator car signals a capacity problem and provides prolonged exit opportunity until some passengers exit the car. 6) Maintain a comfortable environment in the elevator by sensing the temperature in the elevator car that is based upon heat loss/gain of the passengers and the building and then supplying the necessary heat loss/gain to keep the passengers comfortable. 7) A maintenance person needs to repair an individual car; the maintenance person places the elevator system in ‘‘partial maintenance’’ mode so that the other cars can continue to pick up passengers while the car(s) in question is (are) being diagnosed, repaired, and tested. After completion the maintenance person places the elevator system in ‘‘full operation’’ mode. 8) Electric power is transferred to the elevator from the building.

. . . . .

Standard resupply modes of the system Reaction to failure modes of other systems Failure modes due to internal problems, providing as much graceful degradation of the meta-system as possible Shutdown of the system Termination (phase out) of the system

The total number of scenarios for a common (relatively simple) system would be 25 to 50. The SysML modeling technique called a sequence diagram (formerly called an input/output trace in the ﬁrst edition of this book) can be used to make

178

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

Passenger (including mobility, visually & hearing challenged)

Elevator Up Service Request

Feedback that request was received Feedback that car is on the way Feedback that door is opening Entry Opportunity Floor Request Feedback that request was received Feedback that door is closing Feedback about floor where stopped Feedback that door is opening Exit Opportunity

FIGURE 6.7 Sequence diagram of first elevator scenario.

the description of each scenario as explicit as possible. A sequence diagram (see Fig. 6.7) has a time line associated with each major actor (our system and other systems) in the scenario. The systems involved are listed across the top of the diagram with the time lines running vertically down the page under each of the systems. Time moves from top to bottom in an input/output trace; the system of concern is highlighted with a bold label and heavier line. Interactions involving the movement of data, horizontal arcs from the originating system to the receiving system, designate energy or matter among systems. A label is shown just above each arc to describe the data or item being conveyed. Doubleheaded arcs are permissible to represent dialog in a compact manner. Having two or more arcs in quick succession is also common to illustrate that the same item is being transmitted from one system to multiple systems or multiple systems are potentially transmitting the same item to one system. Figure 6.7 shows the ﬁrst of these scenarios documented as an input/output trace diagram. See the elevator case study on the author’s web site for more examples. The purpose of these sequence diagrams is to be more explicit than written text can be about the systems involved with a speciﬁc focus on the time-based interaction of systems and the transmission of data and items. Compare the sequence diagram in Figure 6.7 to the ﬁrst scenario in Table 6.4. These sequence diagrams are not meant to be exact representations of dynamic interaction. An interval time scale is not being represented; rather time is ordinal — any arc that

6.11

EXTERNAL SYSTEMS DIAGRAM

179

is above another happens earlier, but there is no indication as to how large the time interval is. The shared vision, mission requirements, and the use case diagram with sequence diagrams for the scenarios deﬁne the system’s mission and provide the ﬁrst hints as to the boundary of the system. The external systems are deﬁned in the scenarios, also deﬁning the inputs and outputs of the system. The system’s inputs and outputs cross this boundary, deﬁning the input/output requirements of the system and the external interfaces. The mission requirements suggest the fundamental objectives (objectives hierarchy of the stakeholders). This objectives hierarchy becomes the basis of the system’s performance requirements. Finally, the ﬁrst-level decomposition of the system’s function can be suggested by examining the operational concept. Thus the operational concept also leads to the functional requirements. Recall that multiple systems are being developed concurrently, one for each phase of the life cycle and a qualiﬁcation system for each of those systems. Each of these systems should have an operational concept. The American Institute of Aeronautics and Astronautics (AIAA) and the Institute of Electrical and Electronics Engineers (IEEE) have standards documents for the Concept of Operations and Operational Concept for the interested reader.

6.11

EXTERNAL SYSTEMS DIAGRAM

The single, largest issue in deﬁning a new system is where to draw the system’s boundaries; see Figure 6.2. Everything within the boundaries of the system is open to change and subject to the requirements, and nothing outside of the boundaries can be changed, leading to many of the system’s constraint requirements. The external systems’ diagram is the model of the interaction of the system with other (external) systems in the relevant contexts, thus providing a deﬁnition of the system’s boundary in terms of the system’s inputs and outputs. Who is responsible for drawing these boundaries? All of the stakeholders have a say in drawing these boundaries. However, there are substantial cost and schedule implications so the procurer of the system typically has a major input. Nonetheless, all of the stakeholders should be prepared to discuss the impact upon them of various boundary-drawing options. The systems engineer is responsible for guiding this boundary-drawing process to a conclusion that the stakeholders understand and accept. The systems engineer uses these boundaries to establish and maintain control of the system’s interfaces. The system’s boundaries need to be drawn early in the systems engineering process because so much else in the design phase is dependent upon them. As is discussed next, the fundamental objectives or measures of effectiveness of the system need to be focused just beyond the external interfaces of the system. The operational concept relies upon knowing where the boundaries are for each

180

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

stakeholder. The interface requirements capture the implications of the boundaries on the system design. Many graphical modeling techniques (e.g., IDEF0, N2 charts, data ﬂow diagrams, EFFBDs) can be used to deﬁne the system boundary; see Davis, [1990]. See Chapter 12 for a discussion of these techniques. IDEF0 is used in this chapter to illustrate external systems diagrams in terms of the elevator. The boundary for the elevator is deﬁned so as to exclude the passenger, the maintenance personnel, and the building. First, the purpose and viewpoint are deﬁned: Purpose: Explicitly deﬁne the system’s boundary and needed interfaces Viewpoint: Systems Engineering Team Next the mechanisms or external systems are established, followed by the functions of these systems. The system and external system come directly from the input/output traces of the scenarios in the operational concept:

Mechanism (System/External System)

System Function

1. 2. 3. 4.

Provide elevator services Request and use elevator services Maintain elevator operations Provide structural support

Elevator — the system Passengers Maintenance personnel Building

Now the inputs, controls, and outputs of these functions are developed to ﬁnish the external system diagram. Recall that as part of this analysis of the elevator boundaries the focus is on the context or environment of the elevator, and these key variables are shown in the diagram as controls. See Figure 6.8. The above discussion has focused on an external systems diagram for the operational phase of the system, in which the system is interacting with the system’s users and other systems. External systems diagrams can and should be developed for every phase of the system’s life cycle. In addition to the usual syntax and semantics requirements of IDEF0 diagrams, an external systems diagram introduces several new constraints for the diagram to be valid. First, all of the outputs of the system’s function (the elevator in this case) have to go to at least one of the external systems’ functions on the page and cannot exit the diagram. If the output did exit the page, there would be an external system that was not included in the diagram, invalidating the purpose of the effort. Similarly, each of the external systems must receive at least one output of our system; otherwise, the system should be part of the context. In some cases part of the context could be shown on the external systems diagram to emphasize the importance of a particular input to the system.

181

NODE:

A-1

Passengers Needing Elevator Services

Repair Parts

Passengers in Elevator System

Emergency Support

Elevator System

A-0

Provide Elevator Services

Request for Floor & Exit Support

Request for Emergency Support & Emergency Message

Passenger Characteristics

A-12

Passenger Environment

Request for Elevator Service & Entry support

DATE: 05/24/99 REV:

NUMBER:

Building

A-14

Provide Structural Support

Emergency Communication

P. 1

Electric Power & Emergency Communication Response

Emergency Messages

None

DATE CONTEXT:

Building Regulations

ModifiedElevator Configuration& Expected Usage Patterns

Maintenance Personnel

Service, Tests & Repairs

A-13

Maintain Elevator Operations

Diagnostic & Status Messages

Structural Support, Alarm Signals & Building Environment

WORKING READER DRAFT RECOMMENDED PUBLICATION Maintenance Quality Standards

Acknowledgment that Request Was Recieved & Status Information

FIGURE 6.8 External systems’ diagram for operational use of an elevator.

TITLE: External Systems Diagram for Operational Phase

Passengers

Elevator Entry/Exit Opportunity

Elevator Exit Opportunity

A-11

Use Elevator Services

Passengers' Needs

NOTES: 1 2 3 4 5 6 7 8 9 10

AUTHOR: Dennis Buede PROJECT: Elevator Case Study

Request Elevator Services

Elevator Entry Opportunity

George Mason Univ.

USED AT:

182

6.12

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

OBJECTIVES HIERARCHY FOR PERFORMANCE REQUIREMENTS

Traditionally, systems engineers have used the terms measure of effectiveness (MOE) and measure of performance (MOP), some times called a ﬁgure of merit (FOM). A measure of effectiveness describes how well a system carries out a task or set of tasks within a speciﬁc context; an MOE is measured outside the system for a deﬁned environment and state of the context variables and is used to deﬁne mission requirements. Note that the further outside the system that the MOE measurement process is established, the more inﬂuence the external systems have on the measurement, yielding less sensitivity in the measurement process for evaluating the effectiveness of the system. The MOE or MOEs that were used to deﬁne the mission requirements can be divided into additional MOEs for a given system, often one for each major output of the system. An MOP (or FOM) describes a speciﬁc system property or attribute for a given environment and context; an MOP is measured within the system. There are many possible and relevant MOPs for a speciﬁc system output; examples include accuracy, timeliness, distance, throughput, workload, and time to complete. Usually only a few of these MOPs matter for each output. The MOPs form the basis of stakeholders’ requirements when they address outputs. The MOPs that address the performance of system components [e.g., chip speed of the central processing unit (CPU)] are completely inappropriate for use as requirements because they address how to achieve the stakeholders’ needs, not how well to meet these needs. Since the systems engineering design process is decision rich, introducing some concepts from decision analysis is important. Value-focused thinking [Keeney, 1992] emphasizes the proper structuring of decisions in terms of a fundamental objective. The fundamental objective is the aggregation of the essential set of objectives that summarizes the current decision context and is yet relevant to the evaluation of the options under consideration. Generally, this fundamental objective can be subdivided into value objectives that more meaningfully deﬁne the fundamental objective, thereby forming a fundamental objectives hierarchy or value structure. Keeney [1992] distinguishes this hierarchy from a means–ends objectives network, which relates means or ‘‘how to’’ variables (the design options and context) to the fundamental objective. The objectives hierarchy of a system is the hierarchy of objectives that are important to the system’s stakeholders in a value sense; that is, the stakeholders would (should) be willing to pay to obtain increased performance (or decreased cost) in any one of these objectives. Means objectives should not be part of this objectives hierarchy. These means objectives describe physical ways to achieve improvements in the fundamental objectives. Means objectives often contain the variables used in simulation models to estimate the system’s performance on the fundamental objectives. If there is some scientiﬁc relationship among a set of variables in the objectives hierarchy, then these objectives are very likely (but not deﬁnitely) means objectives and should be removed. Carrying the decomposition of the fundamental objectives too far is a mistake.

6.12

OBJECTIVES HIERARCHY FOR PERFORMANCE REQUIREMENTS

183

The process that Keeney [1992] describes for deﬁning this situation-based fundamental objectives hierarchy is consistent with INCOSE Pragmatic Principle 2 (as shown in italics) and involves working from both ends, by generalizing means–ends objectives and operationalizing strategic objectives. Means–ends objectives are ways to achieve the fundamental objective. Strategic objectives are beyond the time horizon and immediate control of options associated with the current system design decision situation. As an example, one of the set of fundamental objectives for the operation of a new elevator (see Fig. 6.9) would be ‘‘minimize passenger time in the system.’’ The set of fundamental objectives deﬁne value trade offs among the stakeholders of the elevator system. A strategic objective would be to ‘‘improve the working environment in the building’’; there are too many other factors beyond the elevator that will determine whether this objective is met for the objective to be a fundamental objective. A means–ends objective would be to ‘‘use a fuzzy logic controller’’; this statement addresses a means for achieving an objective. Next, the fundamental objectives hierarchy is developed by deﬁning the natural subsets of the fundamental objective. Keeney gives the following example of a fundamental objectives hierarchy: maximize safety (the fundamental objective) is disaggregated into minimize loss of life, minimize serious injuries, and minimize minor injuries. The trade offs among these objectives clearly entail one’s values, and only one’s values. This subdivision is contrasted with a means–ends breakout of maximize safety that starts with minimize accidents and maximize the use of safety features on vehicles, both of which are means oriented and involve outcomes for which value trade offs are difﬁcult. Figure 6.9 provides the fundamental objectives hierarchy for the operation of the elevator. Pragmatic Principle 2 [DeFoe, 1993] Use Effectiveness Criteria Based on Needs to Make System Decisions 1. Select criteria that have demonstrable links to customer/consumer needs and system requirements. a. Operational criteria: mission success, technical performance b. Program criteria: cost, schedule, quality, risk c. Integrated logistics support (ILS) criteria: failure rate, maintainability, serviceability 2. Maintain a ‘‘need-based’’ balance among the often-conﬂicting criteria. 3. Select criteria that are measurable (objective and quantiﬁable) and express them in well-known, easily understood units. However, important criteria for which no measure seems to exist still must be explicitly addressed. 4. Use trade offs to show the customer the performance, cost, schedule, and risk impacts of requirements and solutions variations.

184

REQUIREMENTS AND DEFINING THE DESIGN PROBLEM

Operational Objectives

Monthly Operating Costs $1,500 - $1,000, Wt = 0.1

Operational Performance Objectives, Wt = 0.9

Time in System Objectives, Wt = 0.35

Average Wait (Routine) 35 - 27 sec, Wt = 0.3 Average Wait (Priority) 35 - 30 sec, Wt = 0.35 Average Transit Time 90 - 60 sec, Wt = 0.35 Ride Quality Objectives, Wt = 0.30

Max'm Acceleration 1.5 - 1.25 m/s2, Wt = 0.3 Max'm Accel'n Change 2 - 1.5 m/s3, Wt = 0.5 Floor Leveling Error 0.7 - 0.3 cm., Wt = 0.2 Availability Objectives, Wt = 0.35

Operational MTBF 1 - 1.5 yrs, Wt = 0.5 Operational MTTR 8 - 4 hrs, Wt = 0.5

FIGURE 6.9 Fundamental objectives hierarchy for operational phase of elevator.

5. Whenever possible, use simulation and experimental design to perform trade offs as methods that rely heavily on ‘‘engineering judgment’’ rating scales are more subject to bias and error. 6. Have the customer make all value judgments in trade offs.

6.12

OBJECTIVES HIERARCHY FOR PERFORMANCE REQUIREMENTS

185

7. Allow the customer to modify requirements and participate in developing the solution based on the trade offs. The objectives hierarchy (a directed tree) usually has two to ﬁve levels. The objectives in the hierarchy may include stakeholders explicitly and often include context (environmental) variables (e.g., weather conditions, peak versus nonpeak loading) from the scenarios in the operational concept. If present, these scenarios are usually at the top of the hierarchy, shown as varying conditions for deﬁning the objectives. To make use of the objectives hierarchy for trade studies, additional information must be added; value curves must be added for each objective at the bottom of the objectives hierarchy and value weights for comparing the relative value of swinging from the bottom of each value scale to top. Figure 6.9 shows the thresholds and design goals for each objective; each threshold and design goal deﬁnes a ‘‘swing’’ in performance that is used to establish the ‘‘swing’’ weights in the value model (see Chapter 13). Figure 6.10 illustrates the value curves for a simpliﬁed objectives hierarchy for an elevator system. See Sailor [1990] for another example. As mentioned above, decision analysis uses value curves and weights to support trade-off decisions. These value curves and weights need to be obtained from the stakeholders for two important reasons. First, the objectives typically span several groups of stakeholders, necessitating an agreement among these groups of stakeholders about the relative importance of one objective with others. Second, this objectives hierarchy and its associated value curves and weights represent the value structure needed by the systems engineering team to make many trade-off decisions during the design process. The values are those of the stakeholders, not the systems engineers. Far too often the systems engineers must guess at the stakeholders’ values during design decisions