Systems Engineering Principles and Practice (Wiley Series in Systems Engineering and Management) [3 ed.] 1119516668, 9781119516668

Citation preview

SYSTEMS ENGINEERING PRINCIPLES AND PRACTICE

WILEY SERIES IN SYSTEMS ENGINEERING AND MANAGEMENT William Rouse, Series Editor Andrew P. Sage, Founding Editor A complete list of the titles in this series appears at the end of this volume.

SYSTEMS ENGINEERING PRINCIPLES AND PRACTICE THIRD EDITION

Alexander Kossiakoff† Samuel J. Seymour David A. Flanigan Steven M. Biemer

This third edition first published 2020 © 2020 John Wiley & Sons, Inc. Edition History John Wiley & Sons, Inc. (1e, 2003) John Wiley & Sons, Inc. (2e, 2011) All rights reserved. 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 or otherwise, except as permitted by law. Advice on how to obtain permission to reuse material from this title is available at http://www.wiley.com/go/permissions. The right of Alexander Kossiakoff, Samuel J. Seymour, David A. Flanigan, and Steven M. Biemer to be identified as the authors of this work has been asserted in accordance with law. Registered Office John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, USA Editorial Office 111 River Street, Hoboken, NJ 07030, USA For details of our global editorial offices, customer services, and more information about Wiley products visit us at www. wiley.com. Wiley also publishes its books in a variety of electronic formats and by print-on-demand. Some content that appears in standard print versions of this book may not be available in other formats. Limit of Liability/Disclaimer of Warranty While the publisher and authors have used their best efforts in preparing this work, they make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives, written sales materials or promotional statements for this work. The fact that an organization, website, or product is referred to in this work as a citation and/or potential source of further information does not mean that the publisher and authors endorse the information or services the organization, website, or product may provide or recommendations it may make. This work is sold with the understanding that the publisher is not engaged in rendering professional services. The advice and strategies contained herein may not be suitable for your situation. You should consult with a specialist where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages. Library of Congress Cataloging-in-Publication Data Names: Kossiakoff, Alexander, 1914–2005, author. | Biemer, Steven M., author. | Seymour, Samuel J., author. | Flanigan, David A., author. Title: Systems engineering : principles and practice / Alexander Kossiakoff, Steven M. Biemer, Samuel J. Seymour, David A. Flanigan. Description: Third edition. | Hoboken, NJ : John Wiley & Sons, Inc., 2020. | Series: Wiley series in systems engineering and management | Revised edition of: Systems engineering : principles and practice / Alexander Kossiakoff ... [et al.]. 2011. | Includes bibliographical references. Identifiers: LCCN 2020002852 (print) | LCCN 2020002853 (ebook) | ISBN 9781119516668 (hardback) | ISBN 9781119516675 (adobe pdf) | ISBN 9781119516705 (epub) Subjects: LCSH: Systems engineering. Classification: LCC TA168 .K68 2020 (print) | LCC TA168 (ebook) | DDC 620.001/171–dc23 LC record available at https://lccn.loc.gov/2020002852 LC ebook record available at https://lccn.loc.gov/2020002853

Cover Design: Wiley Cover Images: Blue geometric lines © Westend61/Getty Images, chart © John Wiley & Sons, Inc. Set in 10/12pt Times by SPi Global, Pondicherry, India Printed in the United States of America

10 9 8 7 6 5 4 3 2 1

To Alexander Kossiakoff who never took “no” for an answer and refused to believe that anything was impossible. He was an extraordinary problem solver, instructor, mentor, and friend. Samuel J. Seymour David A. Flanigan Steven M. Biemer

CONTENTS

LIST OF ILLUSTRATIONS

XV

LIST OF TABLES

XIX

PREFACE TO THE THIRD EDITION

XXI

PREFACE TO THE SECOND EDITION

XXV

PREFACE TO THE FIRST EDITION

XXIX

PART I

FOUNDATIONS OF SYSTEMS ENGINEERING

1 SYSTEMS ENGINEERING AND THE WORLD OF MODERN SYSTEMS 1.1 What is Systems Engineering? 1.2 The Systems Engineering Landscape 1.3 Systems Engineering Viewpoint 1.4 Perspectives of Systems Engineering 1.5 Examples of Systems Requiring Systems Engineering 1.6 Systems Engineering Activities and Products 1.7 Systems Engineering as a Profession 1.8 Systems Engineer Career Development Model 1.9 Summary Problems References Further Reading

2 STRUCTURE OF COMPLEX SYSTEMS 2.1 2.2

System Elements and Interfaces Hierarchy of Complex Systems

1 3 3 5 9 12 16 20 20 24 27 29 30 30 33 33 34 vii

viiiContents

2.3 System Building Blocks 2.4 The System Environment 2.5 Interfaces and Interactions 2.6 Complexity in Modern Systems 2.7 Summary Problems Reference Further Reading

3 THE SYSTEM DEVELOPMENT PROCESS 3.1 Systems Engineering Through the System Life Cycle 3.2 System Life Cycle 3.3 Evolutionary Characteristics of the Development Process 3.4 The Systems Engineering Method 3.5 Testing Throughout System Development 3.6 Summary Problems Reference Further Reading

4 SYSTEMS ENGINEERING MANAGEMENT 4.1 Managing System Development 4.2 Work Breakdown Structure 4.3 Systems Engineering Management Plan 4.4 Organization of Systems Engineering 4.5 Summary Problems Further Reading PART II

CONCEPT DEVELOPMENT STAGE

5 NEEDS ANALYSIS 5.1 Originating a NewSystem 5.2 Systems Thinking 5.3 Operations Analysis 5.4 Feasibility Definition 5.5 Needs Validation 5.6 Summary Problems

38 43 51 54 57 58 59 60 61 61 62 74 81 94 96 98 99 99 101 101 103 108 111 115 116 116 119 121 121 130 132 143 145 149 150

Contents

References Further Reading

6 REQUIREMENTS ANALYSIS 6.1 Developing the System Requirements 6.2 Requirements Development and Sources 6.3 Requirements Features and Attributes 6.4 Requirements Development Process 6.5 Requirements Hierarchy 6.6 Requirements Metrics 6.7 Requirements Verification and Validation 6.8 Requirements Development: TSE vs. Agile 6.9 Summary Problems Further Reading

7 FUNCTIONAL ANALYSIS 7.1 Selecting the System Concept 7.2 Functional Analysis and Formulation 7.3 Functional Allocation 7.4 Functional Analysis Products 7.5 Traceability to Requirements 7.6 Concept Development Space 7.7 Summary Problems Further Reading

8 EVALUATION AND SELECTION 8.1 Evaluating and Selecting the System Concept 8.2 Alternatives Analysis 8.3 Operations Research Techniques 8.4 Economics and Affordability 8.5 Events and Decisions for Consideration 8.6 Alternative Concept Development and Concept Selection 8.7 Concept Validation 8.8 Traditional vs. Agile SE Approach to Concept Evaluation 8.9 Summary Problems References Further Reading

ix

151 151 153 153 157 160 163 167 175 177 179 179 181 181 183 183 188 194 197 202 204 206 207 208 209 209 210 214 218 222 224 229 230 231 233 234 234

xContents

9 SYSTEMS ARCHITECTING

10

11

12

9.1 Architecture Introduction 9.2 Types of Architecture 9.3 Architecture Frameworks 9.4 Architectural Views 9.5 Architecture Development 9.6 Architecture Traceability 9.7 Architecture Validation 9.8 Summary Problems Further Reading

235 235 236 241 244 246 247 248 249 251 251

MODEL‐BASED SYSTEMS ENGINEERING (MBSE) 10.1 MBSE Introduction 10.2 MBSE Languages 10.3 MBSE Tools 10.4 MBSE Used in the SE Life Cycle 10.5 Examples 10.6 Summary Problems References Further Reading

253 253 259 260 262 263 267 272 273 273

DECISION ANALYSIS AND SUPPORT 11.1 Decision Making 11.2 Modeling Throughout System Development 11.3 Modeling for Decisions 11.4 Simulation 11.5 Trade‐Off Analysis 11.6 Evaluation Methods 11.7 Summary Problems References Further Reading

275 276 282 282 287 296 313 321 324 324 325

RISK MANAGEMENT 12.1 Risk Management in the SE Life Cycle 12.2 Risk Management

327 327 328

xi

Contents

12.3 Risk Traceability/Allocation 12.4 Risk Analysis Techniques 12.5 Summary Problems Reference Further Reading PART III

13

14

15

ENGINEERING DEVELOPMENT PHASE

337 338 345 346 346 347 349

ADVANCED DEVELOPMENT 13.1 Reducing Uncertainties 13.2 Requirements Analysis 13.3 Functional Analysis and Design 13.4 Prototype Development as a Risk Mitigation Technique 13.5 Development Testing 13.6 Risk Reduction 13.7 Summary Problems References Further Reading

351 351 356 361 367 376 385 387 388 390 391

SOFTWARE SYSTEMS ENGINEERING 14.1 Components of Software 14.2 Coping with Complexity and Abstraction 14.3 Nature of Software Development 14.4 Software Development Life Cycle Models 14.5 Software Concept Development: Analysis and Design 14.6 Software Engineering Development: Coding and Unit Test 14.7 Software Integration and Test 14.8 Software Engineering Management 14.9 Summary Problems References Further Reading

393 394 394 398 403 412 424 432 435 442 445 446 446

ENGINEERING DESIGN 15.1 Implementing the System Building Blocks 15.2 Requirements Analysis

449 449 454

xiiContents

16

17

15.3 Functional Analysis and Design 15.4 Component Design 15.5 Design Validation 15.6 Configuration Management 15.7 Summary Problems Further Reading

456 460 473 478 481 483 483

SYSTEMS INTEGRATION 16.1 Integrating the Total System 16.2 System Integration Hierarchy 16.3 Types of Integration 16.4 Integration Planning 16.5 Integration Facilities 16.6 Summary Problems References Further Reading

485 485 488 492 494 494 496 497 498 498

TEST AND EVALUATION 17.1 Testing and Evaluating the Total System 17.2 Developmental System Testing 17.3 Operational Test and Evaluation 17.4 Human Factors Testing 17.5 Test Planning and Preparation 17.6 Test Traceability 17.7 System of Systems Testing 17.8 Summary Problems References Further Reading

499 499 509 515 523 524 529 529 530 533 534 534

PART IV

18

POST‐DEVELOPMENT STAGE

537

PRODUCTION 539 18.1 Systems Engineering in the Factory 539 18.2 Engineering for Production 541 18.3 Transition from Development to Production 545

xiii

Contents

19

20

18.4 Production Operations 18.5 Acquiring a Production Knowledge Base 18.6 Summary Problems References Further Reading

549 554 557 559 560 560

OPERATION AND SUPPORT 19.1 Installing, Maintaining, and Upgrading the System 19.2 Installation and Test 19.3 In‐Service Support 19.4 Major System Upgrades: Modernization 19.5 Operational Factors in System Development 19.6 Summary Problems Reference Further Reading

561 561 564 569 573 577 580 581 582 582

SYSTEM OF SYSTEMS ENGINEERING 583 20.1 System of Systems Engineering 583 20.2 Differences Between SOS and TSE 584 20.3 Types of SOS 587 20.4 Attributes of SOS 590 20.5 Challenges to System of Systems Engineering 591 20.6 Summary 593 Problems 595 References 595 Further Reading 596

PART V

21

SYSTEMS DOMAINS

ENTERPRISE SYSTEMS ENGINEERING 21.1 Enterprise Systems Engineering 21.2 Definitions of Enterprise Systems Engineering 21.3 Processes and Components of Enterprise Systems Engineering 21.4 Enterprise Systems Engineering Applications to Domains 21.5 Challenges to Enterprise Systems Engineering 21.6 Summary

597 599 599 600 603 605 606 607

xivContents

22

23

Problems References Further Reading

607 608 609

SYSTEMS SECURITY ENGINEERING 22.1 Systems Security Engineering 22.2 Types of Security 22.3 Security Applications to Systems Engineering 22.4 Security Applications to Domains 22.5 Security Validation and Analysis 22.6 Summary Problems Further Reading

611 611 613 616 619 621 621 623 624

THE FUTURE OF SYSTEMS ENGINEERING 23.1 Introduction and Motivation 23.2 Areas to Apply the Systems Engineering Approach 23.3 Education for the Future Systems Engineer 23.4 Concluding Remarks 23.5 Summary Problems Further Reading

627 627 630 632 634 635 636 636

INDEX639 WILEY SERIES IN SYSTEMS ENGINEERING AND MANAGEMENT 000

LIST OF ILLUSTRATIONS

1‐1 1‐2 1‐3 1‐4 1‐5 1‐6 1‐7 1‐8 1‐9 2‐1 2‐2 2‐3 2‐4 2‐5 2‐6 3‐1 3‐2 3‐3 3‐4 3‐5 3-6 3‐7 3‐8 3‐9 4‐1 4‐2 4‐3 5‐1

The ideal missile design from the viewpoint of various specialists 11 Systems engineering principles and practice 14 Systems engineering 15 Examples of systems engineering components 16 Examples of systems engineering approaches 17 Career opportunities and growth 22 Systems engineering career elements derived from quality work experiences 25 Components of employer development of systems engineers 25 “T” model for systems engineer career development 26 Knowledge domains of systems engineer and design specialist 37 Context diagram 45 Context diagram for an automobile 47 Environments of a passenger airliner 49 Functional interactions and physical interfaces 52 Pyramid of system hierarchy 55 DoD system life cycle model 63 System life cycle model 65 Principal stages in system life cycle 67 Concept development phases of system life cycle 68 Engineering development phases in system life cycle 71 Principal Participants in Typical Aerospace System Development 78 Systems engineering method’s top‐level flow diagram 82 Systems engineering method flow diagram 84 Spiral model of the system life cycle 93 Systems engineering as a part of project management 102 System product WBS partial breakdown structure 105 Place of SEMP in program management plans 109 Needs analysis phase in the system life cycle 123 xv

xvi

5‐2 5‐3 5‐4 5‐5 5‐6 5‐7 6‐1 6‐2 6‐3 7‐1 7‐2 7‐3 7‐4 7‐5 7‐6 7‐7 7‐8 7‐9 7‐10 7‐11 8‐1 8‐2 8‐3 8‐4 8‐5 8‐6 8‐7 9‐1 9‐2 9‐3 9‐4 10‐1 10‐2 10‐3 10‐4 10‐5 10‐6 10‐7 10‐8 10‐9 11‐1 11‐2 11‐3

List of  Illustrations

Needs analysis phase flow diagram Objectives tree structure Example objectives tree for an automobile Triumvirate of conceptual design Hierarchy of scenarios Analysis pyramid Concept exploration phase in system life cycle Concept exploration phase flow diagram Simple requirements development process Concept definition phase in system life cycle Concept definition phase flow diagram IDEF0 functional model structure Functional block diagram of a standard coffee maker Example functional to subsystem allocation matrix Function category vs. functional media Functional block diagram development from internal view first Functional block diagram development from external view first Functional flow diagram example Coffee maker functional flow diagram Coffee maker sequence diagram Assignment problem to minimize number of machines used Decision tree example Decision path Decision tree solved Nonmonetary benefits example Scatterplot of performance and cost comparison Example context diagram of healthcare costs Glucose meter example functional architecture Glucose meter example physical architecture Glucose meter example allocated architecture DODAF Version 2.0.2 viewpoints SysML block definition diagram of NASA’s Apollo spacecraft Relation map of NASA’s Apollo spacecraft Apollo part decomposition matrix Apollo launch vehicle part properties Internal block diagram Satellite command and data-handling state machine diagram Flight computer SysML state machine SysML parametric diagram Driveline parametric diagram Basic decision process Decision process Virtual reality simulation

129 135 136 138 140 147 155 158 164 184 188 191 192 196 198 199 200 201 201 202 215 216 217 217 219 220 221 238 239 241 243 264 265 266 267 268 269 270 270 271 276 281 294

List of  Illustrations

xvii

11‐4 11‐5 11‐6 11‐7 11‐8 11‐9 11‐10 11‐11 11‐12 11‐13 11‐14 12‐1 12‐2 12‐3 12‐4 12‐5 13‐1 13‐2 13‐3 14‐1 14‐2 14‐3 14‐4 14‐5 14‐6 14‐7 14‐8 14‐9 14‐10 14‐11 14‐12 14‐13 15‐1 15‐2 15‐3 16‐1 16‐2 16‐3 16‐4 17‐1 17‐2 17‐3 17‐4a

304 305 306 308 310 311 316 317 318 319 320 329 329 331 336 342 352 355 381 395 397 397 406 407 408 410 414 415 418 419 420 423 450 451 453 486 490 492 493 500 501 506 517

Candidate utility functions Example utility function for waiting times Criteria profile Queuing alternatives Trade study utility functions Trade study analysis examples MAUT analysis example MAUT final analysis example plot Example cost‐effectiveness integration Example scatterplot of performance cost quadrants QFD House of Quality Variation of program risk and effort throughout systems development Example of a risk mitigation waterfall chart An example of a risk cube display Sample risk plan work sheet Computer failure risk cube plot Advanced development phase in system life cycle Advanced development phase flow diagram Test and evaluation process of a system element IEEE software systems engineering process Software hierarchy Notional three‐tier architecture Classical waterfall software development cycle Software incremental model Spiral model State transition diagram in concurrent development model User needs, software requirements, and specifications Software generation process Principles of modular partitioning Functional flow block diagram example Data flow diagram: library checkout Robustness diagram: library checkout Engineering design phase in system life cycle Engineering design phase in relation to integration and evaluation Engineering design phase flow diagram Integration and evaluation phase in system life cycle Subsystem configuration Top‐down integration process Bottom‐up integration process Evaluation phase in relation to engineering design System test and evaluation team System element test configuration Operation of a passenger airliner

xviii

List of  Illustrations

17‐4b Operational testing of an airliner 17‐5 Test realism vs. cost 18-1 Production phase in system life cycle 18‐2 Production phase overlap with adjacent phases 18‐3 Production operations system 19‐1 Operation and support phase in system life cycle 19‐2 System operation history 19‐3 Non‐disruptive installation via simulation 19‐4 Non‐disruptive installation via a duplicate system 20‐1 System of system requirements context 20‐2 System of systems architecture example 20‐3 Directed SoS attributes 20‐4 Acknowledged SoS attributes 20‐5 Collaborative SoS attributes 20‐6 Virtual SoS attributes 21‐1 Enterprise systems engineering context diagram 22‐1 Systems security engineering context diagram 22‐2 Systems security engineering overlay on the systems engineering process 22‐3 Systems security engineering applications

517 519 540 541 551 563 563 567 568 585 586 588 589 589 590 602 613 617 620

LIST OF TABLES

1‐1 1‐2 1‐3 1‐4 2‐1 2‐2 2‐3 2‐4 3‐1 3‐2 3‐3 5‐1 6‐1 7‐1 7‐2 7-3 8‐1 9-1 11.1 11‐2 11‐3 11‐4 11‐5 11‐6 11‐7 12‐1 12‐2 12‐3

Comparison of Systems Perspectives Examples of Engineered Complex Systems: Signal and Data Systems Examples of Engineered Complex Systems: Material and Energy Systems Systems Engineering Activities and Documents System design hierarchy System Functional Elements Component Design Elements Examples of Interface Elements Evolution of System Materialization Through System Life Cycle Evolution of System Representation Systems Engineering Method over Life Cycle Status of System Materialization at Needs Analysis Phase Status of System Materialization of Concept Exploration Phase Status of System Materialization of Concept Definition Phase Functional to Requirements Allocation Example Coffee Maker Morphological Box System Decision Questions Glucose Meter Example Allocated Architecture List Decision framework Weighted Sum Integration of Selection Criteria Technical Criteria Pair‐Wise Comparison Technical Criteria Pair‐Wise Reasoning Trade Study Conversion of Raw Data to Utility Scores Trade Study Final Scoring Trade Study Sensitivity Analysis Risk Likelihood Risk Criticality Patient Processing Quantification Based on Functions and Components

13 18 19 20 35 40 41 53 76 80 92 125 156 186 203 205 222 240 279 303 309 309 310 311 312 333 333 340 xix

xx

List of Tables

12‐4 Patient Processing Quantification Based on Functions and Components (Degraded) 341 12‐5 Patient Processing Mitigation Example (Before Mitigation) 343 12‐6 Patient Processing Mitigation Example (After Mitigation) 344 13‐1 Status of System Materialization at Advanced Development Phase 354 13‐2 Development of New Components 360 13‐3 Selected Critical Characteristics of System Functional Elements 363 13‐4 Some Examples of Special Materials 369 14‐1 Software Types 399 14‐2 Categories of Software‐Dominated Systems 400 14‐3 Differences Between Hardware and Software 402 14‐4 Systems Engineering Life Cycle and the Waterfall Model 406 14‐5 Commonly Used Computer Languages 426 14‐6 Some Special‐Purpose Computer Languages 427 14‐7 Characteristics of Prototypes 429 14‐8 Comparison of Computer Interface Modes 430 14‐9 Capability Levels 438 14‐10 Maturity Levels 439 15‐1 Status of System Materialization at Engineering Design Phase 452 15‐2 Configuration Baselines 479 17‐1 Status of System Materialization at Integration and Evaluation Phase 503 17‐2 Systems Integration and Evaluation Process 504 17‐3 Parallels Between System Development and T&E Planning 525 20‐1 Traditional Systems Engineering vs. Systems of Systems Engineering 588 20‐2 System of Systems Engineering Examples 591 21‐1 Traditional Systems Engineering vs. Enterprise Systems Engineering 602 22-1 SSE Interfaces with SE Team 622

PREFACE TO THE THIRD EDITION

It is an incredible honor and privilege to again dedicate this edition to one of the authors of the first edition, the late Alexander Kossiakoff, whose vision and principles remain as driving forces in the field of systems engineering. The field continues to mature and make significant advances and this edition is intended to prepare successful systems engineers for the decades to come. Systems Engineering Principles and Practice is designed to help students and developers learn the best approaches to develop and deploy complex systems. The advocacy of the systems engineering viewpoint and goal for the practitioners to think like a systems engineer are still the major premises of this book. Learning how to be a successful systems engineer is entirely different from learning how to excel at a traditional engineering discipline. It requires developing the ability to think in a special way and to make the central objective the system as a whole and the success of its mission. The systems engineer faces in three directions: the system users’ and stakeholders needs and concerns, the enterprise and project managers’ financial and schedule constraints, and the capabilities and ambitions of the specialists who have to develop, build, test, and deploy the elements of the system. This requires learning enough of the language and basic principles of each of the three constituencies to understand their requirements and negotiate balanced solutions acceptable to all. The role of interdisciplinary leadership is the key contribution and principal challenge of systems engineering, and it is absolutely indispensable to the successful development of modern complex systems. While the book describes the necessary processes that systems engineers must know and execute, it stresses the leadership, problem‐solving, and innovative skills necessary for success, as well as being systematic and disciplined. In the future, societies, industries, and governments will be seeking products, services, and systems that are more innovative and economically feasible and will meet mission effectiveness and improve the quality of life. Continuing change offered by advancing technologies offers opportunities and challenges where systems engineering will take a leadership role in integrating a wide variety of disciplines to create and xxi

xxii

PREFACE TO THE THIRD EDITION

deploy systems that have global impact. This text continues to lay the foundation for the principles and practices in the development of systems. As the systems engineering field matures and accommodates the complexity of world domains, we provide time‐tested approaches and advanced methods to be successful. Entrepreneurs and technologists, executives and managers, designers and engineers, hardware and software developers, stakeholders and users, marketing and sales – all will find the wisdom outlined here to be the path for problem solving and development success. Whether dealing with nanosystems, microsystems, large‐scale systems, mega‐systems, global systems, or enterprise systems, approaches and solutions are offered for the full cycle of product creation, management, and deployment. Examples are given in fields of transportation, communications, networks, healthcare, social, climate, natural, space, defense, manufacturing, and many others. The third edition has five parts: •

•

•

•

•

Part I. Foundations of Systems Engineering describes the origins and structure of modern systems, the current field of systems engineering, the structured development process of complex systems, and the organization of system development projects. Part II. Concept Development Stage describes the early stages of the system life cycle in which a need for a new system is demonstrated, its requirements are identified, alternative implementations are developed, and key program and technical decisions are made. Part III. Engineering Development Phase describes the later stages of the system life cycle, in which the system building blocks are engineered (to include both software and hardware subsystems) and the total system is integrated and evaluated in an operational environment. Part IV. Post‐development Stage describes the roles of systems in the production, operation, and support phases of the system life cycle and what domain knowledge of these phases a systems engineer should acquire. Part V. System Domains outlines numerous areas of challenges for system ­engineering development.

Each chapter contains a summary, homework problems, references, and bibliography. The length of the book has grown with the updates and new material reflecting the expansion of the field itself. In addition, sections have been expanded in: Risk Software Modeling Needs analysis

xxiii

PREFACE TO THE THIRD EDITION

Systems thinking System complexity System architecture Systems integration In addition, new sections and chapters have been added to include: Agile Security Systems of systems Enterprise systems engineering Model‐based systems engineering Future Domains The systems engineering program at Johns Hopkins University founded by Dr. Kossiakoff is the largest part‐time graduate program in the United States, with students enrolled from around the world in classroom, distance, and organizational partnership venues, and it continues to evolve as the field expands and teaching venues embrace new technologies, setting the standard for graduate programs in systems engineering. This is the foundational systems engineering textbook for colleges and universities worldwide. The authors of the third edition gratefully thank our families for their support. As with the prior editions, the authors gratefully acknowledge the many contributions made by the present and past faculty of the Johns Hopkins University Systems Engineering graduate program. Their sharp insight and recommendations on improvements to the second edition have been invaluable in framing this publication. A special thanks is given to Michael Vinarcik, who is the primary author of the MBSE chapter. Samuel J. Seymour David A. Flanigan Steven M. Biemer

PREFACE TO THE SECOND EDITION

It is an incredible honor and privilege to follow in the footsteps of an individual who had a profound influence on the course of history and the field of systems engineering. Since publication of the first edition of this book, the field of systems engineering has seen significant advances, including a significant increase in recognition of the discipline, as measured by the number of conferences, symposia, journals, articles, and books available on this crucial subject. Clearly, the field has reached a high level of maturity and is destined for continued growth. Unfortunately, the field has also seen some sorrowful losses, including one of the original authors, Alexander Kossiakoff, who passed away just two years after the publication of the book. His vision, innovation, excitement, and perseverance were contagious to all who worked with him, and he is missed by the community. Fortunately, his vision remains and continues to be the driving force behind this book. It is with great pride that we dedicate this second edition to the enduring legacy of Alexander Ivanovich Kossiakoff.

ALEXANDER KOSSIAKOFF, 1914–2005 Alexander Kossiakoff, known to so many as “Kossy,” gave shape and direction to the Johns Hopkins University Applied Physics Laboratory as its director from 1969 to 1980. His work helped defend our nation, enhance the capabilities of our military, pushed technology in new and exciting directions, and bring successive new generations to an understanding of the unique challenges and opportunities of systems engineering. In 1980, recognizing the need to improve the training and education of technical professionals, he started the master of science degree program at Johns Hopkins University in technical management and later expanded it to systems engineering, one of the first programs of its kind. Today, the systems engineering program he founded is the largest part‐time graduate program in the United States, with students enrolled from around the world in classroom, distance, and organizational partnership venues; it continues to evolve as the field expands and teaching venues embrace new xxv

xxvi

PREFACE TO  THE  SECOND EDITION

technologies, setting the standard for graduate programs in systems engineering. The first edition of the book is the foundational systems engineering textbook for colleges and universities worldwide.

OBJECTIVES OF THE SECOND EDITION Traditional engineering disciplines do not provide the training, education, and experience necessary to ensure the successful development of a large complex system program from inception to operational use. The advocacy of the systems engineering viewpoint and the goal for the practitioners to think like a systems engineer are still the major premises of this book. This second edition of Systems Engineering Principles and Practice continues to be intended as a graduate‐level textbook for courses introducing the field and practice of systems engineering. We continue the tradition of utilizing models to assist students in grasping abstract concepts presented in the book. The five basic models of the first edition are retained, with only minor refinements to reflect current thinking. Additionally, the emphasis on application and practice is retained throughout and focuses on students pursuing their educational careers in parallel with their professional careers. Detailed mathematics and other technical fields are not explored in depth, providing the greatest range of students who may benefit, nor are traditional engineering disciplines provided in detail, which would violate the book’s intended scope. The updates and additions to the first edition revolve around the changes occurring in the field of systems engineering since the original publication. Special attention was made in the following areas: •

•

•

•

The systems engineer’s career. An expanded discussion is presented on the career of the systems engineer. In recent years, systems engineering has been recognized by many companies and organizations as a separate field, and the position of “systems engineer” has been formalized. Therefore, we present a model of the systems engineer’s career to help guide prospective professionals. The systems engineering landscape. The only new chapter introduced in the second edition is titled by the same name and reinforces the concept of the systems engineering viewpoint. Expanded discussions of the implications of this viewpoint have been offered. System boundaries. Supplemental material has been introduced defining and expanding our discussion on the concept of the system boundary. Through the use of the book in graduate‐level education, the authors recognized an inherent misunderstanding of this concept  –  students in general have been unable to ­recognize the boundary between the system and its environment. This area has been strengthened throughout the book. System complexity. Significant research in the area of system complexity is now available and has been addressed. Concepts such as system of systems ­engineering, complex systems management, and enterprise systems engineering

PREFACE TO  THE  SECOND EDITION

•

•

•

xxvii

are introduced to the student as a hierarchy of complexity, of which systems engineering forms the foundation. Systems architecting. Since the original publication, the field of systems architecting has expanded significantly, and the tools, techniques, and practices of this field have been incorporated into the concept exploration and definition chapters. New models and frameworks for both traditional structured analysis and object‐ oriented analysis techniques are described, and examples are provided, including an expanded description of the Unified Modeling Language and the Systems Modeling Language. Finally, the extension of these new methodologies, model‐ based systems engineering, is introduced. Decision making and support. The chapter on systems engineering decision tools has been updated and expanded to introduce the systems engineering student to the variety of decisions required in this field and the modern processes, tools, and techniques that are available for use. The chapter has also been moved from the original special topics part of the book. Software systems engineering. The chapter on software systems engineering has been extensively revised to incorporate modern software engineering techniques, principles, and concepts. Descriptions of modern software development life cycle models, such as the Agile development model, have been expanded to reflect current practices. Moreover, the section on capability maturity models has been updated to reflect the current integrated model. This chapter has also been moved out of the special topics part and introduced as a full partner of advanced development and engineering design.

In addition to the topics mentioned above, the chapter summaries have been reformatted for easier understanding, and the lists of problems and references have been updated and expanded. Lastly, feedback, opinions, and recommendations from graduate students have been incorporated where the wording or presentation was awkward or unclear.

CONTENT DESCRIPTION This book continues to be used to support the core courses of the Johns Hopkins University Master of Science in Systems Engineering program and is now a primary textbook used throughout the United States and in several other countries. Many programs have transitioned to online or distance instruction; the second edition was written with distance teaching in mind and offers additional examples. The length of the book has grown, with the updates and new material reflecting the expansion of the field itself. The second edition now has four parts: •

Part I. The Foundation of Systems Engineering, consisting of Chapters 1–5, describes the origins and structure of modern systems, the current field of systems engineering, the structured development process of complex systems, and the organization of system development projects.

xxviii

•

•

•

PREFACE TO  THE  SECOND EDITION

Part II. Concept Development, consisting of Chapters 6–9, describes the early stages of the system life cycle in which a need for a new system is demonstrated, its requirements are identified, alternative implementations are developed, and key program and technical decisions are made. Part III. Engineering Development, consisting of Chapters 10–13, describes the later stages of the system life cycle, in which the system building blocks are engineered (to include both software and hardware subsystems) and the total system is integrated and evaluated in an operational environment. Part IV. Post‐development, consisting of Chapters 14 and 15, describes the roles of systems in the production, operation, and support phases of the system life cycle and what domain knowledge of these phases a systems engineer should acquire.

Each chapter contains a summary, homework problems, and bibliography.

ACKNOWLEDGMENTS The authors of the second edition gratefully acknowledge the family of Dr. Kossiakoff and Mr. William Sweet for their encouragement and support of a second edition to the original book. As with the first edition, the authors gratefully acknowledge the many contributions made by the present and past faculties of the Johns Hopkins University Systems Engineering graduate program. Their sharp insight and recommendations on improvements to the first edition have been invaluable in framing this publication. Particular thanks are due to E. A. Smyth for his insightful review of the manuscript. Finally, we are exceedingly grateful to our families – Judy Seymour and Michele and August Biemer – for their encouragement, patience, and unfailing support, even when they were continually asked to sacrifice and the end never seemed to be within reach. Much of the work in preparing this book was supported as part of the educational mission of the Johns Hopkins University Applied Physics Laboratory. Samuel J. Seymour Steven M. Biemer 2010

PREFACE TO THE FIRST EDITION

Learning how to be a successful systems engineer is entirely different from learning how to excel at a traditional engineering discipline. It requires developing the ability to think in a special way, to acquire the “systems engineering viewpoint,” and to make the central objective the system as a whole and the success of its mission. The systems engineer faces three directions: the system user’s needs and concerns, the project manager’s financial and schedule constraints, and the capabilities and ambitions of the engineering specialists who have to develop and build the elements of the system. This requires learning enough of the language and basic principles of each of the three ­constituencies to understand their requirements and to negotiate balanced solutions acceptable to all. The role of interdisciplinary leadership is the key contribution and principal challenge of systems engineering, and it is absolutely indispensable to the successful development of modern complex systems.

1.1 OBJECTIVES Systems Engineering Principles and Practice is a textbook designed to help students learn to think like systems engineers. Students seeking to learn systems engineering after mastering a traditional engineering discipline often find the subject highly abstract and ambiguous. To help make systems engineering more tangible and easier to grasp, the book provides several models: (i) a hierarchical model of complex systems, showing them to be composed of a set of commonly occurring building blocks or components; (ii) a system life cycle model derived from existing models but more explicitly related to evolving engineering activities and participants; (iii) a model of the steps in the systems engineering method and their iterative application to each phase of the life cycle; (iv) a concept of “materialization” that represents the stepwise evolution of an abstract concept to an engineered, integrated, and validated system; and (v) repeated references to the specific responsibilities of systems engineers as they evolve during the system life cycle and to the scope of what a systems engineer must know to perform xxix

xxx

PREFACE TO  THE  FIRST EDITION

these effectively. The book’s significantly different approach is intended to complement the several excellent existing textbooks that concentrate on the quantitative and analytical aspects of systems engineering. Particular attention is devoted to systems engineers as professionals, their responsibilities as part of a major system development project, and the knowledge, skills, and mindset they must acquire to be successful. The book stresses that they must be innovative and resourceful, as well as systematic and disciplined. It describes the special functions and responsibilities of systems engineers in comparison with those of systems analysts, design specialists, test engineers, project managers, and other members of the system development team. While the book describes the necessary processes that systems engineers must know and execute, it stresses the leadership, problem‐solving, and innovative skills necessary for success. The function of systems engineering as defined here is to “guide the engineering of complex systems.” To learn how to be a good guide requires years of practice and the help and advice of a more experienced guide who knows “the way.” The purpose of this book is to provide a significant measure of such help and advice through the organized collective experience of the authors and other contributors. This book is intended for graduate engineers or scientists who aspire to or are already engaged in careers in systems engineering, project management, or engineering management. Its main audience is expected to be engineers educated in a single discipline, either hardware or software, who wish to broaden their knowledge so as to deal with systems problems. It is written with a minimum of mathematics and specialized jargon so that it should also be useful to managers of technical projects or organizations, as well as to senior undergraduates.

1.2  ORIGIN AND CONTENTS The main portion of the book has been used for the past five years to support the five core courses of the Johns Hopkins University Master of Science in Systems Engineering program and is thoroughly class tested. It has also been used successfully as a text for distance course offerings. In addition, the book is well suited to support short courses and in‐house training. The book consists of 14 chapters grouped into 5 parts: •

•

•

Part I. The Foundations of Systems Engineering, consisting of Chapters 1–4, describes the origin and structure of modern systems, the stepwise development process of complex systems, and the organization of system development projects. Part II. Concept Development, consisting of Chapters 5–7, describes the first stage of the system life cycle in which a need for a new system is demonstrated, its requirements are developed, and a specific preferred implementation concept is selected. Part III. Engineering Development, consisting of Chapters 8–10, describes the second stage of the system life cycle, in which the system building blocks are engineered and the total system is integrated and evaluated in an operational environment.

PREFACE TO  THE  FIRST EDITION

•

•

xxxi

Part IV. Post‐development, consisting of Chapters 11 and 12, describes the role of systems engineering in the production, operation, and support phases of the system life cycle and what domain knowledge of these phases in the system life cycle a systems engineer should acquire. Part V. Special Topics consists of Chapters 13 and 14. Chapter 13 describes the pervasive role of software throughout system development, and Chapter  14 addresses the application of modeling, simulation, and trade‐off analysis as systems engineering decision tools.

Each chapter also contains a summary, homework problems, and a bibliography. A glossary of important terms is also included. The chapter summaries are formatted to facilitate their use in lecture viewgraphs.

ACKNOWLEDGMENTS The authors gratefully acknowledge the many contributions made by the present and past faculties of the Johns Hopkins University Systems Engineering program. Particular thanks are due to S. M. Biemer, J. B. Chism, R.S. Grossman, D.C. Mitchell, J.W. Schneider, R.M. Schulmeyer, T.P. Sleight, G.D. Smith, R. J. Thompson, and S. P. Yanek for their astute criticism of passages that may have been dear to our hearts but are in need of repairs. An even larger debt is owed to Ben E. Amster, who was one of the originators and the initial faculty of the Johns Hopkins University Systems Engineering program. Though not directly involved in the original writing, he enhanced the text and diagrams by adding many of his own insights and fine‐tuned the entire text for meaning and clarity, applying his 30 years’ experience as a systems engineer to great advantage. We especially want to thank H. J. Gravagna for her outstanding expertise and inexhaustible patience in typing and editing the innumerable rewrites of the drafts of the manuscript. These were issued to successive classes of systems engineering students as the book evolved over the past three years. It was she who kept the focus on the final product and provided invaluable assistance with the production of this work. Finally, we are eternally grateful to our wives, Arabelle and Kathleen, for their encouragement, patience, and unfailing support, especially when the written words came hard and the end seemed beyond our reach. Much of the work in preparing this book was supported as part of the educational mission of the Johns Hopkins University Applied Physics Laboratory. Alexander Kossiakoff William N. Sweet 2002

PART I FOUNDATIONS OF SYSTEMS ENGINEERING

1 SYSTEMS ENGINEERING AND THE WORLD OF MODERN SYSTEMS

1.1  WHAT IS SYSTEMS ENGINEERING? There are many ways in which to define systems engineering. We will use the following definition: The function of systems engineering is to guide the engineering and development of complex systems.

To guide is defined as “to lead, manage, or direct, usually based on the superior experience in pursuing a given course” and “to show the way.” This characterization emphasizes the process of selecting the path for others to follow from among many possible courses – a primary function of systems engineering. A dictionary definition of engineering is “the application of scientific principles to practical ends; as the design, construction and operation of efficient and economical structures, equipment, and systems.” In this definition, the terms “efficient” and “economical” are particular contributions of good systems engineering. “Development” includes the identification, coordination, and management of diverse field of expertise in many domain applications. Systems Engineering Principles and Practice, Third Edition. Alexander Kossiakoff, Samuel J. Seymour, David A. Flanigan, and Steven M. Biemer. © 2020 John Wiley & Sons, Inc. Published 2020 by John Wiley & Sons, Inc.

3

4

Systems Engineering and  The  World of  Modern Systems

The word “system,” as is the case with most common English words, has a very broad meaning. A frequently used definition of a system is “a set of interrelated components working together toward some common objective.” This definition implies a multiplicity of interacting parts that collectively perform a significant function. The term complex restricts this definition to systems in which the elements are diverse and have intricate relationships with one another. Thus, a home appliance such as a washing machine would not be considered sufficiently diverse and complex to require systems engineering, even though it may have some modern automated attachments. On the other hand, the context of an engineered system excludes such complex systems as living organisms and ecosystems. The restriction of the term “system” to one that is complex and engineered makes it more clearly applicable to the function of systems engineering as it is commonly understood. The above definitions of “systems engineering” and “system” are not represented as being unique or superior to those used in other textbooks, each of which defines them somewhat differently. In order to avoid any potential misunderstanding, the meaning of these terms as used in this book is defined at the very outset, before going on to the more important subjects of the responsibilities, problems, activities, and tools of systems engineering.

Systems Engineering and Traditional Engineering Disciplines From the above definition, it can be seen that systems engineering differs from mechanical, electrical, and other engineering disciplines in several important ways. 1. Systems engineering is focused on the system as a whole; it emphasizes its total operation. It looks at the system from the outside, that is, at its interactions with other systems and the environment, as well as from the inside. It is concerned not only with the engineering design of the system but also with external factors, which can significantly constrain the design. These include the identification of customer needs, the system operational environment, interfacing systems, logistic support requirements, the capabilities of operating personnel, and such other factors as must be correctly reflected in system requirements documents and accommodated in the system design. 2. While the primary purpose of systems engineering is to guide, this does not mean that systems engineers do not themselves play a key role in system design. On the contrary, they are responsible for leading the formative (Concept Development) stage of a new system development, which culminates in the functional design of the system reflecting the needs of the user. Important design decisions at this stage cannot be based entirely on quantitative knowledge, as they are for the traditional engineering disciplines, but rather must often rely on qualitative judgments balancing a variety of incommensurate quantities and utilizing experience in a variety of disciplines, especially when dealing with new technology. 3. Systems engineering bridges the traditional engineering disciplines. The diversity of the elements in a complex system requires different engineering disciplines to

THE SYSTEMS ENGINEERING LANDSCAPE

5

be involved in their design and development. For the system to perform correctly, each system element must function properly in combination with one or more other system elements. Implementation of these interrelated functions is dependent on a complex set of physical and functional interactions between separately designed elements. Thus, the various elements cannot be engineered independently of one another and then simply assembled to produce a working system. Rather, systems engineers must guide and coordinate the design of each individual element as necessary to assure that the interactions and interfaces between system elements are compatible and mutually supporting. Such coordination is especially important when individual system elements are designed, tested, and supplied by different organizations.

Systems Engineering and Project Management The engineering of a new complex system usually begins with an exploratory stage in which a new system concept is evolved to meet a recognized need or exploit a technological opportunity. When the decision is made to engineer the new concept into an operational system, the resulting effort is inherently a major enterprise, which typically requires many people, with diverse skills, to devote years of effort to bring the system from concept to operational use. The magnitude and complexity of the effort to engineer a new system requires a dedicated team to lead and coordinate its execution. Such an enterprise is called a “project” and is directed by a project manager aided by a staff. Systems engineering is an inherent part of project management – the part that is concerned with guiding the engineering effort itself  –  setting its objectives, guiding its execution, evaluating its results, and prescribing necessary corrective actions to keep it on course. The management of the planning and control aspects of the project fiscal, contractual, and customer relations is supported by systems engineering, but is usually not considered to be part of the systems engineering function. This subject is described in more detail in Chapter 4. Recognition of the importance of systems engineering by every participant in a system development project is essential for its effective implementation. To accomplish this, it is often useful to formally assign the leader of the systems engineering team to a recognized position of technical responsibility and authority within the project.

1.2  THE SYSTEMS ENGINEERING LANDSCAPE Systems engineering principles have been practiced at some level since the building of the pyramids and probably before. The recognition of systems engineering as a distinct activity is often associated with the effects of World War II. More generally, the recognition of systems engineering as a unique activity evolved as a necessary corollary to

6

Systems Engineering and  The  World of  Modern Systems

the rapid growth of technology, and its application to major defense and commercial operations during the second half of the twentieth century. World War II provided a tremendous spur to the advancement of technology. The development of high‐performance aircraft, military radar, the proximity fuse, missiles, and especially the atomic bomb required revolutionary advances in the application of energy, materials, and information. These systems were complex, combining multiple technical disciplines, and their development posed engineering challenges significantly beyond those that had been presented by their more conventional predecessors. Moreover, the compressed development time schedules imposed by wartime imperatives necessitated a level of organization and efficiency that required new approaches in program planning, technical coordination, and engineering management. Systems engineering developed to meet these challenges. During the late 1900s, defense requirements continued to drive the growth of technology in jet propulsion, control systems, and materials. However, another development, that of solid‐state electronics, has had perhaps a more profound effect on technological growth. This to a large extent made possible the “information age,” in which computing, global networks, and communications are extending the power and reach of systems far beyond their previous limits. Particularly significant in this connection is the development of the digital computer and the associated software technology driving it, which increasingly leads to the replacement of human control of systems by automation. Computer control and complex human–computer interfaces are qualitatively increasing the complexity of systems, and is a particularly important concern of systems engineering. In the current century, processing power and global networks have led to instantaneous transfer of information and hence social concerns and systems security drive continuing developments to expand and protect the ubiquitous presence of digital components and the software associated with them. Systems engineering designs will continue to focus on monitoring, surveillance, and control of autonomous systems interconnected and vulnerable to attack. Sensor technology coupled with miniaturization is producing innovation at an increasing pace, leading to many new products and services.

Future Systems Global innovation across a wide range of domain applications will continue to drive systems solutions requiring increased collaboration and improved systems tools and dedicated, educated systems engineers. Systems will be more complex, network intensive, autonomous capable, intelligent, adaptable, robust, and secure. Economic drivers will be felt much more strongly as competition and government policies provide outlines for commercial development. In addition to systems application to traditional engineering domains, systems engineering will continue to expand in social, medical, cyber, virtual, environmental, and natural systems. These domains increasingly influence the needs, requirements, and usability of modern systems. Human interests, disease control, healthcare, entertainment, communication, urban design, and commercialization, among other factors, profoundly affect the design, life cycle, and domain applications for complex systems.

THE SYSTEMS ENGINEERING LANDSCAPE

7

The International Council on Systems Engineering (INCOSE) provides the assessment, guidance, and policies for professional systems engineers. The INCOSE systems engineering vision for 2025 is an excellent reference to describe future systems and systems challenges.

Risks The explosive growth of technology has been the single largest factor in the emergence of systems engineering as an essential ingredient in the engineering of complex systems. Advancing technology has not only greatly extended the capabilities of earlier systems, such as aircraft, telecommunications, and power plants, but has also created entirely new systems such as those based on jet propulsion, satellite communications and navigation, global networks, and a host of computer‐based systems for manufacturing, finance, transportation, entertainment, healthcare, and other products and services. Advances in technology have not only affected the nature of products, but have also fundamentally changed the way they are engineered, produced, and operated. These are particularly important in early phases of systems development, as described in Needs Analysis, in Chapter 5. Modern technology has had a profound effect on the very approach to engineering. Traditionally, engineering applies known principles to practical ends. Innovation, however, produces new materials, devices, and processes, whose characteristics are not yet fully measured or understood. The application of these to the engineering of new systems thus increases the risk of encountering unexpected properties and effects that might impact system performance and require costly changes and program delays. However, failure to apply the latest technology to system development also carries risks. These are the risks of producing an inferior system; one that could become prematurely obsolete. If a competitor succeeds in overcoming such problems as may be encountered in using advanced technology, the competing approach is likely to be superior. The successful entrepreneurial organization will thus assume carefully selected technological risks, and surmount them by skillful design, systems engineering, and program management. Software continues to be a growing engineering medium, whose power and versatility have resulted in its use in preference to hardware for the implementation of a growing fraction of system functions. Thus, the performance of modern systems increasingly depends on the proper design and maintenance of software components. As a result, more and more of the systems engineering effort has to be directed to the control of software design and its application. The increase in automation has had an enormous impact on people who operate systems, decreasing their number but often requiring higher skills and therefore special training. Human–machine interfaces and other people–system interactions are particular concerns of systems engineering. Risks, some known and others as yet unknown, will entail a significant development effort to bring each new design approach to maturity and later to validate the use of these designs in system components. Selecting the most promising technological

8

Systems Engineering and  The  World of  Modern Systems

approaches, assessing the associated risks, rejecting those for which the risks outweigh the potential payoff, planning critical experiments, and deciding on potential fallbacks are all primary responsibilities of systems engineering.

Interfaces A complex system that performs a number of different functions must of necessity be configured in such a way that each major function is embodied in a separate component capable of being specified, developed, built, and tested as an individual entity. Such a subdivision takes advantage of the expertise of organizations specializing in particular types of products and hence capable of engineering and producing components of highest quality at lowest cost. Chapter 3 describes the kind of functional and physical building blocks that make up most modern systems. The immensity and diversity of engineering knowledge, which are still growing, have made it necessary to divide the education and practice of engineering into a number of specialties, such as mechanical, electrical, aeronautical, and so on. To acquire the necessary depth of knowledge in any one of these fields, further specialization is needed, into such subfields as robotics, digital design, and fluid dynamics. Thus, engineering specialization is a predominant condition in the field of engineering and manufacturing and must be recognized as a basic condition in the system development process. Each engineering specialty has developed a set of specialized tools and facilities to aid in the design and manufacture of its associated products. Large and small companies have organized around one or several engineering groups to develop and manufacture devices to meet the needs of the commercial market or of system‐oriented industry. The convenience of subdividing complex systems into individual components or subsystems requires integrating these disparate parts into an efficient, smoothly operating system. Integration means that each component fits perfectly with its neighbors accomplished at inter‐component boundaries called interfaces. The functional relationships are called interactions. The task of analyzing, specifying, and validating the component interfaces with each other and with the external environment is beyond the expertise of the individual design specialists and is the province of the systems engineer. Chapter 3 discusses further the importance and nature of this responsibility. An essential goal of systems engineering is to achieve a high degree of modularity to make interfaces and interactions as simple as possible for efficient manufacture, system integration, test, operational maintenance, reliability, and ease of in‐service upgrading. The process of subdividing a system into modular building blocks is called “functional allocation” and is another basic tool of systems engineering.

Agile Systems Engineering New products and systems with creative new innovations are designed and introduced into the market place at a rapid pace. Systems engineers need to develop systems that thrive in uncertain and unpredictably evolving environments – that is, they need to be

SYSTEMS ENGINEERING VIEWPOINT

9

agile. Quite often there exists uncertainty in future user needs and operating environments. There should be agility in the systems engineering process itself, carefully exploring design alternatives and delaying manufacturing and deployment as long as possible as new information becomes available during product development. Systems modules would be able to perform effectively with operational environments that are risky, variable, and evolving. This would be considered agile systems‐engineering. In addition, there should be agility in the resulting system. In other words, systems need to be resilient, providing the ability to repair or replace lost capability over time. Some have described such systems as having reusable, reconfigurable, and scalable design principles. An agile system is hence flexible with the ability to change from one state or operating condition to another rapidly, without large costs or increases in system complexity. They are systems that can respond to changed requirements after initial fielding of the system. This would be considered agile‐systems engineering.

Model‐Based Systems Engineering “Model Based Systems Engineering (MBSE) is an emerging new paradigm for improving the efficiency and effectiveness of systems engineering through the pervasive use of integrated descriptive representations of the system to capture knowledge about the system for the benefit of all stakeholders” (Noguchi 2016). Discussed in Chapter 10, MBSE is the application of purpose‐built modeling languages and tools to improve the effectiveness of systems engineering by allowing system concepts, architectures, requirements, and parametrics to be represented and queried. This permits unprecedented levels of insights and alleviates the cognitive burden imposed by document‐ intensive systems engineering (DISE). Instead of being forced to sift or search through document‐based representations of systems information, systems engineers can develop rich queries that return relevant information in compact, meaningful forms. In addition, it permits adjacent analyses and simulations to draw information from (and return information to) the system model without “air gaps” or human translation.

1.3  SYSTEMS ENGINEERING VIEWPOINT The emergence of complex systems and the prevailing conditions of advancing technology, competitive pressures, and specialization of engineering disciplines and organizations required the development of a new profession: systems engineering. This profession did not, until much later, bring with it a new academic discipline, but rather it was initially filled by engineers and scientists who acquired through experience the ability to lead successfully complex system development programs. To do so, they had to acquire a greater breadth of technical knowledge and, more importantly, develop a different way of thinking about engineering, which has been called “the systems engineering viewpoint.” The essence of the systems engineering viewpoint is exactly what it implies – making the central objective the system as a whole and the success of its mission. This, in turn,

10

Systems Engineering and  The  World of  Modern Systems

means the subordination of individual goals and attributes in favor of those of the overall system. The systems engineer is always the advocate of the total system in any contest with a subordinate objective.

Successful Systems The principal focus of systems engineering, from the very start of a system development, is the success of the system – in meeting its requirements and development objectives, its successful operation in the field, and a long useful operating life. The systems engineering viewpoint encompasses all of these objectives. It seeks to look beyond the obvious and the immediate, to understand the user’s problems and the environmental conditions that the system will be subjected to during its operation. It aims at the establishment of a technical approach that will both facilitate the system’s operational maintenance and accommodate the eventual upgrading that will likely be required at some point in the future. It attempts to anticipate developmental problems and to resolve them as early as possible in the development cycle; where this is not practicable, it establishes contingency plans for later implementation as required. Successful system development requires the use of a consistent well‐understood systems engineering approach within the organization, which involves the exercise of systematic and disciplined direction, with extensive planning, analysis, reviews, and documentation. Just as important, however, is a side of systems engineering that is often overlooked, namely, innovation. For a new complex system to compete successfully in a climate of rapid technological change and to retain its edge for many years of useful life, its key components must use some of the latest technological advances.

Total Systems View In characterizing the systems engineering viewpoint, two oft‐stated maxims are “the best is the enemy of the good enough” and “systems engineering is the art of the good enough.” The popular maxims use the terms “best” and “good enough” to refer to system performance, whereas systems engineering views performance as only one of several critical attributes; equally important ones are affordability, timely availability to the user, ease of maintenance, and adherence to an agreed‐upon development completion schedule. Thus, the systems engineer seeks the best balance of the critical system attributes from the standpoint of the success of the development program and of the value of the system to the user. One of the dictionary definitions of the word “balance” that is especially appropriate to system design is “a harmonious or satisfying arrangement or proportion of parts or elements, as in a design or a composition.” An essential function of systems engineering is to bring about a balance among the various components of the system, which, it was noted earlier, are designed by engineering specialists, with each intent on optimizing the characteristics of a particular component. This is often a daunting task, as illustrated in Figure 1.1. The figure is an artist’s conception of what a guided missile

11

SYSTEMS ENGINEERING VIEWPOINT

Aerodynamics

Propulsion

Production Structures

Guidance

Controls

Analysis

Figure 1.1. The ideal missile design from the viewpoint of various specialists.

might look like if it were designed by a specialist in one or another guided missile component technology. While the cartoons may seem fanciful, they reflect a basic truth, that is, that design specialists will seek to optimize the particular aspect of a system that they best understand and appreciate. In general, it is to be expected that, while the design specialist does understand that the system is a group of components that in combination provide a specific set of capabilities, during system development, the specialist’s attention is necessarily focused on those issues that most directly affect his or her own area of technical expertise and assigned responsibilities. Conversely, the systems engineer must always focus on the system as a whole, while addressing design specialty issues only in so far as they may affect overall system performance, developmental risk, cost, or long‐term system viability. In short, it is the responsibility of the systems engineer to guide the development so that each of the components receives the proper balance of attention and resources, while achieving the capabilities that are optimal for the best overall system behavior. This often involves serving as an “honest technical broker” who guides the establishment of technical design compromises in order to achieve a workable interface between key system elements. The viewpoint of the systems engineer calls for a different combination of skills and areas of knowledge than those of a design specialist or a manager. The design specialist may have limited managerial skills but has a deep understanding in one or a few

12

Systems Engineering and  The  World of  Modern Systems

related areas of technology. Similarly, a project manager needs to have a little depth in any particular technical discipline, but must have considerable breadth and capability to manage people and technical effort. A systems engineer, on the other hand, requires significant capabilities in all components, representing the balance needed to span the needs of a total system effort.

1.4  PERSPECTIVES OF SYSTEMS ENGINEERING While the field of systems engineering has matured rapidly in the past few decades, there will continue to exist a variety of differing perspectives as more is learned about the potential and the utility of systems approaches to solve the increasing complex problems around the world. The growth of systems engineering is evidenced in the number of academic programs and graduates in the area. Systems engineering is a favored and potentially excellent career path. Employers in all sectors, private and government, seek experienced systems engineering candidates. Experts in workforce development look for ways to encourage more secondary school and college students to pursue degrees in science, technology, engineering, and mathematics (STEM). With experience and additional knowledge, these students can mature into capable systems engineers.

Think Like a Systems Engineer Since it often requires professional experience in addition to education to tackle the most complex and challenging problems, developing a systems mindset – to “think like a systems engineer”  –  is a high priority at any stage of life. Systems thinking sees everything as holistic, with all parts interconnected and interdependent. Systems thinking is the method of achieving and maintaining a system design in which every requirement is carefully monitored and carefully controlled, including the human factor. A perspective that relates a progression in the maturity of thinking includes concepts of systems thinking, systems engineering, and engineering systems. See Table 1.1. An approach to understanding the environment, process, and policies of a systems problem requires one to using systems thinking. This approach to a problem examines the domain and scope of the problem and defines it in quantitative terms. One looks at the parameters that help define the problem, and then through research and surveys develops observations about the environment the problem exists in and finally generates options that could address the problem. This approach would be appropriate for use in secondary schools to have young students gain an appreciation of the “big picture” as they learn fundamental science and engineering skills. The systems engineering approach discussed in this book focuses on the products and solutions of a problem, with intent to develop or build a system to address the problem. The approach tends to be more technical, seeking from potential future users and developers of the solution system, what are the top‐level needs, requirements, and concepts of operations, before and then conducting a functional and physical design,

13

PERSPECTIVES OF  SYSTEMS ENGINEERING

TABLE 1.1.  Comparison of Systems Perspectives Systems thinking

Systems engineering

Focus on process

Focus on whole product

Consideration of issues

Solve complex technical problems

Evaluation of multiple factors and influences

Develop and test tangible system solutions

Inclusion of patterns, relationships, and common understanding

Need to meet requirements, measure outcomes, and solve problems

Engineering systems Focus on both process and product Solve complex interdisciplinary technical, social, and management issues Influence policy, processes, and use systems engineering to develop systems solutions Integrate human and technical domain dynamics and approaches

development of design specifications, production, and testing of a system solution for the problem. Attention is given to the subsystem interfaces and the need for viable and tangible results. The approach and practical end could be applied to many degrees of complexity, but there is an expectation of a successful field operation of a product. A broader and robust perspective to systems approaches to solve very extensive complex engineering problems by integrating engineering, management, and social ­sciences approaches using advanced modeling methodologies is termed “engineering systems.” The intent is to tackle some of society’s grandest challenges with significant global impact by investigating ways in which engineering systems behave and interact with one another including social, economic, and environmental factors. This approach encompasses engineering, social sciences, and management processes without the implied rigidity of systems engineering. Hence, applications to critical infrastructure, healthcare, energy, environment, information security, and other global issues are likely areas of attention. Much like the proverbial blind men examining the elephant, the field of systems engineering can be considered in terms of various domains and application areas where it is applied. Based on the background of the individuals and on the needs of the systems problems to be solved, the systems environment can be discussed in terms of the fields and technologies that are used in the solution sets. Another perspective can be taken from the methodologies and approaches taken to solve problems and develop complex systems. In any mature discipline, there exist for systems engineering a number of processes, standards, guidelines, and software tools to organize and enhance the effectiveness of the systems engineering professional. The INCOSE maintains current information and reviews in these areas. These perspectives will be discussed in the following sections.

Systems Engineering Principles and Practice The scope of systems engineering is very broad and multidimensional. As more practitioners and organizations understand the importance and engage in systems engineering, new approaches and applications are developed. As shown in Figure  1.2,

14

Systems Engineering and  The  World of  Modern Systems

Systems engineering Principles and practice Engineering Electrical Mechanical Industrial Computer Architectural Civil Chemical Software

Domain applications Space Defense Biomedical Human Aeronautical Electronics Products Natural

Systems character Complexity Value Social Risk Interfaces

Service systems Healthcare Logistics Communication Energy Information Transportation Business

Systems methods Modeling Simulation Linear Spiral Waterfall

Systems integration Innovation Technology Resilience Safety Security Cost Systems of systems Autonomy

Systems engineering management Standards Budget Schedule Planning and control

Figure 1.2.  Systems engineering principles and practice.

systems engineering principles and practice require a perspective that is encompassing and complex. This broadening landscape illustrates the importance of systems engineering in nearly every product, professional, social, and human endeavor.

Systems Domains With a broad view of systems development, it can be seen that the traditional approach to systems now encompasses a growing domain breadth. And much like a Rubik’s Cube, the domain faces are now completely integrated into the systems engineer’s perspective of the “big (but complex) picture.” The systems domain faces shown in Figure 1.3 include not only the engineering, technical, and management domains but also social, political/legal, and human domains. These latter dimensions require additional attention and research to fully understand their impact and utility in systems development, especially as we move to areas at the enterprise and global family of systems levels of complexity. Particularly interesting domains are those that involve scale, such as nano and microsystems, or systems that operate (often autonomously) in extreme environments, such as deep undersea or outer space. Much like physical laws change with scale, does the systems engineering approach need to change? Should systems engineering practices evolve to address the needs for submersibles, planetary explorers, or intravascular robotic systems? Additionally, interesting are the increasing complexities introduced

15

PERSPECTIVES OF  SYSTEMS ENGINEERING

g

rin

Engineering

Management

e ne

gi

en

Technical

s

m

ste Sy

Social

Political/Legal

Human

Figure 1.3.  Systems engineering.

with rapid mobile communications, autonomous vehicles, and social networks, which confound the human, legal, and political elements.

Systems Engineering Components Since systems engineering has a strong connection bridging the traditional engineering disciplines like electrical, mechanical, aerodynamic, and civil engineering among others, it should be expected that engineering specialists look at systems engineering with a perspective more strongly from their engineering discipline. Similarly, since systems engineering is a guide to design of systems often exercised in the context of a project or program, then functional, project, and senior managers will consider the management elements of planning and control to be key aspects of systems development. The management support functions that are vital to systems engineering success such as quality management, human resource management, and financial management can all claim an integral role and perspective to the systems development. These perceptions are illustrated in Figure 1.4 and additional fields are also shown that represent a few of the traditional areas associated with and influence systems engineering methods and practices. An example is the area of operations research whose view of systems engineering includes provision of a structure that will lead to quantitative analysis of alternatives and optimal decisions. The design of systems also has a contingency of professionals who focus on the structures and architectures. In diverse areas such as manufacturing to autonomous systems, another interpretation of systems engineering comes from engineers who develop control systems who lean heavily on

16

Systems Engineering and  The  World of  Modern Systems

O p re era se tio ar n ch s

ing er e n gi lds En fie

Modeling and simulation

Control systems Systems engineering

Arc

hite

Management

H res uma ou n rce s

Project management

ctu

res

y

alit

Qu

Figure 1.4. Examples of systems engineering components.

the systems engineering principles that focus on management of interfaces and feedback systems. Finally, the overlap of elements of modeling and simulation with systems engineering provides a perspective that is integral to cost‐effective examination of systems options to meet the requirements and needs of the users. As systems engineering matures, there will an increasing number of perspectives from varying fields that adopt it as their own.

Systems Engineering Methods Systems engineering can also be viewed in terms of the depictions of the sequence of processes and methodologies used in execution of design, development, integration, and testing of a system. See Figure 1.5 for examples. Early graphics were linear in the process flow with sequences of steps that are often iterative to show the logical means to achieve consistency and viability. Small variations are shown in the waterfall charts that provide added means to illustrate interfaces and broader interactions. Many of the steps are repeated and dependent on each other leading to the spiral or loop conceptual diagrams. The popular systems engineering “V” diagram provides a view of life cycle development with explicit relationships shown between requirements and systems definition and the developed and validated product.

1.5  EXAMPLES OF SYSTEMS REQUIRING SYSTEMS ENGINEERING As noted at the beginning of this chapter, the generic definition of a system as a set of interrelated components working together as an integrated whole to achieve some common objective would fit most familiar home appliances. A washing machine

17

EXAMPLES OF  SYSTEMS REQUIRING SYSTEMS ENGINEERING

Waterfall Systems engineering method

Requirements analysis

Linear

Functional definition Concept development

Engineering development

Post development

Physical definition

Design validation

The “V” Spiral

Need

Mission

2

na

lys is

ept fo

5

rmula tio

n

the

ns yn sig

De

EAND DAV CE/D

io ne ra t ge n tio Sy st em

is lys na sa es en tiv ec Eff

De

op

sis aly

an

o Pr

Sys tem

PSD

sis

on

ti

iza

tim

n

sig

lity

ibi

c du

Logistics support analysis

tion

loca ents al

m

re Requi

4

ca

la

3

ifi

na

ec

Conc

io

alysis q’s an

ct

n

and re

Fu n

Sp

1

test

&e valu a

tion

in

te g

ra t

io

n

Figure 1.5. Examples of systems engineering approaches.

c­ onsists of a main clothes tub, an electric motor, an agitator, a pump, a timer, an inner spinning tub, and various valves, sensors, and controls. It performs a sequence of timed operations and auxiliary functions based on a schedule and operation mode set by the operator. A refrigerator, microwave oven, dishwasher, vacuum cleaner, and radio all perform a number of useful operations in a systematic manner. However, these appliances involve only one or two engineering disciplines, and their design is based on well‐established technology. Thus, they fail the criterion of being complex and we would not consider the development of a new washer or refrigerator to involve much systems engineering as we understand the term, although it would certainly require a high order of reliability and cost engineering. Of course, home appliances increasingly include clever automatic devices that use newly available microchips, but these are usually self‐contained add‐ons and are not necessary to the main function of the appliance. Since the development of new modern systems is strongly driven by technological change, we shall add one more characteristic to a system requiring systems engineering, namely, that some of its key elements use advanced technology. The characteristics

18

Systems Engineering and  The  World of  Modern Systems

of a system whose development, test, and application require the practice of systems engineering are that the system • • •

Is an engineered product and hence satisfies a specified need. Consists of diverse components that have intricate relationships with one another and hence is multidisciplinary and relatively complex. Uses advanced technology in ways that are central to the performance of its primary functions and hence involves development risk and often relatively high cost.

Henceforth, references in this text to an engineered or complex system (or in the proper context, just system) will mean the type which has the three attributes noted above; that is, is an engineered product, contains diverse components, and uses advanced technology. These attributes are, of course, in addition to the generic definition stated earlier, and serve to identify the systems of concern to the systems engineer as those that require system design, development, integration, test, and evaluation.

Complex Engineered Systems To illustrate the types of systems that fit within the above definition, Tables 1.2 and 1.3 list 10 modern systems and their principal inputs, processes, and outputs. It has been noted that a system consists of a multiplicity of elements, some of which may well themselves be complex and deserve to be considered a system in their own right. For example, a telephone‐switching substation can well be considered as a system, with the telephone network considered as a “system of systems.” Such issues will be discussed more fully in future chapters, to the extent necessary for the understanding of systems engineering. TABLE 1.2.  Examples of Engineered Complex Systems: Signal and Data Systems System

Inputs

Process

Outputs

Weather satellite

Images

• Data storage • Transmission

Encoded images

Terminal air traffic control system

Aircraft beacon responses

• Identification • Tracking

• Identity • Air tracks • Communications

Track location system

Cargo routing requests

• Map tracing • Communication

• Routing info. • Delivered cargo

Airline reservation system

Travel requests

Data management

• Reservations • Tickets

Clinical information system

• Patient ID • Test records • Diagnosis

Information management

• Patient status • History • Treatment

19

EXAMPLES OF  SYSTEMS REQUIRING SYSTEMS ENGINEERING

TABLE 1.3.  Examples of Engineered Complex Systems: Material and Energy Systems System

Inputs

Process

Outputs

Passenger aircraft

• Passengers • Fuel

• Combustion • Thrust • Lift

Transported passengers

Modern harvester combine

• Grain field • Fuel

• Cutting • Threshing

Harvested grain

Oil refinery

• Crude oil • Catalysts • Energy

• Cracking • Separation • Blending

• Gasoline • Oil products • Chemicals

Auto assembly plant

• Auto parts • Energy

• Manipulation • Joining • Finishing

Assembled auto

Electric power plant

• Fuel • Air

• Power generation • Regulation

• Electric AC power • Waste products

Example: A Modern Automobile.  A more simple and familiar system, which still meets the criteria for an engineered system, is a fully equipped passenger automobile. It can be considered as a lower limit to more complex vehicular systems. It is made up of a large number of diverse components requiring the combination of several different disciplines. To operate properly, the components must work together accurately and efficiently. Whereas the operating principles of automobiles are well established, modern autos must be designed to operate efficiently, while at the same time maintaining very close control of engine emissions, which requires sophisticated sensors and computer‐ controlled mechanisms for injecting fuel and air. Anti‐lock brakes are another example of a finely tuned automatic automobile subsystem. Advanced materials and computer technology are used to an increasing degree in passenger protection, cruise control, automated navigation, and autonomous driving and parking. The stringent requirements on cost, reliability, performance, comfort, safety, and a dozen other parameters present a number of substantive systems engineering problems. Accordingly, an automobile meets the definition established earlier for a system requiring the application of systems engineering. An automobile (without future autonomous capability) is also an example of a large class of systems that require active interaction (control) by a human operator. To some degree, all systems require such interaction, but in this case, continuous control is required. In a very real sense, the operator (driver) functions as an integral part of the overall automobile system, serving as the steering feedback element that detects and corrects deviations of the car’s path on the road. The design must therefore address as a critical constraint the inherent sensing and reaction capabilities of the operator, in addition to a range of associated human–machine interfaces such as the design and placement of controls and displays, seat position, and so on. Also, while the passengers may not function as integral elements of the auto steering system, their associated

20

Systems Engineering and  The  World of  Modern Systems

interfaces (e.g. weight, seating and viewing comfort, safety) must be carefully addressed as part of the design process.

1.6  SYSTEMS ENGINEERING ACTIVITIES AND PRODUCTS Sometimes followed as a roadmap, the life cycle development of a system can be associated with a number of systems engineering and project management products or outputs that are listed in Table  1.4. The variety and breadth of these products reflect the challenges early professional have in understanding the full utility of engaging in systems engineering. Throughout this book, these products will be introduced and discussed in some detail to help guide the systems engineer in product development.

1.7  SYSTEMS ENGINEERING AS A PROFESSION With the increasing prevalence of complex systems in modern society, and the essential role of systems engineering in the development of systems, systems engineering as a profession has become widely recognized. Its primary recognition has come in companies specializing in the development of large systems. A number of these have established departments of systems engineering, and have classified those engaging in the process as systems engineers. In addition, global challenges in healthcare, communications, environment, and many more complex areas require engineering systems methods to develop viable solutions. Engineering disciplines are built on quantitative relationships, obeying established physical laws, and measured properties of materials, energy, or information. Systems engineering, on the other hand, deals mainly with problems for which there is incomplete TABLE 1.4.  Systems Engineering Activities and Documents Context diagrams

Opportunity assessments

Prototype integration

Problem definition

Candidate concepts

Prototype test and evaluation

User/owner identification

Risk analysis/management plan

Production/operations plan

User needs

Systems functions

Operational tests

Concept of operations

Physical allocation

Verification and validation

Scenarios

Component interfaces

Field support/maintenance

Use cases

Traceability

System/product effectiveness

Requirements

Trade studies

Upgrade/revise

Technology readiness

Component development and test

Disposal/reuse

SYSTEMS ENGINEERING AS  A  PROFESSION

21

knowledge, whose variables do not obey known equations, and where a balance must be made among conflicting objectives involving incommensurate attributes. The absence of a quantitative knowledge base previously inhibited the establishment of systems engineering as a unique discipline. Despite those obstacles, the recognized need for systems engineering in industry and government has spurred the establishment worldwide of a number of academic programs offering master’s degrees and doctoral degrees in system(s) engineering. An increasing number of universities are offering undergraduate degrees in systems engineering as well. The recognition of systems engineering as a profession led in the formation of a professional society, the INCOSE, one of whose primary objectives is the promotion of systems engineering, and the recognition of systems engineering as a professional career.

Career Choices Systems engineers are highly sought after because their skills complement those in other fields and often serve as the “glue” to bring new ideas to fruition. However, career choices and the related educational needs for those choices are complex, especially when the role and responsibilities of a systems engineer are poorly understood. Four potential career directions are shown in Figure  1.6: financial, management, technical, and systems engineering. There are varying degrees of overlap between them despite the symmetry shown in the figure. The systems engineer focuses on the whole system product leading and working with many diverse technical team members, ­following the systems engineering development cycle, conducting studies of alternatives, and managing the system interfaces. The systems engineer generally matures in the field after a technical undergraduate degree with work experience and a master of science degree in systems engineering, with increasing responsibility of successively larger projects, eventually serving as the chief or lead systems engineer for a major systems, or systems‐of‐systems development. Note the overlap and need to understand the content and roles of the technical specialists and coordinate with the program manager (PM). The project manager often with a technical or business background, is responsible for interfacing with the customer and defining the work, developing the plans, monitoring and controlling the project progress, and delivering the finished output to the customer. The project manager often learns on the job from experience with projects of increasing size and importance, enhancing the toolset available with a master of science degree in technical/program management. While not exclusively true, the chief executive officer frequently originates from the ranks of the organization’s project mangers. The financial or business career path that ultimately could lead to a chief financial officer position usually includes business undergraduate and master in business administration (MBA) degrees. Individuals progress through their careers with various horizontal and vertical moves, often with specialization in the field. There is overlap in skill and knowledge with the PM in areas of contract and finance management. Many early careers start with a technical undergraduate degree in engineering, science, or information technology. The technical specialist makes contributions as part

22

Systems Engineering and  The  World of  Modern Systems

CFO MBA One must keep fresh in the technical field to avoid obsolescence

BS

Developing fiscal skills and tools through horizontal and lateral transitions

CTO

BS

MS

OJT

CEO

Financial Technical management

Technical specialty Systems engineering

Interfacing with the customer and managing WBS, budgets, and schedules

Program manager

BS PhD MS BS Increasing technical specialty

MS

OJT Leading multidisciplinary teams and developing diverse products

Focus on whole systems product Increasing technical and program responsibility

Chief or lead systems engineer

Copyright 2008 S.J. Seymour

Figure 1.6.  Career opportunities and growth.

of a team in the area of their primary knowledge, honing skills and experience to develop and test individual components or algorithms that are part of a larger system. Contributions are made project‐to‐project over time and recognition is gained from innovative, timely, and quality workmanship. Technical specialists need to continue to learn about their field, and stay current in order to be employable compared with the next generation of college graduates. Often advanced degrees (MS and PhDs) are acquired to enhance knowledge, capability, and recognition, and job responsibilities can lead to positions such as lead engineer, lead scientist, or chief technology officer in an organization. The broader minded or experienced specialist often considers a career in systems engineering.

The Challenge of Systems Engineering An inhibiting factor in becoming a professional systems engineer is that it represents a deviation from a chosen established discipline to a more diverse, complicated professional practice. It requires the investment of time and effort to gain experience and extensive broadening of the engineering base, as well as learning communication and management skills. For the above reasons, an engineer considering a career in systems engineering may come to the conclusion that the road is difficult. It is clear that a great deal must be learned and that the educational experience in a traditional engineering discipline is

SYSTEMS ENGINEERING AS  A  PROFESSION

23

necessary and will be of only limited direct use; that is, there are few tools and few quantitative relationships to help make decisions. Instead, the issues are ambiguous and abstract, defying definitive solutions. There may appear to be little opportunity for individual accomplishment and even less for individual recognition. For a systems engineer, success is measured by the accomplishment of the development team, not necessarily the system team leader.

What Then Is the Attraction of Systems Engineering? The answer may lie in the challenges of systems engineering rather than its direct rewards. Systems engineers deal with the most important issues in the system development process. They design the overall system architecture and the technical approach and lead others in designing the components. They prioritize the system requirements in conjunction with the customer, to ensure that the different system attributes are appropriately weighted when balancing the various technical efforts. They decide which risks are worth undertaking and which are not, and how the former should be hedged to ensure program success. It is the systems engineers who map out the course of the development program that prescribes the type and timing of tests and simulations to be performed along the way. They are the ultimate authorities on how the system performance and system affordability goals may be achieved at the same time. When unanticipated problems arise in the development program, as they always do, it is the systems engineers who decide how they may be solved. They determine whether an entirely new approach to the problem is necessary, whether more intense effort will accomplish the purpose, whether an entirely different part of the system can be modified to compensate for the problem, or whether the requirement at issue can best be scaled back to relieve the problem. Systems engineers derive their ability to guide the system development not from their position in the organization, but from their superior knowledge of the system as a whole, its operational objectives, how all its parts work together, and all the technical factors that go into its development, as well as from their proven experience in steering complex programs through a maze of difficulties to a successful conclusion.

Attributes and Motivations of Systems Engineers In order to identify candidates for systems engineering careers, it is useful to examine the characteristics that may be useful to distinguish people with a talent for systems engineering from those who are not likely to be interested or successful in that discipline. Those likely to become talented systems engineers would be expected to have done well in mathematics and science in college. A systems engineer will be required to work in a multidisciplinary environment and grasp the essentials of related disciplines. It is here that an aptitude for science and engineering helps a great deal, because it makes it much easier and less threatening for

24

Systems Engineering and  The  World of  Modern Systems

individuals to learn the essentials of new disciplines. It is not so much that they require in‐depth knowledge of higher mathematics, but rather those who have a limited mathematical background tend to lack confidence in their ability to grasp subjects that inherently contain mathematical concepts. A systems engineer should have a creative bent and must like to solve practical problems. Interest in the job should be greater than interest in career advancement. Systems engineering is more of a challenge than a quick way to the top. The following characteristics are commonly found in successful systems engineers. They 1. Enjoy learning new things and solving problems. 2. Like a challenge. 3. Are skeptical of unproven assertions. 4. Are open‐minded to new ideas. 5. Have a solid background in science and engineering. 6. Have demonstrated technical achievement in a specialty area. 7. Are knowledgeable in several engineering areas. 8. Pick up new ideas and information quickly. 9. Have good interpersonal and communication skills.

1.8  SYSTEMS ENGINEER CAREER DEVELOPMENT MODEL When one has the characteristics noted above and is attracted to become a systems engineer, there are four more elements that need to be present in the work environment. As shown in Figure 1.7, one should seek assignments to problems and tasks that are very challenging and likely to expand technical domain knowledge and creative juices. Whatever the work assignment, understanding the context of the work and understanding the big picture is also essential. Systems engineers are expected to manage many activities at the same time, being able to have broad perspectives, but able to delve deeply in to many subjects at once. This ability to multiplex is one that takes time to develop. Finally, the systems engineer should not be intimidated by complex problems since this is the expected work environment. It is clear these elements are not part of an educational program and must be gained through extended professional work experience. This becomes the foundation for the systems engineering career growth model. Employers seeking to develop systems engineers to competitively address more challenging problems should provide key staff with relevant systems engineering work experience, activities that require mature systems thinking, and opportunities for systems engineering education and training. In Figure 1.8, it can be seen that the experience can be achieved not only with challenging problems, but with experienced mentors and real, practical exercises. While using systems thinking to explore complex

25

SYSTEMS ENGINEER CAREER DEVELOPMENT MODEL

Exposure to the big picture

Assigned challenging problems

Ability to multiplex Proclivity for complexity

Figure 1.7.  Systems engineering career elements derived from quality work experiences. Development of systems engineers Engineering process training

Principles

Tools skills

Case studies

Leadership SE processes management Leadership SE processes management

Systems thinking activities

Multiplexing

Multitasking Multidisciplines Prioritization

Leadership SE processes management

Problem solving

Systems engineering work experience

Complexity Multiplexing Problem big picture solving

States/modes relationships interfaces

Outcomes focused schedule driven creative

Complexity big picture

Technical engineering social

Models advisors best practices

Team/group laboratory field/operational

Figure 1.8.  Components of employer development of systems engineers.

problem domains, staff should be encouraged to think creatively and out of the box. Often, technically trained people rigidly follow the same processes and tired ineffective solutions. Using lessons learned from past programs and case studies creates opportunities for improvements. Formal training and use of systems engineering tools further enhance employer preparation for tackling complex issues. Interests, attributes, and training, along with an appropriate environment, provide the opportunity for individuals to mature into successful systems engineers. The combination of these factors is captured in the “T” model for systems engineer career development illustrated in Figure  1.9. In the vertical part, from bottom to top is the time progression in a professional’s career path. After completion of a technical undergraduate degree, shown along the bottom of the chart, an individual generally enters professional life as a technical contributor to a larger effort. The effort is part of a project or program that falls in a particular domain such as aerodynamics, biomedicine, combat

26

Systems Engineering and  The  World of  Modern Systems

Domain breadth Systems programs lead Systems engineering leader (>20 yrs)

Program lead

Technical depth

Large project lead

DSci PhD MS

BS

Education

Operational and field

E x p e r i e n c e

CE

ME

EE

Small project lead

M e n t o r i n g

Senior systems engineer (13–20 yrs) Systems engineer (9–12 yrs) Team participant (5–8 yrs) Technical contributor (1–4 yrs)

AE

App Math

…

Educational disciplines

Figure 1.9.  “T” model for systems engineer career development.

systems, information systems, or space exploration. Within a domain, there are several technical competencies that are fundamental for systems to operate or be developed. The “T” is formed by snapshots during a professional’s career that illustrates in the horizontal part of the “T” the technical competencies at the time that were learned and used to meet the responsibilities assigned at that point in their career. After initial experience in one or two technical domains as technical contributor, one progresses to increasing responsibilities in a team setting and eventually to leading small technical groups. After eight or more years, the professional has acquired both sufficient technical depth and technical domain depth to be considered a systems engineer. Additional assignments lead to project and program systems engineering leadership and eventually to being the senior systems engineer for a major development program that exercises the full range of the technical competencies for the domain. In parallel with broadening and deepening technical experience and competencies, the successful career path is augmented by assignments that involve operational field experiences, advanced education and training, and a strong mentoring program. In order to obtain a good understanding of the environment where the system under development will operate and to obtain firsthand knowledge of the system requirements, it is essential the early systems engineer professional visit the “field site” and operational location. That approach is important to continue throughout one’s career. A wide variety of

SUMMARY

27

systems engineering educational opportunities are available in both classroom and online formats. As in most engineering disciplines where the student is not planning on an academic career, the master of science is the terminal degree. Courses are usually a combination of systems engineering and domain or concentration centric focused with a thesis or capstone project for the student to demonstrate their knowledge and skills on a practical systems problem. Large commercial companies also provide training in systems engineering and systems architecting with examples and tools that are specific to their organization and products. Finally, the pairing of a young professional with an experienced systems engineer will enhance the learning process.

1.9 SUMMARY What Is Systems Engineering? The function of systems engineering is to guide the engineering of complex systems. And a system is defined as a set of interrelated components working together toward a common objective. Furthermore, a complex engineered system is (i) composed of a multiplicity of intricately interrelated diverse elements and (ii) requires systems engineering to lead its development. Systems engineering differs from traditional disciplines in that it (i) is focused on the system as a whole; (ii) is concerned with customer needs and operational environment; (iii) leads system conceptual design; and (iv) bridges traditional engineering disciplines and gaps between specialties. Moreover, systems engineering is an integral part of project management in that it plans and guides the engineering effort.

Systems Engineering Landscape Systems will be more complex, network intensive, autonomous capable, intelligent, adaptable, robust, and secure. Drivers will include economics, risks  –  both known and unknown – from advancing technology and innovation, increased complexity and interfaces, expanded systems applications and social impacts, new autonomy, and expected agility.

Systems Engineering Viewpoint The systems engineering viewpoint is focused on producing a successful system that meets requirements and development objectives, is successful in its operation in the field, and achieves its desired operating life. In order to achieve this definition of success, the systems engineer must balance superior performance with affordability and schedule constraints. In fact, many aspects of systems engineering involve achieving a balance among conflicting objectives. For example, the systems engineering typically must apply new technology to the development of a new system while managing the inherent risks that new technology poses.

28

Systems Engineering and  The  World of  Modern Systems

Throughout the development period, the systems engineering focuses on the total system, making decisions based on the impacts and capabilities of the system as a whole. Often, this is accomplished by bridging multiple disciplines and components to ensure a total solution. Specialized design is one‐dimensional, in that it has great technical depth, but little technical breadth and little management expertise. Planning and control is two‐dimensional: it has great management expertise, but moderate technical breadth and small technical depth. But systems engineering is three‐dimensional: it has great technical breadth, as well as moderate technical depth and management expertise.

Perspectives of Systems Engineering A spectrum of views exist in understanding systems engineering, from a general systems thinking approach to problems, to the developmental process approach for systems engineering, to the broad perspective of engineering systems. Systems thinking is the method of achieving and maintaining a system design, in which every requirement is carefully monitored and carefully controlled, including the human factor. The engineering systems view encompasses not only traditional engineering disciplines, but technical, and management domains, social, political/legal, and human domains. Scales at the extremes are of particular interest due to their complexity. As the field of systems engineering matures and is used for many applications, several process models have been developed including the linear, the “V,” spiral, and waterfall.

Examples of Systems Requiring Systems Engineering Examples of engineered complex systems include: • • • • • • • • • •

Weather satellites Terminal air traffic control Truck location systems Airline navigation systems Clinical information systems Passenger aircraft Modern harvester combines Oil refineries Auto assembly plants Electric power plants

Systems Engineering Activities and Products A full systems life cycle view illustrates the close relationship with the management process and leads to a large diverse set of activities and products.

PROBLEMS

29

Systems Engineering as a Profession Systems engineering is now recognized as a profession, and has an increasing role in government and industry. In fact, numerous graduate (and some undergraduate) degree programs are now available across the country. And a formal, recognized organization exists for systems engineering professionals: the INCOSE. Technical professionals have specific technical orientations – technical graduates tend to be highly specialized. Only a few become interested in interdisciplinary problems – it is these individuals who often become systems engineers.

Systems Engineer Career Development Model The systems engineering profession is difficult but rewarding. A career in systems engineering typically features technical satisfaction  –  finding the solution of abstract and ambiguous problems  –  and recognition in the form of a pivotal program role. Consequently, a successful systems engineer has the following traits and attributes: • • • •

A good problem solver and should welcome challenges. Well‐grounded technically, with broad interests. Analytical and systematic, but also creative. A superior communicator, with leadership skills.

The “T” model represents the proper convergence of experience, education, mentoring, and technical depth necessary to become a successful and influential systems engineer.

PROBLEMS 1.1 Explain what is meant by the statement “Systems engineering is focused on the system as a whole.” State what characteristics of a system you think this statement implies, and how they apply to systems engineering. 1.2 Discuss the difference between engineered complex systems and complex systems that are not engineered. Give three examples of the latter. Can you think of systems engineering principles that can also be applied to non‐ engineered complex systems? 1.3 For each of the following areas, list and explain how at least two major technological advances/breakthroughs occurring since 2010 that have radically changed them. In each case, explain how the change was effected. (a) Transportation (b) Communication (c) Financial management

30

Systems Engineering and  The  World of  Modern Systems

(d) Manufacturing (e) Distribution and sales (f) Entertainment (g) Medical care 1.4 What characteristics of an airplane would you attribute to the system as a whole rather than to a collection of its parts? Explain why. 1.5 List four pros and cons (two of each) of incorporating some of the latest technology into the development of a new complex system. Give a specific example of each. 1.6 Systems engineers have been described as being an advocate for the whole system. Given this statement, which stakeholders should the systems engineer advocate the most? Obviously, there are many stakeholders and the systems engineer must be concerned with most, if not all, of them. Therefore, rank your answer in priority order  –  which stakeholder is the most important to the systems engineer; which is second; which is third? 1.7 Explain the advantages and disadvantages of introducing systems concepts to secondary students in order to encourage them to pursue STEM careers. 1.8 Select a very large complex system of system example and explain how the engineering systems approach could provide useful solutions that would have wide acceptance across many communities. 1.9 Discuss the use of difference systems engineering process models in terms of their optimal use for various systems developments. Is one model significantly better than another?

REFERENCES Noguchi, R.A. (2016). Lessons Learned and Recommended Best Practices from Model‐Based Systems Engineering (MBSE) Pilot Projects. Aerospace Corporation. International Council on Systems Engineering, IEEE Computer Society, Systems Engineering Research Center. Guide to the Systems Engineering Book of Knowledge. https://www. sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_(SEBoK) (accessed 1 January 2019).

FURTHER READING Blanchard, B. and Fabrycky, W. (2013). System Engineering and Analysis, 5e. Prentice Hall. Buede, D. and Miller, W.D. (2016). The Engineering Design of Systems: Models and Methods, 3e. Wiley. Hitchins, D.K. (2007). Systems Engineering: A 21st Century Systems Methodology. Wiley, Chapters 5 and 8.

FURTHER READING

31

Institute of Industrial and Systems Engineers. https://www.iise.org/Home (accessed 1 January 2019). Kasser, J. and Mackley, T. (2008). Applying systems thinking and aligning it to systems engineering. INCOSE International Symposium 18 (1): 1389–1405. Sage, A.P. and Armstrong, J.E. Jr. (2000). Introduction to Systems Engineering. Wiley, Chapter 3. Shortell, T.M. (ed.) (2015). INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 4e. Wiley.

2 STRUCTURE OF COMPLEX SYSTEMS

2.1  SYSTEM ELEMENTS AND INTERFACES The need for a systems engineer to attain a broad knowledge of the several interacting disciplines involved in the development of a complex system raises the question of how deep that understanding needs to be. Clearly, it cannot be as deep as the knowledge possessed by the specialists in these areas. Yet, it must be sufficient to recognize such factors as program risks, technological performance limits, and interfacing requirements, and to make trade‐off analyses among design alternatives. Obviously, the answers depend on specific cases. However, it is possible to provide an important insight by examining the structural hierarchy of modern systems. Such an examination reveals the existence of identifiable types of the building blocks that make up the large majority of systems and represent the lower working level of technical understanding that the systems engineer must have in order to do the job. This is the level at which technical trade‐offs affecting system capabilities must be worked out and at which interface conflicts must be resolved in order to achieve a balanced design

Systems Engineering Principles and Practice, Third Edition. Alexander Kossiakoff, Samuel J. Seymour, David A. Flanigan, and Steven M. Biemer. © 2020 John Wiley & Sons, Inc. Published 2020 by John Wiley & Sons, Inc.

33

34

STRUCTURE OF  COMPLEX SYSTEMS

across the entire system. The nature of these building blocks in their context as fundamental system elements and their interfaces and interactions are discussed in the ensuing sections.

2.2  HIERARCHY OF COMPLEX SYSTEMS In order to understand the scope of systems engineering and what a systems engineer must learn to carry out the responsibilities involved in guiding the engineering of a complex system, it is necessary to define the general scope and structure of that system. Yet, the definition of a “system” is inherently applicable to different levels of aggregation of complex interacting elements. For example, a telephone substation, with its distributed lines to the area that it serves, can be properly called a “system.” Hotel and office building switchboards, with their local lines, may be called “subsystems,” and the telephone instruments may be called “components” of the system. At the same time, the substation may be regarded as a subsystem of the city telephone system, and that, in turn, to be a subsystem of the national telephone system. In another example, a commercial airliner certainly qualifies to be called a “system,” with its airframe, engines, controls, and so on, being subsystems. The airliner may also be called a subsystem of the air transportation system, which consists of the air terminal, air traffic control, and other elements of the infrastructure in which the airliner operates. Thus, it is often said that every system is a subsystem of a higher‐level system, and every subsystem may itself be regarded as a system. The above relationships have given rise to terms such as “super‐systems” to refer to overarching systems like the wide‐area telephone system and the air transportation system. In networked military systems, the term “system of systems” has been coined to describe integrated distributed sensor and weapon systems. This nomenclature has migrated to the commercial world as well; however, the use and definition of the term vary by area and specialty.

Model of a Complex System While learning the fundamentals of systems engineering, this ambiguity of the scope of a “system” may be confusing. Therefore, for the purpose of illustrating the typical scope of a systems engineer’s responsibilities, it is useful to create a more specific model of a typical system. As will be described later, the technique of modeling is one of the basic tools of systems engineering, especially in circumstances where unambiguous and quantitative facts are not readily available. In the present instance, this technique will be used to construct a model of a typical complex system in terms of its constituent parts. The purpose of this model is to define a relatively simple and readily understood system architecture, which can serve as a point of reference for discussing  the process of developing a new system and the role of systems engineering throughout  the process. While the scope of this model does not extend to that of

35

HIERARCHY OF  COMPLEX SYSTEMS

“­ super‐systems” or “system of systems,” it is representative of the majority of systems that are developed by an integrated acquisition process. By their nature, complex systems have a hierarchical structure in that they consist of a number of major interacting elements, generally called subsystems, which themselves are composed of more simple functional entities, and so on, down to primitive elements such as gears, transformers, or light bulbs, usually referred to as parts. Commonly used terminology for the various architectural levels in the structure of systems is confined to the generic system and subsystem designation for the uppermost levels and parts for the lowest. For reasons that will become evident later in this section, the system model as defined in this book will utilize two additional intermediate levels, which will be called components and subcomponents. While some models use one or two more intermediate levels in their representation of systems, these five have proven to be sufficient for the intended purpose. Definition of  System Levels.  Table  2.1 illustrates the above characterization of the hierarchical structure of the system model. In this diagram, four representative system types employing advanced technology are listed horizontally, and successive levels of subdivisions within each system are arranged vertically. In describing the various levels in the system hierarchy depicted in the figure, it was noted previously that the term system as commonly used does not correspond to TABLE 2.1.  System Design Hierarchy Systems Communications systems

Information systems

Material processing systems

Aerospace systems

Subsystems Signal networks

Databases

Material preparation

Engines

Components Signal receivers

Data displays

Databases programs

Power transfer

Material reactors

Thrust generators

Gear trains

Reactive valves

Rocket nozzles

Gears

Couplings

Seals

Subcomponents Signal amplifiers

Cathode ray tubes

Library utilities Parts

Transformer

LED

Algorithms

36

STRUCTURE OF  COMPLEX SYSTEMS

a specific level of aggregation or complexity, it being understood that systems may serve as parts of more complex aggregates or super‐systems, and subsystems may themselves be thought of as systems. For the purpose of the ensuing discussion, this ambiguity will be avoided by limiting the use of the term system to those entities that: 1. Possess the properties of an engineered system. 2. Perform a significant useful service with only the aid of human operators and standard infrastructures (e.g. power grid, highways, fueling stations, communication lines). According to the above conditions, a passenger aircraft would fit the definition of a system, as would a personal computer with its normal peripherals of input and output keyboard, display, and so on. The first subordinate level in the system hierarchy defined in Table 2.1 is appropriately called a subsystem, and has the conventional connotation of being a major portion of the system that performs a closely related subset of the overall system functions. Each subsystem may in itself be quite complex, having many of the properties of a system except the ability to perform a useful function in the absence of its companion subsystems. Each subsystem typically involves several technical disciplines (e.g. electronic, mechanical). The term component is commonly used to refer to a range of mostly lower level entities, but in this book, the term component will be reserved to refer to the middle level of system elements described above. Components will often be found to correspond to configuration items (CIs) in government system acquisition notation. The level below the component building blocks is comprised of entities, referred to as subcomponents that perform elementary functions and are composed of several parts. The lowest level, comprised of parts, represents elements that perform no significant function except in combination with other parts. The great majority of parts come in standard sizes and types, and can usually be obtained commercially.

Adaptive Systems In developing responsiveness in each level of the system model, functionality and interactions are constantly influenced by external forces. Adaptive systems change behavior in response to their environment. They are dynamic systems able to evolve to continue to achieve their goals, objectives, and requirements. While similar to agile‐systems discussed earlier, adaptive systems are often related to natural, human, or social systems. The design and development of adaptive systems must accommodate indirect effects on components and systems building blocks as well as incorporate learning behavior based on use with autonomous‐like characteristics. Systems engineers should also consider adaptive change with artificial systems, artificial intelligence systems, neural networks, advance evolutionary software elements, and related components with complex behaviors. When these building blocks support a complex system, there may be many independent elements or agents that interact at

37

HIERARCHY OF  COMPLEX SYSTEMS

each system level, leading to emergent outcomes that are often difficult to predict by looking at the individual interactions. Hence, systems engineers recognize this element of complexity as the overall systems are designed and developed.

Domains of the Systems Engineer and Design Specialist From the above discussion, the hierarchical structure of engineered systems can be used to define the respective knowledge domains of both the systems engineer and the design specialist. The intermediate system components occupy a central position in the system development process, representing elements that are, for the most part, products fitting within the domain of industrial design specialists, who can adapt them to a particular application based on a given set of specifications. The proper specification of components, especially to define performance and ensure compatible interfaces, is the particular task of systems engineering. This means that the systems engineer’s knowledge must extend to the understanding of the key characteristics of components from which the system may be constituted, largely through dialogue and interaction with the design specialists, so that he or she may select the most appropriate types, and specify their performance and interfaces with other components. The respective knowledge domains of the systems engineer and design specialist are shown in Figure 2.1, using the system hierarchy defined above. It shows that the

Systems

Systems engineer

… Subsystems

Signals

Data

Materials

…

Energy

Components Electronic

Electrooptical

Software

Electro mechanical

Mechanical

Thermo mechanical

…

Subcomponents Design specialist

… Parts

Figure 2.1.  Knowledge domains of systems engineer and design specialist.

38

STRUCTURE OF  COMPLEX SYSTEMS

systems engineer’s knowledge needs to extend from the highest level, the system and its environment, down through the middle level of primary system building blocks or components. At the same time, the design specialist’s knowledge needs to extend from the lowest level of parts, up through the components level, at which point their two knowledge domains “overlap.” This is the level at which the systems engineer and the design specialist must communicate effectively, identify and discuss technical problems, and negotiate workable solutions that will not jeopardize either the system design process or the capabilities of the system as a whole. The horizontal boundaries of these domains are deliberately shown as continuity lines in the figure, to indicate that they should be extended as necessary to reflect the composition of the particular system. When a subcomponent or part happens to be critical to the system’s operation, the systems engineer should be prepared to learn enough about its behavior to identify its potential impact on the system as a whole. This is frequently the case in high‐performance mechanical and thermomechanical devices, such as turbines and compressors. Conversely, when the specified function of a particular component imposes unusual demands on its design, the design specialist should call on the systems engineer to reexamine the system‐level assumptions underlying this particular requirement.

2.3  SYSTEM BUILDING BLOCKS Using this system model provides systems engineers with a simple method of partitioning a system along a functional and physical dimension: understanding the functional aspects of the system, then partitioning the system into a physical hierarchy. Each dimensional description of the system can then be decomposed into elements. Below is the description of these two categories of building blocks and a recommended set of elements used in defining the components of each.

Functional Building Blocks: Functional Elements The three basic entities that constitute the media on which systems operate are: Information: the content of all knowledge and communication Material: the substance of all physical objects Energy: which energizes the operation and movement of all active system components. Because all system functions involve a purposeful alteration in some characteristic of one or more of these entities, the latter constitute a natural basis for classifying the principal system functional units. Since information elements are more than twice as populous as the material and energy entities among system functions, it is convenient to subdivide them into two classes: (i) elements dealing with propagating information (e.g. radio signals), to be referred to as signal elements, and (ii) those dealing with

SYSTEM BUILDING BLOCKS

39

stationary information (e.g. computer programs), to be referred to as data elements. The former class is primarily associated with sensing and communications and the latter with analysis and decision processes. This results in a total of four classes of system functional elements: 1. Signal elements, which sense and communicate information. 2. Data elements, which interpret, organize, and manipulate information. 3. Material elements, which provide structure and transformation of materials. 4. Energy elements, which provide energy and motive power. To provide a context for acquainting the student with significant design knowledge peculiar to each of the four broad classes of functional elements, a set of generic functional elements has been defined that represents the majority of important types for each class. To make the selected elements self‐consistent and representative, three criteria may be used to ensure that each element is neither trivially simple nor inordinately complex, and has wide application: 1. Significance: Each functional element must perform a distinct and significant function, typically involving several elementary functions. 2. Singularity: Each functional element should fall largely within the technical scope of a single engineering discipline. 3. Commonality: The function performed by each element can be found in a wide variety of system types. In configuring the individual functional elements, it is noted that regardless of their primary function and classification, their physical embodiments are necessarily built of material, usually controlled by external information, and powered by electricity or some other source of energy. Thus, a television set, whose main function is to process information in the form of a radio frequency signal into information in the form of a TV picture and sound, is built of materials, powered by electricity, and controlled by user‐generated information inputs. Accordingly, it should be expected that most elements in all classes would have information and energy inputs in addition to their principal processing inputs and outputs. The above process converges on a set of 23 functional elements, 5 or 6 in each class. These are listed in the middle column of Table 2.2. The function of the class as a whole is shown in the left column, and typical applications that might embody the individual elements are listed in the right column. It should be noted that the above classification is not meant to be absolute, but is established solely to provide a systematic and logical framework for discussing the properties of systems at the levels of importance to systems engineers. Fundamentally, the functional design of any system may be defined by conceptually combining and interconnecting the identified functional elements along with

40

STRUCTURE OF  COMPLEX SYSTEMS

TABLE 2.2.  System Functional Elements Class function

Element function

Applications

Signal – generate, transmit, distribute, and receive signals used in passive or active sensing and in communications

Input signal Transmit signal Transduce signal Receive signal Process signal Output signal

TV camera FM radio transmitter Radar antenna Radio receiver Image processor

Data – analyze, interpret, organize, query, and/or convert data and information into forms desired by the user or other systems

Input data Process data Control data Control processing Store data Output data Display data

Keyboard Computer CPU Operating system Word processor Printer

Material – provide system structural support or enclosure, or transform the shape, composition, or location of material substances

Support material Store material React material Form material Join material Control position

Airframe Shipping container Autoclave Milling machine Welding machine Servo actuator

Energy – provide and convert energy or propulsive power to the system

Generate thrust Generate torque Generate electricity Control temperature Control motion

Turbojet engine Reciprocating engine Solar cell array Refrigerator Auto transmission

perhaps one or two very specialized elements that might perform a unique function in certain system applications so as to logically derive the desired system capabilities from the available system inputs. In effect, the system inputs are transformed and processed through the interconnected functions to provide the desired system outputs.

Physical Building Blocks: Components System physical building blocks are the physical embodiments of the functional elements, consisting of hardware and software. Consequently, they have the same distinguishing characteristics of significance, singularity, and commonality, and are at the same level in the system hierarchy, generally one level below a typical subsystem, and two levels above a part. They will be referred to as component elements or simply as components. The classes into which the component building blocks have been categorized are based on the different design disciplines and technologies that they represent. In total, 31 different component types were identified and grouped into 6 categories, as shown in Table 2.3. The table lists the category, component name, and the functional element(s)

41

SYSTEM BUILDING BLOCKS

TABLE 2.3.  Component Design Elements Category

Component

Functional element(s)

Electronic

Receiver Transmitter Data processor Signal processor Communications processors Special electronic equipment

Receive signal Transmit signal Process data Process signal Process signal/data Various

Electro‐optical

Optical sensing device Optical storage device Display device High‐energy optics device Optical power generator

Input signal Store data Output signal/data Form material Generate electricity

Electromechanical

Inertial instrument Electric generator Data storage device Transducer Data input/output device

Input data Generate electricity Store data Transduce signal Input/output data

Mechanical

Framework Container Material processing machine Material reactor Power transfer device

Support material Store material Form/join material React material Control motion

Thermomechanical

Rotary engine Jet engine Heating unit Cooling unit Special energy source

Generate torque Generate thrust Control temperature Control temperature Generate electricity

Software

Operating system Application Support software Firmware

Control Control Control Control

system processing processing system

with which it is associated. As in the case of functional elements, the component names are indicative of their primary function, but in this case represent things rather than processes. Many of these represent devices that are in widespread use. The systems engineer’s concern with the implementation of the functional elements within components is related to a different set of factors than those associated with the initial functional design itself. Here, the predominant issues are reliability, form and fit, compatibility with the operational environment, maintainability, producibility, testability, safety, and cost, along with the requirement that product design does not violate the integrity of the functional design. The depth of the systems engineer’s understanding of the design of individual components needs to extend to the place where the system‐level

42

STRUCTURE OF  COMPLEX SYSTEMS

significance of these factors may be understood, and any risks, conflicts, and other potential problems addressed. The required extent and nature of such knowledge varies widely according to the type of system and its constitution. A systems engineer dealing with an information system can expect to concentrate largely on the details of the software and user aspects of the system, while considering mainly the external aspects of the hardware components, which are usually standard (always paying special attention to component interfaces). At another extreme, an aerospace system such as an airplane consists of a complex and typically nonstandard assemblage of hardware and software operating in a highly dynamic and often adverse environment. Accordingly, an aerospace systems engineer needs to be knowledgeable about the design of system components to a considerably more detailed level so as to be aware of the potentially critical design features before they create reliability, producibility, or other problems during the product engineering, test, and operational stages.

Common Building Blocks An important and generally unrecognized observation resulting from an examination of the hierarchical structure of a large variety of systems is the existence of an intermediate level of elements of types that recur in a variety of systems. Devices such as signal receivers, data displays, torque generators, containers, and numerous others perform significant functions used in many systems. Such elements typically constitute product lines of commercial organizations, which may configure them for the open market or customize them to specifications to fit a complex system. In Table 2.1, the above elements are situated at the third or middle level, and are referred to by the generic name component. Referring back to Table 2.1, it is noted that as one moves up through the hierarchy of system element levels, the functions performed by those in the middle or component level are the first that provide a significant functional capability, as well as being found in a variety of different systems. For this reason, the types of elements identified as components in the table were identified as basic system building blocks. Effective systems engineering therefore requires a fundamental understanding of both the functional and physical attributes of these ubiquitous system constituents. To provide a framework for gaining an elementary knowledge base of system building blocks, a set of models has been defined to represent commonly occurring system components. This section is devoted to the derivation, classification, interrelationships, and common examples of the defined system building blocks.

Applications of System Building Blocks The system building block model described above may be useful in several ways: 1. The categorization of functional elements into the four classes of signal, data, material, and energy elements can help suggest what kind of actions may be appropriate to achieve required operational outcomes.

THE SYSTEM ENVIRONMENT

43

2. Identifying the classes of functions that need to be performed by the system may help group the appropriate functional elements into subsystems, and thus facilitate functional partitioning and definition. 3. Identifying the individual functional building blocks may help define the nature of the interfaces within and between subsystems. 4. The interrelation between the functional elements and the corresponding one or more physical implementations can help visualize the physical architecture of the system. 5. The commonly occurring examples of the system building blocks may suggest the kinds of technology appropriate to their implementation, including possible alternatives. 6. For those specialized in software and unfamiliar with hardware technology, the relatively simple framework of four classes of functional elements and six classes of physical components should provide an easily understood organization of hardware domain knowledge.

2.4  THE SYSTEM ENVIRONMENT The system environment may be broadly defined as everything outside of the system that interacts with the system. The interactions of the system with its environment form the main substance of system requirements. Accordingly, it is important at the outset of system development to identify and specify in detail all of the ways in which the system and its environment interact. It is the particular responsibility of the systems engineer to understand not only what these interactions are, but also their physical basis, to make sure that the system requirements accurately reflect the full range of operating conditions.

System Boundaries To identify the environment in which a new system operates, it is necessary to identify the system’s boundaries precisely, that is, to define what is inside the system and what is outside. Since we are treating systems engineering in the context of a system development project, the totality of the system will be taken as that of the product to be developed. Although defining the system boundary seems almost trivial at first glance, in practice, it is very difficult to identify what is part of the system, and what is part of the environment. Many systems have failed due to miscalculations and assumptions about what is internal and what is external. Moreover, different organizations tend to define boundaries differently, even with similar systems. Fortunately, several criteria are available to assist in determining whether an entity should be defined as part of a system: •

Developmental control: does the system developer have control over the entity’s development? Can the developer influence the requirements of the entity, or are

44

STRUCTURE OF  COMPLEX SYSTEMS

•

• •

requirements defined outside of the developer’s sphere of influence? Is funding part of the developer’s budget, or is it controlled by another organization? Operational control: once fielded, will the entity be under the operational control of the organization that controls the system? Will the tasks and missions ­performed by the entity be directed by the owner of the system? Will another organization have operational control at times? Functional allocation: In the functional definition of the system, is the systems engineer “allowed” to allocate functions to the entity? Unity of purpose: Is the entity dedicated to the system’s success? Once fielded, can the entity be removed without objection by another entity?

Systems engineers have made mistakes by defining entities as part of the system when in fact the span of control (as understood by the above criteria) was indeed small. And typically, either during development or operations, the entity was not available to perform its assigned functions or tasks. One of the basic choices required early is to determine whether human users or operators of a system are considered part of the system or are external entities. In a majority of cases, the user or operator should be considered external to the system. The system developer and owner rarely have sufficient control over operators to justify their inclusion in the system. When operators are considered external to the system, the systems engineer and the developer will focus on the operator interface, which is critical to complex systems. From another perspective, most systems cannot operate without the active participation of human operators exercising decision and control functions. In a functional sense, the operators may well be considered to be integral parts of the system. However, to the systems engineer, the operators constitute elements of the system environment, and impose interface requirements that the system must be engineered to accommodate. Accordingly, in our definition, the operators will be considered to be external to the system. As noted earlier, many, if not most, complex systems can be considered as parts of larger systems. An automobile operates on a network of roads, and is supported by an infrastructure of service stations. However, these are not changed to suit a new automobile. A spacecraft must be launched from a complex gantry, which performs the fueling and flight preparation functions. The gantry, however, is usually part of the launch complex and not part of the spacecraft’s development. In the same manner, the electrical power grid is a standard source of electricity, which a data‐processing system may utilize. Thus, the super‐systems identified in the above examples need not be considered in the engineering process as part of the system being developed, but as an essential element in its operational environment, and to the extent required to assure that all interfacing requirements are correctly and adequately defined. Systems engineers must also become involved in interface decisions affecting designs of both their own and an interfacing system. In the example of a spacecraft launched from a gantry, some changes to the information handling and perhaps other

45

THE SYSTEM ENVIRONMENT

functions of the gantry may well be required. In such instances, the definition of common interfaces and any associated design issues would need to be worked out with engineers responsible for the launch complex.

System Boundaries: The Context Diagram An important communications tool available to the systems engineer is the context diagram. This tool effectively displays the external entities and their interactions with the system, and instantly allows the reader to identify those external entities. Figure 2.2 shows a generic context diagram. This type of diagram is known as a black box diagram, in that the system is represented by a single geographical figure in the center, without any detail. Internal composition or functionality is hidden from the reader. The diagram consists of three components: 1. External entities. These constitute all entities in which the system will interact. Many of these entities can be considered as sources for inputs into the system, and destinations of outputs from the system. 2. Interactions. These represent the interactions between the external entities and the system, and are represented by arrows. Arrowheads represent the direction or flow of a particular interaction. While double‐headed arrows are allowed, single‐headed arrows communicate clearer information to the reader. Thus, the engineer should be careful when using two‐directional interactions – make sure

External entity

Activity

External entity

Materials

Data

Data

The system

Materials

External entity Data

Activity Energy

Data

External entity Figure 2.2.  Context diagram.

Signals

External entity

46

STRUCTURE OF  COMPLEX SYSTEMS

the meanings of your interactions are clear. Regardless, each interaction (arrow) is labeled to identify what is being passed across the interface. The diagram depicts the common types of interactions that a context diagram typically contains. In an actual context diagram, these interactions would be labeled with the specific interactions, not the notional words used above. The labels need to be sufficiently detailed to communicate meaning, but abstract enough to fit into the diagram. Thus, words such as “data” or “communications” are to be avoided in the actual diagram since they convey little meaning. 3. The system. This is the single geographical figure mentioned already. Typically, this is an oval, circle, or rectangle in the middle of the figure with only the name of the system within. No other information should be present. We can categorize what can be passed across these external interfaces by utilizing our definitions of the four basic elements listed above. Using these elements, and adding one additional element, we can form five categories: • • • • •

Data Signals Materials Energy Activities

Thus, a system interacts with its environment (and specifically, the external entities) by accepting and providing either one of the first four elements or by performing an activity that influences the system or the environment in some manner. Constructing a diagram such as the system context diagram can be invaluable in communicating the boundary of the system. The picture clearly and easily identifies the external interfaces needed and provides a short description of what is being passed into and out of the system – providing a good pictorial of the system’s inputs and outputs. Figure  2.3 provides a simple example using a typical automobile as the system. Although the system is rather simple, it nicely illustrates all five types of interfaces. Four external entities are identified: users (to include the driver and passengers), the maintainer (which could be a user; but because of his specialized interactions with the system, is listed separately), an energy source, and the environment. Most systems will interact with these four external entity types. Of course, many other entities may interact with a system as well. The user provides a multitude of inputs to the system, including various commands and controls as well as actions, such as steering and braking. Materials are also passed to the system: cargo. In return, several outputs are passed from the automobile back to the user, including various status indications on the state of the system. Additionally, an activity is performed: entertainment, representing the various forms of entertainment available in today’s automobile. Finally, cargo is returned to the users when desired.

47

THE SYSTEM ENVIRONMENT

• Status of auto. states • Entertainment • Temperature-controlled air • Cargo Users • • • • • • • • • •

Maintainer • Parts • Request signals

Steering Braking Acceleration Light commands Window commands Horn activation Security commands Temperature controls Entertainment controls Cargo

Energy source

• Diagnostics data • Worn-out parts Automobile

• Support • Resistance • Weather Gasoline

• Heat • Siren • Exhaust • Light

Environment

Figure 2.3.  Context diagram for an automobile.

Other entities also interact with the system. The maintainer must provide a request for diagnostics data, typically in the form of signals passed to the auto via an interface. Diagnostics data are returned along with the exchange of parts. The last two external entities represent somewhat specialized entities: an energy source and the ubiquitous environment. In the automobile case, the energy source provides gasoline to the automobile. This energy source can be one of many types: electric, a gasoline pump at a station, or a small container with a simple nozzle. The environment requires some special consideration, if for no other reason than it includes everything not specifically contained in the other external entities. So in some respects, the environment entity represents “other.” In our example, the automobile will generate heat and exhaust in its typical operation. Additionally, a siren and light from various light bulbs, horns, and signals will also radiate from the auto. The environment is also a source of many inputs, such as physical support, air resistance, and weather. It takes some thought to identify the inputs, outputs, and activities that are part of the system  –  environment interaction. The creator of this diagram could have really gone “overboard” and specified temperature, pressure, light, humidity, and a number of other factors in this interaction. This brings up an interesting question: what do we include in listing the interactions between the system and the external entity? For that matter, how do we know whether an external entity should be included in our diagram?

48

STRUCTURE OF  COMPLEX SYSTEMS

Fortunately, there is a simple answer to this: if the interaction is important for the design of the system, then it should be included. In our automobile case, physical support is important for our design, and will influence the type of transmission, steering, and tires. So we include “support” in our diagram. Temperature, humidity, pressure, etc., will be a factor; but we are not sure about their importance to design, so we group these characteristics under “weather.” This does not mean that the automobile will be designed for all environmental conditions, only that we are not considering all conditions in our design. We should have an idea of the environmental conditions from the requirements, and therefore, we can determine whether they should be in our context diagram. Output from the system to the environment also depends on whether it will influence the design. The automobile will in fact output many things into the environment: heat, smells, texture, colors… and especially carbon dioxide as part of the exhaust! But which of these influence our design? Four will be major influences: heat, noise from the siren, exhaust, and light. Therefore, we include only those for now, and omit the others. We can always go back and update the context diagram (in fact, we should as we progress through both the systems engineering process and the system development life cycle). The system context diagram is a very simple, yet powerful tool to identify, evaluate, and communicate the boundaries of our system. Therefore, it becomes the first tool we introduce in this book. More will follow that will eventually provide the systems engineer with the collection needed to adequately develop the system. Note that in MBSE, style guides and modeling practices in a given organization should facilitate the development of the system context diagram. For example, a guideline that any entity defined on a use case diagram (one of the diagram types that is part of SysML, the Systems Modeling Language) must be a part property in the system context that ensures complete traceability between the behavioral explorations and the context. As the context is further defined in the system model, inputs and outputs can be modeled, and flows can be established between elements (associated with specific interfaces). Validation rules and automated quality checks can ensure this consistency, allowing the systems engineer to focus on cognitive tasks instead of the “administrivia” of cross‐checking diagrams and other content.

Types of Environmental Interactions To understand the nature of the interactions of a system with its surroundings, it is convenient to distinguish between primary and secondary interactions. The former involve elements that interact with the system’s primary functions, that is, represent functional inputs, outputs, and controls; the latter relate to elements that interact with the system in an indirect nonfunctional manner, such as physical supports, ambient temperature, and so on. Thus, the functional interactions of a system with its environment include its inputs and outputs, and human control interfaces. Operational maintenance may be considered a quasi‐functional interface. Threats to the system are those

49

THE SYSTEM ENVIRONMENT

entities that deny or disrupt the system’s ability to perform its activities. The physical environment includes support systems, system housing, and shipping, handling, and storage. Each of these is briefly described below. Inputs and  Outputs. The primary purpose of most systems is to operate on external stimuli and/or materials in such a manner as to process these inputs in a useful way. For a passenger aircraft, the materials are the passengers, their luggage, and fuel, and the aircraft’s function is to transport the passengers and their belongings to a distant destination rapidly, safely, and comfortably. Figure  2.4 illustrates some of the large variety of interactions that a complex system has with its operating environment for the case of a passenger aircraft.

Rain

Winds

Turbulence mands

Flight com

Beacon interrog ation

Flight environment

ILS beacon Shock and vibration

Landing environment

Power

Support environment

Passengers

Luggage

People and payload interface

Maintenance environment

Figure 2.4.  Environments of a passenger airliner.

Fuel

50

STRUCTURE OF  COMPLEX SYSTEMS

System Operators. As noted previously, virtually all systems, including automated systems, do not operate autonomously but are controlled to some degree by human operators in performing their function. For the purposes of defining the systems engineer’s task, the operator is part of the system’s environment. The interface between the operator and the system (human–machine interface) is one of the most critical of all because of the intimate relationship between the control exercised by the operator and the performance of the system. It is also one of the most complex to define and test. Operational Maintenance.  The requirements for system readiness and operational reliability relate directly to the manner in which it is to be maintained during its operating life. This requires that the system be designed to provide access for monitoring, testing, and repair requirements that are frequently not obvious at the outset, but nevertheless must be addressed early in the development process. Thus, it is necessary to recognize and explicitly provide for the maintenance environment. Threats. This class of external entities can be manmade or natural. Clearly, weather could be considered a threat to a system exposed to the elements. For example, when engineering naval systems, the salt water environment becomes a corrosive element that must be taken into consideration. Threats can also be manmade. For example, a major threat to an automatic teller machine (ATM) would be the thief, whose goal might be access to the stored cash. System threats need to be identified early to design countermeasures into the system. Support Systems.  Support systems are that part of the infrastructure on which the system depends for carrying out its mission. As illustrated in Figure 2.4, the airport, the air traffic control system, and their associated facilities constitute the infrastructure in which an individual aircraft operates, but which is also available to other aircraft. These are parts of the system of systems (SoS) represented by the air transportation system, but for an airplane, they represent standard available resources. Two examples of common support systems that have been mentioned previously are the electric power grids, which distribute usable electric power throughout the civilized world, and the network of automobile filling stations and their suppliers. In building a new airplane, automobile, or other system, it is necessary to provide interfaces that are compatible with and capable of utilizing these support facilities. System Housing. Most stationary systems are installed in an operating site, which itself imposes compatibility constraints on the system. In some cases, the installation site provides protection for the system from the elements, such as variations in temperature, humidity, and other external factors. In other cases, such as installations on board ship, these platforms provide the system’s mechanical mounting, but otherwise may expose the system to the elements, as well as subject it to shock, vibration, and other rigors.

INTERFACES AND  INTERACTIONS

51

Shipping and Handling Environment.  Many systems require transport from the manufacturing site to the operating site, which imposes special conditions for which the system must be designed. Typical of these are extreme temperatures, humidity, shock, and vibration, which are sometimes more stressful than those characteristic of the operating environment. It may be noted that the impact of the latter categories of environmental interactions are addressed mainly in the engineering development stage.

2.5  INTERFACES AND INTERACTIONS Interfaces: External and Internal The previous section described the different ways in which a system interacts with its environment, including other systems. These interactions all occur at various boundaries of the system. Such boundaries are called the system’s external interfaces. Their definition and control are a particular responsibility of the systems engineer because they require knowledge of both the system and its environment. Proper interface control is crucial for successful system operation. A major theme of systems engineering is accordingly the management of interfaces. This involves: 1. Identification and description of interfaces as part of system concept definition. 2. Coordination and control of interfaces to maintain system integrity during engineering development, production, and subsequent system enhancements. Inside the system, the boundaries between individual components constitute the system’s internal interfaces. Here, again, the definition of internal interfaces is the concern of the systems engineer because they fall between the responsibility boundaries of engineers concerned with the individual components. Accordingly, their definition and implementation must often include consideration of design trade‐offs that impact on the design of both components. Particular complexity for the systems engineer requiring close attention are the interfaces that occur in networked systems. Often, they are hidden in embedded software or secondary interactions that are not easily visible beyond the system components. Unexpected failures or the introduction of rogue software during operations can further challenge systems designs in information systems needing protection from undesired external interfaces.

Interactions Interactions between two individual elements of the system are effected through the interface connecting the two. Thus, the interface between a car driver’s hands and the steering wheel enables the driver to guide (interact with) the car by transmitting a force

52

STRUCTURE OF  COMPLEX SYSTEMS

Function Aileron deflection command

Aileron deflection

Move aileron

Functional interaction Aileron deflection = 3 deg. per deg. of stick motion

Aileron

Receiver/decoder Physicl interfaces

Drive motor

Controller/encoder Transmitter

Power amp Antenna

Aileron

Radio–controlled air vehicle

Figure 2.5.  Functional interactions and physical interfaces.

that turns the steering wheel and thereby the car’s wheels. The interfaces between the tires of the car and the road both propel and steer the car by transmitting driving traction to the road, and also help cushion the car body from the roughness of the road surface. The above examples illustrate how functional interactions (guiding or propelling the car) are effected by physical interactions (turning the steering wheel or the drive wheels) that flow across (physical) interfaces. Figure 2.5 illustrates the similar relations between physical interfaces involved in steering an air vehicle and the resulting functional interactions. An important and sometimes less than adequately addressed external system interaction occurs during system maintenance. This activity necessarily requires access to a number of vital system functions for testing purposes. Such access calls for the provision of special test points of the system, which can be sampled externally with a minimum of manipulation. In some complex systems, an extensive set of built‐in tests (BIT) is incorporated, which may be exercised while the system is in its operational status. The definition of such interfaces is also the concern of the systems engineer.

Interface Elements To systematize the identification of external and internal interfaces, it is convenient to distinguish three different types: 1. Connectors, which facilitate the transmission of electricity, fluid, force, and so on, between components. 2. Isolators, which inhibit such interactions.

53

INTERFACES AND  INTERACTIONS

TABLE 2.4.  Examples of Interface Elements Type

Electrical

Mechanical

Hydraulic

Human– machine

Interaction medium

Current

Force

Fluid

Information

Connectors

Cable Switch

Joint coupling

Pipe valve

Display Control panel

Isolator

RF shield insulator

Shock mount bearing

Seal

Cover

Converter

Antenna A/D converter

Gear train piston

Reducing valve Pump

Window Keyboard

3. Converters, which alter the form of the interaction medium. These interfaces are embodied in component parts or subcomponents, which can be thought of as interface elements. Table 2.4 lists a number of common examples of interface elements of each of the three types, for each of four interaction media: electrical, mechanical, hydraulic, and human. The table brings out several points worthy of note: 1. The function of making or breaking a connection between two components (i.e. enabling or disabling an interaction between them), must be considered as an important design feature, often involved in system control. 2. The function of connecting nonadjacent system components by cables, pipes, levers, and so on, is often not part of a particular system component. Despite their inactive nature, such conducting elements must be given special attention at the system level to ensure that their interfaces are correctly configured. 3. The relative simplicity of interface elements belies their critical role in ensuring system performance and reliability. Experience has shown that a large fraction of system failures occurs at interfaces. Assuring interface compatibility and reliability is a particular responsibility of the systems engineer.

MBSE and Interfaces MBSE, in general (and SysML, in particular), supports the effective and efficient management and definition of interfaces. Competent modelers can leverage the modeling tools to prohibit illegal flows, detect inconsistencies, and generate detailed interface specifications (whether in the model or as exported documents). This ensures consistency and eliminates a common source of error in document‐intensive methods (in which engineers are required to read and analyze disconnected documents without automated support). It is particularly well suited to integrate and analyze subsystem models (perhaps created by different suppliers or departments). Connecting the ­ subsystem model

54

STRUCTURE OF  COMPLEX SYSTEMS

i­nterfaces and executing quality check to ensure flows out of subsystem A are inputs in subsystem B (and vice versa) is relatively trivial (and significantly less effort than performing this task manually). It should be noted that structuring the models correctly to support these analyses is not trivial…but the payoff in fidelity and reduced subsequent effort is why MBSE is INCOSE’s desired path forward for systems engineering.

2.6  COMPLEXITY IN MODERN SYSTEMS Earlier in the chapter, we described the system hierarchy – how systems are subdivided into subsystems, then components, subcomponents, and finally, parts (see Table 2.1). And as modern systems grow in complexity, the number, diversity, and complexity of these lower level subsystems, components, and parts increase. Furthermore, the interactions between these entities also increase in complexity. Systems engineering principles, and their applied practices, are designed to deal with this complexity. Increasingly, a single system may be, or become, a part of a larger entity. While there are many terms currently in use today to describe this super‐system concept, the term SoS seems to be accepted by a wide variety of organizations. Other terms are found in the literature – some meaning the same thing, some having different connotations. Details will be provided in Chapter 20. Another concept – Enterprise systems engineering – refers to the application of systems engineering principles and practices to engineering systems that are part of an enterprise and will be discussed in Chapter 21. Then, there are families of systems that are related in various ways. This next section provides a basic introduction to the engineering of entities that are considered “above,” or more complex, than single systems: systems of systems, enterprises, and families.

System of Systems For our purposes, we will use two definitions to describe what is meant by a SoS. Both come from the US Department of Defense (DoD 2008). The first is the simplest: A set or arrangement of systems that results when independent and useful systems are integrated into a larger system that delivers unique capabilities.

In essence, anytime a set of independently useful systems is integrated together to provide an enhanced capability beyond that of the sum of the individual systems’ capabilities, we have a SoS. Of course, the level of integration could vary significantly. At one end of the spectrum, a SoS could be completely integrated from the earliest development phases, where the individual systems, while able to operate independently, are almost exclusively designed for the SoS. At the other end of the spectrum, multiple systems could be loosely joined for a limited purpose and time span to perform a needed

55

COMPLEXITY IN  MODERN SYSTEMS

mission, with no more than an agreement of the owners of each system. Thus, a method to capture this range of integration is necessary to fully describe the different nuances of systems of systems. As the reader might surmise, engineering and architecting a SoS can be different than engineering and architecting a single system, especially for the two middle categories. System of systems engineering (SoSE) can be different because of the unique attributes of a SoS.

Enterprise Systems Engineering SoSE, by its nature, increases the complexity of developing single systems. However, it does not represent the highest level of complexity. In fact, just as Table 2.1 presented a hierarchy with the system at the apex, we can expand this hierarchy, and go beyond systems of systems, to an enterprise. Figure 2.6 depicts this hierarchy. Above a SoS lies the enterprise, which typically consists of multiple systems of systems within its structure. Furthermore, an enterprise may consist of a varied collection of system types, not all of which are physical. For instance, an enterprise includes human or social systems that must be integrated with physical systems. Formally, an enterprise is “anything that consists of people, processes, technology, systems and other resources across organizations and locations interacting with each other and their environment to achieve a common mission or goal.” The level of ­interaction between these entities varies, just as component systems within a SoS do. And many entities fit into this definition. Almost all mid‐size to large organizations would satisfy this definition. In fact, suborganizations of some large corporations would themselves be defined as an enterprise.

Enterprise

System of systems System Subsystem Components

Figure 2.6.  Pyramid of system hierarchy.

56

STRUCTURE OF  COMPLEX SYSTEMS

Government agencies and departments would also fit into this definition. And finally, large social and physical structures, such as cities or nations, satisfy the definition. The source of complexity in enterprise systems engineering is primarily the integration of a diversity of systems and processes. The enterprise typically includes the following components that must be integrated together under the inherent uncertainty of today’s enterprise: • • • • • • • • • • •

Business strategy and strategic planning Business processes Enterprise services Governance Technical processes People management and interactions Knowledge management Information technology infrastructure and investment Facility and equipment management Supplies management Data and information management

Enterprise systems engineering refers to the application of systems engineering principles and practices to engineering systems that are part of an enterprise. Developing the individual component systems of the enterprise is known by this term. Another broader term has also emerged: Enterprise engineering. This term, with the “systems” omitted, typically refers to the architecting, development, implementation, and operation of the enterprise as a whole. Some have used the terms interchangeably; however, the two terms refer to different levels of abstraction. The reason that enterprise systems engineering is deemed more complex than SoSE is that many of the components of an enterprise involve one or more systems of systems. Therefore, the enterprise could be considered an integration of multiple systems of systems. Just as new tools and techniques are being developed for SoSE applications, so too are tools, methods, and techniques being developed for this relatively young field.

Family of Systems In some circumstances, it is helpful to identify a particular group of systems. The members of a family of systems (FoS) have a common characteristic but the grouping does not provide new capability and they may not be connected into a whole. A FoS may be a product line or a set of systems used in a common environment. The set of systems would be a group of independent (not interdependent) systems that can be

SUMMARY

57

arranged or interconnected in various ways. The FoS could be a set of manned or unmanned vehicles, a group of space satellites, or a family of network systems. Such arrangements would not present new properties or capabilities and they lack the synergy of a SoS.

2.7 SUMMARY System Building Blocks and Interfaces The need for a systems engineer to attain a broad knowledge of the several interacting disciplines involved in the development of a complex system raises the question of how deep that understanding needs to be.

Hierarchy of Complex Systems Complex systems may be represented by a hierarchical structure in that they are composed of subsystems, components, subcomponents, and parts. The domain of the systems engineer extends down through the component level and extends across several categories. In contrast, the domain of the design specialist extends from the part level up through the component level, but typically within a single technology area or discipline.

System Building Blocks System building blocks are at the level of components and are the basic building blocks of all engineered systems characterized by both functional and physical ­attributes. These building blocks are characterized by performing a distinct and significant function, and are singular  – they are within the scope of a single engineering discipline. Functional elements are functional equivalents of components and are categorized into four classes by operating medium: • • • •

Signal elements, which sense and communicate information. Data elements, which interpret, organize, and manipulate information. Material elements, which provide structure and process material. Energy elements, which provide energy or power.

Components are physical embodiment of functional elements, which are categorized into six classes by materials of construction: • •

Electronic Electro‐optical

58

STRUCTURE OF  COMPLEX SYSTEMS

• • • •

Electromechanical Mechanical Thermomechanical Software

System building block models can be useful in identifying actions capable of achieving operational outcomes, facilitating functional partitioning and definition, identifying subsystem and component interfaces, and visualizing the physical architecture of the system.

The System Environment The system environment, that is everything outside the system that interacts with it, includes: (i) system operators (part of system function but outside the delivered system); (ii) maintenance, housing, and support systems; (iii) shipping, storage, and handling; (iv) weather and other physical environments; and (v) threats.

Interfaces and Interactions Interfaces are a critical systems engineering concern, which effect interactions between components and can be classified into three categories: connect, isolate, or convert interactions. They require identification, specification, coordination, and control. Moreover, test interfaces typically are provided for integration and maintenance.

Complexity in Modern Systems Each system is always part of a larger entity. At times, this larger entity can be classified as a separate system in itself (beyond simply an environment, or “nature”). These situations are referred to as “systems of systems.” They tend to exhibit seven distinct characteristics: operational independence of the individual system, managerial independence of the individual system, geographic distribution, emergent behavior, evolutionary development, self‐organization, and adaptation. Enterprise systems engineering is similar in complexity, but focuses on an organizational entity. Since an enterprise involves social systems as well as technical systems, the complexity tends to become unpredictable.

PROBLEMS 2.1 Referring to Table 2.1, list a similar hierarchy consisting of a typical subsystem, component, subcomponent, and part for (i) a terminal air traffic control system, (ii) a personal computer system, (iii) an automobile, and (iv) an electric power plant. For each system you need only name one example at each level. 2.2 Give three key activities of a systems engineer that require technical knowledge down to the component level. Under what circumstances should the systems

REFERENCE

59

engineer need to probe into the subcomponent level for a particular system component? 2.3 Referring to Figure 2.1, describe in terms of levels in the system hierarchy, the knowledge domain of a design specialist. In designing or adapting a component for a new system, what typical characteristics of the overall system and of other components must the design specialist understand? Illustrate by an example. 2.4 The last column of Table  2.2 lists examples of the applications of the 23 functional elements. List one other example application than the one listed for three elements in each of the four classes of elements. 2.5 Referring to Figure  2.4, for each of the environments and interfaces illustrated, (i) list the principal interactions between the environment and the aircraft, (ii) the nature of each interaction, and (iii) describe how each affects the system design. 2.6 For a passenger automobile, partition the principal parts into four subsystems and their components. (Do not include auxiliary functions such as environmental or entertainment.) For the subsystems, group together components concerned with each primary function. For defining the components, use the principles of significance (performs an important function), singularity (largely falls within a simple discipline), and commonality (found in a variety of system types). Indicate where you may have doubts. Draw a block diagram relating the subsystems and components to the system and to each other. 2.7 In the cases selected in answering Problem 2.5, list the specific component interfaces that are involved in the above interactions. 2.8 Draw a context diagram for a standard coffee maker. Make sure to identify all of the external entities, and label all of the interactions. 2.9 Draw a context diagram for a standard washing machine. Make sure to identify all of the external entities, and label all of the interactions. 2.10 In a context diagram, “Maintainer” is typically an external entity, providing both activities (i.e. “maintenance”) and materials (e.g. spare parts) to the system, and the system providing diagnostic data back to the maintainer. Give some examples of systems that would require a maintainer in the list of external entities. 2.11 List the test interfaces and BIT indicators in your automobile that are available to the user (do not include those only available to a mechanic).

REFERENCE Department of Defense (2008). Systems Engineering Guide for Systems of Systems. DUSD (A&T) and OSD(AT&L).

60

STRUCTURE OF  COMPLEX SYSTEMS

FURTHER READING Buede, D. (2016). The Engineering Design of Systems: Models and Methods, 3e. Wiley. Jamshidi, M. (ed.) (2008a). System of Systems Engineering: Innovations for the 21st Century. Wiley. Jamshidi, M. (2008b). Systems of Systems Engineering: Principles and Applications. CRC Press. Maier, M. and Rechtin, E. (2009). The Art of Systems Architecting. CRC Press. Sage, A. and Biemer, S. (2007). Processes for system family architecting, design and integration. IEEE Systems Journal 1 (1): 5–16.

3 THE SYSTEM DEVELOPMENT PROCESS

3.1  SYSTEMS ENGINEERING THROUGH THE SYSTEM LIFE CYCLE As was described in Chapter 1, modern engineered systems come into being in response to societal needs or because of new opportunities offered by advancing technology, or both. The evolution of a particular new system from the time when a need for it is recognized and a feasible technical approach is identified, through its development and introduction into operational use, is a complex effort, which will be referred to as the system development process. This chapter is devoted to describing the basic system development process and how systems engineering is applied at each step of this process. A typical major system development exhibits the following characteristics: • • • •

It It It It

is a complex effort. meets an important user need. usually requires several years to complete. is made up of many interrelated tasks.

Systems Engineering Principles and Practice, Third Edition. Alexander Kossiakoff, Samuel J. Seymour, David A. Flanigan, and Steven M. Biemer. © 2020 John Wiley & Sons, Inc. Published 2020 by John Wiley & Sons, Inc.

61

62

THE SYSTEM DEVELOPMENT PROCESS

• • •

It involves several different disciplines. It is usually performed by several organizations. It has a specific schedule and budget.

The development and introduction into use of a complex system inherently requires increasingly large commitments of resources as it progresses from concept, through engineering, production, and operational use. Further, the introduction of new t­ echnology inevitably involves risks, which must be identified and resolved as early as possible. These factors require that the system development be conducted in a step‐by‐step manner, in which the success of each step is demonstrated, and the basis for the next one validated, before a decision is made to proceed to the next step.

3.2  SYSTEM LIFE CYCLE The term “system life cycle” is commonly used to refer to the stepwise evolution of a new system from concept through development and on to production, operation, and ultimate disposal. As the type of work evolves from analysis in the early conceptual phases to engineering development and testing, to production and operational use, the role of systems engineering changes accordingly. As noted previously, the organization of this book is designed to follow the structure of the system life cycle, so as to more clearly relate systems engineering functions to their roles in specific periods during the life of the system. This chapter presents an overview of the system development process to create a context for the more detailed discussion of each step in the later chapters.

Development of a Systems Engineering Life Cycle Model System life cycle models have evolved significantly over the past three decades. Furthermore, the number of models has grown as additional unique and custom applications were explored. Additionally, software engineering has spawned a significant number of development models that have been adopted by the systems community. The end result is that there is no single life cycle model that (i) is accepted worldwide and (ii) fits every possible situation. Various standards organizations, government agencies, and engineering communities have published their particular models or frameworks that can be used to construct a model. Therefore, adopting one model to serve as an appropriate framework for this book was simply not prudent. Fortunately, all life cycle models subdivide the system life into a set of basic steps that separate major decision milestones. Therefore, the derivation of a life cycle model to serve as an appropriate framework for this book had to meet two primary objectives. First, the steps in the life cycle had to correspond to the progressive transitions in the principal systems engineering activities. Secondly, these steps had to be capable of being mapped into the principal life cycle models in use by the systems engineering

63

SYSTEM LIFE CYCLE

community. The derived model will be referred to as the “systems engineering life cycle,” and will be based on three different sources: the Department of Defense (DoD) Acquisition Management model (DoD 5000.2), the International model ISO/IEC 15288, and the National Society of Professional Engineers (NSPE) model. Department of  Defense Acquisition Management Model. The United States has been in the forefront of developing large‐scale complex military systems such as warships, airplanes, tanks, and command and control systems. To manage the risks in the application of advanced technology, and to minimize costly technical or management failures, the DoD has evolved comprehensive system acquisition guidelines, which are contained in the DoD 5000 series of directives. The DoD life cycle model, which reflects the acquisition guidelines, is displayed in Figure 3.1. It consists of five phases: material solution analysis, technology development, engineering and manufacturing development, production and deployment, and operations and support. The two activities of user need determination and technology opportunities and resources are considered to be part of the process but are not included in the formal portion of the acquisition cycle. The model is tailored toward managing large, complex system development efforts where reviews and decisions are needed at key events throughout the life cycle. The major reviews are referred to as milestones and are given letter designations: A, B, and C. Each of the three major milestones is defined with respect to entry and exit conditions. For example, at Milestone A, a requirements document needs to be approved by a military oversight committee before a program will be allowed to transition to the • The material development decision precedes entry into any phase of the acquisition management system • Entrance criteria met before entering phase • Evolutionary acquisition or single step to full capability

User needs Technology opportunities and resources

A Material solution analysis

B Technology development

Material development decision

(Program initiation)

PostPDR A

Presystems acquisition , decision point

IOC

FOC

Production and deployment

Operations and support

C

Engineering and manufacturing development PostCDR A

LRIP/IOT and E

FRP decision review

Systems acquisition , milestone review

Sustainment

, decision point if PDR is not conducted before milestone B PDR, preliminary design review CDR, critical design review LRIP, low-rate initial production FRP, full-rate production IOT and E, initial operational test and evaluation IOC, initial operational capability FOC, full operational capability

Figure 3.1.  DoD system life cycle model.

64

THE SYSTEM DEVELOPMENT PROCESS

next phase. In addition to milestones, the process contains four additional decision points: material development decision (MDD), preliminary design review (PDR), critical design review (CDR), and full rate production (FRP) decision review. Therefore, DoD management is able to review and decide on the future of the program at up to seven major points within the life cycle. International ISO/IEC 15288 Model. The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) issued a systems engineering standard designated ISO/IEC 15288, Systems engineering – System life cycle processes. The basic model is divided into 6 stages and 25 primary processes. The processes are intended to represent a menu of activities that may need to be accomplished within the basic stages. The ISO standard purposely does not align the stages and processes. The six basic stages are: concept, development, production, utilization, support, and retirement. Professional Engineering Model. The NSPE model is tailored to the development of commercial systems. This model is mainly directed to the development of new products, usually resulting from technological advances (“technology driven”). Thus, the NSPE model provides a useful alternative view to the DoD model of how a typical system life cycle may be divided into phases. The NSPE life cycle is partitioned into six stages: conceptual, technical feasibility, development, commercial validation and production preparation, full‐scale production, and product support. Systems Engineering Life Cycle Model.  In structuring a life cycle model that corresponded to significant transitions in systems engineering activities throughout the system’s active life, it was found most desirable to subdivide the life cycle into three broad stages, and partition these into eight distinct phases. This structure is shown in Figure 3.2 and will be discussed below. The names of these subdivisions were chosen to reflect the primary activities occurring in each part of the process. Inevitably, some of these names are the same or similar to the names of corresponding parts of one or more of the existing life cycles. Software Life Cycle Models.  The system life cycle stages and their constituent phases represented by the above models apply to the majority of complex systems, including those containing significant software functionality at the component level. However, software‐intensive systems, in which software performs virtually all the functionality, as in modern financial systems, airline reservation systems, the World Wide Web, and other information systems, generally follow life cycles similar in form but often involving iteration and prototyping. Chapter 14 describes the differences between software and hardware, discusses the activities involved in the principal stages of software system development, and contains a section dealing with examples of software system life cycles representing software‐intensive systems. However, with that exception, the systems engineering life cycle model, as will be discussed in Chapters

65

SYSTEM LIFE CYCLE

Concept development

Engineering development

Needs analysis

Advanced development

Production

Engineering design

Concept exploration

Concept definition

Post-development

Operations and support

Integration and evaluation

Figure 3.2.  System life cycle model.

4 through 14, provides a natural framework for describing the evolution of systems engineering activity throughout the active life of all engineered complex systems.

Systems Engineering Life Cycle Stages As described above, and illustrated in Figure 3.2, the systems life cycle model consists of three stages, the first two encompassing the developmental part of the life cycle, and the third the post‐development period. These stages mark the more basic transitions in the system life cycle, as well as the changes in the type and scope of effort involved in systems engineering. In this book, these stages will be referred to as (i) The concept development stage, which is the initial stage of the formulation and definition of a system concept perceived to best satisfy a valid need; (ii) the engineering development stage, which covers the translation of the system concept into a validated physical system design meeting the operational, cost, and schedule requirements; and (iii) the post‐development stage, which includes the production, deployment, operation, and support of the system throughout its useful life. The names for the individual stages are intended to correspond generally to the principal type of activity characteristic of these stages. The concept development stage, as the name implies, embodies the analysis and planning that is necessary to establish the need for a new system, the feasibility of its realization, and the specific system architecture perceived to best satisfy the user needs. Systems engineering plays the lead role in translating the operational needs into a technically and economically feasible system concept. Maier and Rechtin (2009) call this process “systems architecting,” using the analogy of the building architect translating

66

THE SYSTEM DEVELOPMENT PROCESS

a client’s needs into plans and specifications that a builder can bid on and build from. The level of effort during this stage is generally much smaller than in subsequent stages. The principal objectives of the concept development stage are to: 1. Establish that there is a valid need (and market) for a new system that is ­technically and economically feasible. 2. Explore potential system concepts and formulate and validate a set of system performance requirements. 3. Select the most attractive system concept, define its functional characteristics, and develop a detailed plan for the subsequent stages of engineering, ­production, and operational deployment of the system. 4. Develop any new technology called for by the selected system concept, and validate its capability to meet requirements. The engineering development stage corresponds to the process of engineering the system to perform the functions specified in the system concept, in a physical embodiment that can be produced economically and maintained and operated successfully in its operational environment. Systems engineering is primarily concerned with guiding the engineering development and design, defining and managing interfaces, developing test plans, and determining how discrepancies in system performance uncovered during test and evaluation (T&E) should best be rectified. The main bulk of the engineering effort is carried out during this stage. The principal objectives of the engineering development stage are to: 1. Perform the engineering development of a prototype system satisfying the requirements of performance, reliability, maintainability, and safety. 2. Engineer the system for economical production and use, and demonstrate its operational suitability. The post‐development stage consists of activities beyond the system development period, but still requires significant support from systems engineering, especially when unanticipated problems requiring urgent resolution are encountered. Also, continuing advances in technology often require in‐service system upgrading, which may be just as dependent on systems engineering as the concept and engineering development stages. The post‐development stage of a new system begins after the system successfully undergoes its operational T&E, sometimes referred to as Acceptance Testing, and is released for production and subsequent operational use. While the basic development has been completed, systems engineering continues to play an important supporting role in this effort. The relations among the principal stages in the system life cycle are illustrated in the form of a flow chart in Figure 3.3. The figure shows the principal inputs and outputs

67

SYSTEM LIFE CYCLE

Operational deficiencies

System functional specifications

Concept development

Technological opportunities

System production specifications

Engineering development

Defined system concept(s)

Operations and maintenance documentation

Post-development

Production system

Installed operational system

Figure 3.3.  Principal stages in system life cycle.

of each of the stages. The legends above the blocks relate to the flow of information in the form of requirements, specifications, and documentation, beginning with operational needs. The inputs and outputs below the blocks represent the stepwise evolution of the design representations of an engineered system from concept to the operational system. It is seen that both the documentation and design representations become increasingly complete and specific as the life cycle progresses. A future section “System Materialization” is devoted to a discussion of the factors involved in this process. Example: Development Stages of a New Commercial Aircraft.  To illustrate the application of this life cycle model, consider the evolution of a new passenger aircraft. The concept development stage would include the recognition of a market for a new aircraft, the exploration of possible configurations, such as number, size, and location of engines, body dimensions, wing platform, and so on, leading to the selection of the optimum configuration from the standpoint of production cost, overall efficiency, passenger comfort, and other operational objectives. The above decisions would be based largely on analyses, simulations, and functional designs, which collectively would constitute justifications for selecting the chosen approach. The engineering development stage of the aircraft life cycle begins with the acceptance of the proposed system concept and a decision by the aircraft company to proceed with its engineering. The engineering effort would be directed to validating the use of any unproven technology, implementing the system functional design into hardware and software components, and demonstrating that the engineered system meets the user needs. This would involve building prototype components, integrating them into an operating system, and evaluating it in a realistic operational environment. The post‐development stage includes the acquisition of production tooling and test equipment, production of the new aircraft, customizing it to fit requirements of different

68

THE SYSTEM DEVELOPMENT PROCESS

customers, supporting regular operations, fixing any faults discovered during use, and periodically overhauling or replacing engines, landing gear, and other highly stressed components. Systems engineering plays a limited but vital supporting and problem‐ solving role during this stage.

Concept Development Phases While the three stages described above constitute the dominant subdivisions of the system life cycle, each of these stages contains recognizable subdivisions with characteristically different objectives and activities. In the case of large programs, formal decision points also mark most of these subdivisions, similar to those marking the transition between stages. Furthermore, the roles of systems engineering tend to differ significantly among these intermediate subdivisions. Hence, to understand how the evolution of the system life cycle relates to the systems engineering process, it is useful to develop a model of its structure down to this second level of subdivision. The concept development stage of the systems engineering life cycle encompasses three phases: needs analysis, concept exploration, and concept definition. Figure 3.4 shows these phases, their principal activities, and inputs and outputs in a format analogous to Figure 3.3. Needs Analysis Phase. The needs analysis phase defines the need for a new system. It addresses the questions: “Is there a valid need for a new system?” and “Is there a practical approach to satisfying such a need?” These questions require a critical examination of the degree to which current and perceived future needs cannot be satisfied by physical or operational modification of available means, as well as whether or not available technology is likely to support the increased capability desired. In many cases the beginning of the life of a new system evolves from continuing analysis of Operational deficiencies

System operational effectiveness

System performance requirements

System functional specifications

Needs analysis

Concept exploration

Concept definition

System studies Technology assessment Operational analysis

Requirements analysis Concept synthesis Feasibility experiments

Analysis of alternatives Functional architecture Physical architecture

Technological opportunities

System capabilities

Candidate system concepts

Figure 3.4.  Concept development phases of system life cycle.

Defined system concept(s)

SYSTEM LIFE CYCLE

69

operational needs, or innovative product development, without a sharply identified beginning. The output of this phase is a description of the capabilities and operational effectiveness needed in the new system. In many ways, this description is the first iteration of the system itself, albeit, a very basic conceptual model of the system. The reader should take note of how the “system” evolves from this very beginning phase throughout its life cycle. Although we would not yet call this description a set of requirements, they certainly are the forerunner of what will be defined as official requirements. The US DoD community refers to this early description as an initial capability description. Several classes of tools and practices exist to support the development of the system capabilities and effectiveness description. Most fall into two categories of mathematics, known as operational analysis and operations research. However, technology assessments and experimentation are an integral part of this phase, and will be used in conjunction with mathematical techniques. Concept Exploration Phase. This phase examines potential system concepts in answering the questions: “What performance is required of the new system to meet the perceived need?” and “Is there at least one feasible approach to achieving such performance at an affordable cost?” Positive answers to these questions set a valid and achievable goal for a new system project prior to expending a major effort on its development. The output of this phase includes our first “official” set of requirements, typically known as system performance requirements. What we mean by “official” is that a contractor or agency can be measured against this set of required capabilities and performance. In addition to an initial set of requirements, this phase produces a set of candidate system concepts. Note the plural – more than one alternative is important to explore and understand the range of possibilities in satisfying the need. A variety of tools and techniques are available in this phase and range from process methods (e.g. requirements analysis) to mathematically based (e.g. decision support methods) to expert judgment (e.g. brainstorming). Initially, the number of concepts can be quite large from some of these techniques; however, the set quickly reduces to a manageable set of alternatives. It is important to understand and “prove” the feasibility of the final set of concepts that will become the input of the next phase. Concept Definition Phase.  The concept definition phase selects the preferred concept. It answers the question: “What are the key characteristics of a system concept that would achieve the most beneficial balance between capability, operational life, and cost?” To answer this question, a number of alternative concepts must be considered and their relative performance, operational utility, development risk, and cost must be compared. Given a satisfactory answer to this question, a decision to commit major resources to the development of the new system can be made. The output is really two perspectives on the same system: a set of functional specifications that describe what the system must do, and how well, and a selected system

70

THE SYSTEM DEVELOPMENT PROCESS

concept. The latter can be in two forms. If the complexity of the system is rather low, a simple concept description is sufficient to communicate the overall design strategy for the development effort to come. However, if the complexity is high, a simple concept description is insufficient, and a more comprehensive system architecture is needed to communicate the various perspectives of the system. Regardless of the depth of description, the concept needs to be described in several ways, primarily from a functional perspective and from a physical perspective. Further perspectives may very well be needed if complexity is particularly high. The tools and techniques available fall into two categories: analysis of alternatives and systems architecting. As noted previously, in commercial projects (NSPE model), the first two phases are often considered as a single pre‐project effort. This is sometimes referred to as a “feasibility study” and its results constitute a basis for making a decision as to whether or not to invest in a concept definition effort. In the defense acquisition life cycle, the second and third phases are combined, but the part corresponding to the second phase is performed by the government, resulting in a set of system performance requirements, while that corresponding to the third can be conducted by a government‐contractor team or performed by several contractors competing to meet the above requirements. In any case, before reaching the engineering development stage, only a fractional investment has usually been made in the development of a particular system, although some years and considerable effort may have been spent in developing a firm understanding of the operational environment and in exploring relevant technology at the subsystem level. The ensuing stages are where the bulk of the investment will be required.

Engineering Development Phases Figure  3.5 shows the activities, inputs, and outputs of the constituent phases of the engineering development stage of the system life cycle in the same format as used in Figure 3.3. These are referred to as advanced development, engineering design, and integration and evaluation. Advanced Development Phase. The success of the engineering development stage of a system project is critically dependent on the soundness of the foundation laid during the concept development stage. However, since the conceptual effort is largely analytical in nature and carried out with limited resources, significant unknowns invariably remain that are yet to be fully defined and resolved. It is essential that these “unknown unknowns” be exposed and addressed early in the engineering stage. In particular, every effort must be made to minimize the number of as yet undisclosed problems prior to translating the functional design and associated system requirements into engineering specifications for the individual system hardware and software elements. The advanced development phase has two primary purposes: (i) the identification and reduction of development risks and (ii) the development of system design

71

SYSTEM LIFE CYCLE

System functional specifications

System design specifications

Test and evaluation plan

System production specifications

Advanced development

Engineering design

Integration and evaluation

Risk management subsystem definition component specs

Component engineering component test specialty engineering

System integration system test operational evaluation

Defined system concept(s)

Validated development model

Engineered components

Production system

Figure 3.5.  Engineering development phases in system life cycle.

s­pecifications. The advanced development phase is especially important when the system concept involves advanced technology not previously used in a similar application, or where the required performance stresses the system components beyond proven limits. It is devoted to designing and demonstrating the undeveloped parts of the system, to proving the practicality of meeting their requirements, and to laying the basis for converting the functional system requirements into system specifications and component design requirements. Systems engineering is central to the decisions of what needs to be validated and how, and to the interpretation of the results. This phase corresponds to the defense acquisition phase called “engineering and manufacturing development,” once referred to as “demonstration and validation.” When the risks of using unproven technology are large, this phase is often contracted separately, with contracts for the remaining engineering phase contingent on its success. Matching the purpose of this phase, the two primary outputs are the design specifications and a validated development model. The specifications are a refinement and evolution of the earlier function specifications. The development model is the final outcome of a very comprehensive risk management task – where those unknowns mentioned above have been identified and resolved. This is what we mean when we use the adjective “validated.” The systems engineer needs to be convinced that this system can be designed and manufactured before transitioning from this phase. Therefore, all risks at this phase must be rated as manageable before proceeding. Modern risk management tools and techniques are essential to reduce and ultimately mitigate risks inherent in the program. As these risks are managed, the level of definition continues to migrate down, from the system to the subsystem. Furthermore, a set of specifications for the next level of decomposition, at the component level, occurs. In all of these cases, both experimental models and simulations are often employed at this stage to validate component and subsystem design concepts at minimum cost.

72

THE SYSTEM DEVELOPMENT PROCESS

Engineering Design Phase.  The detailed engineering design of the system is performed during this phase. Because of the scale of this effort, it is usually punctuated by formal design reviews. An important function of these reviews is to provide an opportunity for the customer or user to obtain an early view of the product, monitor its cost and schedule, and provide valuable feedback to the system developer. While issues of reliability, producibility, maintainability, and other “ilities” have been considered in previous phases, they are of paramount importance in the ­engineering design phase. These types of issues are typically known as “specialty engineering.” Since the product consists of a set of components capable of being integrated and tested as a system, the systems engineer is responsible for ensuring that the engineering design of the individual components faithfully implements the functional and compatibility requirements, and for managing the engineering change process to maintain interface and configuration control. The tasks of this phase deals with converting the component specifications into a set of component designs. Of course, testing these components is essential to occur immediately after design, or in some cases, concurrently with design. One additional task is performed during this phase, the refinement of the system T&E plan. We use the term refinement to distinguish between the initiation and continuation. The T&E plan is initially developed much earlier in the life cycle. At this phase, the T&E plan is largely finished, using the knowledge gained from the previous phases. The two primary outputs are the T&E plan and an engineered prototype. The prototype can take many forms, and should not be thought of in the same way as we think of a software prototype. This phase may produce a prototype that is virtual, physical, or a hybrid, depending on the program. For example, if the system is an ocean‐going cargo vessel, the prototype at this stage may be a hybrid of virtual and physical mockups. A full‐scale prototype of a cargo ship may not be possible or prudent at this phase. On the other hand, if the system is a washing machine, a full‐scale prototype may be totally appropriate. Modern computer‐aided design tools are available as design engineers perform their trade. System models and simulations are also updated as designs are finalized and tested. Integration and Evaluation Phase.  The process of integrating the engineered components of a complex system into a functioning whole, and evaluating the system’s operation in a realistic environment, is nominally part of the engineering design process because there is no formal break in the development program at this point. However, there is a basic difference between the role and responsibility of systems engineering during the engineering design of the system elements and that during the integration and evaluation process. Since this book is focused on the functions of systems ­engineering, the system integration and evaluation process is treated as a separate phase in the system life cycle. It is important to realize that the first time a new system can be assembled and evaluated as an operating unit is after all its components are fully engineered and built.

SYSTEM LIFE CYCLE

73

It is at this stage that all the component interfaces must fit and component interactions must be compatible with the functional requirements. While there may have been prior tests at the subsystem level or at the level of a development prototype, the integrity of the total design cannot be validated prior to this point. It should also be noted that the system integration and evaluation process often requires the design and construction of complex facilities to closely simulate operational stimuli and constraints and measure the system’s responses. Some of these facilities may be adapted from developmental equipment, but the magnitude of the task should not be underestimated. The outputs of this phase are twofold: (i) the specifications to guide the manufacturing of the system, typically called the system production specifications (sometimes referred to as the production baseline), and (ii) the production system itself. The latter includes everything necessary to manufacture and assemble the system, and may include a prototype system. Modern integration techniques and T&E tools, methods, facilities, and principles are available to assist and enable the engineers in these tasks. Of course, before full‐ scale production can occur, the final production system needs to be verified and validated through an evaluation within the operational environment or a sufficient surrogate for the operational environment.

Post‐Development Phases Production Phase. The production phase is the first of the two phases comprising the post‐development stage, which are exactly parallel to the defense acquisition phases of “production and deployment” and “operations and support.” No matter how effectively the system design has been engineered for production, problems inevitably arise during the production process. There are always unexpected disruptions beyond the control of project management; for example, a strike at a vendor’s plant, unanticipated tooling difficulties, bugs in critical software programs, or an unexpected failure in a factory integration test. Such situations threaten costly disruptions in the production schedule that require prompt and decisive remedial action. Systems engineers are often the only persons qualified to diagnose the source of the problem and find an effective solution. Often, a systems engineer can devise a “workaround” that solves the problem for a minimal cost. This means that an experienced cadre of systems engineers intimately familiar with the system design and operation needs to be available to support the production effort. Where specialty engineering assistance may be required, the systems engineers are often best qualified to decide who should be called in and when. Operation and  Support Phase.  In the operation and support phase, there is an even more critical need for systems engineering support. The system operators and maintenance personnel are likely to be only partially trained in the finer details of system operation and upkeep. While specially trained field engineers generally provide

74

THE SYSTEM DEVELOPMENT PROCESS

support, they must be able to call on experienced systems engineers in case they encounter problems beyond their own experience. Proper planning for the operational phase includes provision of a logistic support system and training programs for operators and maintenance personnel. This planning should have major participation from systems engineering. There are always unanticipated problems that arise after the system becomes operational that must be recognized and included in the logistic and training systems. Very often, the instrumentation required for training and maintenance is itself a major component of the system to be delivered. Most complex systems have lifetimes of many years, during which they undergo a number of minor and major upgrades. These upgrades are driven by evolution in the system mission, as well as by advances in technology that offer opportunities to improve operation, reliability, or economy. Computer‐based systems are especially subject to periodic upgrades, whose cumulative magnitude may well exceed the initial system development. While the magnitude of an individual system upgrade is a fraction of that required to develop a new system, it usually entails a great many complex decisions requiring the application of systems engineering. Such an enterprise can be extremely complex, especially in the conceptual stage of the upgrade effort. Anyone that has undergone a significant home alteration, such as the addition of one bedroom and bath, will appreciate the unexpected difficulty of deciding just how this can be accomplished in such a way as to retain the character of the original structure and yet realize the full benefits of the added portion, as well as be performed for an affordable price.

3.3  EVOLUTIONARY CHARACTERISTICS OF THE DEVELOPMENT PROCESS The nature of the system development process can be better understood by considering certain characteristics that evolve during the life cycle. Four of these are described in the sections below. Section “The Predecessor System” discusses the contributions of an existing system on the development of a new system that is to replace it. Section “System Materialization” describes a model of how a system evolves from concept to an engineered product. Section “The Participants” describes the composition of the system development team and how it changes during the life cycle. Section “Requirements and Specifications” describes how the definition of the system evolves in terms of system requirements and specifications as the development progresses.

The Predecessor System The process of engineering a new system may be described without regard to its resemblance to current systems meeting the same or similar needs. The entire concept and all of its elements are often represented as starting with a blank slate, a situation that is virtually never encountered in practice.

EVOLUTIONARY CHARACTERISTICS OF  THE DEVELOPMENT  PROCESS

75

In the majority of cases, when new technology is used to achieve radical changes in such operations as transportation, banking, or armed combat, there exist predecessor systems. In a new system, the changes are typically confined to a few subsystems, while the existing overall system architecture and other subsystems remain substantially unchanged. Even the introduction of automation usually changes the mechanics but not the substance of the process. Thus, with the exception of such breakthroughs as the first generation of nuclear systems or of spacecraft, a new system development can expect to have a predecessor system that can serve as a point of departure. A predecessor system will impact development of a new system in three ways: 1. The deficiencies of the predecessor system are usually recognized, often being the driving force for the new development. This focuses attention on the most important performance capabilities and features that must be provided by the new system. 2. If the deficiencies are not so serious as to make the current system worthless, its overall concept and functional architecture may constitute the best starting point for exploring alternatives. 3. To the extent that substantial portions of the current system perform their function satisfactorily, and are not rendered obsolete by recent technology, great cost savings (and risk reduction) may be achieved by utilizing them with minimum change. Given the above, the average system development will almost always be a hybrid, in that it will combine new and undemonstrated components and subsystems with previously engineered and fully proven ones. It is a particular responsibility of systems engineering to ensure that the decisions as to which predecessor elements to use, which to reengineer, which to replace by new ones, and how these are to be interfaced are made through careful weighing of performance, cost, schedule, and other essential criteria.

System Materialization The steps in the development of a new system can be thought of as an orderly progressive “materialization” of the system from an abstract need to an assemblage of actual components cooperating to perform a set of complex functions to fulfill that need. To illustrate this process, Table  3.1 traces the growth of materialization throughout the phases of the project life cycle. The rows of the table represent the levels of system subdivision, from the system itself at the top to the part level at the bottom. The columns are successive phases of the system life cycle. The entries are the primary activities at each system level and phase, and their degree of materialization. The shaded areas indicate the focus of the principal effort in each phase. It is seen that each successive phase defines (materializes) the next lower level of system subdivision until every part has been fully defined. Examining each row from left to right, say at the component level, it is also seen that the process of definition

TABLE 3.1.  Evolution of System Materialization Through System Life Cycle Concept development

Phase Level System

Subsystem

Needs analysis

Concept exploration

Define system capabilities and effectiveness

Identify, explore, and synthesize concepts

Define selected concept with specifications

Validate concept

Test and evaluate

Define requirements and ensure feasibility

Define functional and physical architecture

Validate subsystems

Integrate and test

Component Subcomponent

Part

76

Engineering development Concept definition

Advanced development

Allocate functions Define to components specifications Visualize

Allocate functions to subcomponents

Engineering design

Design and test Design

Make or buy

Integration and evaluation

Integrate and test

EVOLUTIONARY CHARACTERISTICS OF  THE DEVELOPMENT  PROCESS

77

starts with visualization (selecting the general type of system element), then proceeds to defining its functions (functional design what it must do), and then to its implementation (detailed design how it will do it). The above progression holds true through the engineering design phase, where the components of the system are fully “materialized” as finished system building blocks. In the integration and evaluation phase, the materialization process takes place in a distinctly different way, namely, in terms of the materialization of an integrated and validated operational system from its individual building blocks. It is important to note from Table 3.1 that while the detailed design of the system is not completed until near the end of its development, its general characteristics must be visualized very early in the process. This can be understood from the fact that the selection of the specific system concept requires a realistic estimate of the cost to develop and produce it, which in turn requires a visualization of its general physical implementation as well as its functionality. In fact, it is essential to have at least a general vision of the physical embodiment of the system functions during even the earliest investigations of technical feasibility. It is of course true that these early visualizations of the system will differ in many respects from its final materialization, but not so far as to invalidate conclusions about its practicality. The role of systems architecting fulfills this visualization requirement by providing visual perspectives into the system concept early in the life cycle. As a system project progresses through its life cycle, the products of the architecture are decomposed to ever‐lower levels. At any point in the cycle, the current state of system definition can be thought of as the current system model. Thus, during the concept development stage, the system model includes only the system functional model that is made up entirely of descriptive material, diagrams, tables of parameters, and so on, in combination with any simulations that are used to examine the relationships between system‐level performance and specific features and capabilities of individual system elements. Then, during the engineering development stage, this model is augmented by the gradual addition of hardware and software designs for the individual subsystems and components, leading finally to a completed engineering model. The model is then further extended to a production model as the engineering design is transformed into producible hardware designs, detailed software definition, production tooling, and so on. At every stage of the process, the current system model necessarily includes models of all externally imposed interfaces as well as the internal system interfaces.

The Participants A large project involves not only dozens or hundreds of people but also several different organizational entities. The ultimate user may or may not be an active participant in the project, but plays a vital part in the system’s origin and in its operational life. The two most common situations are when (i) the government serves as the system acquisition agent and user, with a commercial prime contractor supported by subcontractors

78

THE SYSTEM DEVELOPMENT PROCESS

100

Relative resource level

75

Sys Anal – System analysts Sys Arch – System architects Sys Eng – Systems engineers Des Eng – Design engineers (incl. specialty) Integ Eng – Integration engineers Test Eng – Test engineers

Test Eng Test Eng

Integ Eng Test Eng

Integ Eng 50

Des Eng

Des Eng

Des Eng

Sys Eng 25

0

Sys Eng

Integ Eng

Des Eng Sys Eng

Sys Arch

Sys Eng Sys Arch Sys Anal

Sys Arch Sys Anal

Sys Anal

Needs Analysis

Concept Exploration

Concept Definition

Concept Development

Sys Arch

Sys Eng

Sys Eng

Sys Arch

Sys Arch

Engineering Advanced Design Development

Integration and Evaluation

Engineering Development

Figure 3.6.  Principal Participants in Typical Aerospace System Development

as the system developer and producer, and (ii) a commercial company serves as the acquisition manager, system developer, and producer. Other commercial companies or the general public may be the users. The principal participants in each phase of the project are also different. Therefore, one of the main functions of systems engineering is to provide the continuity between successive participating levels in the hierarchy and successive development phases and their participants through both formal documentation and informal communications. A typical distribution of participants in an aerospace system development is shown in Figure 3.6. The height of the columns represents the relative number of engineering personnel involved. The entries are the predominant types of personnel in each phase. It is seen that, in general, participation varies from phase‐to‐phase, with systems engineering providing the main continuity. The principal participants in the early phases are analysts and architects (system and operations/market). The concept definition phase is usually carried out by an expedited team effort, representing all elements necessary to select and document the most cost‐effective system concept for meeting the stated requirements. The advanced development phase usually marks the initial involvement of the system design team that will carry the project through the engineering stage and on into production. It is led by systems engineering, with support from the design and test engineers engaged in the development of components and subsystems requiring development.

EVOLUTIONARY CHARACTERISTICS OF  THE DEVELOPMENT  PROCESS

79

The engineering design phase further augments the effort with a major contribution from specialty engineering (reliability, maintainability, etc.), as well as test and production engineering. For software, this phase involves designers, as well as coders, to the extent that prototyping is employed. The integration and evaluation phase relies heavily on test engineering with guidance from systems engineering and support from design engineers and engineering specialists.

System Requirements and Specifications Just as the system design gradually materializes during the successive steps of system development, so the successive forms of system requirements and specifications become more and more specific and detailed. These start with a set of operational requirements and end with a complete set of production specifications, operation, maintenance, and training manuals and all other information needed to replicate, operate, maintain, and repair the system. Thus, each phase can be thought of as producing a more detailed description of the system: what it does, how it works, and how it is built. Since the above documents collectively determine both the course of the development effort and the form and capabilities of the system as finally delivered, oversight of their definition and preparation is a primary responsibility of systems engineering. This effort must, however, be closely coordinated with the associated design specialists and other involved organizations. The evolution of system requirements and specifications is shown in the second row of Table 3.2 as a function of the phases in the system life cycle. It should be emphasized that each successive set of documents does not replace the versions defined during the previous phases, but rather supplements them. This produces an accumulation rather than a succession of system requirements and other documents. These are “living documents,” which are periodically revised and updated. The necessity for an aggregation of formal requirements and specifications developed during successive phases of the system development can be better understood by recalling the discussion of “Participants” and Figure 3.6. In particular, not only are there many different groups engaged in the development process, but many, if not most, of the key participants change from one phase to the next. This makes it essential that a complete and up‐to‐date description exists that defines what the system must do and also, to the extent previously defined, how it must do it. The system description documents not only lay the basis for the next phase of system design but they also specify how the results of the effort are to be tested in order to validate compliance with the requirements. They provide the information base needed for devising both the production tools and the tools to be used for inspecting and testing the product of the forthcoming phase. The representations of system characteristics also evolve during the development process, as indicated in the second row of Table 3.2. Most of these will be recognized as architecture views and conventional engineering design and software diagrams and

TABLE 3.2.  Evolution of System Representation Concept development Needs analysis

Engineering development

Concept exploration

Concept definition

Advanced development

Engineering design

Integration and evaluation

Documents

System capabilities and effectiveness

System performance requirements

System functional requirements

System design specifications

Design documents

Test plans and evaluation reports

System models

Operational diagrams; mission simulations

System diagrams; high‐level system simulations

Architecture products and views; simulations; mock‐ups

Architecture products and views; detailed simulations; breadboards

Architecture drawings and schematics; engineered components; CAD products

Test setups, simulators, facilities and test articles

80

THE SYSTEMS ENGINEERING METHOD

81

models. Their purpose is to supplement textual descriptions of successive stages of system materialization by more readily understandable visual forms. This is especially important in defining interfaces and interactions among system elements designed by different organizations.

3.4  THE SYSTEMS ENGINEERING METHOD In the preceding sections, the engineering of a complex system was seen to be divisible into a series of steps or phases. Beginning with the identification of an opportunity to achieve a major extension of an important operational capability by a feasible technological approach, each succeeding phase adds a further level of detailed definition (materialization) of the system, until a fully engineered model is achieved that proves to meet all essential operational requirements reliably and at an affordable cost. While many of the problems addressed in a given phase are peculiar to that state of system definition, the systems engineering principles that are employed, and the relations among them, are fundamentally similar from one phase to the next. This fact, and its importance in understanding the system development process, has been generally recognized; the set of activities that tends to repeat from one phase to the next has been referred to in various publications on systems engineering as the “systems engineering process” or the “systems engineering approach,” and is the subject of the sections below. In this book, this iterative set of activities will be referred to as the “systems engineering method.” The reason for selecting the word “method” in place of the more widely used “process” or “approach” is that it is more definitive and less ambiguous. The word “method” is more specific than “process,” having the connotation of an orderly and logical process. Furthermore, the term “systems engineering process” is sometimes used to apply to the total system development. “Method” is also more appropriate than “approach,” which connotes an attitude rather than a process. With all this said, the use of a more common terminology is perfectly acceptable.

Our Systems Engineering Method The systems engineering method can be thought of as the systematic application of the scientific method to the engineering of a complex system. It can be considered as consisting of four basic activities applied successively, as illustrated in Figure 3.7: 1. Requirements analysis 2. Functional definition 3. Physical definition 4. Design validation These steps will vary in their specifics depending on the type of system and the phase of its development. However, there is enough similarity in their operating principles

82

THE SYSTEM DEVELOPMENT PROCESS

that it is useful to describe the typical activities of each step in the method. Such brief descriptions of the activities in the four steps are listed below. Requirements analysis (Problem definition). Typical activities include: • • • •

Assembling and organizing all input conditions, including requirements, plans, milestones, and models from the previous phase. Identifying the “whys” of all requirements in terms of operational needs, ­constraints, environment, or other higher‐level objectives. Clarifying the requirements of what the system must do, how well it must do it, and what constraints it must fit. Correcting inadequacies and quantifying the requirements wherever possible.

Functional definition (Functional analysis and allocation). Typical activities include: • • •

Translating requirements (why) into functions (actions, tasks) that the system must accomplish (what). Partitioning (allocating) requirements into functional building blocks. Defining interactions among functional elements to lay a basis for their ­organization into a modular configuration.

Physical definition (Synthesis, physical analysis, and allocation). Typical activities include:

Need

Requirements analysis Requirements Functional definition Functions Physical definition System model Design validation Solution(s)

Figure 3.7.  Systems engineering method’s top‐level flow diagram.

THE SYSTEMS ENGINEERING METHOD

•

•

•

83

Synthesizing a number of alternative system components representing a variety of design approaches to implementing the required functions, and having the most simple practicable interactions and interfaces among structural subdivisions. Selecting a preferred approach by trading‐off a set of predefined and prioritized criteria (measures of effectiveness, MOE) to obtain the best “balance” among performance, risk, cost, and schedule. Elaborating the design to the necessary level of detail.

Design validation (Verification, evaluation). Typical activities include: • • •

Designing models of the system environment (logical, mathematical, simulated, and physical) reflecting all significant aspects of the requirements and constraints. Simulating or testing and analyzing system solution(s) against environmental models. Iterating as necessary to revise the system model or environmental models, or to revise system requirements if too stringent for a viable solution until the design and requirements are fully compatible.

The elements of the systems engineering method as described above are displayed in the form of a flow diagram in Figure 3.8, which is an expanded view of Figure 3.7. The rectangular blocks are seen to represent the above four basic steps in the method: requirements analysis, functional definition, physical definition, and design validation. At the top are shown inputs from the previous phase, which include requirements, constraints, and objectives. At the left of each block are shown external inputs, such as the predecessor system, system building blocks, and previous analyses. At the upper right of the top blocks and at the very bottom are inputs from systems engineering methodology. The circles inside each block are simplified representations of key processes in that step of the method. The interfacing arrows represent information flow. It is seen that there are feedbacks throughout the process, iteration within the elements as well as to prior elements, and indeed all the way back to the requirements. Each of the elements of the method is described more fully in the remainder of this section.

Requirements Analysis (Problem Definition) In attempting to solve any problem, it is first necessary to understand exactly what is given, and to the extent that it appears to be incomplete, inconsistent, or unrealistic, to make appropriate amplifications or corrections. This is particularly essential in the system development process, where a basic characteristic of systems engineering is that everything is not necessarily what it seems and that important assumptions must be verified before they are accepted as being valid.

84

THE SYSTEM DEVELOPMENT PROCESS

Previous phase

• System model requirements and constraints • Development objectives

Organize and analyze inputs

Predecessor system

Requirements analysis

Clarify, correct, and quantify

Partitioning criteria

Consistent documented requirements Predecessor system Functional building blocks

Functional definition

Define functional interactions

Translate into functions

Functional configuration

Predecessor system • Building blocks • Technology

Synthesize system elements

Excessive requirements

Previous analysis

Select preferred design System model

Design test environment

Trade-off criteria

Physical definition

Measures of effectiveness Design deficiencies

Simulate or test and analyze

Tools and methodologies

Design validation

Next phase

Figure 3.8.  Systems engineering method flow diagram.

Thus, in a system development project, it is the responsibility of systems engineering to thoroughly analyze all requirements and specifications, first in order to understand them vis‐à‐vis the basic needs that the system is intended to satisfy, and then to identify and correct any ambiguities or inconsistencies in the definition of capabilities for the system or system element being addressed.

THE SYSTEMS ENGINEERING METHOD

85

The specific activities of requirements analysis vary as the system development progresses, as the inputs from the previous phase evolve from operational needs and technological opportunities (see Figure 3.3) to increasingly specific representations of requirements and system design. The role of systems engineering is essential throughout, but perhaps more so in the early phases, where an understanding of the operational environment and the availability and maturity of applicable technology are most critical. In later phases, environmental, interface, and other inter‐element requirements are the special province of systems engineering. Organization and Interpretation.  In a well‐structured acquisition process, a new phase of the system life cycle begins with three main inputs, which are defined during or upon completion of the previous phase: 1. The system model, which identifies and describes all design choices made and validated in the preceding phases. 2. Requirements (or specifications) that define the design, performance, and interface compatibility features of the system or system elements to be developed during the next phase. These requirements are derived from previously developed higher‐level requirements, including any refinements and/or revisions introduced during the latest phase. 3. Specific progress to be achieved by each component of the engineering organization during the next phase, including the identification of all technical design data, hardware/software products, and associated test data to be provided. This information is usually presented in the form of a series of interdependent task statements. Clarification, Correction, and  Quantification. It is always difficult to express objectives in unambiguous and quantitative terms, so it is therefore common that stated requirements are often incomplete, inconsistent, and vague. This is especially true if the requirements are prepared by those who are unfamiliar with the process of converting them to system capabilities, or with the origins of the requirements in terms of operational needs. In practice, the completeness and accuracy of these inputs can be expected to vary with the nature of the system, its degree of departure from predecessor systems, the type of acquisition process employed, and the phase itself. The above analysis must include interaction with the prospective users of the system to gain a firsthand understanding of their needs and constraints and to obtain their inputs where appropriate. The result of the analysis may be modifications and amplifications of the requirement documents so as to better represent the objectives of the program or the availability of proposed technological improvements. The end objective is to create a firm basis from which the nature and location of the design changes needed to meet the requirements may be defined.

86

THE SYSTEM DEVELOPMENT PROCESS

Functional Definition (Functional Analysis and Allocation) In the systems engineering method, functional design precedes physical or product design to ensure a disciplined approach to an effective organization (configuration) of the functions and to the selection of the implementation that best balances the desired characteristics of the system (e.g. performance, cost). Translation into Functions.  The system elements that may serve as functional building blocks are briefly discussed in Chapter 1. The basic building blocks are at the component level representing elements that perform a single significant function and deal with a single medium, that is, either signals, data, material, or energy. They, in turn, consist of sub‐elements performing lower‐level functions and aggregate into functional subsystems. Thus, functional design can be thought of as selecting, subdividing, or aggregating functional elements appropriate to the required tasks and level of system materialization (see Table 3.1). Decomposition and allocation of each iterative set of requirements and functions for implementation at the next lower level of system definition is a prime responsibility of systems engineering. This first takes place during the concept development stage as follow‐on to the definition of the system architecture. It includes identification and description of all functions to be provided, along with the associated quantitative requirements to be met by each subsystem, in order that the prescribed system‐level capabilities can in fact be achieved. This information is then reflected in system functional specifications, which serve as the basis for the follow‐on engineering development stage. As part of the advanced development phase, these top‐level subsystem functions and requirements are further allocated to individual system components within each subsystem. This, as noted earlier, is the lowest level in the design hierarchy that is of direct concern to systems engineering, except in special cases where lower‐level elements turn out to be critical to the operation of the system. Trade‐Off Analysis. The selection of appropriate functional elements, as all aspects of design, is an inductive process, in which a set of postulated alternatives are examined and the one judged to be best for the intended purpose is selected. The systems engineering method relies on making design decisions by the use of trade‐off analysis. Trade‐off analysis is widely used in all types of decision making, but in systems engineering, it is applied in a particularly disciplined form, especially in the step of physical definition. As the name implies, trade‐offs involve the comparison of alternatives, which are superior in one or more required characteristics, with those that are superior in others. To ensure that an especially desirable approach is not overlooked, it is necessary to explore a sufficient number of alternative implementations, all defined to a level adequate to enable their characteristics to be evaluated relative to one another. It is also necessary that the evaluation be made relative to a carefully formulated set of criteria or “MOE”. Note that model‐based systems engineering (MBSE) is particularly

THE SYSTEMS ENGINEERING METHOD

87

well suited to support various levels of automated trade studies because relevant information about the system of interest is contained in a model that can exchange information directly with various simulation and analysis tools. Functional Interactions. One of the single most important steps in system design is the definition of the functional and physical interconnection and interfacing of its building blocks. A necessary ingredient in this activity is the early identification of all significant functional interactions and the ways in which the functional elements may be aggregated so as to group strongly interacting elements together and make the interactions among the groups as simple as possible. Such organizations (architectures) are referred to as “modular” and are the key to system designs that are readily maintainable and capable of being upgraded to extend their useful life. Another essential ingredient is the identification of all external interactions and the interfaces through which they affect the system.

Physical Definition (Synthesis or Physical Analysis and Allocation) Physical definition is the translation of the functional design into hardware and software components, and the integration of these components into the total system. In the concept development stage, where all design is still at the functional level, it is nevertheless necessary to visualize or imagine what the physical embodiment of the concept would be like in order to help ensure that the solution will be practically realizable. The process of selecting the embodiment to be visualized is also governed by the general principles discussed below, applied more qualitatively than in the engineering development stage. Synthesis of Alternative System Elements.  The implementation of functional design elements requires decisions regarding the specific physical form that the implementation should take. Such decisions include choice of implementation media, element form, arrangement, and interface design. In many instances, they also offer a choice of approaches, ranging from exploiting the latest technology to relying on proven techniques. As in the case of functional design, such decisions are made by the use of trade‐off analysis. There usually being more choices of different physical implementations than functional configurations, it is even more important that good systems engineering practice be used in the physical definition process. Selection of  Preferred Approach. At various milestones in the system life cycle, selection of a preferred approach, or approaches, will need to be made. It is important to understand that this selection process changes depending on the phase within the life cycle. Early phases may require selecting a several approaches to explore; while later phases may require a down‐select to a single approach. Additionally, the level of decisions evolves. Early decisions relate to the system as a whole; later decisions focus on subsystems and components.

88

THE SYSTEM DEVELOPMENT PROCESS

As stated previously, to make a meaningful choice among design alternatives, it is necessary to define a set of evaluation criteria and establish their relative priority. Among the most important variables to be considered in the physical definition step is the relative affordability or cost of the alternatives, and their relative risk of successful accomplishment. In particular, early focus on one particular implementation concept should be avoided. Risk as a component of trade‐off analysis is basically an estimate of the probability that a given design approach will fail to produce a successful result whether because of deficient performance, low reliability, excessive cost, or unacceptable schedule. If the component risk appears substantial, the risk to the overall project must be reduced (risk abatement) by either initiating an intensive component development effort, by providing a backup using a proven but somewhat less capable component, by modifying the overall technical approach to eliminate the need for the particular component that is in doubt, or, if these fail, by relaxing the related system performance specification. Identifying significantly high‐risk system elements and determining how to deal with them is an essential systems engineering responsibility. Chapter 12 discusses the risk management process and its constituent parts. Proper use of the systems engineering method thus ensures that: 1. All viable alternatives are considered. 2. A set of evaluation criteria is established. 3. The criteria are prioritized and quantified where practicable. Whether or not it is possible to make quantitative comparisons, the final decision should be tempered by judgment based on experience. Interface Definition.  Implicit in the physical definition step is the definition and control of interfaces, both internal and external. Each element added or elaborated in the design process must be properly connected to its neighboring elements and to any external inputs or outputs. Further, as the next lower design level is defined, adjustments to the parent elements will inevitably be required, which must in turn be reflected in adjustments to their previously defined interfaces. All such definitions and readjustments must be incorporated into the model design and interface specifications to form a sound basis for the next level of design.

Design Validation (Verification, Evaluation) In the development of a complex system, even though the preceding steps of the design definition may have been carried out apparently in full compliance with requirements, there still needs to be an explicit validation of the design before the next phase is undertaken. Experience has shown that there are just too many opportunities for undetected errors to creep in. The form of such validation varies with the

THE SYSTEMS ENGINEERING METHOD

89

phase and degree of system materialization, but the general approach is similar from phase to phase. Modeling the System Environment.  To validate a model of the system, it is necessary to create a model of the environment with which the system can interact to see if it produces the required performance. This task of modeling the system environment extends throughout the system development cycle. In the concept development stage, the model is largely functional, although some parts of it may be physical, as when an experimental version of a critical system component is tested over a range of ambient conditions. In later stages of development, various aspects of the environment may be reproduced in the laboratory or in a test facility, such as an aerodynamic wind tunnel or inertial test platform. In cases where the model is dynamic, it is more properly called a simulation, in which the system design is subjected to a time‐varying input to stimulate its dynamic response modes. As the development progresses into the engineering development stage, modeling the environment becomes increasingly realistic, and environmental conditions are embodied in system and component test equipment, such as environmental chambers, or shock and vibration facilities. During operational evaluation testing, the environment is, insofar as is practicable, made identical to that in which the system will eventually operate. Here, the model has transitioned into greater reality. Some environments that are of great significance to system performance and reliability can only be imperfectly understood and are very difficult to simulate, for example, the deep ocean and exo‐atmospheric space. In such cases, defining and simulating the environment may become a major effort in itself. Even environments that were thought to be relatively well understood can yield surprises. At each step, the system development process requires a successively more detailed definition of the requirements that the system must meet. It is against these environmental requirements that the successive models of the system are evaluated and refined. A lesson to be learned is that the effort required to model the environment of a system for the purpose of system T&E needs to be considered at the same level of priority as the design of the system itself and may even require a separate design effort comparable with the associated system design activity. Tests and  Test Data Analysis. The definitive steps in the validation of the system design are the conduct of tests in which the system model (or a significant portion of it) is made to interact with a model of its environment in such a way that the effects can be measured and analyzed in terms of the system requirements. The scope of such tests evolves with the degree of materialization of the system, beginning with paper calculations and ending with operational tests in the final stages. In each case, the objective is to determine whether or not the results conform to those prescribed by the requirements, and if not, what changes are required to rectify the situation.

90

THE SYSTEM DEVELOPMENT PROCESS

In carrying out the above process, it is most important to observe the following key principles: 1. All critical system characteristics need to be stressed beyond their specified limits to uncover incipient weak spots. 2. All key elements need to be instrumented to permit location of the exact sources of deviations in behavior. The instruments must significantly exceed the test articles in precision and reliability. 3. A test plan and an associated test data analysis plan must be prepared to assure that the requisite data are properly collected and are then analyzed as necessary to assure a realistic assessment of system compliance. 4. All limitations in the tests due to unavoidable artificialities need to be explicitly recognized and their effect on the results compensated or corrected for, as far as possible. 5. A formal test report must be prepared to document the degree of compliance by the system and the source of any deficiencies. The test plan should detail each step in the test procedure and identify exactly what information will be recorded prior to, during, and at the conclusion of each test step, as well as how and by whom it will be recorded. The test data analysis plan should then define how the data would be reduced, analyzed, and reported along with specific criteria that will be employed to demonstrate system compliance. To the extent that the validation tests reveal deviations from required performance, the following alternatives need to be considered: 1. Can the deviation be due to a deficiency in the environmental simulation (i.e. test equipment)? This can happen because of the difficulty of constructing a realistic model of the environment. 2. Is the deviation due to a deficiency in the design? If so, can it be remedied without extensive modifications to other system elements? 3. Is the requirement at issue overly stringent? If so, a request for a deviation may be considered. This would constitute a type of feedback that is characteristic of the system development process.

Preparation for the Next Phase Each phase in the system development process produces a further level of requirements or specifications to serve as a basis for the next phase. This adds to, rather than replaces, previous levels of requirements and serves two purposes: 1. It documents the design decisions made in the course of the current phase. 2. It establishes the goals for the succeeding phase.

THE SYSTEMS ENGINEERING METHOD

91

Concurrent with the requirements analysis and allocation activity, systems engineering, acting in concert with project management, is also responsible for the definition of specific technical objectives to be met and for the products (e.g. hardware/software components, technical documentation, supporting test data) that will be provided in response to the stated requirements for inputs to the next phase. These identified end products of each phase are also often accompanied by a set of intermediate technical milestones that can be used to judge technical progress during each particular design activity. The task of defining these requirements or specifications and the efforts to be undertaken in implementing the related design activities is an essential part of system development. Together, these constitute the official guide for the execution of each phase of the development. It must, however, be noted that in practice, the realism and effectiveness of this effort, which is so critical to the ultimate success of the project, depends in large part on good communication and cooperation between systems engineering and project management on the one hand, and on the other, the design specialists who are ultimately the best judges of what can and cannot be reasonably accomplished given the stated requirements, available resources, and allotted time scale. Since the nature of the preparation for the next phase varies widely from phase to phase, it is not usually accorded the status of a separate step in the systems engineering method; most often, it is combined with the validation process. However, this does not diminish its importance because the thoroughness with which it is done directly affects the requirements analysis process at the initiation of the next phase. In any event, the definition of the requirements and tasks to be performed in the next phase serves an important interface function between phases.

Systems Engineering Method over the System Life Cycle To illustrate how the systems engineering method is applied in successive phases of the system life cycle, Table  3.3 lists the primary focus of each of the four steps of the method for each of the phases of the system life cycle. As indicated earlier in Table 3.1, it is seen that as the phases progress, the focus shifts to more specific and detailed (lower level) elements of the system until the integration and evaluation phase. The table also highlights the difference in character of the physical definition and design validation steps in going from the concept development to the engineering development stage. In the concept development stage (left three columns), the defined concepts are still in functional form (except where elements of the previous or other systems are applied without basic change). Accordingly, physical implementation has not yet begun, and design validation is performed by analysis and simulation of the functional elements. In the engineering stage, implementation into hardware and software proceeds to lower and lower levels, and design validation includes tests of experimental, prototype, and finally production system elements and the system itself. In interpreting both Tables 3.1 and 3.3, it should be borne in mind that in a given phase of system development, some parts of the system might be prototyped to a more

TABLE 3.3.  Systems Engineering Method over Life Cycle Concept development

Phase Step

Needs analysis

Concept exploration

Engineering development Concept definition

Advanced development

Engineering design

Integration and evaluation

Analyze design requirements

Analyze test and evaluation requirements

Requirements analysis

Analyze needs

Analyze operational Analyze performance Analyze functional requirements requirements requirements

Functional definition

Define system objectives

Define subsystem functions

Develop functional architecture– component functions

Refine functional architecture– subcomponent functions

Define part functions

Define functional tests

Physical definition

Define system capabilities, visualize subsystems, ID technology

Define system concepts, visualize components

Develop physical architecture– components

Refine physical architecture– specify component construction

Specify subcomponent construction

Define physical tests; specify test equipment and facilities

Design validation

Validate needs and feasibility

Validate operational requirements

Evaluate system capabilities

Test and evaluate critical subsystems

Validate component construction

Test and evaluate system

92

93

THE SYSTEMS ENGINEERING METHOD

advanced phase to validate critical features of design. This is particularly true in the advanced development phase, where new potentially risky approaches are prototyped and tested under realistic conditions. Normally, new software elements are also prototyped in this phase to validate their basic design. While these tables present a somewhat idealized picture, the overall pattern of the iterative application of the systems engineering method to successively lower levels of the system is an instructive and valid general view of the process of system development.

Spiral Life Cycle Model The iterative nature of the system development process, with the successive applications of the systems engineering method to a stepwise “materialization” of the system, has been captured in the so‐called “spiral” model of the system life cycle. A version of this model as applied to life cycle phases is shown in Figure 3.9. The sectors representing Requirements analysis Mission and requirements analysis Functional analysis

Specification generation Producibility analysis

Functional definition Concept formulation

Logistics support analysis

Production and deployment

System test and evalution

Requirements allocation

Design optimization

Design synthesis

System development and demonstration

System integration

Component advanced development Concept exploration Physical definition

System effectiveness analysis

Figure 3.9.  Spiral model of the system life cycle.

Design validation

94

THE SYSTEM DEVELOPMENT PROCESS

the four steps in the systems engineering method defined in the above section are shown separated by heavy radial lines. This model emphasizes that each phase of the development of a complex system necessarily involves an iterative application of the systems engineering method and the continuing review and updating of the work performed and conclusions reached in the prior phases of the effort.

3.5  TESTING THROUGHOUT SYSTEM DEVELOPMENT Testing and evaluation are not separate functions from design but rather inherent parts of design. In basic types of design, for example, as of a picture, the function of T&E is performed by the artist as part of the process of transferring a design concept to canvas. To the extent that the painting does not conform to the artist’s intent, he or she alters the picture by adding a few brushstrokes, which tailor the visual effect (performance) to match the original objective. Thus, design is a closed‐loop process in which T&E constitutes the feedback that adjusts the result to the requirements that it is intended to meet.

Unknowns In any new system development project, there are a great many unknowns that need to be resolved in the course of producing a successful product. For each significant departure from established practice, the result cannot be predicted with assurance. The project cost depends on a host of factors, none of them known precisely. The resolution of interface incompatibilities often involves design adjustment on both sides of the interface, which frequently leads to unexpected and sometimes major technical difficulties. An essential task of systems engineering is to guide the development of the system so that the unknowns are turned into knowns as early in the process as possible. Any surprises occurring late in the program can prove to be many times more costly than those encountered in its early phases. Many unknowns are evident at the beginning, and may be called “known unknowns.” These are identified early as potential problem areas and are therefore singled out for examination and resolution. Usually, this can be accomplished through a series of critical experiments involving simulations and/or experimental hardware and software. However, many other problem areas are only identified later when they are discovered during system development. These unanticipated problems are often identified as “unknown unknowns” or “unk‐unks” to distinguish them from the group of “known unknowns” that were recognized at the outset and dealt with before they could seriously impact the overall development process.

Transforming the Unknown into the Known The existence of “unk‐unks” makes the task of attempting to remove all the unknowns far more difficult. It forces an active search for hidden traps in the favored places of technical problems. It is the task of the systems engineer to lead this search based on

TESTING THROUGHOUT SYSTEM DEVELOPMENT

95

experience gathered during previous system developments and supported by a high degree of technical insight and a “What‐if, …?” attitude. Since every unknown poses an uncertainty in the accomplishment of the final objective, it represents a potential risk. In fact, unknowns present the principal risks in any development program. Hence, the task of risk assessment and integration is one and the same as that of identifying unknowns and resolving them. The tools for resolving unknowns are analysis, simulation, and test, these being the means for discovering and quantifying critical system characteristics. This effort begins during the earliest conceptual stages and continues throughout the entire development, only changing in substance and character and not in objective and approach. In designing a new system or a new element of a system that requires an approach never attempted before under the same circumstances (as, for example, the use of new materials for making a highly stressed design element), the designer faces a number of unknowns regarding the exact manner in which the new design when implemented will perform (for example, the element made of a new material may not be capable of being formed into the required shape by conventional tools). In such cases, the process of testing serves to reveal whether or not the unknown factors create unanticipated difficulties requiring significant design changes or even abandonment of the approach. When a new design approach is undertaken, it is unwise to wait until the design is fully implemented before determining whether or not the approach is sound. Instead, testing should first be done on a theoretical or experimental model of the design element, which can be created quickly and at minimum cost. In doing so, a judgment must be made as to the balance between the potential benefit of a greater degree of realism of the model and the time and cost of achieving it. This is very often a system‐level rather than a component‐level decision, especially if the performance of the element can have a system impact. If the unknowns are largely in the functional behavior of the element, then a computational model or a simulation is indicated. If, on the other hand, the unknowns are concerned with the material aspects, an experimental model is required.

Systems Engineering Approach to Testing The systems engineering approach to testing can be illustrated by comparing the respective views of testing by the design engineer, the test engineer, and the systems engineer. The design engineer wants to be sure that a component passes the test, wanting to know, “Is it OK?” The test engineer wants to know that the test is thorough, so as to be sure the component is stressed enough. The systems engineer wants to be sure to find and identify all deficiencies present in the component. If the component fails a test, the systems engineer wants to know why, so that there will be a basis for devising changes that will eliminate the deficiency. It is evident from the above that the emphasis of systems engineering is not only on the test conditions but also on the acquisition of data showing exactly how the

96

THE SYSTEM DEVELOPMENT PROCESS

various parts of the system did or did not perform. Furthermore, the acquisition of data itself is not enough; it is necessary to have in hand procedures for analyzing the data. These are often complicated and require sophisticated analytical techniques, which must be planned in advance. It also follows that a systems engineer must be an active participant in the formulation of the test procedures and choice of instrumentation. In fact, the prime initiative for developing the test plan should lie with systems engineering, working in close cooperation with test engineering. To the systems engineer, a test is like an experiment is to a scientist, namely, a means of acquiring critical data on the behavior of the system under controlled circumstances.

System T&E The most intensive use of testing in the system life cycle takes place in the last phase of system development, integration and evaluation, which is the subject of Chapter 16. Chapter 17 also contains a section on T&E during the advanced development phase.

3.6 SUMMARY Systems Engineering Through the System Life Cycle A major system development program is an extended complex effort to satisfy an important user need. It involves multiple disciplines and applies new technology, requires progressively increasing commitment of resources, and is conducted in a ­stepwise manner to a specified schedule and budget.

System Life Cycle The system life cycle may be divided into three major stages: Concept Development. Systems engineering establishes the system need, explores feasible concepts, and selects a preferred system concept. The concept development stage may be further subdivided into three phases: 1. Needs analysis defines and validates the need for a new system, demonstrates its feasibility, and defines system operational requirements. 2. Concept exploration explores feasible concepts and defines functional performance requirements. 3. Concept definition examines alternative concepts, selects preferred concept on the basis of performance, cost, schedule, and risk, and defines system functional specifications (A‐Spec).

SUMMARY

97

Engineering Development. Systems engineering validates new technology, transforms the selected concept into hardware and software designs, and builds and tests production models. The engineering development stage may be further subdivided into three phases: 1. Advanced development identifies areas of risk, reduces these risks through analysis, development, and test, and defines system development specifications (B‐Spec). 2. Engineering design performs preliminary and final design, and builds and tests hardware and software components (CIs). 3. Integration and evaluation integrates components into production prototype, evaluates prototype system, and rectifies deviations. Post‐Development.  Systems engineering produces and deploys the system, and supports system operation and maintenance. The post‐development stage is further subdivided into two phases: 1. Production develops tooling and manufactures system products, provides the system to the users, and facilitates initial operations. 2. Operation and support supports system operation and maintenance, and develops and supports in‐service updates.

Evolutionary Characteristics of the Development Process Most new systems evolve from predecessor systems – their functional architecture and even some components may be reusable. A new system progressively “materializes” during its development. System descriptions and designs evolve from concepts to reality. Documents, diagrams, models, and products all change correspondingly. Moreover, key participants in system development change during development; however, systems engineering plays a key role throughout all phases.

The Systems Engineering Method The systems engineering method involves four basic steps: • • • •

Requirements analysis – identifies why requirements are needed Functional definition – translates requirements into functions Physical definition – synthesizes alternative physical implementations Design validation – models the system environment

98

THE SYSTEM DEVELOPMENT PROCESS

These four steps are applied repetitively in each phase during development. Application of the systems engineering method evolves over the life cycle – as the system progressively materializes, the focus shifts from system‐level during needs analysis down to component and part levels during engineering design.

Testing Throughout System Development Testing is a process to identify unknown design defects in that it verifies resolution of “known unknowns,” and uncovers “unknown unknowns” (unk‐unks) and their causes. Late resolution of unknowns may be extremely costly; therefore, test planning and analysis is a prime systems engineering responsibility.

PROBLEMS 3.1 Identify a recent development (since 2010) of a complex system (commercial or military) of which you have some knowledge. Describe the need it was developed to fill and the principal ways in which it is superior to its predecessor(s). Briefly describe the new conceptual approach and/or technological advances that were employed. 3.2 Advances in technology often lead to the development of a new or improved system by exploiting an advantage not possessed by its predecessor. Name three different types of advantages that an advanced technology may offer and cite an example of each. 3.3 If there is a feasible and attractive concept for satisfying the requirements for a new system, state why it is important to consider other alternatives before deciding which to select for development. Describe some of the possible consequences of failing to do so. 3.4 The space shuttle is an example of an extremely complicated system using leading edge technology. Give three examples of shuttle components that you think represented unproven technology at the time of its development, and which much have required extensive prototyping and testing to reduce operational risks to an acceptable level. 3.5 What steps can the systems engineer take to help ensure that system components designed by different technical groups or contractors will fit together and interact effectively when assembled to make up the total system? Discuss in terms of mechanical, electrical, and software system elements. 3.6 For six of the systems listed in Tables  1.2 and 1.3, list their “predecessor systems.” For each, indicate the main characteristics in which the current systems are superior to their predecessors. 3.7 Table  3.2 illustrates the evolution of system models during the system development process. Describe how the evolution of requirement documents illustrates the materialization process described in Table 3.1.

FURTHER READING

99

3.8 Select one of the household appliances listed below. a. State the functions that it performs during its operating cycle. Indicate the primary medium (signals, data, material, or energy) involved in each step and the basic function that is performed on this medium. Automatic dishwasher Washing machine Television set b. For the selected appliance, describe the physical elements involved in the implementation of each of the above functions.

REFERENCE Maier, M. and Rechtin, E. (2009). The Art of Systems Architecting. CRC Press.

FURTHER READING Biemer, S. and Sage, A. (2009). Chapter 4: Systems engineering: basic concepts and life cycle. In: Agent‐Directed Simulation and Systems Engineering (eds. L. Yilmaz and T.I. Oren). Wiley. Blanchard, B. (2004). System Engineering Management, 3e. Wiley. Blanchard, B. and Fabrycky, W. (2013). System Engineering and Analysis, 5e. Prentice Hall. Buede, D. (2016). The Engineering Design of Systems: Models and Methods, 3e. Wiley. Chesnut, H. (1967). System Engineering Methods. Wiley. DeGrace, P. and Stahl, L.H. (1990). Wicked Problems, Righteous Solutions. Yourdon Press, Prentice Hall. Eisner, H. (1988). Computer‐Aided Systems Engineering. Prentice Hall, Chapter 10. Eisner, H. (2002). Essentials of Project and Systems Engineering Management, 2e. Wiley. Hall, A.D. (1962). A Methodology for Systems Engineering. Van Nostrand, Chapter 4. Martin, J.N. (1997). Systems Engineering Guidebook: A Process for Developing Systems and Products. CRC Press, Chapters 2–5. Rechtin, E. (1991). Systems Architecting: Creating and Building Complex Systems. Prentice Hall, Chapters 2 and 4. Reilly, N.B. (1993). Successful Systems for Engineers and Managers. Van Nostrand Reinhold, Chapter 3. Sage, A.P. (1992). Systems Engineering. McGraw Hill, Chapter 2. Sage, A.P. and Armstrong, J.E. Jr. (2000). Introduction to Systems Engineering. Wiley, Chapter 2. Sage, A.P. and Biemer, S.M. (2008). Processes for system family architecting, design and integration. IEEE Systems Journal 1: 5–16. Stevens, R., Brook, P., Jackson, K., and Arnold, S. (1998). Systems Engineering, Coping with Complexity. Prentice Hall, Chapters 7 and 8.

4 SYSTEMS ENGINEERING MANAGEMENT

4.1  MANAGING SYSTEM DEVELOPMENT As noted in the first chapter, systems engineering is an integral part of the management of a system development project. The part that systems engineering plays in the project management function is pictured in the Venn diagram of Figure 4.1. The ovals in the diagram represent the domain of project management, and those of its principal ­constituents: systems engineering and project planning and control. It is seen that both constituents are wholly contained within the project management domain, with technical guidance being the province of systems engineering, while program, financial, and contract guidance are the province of project planning and control. The allocation of resources and definition of tasks are necessarily shared functions. To better understand the many different functions of systems engineering, this chapter describes some of the main features of the project management framework, such as the work breakdown structure (WBS), project organization, and the systems engineering management plan (SEMP). It also discusses the subject of risk management, the organization of systems engineering effort, and the capability maturity model integrated as it applies to systems engineering. Systems Engineering Principles and Practice, Third Edition. Alexander Kossiakoff, Samuel J. Seymour, David A. Flanigan, and Steven M. Biemer. © 2020 John Wiley & Sons, Inc. Published 2020 by John Wiley & Sons, Inc.

101

102

SYSTEMS ENGINEERING MANAGEMENT

Project management Systems engineering Systems architecture Concept design Functional allocation Technical coordination Technical disciplines Subcontractors Systems integration Interface management Verification and validation

Project planning and control Task definitions Task allocation Program reviews

Risk management Risk assessment Risk mitigation Customer interaction Management technical

Project planning Work breakdown Costs and schedules Resource allocation Manpower Facilities Financial & contract management Program commitment Subcontracts

Figure 4.1.  Systems engineering as a part of project management.

The engineering of a complex system requires the performance of a multitude of interrelated tasks by dozens or hundreds of people, management leaders, and a number of contractors or other organizational entities. These tasks include not only the entire development process but also usually everything needed to support system operation, such as maintenance, documentation, training, and so on, which must be provided for. Test equipment, facilities, and transportation have to be developed and acquired. The tasks involved in project management and systems engineering, including planning, scheduling, costing, and configuration control need to be explicitly dealt with. The management complexity is addressed with defined roles for the management team leaders. The program manager (PM) is responsible for the overall scope of an initiative from beginning to end, overseeing multiple projects that lead to ultimate objectives that benefit the organization. The PM develops and implements the strategy for the program team, optimizing the work across projects and managing the budgets, and reporting the program performance to the client and senior organization management. The long‐term organization goals guide evaluation and directions of the program. In short, this person is responsible for planning, governance, and overseeing the successful delivery of the program’s output/product. The project manager is in charge of a specific project in an organization, planning, budgeting, and monitoring the daily activities of the project. The role includes identifying needed resources, hiring appropriate staff, setting milestones, identifying new

WORK BREAKDOWN STRUCTURE

103

technologies, and mediating conflicts. The project manager is the bridge between the PM, upper management, and the teams tasked with the actual execution of the project. The systems engineer (SE) is responsible for maintaining a view of the whole system product, developing and integrating all components, and evaluating performance against all contract specifications. The SE assists in the development of strategy and planning, conducts the technical and engineering development of the systems, integrates and tests all components and final system, and ensures the operation and delivery of the product. The sections in this chapter are intended to apply to the management of all systems engineering activities for all types of complex systems. However, in the management of software‐intensive systems, in which essentially all of the functionality is performed by software, there are a number of special characteristics that need to be considered. These are noted, in particular, in the Section 14.7.

Proposal Development and Statement of Work Systems development often starts with someone who has a need, a customer, who requests support often in the form of a request for proposal (RFP) when in a competitive environment. Following a corporate decision to respond to the RFP, a PM or a professional proposal team is assigned to generate the proposal. While a SE may not be officially assigned to the team, it is essential that the technical concepts and implied design and interfaces are feasible. Hence, even in the early phases of a project, the integration of systems engineering with project management is evident. A critical element of the proposal is the statement of work (SOW). This is a narrative description of the work that is needed to develop the system to meet the customer needs. The SE concerns will focus on the product to be developed; ensuring the scope of work in the SOW includes all the products and services needed to complete the effort. Specifically, the SE focuses on being responsive to the customer needs, ensures the SOW is based on a credible concept of operations, reviews the implied design for the use of legacy components and their availability, examines to see if the proposed system integrates commercial off the shelf (COTS), and to determine the technology readiness levels for the important subsystems envisioned in the preliminary system design. This early planning sets the stage for the work the technical contributors will have “to live with” throughout the life of the project.

4.2  WORK BREAKDOWN STRUCTURE The successful management of the system development effort requires special techniques to ensure that all essential tasks are properly defined, assigned, scheduled, and controlled. One of the most important techniques is the systematic organization of project tasks into a form called the WBS, or less commonly the project or system breakdown structure. It defines all of the tasks it terms of goods and services to be accomplished during the

104

SYSTEMS ENGINEERING MANAGEMENT

project in terms of a hierarchical structure. Its formulation begins early in the concept definition phase to serve as a point of reference for concept trade‐off studies. It is then more fully articulated in the latter stages to serve as a basis for system life cycle costing. The WBS is often a contractual requirement in competitive system developments. The WBS typically defines the whole system to be developed, produced, tested, deployed, and supported, including hardware, software, services, and data. It defines a skeleton or framework on which the project is to be implemented.

Elements of a Typical WBS The WBS format is generally tailored to the specific project in hand, but always follows a hierarchical tree structure designed to ensure a specific place for every significant portion of work under the project. For purposes of illustration, the following paragraphs describe the main elements of a typical defense system WBS. With the system project at level 1 in the hierarchy (some WBS structures begin at level 0), the level 2 categories may be broken down as follows: 1.1 1.2 1.3 1.4 1.5

System product System support System testing Project management Systems engineering

Note that these categories are not parallel in content or scope, but collectively they are designed to encompass all the work under the system project. 1.1

System product is the total effort required to develop, produce, and integrate the system itself, together with any auxiliary equipment required for its operation. Figure  4.2 shows an example of the WBS breakdown of the system product. The level 3 entries are seen to be the several subsystems, as well as the equipment required for their integration (assembly equipment), and other auxiliary equipment used by more than one subsystem. The figure also shows an example of the level 4 and 5 breakdown of one of the subsystems into its constituent components, which represent definable products of development, engineering, and production effort. It is preferred that integration and test of hardware and software component is done separately for each subsystem, and then the tested subsystems are integrated in the final system for testing (1.3 below). Finally, for cost allocation and control purposes, each component is further broken down at level 5 into work packages that define the several steps of the component’s design, development, and test. From this level and below the WBS, elements are often expressed with action words, e.g. ­purchase, design, integrate, test.

105

WORK BREAKDOWN STRUCTURE

Level 1

Level 2

Level 3

Level 4

Level 5

1. System product 1.1 System product 1.1.1 Subsystem A 1.1.1.1 Component A1

1.1.1.2 Component A2

1.1.1 Subsystem B

1.1.2.1 Component B1

1.1.1.1.1 Functional design 1.1.1.1.2 Engineering design 1.1.1.1.3 Fabrication 1.1.1.1.4 Unit test 1.1.1.1.5 Documentation 1.1.1.2.1 Functional design … (etc.)

1.1.2.1.1 Functional design … (etc.)

1.1.3 Subsystem C 1.1.4 Assembly equipment 1.1.5 Auxiliary equipment

Figure 4.2.  System product WBS partial breakdown structure.

1.2 System support (or integrated logistic support) provides equipment, ­facilities, and services necessary for the development and operation of the system product. These items can be categorized (level 3 categories) under six headings: 1.2.1 Supply support 1.2.2 Test equipment 1.2.3 Transport and handling 1.2.4 Documentation 1.2.5 Facilities 1.2.6 Personnel and training Each of the system support categories applies to both the development process and system operation, which may involve quite different activities. 1.3 System testing begins after design of the individual components has been validated via component tests. A very significant fraction of the total test effort is usually allocated to system‐level testing, which involves four categories of tests as follows: 1.3.1 Integration testing – this category supports the stepwise integration of components and subsystems to achieve a total system. 1.3.2 System testing  –  this category provides for overall system tests and the evaluation of test results. 1.3.3 Acceptance testing – this category provides for factory and installation tests of delivered systems.

106

SYSTEMS ENGINEERING MANAGEMENT

1.3.4 Operational testing and evaluation – this category tests the effectiveness of the entire system in a realistic operational environment. Individual tests to be performed at each level are prescribed in a series of separate test plans and procedures. However, an overall description of test objectives and content and a listing of the individual tests to be performed should also be set forth in an integrated test planning and management document, the “test and evaluation management plan” or TEMP in defense acquisition terminology. Chapters 16 and 17 are devoted to the subject of system integration and evaluation. 1.4 Project management tasks include all activities associated with project planning and control, including the management of the WBS, costing, scheduling, performance measurement, project reviews and reports, and associated activities. 1 .5 Systems engineering tasks include the activities of the systems engineering staff in guiding the engineering of the system through all its conceptual and engineering phases. This specifically includes activities such as requirements analysis, trade‐off studies (analysis of alternatives), technical reviews, test requirements and evaluations, system design requirements, configuration management, and so on, which are identified in the SEMP. Another important activity is the integration of specialty engineering into the early phases of the engineering effort, in other words, concurrent engineering. The WBS is structured so that every task is identified at the appropriate place within the WBS hierarchy. Systems engineering plays an important role in helping the project manager to structure the WBS so as to achieve this objective. The use of the WBS as a project‐organizing framework generally begins in the concept exploration phase. In the concept definition phase, the WBS is defined in detail as the basis for organizing, costing, and scheduling. At this point, the subsystems have been defined and their constituent components identified. Also, decisions have been made, at least tentatively, regarding outside procurement of elements of the system. Accordingly, the level down to which the WBS needs to be defined in detail should have been established. It is, of course, to be expected that the details of the WBS evolve and change as the system is further engineered. However, its main outline should remain stable.

Cost Control and Estimating The WBS is the heart of the project cost control and estimating system. Its organization is arranged so that the lowest indenture work packages correspond to cost allocation items. Thus, at the beginning of the project, the target cost is distributed among the identified work packages, and is partitioned downward as lower‐level packages are defined. Keeping track of all actual costs is essential along with the actual time required to develop a system component. Project cost control is then exercised by comparing actual reported costs against estimated costs, identifying and focusing attention on those work packages that deviate seriously from initial estimates. If any new work is required to

WORK BREAKDOWN STRUCTURE

107

be carried out, estimations are needed for this and see if it can be accommodated with the final amount in the budget. Time management is key to cost control especially if project deadlines are missed since the longer the project is dragged on, the higher the costs incurred, which effectively means that the budget will be exceeded. Another technique to cost control is to identify the value of the work that has been carried out as the project progresses, an approach commonly known as earned value. Early in the budget planning process, the PM should conduct an affordability assessment to demonstrate that the projected funding and manpower requirements are realistic and achievable. This activity would examine all fiscal demands from acquisition, development, testing, sustainment, and management  –  comparing the projected costs with the total budget. This is best conducted on a yearly basis noting the funding availability, inflation, and development risks. Key participants at all levels should be engaged to ensure the best expertise and prior experience is included. Another key component for adequate cost estimating is the conduct of a life cycle cost analysis. The approach is to determine and compare among alternatives in each development phase to acquire, develop, operate, and maintain all system element for the most cost‐effective options. Note that least costly current element may not be a sound decision over the life of the system due to sustainment and replacement costs. Hence, the life cycle cost analysis is best conducted in the early planning and conceptual design phase of a project. The collection of project costs down to the component level and their distribution among the principal phases of project development, engineering, and fabrication is essential also for contributing to a database, which is used by the organization for estimating the costs of future projects. For new components, cost estimates must be developed by adapting the previously experienced costs of items directly comparable to those in the projected system, at the lowest level of aggregation for which costs figures are available. At higher levels, departures from one system to the next become too large to reliably use data derived from previous experience without major correction. It should not be expected that the lowest indenture level would be uniform throughout the various subsystems and their components. For example, if a subsystem is being obtained on a fixed price subcontract, it may well be appropriate to terminate the lowest indenture in the WBS at that subsystem. In general, program control, including costing, is exercised at the level at which detailed specifications, interface definitions, and work assignments are available, representing in effect a contract between the project and the organization charged with the responsibility for developing, engineering, or fabricating given elements of the system.

Critical Path Method Network scheduling techniques are often used in project management to aid in planning and control of the project. Networks are composed of events and activities needed to carry out the project. Events are equivalent to a milestone indicating when an activity starts and finishes. Activities represent the element of work or task, usually derived from the WBS that needs to be accomplished. Critical path analysis is an essential project management

108

SYSTEMS ENGINEERING MANAGEMENT

tool that traces each major element of the system back through the engineering of its constituent parts. Estimates are made of not only the size but also the duration of effort required for each step. The particular path that is estimated to require the longest time to complete its constituent activities is called the “critical path.” The differences between this time and the times required for other paths are called “slack” for those paths. The resulting critical path network is a direct application of the WBS. The SE uses the CPM to understand the dependences of task activities, help prioritize the work of the technical teams, and to communicate graphically the work of the entire program.

4.3  SYSTEMS ENGINEERING MANAGEMENT PLAN In the development of a complex system, it is essential that the customer and all of the key participants in the system development process not only know the key systems requirements and their own responsibilities but also know how they interface with one another. Just as special documentation is required to control system interfaces, so the interfacing of responsibilities and authority within the project must also be defined and controlled. This is usually accomplished through the preparation and dissemination of a systems engineering plan (SEP) for government contracts or a SEMP. The primary responsibility of creating such a plan for guiding the engineering effort is that of the systems engineering component of project management. The SEP is typically associated with product development for the US government. The USD (ST&L) has stated: “All programs responding to a capabilities or requirements document, regardless of acquisition category, shall employ a robust systems engineering (SE) approach that balances total system performance and total ownership costs within the family‐of‐systems, system‐of‐systems context. Programs shall develop a Systems Engineering Plan (SEP) for Milestone Decision Authority (MDA) approval in conjunction with each Milestone review, and integrated with the Acquisition Strategy. This plan shall describe the program’s overall technical approach, including processes, resources, metrics, and applicable performance incentives. It shall also detail the timing, conduct, and success criteria of technical reviews.” The SEP would be updated as plans are modified, development progress is made, known risks are mitigated or significantly change, new risks are identified, and technologies are adopted. The SEP defines government (customer) technical planning expectations from their perspective. It provides contractor guidance for systems engineering as applied to the acquisition program. The SEP communicates technical management approach to program team, stakeholders, and contractor teams and is required for milestone approval.

SEP or SEMP? A SEMP should be developed in the prime performing organization by the senior SE for all new program development. For government contracts, a SEP is acceptable only if it

109

SYSTEMS ENGINEERING MANAGEMENT PLAN

addresses the overall program’s systems engineering technical approach across the government, prime, and subcontractor domains. Typically, a SEMP may not flow down the systems engineering process and requirements to all program subcontractors and vendors. Other possible SEP/SEMP differences include: government stakeholder versus contractor perspective, problem/requirement space versus solution space, program requirements versus technical system, requirements, technical strategy review focus versus what and how systems are reviewed, and planning integrated between government and contractor versus total integration of engineering between all contributing parties. The importance of having formalized plans for managing the engineering effort is by requiring the contractor to prepare a SEMP as part of the concept definition effort. The most important function of the SEMP is to ensure that all of the many active participants (subsystem managers, component design engineers, test engineers, systems analysts, specialty engineers, subcontractors, etc.) know their responsibilities to one another. This is an exact analogue of the component interface function of systems engineering defining the interactions among all parts of the system so that they fit together and operate smoothly. It also serves as a reference for the procedures that are to be followed in carrying out the numerous systems engineering tasks. The place of the SEMP in the program management planning is shown in Figure 4.3. Program requirements

Program management plan (PMP)

Program technical requirements

Specifications A

Program management requirements Systems engineering management plan (SEMP)

B C D E

Related management plans Configuration management Test and evaluation

Individual program plans

Manufacturing management Total quality

Functional design Reliability Maintainability Producibility Safety Logistics

Figure 4.3.  Place of SEMP in program management plans.

110

SYSTEMS ENGINEERING MANAGEMENT

The SEMP is intended to be a living document, starting as an outline, and being elaborated and otherwise updated as the system development process goes on. Having a formal SEMP also provides a control instrument for comparing the planned tasks with those accomplished.

Elements of a Typical SEMP The SEMP contains a detailed statement of how the systems engineering functions are to be carried out in the course of system development. It can be considered to consist of three types of activity: 1. Development program planning and control describes the systems engineering tasks that must be implemented in managing the development program, including: • Statements of work • Organization • Scheduling • Program, design, and test readiness reviews • Technical performance measurement • Risk management 2. Systems engineering process describes the systems engineering process as it applies to the development of the system, including: • Operational requirements • Functional analysis • System analysis and trade‐off strategy • System test and evaluation strategy 3. Engineering specialty integration describes how the areas of specialty engineering are to be integrated into the primary system design and development, including: • Reliability, maintainability, and availability (RMA) engineering • Producibility engineering • Safety engineering • Human factors engineering A typical SEMP outline is tailored to the development system but could include: Introduction Scope, Purpose, Overview, Applicable Documents Program Planning and Control Organizational Structure Responsibilities, Procedures, Authorities

ORGANIZATION OF  SYSTEMS ENGINEERING

111

Work breakdown structure, Milestones, Schedules Program Events Program, Technical, Test Readiness Reviews Technical and Schedule Performance Metrics Engineering Program Integration, Interface Plans Systems Engineering Process Mission, System Overview Graphic Requirements and Functional Analysis Trade Studies (Analysis of Alternatives) Technical Interface Analysis/Planning Specification Tree/Specifications Modeling and Simulation Test Planning Logistic Support Analysis Systems Engineering Tools Engineering Integration Integration Design/Plans Specialty Engineering Compatibility/Interference Analysis Producibility Studies

4.4  ORGANIZATION OF SYSTEMS ENGINEERING Despite decades of study, there are many opinions, but no general agreement, on which organizational form is most effective for a given type of enterprise. For this reason, the organizations participating in a system development project are likely to employ a variety of different organizational styles. Each individual style has evolved as a result of history, experience, and the personal preferences of upper management. Accordingly, despite its central importance to the success of a given system development project, the systems engineering function will usually need to adapt to preexisting organizational structures. Virtually, all system development projects are managed by a single industrial company. Hence, it is the organizational form of this company that drives the organization of systems engineering. In most cases, this company will develop some subsystems in house, and contract for other subsystems with subcontractors. We will refer to the first company as the prime contractor or system contractor, and to the collection of participating contractors as the “contractor team.” This means that the systems engineering activity must span not only a number of different disciplines but also several independent companies.

112

SYSTEMS ENGINEERING MANAGEMENT

The organizational structure of the prime contractor is usually some form of a “matrix” organization. In a matrix organization, most of the engineering staff is organized in discipline‐ or technology‐oriented groups. Major projects are managed by project management teams reporting to a “vice president for project management” or equivalent. At times, these teams are called integrated product teams (IPTs). Technical staff is assigned to individual projects as required, but employees retain affiliation with their engineering groups. The main variations in matrix‐type organizations relate to whether the bulk of the technical staff assigned to a project is physically relocated to an area dedicated to the project, and remain as full‐time participants throughout much of the development, or whether they remain in their home group areas. A related difference is the degree to which authority for the direction of the technical work assignments is retained by their home group supervisors. As stated earlier, the organization of the systems engineering function is necessarily dependent on the system contractor’s organizational structure. There should be some common practices, however. Referring to Figure  4.1, a major system project should have a single focus of responsibility for the systems engineering function (a project SE), apart from the project planning and control function. As an integral part of project management, an appropriate title might be “associate (or deputy) project manager for systems engineering” or more simply “systems engineering manager.” Since the systems engineering function is that of guidance, authority is exercised by establishing goals (requirements and specifications), formulating task assignments, conducting evaluations (design reviews, analysis, and test), and controlling the configuration. Effective technical communications are difficult to maintain in any organization for a variety of reasons, many of them inherent in human behavior. They are, nevertheless, absolutely vital to the ultimate success of the development project. Perhaps the single most important task of the project SE is to establish and maintain effective communication among the many individuals and groups, inside and outside the company, whose work needs to interact with others. This is a human interface function corresponding to the system physical interface functions that make the system elements fit together and operate as one. Since the SE usually works in parallel with rather than through established lines of authority, he or she must exercise extraordinary leadership to bring together those individuals who need to interact. There are several different means of communication, all of which need to be exercised as appropriate: 1. All key participants need to know what they are expected to do, when, and why: The “What” is expressed in task assignments and WBS; the “When” is contained in schedules, milestones, and critical path networks; and the “Why” should be answered in the requirements and specifications. A clear and complete statement of the “Why” is essential to ensure that the designers, analysts, and testers understand the objectives and constraints of the task assignments.

ORGANIZATION OF  SYSTEMS ENGINEERING

113

2. Participants must be aware of how their portions of the system interact with other key elements, and the nature of their mutual interdependence. Such interactions, and particularly their underlying causes, can never be sufficiently covered in specification documents. This awareness can only be provided by periodic personal communication among the responsible participants and the documentation of any resulting agreements, interface definitions, and so on, however small or tentative. Systems engineering must provide the glue that binds these items of system design through the formation of interface working groups and the development of interface control documents, and such less formal communications as may be needed in special cases. 3. Subcontractors and other key participants at remote sites must be integrated into the project communication framework. At the management level, this is the task of the system project manager, but at the engineering level, it is the responsibility of the project systems engineering staff. It is essential that the same two coordinating functions described above be provided for the entire contractor team. For this purpose, conventional formal contractual mechanisms never suffice and sometimes hinder. Accordingly, special efforts should be made to integrate the team members effectively into the total system development effort. This needs to be carried out at two levels: (i) periodic program management reviews attended by top‐level representatives of the contractor team and (ii) frequent technical coordination meetings concerned with specific ongoing aspects of the program. 4. The principal leaders of the system design effort must have a regular and ­frequent means of communication with one another to keep the program closely coordinated and to react quickly to problems. This is discussed in the following paragraphs.

Systems Analysis Staff An essential part of any systems engineering organization is a highly competent and experienced analytical staff. Such a staff need not be a single entity, nor does it need to be organizationally colocated with the project staff itself, but it must be part of the systems engineering organization, at least during the conceptual and early engineering phases of the project. The systems analysis staff must have a deep understanding of the system environment, with respect to both its operational and physical characteristics. In both instances, it must be able to model the system environment, by use of mathematical and computer models, to provide a basis for analyzing the effectiveness of system models. In the concept exploration phase, the systems analysis staff is the source of much of the quantitative data involved in defining the system performance required to meet its operational requirements. In the concept definition phase, the analysis staff is responsible for constructing the system simulations used in the trade‐off studies and the selection of the best system concept. Throughout the engineering

114

SYSTEMS ENGINEERING MANAGEMENT

development stage of the program, the analysis staff is involved in numerous component trade‐off studies. It conducts test analyses to derive quantitative measures of the performance of system prototypes and contributes to defining the quantitative aspects of system design specifications. While the systems analysis staff must be skilled in mathematical modeling, software design, and other specialized techniques, its members are also required to have a system perspective and a thorough knowledge of the operational requirements of the system under development.

System Design Team The exercise of leadership and coordination in any large program requires one or more teams of key individuals working closely together, maintaining a general consensus on the conduct of the engineering program. A system design team for a complex system development project may have the following membership: • • • • • • •

SE Lead subsystem engineers Software SEs Support engineers Test engineers Customer representative Specialty and concurrent engineers

The customer representative is an advocate for the system requirements. The advantage of the team approach is that it generally increases the esprit de corps and motivation of the participants, and broadens their understanding of the status and problems of other related aspects of the system development. This develops a sense of ownership of the team members in the overall system, rather than the limitation of responsibility that is the rule in many organizations. It makes response to unexpected problems and other program changes more effective. In a particular application, the leadership of the system development needs to be tailored to the prime contractor’s organization and to the customer’s level of involvement in the process. The most important common denominators are: 1. Quality of leadership of the team leader 2. Representation of those with key responsibilities 3. Participation of key technical contributors Without energetic leadership, the members of the system design team will flounder or go their separate ways. If for some reason the person designated as the project SE does

SUMMARY

115

not have the required personal leadership qualities, either the project engineer or a deputy SE should assume the team leadership role. The presence of the leaders of the major portion of the development effort is necessary to bring them into the design decision process, as well as to have them available to use their resources to resolve problems. There are usually several senior SEs whose experience and knowledge are of great value to the project. Their presence adds a necessary ingredient of wisdom to the design process. Involvement of the customer in the design process is essential, but in many cases may be an inhibiting influence on free discussion in team meetings. Frequent but more formal meetings with the customer may be preferred to team membership.

4.5 SUMMARY Managing System Development and Risks Systems engineering is a part of project management that provides technical guidelines, system integration, and technical coordination. The PM, project manager, and SE all play key roles in the planning, budgeting, and execution of the system.

Work Breakdown Structure The SE’s role also involves contributing to resource allocation, task definition, and customer interaction; with the initial focus on the development of the WBS, a hierarchical task organization that subdivides total effort into successively smaller work elements. This provides the basis for scheduling, costing, and monitoring, and enables cost control and estimating. One key tool used for program scheduling is the critical path method (CPM). CPM is based on WBS work elements and creates a network of sequential activities. Analyzing this network enables the SE and PM to identify paths that take the longest to complete.

Systems Engineering Plan and Systems Engineering Management Plan The SEP often associated with US government contracts, addresses the program’s requirements, overall technical approach, and metrics for the program. SEMP plans implementation of all systems engineering tasks. In the process, it defines roles and responsibilities of all participants.

Organization of Systems Engineering The systems engineering organization spans disciplines and participating organizations but also adapts to the company organizational structure. Therefore, systems engineering must communicate effectively “what, when, and why” to the proper stakeholders, and

116

SYSTEMS ENGINEERING MANAGEMENT

provides technical reviews for all participants. In large programs, systems engineering is supported by a system analysis staff. Large programs will require formal system design teams, which integrate major subsystems and subcontractors, and the products of software systems engineering. These teams contain members from support engineering and the test organization, and typically contain specialty (concurrent engineering) members as appropriate. They may also include user representation when appropriate. A key role for systems engineering involvement in these design teams is to keep their focus on the success of the entire enterprise.

PROBLEMS 4.1 Developing a detailed WBS for a system development project is a basic function of project management. What part should be played by systems engineering in the definition of the WBS in addition to detailing the section named “systems engineering”? 4.2 The preparation of a formal SEMP is usually a required portion of a contractor’s proposal for a competitive system development program. Since at this time the system design is still in a conceptual state, explain where you would get the information to address the elements of a typical SEMP as listed in this chapter. 4.3 Research the building of the tunnel under the English Channel in the late twentieth century. (i) What risks were present with this project? (ii) What successful activities were undertaken to mitigate these risks that led to the tunnel’s completion? 4.4 Describe the general type of the organizational structure in which you work. Discuss instances where this structure has been beneficial, and those where it has not been so beneficial to programs you have been involved in or have some knowledge of. 4.5 Discuss the advantages of using the system design team approach for a large development project. List and discuss six requirements that are needed to make this approach successful.

FURTHER READING Blanchard, B. (2004). System Engineering Management, 3e. Wiley. Blanchard, B. and Fabrycky, W. (2013). System Engineering and Analysis, 5e. Prentice Hall. Chase, W.P. (1974). Management of Systems Engineering. Wiley, Chapters 2 and 8. Eisner, H. (2008). Essentials of Project and Systems Engineering Management, 3e. Wiley. Hall, A.D. (1962). A Methodology for Systems Engineering. Van Nostrand, Chapter 4.

FURTHER READING

117

Kendrick, T. (2003). Identifying and Managing Project Risk: Essential Tools for Failure‐Proofing Your Project. American Management Association. Pressman, R.S. (2014). Software Engineering, A Practitioner’s Approach, 8e. McGraw Hill. Rechtin, E. (1991). Systems Architecting: Creating and Building Complex Systems. Prentice Hall, Chapter 14. Sage, A.P. (1992). Systems Engineering. McGraw Hill, Chapter 3. Sage, A.P. and Armstrong, J.E. Jr. (2000). Introduction to Systems Engineering. Wiley, Chapter 6. Shortell, T.M. (ed.) (2015). INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 4e. Wiley. Smith, P. and Merritt, G. (2002). Proactive Risk Management: Controlling Uncertainty in Product Development. Productivity Press. Stevens, R., Brook, P., Jackson, K., and Arnold, S. (1998). Systems Engineering, Coping with Complexity. Prentice Hall, Chapter 6.

PART II CONCEPT DEVELOPMENT STAGE

5 NEEDS ANALYSIS

5.1 ORIGINATING A NEWSYSTEM The primary objective of the needs analysis phase of the system life cycle is to show clearly and convincingly that a valid operational need (or potential market) exists for a new system or a major upgrade to an existing system, and that there is a feasible approach to fulfilling the need at an affordable cost and within an acceptable level of risk. It answers the question of why a new system is needed, and shows that such a system offers a sufficient improvement in capability to warrant the effort to bring it into being. This is achieved, in part, by devising at least one conceptual system that can be shown to be functionally capable of fulfilling the perceived need, and describing it in sufficient detail to persuade decision makers that it is technically feasible and can be developed and produced at an acceptable cost. In short, this whole process must produce persuasive and defensible arguments that support the stated need and create a “vision of success” in the minds of those responsible for authorizing the start of a new system development.

Systems Engineering Principles and Practice, Third Edition. Alexander Kossiakoff, Samuel J. Seymour, David A. Flanigan, and Steven M. Biemer. © 2020 John Wiley & Sons, Inc. Published 2020 by John Wiley & Sons, Inc.

121

122

NEEDS ANALYSIS

Place of the Needs Analysis Phase in the System Life Cycle The exact beginning of the active development of a new system is often difficult to identify. This is because the earliest activities in the origin of a new system are usually exploratory and informal in nature, without a designated organizational structure, ­specified objectives, or established timetable. Rather, the activities seek to determine whether or not a dedicated effort would be warranted, based on an assessment of a valid need for a new system and a feasible technological approach to its implementation. The existence of a discrete phase corresponding to that defined as needs analysis in Chapter 3 is more characteristic of needs‐driven system developments than of those that are technology driven. In defense systems, for example, “material solution analysis” (see DoD life cycle of Figure  3.1) is a required prerequisite activity for the official creation of a specific item in the budget for the forthcoming fiscal year, thereby allocating funds for the initiation of a new system project. Within this activity, a need determination task produces an initial capability description (ICD), which attests to the validity of the system objective or need, and gives evidence that meeting the stated objective will yield significant operational gains and is feasible of realization. Its completion culminates in the first official milestone of the defense acquisition life cycle. Other nondefense systems may also have needs that may be more community driven (such as requiring a new freeway or mass transit system in the case of transportation) or human health issues (such as requiring integrated healthcare services to address multiple health hazards). In a technology‐driven system development, typical of new commercial systems, the needs analysis phase is considered to be part of the conceptual development stage (Figure 3.2). An example would be the telecommunications industry, where new products and capabilities from the competition will drive newer systems development to capture market share. However, in this case too, there must be similar activities, such as market analysis, assessment of competitive products, and assessment of deficiencies of the current system relative to the proposed new system, that establish a bona fide need (potential market) for a product that will be the object of the development. Accordingly, the discussion to follow will not distinguish between needs‐driven and technology‐driven system developments except where specifically noted. The place of the needs analysis phase in the system life cycle is illustrated in Figure  5.1. Its inputs are seen to be operational deficiencies and/or technological opportunities. Its outputs to the following phase, concept exploration, are an estimate of system operational effectiveness that specify what results a new system should achieve to meet the identified need, together with system capabilities, the output of various operational analyses and system studies, which provide evidence that an affordable system capable of meeting the effectiveness target is feasible. As discussed above and depicted in the figure, the impetus for the initiation of a new system development generally comes from one of multiple sources: (i) the perception of a serious deficiency in a current system designed to meet an important operational need (needs driven) or (ii) an idea triggered by a technological development whose application promises a major advance over available systems in satisfying a need (technology driven) or (iii) for example, emergent global healthcare need that is rapidly

123

ORIGINATING A NEW SYSTEM

Operational deficiencies

System operational effectiveness

Needs analysis

Concept exploration

System studies Technology assessment Operational analysis

Technological opportunities

System capabilities

Figure 5.1.  Needs analysis phase in the system life cycle.

spreading throughout the entire world, or (iv) policy changes to perform daily routines, such as increasing use of autonomous vehicles or smart grids to provide additional capabilities. Any of these may then lead to investigations and analyses that eventually culminate in a program to develop a new system. Quite often several factors contribute to the final decision.

Examples of New System Needs The automobile industry is a prime example where changing conditions have forced the need for system improvements. Beginning in the 1960s, the government made laws that required manufacturers to make substantial improvements in fuel economy, safety, and pollution control. Almost overnight, existing automobile designs were rendered obsolete. These regulations continue to pose a major challenge to the automobile industry because they required technically difficult trade‐offs and the development of many new components and materials. While the government gave manufacturers a number of years to phase in these improvements, the need for innovative design approaches and new components was urgent. In this example, the need for change continues to be triggered by legislative action based on the needs of society as a whole. Examples of technology‐driven new systems are applications of space technology to meet important public and military needs. Here, the development of a range of advanced devices, such as powerful propulsion systems, lightweight materials, and compact electronics, makes the engineering of reliable and affordable spacecraft a practical reality. In recent years, satellite manufacturers have become competitive and often develop superior platforms for communication relays, navigation (GPS), weather surveillance, and a host of surveying and scientific instruments.

124

NEEDS ANALYSIS

A more pervasive example of technology‐driven system developments is the application of computer technology to the automation of a wide range of commercial and military systems. Information and networked systems in particular (e.g. banking, ticketing, routing, and inventory) have been drastically altered by computerization. System obsolescence in these cases has come not from recognized deficiencies, but rather from opportunities to apply rapidly advancing technology to enhance system capabilities, reduce cost, and improve competitive position. Healthcare systems have increased the use of technology to provide additional monitoring of patient vitals, yet still require the human (e.g. nurse or healthcare provider) to observe, process, and take actions based on the displays, sometimes by remote communications. External Events.  As will be seen later in this section, analysis of needs goes on more or less continuously in most major mission or product areas. However, external events often precipitate intensification and focusing of the process; this results in the formulation of a new operational requirement. In the defense area, this may be a finding of a new potential threat, a local conflict that exposes the deficiency in a system, or a major technological opportunity uncovered in a continuing program of concept exploration, or a major deficiency uncovered in periodic operational testing outcome. In the civil products area, a triggering event might be a sudden shift in customer demand or a major technological change, such as the discovery of a radically new product or an opportunity to automate a labor‐intensive process.

Competitive Issues Going from a perceived need to the initiation of a development program requires more than a statement of that need. Regardless of the source of funding (government or private), there is likely to be competition for the resources necessary to demonstrate a bona fide need. In the case of the military, it is not unusual for competition to come from another department or service. For example, should maritime superiority be primarily a domain of the surface or air navy? Or a combination of the two? Should cleaner air be achieved by more restrictions on the automobile engine combustion process or on the chemical composition of the fuel? The answers to these types of questions can have a major impact on the direction of any resulting development. For these reasons, strong competition can be expected from many sectors when it is publicly known that a new system development is under consideration. The task of sorting out these possibilities for further consideration is a major systems engineering responsibility.

Design Materialization Status As described in Chapter 3, the phases of the system development process can be considered as steps in which the system gradually materializes, that is, progresses from a general concept to a complex assembly of hardware and software that performs an operational function. In this initial phase of the system life cycle, this process of materialization has only just started. Its status is depicted in Table 5.1.

TABLE 5.1.  Status of System Materialization at Needs Analysis Phase Concept development

Engineering development

Phase Level

Needs analysis

System

Define system capabilities and effectiveness

Identify, explore, and synthesize concepts

Define selected concept with specifications

Validate concept

Test and evaluate

Define requirements and ensure feasibility

Define functional and physical architecture

Validate subsystems

Integrate and test

Allocate functions to components

Define specifications

Design and test

Allocate functions to subcomponents

Design

Subsystem

Component

Subcomponent

Part

Visualize

Concept definition

Advanced development

Engineering design

Integration and evaluation

Concept exploration

Integrate and test

Make or buy

125

126

NEEDS ANALYSIS

The focus of attention in this phase is on the system operational objectives, and goes no deeper than the subsystem level. Even at that level, the activity is listed as “visualize” rather than definition or design. The term visualize is used here and elsewhere in the book in its normal sense of “forming a mental image or vision,” implying a conceptual rather than a material view of the subject. It is at this level of generality that most designs first originate, drawing on analogies from existing system elements. Table  5.1 oversimplifies the representation of the evolving state of a system by implying that all of its elements begin as wholly conceptual and evolve at a uniform rate throughout the development. This is very seldom, if ever, the case in practice. To take an extreme example, a new system based on rectifying a major deficiency in one of the subsystems of its predecessor may well retain the majority of the other subsystems with little change, except perhaps in the selection of production parts. Such a new system would start out with many of its subsystems well advanced in materialization status, and with very few, if any, in a conceptual status. Similarly, if a new system is technology driven, as when an innovative technical approach promises a major operational advance, it is likely that parts of the system not directly involved in the new technology will be based on existing system components. Thus, the materialization status of the system in both examples will not be uniform across its parts, but will differ for each part as a function of its derivation. However, the general principle illustrated in the table is nevertheless valuable for the insight it provides into the system development process.

Applying the Systems Engineering Method in Needs and Requirements Analysis As the initial phase in the system development cycle, the needs analysis phase is inherently different from most of the succeeding phases. There being no preceding phase, the inputs come from different sources, especially depending on whether the development is needs driven or technology driven, and on whether the sponsor is the government or a commercial company. Nevertheless, the activities during the needs analysis phase can be usefully discussed in terms of the four basic steps of the systems engineering method described in Chapter  3, with appropriate adaptations. These activities are summarized below: the generic names of the individual steps as used in Chapter 3 are listed in parentheses. Operations analysis (Requirements analysis). Typical activities include: •

Analyzing projected needs for a new system, either in terms of serious deficiencies of current systems or the potential of greatly superior performance or lower cost by the application of new technology.

ORIGINATING A NEW SYSTEM

• •

127

Understanding the value of fulfilling projected needs, by extrapolating over the useful life of a new system. Defining quantitative operational objectives and the concept of operation.

The general products of this activity are a list of operational objectives and system capabilities. Functional analysis (Functional definition). Typical activities include: Translating operational objectives into functions that must be performed. • Allocating functions to subsystems by defining functional interactions and ­organizing them into a modular configuration. •

The general product of this activity is a list of initial functional requirements. Feasibility definition (Physical definition). Typical activities include: • Visualizing the physical nature of subsystems conceived to perform the needed system functions. • Defining a feasible concept in terms of capability and estimated cost by varying (trading off) the implementation approach as necessary. The general product of this activity is a list of initial physical requirements. Needs validation (Design validation). Typical activities include: • Designing or adapting an effectiveness model (analytical or simulation) with operational scenarios, including economic (cost, market, etc.) factors. • Defining validation criteria. • Demonstrating the cost‐effectiveness of the postulated system concept, after suitable adjustment and iteration. • Formulating the case for investing in the development of a new system to meet the projected need. The general products of this activity are a list of operational validation criteria.Given a successful outcome of the needs analysis process, it is necessary to translate the ­operational objectives into a formal and quantitative set of operational requirements. Thus, this phase produces four primary products. Operational requirements refer largely to the mission and purpose of the system. The set of operational requirements will describe and communicate the end state of the world after the system is deployed and operated. Thus, these types of requirements are broad and describe the overall objectives of the system. All references relate to the system as a whole. Some organizations refer to  these requirements as capability requirements, or simply required capabilities.

128

NEEDS ANALYSIS

Functional requirements refer largely to what the system should do. These requirements should be action‐oriented and describe the tasks or activities the system performs during its operation. Within this phase, they refer to the system as a whole; but they should be largely quantitative. These will be significantly refined in the next two phases. Performance requirements refer largely to how well the system should perform its requirements and affect its environment. In many cases, these requirements correspond to the two types above and provide minimal numerical thresholds. These requirements are almost always objective and quantitative, though exceptions occur. These will be significantly refined in the next two phases. Physical requirements refer to the characteristics and attributes of the physical system and the physical constraints placed upon the system design. These may include appearance, general characteristics, as well as volume, weight, power, material, and external interface constraints to which the system must adhere. Many organizations do not have a special name for these and refer to them simply as constraints, or even system requirements. These will be significantly refined in the next two phases. For new start systems, the first iteration through the needs and requirements analysis phase results in a set of operational requirements that are rather broad and not completely defined. The requirements‐like document that emerges from the needs analysis is formally known as the ICD. This term is also used as a generic description of capabilities desired. In either case, the ICD document contains a broad description of the system concept needed, and focuses on operational, or capability, requirements. Only top‐level functional, performance, and physical requirements are included. Later ­documents will provide detail to this initial list. The elements of the systems engineering method as applied to the needs analysis phase, described above, are displayed in the flow diagram of Figure 5.2, with appropriate modifications for the activities in this phase. Rectangular blocks represent the four basic steps and the principal activities are shown as circles, with the arrows denoting information flow. The inputs at the top of the diagram are operational deficiencies and technological opportunities. Deficiencies in current systems due to obsolescence or other causes are need‐drivers. Technological opportunities resulting from an advance in technology that offers a potential major increase in performance or decrease in cost of a marketable system are technology‐drivers. In the latter case, there must also be a projected concept of operation for the application of the new technology. The two middle steps are concerned with determining if there is at least one possible concept that is likely to be feasible at an affordable cost and acceptable risk. The validation step completes the above analysis and also seeks to validate the significance of the need being addressed in terms of whether or not it is likely to be worth the investment in developing a new system. Each of these four steps is further detailed in succeeding sections of this chapter.

129

ORIGINATING A NEW SYSTEM

Operational deficiencies

Technology opportunities

Analyze projected needs

Predecessor system

Operations analysis

Define operational approach

Partitioning criteria

Operational objectives

Predecessor system

Translate into functions

Related systems

Functional analysis

Allocate functions to subsystems

Feasibility criteria Subsystem functions Predecessor system

Visualize subsystem technology

• Building blocks • New concepts

Unrealistic objectives

Previous analytical models

Feasibility definition

Define feasible concept

Feasible system concept

Design effectiveness model

Concept deficiencies

Validate needs and feasibility

Operational requirements

Measures of effectiveness

Needs validation

Concept exploration phase

Figure 5.2.  Needs analysis phase flow diagram.

User Interaction Users are needed for consultation on whether the needs are valid and to prioritize the needs, whether they are needed or require new needs. This is typically based on experience with the legacy systems and identification of deficiencies based on changes in mission or threats. Users may be consulted in a variety of methods – interviews allow

130

NEEDS ANALYSIS

a means of follow‐up questions, while surveys can reach a larger range of users. A wide variety of users should also be consulted to capture the needs, as a variety of perspectives can uncover many more needs of the system concept before it comes to market.

Customer Satisfaction Customer satisfaction is a continual process to determine if the system is performing satisfactorily. Often, comments from the customer may uncover different features that could be valuable for the future iterations of the system. Pay attention to the customer as they describe what is liked and what is not liked, a variety of information may be gained: operating instructions/procedures may not be as clear as the engineer designed it; customers may operate the system in an environment not originally designed for; or human factors may prompt a redesign of the system to accommodate a greater range of customers. All of these comments are valuable to the systems engineer to understand what could be improved for the future system and supporting infrastructure. Note that MBSE support non‐textual requirements in the form of constraints, measures of effectiveness (MOE), and other system properties. As the discipline matures, it is likely that some hybrid approach, including traditional textual requirements, property‐based requirements, and collections of other system elements (for example, a well‐formed state machine that includes rigorous definitions of state transitions and behaviors), will be used to communicate intent to stakeholders and those involved in the systems engineering process.

5.2  SYSTEMS THINKING When determining the need for a new system, or in fact while conducting each phase of the system development, the systems engineer should adopt the role of systems thinking. In leading and guiding teams in the development of complex and highly integrated systems, the key to understanding the need and design of the system is to consider the system in a holistic perspective. The full life cycle of the system takes into account the stakeholders’ expectations, the systems users, the advancing rate of technology, the operational and physical environment, and the social and policy influences. Systems thinking should be a part for each contributor of the system development. The practicing systems engineer is the quintessential systems thinker. Systems thinking is a set of habits or practices within a structure that is based on the principle that the parts of a system are best understood within the framework of relationships of the parts with each other and with other systems, rather than in isolation. From design through production, the focus is whether you are developing the right thing, e.g. are customer requirements being met; are users satisfied with system performance; are interactions with other systems compatible; are implications of change understood; are the systems dynamics expected and smooth; and are outcomes economically acceptable and sound. This way of thinking is continually engaged in validation

SYSTEMS THINKING

131

and verification of all aspects of the system. All domains that touch the system have needs met and everyone buys into the design. A systems thinker understands and sees the big picture; recognizes interconnections; and can view multiple perspectives. At the same time, the systems thinker is creative and not stuck on details. Effectively they are able to “see” the future. Systems thinking must also anticipate unexpected behavior in complex systems when the subsystems are integrated or encounter new environments. This emergent behavior of unintended consequences can be avoided by thinking in advance how the system would perform and accommodate appropriate design and development changes. Hence, you are encouraged to think about problems and solutions with an eye toward the long view for the whole system. Not only can requirements change but also the world view of concepts and solution may change. Technical and societal advances create new challenges and opportunities that need to be incorporated into the system design. While successful revolutionary products are welcomed, single‐purpose designs may not meet future trends. Strong leaders design robust and resilient systems and communicate effectively to the stakeholders and the design team. A systems behavior or response to sensor input is dynamic due to the interactions and connections that cause a feedback loop between output and input to a subsystem. Systems thinking identifies the operational environments, especially in social contexts, for threats that directly or indirectly will influence performance. The thinking must take on a temporal perspective, recognizing initial design concepts may need to be broader than limited initial needs and requirements, and that over time, more robust approaches may be needed. The systems engineer when thinking holistically, considers the world as a system of subsystems that are all interconnected and interact to influence each other and the external environment. Systems thinking can then be used to analyze the different factors in the system’s role within the operational environment, and how systems engineers can identify relationships and evaluate how the system plays a role within the larger picture. Kasser and Mackley (2008) present an overview of the different perspectives that one can view systems in a holistic perspective. Many are principles that are used in systems engineering, and they should be applied to understand how the system concept can operate within the “larger picture” to include the operational environment. These are operational (applying use cases and concepts of operations to identify how the system will work in the environment), functional (defining what functions are needed to operate), big picture (viewing the system in a context diagram approach to identify other relevant actors and the interdependencies between them), structural (system architecture for internal and external connections), generic (looking for similar properties from similar systems and inheriting them), continuum (how do failures of other interdependent systems affect our system?), temporal (evaluating system behavior as a function of time, which may depend on the interdependency), quantitative (how to develop the mathematical relationships in the models and simulations), and scientific (how to formulate and test the hypotheses). The sections below will show such systems thinking occurring during the systems engineering process.

132

NEEDS ANALYSIS

Examples of Systems Thinking Common systems thinking methods and tools include systems dynamics and causal loop diagrams. These show the relationships between various contributors and the system can show the effects of changing relationships, and the behavior of the system(s) over time as the inputs and outputs change. Other popular tools include agent‐based modeling to define the attributes and behavior of a contributor and how it operates depending on the external environment changes. These approaches can then provide guidance on how the system will be expected to operate, determine what types of relationships are required, and also to help define the required behavior based on the context of the system. An example of how systems thinking is applied to show how the problem can be described, identifying the relevant actors and relationships, and can aid in defining desired behavior and performance. Consider the social system for immunization rates in Kerala, India, to understand coverage and overall household trust in immunization (Varghese et al. 2014). The first‐order effects focus on household immunization, influenced by both private and public doctors, as well as health field workers. When a polio campaign was introduced as part of the Global Polio Eradication Initiative, a separate series of causal loop diagrams (second‐ and third‐order effects) discovered additional sources that would either support or oppose the immunization efforts, to include alternative providers, religious leaders, academic/private doctors, media coverage, and side effects of a Japanese encephalitis vaccination in a nearby state that caused ­additional public debate and opinions on household trust. Consider next a systems thinking example in the development of an advanced automated automobile system (AAS). The self‐driving vehicle would have more independence than those of today. The SE would decompose the system into subsystems, e.g. the vehicle, location sensors, sensors for detection and identification of other vehicles and objects, communication systems, control systems, vehicle riders. Then, one would consider the situation awareness – the internal and external environment – and the full set of surveillance capability, as well as the vehicle reaction time. But are road and weather conditions effects included? Can sensors and control systems accommodate future highway effects and signals? What if a rider would override the controls and chose to exceed the speed limits? Can planned AAS subsystems be reengineered or refitted to detect, identify, and react to the new targets? Many other systems thinking questions need to be raised to draw implications and answers that would change perceived needs and conceptual designs. Otherwise, the next AAS produced would have a short road life.

5.3  OPERATIONS ANALYSIS Whether the projected system development is needs driven or technology driven, the first issue that must be addressed is the existence of a valid need (potential market) for a new system. The development of a new system or major upgrade is likely to be very costly, and will usually extend over several years. Accordingly, a decision to initiate such a development requires careful and deliberate study.

OPERATIONS ANALYSIS

133

Analysis of Projected Needs In the commercial sector, market studies are continuously carried out to assess the performance of existing products and the potential demand for new products. Customer reactions to product characteristics are solicited. The reason for lagging sales is ­systematically probed. The strengths and weaknesses of competing systems and their likely future growth are analyzed. For military systems, each service has one or more systems analysis organizations whose responsibility is to maintain a current assessment of their operational capability and readiness. These organizations have access to intelligence assessments of changes in the military capability of potential adversaries that serve as inputs to effectiveness studies. In addition, periodic operational tests, such as simulated combat at sea, landing operations, and so on, serve to provide evidence of potential deficiencies that may signal the need for developing a more capable system. A particularly important consideration is whether or not modification of doctrine, strategy, or tactics can better meet the need with existing assets, thus reducing the urgency of acquiring expensive new assets. Deficiencies in Current Systems.  In virtually all cases, the need addressed by a projected new system is already being fulfilled, at least in part, by an existing system. Accordingly, one of the first steps in the needs analysis process is the detailed identification of the perceived deficiencies in the current system. If the impetus for the new system is technology driven, the current system is examined relative to the predicted characteristics achieved with the prospective technology. For commercial systems, these deficiencies may be to keep up with competition, upgrade from outdated technology, address emerging threats, or merge capabilities based on consumer demand. Since the development of a successor system or even a major upgrade of an existing system is likely to be technically complex and requires years of challenging work, operational studies must focus on conditions as much as 10 years in the future. This means that the system owner/user must continually extrapolate the conditions in which the system operates and reevaluate system operational effectiveness. In this sense, some form of needs analysis is being conducted throughout the life of the system. The above process is most effective when it combines accumulated test data with analysis, often using existing system simulations. This approach provides two major benefits: a consistent and accurate evaluation of system operational performance and a documented history of results, which can be used to support the formal process of needs analysis if a new development program becomes necessary. Obsolescence.  The most prevalent single driving force for new systems is obsolescence of existing systems. System obsolescence can occur for a number of reasons, for example, the operating environment may change, the current system may become too expensive to maintain, the parts necessary for repair may be no longer available, competition may offer a much superior product, or technology may have advanced to the point where substantial improvements are available for the same or lower cost. These examples are not necessarily independent; combined elements of each can greatly

134

NEEDS ANALYSIS

accelerate system obsolescence. Belated recognition of obsolescence can be painful for all concerned. It can significantly delay the onset of the needs analysis phase until time becomes critical. Vigilant self‐evaluation should be a standard procedure during the operational life of a system. An essential factor in maintaining a viable system is keeping aware of advances in technology. Varied R&D activities are carried out by many agencies and industry. They receive support from government or private funding or combinations of both. In the defense sector, contractors are authorized to use a percentage of their revenues on relevant research as allowable overhead. Such activity is called independent research and development (IRAD). There are also a number of wholly or partially government‐ funded exploratory development efforts. Most large producers of commercial products support extensive applied R&D organizations. In any case, the wise system sponsor, owner, or operator should continually keep abreast of these activities and be ready to capitalize on them when the opportunity presents itself. Competition at all levels is a potent driver of these activities. Examples of commercial product development may emerge to incorporate features that newer technologies can provide, such as 4G wireless service, precision location from GPS services, and crowdsourcing of information (such as traffic reporting, product selling, or information providing).

Operational Objectives The principal outcome of operational studies is the definition of the objectives, in operational terms, that a new system must meet in order to justify its development. In a needs‐driven development, these objectives must overcome such changes in the environment or deficiencies in the current system as have generated the pressure for an improved system. In a technology‐driven development, the objectives must embody a concept of operations (CONOPS) that can be related to an important need. The term “objectives” is used in place of “requirements” because at this early stage of system definition the latter term is inappropriate; it should be anticipated that many iterations (see Figure  5.2) would take place before the balance between operational performance and technical risk, cost, and other developmental factors will be finally established. Although objectives should be quantifiable and objective, the reality is that most are qualitative and subjective at this early stage. Some rules of thumb can be helpful: •

•

Objectives should address the end state of the operational environment or ­scenario – it focuses on what the system will accomplish in the large sense; an end state example from the transportation sector may be to attain a certain behavior from the operational environment, such as increasing miles per gallon efficiency and increasing the renewable energy source infrastructure throughout the nation. Objectives should address the purpose of the system and what constitutes the satisfaction of the need. These would identify quantitative values to determine

135

OPERATIONS ANALYSIS

• •

if the objective was satisfied or not, such as one million metric tons of carbon dioxide removed within a city in a day. Taken together, objectives answer the “why” question  –  why is the system needed? Most objectives start with the infinitive word “provide,” but this is not mandatory.

Objectives Analysis.  The term objectives analysis is the process of developing and refining a set of objectives for a system. Typically, the product of this effort is an objectives tree, where a single or small set of top‐level objectives are decomposed into a set of primary and secondary objectives. Figure 5.3 illustrates this tree. Decomposition is appropriate until an objective becomes verifiable, or you begin to define functions of the system. When that occurs, stop at the objective. The figure illustrates functions by graying the boxes – they would not be part of your objectives tree. In our experience, most objective trees span one or two levels deep; there is no need to identify extensive depth. As an example of an objectives analysis, think about a new automobile that can be marketed as “green” or environmentally friendly. Understanding the objectives of this new car establishes priorities for the eventual design. Objectives analysis forces the management and the technical staff to evaluate and decide what is important when developing a new system. Therefore, it is worth investing some time, energy, and capital

Overarching objective

Primary objective

Primary objective

Secondary objective

Primary objective

Secondary objective

Secondary objective

Secondary objective

Function

Function

Function

Function

Function

Function

Function

Figure 5.3.  Objectives tree structure.

Secondary objective

136

NEEDS ANALYSIS

in determining the overall objectives of the system. Moreover, agreeing to a concise single statement helps focus the development team to the job at hand. In the automobile example, the company might soon realize that the overall objective of this new vehicle is to provide users with clean transportation. The top‐level objective does not include performance, cargo capacity, off‐road capability, etc. What is in the overall objective are two key words: clean and transportation. Both imply various aspects or attributes of this new car. Since both words are not yet well defined, we need to decompose them further. But the overall goal is clear: this vehicle is going to be environmentally “clean” and provide sufficient transportation. The first decomposition focuses the thinking of the development team. Clearly, the two key words need to be “fleshed out.” In this case, “clean” may mean “good gas mileage” as well as “comfortable.” Transportation also implies a safe and enjoyable experience in the vehicle as it travels from one point to the next. There may also be another objective that is loosely tied to clean and transportation – cost. Note that some objectives may not have supporting functions and may not require further decomposition. Generally, all secondary objectives would need to be satisfied before we can claim that the primary objective is satisfied. Thus, in our example, the development team focuses on four primary objectives that flow from our overarching objective: comfort, mileage, safety, and cost. Figure 5.4 presents one possibility of an objectives tree. In determining whether an objective needs further decomposition, one should ask a couple of questions: • • • •

Does the objective stand on its own in terms of clarity of understanding? Is the objective verifiable? Would decomposition lead to better understanding? Are requirements and functions readily implied by the objective?

Provide clean transportation

Provide a comfortable ride for four passengers

Provide a sound system that satisfies customer base

Allow for normal conversation

Achieve ≥35 mpg

Meet all federal safety standards

Provide sufficient head, shoulder, and leg room

Figure 5.4.  Example objectives tree for an automobile.

Achieve a base retail price of $ 25K

OPERATIONS ANALYSIS

137

In our example, one could argue that three of the primary objectives are sufficient as stated, and all three are verifiable. Only the subjective objective relating to comfort needs further decomposition. In this case, comfort can be divided into three components: a sound system, noise levels that allow conversation, and physical space. As worded in the figure, these three could all be verified by various methods (a satisfaction survey in the first, a definition of noise levels for normal conversation, and volume requirements). Having an objectives tree focuses the development effort on the priorities. In our example, the four primary objectives communicate what is important with this new automobile. In many cases where objective trees are used, an initial tree will be similar to our example, listing only those objectives that are the highest priorities. These trees would then be expanded to include other areas that will need to be addressed. For our automobile, these “other” areas would include maintenance considerations, human–system interaction expectations, and cargo space, to name a few. An objective of having an objectives tree is ultimately to identify the CONOPS, the functions, and their performance requirements.

Concept of Operations Although the two terms are often used synonymously, in truth, an operational concept is a broader description of a capability that encompasses multiple systems. It tends to describe how a large collection of systems will operate. An example would include an operational concept for the US transportation system (or even a subsystem of the whole system). In this case, “system” does not refer to a single system but a collection or family of systems. Another example would be an operational concept for an oil refinery – again referring to how a collection of systems would operate together. When referring to a single system, the term CONOPS is generally used. A further distinction relates to scenarios. An operational concept is sufficiently broad to be scenario‐ independent. A CONOPS is intended to show how a system concept will work in the operational environment. It is informed by early systems engineering artifacts, such as context diagrams (shows which systems, users, or threats the system will operate with), use cases (which cases/conditions and with specific actors), and functional architecture artifacts such as activity or sequence diagrams (what the system intends to perform). The CONOPS is informed by users by describing the logics and/or tactics that they intend to employ the system in order to help inform system design by describing how well the system is expected to operate. As the CONOPS can be fairly detailed, the description may be limited to a single scenario or a set of related scenarios. Operational concepts are useful since requirements should avoid prescribing how they should be fulfilled. Requirements documents risk inadvertently barring an especially favorable solution. However, a set of operational requirements alone is often insufficient to constrain the system solutions to the types desired. For example, the operational requirements for defending an airplane against terrorist attack could ­conceivably be met by counter weapons, passenger surveillance, or

138

NEEDS ANALYSIS

sensor technology. In a particular program initiative, the requirements would be constrained by adding a CONOPS, which would describe the general type of counter weapons that are to be considered. This extension of the operational requirement adds constraints, which express the customer’s expectation for the anticipated system development. The term CONOPS is quite general. The components of a CONOPS usually include: 1. mission descriptions, with success criteria; 2. relationships with other systems or entities; 3. information sources and destinations; and 4. other relationships or constraints. The CONOPS should be considered as an addition to the operational requirements. It defines the general approach, though not a specific implementation, to the desired system, thereby eliminating undesired approaches. In this way, the CONOPS clarifies the intended goal of the system. The CONOPS should be prepared by the customer organization or by an agent of the customer and should be available prior to the beginning of the concept definition phase. Thereafter, it should be a “living” document, together with the operational requirements document. Figure 5.5 provides an overview of the triumvirate of conceptual design to describe requirements, scenarios, and CONOPS.

Operational requirements Functional and performance requirements

Why

What How much

System concept

Operational concept (Concept of operations)

Operational context (Scenarios)

How

Where

Who

When

Figure 5.5.  Triumvirate of conceptual design.

OPERATIONS ANALYSIS

139

Scenarios A description of an operational context is the last piece of the triumvirate in defining the system concept. This description (as depicted in Figure 5.6) focuses on the where and when. Specifically, an operational context description describes the environment within which the system is expected to operate. A specific instantiation of this context is known as a scenario. A scenario can be defined as: a sequence of events involving detailed plans of one or more participants and a description of the physical, social, economic, military, and political environment in which these events occur. With respect to system development, scenarios are typically projected into the future to provide designers and engineers a context for the system description and design. Most scenarios include at least five elements: 1. Mission objectives: a description of the overall mission with success criteria. The reader should notice this is the same as one of the components of a CONOPS. The mission can be of any type: e.g. military, economic, social, or political. 2. Friendly parties: a description of friendly parties and systems, and the relationships among those parties and systems. 3. Threat actions (and Plans): a description of actions and objectives of threat forces. These threats need not be human; they could be natural (e.g. volcano eruption). 4. Environment: a description of the physical environment germane to the mission and system. 5. Sequence of events: a description of individual events along a timeline. These event descriptions should not specify detailed system implementation details. Scenarios come in all sizes and flavors. The type of scenario is determined by the system in questions and the problem being examined. Figure 5.6 shows different levels of scenarios that might be needed in a system development effort. During the early phases (Needs analysis and concept exploration), the scenarios tend to be higher levels, near the top of the pyramid. As the development effort transitions to later phases, more detail is available as the design improves, and lower‐level scenarios are used in engineering analyses. High‐level scenarios continue to be used throughout to estimate the overall system effectiveness as the design matures.

Operational Scenarios A logical method of developing operational requirements is to postulate a range of scenarios that together are representative of the full gamut of expected operational ­situations. These scenarios must be based on an extensive study of the operational environment, discussions with experienced users of the predecessor and similar systems,

140

NEEDS ANALYSIS

Global

Estimate total system architecture effectiveness over an extended period of time (beyond one cycle)

Environment

Estimate total system effectiveness within an architecture over one business cycle

System

Estimate system effectiveness in its local environment

Subsystem

Estimate performance of individual components of the system

Figure 5.6.  Hierarchy of scenarios.

and a detailed understanding of past experience and demonstrated deficiencies of current systems. It is especially important to establish the user priorities for the required improvements, in particular, those that appear most difficult to achieve. While scenarios range widely in their content depending on their application, we define five basic components of almost all scenarios. 1. Mission objectives. The scenario should identify the overall objectives of the mission represented, and the purpose and role of the system(s) in focus in accomplishing those objectives. In some cases, this component is system‐independent, meaning that the role of any one system is not presented – only a general description of the mission at stake and the objectives sought. In a commercial example, the mission could be to capture market share. In a government example, the mission might be to provide a set of services to constituents. In a military example, the mission might be to take control of a particular physical installation. 2. Architecture. The scenario should identify the basic systems architecture involved. This includes a list of systems, organizations, and basic structural information. If governance information is available, this would be included. This component could also include basic information on system interfaces, or a description of the information technology infrastructure. In essence, a description of the resources available is provided. In a commercial scenario, the resources of the organization are described. If this is a government scenario, the organizations and agencies involved in the mission are described. If this is a military scenario, these resources could include the units involved, with their equipment.

OPERATIONS ANALYSIS

141

3. Competition. The scenario should identify competition to your efforts. This may be elements that are directly opposed to your mission success, such as a software hacker or other type of “enemy.” This may be your competition in the market or outside forces that influence your customers. This could also include natural disasters, such as a tsunami or hurricane. 4. Physical environment. The scenario should identify the environment in which the scenario takes place. This would include the physical environment (e.g. terrain, weather, transportation grid, and energy grid) as well as the business environment (e.g. recession, growth period). “Neutral” entities are described in this section. For example, customers and their attributes would be defined; or neutral nations and their resources. The scenario should describe a general sequence of events within the mission context. We are careful to use the term general though. The scenario should allow for freedom of action on the part of the players. Since we use scenarios to generate operational requirements and estimate system effectiveness, we need the ability to alter various parameters and events within the overall scenario description. Scenarios should not “script” the system; they are analysis tools, not shackles to restrain the system development. Thus, scenarios typically provide a general sequence of events and leave the details to an analyst using the scenario. At times, a scenario may provide a detailed sequence of events leading up to a point in time, whereby the analysis starts and actions may be altered from that time forward. A scenario could include much more, depending on its application and intended purpose. They come in all sizes, from a short, graphic description of a few pictures to hundreds of pages of text and data. Even though the operational scenarios developed during this phase are frequently not considered a part of the formal operational requirements document, in complex systems, they should be an essential input to the concept exploration phase. Experience has shown that it is seldom possible to encompass all of the operational parameters into a requirements document. Further, the effectiveness analysis process requires operational inputs in scenario form. Accordingly, a set of operational scenarios should be appended to the requirements document, clearly stating that they are representative and not a comprehensive statement of requirements. As noted above, the scenarios should include not only the active operational inter‐ actions of the system with its environment but also the requirements involved in its transport, storage, installation, maintenance, and logistics support. These phases often impose physical and environmental constraints and conditions that are more severe than normal operations. The only means for judging whether or not requirements are complete is to be sure that all situations are considered. For example, the range of ­temperature or humidity of the storage site may drastically affect system life. Scenario Development Process.  Attached is a simplified process to develop scenarios while in the concept development phase. It provides a template in order to

142

NEEDS ANALYSIS

analyze the problem, as well as ensure that all relevant topics and issues are addressed. A scenario can be defined as “a sequence of events involving detailed plans of one or more participants and a description of the physical, social, economic, military, and political environment in which these events occur.” With respect to system development, scenarios are typically projected into the future to provide designers and engineers a context for the system description and design. Scenario development includes the following steps: Define the mission, mission functions, and mission objectives: this provides a description of the overall mission to include the success criteria. The mission can be of any type, for example, military, economic, social, or political. The reader should notice this will also be decomposed to the functional level in terms of describing what is needed to successfully execute the mission. Objectives provides a benchmark to determine when a mission is deemed successful. Define the friendly parties: this provides a description of friendly parties and systems, and the relationships among those parties and systems. These may be either as‐is (or current) systems and organizations, or may identify the to‐be (for future) elements. Define the threat actions (and Plans): this includes a description of actions and objectives of threat forces that are representative of either current or future threat activity, and usually require some form of official validation of the threat’s capability. For defense systems, this is usually the intelligence community that provides such validation. For healthcare systems, this could be a consortium of SME that identifies emerging threats. For environmental systems, these threats need not be human; they could be natural (e.g. volcano eruption). Define the operational environment: this provides a description of the physical and operational environment that the mission will be accomplished, and who the system will need to operate with. Define the relevant actions and interfaces: this provides a description of the relevant events along a timeline in order to accomplish the mission. These event descriptions should not specify detailed system implementation details, but rather provide context to match friendly party actions against threat actions. Scenarios may also be reviewed by operators that are familiar with the mission space to validate the concepts being explored, as well as provide insight into current and future challenges to their mission.

Social Factors Systems may require some evaluation of the intended users and how the system may be accepted within the social network and organizational culture. User needs should

FEASIBILITY DEFINITION

143

explore how the system is envisioned to perform and interact within the culture, which may require understanding how current and future employees will interact with the system concept. Surveys and interviews as well as market research from peer companies may also provide insight on how the system concept may be received. This is critically important for systems in global use. The system may be used to enhance relationships between individuals, groups, or institutions as one performs their mission. Watson (2017) examines how systems may influence behavior within the organization, organized into sociological ambivalence that may occur when the organization is confronted with conflicting norms. These may range from conflicts of interest (e.g. employee works in several groups or multiple projects that may conflict with project or time priorities) to contradicting organizational cultures.

Mission Analysis Mission analysis may be performed to evaluate how well the mission can be accomplished using the system concept. It may also be used to evaluate how well the organization (and supporting external organizations and entities) also operates while performing the mission. Mission performance as well as post‐mission sustainment and logistics may also be a factor to determining how well the system performed and was maintained for the next mission. These may identify additional requirements and interfaces that support the original system, or may motivate additional nonmaterial changes to improve mission performance. Much attention may be paid to the nonmaterial as well as sustainability of system performance, particularly in austere operating conditions.

5.4  FEASIBILITY DEFINITION The feasibility of a system concept (and therefore of meeting the projected need) cannot be established solely on the basis of its functional design. The issue of feasibility must also address the physical implementation. In particular, system cost is always a dominant consideration, especially as it may compare with that of other alternatives, and this cannot be judged at the functional level. Accordingly, even at this initial phase of system development, it is necessary to visualize the physical makeup of the system as it is intended to be produced. It is also necessary to visualize all external constraints and interactions, including compatibility with other systems. While it is necessary to consider the physical implementation of the projected system in the needs analysis phase, this does not imply that any design decisions are made at this time. In particular, no attempt should be made to seek optimum designs; those issues are dealt with much later in the development process. The focus at this point is to establish feasibility to meet a given set of operational objectives. It is the validation of these objectives that is the primary purpose of the needs analysis phase. The paragraphs that follow discuss some of the issues that need to be considered, but only in an exploratory way.

144

NEEDS ANALYSIS

Visualization of Subsystem Implementation Given the allocation of functions to subsystems, it is necessary to envision how these might be implemented. At this stage, it is only necessary to find examples of similar functional units in existing systems, so that the feasibility of applying the same type of technology to the new system may be assessed. The identification of the principal media involved in each major function (signal, data, material, and energy) is also helpful in finding systems with similar functional elements and hence with physical implementations representative of those required in the new system. Relation to Current System.  Where there exists a system that has been meeting the same general need for which the new system is intended, there are usually a number of subsystems that may be candidates for incorporation in modified form in the new system. Whether or not they will be utilized as such, they are useful in building a case for system feasibility and for estimating part of the development and production cost of the new system. Existing models and simulations of the current system are especially useful tools in this type of analysis, since they will usually have been verified against data gathered over the life of the system. They may be used to answer “What‐if?” questions and find the driving parameters, which help to focus the analysis process. Another important tool, used in conjunction with the system simulation, is an effectiveness model and the analytic techniques of effectiveness analysis. Other less tangible factors can also come into play, such as the existence of a support infrastructure. In the case of the automobile engine, many years of successful operation have established a very wide base of support for conventional reciprocating engines in terms of repair sites, parts suppliers, and public familiarity. Because of the prospective cost for changing this base, innovative changes, such as the Wankel rotary engine and designs based on the Sterling cycle, have been resisted. The point here is that beneficial technological innovations are often overridden by economic or psychological resistance to change. Application of  Advanced Technology. In technology‐driven systems, it is more difficult to establish feasibility by reference to existing applications. Instead, it may be necessary to build the case on the basis of theoretical and experimental data available from such research and development work as has been done on the candidate technology. In case this proves to be insufficient, limited prototyping may be required to demonstrate the basic feasibility of the application. Consultation with outside experts may be helpful in adding credibility to the feasibility investigation. Unfortunately, highly touted technical advances may also come with unproven claims and from unreliable sources. Sometimes a particular technology may offer a very substantial gain, but lacks maturity and an established knowledge base. In such situations, the case for incorporating the technology should be coupled with a comparably capable backup alternative. Systems engineers must be intimately involved in the above process to keep the overall system priorities foremost.

NEEDS VALIDATION

145

Cost.  The assessment of cost is always an important concern in needs analysis. This task is particularly complicated when there is a mix of old, new, and modified subsystems, components, and parts. Here again, cost models and maintenance records of the current system, combined with inflation factors, can be helpful. The long‐term view is important. By comparing similar components and development activities, cost estimation will at least have a credible base from which to work. In the case of new technology, cost estimates should contain provisions for substantial development and testing prior to commitment for its use.

Definition of a Feasible Concept To satisfy the objectives of the needs analysis phase, the above considerations should culminate in the definition and description of a plausible system concept, and a well‐ documented substantiation of its technical feasibility and affordability. The system description should include a discussion of the development process, anticipated risks, general development strategy, design approach, evaluation methods, production issues, and CONOPS. It should also describe how the cost of system development and ­production had been assessed. It need not be highly detailed, but should show that all major aspects of system feasibility have been addressed. In order to evaluate the feasibility of this concept, a new product, the operational concept, sometimes referred to as a CONOPS, addresses how and who. To accompany the CONOPS is a description of the operational context that the system will operate within (sometimes referred to as scenarios), and addresses where and when.

5.5  NEEDS VALIDATION The final and most critical step in the application of the systems engineering method is the systematic examination of the validity of the results of the previous steps. In the case of the needs analysis phase, the validation step consists of determining the basic soundness of the case that has been made regarding the existence of a need for a new system and for the feasibility of meeting this need at an affordable cost and at acceptable risk.

Operational Effectiveness Model In the concept development stage, the analyses that are designed to estimate the degree to which a given system concept may be expected to meet a postulated set of operational requirements is called operational effectiveness analysis. It is based on a mathematical model of the operational environment and of the candidate system concept being analyzed. In effectiveness analysis, the operational environment is modeled in terms of a set of scenarios – postulated actions that represent a range of possible encounters to which

146

NEEDS ANALYSIS

the system must react. Usually, initial scenarios are selected to present the more likely situations, followed by more advanced cases for testing the limits of the operational requirements. For each scenario, the acceptable responses of the system in terms of operational outcomes are used as evaluation criteria. To animate the engagements between the system model and the scenarios, an effectiveness model is designed with  the capability of accepting variable system performance parameters from the system model. Effectiveness analysis must include not only the operational modes of the system but also must represent its nonoperating modes, such as transport, storage, installation, maintenance, and logistic support. Collectively, all the significant operational requirements and constraints need to be embodied in operational scenarios and the accompanying documentation of the system environment. System Performance Parameters.  The inputs from the system model to the effectiveness analysis are values of performance characteristics that define the system’s response to its environment. For example, if a radar device needs to sense the presence of an object (e.g. an aircraft), its predicted sensing parameters are entered to determine the distance at which the object will be detected. If it needs to react to the presence of the object, its response processing time will be entered. The effectiveness model ensures that all of the significant operational functions are addressed in constructing the system model. Measures of  Effectiveness. To evaluate the results of effectiveness simulations, a set of criteria are established that identify those characteristics of the system response to its environment that are critical to its operational utility. These are called “measures of effectiveness”. They should be directly associated with specific objectives and prioritized according to their relative operational importance. MOE and performance are described later in requirements analysis. While the effort required to develop an adequate effectiveness model for a major system is extensive, once developed, it will be valuable throughout the life of the system, including potential future updates. In the majority of cases where there is a current system, much of the new effectiveness model may be derived from its predecessor. The Analysis Pyramid. When estimating or measuring the effectiveness of a system, the analyst needs to determine the perspective within which the system’s effectiveness will be described. For example, the system effectiveness may be described within a larger context, or mission, where the system is one of many working loosely or tightly together to accomplish a result. On the other hand, effectiveness can be described in terms of an individual system’s performance in a given situation in response to selected stimuli, where interaction with other systems is minimal. Figure  5.7 depicts a common representation of what is known as the analysis pyramid. At the base of the pyramid is the foundational physics and physical

147

NEEDS VALIDATION

Strategy Multiple missions Multiple systems/ single mission

System/subsystem

Physics/phenomenology

Figure 5.7.  Analysis pyramid.

p­ henomenology knowledge. Analysis at this end of the spectrum involves detailed evaluation of environmental interactions, sometimes down to the molecular level. As the analyst travels up the pyramid, details are abstracted and the perspective of the analyst broadens, until he reaches the apex. At this level, technical details have been completely abstracted and the analysis focuses on strategy and policy alternatives and implications. The systems engineer will find that typically, analysis perspectives during the needs analysis phase tends to be near the top of the pyramid. Although Strategy may not be in the domain of the system development effort, certainly the system’s effectiveness within a multiple‐mission or single mission context would need to be explored. The lower part of the pyramid is usually not analyzed due to lack of system definition. As the system becomes more defined, the analysis performed will tend to migrate down the pyramid. We will explore the analysis pyramid more as we continue our look at systems engineering within the development phases.

Validation of Feasibility and Need Finally, the effectiveness analysis described above is mainly directed to determining whether or not a system concept, derived in the functional and physical definition process, is (i) feasible and (ii) satisfies the operational objectives required to meet a projected need. It assumes that the legitimacy of the need has been established previously. This assumption is not always a reliable one, especially in the case of technology‐driven system developments, where the potential application is new and its acceptance depends on many intangible factors. A case in point, of which there are hundreds of examples, is the application of automation to a system previously operated

148

NEEDS ANALYSIS

mainly by people. (The airplane reservation and ticketing system is one of the larger successful ones.) The validation of the need for such a system requires technical, ­operational, and market analyses that seek to take into account the many complex factors likely to affect the acceptability of an automated system, and its probable profitability. In complex cases such as the above example, only a very preliminary validation can be expected before considerable exploratory development and experimentation should take place. However, even a preliminary validation analysis will bring out most of the critical issues and may occasionally reveal that the likelihood of meeting some postulated needs may be too problematical to warrant a major investment at the current state of the technology. The primary product of needs analysis is a set of operational objectives, which are then translated into a set of operational requirements. The system operational requirements that result from the needs analysis phase will establish the reference against which the subsequent development of a system to meet the projected needs will be judged. Accordingly, it is essential that these requirements be clear, complete, consistent, and feasible of accomplishment. The feasibility has presumably been established by the identification of at least one system approach that is judged to be both feasible and capable of meeting the need. It remains to make certain that the operational requirements are adequate and consistent.

Feasibility Validation Effectiveness analysis is intrinsically concerned with functional performance of a system, and therefore cannot in itself validate the feasibility of its physical implementation. This is especially true in the case where unproven technology is invoked to achieve certain performance attributes. An indirect approach to feasibility validation is to build a convincing case by analogy with already demonstrated applications of the projected technique. Such an approach may be adequate, provided that the application cited is truly representative of that proposed in a new system. It is important, however, that the comparison be quantitative rather than only qualitative so as to support the assumed performance resulting from the technology application. A direct approach to validating the feasibility of a new physical implementation is to conduct experimental investigations of the techniques to be applied to demonstrate that the predicted performance characteristics can be achieved in practice. This approach is often referred to as “critical experiments,” which are conducted early in the program to explore new implementation concepts. The resources available for carrying out the validation process in the needs analysis phase are likely to be quite limited, since the commitment to initiate the actual development of the system has not yet been made. Accordingly, the quality of the ­validation process will depend critically on the experience and ingenuity of the systems

SUMMARY

149

engineering staff. The experience factor is especially important here because of the dependence of the work on knowledge of the operational environment, of the predecessor system, of analyses and studies previously performed, of the technological base, and of the methods of systems analysis and systems engineering. Importance of Feasibility Demonstration.  In defining a basis for developing a new system, the needs analysis phase not only demonstrates the existence of an important unfulfilled operational need but also provides evidence that satisfying the need is feasible. Such evidence is obtained by visualizing a realistic system concept that has the characteristics required to meet the operational objectives. This process illustrates a basic systems engineering principle that establishing realistic system requirements must include the simultaneous consideration of a system concept that could meet those requirements. This principle contradicts the widely held notion that requirements, derived from needs, should be established prior to consideration of any system concept that can fulfill those requirements.

5.6 SUMMARY Originating a New System Objectives of the needs analysis phase are to identify a valid operational need for a new system and develop a feasible approach to meeting that need. This needs‐driven system development approach is characteristic of most defense and other government programs, and typically stems from a deficiency in current system capabilities. This type of development requires a feasible and affordable technical approach. The other major type of approach is the technology‐driven system development approach. This approach is characteristic of most commercial system development and stems from a major technological opportunity to better meet a need. This type of development requires demonstration of practicality and marketability. Activities comprising the needs analysis phase are: • • • •

Operations analysis – understanding needs for a new system. Functional analysis – deriving functions required to accomplish operations. Feasibility definition – visualizing a feasible implementation approach. Needs validation – demonstrating cost‐effectiveness.

Systems Thinking Systems thinking analyze the system from a holistic perspective to consider the entire operational and physical environment. This is done to identify what other systems and organizations will influence the system when determining the initial needs.

150

NEEDS ANALYSIS

Operations Analysis Studies and analyses are conducted to generate and understand the operational needs of the system. These studies feed the development of an objectives tree – describing the hierarchy of system expectations and outcomes. Development of CONOPS, ­scenarios, and mission statements as well as incorporating social and technology views are critical to success.

Feasibility Definition The system development approach is decided upon, articulated to stakeholders, and approximately costed. Moreover, an early feasible system concept is articulated. Finally, developing operational requirements commences.

Needs Validation The vetted set of operational needs is now validated by operational effectiveness analysis, usually at multiple levels within the analysis pyramid. Systems concepts, which satisfy the operational needs, are evaluated with agreed upon MOE and reflect the entire system life cycle.

PROBLEMS 5.1 Describe and define the principal outputs (products) of the needs analysis phase. List and define the primary systems engineering activities that ­contribute to these products. 5.2 Identify the relationships between operational objectives and functional requirements for the case of a new commuter aircraft. Cite three operational objectives that are needed to realize these objectives. 5.3 Assume that you have a business in garden care equipment and are planning to develop one or two models of lawn tractors to serve suburban homeowners. Consider the needs of the majority of such potential customers and write at least six operational requirements that express these needs. Remember the qualities of good requirements as you do so. Draw a context diagram for a lawn tractor. 5.4 Given the landscaping problem of the previous question, develop a scenario that outlines the landscapers’ perspective for initial development for a new homeowner. Consider the needs of the homeowner, operational environment, physical environment, and any impediments/threats that the landscaper would need to overcome when developing the landscaping project.

FURTHER READING

151

5.5 Given the results of Problem 5.4, describe how you would perform a validation of the landscaping project user needs when it is complete. Describe the process to be taken and the data that would be needed to validate that the effort satisfied the operational requirements.

REFERENCES Kasser, J. and Mackley, T. (2008). Applying systems thinking and aligning it to systems engineering. INCOSE International Symposium 18 (1): 1389–1405. Varghese, J., Kutty, V.R., Paina, L., and Adam, T. (2014). Advancing the application of systems thinking in health: understanding the growing complexity governing immunization services in Kerala, India. Health Research Policy and Systems 12 (1): 1–12. Watson, M.D., Andrews, J.G., Eckley, J.C., and Culver, M.L. (2017). Practical Application of Sociology in Systems Engineering. American Society for Engineering Management (ASEM).

FURTHER READING Blanchard, B. and Fabrycky, W. (2013). System Engineering and Analysis, 5e. Prentice Hall. Hall, A.D. (1962). A Methodology for Systems Engineering. Van Nostrand, Chapter 6. Peters, D.H. (2014). The application of systems thinking in health: why use systems thinking? Health Research Policy and Systems 12 (1): 1–6. Rehmann, C.R., Rover, D.T., Laingen, M. et  al. (2011). Introducing Systems Thinking to the Engineer of 2020. American Society for Engineering Education. Reilly, N.B. (1993). Successful Systems for Engineers and Managers. Van Nostrand Reinhold, Chapter 4. Sage, A.P. and Armstrong, J.E. Jr. (2000). Introduction to Systems Engineering. Wiley, Chapter 3. Shortell, T.M. (ed.) (2015). INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 4e. Wiley. Stevens, R., Brook, P., Jackson, K., and Arnold, S. (1998). Systems Engineering, Coping with Complexity. Prentice Hall, Chapter 2.

6 REQUIREMENTS ANALYSIS

6.1  DEVELOPING THE SYSTEM REQUIREMENTS Chapter 5 discussed the process of needs analysis, which is intended to provide a well‐ documented justification for initiating the development of a new system. The process also produces a set of operational requirements (or objectives) that describe what the new system must be designed to do. Assuming that those responsible for authorizing the initiation of a system development have been persuaded that these preliminary requirements are reasonable and attainable within the constraints imposed by time, money, and other external constraints, the conditions have been achieved for taking the next step in the development of a new system. The principal objective of the concept exploration phase, as defined here, is to convert the operationally oriented view of the system derived in the needs analysis phase into an engineering‐oriented view required in the concept definition and subsequent phases of development. This conversion is necessary to provide an explicit and quantifiable basis for selecting an acceptable functional and physical system concept and then guiding its evolution into a physical model of the system.

Systems Engineering Principles and Practice, Third Edition. Alexander Kossiakoff, Samuel J. Seymour, David A. Flanigan, and Steven M. Biemer. © 2020 John Wiley & Sons, Inc. Published 2020 by John Wiley & Sons, Inc.

153

154

REQUIREMENTS ANALYSIS

As in the case of operational requirements, the derivation of system performance requirements must also simultaneously consider system concepts that could meet them. However, to ensure that the performance requirements are sufficiently broad to avoid unintentionally restricting the range of possible system configurations, it is necessary to conceive not one, but to explore a variety of candidate concepts. New systems that strive for a major advance in capability over their predecessors, or depend on the realization of a technological advance, require a considerable amount of exploratory research and development (R&D) before a well‐founded set of performance requirements can be established. The same is true for systems that operate in highly complex environments and whose characteristics are not fully understood. For these cases an objective of the concept exploration phase is to acquire the needed knowledge through applied R&D. This objective may sometimes take several years to accomplish, and occasionally these efforts prove that some of the initial operational objectives are impracticable to achieve and require major revision. The discussion to follow is generally applicable to all types of complex systems. For information systems, in which software performs virtually all the functionality, Section 14.4 discusses software system architecture and its design and should also be consulted.

Place of Concept Exploration Phase in the System Life Cycle The place of the concept exploration phase in the overall system development process is shown in Figure  6.1. It is seen that the top‐level system operational requirements come from needs analysis, which establishes that the needs are justified and that a development program is feasible within prescribed bounds. The outputs of the concept exploration phase are a set of system performance requirements down to the subsystem level and a number of potential system design concepts that analysis indicates to be capable of fulfilling those requirements. While the formally defined concept exploration phase has a well‐defined beginning and end, many of the supporting activities do not. For example, the exploratory development of advanced technological approaches or the quantitative characterization of complex system environments often begin before and extend beyond the formal terms of this phase, being supported by Independent Research and Development (IRAD) or other non‐project funds. Additionally, considerable preliminary concept definition activity usually takes place well before the formal beginning of this phase. The specific content of the concept exploration phase depends on many factors, particularly the relationship between the customer and the supplier or developer, and whether the development is needs driven or technology driven. If the system ­developer and supplier are different from the customer, as is frequently the case in needs‐driven system developments, the concept exploration phase is conducted in  part by the c­ustomer’s own organization or with the assistance of a systems

155

DEVELOPING THE  SYSTEM REQUIREMENTS

System operational effectiveness

Needs analysis

System performance requirements

Concept exploration

Concept definition

Requirements analysis Concept synthesis Feasibility experiments

System capabilities

Candidate system concepts

Figure 6.1.  Concept exploration phase in system life cycle.

e­ ngineering agent engaged by the customer. The focus is on the development of performance requirements that accurately state the customer’s needs in terms that one or more suppliers could respond to with specific product concepts. In the case of a technology‐driven system development, the concept exploration phase is often conducted by the system developer and is focused on ensuring that all viable alternative courses of action are considered before deciding whether or not to pursue the development of a new system. In both cases a primary objective is to derive a set of performance requirements that can serve as the basis of the projected system development and that have been demonstrated to ensure that the system product will meet a valid operational need.

System Materialization Status The needs analysis phase was devoted to defining a valid set of operational objectives to be achieved by a new system, while a feasible system concept was visualized only as necessary to demonstrate that there was at least one possible way to meet the projected need. The term “visualize” is meant to connote the conceptualization of the general functions and physical embodiment of the subject in the case of needs analysis at the subsystem level. Thus, in the concept exploration phase, one starts with a vision based generally on the above feasible concept. The degree of system materialization addressed in this phase has progressed to the next level, namely, the definition of the functions that the system and its subsystems must perform to achieve the operational objectives, and to the visualization of the system’s component configuration, as illustrated in Table 6.1.

TABLE 6.1.  Status of System Materialization of Concept Exploration Phase Concept development

Phase Level System

Subsystem

Concept exploration

Define system capabilities and effectiveness

Identify, explore, and synthesize concepts

Define selected concept with specifications

Validate concept

Test and evaluate

Define requirements and ensure feasibility

Define functional and physical architecture

Validate subsystems

Integrate and test

Allocate functions to components

Define specifications

Design and test

Allocate functions to subcomponents

Design

Component

Subcomponent Part

156

Engineering development

Needs analysis

Visualize

Concept definition

Advanced development

Engineering design

Make or buy

Integration and evaluation

Integrate and test

REQUIREMENTS DEVELOPMENT AND  SOURCES

157

Systems Engineering Method in Concept Exploration The activities in the concept exploration phase and their interrelationships are the result of the application of the systems engineering method. A brief summary of these activities is listed below; the names of the four generic steps in the method are shown in parentheses: Operational requirements analysis (Requirements analysis). Typical activities include: • Analyzing the stated operational requirements in terms of their objectives. • Restating or amplifying, as required, to provide specificity, independence, and consistency among different objectives, to assure compatibility with other related systems, and to provide such other information as may be needed for completeness. Performance requirements formulation (Functional definition). Typical activities include: • Translating operational requirements into system and subsystem functions. • Formulating the performance parameters required to meet the stated operational requirements. Implementation concept exploration (Physical definition). Typical activities include: • Exploring a range of feasible implementation technologies and concepts offering a variety of potentially advantageous options. • Developing functional descriptions and identifying the associated system components for the most promising cases. • Defining a necessary and sufficient set of performance characteristics reflecting the functions essential to meeting the system’s operational requirements. Performance requirements validation (Design validation). Typical activities include: • Conducting effectiveness analyses to define a set of performance requirements that accommodate the full range of desirable system concepts. • Validating the conformity of these requirements with the stated operational objectives and refining the requirements if necessary. The interrelationships among the activities in the above steps in the systems engineering method are depicted in the flow diagram of Figure 6.2.

6.2  REQUIREMENTS DEVELOPMENT AND SOURCES Requirements can originate from a variety of sources. The authors can rely on knowledge from existing system deficiencies as well as evaluating novel concepts to derive requirements for the users to succeed in their future missions. A representative list of four

158

REQUIREMENTS ANALYSIS

Needs analysis phase Operational requirements

Analyze operational objectives

Predecessor system

Functional elements

Partitioning criteria

Operational requirements

Incompatibilities

Predecessor system

Operational requirements analysis

Refine operational requirements

Derive subsystem functions

Subsystem functions Predecessor system

Formulate performance parameters

Incomplete objectives

Previous analysis

Feasibility criteria

Performance parameters

Explore implementation concepts

• Building blocks • Technology

Performance requirements formulation

Define performance characteristics

Performance characteristics

Integrate performance characteristics

Implementation concept exploration

Incompatible characteristics

Validate performance requirements

Performance requirements

Measures of effectiveness

Performance requirements validation

Concept definition phase

Figure 6.2.  Concept exploration phase flow diagram.

types of approaches is offered in order to identify the diversity of requirements sources and to motivate the requirements developer to search for the right requirements development approach, depending on the starting point of the system and operational environment. In a first approach, the developer is given the chance to develop a new system that would operate in an environment against future threats. This may be a result of technology

REQUIREMENTS DEVELOPMENT AND  SOURCES

159

or concept breakthroughs that are ahead of the existing market and are constrained by the operational environment or selected threat conditions. The market may be very small and limited, and hence a great opportunity space is afforded the requirements developer. Some examples are from the physical sciences, such as space exploration, or deep‐sea exploration or other operations in extreme environmental conditions. Other examples may take a radically different approach to an existing problem, such as commuter traffic that is conducted underground in enclosed tubes. Requirements sources may include visionaries or cutting‐edge researchers that are both inventing capabilities and discovering them. The second approach is to improve existing systems based on their existing capabilities and deficiencies. This may originate from consumer demands to improve their capability or in response to how the users intend to adapt the systems use. This may often be found by crowdsourcing different ideas and to consider how the existing system may be improved. Often a business case may be made if the consumer demand is large enough and is well documented to provide a good set of requirements. Many consumer goods would fall under this category, as the next model or next upgrade is rolled out to the consumer, often studying the previous feedback from the existing model. The third approach may require the system to be modified in response to a new threat while operating. Often this comes about with military systems when operating against adversaries whose newer capabilities are discovered, necessitating a response in order to protect the users. Study of the deficiencies of the existing system against the new threats is made in order to consider the solution space to adequately defend against the advanced threat. There is some risk in modifying the system to counter the exact threat, as it may mature into a different capability, so the requirements analyst must look to forecast the likely range of threats to handle, especially if the acquisition and modification process is slower than the threat’s rate of change. This may also occur due to natural disasters that strike against existing systems and infrastructure, which necessitate a change in systems, particularly if a great deal of damage and/or loss of life has occurred. The fourth approach is creating additional systems to operate with the existing system. This may occur when allies or partnering organizations join forces to address a common problem. These new interoperability requirements may occur between systems, or it may be to modify the system operators’ behaviors or procedures. Often new system behavior may emerge from this new system modification, requiring additional constraints, procedures, and doctrine to be created to realize the benefit of the new system. New organization mergers that produce a modified system would be representative of this approach, such as international cooperation, for example, space exploration, joint military endeavors, or natural disaster responses that bring local, state, tribal, and federal emergency management forces together. Sources of new requirements may be visualized through use of the system context diagram, definition of the operational environment, threats, and users and other supporting systems and organizations. Through use of the approaches listed above, the creation of capability, interfaces, or additional system characteristics may help motivate

160

REQUIREMENTS ANALYSIS

the requirements engineer to explore the potential system configurations that would address the problem. Other sources of requirements may originate by extending the context diagram with additional users, such as maintainers, logistics, policy makers, allies, social, program offices, stakeholders, etc. By evaluating the system from different perspectives/users, additional requirements may be generated.

6.3  REQUIREMENTS FEATURES AND ATTRIBUTES Requirements Features A feature is a set of requirements that will satisfy an objective, which is typically at a higher level of abstraction. These may be identified more with potential users on the system’s envisioned performance, which then may be decomposed to more specific requirements. An example of a feature is a vehicle that can support travel soccer game support. This feature may be composed of the following requirements: • • •

Vehicle can transport a minimum of six school‐aged children. Vehicle can transport a minimum of 10 soccer balls, 20 jerseys, and 2 games worth of snacks. Vehicle can transport a minimum of two full‐size coolers of food and beverages.

These features may vary between requirements users and their system needs, but may be useful to organize sets of requirements in order to describe their performance to a set of specific users. Collections of these features can then be developed to ensure that the proper set of stakeholders have been adequately consulted to satisfy their specific needs. The features may also serve to ensure that conflicting or competing requirements are also identified and either negotiated, modified, or removed. Dependent features may also be analyzed to ensure that one requirement that is dependent on another requirement is considered in order to ensure a successful system requirement is developed.

Requirements Attributes There are selected attributes that may describe requirements, which are common throughout the literature, much of which has been emphasized on the technical composition of the requirement: is it measureable, is it quantifiable, under what conditions and qualifiers is the requirement satisfied, etc.? Often the “SMART” approach will accompany requirements: simple, measurable, attainable, realistic, and time bound. These attributes can determine whether the requirement is well written and stands a chance of accurately representing the system capability. Of equal importance is the approach on how requirements are developed, how to document the requirements, and updating and maintaining configuration control. Numerous tools are available to maintain these requirements and to ensure that work can be applicable to various portions of the system development effort.

REQUIREMENTS FEATURES AND  ATTRIBUTES

161

As requirements are verified and validated, these are also important attributes for the systems engineer to ensure that the requirements will contribute to a successful system development effort. There are also good and bad examples of requirements that systems engineers should acquaint themselves with in order to emulate the successful requirements and to avoid the pitfalls of poorly developed requirements. Consider the example of a public transportation system concept. Examples of good requirements: •

•

The system shall be able to transport up to 20 passengers within a radius of 50 miles. Why is this good? It provides a measureable amount of passengers and operational radius, so the transportation system can be tested to see if it meets this requirement. The system shall provide a means of communication between the transport and the dispatch station to exchange health and status data of the transport system, exchanged every 15 minutes. Why is this good? It provides a quantifiable means of describing the needed information to be exchanged; note that it does not describe what type or format of message, nor does it presuppose the communications means – this is for the designer and systems engineering team to determine later.

Examples of poor requirements: •

•

•

The system shall be able to operate in all weather. Why is this poor? Stating “all weather” implies that every imaginable weather condition would need to be satisfied for the transportation system. The system shall be diesel powered. Why is this poor? It states the design by using a diesel engine. How do we know this is the correct solution, as there may be other alternatives? Requirements should describe what needs to occur, not how it should be built. The system shall use Volvo engines. Why is this poor? It presupposes the solution.

Human factors may also play into requirements development. Understanding the representative user and personnel that will come into contact with the system will greatly improve the chance of capturing a good set of human factors requirements. Research in the field, perhaps with a prototype, can also elicit requirements by observing interaction and human behavior while the prototype is being operated and can also provide insight into what requirements were successful and which requirements may need improvement. Language may also be an issue, particularly if the system under development is not from the originating user country.

Characteristics of Well‐Stated Requirements As mentioned above, the requirements analysis process leads to a concise set of performance requirements. This section examines the challenges associated specifically with translating operational requirements to performance requirements.

162

REQUIREMENTS ANALYSIS

Since operational requirements are first formulated as a result of studies and analyses performed outside a formal project structure, they tend to be less complete and rigorously structured than requirements prepared in the subsequent managed phases of the development and are mainly oriented to justifying the initiation of a system development. Accordingly, in order to provide a valid basis for the definition of system performance requirements, their analysis must be particularly exacting and mindful of frequently encountered deficiencies, such as lack of specificity, dependence on a single assumed technical approach, incomplete operational constraints, lack of traceability to fundamental needs, and requirements not adequately prioritized. In an effort to cover all expected operating conditions (and to “sell” the project), operational requirements are often overly broad and vague where they should be specific. In the case of most complex systems, it is necessary to supplement the basic requirements with a set of well‐defined operational scenarios that represent the range of conditions that the system is required to meet. The opposite problem occurs if operational requirements are stated so as to be dependent on a specific assumed system configuration. To enable consideration of alternative system approaches, such requirements need to be restated to be independent of specific or “point” designs. Often operational requirements are complete only in regard to the active operational functions of the system and do not cover all the constraints and external interactions that the system must comply with during its production, transportation, installation, and operational maintenance. To ensure that these interactions are treated as fully as possible at this stage of development, it is necessary to perform a life cycle analysis and provide scenarios that represent these interactions. All requirements must be associated with and traceable to fulfilling the operational objectives of the user. This includes understanding who will be using the system and how it will be operated. Compliance with this guideline helps to minimize unnecessary or extraneous requirements. It also serves as a good communication link between the customer and developer when particular requirements subsequently lead to complex design problems or difficult technical trade‐offs. The essential needs of the customer must be given top priority. If the needs analysis phase has been done correctly, requirements stemming from these needs will be clearly understood by all concerned. When design conflicts occur later in development, a review of these primary objectives can often provide useful guidance for making a decision. Beyond the above primary or essential requirements, there are always those capabilities that are desirable if they prove to be readily achievable and affordable. Requirements that are essential should be separately distinguished from those that are desirable but not truly necessary for success of the primary mission. Often, preferences of the customer come through as hard and fast requirements, when they are meant to be desirable features. Examples of desirable requirements are those that provide ­additional performance capability or design margin. There should be some indication of cost and risk associated with each desirable requirement so that an informed

REQUIREMENTS DEVELOPMENT PROCESS

163

p­ rioritization can be made. The discrimination between essential and desirable requirements and their prioritization is a key systems engineering function. MBSE can support good requirements definition by enforcing an organization’s rules; for example, all requirements must be traced to an authoritative source or all functional requirements must have an associated performance requirement (“what” and “how well”). MBSE also supports collecting requirements by connections to system elements (and not just by how they are organized or stored). This reduces the probability of a requirement being overlooked simply because it was misfiled.

6.4  REQUIREMENTS DEVELOPMENT PROCESS As in all phases of the system development process, the first task is to understand thoroughly, and if necessary clarify and extend, the system requirements defined in the previous phase (in this case the operational requirements). In so doing it is important to be alert for and avoid shortcomings that are often present in the operational requirements as initially stated. We use a general process, known as requirements analysis, to identify and discover performance requirements, synthesize and minimize initial sets of requirements, and finally validate the final set of requirements. This requirements analysis occurs at each phase. However, the majority of effort occurs in the concept exploration phase where operational requirements are transformed into system performance requirements with measurable thresholds of performance. These system performance requirements tend to be the basis for contractual agreements between customer and developer and therefore need to be accurate and concise. Figure 6.3 depicts the general process for developing requirements. Of course, this would be tailored to a specific application. The first activity involves the creation of a set of requirements. It is rare this occurs out of whole cloth  –  typically a source of needs exist. In the concept exploration phase, a set of operational needs and requirements have been established. However, those needs and requirements are typically expressed in the language and context of an operator or user. These must be translated into a set of system‐specific requirements describing its performance.

Requirements Elicitation When analysts are developing operational requirements, they rely heavily on input from users and operators, typically through market surveys and interviews. When analysts are developing performance requirements, they rely on both people and studies. Initially, the customer (or buying agent within an organization) is able to provide thresholds of affordability and levels of performance that are desirable. But subject matter experts (SMEs) can also provide performance parameters as a function of technology levels, cost, and manufacturability. Previous studies and system development efforts can also assist in determining performance requirements. And finally, a requirements analyst performs a system effectiveness analysis to provide insight into the level of performance

164

REQUIREMENTS ANALYSIS

Requirements elicitation

Requirements analysis

Requirements validation

Requirements documentation

Figure 6.3.  Simple requirements development process.

needed. All of these sources provide the analyst with an initial set of performance requirements. Many times, however, this set of requirements contains inconsistencies, or even dichotomies. Further, many requirements are redundant, especially when they come from different sources. So the analyst must conduct a synthesis to transform an initial set of requirements into a concise, consistent set. A useful approach to developing requirements of any type is to ask the six interrogatives: who, what, where, why, when, and how. Of course, different types of requirements focus on different interrogatives. Operational requirements focus on the “why,” defining the objectives and purpose of the system. Performance requirements focus on the “what,” defining what the system should do (and how well).

Requirements Analysis This activity starts with an initial set of requirements from the elicitation stage. Individual requirements as well as the set as a whole are analyzed for various attributes and characteristics. Some characteristics are desirable, such as “feasible” and “verifiable.” Other characteristics are not, such as “vague” or “inconsistent.” For each requirement, a set of tests (or questions) is applied to determine whether the requirement is valid. And while many tests have been developed by numerous organizations, we present a set of tests that at least form a baseline. These tests are specific to the development of system performance requirements: 1. Is the requirement traceable to a user need or operational requirement? 2. Is the requirement redundant with any other requirement? 3. Is the requirement consistent with other requirements? (Requirements should not contradict each other, or force the engineer to an infeasible solution.) 4. Is the requirement unambiguous and not subject to interpretation?

REQUIREMENTS DEVELOPMENT PROCESS

165

5. Is the requirement technologically feasible? 6. Is the requirement affordable? 7. Is the requirement verifiable? If the answer to any of the questions above is “no,” then the requirement needs to be revised, or possibly omitted. In addition, other requirements may need to be revised after performing this test. In addition to individual requirements tests, a collective set of tests is also performed (usually after the individual tests have been performed on each requirement): 1. Does the set of requirements cover all of the user needs and operational requirements? 2. Is the set of requirements feasible in terms of cost, schedule, and technology? 3. Can the set of requirements be verified as a whole? Both types of tests may need to be iterated before a final set of performance requirements exists.

Requirements Validation Once a set of performance requirements are available, the set needs to be validated. This may be accomplished formally or informally. Formal validation means using an independent organization to apply various validation methods to validate the set of requirements against operational situations (i.e. scenarios and use cases) and determine whether the requirements embodied within a system concept could achieve the user needs and objectives. Informal validation at this point means reviewing the set of requirements with the customer and/or users to determine the extent and comprehensiveness of the requirements.

Requirements Documentation A final important activity is the documentation of the performance requirements. This is typically accomplished through the use of an automated tool, such as DOORS. Many tools exist that manage requirements, especially large, complex requirements hierarchies. As system complexity increases, the number and types of requirements tend to grow, and using simple spreadsheet software may not be sufficient to manage requirements databases.

Incompatible Operational Requirements It should be noted that a given set of operational requirements does not always lead to feasible performance characteristics. Earlier, the automobile was mentioned as a system

166

REQUIREMENTS ANALYSIS

that was required to undergo significant changes because of government‐imposed regulations concerning safety, fuel economy, and pollution control. Initially, these areas of regulation were independently developed. Each set of requirements was imposed solely on the basis of a particular need, with little regard for either the associated engineering problems or other competing needs. When these regulations were subjected to engineering analysis, it was shown that they were not collectively feasible within the practical technology available at that time. Also, the investment in development and production would result in a per‐unit cost far in excess of the then current automobile prices. The basic reason for these problems was that the available pollution controls necessary to meet emission requirements resulted in lowered fuel economy, while the weight reduction necessary to meet the required fuel economy defeated the safety requirements. In other words, the three independent sets of operational requirements turned out to be incompatible because no one had initially considered their combined impact on the design. Note that in this instance, an analysis of the requirements did not depend on a detailed design study, since simply examining the design concepts readily revealed the conflicts.

Example: Concepts for a New Aircraft An instructive example of concept exploration is illustrated by the acquisition of a new commercial aircraft. Assume for this discussion that an airline company serves short to medium domestic routes using two‐engine propeller‐driven aircraft. Many of the airports it serves have relatively short runways. This arrangement has worked well for a number of years. The problem that has become more and more apparent is that because of increasing maintenance and fuel expenses, the cost per passenger mile has increased to the point where the business is marginally profitable. The company is therefore considering a major change in its aircraft. In essence, the airline’s need is to lower the cost per passenger mile to some acceptable value and to maintain its competitive edge in short route service. The company approaches several aircraft manufacturers for preliminary discussion of a new or modified airplane to meet its needs. The discussions indicate that there are several options available. Three such options are: 1. A stretched aircraft body and increased power. Engines of the appropriate form and fit exist for such a configuration. This option permits a quick, relatively low‐cost upgrade, which increases the number of passengers per aircraft, thereby lowering the overall cost per passenger mile. 2. A new, larger, four‐engine propeller aircraft using state‐of‐the‐art technology. This option offers a good profit return in the near term. It is reasonably low risk, but the total useful life of the aircraft is not well known, and growth potential is limited. 3. A jet‐powered aircraft that is capable of takeoff and landing at most, but not necessarily all, of the current airports being served. This option permits a

REQUIREMENTS HIERARCHY

167

significant increase in passengers per airplane and opens up the possibility of competing for new, longer routes. This is also the most expensive option. Because of the inherent lower maintenance and fuel costs of jet engines relative to propeller engines, operating costs for this aircraft are attractive, but some existing routes will be lost. It is evident that the final choice will require considerable expertise and should be based on a competition among interested manufacturers. The airline engages the services of an engineering consulting company to help its staff prepare a set of aircraft performance requirements that can serve as a basis for competitive bids and to assist in the selection process. In exploring the above and related options, the alternative functional approaches are considered first. These appear to center on the choice between staying with propeller engines, an option that retains the basic features of the present aircraft, or moving to jet engines, which offer considerable operating economies. However, the latter is a major departure from the current system and will also affect its operational capabilities. To permit this choice to be left open to the bidders, the performance requirements such as runway length, cruising speed, and cruising altitude will need to be sufficiently broad to accommodate these two quite different functional approaches.

6.5  REQUIREMENTS HIERARCHY Requirements are organized into several different levels in order to assist the requirements engineer a means to develop the requirements for the proper scope. For the purpose of this textbook, we organize the requirements into: operational, system, performance, and components. Each requirement level can provide information to different users, as well as guide the system and concept development. In addition, the linkage between the different levels must be defined as well in order to quantify how requirements from lower levels contribute to the successive level.

Operational Requirements Operational requirements are described by what needs to execute within the scope of operations. These requirements are generally less quantified and higher in level of detail. Users and stakeholders perspectives play a larger role in shaping these requirements and often describing the requirement in their own words or terminology. It is critical to capture the correct set of users to develop these requirements types in order to represent the scope of stakeholders. Operational requirements must initially be described in terms of operational ­outcomes rather than system performance. They must not be stated in terms of implementation, nor biased toward a particular conceptual approach. All requirements should be expressed in measurable (testable) terms. In cases where the new system is required to use substantial portions of an existing system, this should be specifically stated.

168

REQUIREMENTS ANALYSIS

The rationale for all requirements must be stated or referenced. It is essential for the systems engineers leading the system development to understand the requirements in terms of user needs so that inadvertent ambiguities do not result in undue risks or costs. The time at which a new system needs to be available is not readily derived from purely operational factors, but may be critical in certain instances due to financial factors, obsolescence of current systems, schedules of system platforms (e.g. ships, bases), and other considerations. This may place constraints on system development time and hence on the degree of departure from the existing system. Since the initially stated operational requirements for a new system are seldom based on an exhaustive analysis, it should be understood by both the customer and potential developer that these requirements will be refined during the development process, as further knowledge is gained concerning the system needs and operating environment. From the above considerations, it is seen that work carried out during this analysis phase must be regarded as preliminary. Subsequent phases will treat all system aspects in more detail. However, experience has shown that the basic conceptual approach identified during needs analysis often survives into subsequent phases. This is to be expected because considerable time and effort is usually devoted to this process, which may last for two or three years. Even though only limited funds are expended, many organizations are often involved.

System‐Level Requirements System‐level requirements are more focused on the system and how it performs in the operational environment. It may also be concerned with the supporting infrastructure as well as other systems that it may come into contact with during expected operations. System‐level requirements will likely focus more on quantitative metrics and how the system will perform within the environment. Different perspectives may be garnered from using a context diagram or other ways to look at the system in a holistic manner in order to ensure completeness with requirements. Being able to conceptualize the system within the environment can also identify additional requirements, such as interfaces or behaviors in response to friend or foe during the envisioned system objective. Also included other aspects of the system life, such as maintenance, repair, disposal, training, etc., may also identify additional requirements that should be considered from a systems perspective.

Performance Requirements Formulation As noted previously, in the course of developing a new system, it is necessary to transform the system operational requirements, which are stated as required outcomes of system action, into a set of system performance requirements, which are stated in terms of engineering characteristics. This step is essential to permit subsequent stages of

REQUIREMENTS HIERARCHY

169

system development to be based on and evaluated in engineering rather than operational terms. Thus, system functional performance requirements represent the transition from operational to engineering terms of reference.

Performance‐Level Requirements In deriving performance requirements from operational objectives, it is first necessary to identify the major functions that the system must perform to carry out the prescribed operational actions. That means, for example, that if a system is needed to transport passengers to such destinations as they may wish along existing roadways, its functional elements must include, among others, a source of power, a structure to house the passengers, a power‐transmitting interface with the roadway, and operator‐activated controls of locomotion and direction. Expressed in functional terms (verb–object) these elements might be called “power vehicle,” “house passengers,” “transmit power to roadway,” “control locomotion,” and “control direction.” A beginning in this process has already been made in the preceding phase. However, a more definitive process is needed to establish specific performance parameters. During this phase the functional definition needs to be carried a step further, that is, to a definition of subsystem functions, and to the visualization of the functional and associated physical components, which collectively can provide these subsystem functions.

The Nondeterministic Nature of System Development The derivation of performance requirements from desired operational outcomes is far from straightforward. This is because, like other steps in system materialization process, the design approach is inductive rather than deductive, and hence not directly reversible. In going from the more general operational requirements to the more specifically defining system performance requirements, it is necessary to fill in many details that were not explicitly called out in the operational requirements. This can obviously be done in a variety of ways, meaning that more than one system configuration can, in principle, satisfy a given set of system requirements. This is also why in the system development process the selection of the “best” system design at a given level of materialization is accomplished by trade‐off analysis using a predefined set of evaluation criteria. The above process is exactly the same as that used in inductive reasoning. For example, in designing a new automobile to achieve an operational goal of 600 miles on a tank of gasoline, one could presumably make its engine extremely efficient, or give it a very large gasoline tank, or make the body very light, or some combination of these characteristics. Which combination of these design approaches is selected would depend on the introduction of other factors, such as relative cost, development risk, passenger capacity, safety, and many others. This process can also be understood by considering a deductive operation, as, for example, performance analysis. Given a specific system design, the system’s performance

170

REQUIREMENTS ANALYSIS

may be deduced unambiguously from the characteristics of its components by first breaking down component functions, then calculating their individual performance parameters, and finally aggregating these into measures of the performance of the system as a whole. The reverse of this deductive process is, therefore, inductive and consequently nondeterministic. One can see from the preceding discussion that, given a set of operational requirements, there is no direct (deductive) method of inferring a corresponding unique set of system performance characteristics that are necessary and sufficient to specify the requirements for a system to satisfy the operational needs. Instead, one must rely on experience‐based heuristics, and to a large extent, a trial and error approach. This is accomplished through a process in which a variety of different system configurations are tentatively defined, their performance characteristics are deduced by analysis or data collection, and these are subjected to effectiveness analysis to establish those characteristics required to meet the operational requirements. Formulation of Performance Characteristics.  As noted above the objective of the concept exploration phase is to derive a set of system performance characteristics that are both necessary and sufficient. This means that a system possessing them will satisfy the following criteria: 1. A system that meets the system operational requirements, and is technically feasible and affordable, will comply with the performance characteristics. 2. A system that possesses these characteristics will meet the system operational requirements and can be designed to be technically feasible and affordable. The condition that the set of performance requirements must be necessary as well as sufficient is essential to ensure that they do not inadvertently exclude a system concept that may be especially advantageous compared with others just because it may take an unusual approach to a particular system function. This often happens when the performance requirements are derived in part from a predecessor system and carry over features that are not essential to its operational behavior. It also happens when there is a preconceived notion of how a particular operational action should be translated into a system function. For the above reasons, the definition of performance characteristics needs to be an exploratory and iterative process, as shown in Figure  6.2. In particular, if there are alternative functional approaches to an operational action, they should all be reflected in the performance characteristics, at least until some may be eliminated in the implementation and validation steps in the process.

Requirements Formulation by Integrated Product Teams As noted earlier, the responsibility for defining the performance requirements of a new product is that of the customer, or in the case of government programs, that of the acquisition agency. However, the organization of the process and its primary ­participants

REQUIREMENTS HIERARCHY

171

vary greatly with the nature of the product, the magnitude of the development, and the customer auspices. A recent practice introduced by DoD is the use of integrated product teams (IPTs) throughout the acquisition process. IPTs are intended to bring a number of benefits to the process: 1. They bring senior industry participants into the system conceptual design process at the earliest opportunity, thereby educating them in the operational needs and injecting their ideas during the formative stages of the development. 2. They bring together the different disciplines and specialty engineering viewpoints throughout the development. 3. They capitalize on the motivational advantages of team collaboration and consensus building. 4. They bring advanced technology and COTS knowledge to bear on system design approaches. As in the case of any organization, the success of this approach is highly dependent on the experience and interpersonal skills of the participants, as well as on the leadership qualities of the persons responsible for team organization. And perhaps even more important is the systems engineering experience of the team leaders and members. Without this, the majority of the team members, who tend to be specialists, will not be able to communicate effectively and hence the IPT will not achieve its objectives.

Component‐Level Requirements and Specifications Component‐level requirements are focused on the technical aspect of the system and will at a lower level of technical detail. These requirements may also be concerned with the design aspects in order to ensure that performance criteria are met. Similar to system‐level requirements, these are highly quantitative in nature and will come with some expected performance under defined conditions. Reliability may also be focused at the component level in order to determine if the entire system reliability numbers are achievable. Specifications are developed as the next steps from the component‐level requirements in order to guide manufacturers with the desired level of performance and precision while constructing the components. Each phase of development must begin with a detailed analysis of all of the requirements and other terms of reference on which the ensuing program is to be predicated. In terms of problem solving, this is equivalent to first achieving a complete understanding of the problem to be solved.

Analysis of Stated Performance Requirements Requirements analysis in the concept definition phase is especially important because system performance requirements as initially stated often represent an imperfect interpretation of the user’s actual needs. Even though the previous phases may have been

172

REQUIREMENTS ANALYSIS

thoroughly carried out, the derivation of a set of performance requirements for a complex system is necessarily an imprecise and often subjective process, not to mention iterative. In particular, the stated requirements tend to be influenced by personal and often not well‐founded presumptions of what will turn out to be hard or easy to achieve. This may result in some performance requirements being unnecessarily stringent because they are believed to be readily achievable (a presumption that may turn out to be invalid). It is therefore essential that both the basis for the requirements and their underlying assumptions be clearly understood. Following this, steps can be taken to refine the requirements as necessary to support the definition of a truly viable system concept. The estimated relative difficulty of achieving the requirements will help to guide resource allocation during development. The task of understanding the source of the given performance requirements in terms of user needs is the particular province of systems engineering. This task requires as intimate an acquaintance with the operational environment and with system users as circumstances may permit. In the case of complex operational systems, such an ­understanding can best be derived through years of work in the field. Categories of  System Requirements. In discussing the subject of requirements analysis, attention is usually focused on what functions the system must perform and how well. We have named these types of well‐defined requirements: functional and performance. There are, however, other types of requirements that may be much more poorly defined, or even omitted in this phase. These include: 1. Compatibility requirements. How the system is to interface with its operating site, its logistic support, and with other systems. 2. Reliability, maintainability, and availability (RMA) requirements. How r­ eliable the system must be to fulfill its purpose, how it will be maintained, and what support facilities will be required. 3. Environmental requirements. What extremes of the physical environment must the system be built to withstand throughout its lifetime. RMA requirements, when explicitly stated, tend to be arbitrary and often not well defined. For the other two categories, requirements are often largely confined to the system’s operational mode and leave out the conditions of shipping, storage, transit, assembling, and supporting the system. In these circumstances it is necessary to investigate in detail the entire life of the system, from product delivery to the end of its operating life and its disposition. System Life Cycle Scenario.  To understand all of the situations that the system will encounter during its lifetime, it is necessary to develop a model or scenario that identifies all of the different circumstances to which the system will be exposed. These will include at least:

REQUIREMENTS HIERARCHY

173

1. Storage of the system and/or its components 2. Transportation of the system to its operational site 3. Assembly and readying the system for operation 4. Extended deployment in the field 5. Operation of the system 6. Routine and emergency maintenance 7. System modification and upgrading 8. System disposition The model of these phases of the system’s use must be sufficiently detailed to reveal any interactions between the system and its environment that will affect its design. For example, the maintenance of the system will require a supply of spare parts, special test equipment, special test points, and other provisions that need to be recognized. Only by visualizing the complete life of the projected system can valid requirements and associated costs be developed.

Completion and Refinement of System Requirements The development of a system life cycle model will almost always reveal that many important system requirements were not explicitly stated. This is likely to be true not only for the nonoperating phases of the system but also for its interaction with the physical environment. These environmental specifications are often derived from “boiler plate,” rather than from a realistic model of the operating environment. In contrast, the desire to make use of standard commercial components may cause such specifications to be unduly relaxed, or omitted entirely. Probably the most important requirement that is often not stated is that of affordability. In competitive system developments, the projected system cost is one of the factors considered in selecting the winning proposal. Therefore, affordability must be considered as equivalent to other stated requirements, even though it may not be represented as such. It is, therefore, necessary to gain as much insight as practicable into what level of projected system cost development, production, and support will constitute an acceptable (or competitive) value. Useful life is another system characteristic that is seldom stated as a requirement. To prevent early obsolescence, a system that uses high technology must be capable of periodic upgrading or modernization. To make such a process economically viable, the system must be designed with this objective in mind, making those subsystems or components that are susceptible to early obsolescence easy to modify or replace with newer technology. In some programs, such upgrading or growth capability is explicitly provided for. This process is sometimes called “Pre‐Planned Product Improvement” (P3I). In the majority of cases, however, especially when initial cost is a major concern, there is not

174

REQUIREMENTS ANALYSIS

a stated requirement for such capability. Nevertheless, it must be kept in mind as an important criterion for comparing alternative system concepts, since in practice, future changes in operating conditions and/or system environment (or product competition) will more often than not lead to increasing pressures for a system upgrade. Unquantified Requirements. In order to be useful, a system requirement must be verifiable. This typically means measurable. Where the requirement is stated in ­nonquantifiable terms, the task of requirements analysis includes endowing it with as much quantification as possible. The following two examples are typical of such requirements. A commonly unquantified area is that of user requirements, and especially the user–system interface. The overworked term “user friendly” does not translate readily into measurable form. Accordingly, it is important to gain a firsthand understanding of the user’s needs and limitations. This, in turn, is complicated by the fact that there may be several users with different interfacing constraints and levels of training. There is also the maintenance interface, which has totally different requirements. The interfaces between the system and other equipment at its operating site and with related systems are also often not stated in measurable terms. This may require a firsthand examination of the projected system environment, and even measurements of these interfaces, if necessary. For example, are there specifications for such parameters as available power or input signals that must be provided at the site? Requirements and the Predecessor System.  As noted previously, if there is a predecessor (current) system that performs the same or similar function as the projected system, as is usually the case, it is the single richest source of information on the requirements for the new system. It deserves detailed study by systems engineering at all stages of development, especially in the formative phases. The predecessor system offers an excellent basis for understanding the exact nature of the deficiencies that led to the call for a new system. Since all its attributes are measurable, they can serve as a point of departure for quantifying the requirements for the new system. There is frequently documentation available that can provide a direct comparison to requirements for the new system. The users of the predecessor system are usually the best source of information of what is needed in a new system. Thus, systems engineering should make the effort to gain a detailed firsthand understanding of system operation. Operational Availability. There may or may not be a stated requirement for the date at which the system is to be ready for operational use. When there is, it is important to try to understand the priority of meeting this date relative to the importance of development cost, performance, and other system characteristics. This knowledge is needed because these factors are mutually interdependent, and their proper balance is essential to the success of the system development. In any event, the time of availability is always important to the ultimate value of the system. This is because the growth of technology and competitive pressures operate

REQUIREMENTS METRICS

175

continuously to shorten the new system’s effective operational life. Thus, the time of operational availability must be considered a prime factor in the planning of a system development. In commercial developments, the first product to exploit a new technology often gains a lion’s share of the market. Determining Customer/User Needs. As noted previously, it is always necessary to clarify, extend, and verify the stated system requirements through contacts not only with the customer but also with present users of existing or similar systems. In a competitive acquisition program, access to the customer may often be formally controlled. However, it should be used, insofar as possible, to clarify ambiguities and inconsistencies in the requirements as originally stated. This may be done directly, through correspondence, or at a bidders’ conference, as appropriate. A better opportunity to clarify system requirements is in the pre‐proposal stage. In many large acquisition programs, a draft request for proposal (RFP) is circulated to prospective bidders for comment. During this period it is usually possible to obtain a better understanding of the customer requirements than will be possible after the issuance of the RFP. This emphasizes the fact that the effort to respond to a system acquisition RFP must begin well before (months or years) its formal issuance. In developing commercial systems, there is always an active and often an extended market survey to establish customer/user needs. In these cases, explicit system requirements may often not yet exist. As a prerequisite to the definition of a system concept and its associated performance requirements, it is therefore essential that systems engineering interact as directly as possible with potential customers and users of current systems to observe at first hand the system strengths, limitations, and associated operating procedures.

6.6  REQUIREMENTS METRICS Metrics are used to inform the analyst, engineer, and decision maker whether or not the system will successfully accomplish its intended objective while in an operational environment under operational conditions. Metrics may also be consulted while performing system analysis to estimate if the envisioned system concept will be successful or not, based on the value of the metric. Metrics may also provide a sense of a goal for the developers to design a system that will meet these metrics, which may describe the capabilities from the system down to the component. Metrics may be used by numerous users: concept designers will use metrics to envision the desired performance of the new system concept and gauge its contribution to the environment. Requirements analysts will use metrics to evaluate the system concept within their models and simulations. Test engineers will use metrics to evaluate whether the test on the selected system was successful or not.

176

REQUIREMENTS ANALYSIS

Measures of Effectiveness and Measures of Performance With the introduction of operational effectiveness analysis, we need to explore the concept and meaning of certain metrics. Metrics are key to ultimately defining the system, establishing meaningful and verifiable requirements, and testing the system. Therefore, defining these metrics appropriately and consistently through the development life cycle is essential. Many terms exist to describe these effectiveness and performance metrics. Two commonly used (and ones we will use throughout this book) are measures of effectiveness (MOEs) and measures of performance (MOPs). Unfortunately, no universal definitions exist for these terms. But the basic concept behind them is crucial to understanding and communicating a system concept. 1. Measure of effectiveness. A qualitative or quantitative metric of a system’s overall performance that indicates the degree to which it achieves its objectives under specified conditions. An MOE always refers to the system as a whole. 2. Measure of performance. A quantitative metric of a system’s characteristics or performance of a particular attribute or subsystem. An MOP typically measures a level of physical performance below that of the system as a whole. Regardless of the definition you use, it is a universal axiom that an MOE is a superior to MOP. In other words, if the two are placed in a hierarchy, MOEs will always be above MOPs. Typically, an MOE or MOP will have three parts: the metric, its units, and the conditions or context under which the metric applies. For example, an MOE of a new recreational aircraft would be maximum range, in nautical miles at sea level on a standard atmospheric day. The metric is “maximum range,” the units are “nautical miles,” and the conditions are “a standard atmospheric day (which is well defined) at sea level.” This MOE relates to the aircraft as a whole and describes one aspect of its performance in achieving the objective of aerial flight. MOEs can be of many forms; but we can define three general categories: measurement, likelihood, or binary. Measurement is an MOE that can be directly measured (either from an actual system, subsystem, or mathematical or physical model). It may be deterministic or random. Likelihood MOEs correspond to a probability of an event occurring and may include other MOEs. For example, a likelihood MOE could be the probability of an aircraft achieving a maximum altitude of 20 000 ft. In this case, the likelihood is defined in terms of another measurement MOE. Finally, a binary MOE is a logical variable of the occurrence of an event. Either the event occurs or not. When an MOE is measured or determined, we call the resultant measurement the value of the MOE. Thus, in our aircraft example, if we measure the maximum range of a new aircraft as 1675 nm, then “1675” is the value. Of course, MOEs, as any metrics, can have multiple values under different conditions. Finally, engineers use binary MOEs to determine whether a particular characteristic of a system exceeds a threshold. For example, we could define a threshold for the

REQUIREMENTS VERIFICATION AND  VALIDATION

177

maximum range of an aircraft as 1500 nm at sea level on a standard day. A binary MOE could then be defined to determine whether a measured value of the MOE exceeds our threshold. For example, if the binary MOE would be “yes,” our measured value of 1675 nm exceeds our threshold of 1500 nm.

6.7  REQUIREMENTS VERIFICATION AND VALIDATION Having derived the operationally significant performance characteristics for several feasible alternative concepts, all of which appear to be capable of meeting the system operational requirements, the next step is to refine and integrate them into a singular set to serve as a basis for the preparation of formal system performance requirements. As stated earlier, these performance requirements, stated in engineering units, provide an unambiguous basis for the ensuing phases of system development, up to the stage where the actual system can be tested in a realistic environment. The operations involved in the refinement and validation of system performance requirements can be thought of as two tightly coupled processes  –  an integration process, which compares and combines the performance characteristics of the feasible alternative concepts, and an effectiveness analysis process, which evaluates the validity of the integrated characteristics in terms of the operational requirements.

Performance Characteristics Integration The integration process serves to select and refine those characteristics of the different system concepts examined in the exploration process that are necessary and sufficient to define a system that will possess the essential operational characteristics. Regardless of the analytical tools that may be available, this process requires the highest level of systems engineering judgment. This and other processes in this phase can benefit greatly by the participation of systems engineers with experience with the predecessor system, as mentioned previously. The knowledge and database that comes with that system is an invaluable source of information for developing new requirements and concepts. In many cases some of the key engineers and managers who directed its development may still be available to contribute to the development of new requirements and concepts. They may not only be aware of the current deficiencies but are likely to have considered various improvements. Additionally, they are probably aware of what the customer really wants, based on their knowledge of operational factors over a number of years. Just one key systems engineer with this background can provide significant help. Experienced people of this type will also have an educated “gut feel” about the viability of the requirements and concepts that are being considered. Their help, at least as consultants, will not alleviate the need for requirements analysis, but it may quickly point the effort in the right direction and avoid blind alleys that might otherwise be pursued.

178

REQUIREMENTS ANALYSIS

Performance Characteristics Validation The final steps in the process are to validate the derived performance characteristics against the operational requirements and constraints and to convert them into the form of a requirements document. Ideally, the performance characteristics derived from the refinement step will have been obtained from concepts validated in the implementation concept exploration process. However, it is likely that the effort to remove irrelevant or redundant characteristics in the integration step, and to add external constraints not present in the effectiveness model, will have significantly altered the resultant set of characteristics. Hence, it is essential to subject them once more to an effectiveness analysis to verify their compliance with the operational requirements. The effectiveness model in the above step should generally be more rigorous and detailed than models used in previous steps so as to ensure that the final product does not contain deficiencies due to omission of important evaluation criteria. The above processes operate in closed‐loop fashion until a self‐consistent set of system performance characteristics is obtained that meets the following objectives: 1. They define what the system must do, and how well, but not how the system should do it. 2. They define characteristics in engineering terms that can be verified by analytical means or experimental tests, so as to constitute a basis for ensuing engineering phases of system development. 3. They completely and accurately reflect the system operational requirements and constraints, including external interfaces and interactions, so that if a system possesses the stated characteristics, it will satisfy the operational requirements.

Requirements Documentation To convert the system performance characteristics into a requirements document involves skillful organization and editing. Since the system performance requirements will be used as the primary basis for the ensuing concept definition phase and its successors, it is most important that this document be clear, consistent, and complete. However, it is equally important to recognize that it is not carved in stone, but is a living document, which will continue to evolve and improve as the system is developed and tested. In a needs‐driven system development in which it is intended to compete the concept definition phase among a number of bidders, the system performance requirements are a primary component of the competitive solicitation, along with a complete statement of all other conditions and constraints. Such a solicitation is often circulated in draft form among potential bidders to help ensure its completeness and clarity. In a technology‐driven system development in which the same commercial company that will carry out the definition and subsequent phases conducts the exploratory phase, the end product typically serves as a basis for deciding whether or not to authorize and fund a concept definition phase preliminary to engineering development. For this purpose the requirements document typically includes a thorough description of the

SUMMARY

179

most attractive alternative concepts investigated, evidence of their feasibility, market studies validating the need for a new system, and estimates of development, production, and market introduction costs.

6.8  REQUIREMENTS DEVELOPMENT: TSE VS. AGILE Traditional systems engineers (TSE) will often take a waterfall approach toward developing new requirements, ensuring that the appropriate stakeholders have been consulted, considering the various operational environments and future threats for which the new system will be designed for is adequate. This approach can often be more time consuming, as it may look at more of a strategic approach in order to evaluate the new system concept and its envisioned contribution into the environment. Agile systems engineers will often take a quicker development approach toward requirements development. They will also consult the stakeholders, but this may require an iterative approach in order to develop portions of the system requirements, and may focus on selected parts and perspectives of the system, while gaining feedback from the various stakeholders. Because of this approach, this may take a more bottoms‐up perspective toward the system, and may look at the tactical view of the system and its requirements.

6.9 SUMMARY Developing the System Requirements The objectives of the concept exploration phase (as defined here) are to explore alternative concepts to derive common characteristics and convert the operationally oriented system view into an engineering‐oriented view. Outputs of concept exploration are (i) system performance requirements, (ii) a system architecture down to the subsystem level, and (iii) alternative system concepts. Activities that comprise concept exploration are: • • • •

Operational requirements analysis – ensuring completeness and consistency. Implementation concepts exploration – refining functional characteristics. Performance requirements formulation – deriving functions and parameters. Performance requirements validation – ensuring operational validity.

Requirements Development and Sources Requirements can originate from a variety of sources. The authors can rely on knowledge from existing system deficiencies as well as evaluating novel concepts to derive requirements for the users to succeed in their future missions. Four general approaches include:

180

REQUIREMENTS ANALYSIS

• • • •

Development of a new system to operate in a future environment, usually as a result of new technology or concept. Improvement: Given the existing system, consumer demands can identify new ways to improve the existing system. Threat driven: New threats require reexamination of existing systems and concepts, with improvements to counter these threats. Addition: New allied or complementary systems are introduced, enhancing the original system, but requires a new way to interface and operate.

Requirements Features and Attributes A feature is a set of requirements that will satisfy an objective, which is typically at a higher level of abstraction. These features may vary between requirements users and their system needs, but may be useful to organize sets of requirements in order to describe their performance to a set of specific users. Collections of these features can then be developed to ensure that the proper set of stakeholders have been adequately consulted to satisfy their specific needs. Requirements attributes describe the technical composition of the requirement: is it measureable, is it quantifiable, under what conditions and qualifiers is the requirement satisfied, etc.?

Requirements Development Process Requirements development involves four basic steps: elicitation, analysis, validation, and documentation. These steps will, done correctly, lead to a robust set of well‐articulated requirements.

Requirements Hierarchy Requirements are organized into several different levels; in order to develop requirements for the proper scope, this textbook organizes requirements into operational, system, performance, and components. Operational requirements are described by what needs to execute within the scope of operations. System‐level requirements are more focused on the system and how it performs in the operational environment. Performance‐ level requirements are stated as required outcomes of system action, typically stated in terms of engineering characteristics. Component‐level requirements are focused on the technical aspect of the system and will at a lower level of technical detail.

Requirements Metrics Metrics are used to inform the analyst, engineer, and decision maker whether or not the system will successfully accomplish its intended objective while in an o­ perational environment under operational conditions. An MOE refers to a qualitative or quantitative

FURTHER READING

181

metric of a system’s overall performance that indicates the degree to which it achieves its objectives under specified conditions. An MOE always refers to the system as a whole. An MOP refers to a quantitative metric of a system’s characteristics or performance of a particular attribute or subsystem. An MOP typically measures a level of physical performance below that of the system as a whole.

Requirements Verification and Validation Performance requirements validation involves two interrelated activities: (i) integration of requirements derived from alternative system concepts and (ii) effectiveness analyses to demonstrate satisfaction of the operational requirements. Performance requirements are defined in a living document; requirements are reviewed and updated throughout the system life cycle.

Requirements Development: TSE VS. Agile Traditional waterfall techniques may progress through a more methodical approach toward requirements development, but may take longer. Agile techniques may iteratively develop requirements quicker.

PROBLEMS 6.1 To meet future pollution standards, several automobile manufacturers are developing cars powered by electricity. Develop five requirements for new electric‐powered cars. 6.2 For the example in Problem  6.1, develop five requirements for existing cars that would be modified to accept this new power supply. 6.3 Given the example in Problem 6.1, create five operational requirements for new electric‐powered cars and their refueling stations. Ensure these are quantified. 6.4 Given the example in Problem 6.1, create five performance requirements for new electric‐powered cars and their refueling stations. Ensure these are quantified. 6.5 Given the example in Problem 6.1, state five component requirements for new electric‐powered cars and their refueling stations. Ensure these are quantified. 6.6 Given the example in Problem 6.1, state five MOEs for new electric‐powered cars and their refueling stations. Ensure these are quantified.

FURTHER READING Blanchard, B. and Fabrycky, W. (2013). System Engineering and Analysis, 5e. Prentice Hall. Chase, W.P. (1974). Management of Systems Engineering. Wiley, Chapters 4 and 5.

182

REQUIREMENTS ANALYSIS

Eisner, H. (1997). Essentials of Project and Systems Engineering Management. Wiley, Chapter 8. Hitchins, D.K. (2007). Systems Engineering: A 21st Century Systems Methodology. Wiley, Chapters 5 and 8. Kendall, K. and Kendall, J. (2003). Systems Analysis and Design, 6e. Prentice Hall, Chapters 4 and 5. Law, A.M. (2014). Simulation, Modeling & Analysis, 5e. McGraw‐Hill. Lykins, H., Friedenthal, S., and Meilich, A. (2000). Adapting UML for an Object‐Oriented Systems Engineering Method (OOSEM). Proceedings of Tenth International Symposium INCOSE, Minneapolis, MN (July 2000). Meilich, A. and Rickels, M. (1999). An application of object‐oriented systems engineering to an army command and control system: a new approach to integration of systems and software requirements and design. Proceedings of Ninth International Symposium INCOSE, Brighton, England (July 1999). Rechtin, E. (1991). Systems Architecting: Creating and Building Complex Systems. Prentice Hall, Chapter 1. Reilly, N.B. (1993). Successful Systems for Engineers and Managers. Van Nostrand Reinhold, Chapters 4 and 6. Sage, A.P. and Armstrong, J.E. Jr. (2000). Introduction to Systems Engineering. Wiley, Chapter 4. Shortell, T.M. (ed.) (2015). INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 4e. Wiley. Stevens, R., Brook, P., Jackson, K., and Arnold, S. (1998). Systems Engineering, Coping with Complexity. Prentice Hall, Section 8.

7 FUNCTIONAL ANALYSIS

7.1  SELECTING THE SYSTEM CONCEPT Functional analysis is the key transition from needs analysis, where new ideas and concepts are developed, to the functional analysis phase where the new system concept starts to be engineered. Functions to describe the system’s activities, interactions, and operations are created here. The systems engineer has several tools to create these products during this phase in order to socialize ideas to ensure completeness of the envisioned system, as well as lay the foundations for physical design. The concept definition phase of the system life cycle marks the beginning of a serious, dedicated effort to define the functional and physical characteristics of a new system (or major upgrade of an existing system) that is proposed to meet an operational need and requirements defined in the preceding conceptual phases. It marks a commitment to characterize the system in sufficient detail to enable its operational performance, time of development, and life cycle cost to be predicted in quantitative terms. The level of effort in the concept definition phase is sharply greater than in previous phases, as system designers and engineering specialists are added to the systems engineers and  analysts who largely staffed the preceding phases. In most needs‐driven system Systems Engineering Principles and Practice, Third Edition. Alexander Kossiakoff, Samuel J. Seymour, David A. Flanigan, and Steven M. Biemer. © 2020 John Wiley & Sons, Inc. Published 2020 by John Wiley & Sons, Inc.

183

184

FUNCTIONAL ANALYSIS

developments, this phase is conducted by several competing developers, based on performance requirements developed in the preceding phases by or for the customer. The output of this phase is the selection, from a number of alternative system concepts, of a specific configuration that will constitute the baseline for development and ­engineering. From this phase on, the system development consists of implementing the selected system concept (with m ­ odifications as necessary) in hardware and software, and engineering it for production and operational use. With the advent and formal definition of systems architecting, this phase has been known in some sources as the system architecture phase. While this may not be entirely appropriate, systems architecting, as it is now defined and understood, is a major activity within this phase. The specifics of systems architecting are discussed in Chapter 9.

Place of the Concept Definition Phase in the System Life Cycle The place of the concept definition phase in the overall system development is shown in Figure 7.1. It constitutes the last phase of the concept development stage and leads to the initiation of the engineering development stage, beginning with the advanced development phase. Its inputs are system performance requirements, the technology base that includes a number of feasible system concepts, and the contractual and organizational framework in which the system development is to be cast. Its outputs are system functional specifications, a defined system concept, and a detailed plan for the ensuing engineering program. The planning outputs of this phase are usually specified to include the systems engineering management plan (SEMP), which defines in detail the systems engineering approach to be followed, the project work breakdown structure (WBS), cost estimates for development and production, test plans, and such other ­supporting material as may be directed (see Chapter 4). System performance requirements

Concept exploration

System functional specifications

Advanced development

Concept definition Analysis of alternatives Functional architecture Physical architecture

Candidate system concepts

Defined system concept (s)

Figure 7.1.  Concept definition phase in system life cycle.

SELECTING THE  SYSTEM CONCEPT

185

When the customer is the government, laws specify that all acquisition programs be conducted competitively, except in unusual circumstances. The competition frequently occurs during the concept definition phase. It customarily begins with a formal solicitation, which contains the system requirements, usually at the level of total system functionality, performance, and compatibility. Based on this solicitation, competing contractors carry out a proposal preparation effort, which embodies the concept definition phase of the program. The system concept and approach proposed by the successful bidder (or in some cases more than one) then becomes the baseline for the ensuing system development. In the development of a commercial product, the concept definition phase generally begins after the conclusion of a feasibility study, which established a valid need for the product and the feasibility of meeting this need by one or more technical approaches. It is the point at which the company has decided to commit significant resources to define the product to a degree where a further decision can be made whether or not to proceed to full‐scale development. Except for the formality and requirements for detailed documentation, the general technical activities during this phase for commercial and government programs are similar. One or several design concepts may be pursued, depending on the perceived importance of the objective and available funds.

Design Materialization Status The previous phase was concerned with system design only to the level necessary to define a set of performance requirements that could be realized with a feasible system design, and that would not rule out other advantageous design concepts. For that purpose, it was sufficient to define functions at the subsystem level and only visualize the type of components that would be needed to implement the concept. In order to define a system to the level where its operational performance, development effort, and production cost can be estimated with any degree of confidence (by analogy with previously developed systems), the conceptual design must be carried one level further. Thus, in the concept definition phase, the design focus is on components, the fundamental building blocks of systems. As indicated in Table 7.1, which is an overlay of Table  3.1, the focus in this phase is on the selection and functional ­definition of the system components and the definition of their configuration into subsystems. Performance of the above tasks is primarily a systems engineering responsibility since they address technical issues that often cut across both technical disciplines and organizational boundaries. However, the functional definition task can be effectively carried out only if the component implementation used to achieve each prescribed function is reasonably well understood and is sufficiently visualized to serve as the basis for risk assessment and costing, which cannot be carried out solely at the functional level. Accordingly, as with many systems engineering tasks, consultation with and advice from experienced design specialists is almost always required, especially in cases where advanced techniques may be used to extend subsystem performance beyond previously achieved levels.

TABLE 7.1.  Status of System Materialization of Concept Definition Phase Concept development

Phase Level System

Subsystem

Needs analysis Define system capabilities and effectiveness

Concept definition

Advanced development

Identify, explore, and synthesize concepts

Define selected concept with specifications

Validate concept

Test and evaluate

Define requirements and ensure feasibility

Define functional and physical architecture

Validate subsystems

Integrate and test

Allocate functions to components

Define specifications

Design and test

Allocate functions to subcomponents

Design

Part

186

Visualize

Engineering design

Integration and evaluation

Concept exploration

Component Subcomponent

Engineering development

Make or buy

Integrate and test

SELECTING THE  SYSTEM CONCEPT

187

Systems Engineering Method in Concept Definition The activities in the concept definition phase are discussed in the following sections in terms of the four steps of the systems engineering method (see Chapter 3), followed by a description of the planning of the ensuing system development effort and the formulation of system functional requirements. The four steps, as applied to this phase, are summarized below (generic names in parentheses): Performance requirements analysis (Requirement analysis). Typical activities include: • Analyzing the system performance requirements and relating them to operational objectives and to the entire life cycle scenario. • Refining the requirements as necessary to include unstated constraints and quantifying qualitative requirements where possible. Functional analysis and formulation (Functional definition). Typical activities include: • Allocating subsystem functions to the component level in terms of system functional elements and defining element interactions. • Developing functional architectural products. • Formulating preliminary functional requirements corresponding to the assigned functions. Concept selection (Physical definition). Typical activities include: • Synthesizing alternative technological approaches and component configurations designed to performance requirements. • Developing physical architectural products. • Conducting trade‐off studies among performance, risk, cost, and schedule to select the preferred system concept, defined in terms of components and architectures. Concept validation (Design validation). Typical activities include: • Conducting system analyses and simulations to confirm that the selected concept meets requirements and is superior to its competitors. • Refining the concept as may be necessary. The application of the systems engineering method to the concept definition phase is illustrated in Figure  7.2. Inputs are shown to come from the previous (requirements definition) phase in the form of system performance requirements and competitive design concepts. In addition, there are important external inputs in the form of technology, system building blocks (components), tools, models, and an experience knowledge base. Outputs include system functional requirements, a defined system concept, and (not shown in the diagram) detailed plans for the ensuing engineering stage of system development.

188

FUNCTIONAL ANALYSIS

Concept exploration phase Performance requirements

Analyze performance requirements

Predecessor system

Performance requirements

Incompatibilities

Predecessor system

Define component functions

Functional elements

Performance requirements analysis

Refine performance requirements

Functional analysis and formulation

Formulate functional requirements

Trade-offs

Trade-off criteria

Preliminary functional design

Functional elements Predecessor system

Synthesize alternative concepts

• Building blocks • Technology

Concept selection

Select preferred concept

Trade-offs

Excessive requirements

Concept effectiveness

Previous simulations

Concept effectiveness

Concept deficiencies

Conduct system simulation

Validate selected concept

Selected concept

Measures of effectiveness

Concept validation

Advanced development phase

Figure 7.2.  Concept definition phase flow diagram.

7.2  FUNCTIONAL ANALYSIS AND FORMULATION It has been seen that in keeping with the inherent magnitude of designing a complex system, the systems engineering method divides the design task into two closely coupled steps: (i) analyzing and formulating the functional design of the system (what

FUNCTIONAL ANALYSIS AND  FORMULATION

189

actions it needs to perform) and (ii) selecting the most advantageous implementation of the system functions (how the actions can best be physically generated). The close coupling between these steps results from their mutual interdependence, which requires both visualization of the implementation step in formulating the functional design, and iteration of the implementation step when alternative approaches are considered. Those familiar with software engineering will recognize these two steps as design and implementation, respectively.

Definition of Component Functions The system materialization process in the concept definition phase is mainly concerned with the functional definition of system components (see Table 7.1). If the details of the concept exploration phase are available, the functional configuration at the system level has already been explored. If not, there will have almost always been exploratory studies preceding the formal start of concept definition that have laid out one or more candidate top‐level concepts that can serve as a starting point for component functional design. Functional Building Blocks. The general nature of the task of translating performance requirements into system functions can be illustrated by using the concept of system functional building blocks. The following steps are involved: 1. Identification of functional media. The type of medium (signals, data, materials, energy, and force) involved in each of the primary system functions can usually be readily associated with one of these five classes. 2. Identification of functional elements. Operations on each of the five classes of media are represented by five or six basic functional elements, each performing a significant function and found in a wide variety of system types. The system actions (functions) can be constructed from a selection of those functional building blocks. 3. Relation of performance requirements to element attributes. Each functional element possesses several key performance attributes (e.g. speed, accuracy, capacity). If these can be related to the relevant system performance requirement(s), it confirms the correct selection of the functional element. 4. Configuration of functional elements. The functional elements selected to achieve the required performance characteristics must be interconnected and grouped into integrated subsystems. This may require adding interfacing (input/ output) elements to achieve connectivity. 5. Analysis and integration of all external interactions. The given performance requirements often leave out important interactions of the system with its operational (or other) environment (for example, external controls or energy source). These interactions need to be integrated into the total functional configuration.

190

FUNCTIONAL ANALYSIS

It is not advisable to attempt to optimize at this stage. The initial formulation of the system functional design will need to be modified after the subsequent step of physical definition and the ensuing iteration. Functional Interactions.  The functional elements are inherently constituted to require a minimum of interconnections to other elements besides primary inputs and outputs. However, most of them depend on external controls and sources of energy, as well as being housed or supported by a material structure. Their grouping into subsystems should be such as to make each subsystem as self‐sufficient as possible. Minimizing critical functional interactions among different subsystems has two purposes. One is to aid the system development, engineering, integration, test, maintenance, and logistics support. The other is to facilitate making future changes in the system during its operational life to upgrade its effectiveness. When several different ways to group functions (functional configurations) are comparably effective, these alternatives should be carried forward to the next step of the design process where a choice of the superior configuration may be more obvious.

Functional Block Diagramming Tools Several formal tools and methods exist (and continue to be developed) for representing a system’s functionality and their interactions. Commercial industry has used the functional flow diagram (FFD), formally referred to as the functional flow block diagram (FFBD), to represent not only functionality but also the flow of control (or any of the five basic elements). This diagramming technique can be used at multiple levels to form a hierarchy of functionality. The integrated definition (IDEF) method was developed in the 1970s and 1980s. In fact, IDEF extends beyond functionality and now encompasses a range of capability descriptions for a system. Integrated definition zero (IDEF0) is the primary technique for representing system functionality. The basic construct is the functional entity, represented by a rectangle, as shown in Figure 7.3. Strict rules exist for identifying interfaces to and from a function. Sometimes, detail is included within the box, such as the listing of multiple functions performed by the entity; other times, the inside of the rectangle is left blank. Inputs always enter from the left; outputs exit to the right. Controls (separated from inputs) enter the function from the top, and mechanisms (or implementation) enter from the bottom. One of the simplest diagramming techniques is the functional block diagram (FBD). This technique is similar to FFBDs, but without the flow structure, and IDEF0, but without the diagramming rules. Basically, each function is represented by a rectangle. Interfaces between functions are identified by directional arrows and are labeled to represent what is being passed between the functions. When a function interfaces with an external entity, the entity is represented in some fashion (e.g. rectangle, circle, etc.) and an interface arrow is provided.

191

FUNCTIONAL ANALYSIS AND  FORMULATION

Controls

Title Inputs

Functions • F1 • F2 • F3

Outputs

Mechanisms Figure 7.3.  IDEF0 functional model structure.

Consider an example of a coffee maker. Eleven functions can be identified: Input functions • Accept user command (on/off) • Receive coffee materials • Distribute electricity • Distribute weight Transformative functions • Heat water • Mix hot water with coffee grinds • Filter out coffee grinds • Warm brewed coffee Output functions • Provide status • Facilitate removal of materials • Dissipate heat Figure 7.4 represents a FBD using the 11 functions. Three external entities were also identified: the User, a Power source (assumed to be an electrical outlet), and the Environment. Notice that within the functions list, and the diagram, Maintenance is not considered. This is due to the nature of household appliances in general, and coffee makers in particular. They are not designed to be maintained. They are “expendable” or “throw‐away.” Since it is difficult to avoid crossing lines, several mechanisms exist to distinguish between separate interface arrows. Color is probably the most prevalent. But other

192

FUNCTIONAL ANALYSIS

Coffee grinds filter water

1. Receive coffee materials

Water Coffee grinds

5. Heat water

User

On/off status

2. Accept user command

On/off signal

Hot water 6. Mix hot water with coffee grinds

On/off signal

11. Dissipate heat

Coffee sludge Filter

On/off command

Heat

9. Provide status

Heat

7. Filter out coffee grinds Brewed coffee

3. Distribute electricity

Used coffee grinds Used filter

Electricity

Power source

Electricity

Used coffee grinds Used filter

10. Facilitate removal of materials

F5 F6 F8 F9

8. Warm brewed coffee

Environment

Heat

Weight Warm brewed coffee User

All functions

Weight

4. Distribute weight

Figure 7.4.  Functional block diagram of a standard coffee maker.

methods, such as dashing lines, are used as well. In the case of power, we have simply listed the functions that require power (e.g. “F5”). We have tried to be rather thorough in this example to help the reader think through the process of identifying functions and developing a functional structure for the system. Simplifying this diagram would not be difficult since we could omit several functions at this stage, as long as we did not forget about them later on. For example, function number 10, Facilitate removal of materials, could be omitted at this stage, as long as the ultimate design does indeed allow the user to easily remove materials. Notice as well that we can categorize the functions into those handling the five basic elements: Materials

Data Signals Energy

Force

Receive coffee materials Mix hot water with coffee grinds Filter out coffee grinds Facilitate removal of materials Provide status Accept user commands Distribute electricity Heat water Warm brewed coffee Dissipate heat Distribute weight

FUNCTIONAL ANALYSIS AND  FORMULATION

193

This is not a “clean” categorization, since some functions input one type of element and convert it into another type. For example, Function 2, Accept user command, inputs a datum and converts it to signals. Subjective judgment is necessary. SysML provides similar capabilities and allows rigorous definition of function inputs and outputs; these are typically expressed using model elements such as operations, signals, and parameters. Competent SysML modeling integrates these functional expressions with interface definitions and supports automated error checking (such as ensuring that a legal interface exists between two system elements whose functions are exchanging data, energy, or material). Hardware–Software Allocation.  The issue of whether a given function should be performed by hardware or software may seem like a question of implementation rather than function. However, system‐level issues are almost always involved in such decisions, such as the effect on operator interfaces, test equipment, and widespread interaction with other system elements. Accordingly, the definition of functional building blocks makes a clear distinction between software elements (e.g. control system and control processing) and hardware elements (e.g. process signal and process data). For these reasons, the functional definition at the component level should include the allocation of all significant processing functions to either hardware or software. An important consideration in such decisions is provision for future growth potential to keep up with the rapidly advancing data processing technology. In software‐embedded systems, software tends to be assigned to most of the critical functions, especially those related to controls, because of its versatility. In software‐ intensive systems, in which virtually all the functionality is performed by software, functional allocation is not as straightforward because of the absence of commonly occurring functional elements. Chapter 14 describes the inherent differences between hardware and software and their effect on system design, and addresses the methods used in designing software system architectures. To the extent that decisions may be involved in selecting functional elements, ­configuring them, or quantifying their functional characteristics, trade‐offs should be made among the candidates using a set of predefined criteria.

Simulation The analysis of the behavior of systems that have dynamic modes of response to events occurring in their environment often requires the construction of computer‐driven models that simulate such behavior. The analysis of the motion of an aircraft, or for that matter of any vehicle, requires the use of a simulation that embodies its kinematic characteristics. Simulations can be thought of as a form of experimental testing. They are used to obtain information critical to the design process in a much shorter time and at lesser cost than building and testing system components. In effect, simulations permit designers and analysts to gain an understanding of how a system will behave before the system exists

194

FUNCTIONAL ANALYSIS

in physical form. Simulations also permit designers to conduct “what‐if” experiments by making selected changes in key parameters. Simulations are dynamic; that is, they represent time‐dependent behavior. They are driven by a programmed set of inputs or scenarios, whose parameters may be varied to produce the particular responses to be studied, and may include input–output functional models of selected system elements. These characteristics are especially useful for conducting system trade‐off studies. In the concept definition phase, system simulation is particularly useful in the concept selection process, especially in cases where the dynamic behavior of the system is important. Simulation of the several alternative concepts permits the conduct of “experiments” that present the candidates with a range of critical potential challenges. Use of simulation results in scoring the candidates is generally more meaningful and persuasive than using judgment alone.

Formulation of Functional Specifications One of the outputs of the concept definition phase is a set of system functional specifications to serve as an input to the advanced development phase. It is appropriate to formulate a preliminary set of functional specifications at this step in the process to lay the groundwork for more formal documents. This also serves as a check on the ­completeness and consistency of the functional analysis. In stating functional specifications, it is essential to quantify them insofar as may be inferred from the performance and compatibility requirements. The quantification should be considered provisional at this time, to be iterated during the physical definition step and incorporated into the formal system functional specification document at the end of the concept definition phase. It is at this level in the system hierarchy that the physical configuration becomes clearly evident.

7.3  FUNCTIONAL ALLOCATION At this initial phase of the system development process, functional analysis is an extension of operational studies, directed to establishing whether there is a feasible technical approach to a system that could meet the operational objectives. At this stage, the term “feasible” is synonymous with “possible,” and implies making a case that there is a good likelihood that such a system could be developed within the existing state of the art, without having to prove it beyond reasonable doubt.

Translation of Operational Objectives into System Functions To make such a case, it is necessary to visualize the type of system that could carry out certain actions in response to its environment that would meet the projected operational objectives. This requires an analysis of the types of functional capabilities that the system would have to possess in order to perform the desired operational actions.

FUNCTIONAL ALLOCATION

195

In  needs‐driven systems, this analysis is focused on those functional characteristics needed to satisfy those operational objectives that are not adequately handled by current systems. In technology‐driven systems, the advances in functional performances would presumably be associated with the technology in question. In any case, both the feasibility of these approaches and their capability to realize the desired operational gains must be adequately demonstrated. The visualization of a feasible system concept is inherently an abstract process that relies on reasoning on the basis of analogy. This means that all the elements of the concept should be functionally related to elements of real systems. A helpful approach to the translation of operational objectives to functions is to consider the type of primary media (signals, data, material, or energy) that are most likely to be involved in accomplishing the various operational objectives. This association usually points to the class of subsystems that operate on the medium, as, for example, sensor or communication subsystems in the case of signals, computing subsystems for data, and so on. In the above process, it must be shown that all of the principal system functions, especially those that represent advances over previous systems, are similar to those already demonstrated in some practical context. An exception to this process of reasoning by analogy is when an entirely new type of technology or application is a principal part of a proposed system; in this case, it may be necessary to go beyond analysis and ­demonstrate its feasibility by modeling and ultimately, experimentation. In identifying the top‐level functions that the system needs to perform, it is important even at this early stage to visualize the entire system life cycle, including its ­nonoperational phases. The above discussion is not meant to imply that all considerations at this stage are qualitative. On the contrary, when primarily quantitative issues are involved, it is necessary to perform as much quantitative analysis as available resources and existing knowledge permit.

Allocation of Functions to Subsystems In cases where all operational objectives can be directly associated with system‐level functions that are analogous to those presently exhibited by various real systems, it is still essential to visualize just how these might be allocated, combined, and implemented in the new system. For this purpose, it is not necessary to visualize some best system configuration. Rather, it need only be shown that the development and production of an appropriate system is, in fact, feasible. Toward this end, a top‐level system concept that implements all the prescribed functions should be visualized in order to demonstrate that the desired capabilities can be obtained by a plausible combination of the prescribed functions and technical features. Here it is particularly important that all interactions and interfaces, both external and internal to the system, be identified and associated with the system functions, and that a trade‐off process be employed to ensure that the consideration of the various system attributes is thorough and properly ­balanced. This is typically done in terms of an initial concept of operation.

196

FUNCTIONAL ANALYSIS

A simple matrix allocating the subsystems to the functions may be developed, in order to visually see which functions are being performed by none, one, or more subsystems, as shown in Figure  7.5. In the case of no subsystems being allocated, this represents a gap in capability, and should be resolved. In the case of one subsystem allocated to the function, this may result in a single point of failure (if the subsystem does fail), although limits on systems, such as weight or size constraints, may necessitate the single subsystem. In the case of multiple subsystems that perform the same function, this may be a case of: redundant subsystems (planned) or overlapping subsystem coverage (unplanned, which may cause conflicts if failures or different performance may elicit a different capability). An example of such an allocation matrix is shown in Figure 7.5. In this case, function 1 only has subsystem A allocated. Function 2 has subsystems B and C allocated, perhaps for redundancy. Function 3 has no subsystems allocated, and should be reviewed and corrected. Subsystems A, B, C, and E are all allocated to functions, but subsystem D does not have any functions, which may be consideration for removal.

Functional Exploration and Allocation The exploration of potential system configurations is performed at both the functional and physical levels. The range of different functional approaches that produce behavior suitable to meet the system operational requirements is generally much more limited than the possibilities for different physical implementations. However, there are often several significantly different ways of obtaining the called for operational actions. It is important that the performance characteristics of these different functional approaches be considered in setting the bounds on system performance requirements. One of the outputs of this step is the allocation of operational functions to individual subsystems. This is important in order to set the stage for the next step, in which the basic physical building blocks components may be visualized as part of the exploration of implementation concepts. These two steps are very tightly bound through iterative loops. Two important inputs to the functional allocation process are the predecessor Subsystems A

Functions

1 2

B

C

X

X

D

E

X

3 4

X

5 6

X X

X

X X

Figure 7.5.  Example functional to subsystem allocation matrix.

FUNCTIONAL ANALYSIS PRODUCTS

197

system and functional building blocks. In most cases, the functions performed by the subsystems of the predecessor system will largely carry over to the new system. Accordingly, the predecessor system is especially useful as a point of departure in defining a functional architecture for the new system. And since each functional building block is associated with both a set of performance characteristics and a particular type of physical component, the building blocks can be used to establish the selection and interconnection of elementary functions and the associated components needed to provide the prescribed subsystem functions. To aid in the process of identifying those system functions responsible for its operational characteristics, recall that functional media can be classed into four basic types: signals, data, material, and energy. The process addresses the following series of questions: 1. Are there operational objectives that require sensing or communications? If so, this means that signal input, processing, and output functions must be involved. 2. Does the system require information to control its operation? If so, how are data generated, processed, stored, or otherwise used? 3. Does system operation involve structures or machinery to house, support, or process materials? If so, what operations contain, support, process, or manipulate material elements? 4. Does the system require energy to activate, move, power, or otherwise provide necessary motion or heat? Furthermore, functions can be divided again into three categories: input, transformative, and output. Input functions relate to the processes of sensing and inputting signals, data, material, and energy into the system. Output functions relate to the processes of interpreting, displaying, synthesizing, and outputting signals, data, material, and energy out of the system. Transformative functions relate to the processes of transforming the inputs to the outputs of the four types of functional media. Of course, for complex systems, the number of transformative functions may be quite large, and have successive “sequences” of transformations. Figure 7.6 depicts concept of this two‐dimensional construct, function category vs. functional media. In constructing an initial function list, it helps to identify inputs and outputs. This list directly leads the engineer to a list of input and output functions. The transformative functions may be easier to identify when examining them in the light of a system’s inputs and outputs.

7.4  FUNCTIONAL ANALYSIS PRODUCTS There are several products that systems engineers will use to describe the system’s functions. The most common three products are: FBD, FFD, and sequence diagrams (SD). For each of these products, a simplified description of how the systems engineer will approach the problem and develop the product is described. For simplicity, we will continue the coffee maker problem.

198

FUNCTIONAL ANALYSIS

S

Signals

M

E

D

M

Output functions

Energy

D

Transformative functions

Material

Input functions

Data

S

E

Figure 7.6.  Function category vs. functional media.

How to Build the FBD As shown in Figure 7.4, we have previously identified the relevant functions of a coffee maker. But how did we derive these functions? How do we know our FBD is complete? Some of the steps described below should assist the reader in linking the basic concepts to build a FBD. We start with the context diagram. It contains a description of what is in and out of scope for our system. Residing inside the scope should be the basic concepts/­ structures of our system – in the case of the coffee maker, it may be the internal heating element, liquids reservoir, receptacle for holding the grounds, receptacle for holding the brewed coffee, power interface, and user display interface. Outside the scope would be the external power source, users, coffee grounds to be used, water to be used, and the environment that the coffee maker would operate in. Implied are also the structures (e.g. tables) that would support the coffee maker. We then ask the stakeholders to describe the envisioned functions to brew a cup of coffee, while describing the activities of each of the elements. Presumably, there would also be an input to each of the functions, as well as an output from each of the functions. In some cases, there would be only an input (the starting function) and only an output (the concluding function). Elicitation of the functions would occur from a variety of users and in different perspectives. Some examples may be the user or the maintainer (in the event that the coffee maker is not working properly), which may have different functions. For the purpose of this text, we will focus on the user’s perspectives and the development of the FBD. Each function should then start with a verb and have a qualifying infinitive. We can then approach the FBD development in two ways: first by listing all the functions that the coffee maker performs internally, then tracing the internal functions, and then finally linking to all the external functions outside of the scope. See Figure 7.7

199

FUNCTIONAL ANALYSIS PRODUCTS

E E 4.0 Verb-Object

5.0 Verb-Object

F

2.0 Verb-Object

G

F

1. Develop the internal functions

G 6.0 Verb-Object

D 1.0 Verb-Object

H H

A

D

3.0 Verb-Object

C

E

E

5.0 Verb-Object F

4.0 Verb-Object

2.0 Verb-Object

B B

F

G

Ext. Entity I

G D

Ext. Entity I

A

2. Link the internal functions

6.0 Verb-Object

1.0 Verb-Object

H H

A

3.0 Verb-Object

C C

E 4.0 Verb-Object

Ext. Entity II

5.0 Verb-Object

F

2.0 Verb-Object

B

G

Ext. Entity II

6.0 Verb-Object

3. Link the internal functions with the external functions

Ext. Entity I

D A

1.0 Verb-Object

H

3.0 Verb-Object

C

Ext. Entity III

Figure 7.7.  Functional block diagram development from internal view first.

for an example. This approach may be applicable if we are developing a novel system and are focusing on the system characteristics first, and then developing the external interfaces later. Second, we may also approach the FBD by listing all of the external functions with the coffee maker with the external entities. Then, we can describe the internal functions of the coffee maker and trace them to the various external outputs. See Figure 7.8 for an example. This process may be used if we know all of the external entities and interfaces ahead of time. This may be applicable to systems that must work in a legacy environment where there are existing systems that our system must work with. Finally, how do we know that the FBD is complete? By walking through all the various possible use cases or scenarios on how coffee is brewed, we can then explore all the different variations of how the system would operate. Each of these scenarios should start with a starting function, trace to the various intermediate functions, and then end with a concluding function. Generally, the linking of functions would occur when an output from one function is an input to a different function. Note that some of these functions may reuse similar blocks of functions, although have a different outcome. One scenario is where the coffee maker is used to heat only water. Another scenario is where the coffee maker is used to heat water and pour over grounds. Another scenario is where

200

FUNCTIONAL ANALYSIS

2.0 Verb-Object

B

Ext. Entity II

1. Develop all external functions Ext. Entity I

A

1.0 Verb-Object 3.0 Verb-Object

C

Ext. Entity III

E

5.0 Verb-Object

F

2.0 Verb-Object

Ext. Entity II

B

4.0 Verb-Object

2. Link the internal and external functions

D

Ext. Entity I

A

1.0 Verb-Object

C

3.0 Verb-Object

E 4.0 Verb-Object

3. Continue linking until all scenarios are complete

D

Ext. Entity I

A

1.0 Verb-Object

Ext. Entity III

5.0 Verb-Object

F

2.0 Verb-Object

B

G

Ext. Entity II

6.0 Verb-Object H

3.0 Verb-Object

C

Ext. Entity III

Figure 7.8.  Functional block diagram development from external view first.

the coffee maker is used as a timer only. In all three scenarios, the user commands may be similar (e.g. setting the timer), but will result in three different outputs.

How to Build the FFD As we are soliciting the functions that are to be used in our system, we will also need to understand how these functions are linked together logically: does each function need to be completely executed first before progressing to the next function? Are there other functions that are occurring in parallel? Are there dependencies of the functions that require all of them to be complete before progressing to the next function? Are there options that only one function needs to be satisfied before progressing to the next? These questions help us start to build a FFD. This is similar to a FBD, but instead of the interfaces, we merely need to state the logics behind the functions. If there is a serial flow of activity (e.g. one function is executed and then outputs to the successive function), then a simple link (e.g. line) between the functions is displayed. If there are logics (e.g. AND or OR decisions – in the diagram, these are called “summing gates”), then these may be shown on the FFD. Figure 7.9 provides an example of the FFD. An FFD for the coffee maker example is shown in Figure 7.10.

201

FUNCTIONAL ANALYSIS PRODUCTS

Feedback loops F3 F1

F2

F4

F5

OR

F6

Summing gates

F7

F8

Functions F10 F9

AND

F12 F11

Figure 7.9.  Functional flow diagram example. System functions: F1. F2. F3. F4. F5. F6. F7. F8. F9. F10. F11.

Accept user command (on/off) Receive coffee materials Distribute electricity Distribute weight Heat water Mix hot water with coffee grinds Filter out coffee grinds Warm brewed coffee Provide status Facilitate removal of materials Dissipate heat

F9

F3 Start

F1

F2

AND

AND

F5

F6

F7

F8

AND

F10

AND

End

F4 F11

Figure 7.10.  Coffee maker functional flow diagram.

How to Build SD The SD is intended to graphically show interactions between the actors, whether they are in series or in parallel, similar to the FFD. The SD is concerned more with interactions or messages, and can either be functional (the actors would be functions in this

202

FUNCTIONAL ANALYSIS

System functions: F1. Accept user command (on/off) F2. Receive coffee materials F3. Heat water F4. Mix hot water with coffee grinds F5. Filter out coffee grinds F6. Warm brewed coffee

F1

F2

F3

F4

F5

F6

Command Materials Heat Grinds

Heat

Figure 7.11.  Coffee maker sequence diagram.

case) or could also be physical (the actors would be components, organizations, people, or systems). The SD is generally constrained to focus on specific capability, so the diagram is limited to a single scenario, unlike the FBD and FFD that encompass multiple scenarios. Elicitation from the stakeholders would be similar as other functional products, by allowing stakeholders to describe what actions and interactions are ongoing while executing the scenario. In this case, the order of interactions will matter, as some functions/activities will have dependencies based on when the interactions are received. Care should be taken to document the interactions in a temporal sequence, to ensure that the SD is properly constructed. Having a completed FBD and/or FFD will assist the systems engineer to elicit the proper sequence of commands/interactions while constructing the SD. Figure 7.11 is an example of the coffee maker SD from a functional perspective.

7.5  TRACEABILITY TO REQUIREMENTS Tracing requirements to functions while developing the functional architecture is critical in order to ensure that the system functions are being developed with some purpose, with the requirements providing the linkage to the user/stakeholder needs. The systems engineer can allocate these functions and requirements in order to account for the allocation, as well as perform analysis on these pairings that are overallocated (e.g. too many functions depend on a single requirement), or those requirements or functions that are not allocated at all. The former may be addressed by increasing the level of specificity to the requirement or function, and decomposing to a greater detail. The latter is more troubling, in that a requirement exists that does not have a corresponding function (therefore, the system may not be able to execute the requirement), or that a function exists without requirement (thus raising the question on why the function exists in the first place).

203

TRACEABILITY TO  REQUIREMENTS

For those requirements that have multiple functions, a logical check may be in order to assess the allocation. Presumably, if all functions are successfully executed, then the requirement is satisfied. However, what happens if one (or more functions) are not executed? Does the requirement fail completely? Fail partially? What is the impact to the system if the requirement does fail? Additional analysis may be completed to show completeness of the functional allocation to the requirements. Using automated tools, the systems engineer can quickly run through the functions and requirements to see which ones are allocated, and which ones are not – requiring additional attention. For a medical system example, Table 7.2 provides a manual version of the allocation process (a check indicates the function is allocated to the requirement), and counting the number of functional‐ requirements pairing, which is a sum of all the pairings. If there is a threshold value where the systems engineer deems overallocated, then the team may evaluate whether to decompose the function/requirement and reallocate the remaining functions/ requirements. The systems engineer can methodically move through the functional architecture (in this case, the FBD), and for each function, identify which of the requirements this function will satisfy. In some cases, the function may satisfy multiple requirements. This may also identify gaps in the requirements where there is a function without requirement. This issue must be returned to the requirements engineer and consultation with the stakeholders and users. The function should be verified by the users that it is a valid function. The stakeholders in turn must validate the requirement. Configuration control should be maintained when comparing the functional architecture with the requirements, as likely separate teams are working on these products, and may be doing so independently of the other team. In a traditional systems engineering approach, these teams may be separated in time and the functional team may not start until the requirements team has finished, requiring some reconstitution TABLE 7.2.  Functional to Requirements Allocation Example Functions

R1

Process patient Retrieve data Perform consultation Decide on next steps Schedule for chemotherapy Number

X

R1: The R2: The R3: The R4: The R5: The R6: The

R2

R3

X

X

R4

R5

R6

X X X

1

1

1

2

1

X 1

system shall process the patient within TBD minutes of entry. system shall query and retrieve E.H.R. data within TBD minutes of request. system shall queries require TBD authentication measure to access E.H.R. oncologist shall consult with the patient within TBD minutes of processing entry. system shall enable decisions and scheduling within TBD minutes of consultation start. oncologist shall schedule follow‐on treatment within TBD minutes of decision.

Number 2 2 1 1 1

204

FUNCTIONAL ANALYSIS

of the requirements team, if additional requirements or modifications need to be made. In an agile systems engineering approach, these teams may frequently collaborate as both products are being developed simultaneously, requiring some version control and coordination of the products as they are analyzed. The modeling tools used in MBSE facilitate these functional analyses, allocations, and reports. Specifics vary, based upon the tool and language, but the reader is encouraged to explore the potential of any tool available. For example, connecting nodes on an activity diagram can automatically display those connections on a properly defined matrix (eliminating the need to keep them in synch manually).

7.6  CONCEPT DEVELOPMENT SPACE Often, the development space starts with describing the problem space, starting with the context diagram as discussed in Figure 2.3. This may be found within the functional analysis phase by identifying what is in and out of scope for the envisioned system context. The systems engineer may use the context diagram as a mechanism to solicit additional inputs from stakeholders – one, to ensure the system is correctly described both in function as well as interface; two  –  to enable the creative thinking on what could be imagined by the system context that is currently not existing. This may be a way to promote the creativity of the stakeholders that are consulted. Steps to examine the context diagram to ensure completeness may include the following questions: •

•

•

Do we have the context scope set correctly? Are there other items missing inside the scope? Are there items that would describe future capabilities within the scope? Are the correct external entities (e.g. systems, organizations, people) listed? Are the interfaces (and directionality) correctly described? Are there entities that we would envision the system operating with in the future? Given an example of how the system is intended to be operated (e.g. regular operations, emergency operations, maintenance operations)  –  does the context diagram capture the correct organizations and interfaces? Are there other human factors or users that may play a role in how the system is intended to operate?

Consider also the development of a morphological box concept that may also promote additional creativity on how the system context diagram may be displayed and also to uncover what may be evaluated. This systems thinking tool allows multiple factors to be displayed in order to identify a solution. The system concept is combined with a combination of different perspectives and organizations, which are then evaluated as a valid or invalid combination. This may be done to reject organizational bias on existing system operations, and may encourage consideration of potentially unrealized combinations. An example is provided in Table  7.3, with a coffee maker containing four

TABLE 7.3.  Coffee Maker Morphological Box

Heating coil (S) Heating coil (L) Water carafe (S) Water carafe (L) Grounds container (S) Grounds container (L) Voltage (S) Voltage (L)

Heating coil (S)

Heating coil (L)

Water carafe (S)

Water carafe (L)

Grounds container (S)

Grounds container (L)

Voltage (S)

Voltage (L)

N/A No Yes Sub Yes Sub Yes No

No N/A No Yes Sub Yes Sub Yes

Yes No N/A No Yes Sub Yes Sub

Sub Yes No N/A Sub Yes Sub Yes

Yes Sub Yes Sub N/A No Yes Sub

Sub Yes Sub Yes No N/A Sub Yes

Yes Sub Yes Sub Yes Sub N/A No

No Yes Sub Yes Sub Yes No N/A

Levels of coffee maker components: • Heating coil (small, large) • Water carafe (small, large) • Grounds container (small, large) • Voltage (small, large)

205

206

FUNCTIONAL ANALYSIS

components: heating coil, water carafe, grounds holder, and voltage. Each component has two levels: small and large. The box shows all potential combinations in an 8 × 8 box, with “Yes” as an acceptable combination, “Sub” as suboptimal, “N/A” as not applicable that links to the other level, and “No” as an infeasible combination of component levels.

7.7 SUMMARY Selecting the System Concept Objectives of the concept definition phase are to select a preferred system configuration and define system functional specifications, as well as a development schedule and cost. Concept definition concludes the concept development stage, which lays the basis for the engineering development stage of the system life cycle. Defining a preferred concept also provides a baseline for development and engineering. Activities that comprise concept definition are: • • • •

Performance requirements analysis – relating to operational objectives. Functional analysis and formulation – allocating functions to components. Concept selection – choosing the preferred concept by trade‐off analysis. Concept validation  –  confirming the validity and superiority of the chosen concept.

Functional Analysis and Formulation Functional system building blocks (Chapter  3) are useful for functional definition. Selection of a preferred concept is a systems engineering function, which formulates and compares evaluation of a range of alternative concepts.

Functional Allocation Developing alternative concepts requires part art and part science. Certainly, the predecessor system can act as a baseline for further concepts (assuming a predecessor is available). Brainstorming and other team innovation techniques can assist in developing alternatives.

Functional Analysis Products FBD: identify the system functions and the external organizations that interact with the system. Connect them together either internally or externally first, whichever may be more comfortable to visualize how your system interacts with the operational environment.

PROBLEMS

207

FFD: identify the system functions and connect them using logic gates: do the functions require all or just some inputs from previous functions to execute the function? SD: identify the organizations, users, systems, subsystems, or components of the system concept. Connect them in time, as your scenario starts: do the interactions require a unique input or are there multiple inputs? Similar for the outgoing messages: are there singles or simultaneous messages that go out?

Traceability to Requirements Map the functions to the requirements and identify where there are either gaps or overallocated functions/requirements. If there are gaps, then a requirement has no supporting functions or a function has no requirements it supports. This will either require the systems engineer to find a suitable pairing or delete the function/requirement. If there are overallocated pairings, then look to decompose either the function into additional sub functions or decompose the requirement into multiple requirements.

Concept Development Space Developing the correct concept both in scope and level of detail. It may require multiple perspectives to ensure that the team has considered the representative set of functions, interacts with the correct organizations/systems/threats, and operating in the representative operational environment.

PROBLEMS 7.1 Draw a FBD of a personal computer using functional elements as building blocks. For each building block, consider what functions it performs, how it interacts with other building blocks, and how it relates to the external inputs and outputs of the computer system. 7.2 Develop a top‐level function list for an automated teller machine (ATM) system. Limit yourself to no more than 12 functions. 7.3 Given the ATM, draw a FBD of the ATM using the functions from Problem 7.2. 7.4 Given the ATM, draw a FFD of the ATM using the functions from Problem 7.2. 7.5 Given the ATM, develop a scenario that would describe how a user would interact with the ATM and successfully extract funds. Based on the functions from Problems 7.2 and 7.3, develop a SD of the scenario. 7.6 Develop a set of 12 top‐level requirements for the ATM system. Using the function list from Problem  7.2, develop a function‐requirement allocation matrix. Use no more than two functions allocated to the same requirement, and allocate no more than two requirements per same function.

208

FUNCTIONAL ANALYSIS

FURTHER READING Baker, L., Clemente, P., Cohen, B. et al. (2000). Foundational Concepts for Model Driven System Design. INCOSE Model Driven Design Interest Group Paper. Balmelli, L., Brown, D., Cantor, M., and Mott, M. (2006). Model‐driven systems development. IBM Systems Journal 45 (3): 569–585. Blanchard, B. and Fabrycky, W. (2011). Systems Engineering and Analysis, 5e. Pearson Prentice Hall. Chase, W.P. (1974). Management of Systems Engineering. Wiley, Chapters 3, 4. Chesnut, H. (1967). Systems Engineering Methods. Wiley. Dam, S. (2015). DOD Architecture Framework 2.0: A Guide to Applying Systems Engineering to Develop Integrated, Executable Architectures. SPEC Innovations. Defense Acquisition University (2001). Systems Engineering Fundamentals. Department of Defense, Chapters 5 and 6. http://www.dau.mil/pubscats/Pages/sys_eng_fund.aspx. Defense Acquisition University (2006). Risk Management Guide for DoD Acquisition, 6e. Department of Defense http://www.dau.mil/pubscats/Pages/risk_management.aspx. Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Modeling Language. Addison‐Wesley Professional. Department of Defense, Chief Information Officer (2010). The DoDAF Architecture Framework Version 2.02. https://dodcio.defense.gov/Library/DoD‐Architecture‐Framework/ (accessed 25 December 2018). Estefan, J.A. (2008). Survey of Model‐Based Systems Engineering (MBSE) Methodologies. INCOSE Technical Document INCOSE‐TD‐2007‐003‐02, Revision B. Kasser, J. (2013). A Framework for Understanding Systems Engineering. CreateSpace Independent Publishing Platform. Maier, M. and Rechtin, E. (2009). The Art of Systems Architecting. CRC Press. Pressman, R.S. (2001). Software Engineering: A Practitioner’s Approach. McGraw Hill. Sage, A.P. and Armstrong, J.E. Jr. (2000). Introduction to Systems Engineering. Wiley, Chapter 3. Schmidt, D. (2006). Model‐driven engineering. IEEE Computer 39 (2): 25–31. Shortell, T.M. (ed.) (2015). INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 4e. Wiley. The Open Group (2009). TOGAF Version 9 Enterprise Edition. Document Number G091, The Open Group. https://www.opengroup.org/togaf (accessed 2 February 2020).

8 EVALUATION AND SELECTION

8.1  EVALUATING AND SELECTING THE SYSTEM CONCEPT The physical implementation of alternative functional approaches involves the examination of different technological approaches, generally offering a more diverse source of alternatives. As in the case of examining alternative functional concepts, the objective of exploring implementation concepts is to consider a sufficient variety of approaches to support the definition of a set of system performance requirements that are feasible of realization in practice and do not inadvertently preclude the application of an otherwise desirable concept. To that end, the exploration of system concepts needs to be broadly based. Evaluating the various system concepts may also require some applied mathematics techniques, so as to maximize the performance and minimize the cost for the entire system. By developing a range of performance and cost profiles, the systems engineer can provide the decision makers with a variety of choices for the system concept. The systems engineer will also rely on the cost analyst to help make sense of cost elements to consider.

Systems Engineering Principles and Practice, Third Edition. Alexander Kossiakoff, Samuel J. Seymour, David A. Flanigan, and Steven M. Biemer. © 2020 John Wiley & Sons, Inc. Published 2020 by John Wiley & Sons, Inc.

209

210

EVALUATION AND  SELECTION

8.2  ALTERNATIVES ANALYSIS The full alternative space should be considered when evaluating the design elements. After the functions for the system concept have been defined and validated, the systems engineer should then consider how the design may be developed in order to effectively execute the functions. Considering the full alternative space allows the systems engineer to identify the constraint space, such as what needs to be addressed and considered  –  perhaps this accounts for the operational environment constraints for the system to work in, or other organizational constraints that the system must operate in and account for other organizations. Some of the constraints may include performance, cost, or schedule. Performance constraints may include interoperability, timing, formatting, or language, to name a few. Cost constraints may limit the systems engineer to selecting portions of the design that would fit under the budget caps, and may potentially reduce the overall effectiveness while remaining under the fiscal constraints. Schedule constraints may also limit the systems engineer to select portions of the design that will be compatible with the desired overall system schedule, even if this may be a suboptimal system in totality. One approach is to identify all the possible combinations of system designs, regardless of the constraints. This may allow the systems engineer to then work through each part of the system in order to satisfy all the constraints levied upon the system concept. This may originate with identifying which of these three constraints (performance, cost, and schedule) has the most limiting factors and then working through each of the different constraints until a satisfactory system design arises.

Alternative Implementation Concepts The predecessor system, where one exists, forms one end of the spectrum to be explored. Given the operational deficiencies of the predecessor system to meet projected needs, modifications to the current system concept should first be explored with a view to eliminating these deficiencies. Such concepts have the advantage of being relatively easier to assess from the standpoint of performance, development risk, and cost than are radically different approaches. They can also generally be implemented faster, more cheaply, and with less risk than innovative concepts. On the other hand, they are likely to have severely limited growth potential. The other end of the spectrum is represented by innovative technical approaches featuring advanced technology. For example, the application of powerful, modern microprocessors might permit extensive automation of presently employed manual operations. These concepts are generally riskier and more expensive to implement, but offer large incremental improvements or cost reduction and greater growth potential. In between are intermediate or hybrid concepts, including those defined in the needs analysis phase for demonstrating the feasibility of meeting the proposed system needs.

ALTERNATIVES ANALYSIS

211

Many techniques exist for developing new and innovative concepts. Perhaps the oldest is brainstorming, individually and within a group. Within the concept of brainstorming, several modern methods, or variations, to the old fashion, largely unstructured, brainstorming process have risen. The natural temptation to focus quickly on a single concept or “point design” approach can easily preclude the identification of other potentially advantageous approaches based on fundamentally different concepts. Accordingly, several concepts spanning a range of possible design approaches should be defined and investigated. At this stage, it is important to encourage creative thinking. It is permissible, even sometimes desirable, to include some concepts that do not meet all of the requirements; otherwise, a superior alternative may be passed by because it fails to meet what may turn out to be a relatively arbitrary requirement. Just as in the needs analysis phase, negotiations with the customer regarding which requirements are really necessary and which are not can often make a significant difference in cost and risk factors, while having minimal impact on performance. Example: Concept Exploration for a New Aircraft.  Two principal functional options to be explored: a propeller‐driven and a jet‐driven aircraft. It remains to explore alternative physical implementations of each of these options. As is usually the case, these are more numerous than the basic functional alternatives. A host of technological advances continue to be developed. For example, automation has become more widespread, especially in autopilots and navigation systems. Autonomous planes may be in the future. Changes in safety requirements, such as for deicing provisions, must also be examined to identify those performance characteristics that should be called out. In exploring alternative implementations, the main features of each candidate system must first be analyzed to see if they are conceptually achievable. At this stage of development, a detailed design analysis is usually not possible because the concept is not yet sufficiently formulated. However, based on previous experience and engineering judgment, someone, usually the systems engineer, must decide whether or not the concept as proposed is likely to be achievable within the given bounds of time, cost, and risk. There are numerous other options and variations that have pros and cons, which typically leave the customer with no obvious choice. Note also that the option to use jet aircraft may partially violate the operational requirement that short‐route capability be maintained. However, as noted earlier, it is not at all unusual at this stage to consider options that do not meet all the initial requirements to ensure that no desirable option is overlooked. The airline may decide that the loss of some routes is more than compensated for by the advantages to the overall system of using jet aircraft. It is also important to note that the entire system life cycle must be considered in exploring alternatives. For example, while the jet option offers a number of performance advantages, it will require a substantial investment in training and logistic support facilities. Thus, assessment of these supporting functions must be included in formulating system requirements. In order to be a “smart buyer,” the airline needs to have a staff

212

EVALUATION AND  SELECTION

well versed in aircraft characteristics, as well as the business of running an airline, and access to consultants or engineering services organizations capable of carrying out the analyses involved in developing the requisite set of performance requirements. Preferred System. Although in most cases it is best to refrain from picking a superior system concept prematurely, there are instances where it is permissible for the requirements definition effort to identify a so‐called “preferred system,” in addition to considering a number of other viable system alternatives. Preference for a system or subsystem may be set forth when significant advanced development work has taken place and produced very promising results in anticipation of future upgrades to the current system. Such work is often conducted or sponsored by the customer. Another justifying factor may be when there has been a recent major technological breakthrough, which promises high gains in performance at an acceptable risk. The idea of a preferred system approach is that subsystem analysis can start building on this concept, thereby saving time and cost. Of course, further analysis may show the favored approach not to be as desirable as predicted.

Technology Development Whether the origin of a new system is needs driven or technology driven, the great majority of new systems have been brought into being, directly or indirectly, as a result of technological growth. In the process of exploring potential concepts for the satisfaction of a newly established need, a primary input is derived from what is called the technology base, which means the sum total of the then existing technology. It is, therefore, important for systems engineers to understand the nature and sources of technological advances that may be pertinent to a proposed system development. System‐oriented exploratory research and development (RAD) can be distinguished according to whether it relates to new needs‐driven or technology‐driven systems. The former is mainly directed to gaining a firm understanding of the operational environment and the factors underlying the increased need for the new system. The latter is usually focused on extending and quantifying the knowledge base for the new technology and its application to the new system objectives. In both instances, the objective is to generate a firm technical base for the projected system development, thus clarifying the criteria for selecting specific implementation concepts and transforming unknown characteristics and relationships into knowns. Both industry and government support numerous programs of RAD on components, devices, materials, and fabrication techniques, which offer significant gains in performance or cost. In recent years, the greatest amount of technology growth has been in the electronics industry, especially computers and communication equipment, which, in turn, has driven the explosive growth of information systems and automation. In government‐sponsored RAD, there is also a continuing large‐scale effort, mainly among government contractors, laboratories, and universities, directed toward the development of technologies of direct interest to the government. As has been noted

ALTERNATIVES ANALYSIS

213

p­ reviously, defense contractors are permitted to charge a percentage of their revenues from government contracts to independent RAD (IRAD) as allowable overhead. A large fraction of such funds is devoted to activities that relate to potential new system developments.

Performance Characteristics The derivation of performance characteristics through the exploration of implementation concepts can be thought of as consisting of a combination of two analytical processes: performance analysis and effectiveness analysis. Performance analysis derives a set of performance parameters that characterize each candidate concept. Effectiveness analysis determines whether or not a candidate concept meets the operational requirements, and if not, how the concept needs to be changed to do so. It employs an effectiveness model that is used to evaluate the performance of a conceptual system design in terms of a selected set of criteria or measures of effectiveness. This is a similar model to that used in the previous phase and to the one employed in the next step, the validation of performance requirements. The main difference in its use is the level of detail and rigor. Performance Analysis.  The performance analysis part of the process is used to derive a set of relevant performance characteristics for each candidate system concept that has been found to satisfy the effectiveness criteria. The issue of relevancy arises because a full description of any complex system will involve many parameters, some of which may not be directly related to its primary mission. For example, some features, such as the ability of an aircraft search radar device to track some particular coded beacon transponder, might be included only to facilitate system test or calibration. Therefore, the performance analysis process must extract from the identified system characteristics only those that directly affect the system’s operational effectiveness. At the same time, care must be taken to include all characteristics that can impact effectiveness under one or another particular operating condition. The problem of irrelevant characteristics is especially likely to occur when the concept for a particular subsystem has been derived from the design of an existing subsystem employed in a different application. For example, a relatively high value of the maximum rate of elevation for a radar antenna assembly might not be relevant to the application now being examined. Thus, the derived model should not reflect this requirement unless it is a determining factor in the overall subsystem design concept. In short, as stated previously, the defined set of characteristics must be both necessary and sufficient to facilitate a valid determination of effectiveness for each candidate system concept. Constraints.  At this phase of the project, the emphasis will naturally be focused on active system performance characteristics and functions to achieve them. However, it is essential that other relevant performance characteristics not be overlooked, especially the interfaces and interactions with other systems or parts of systems, which will invariably place constraints on the new system. These constraints may affect physical form and fit, weight and power, schedules (e.g. a launch date), mandated software tools,

214

EVALUATION AND  SELECTION

operating frequencies, operator training, and so on. While constraints of this type will be dealt with in great detail later in the development process, it is not too soon to recognize their impact during the process of requirements definition. The immediate benefit of early attention to such problems is that conflicting concepts can be filtered out, leaving more time for analysis of the more promising approaches.

8.3  OPERATIONS RESEARCH TECHNIQUES A brief introduction to different operations research techniques is provided for the systems engineer to consider and apply while developing the system concept and considering the alternatives space for the design. Each of these techniques may allow calculation of different aspects of the system and should be used to converse with the stakeholders on what is most important about the system.

Optimization Techniques Optimization seeks to minimize or maximize a selected attribute of the system. Some classic optimization examples are how to maximize profit by identifying how many different products should be developed and sold for, thus minimizing the limited resources to develop a product and maximize the expected profit. Linear programming (LP) is a technique that may be used to find a maximum or minimum value to achieve the best outcome. Examples may be to maximize profits or minimize costs. This technique can also be applied to identifying exactly how many transportation platforms are needed to address the product demands (such as cities), given a finite number of sources (such as warehouses) and the distance from source to destination, in order to minimize transportation costs while satisfying all market demands. LP assumes that the change in the variable will correspond linearly to the outcome. A subset of LP is called integer programming, where all the decision variables are in integers; this may be useful when solving for whole number of units, such as vehicles allocated, X‐ray machines, or computers. An example of LP is shown in Figure 8.1. This is a problem that seeks to minimize the total number of systems to be used to satisfy all functions. Another objective is to minimize the total cost, as each machine can perform multiple functions. This example identifies 6 systems (labeled A through F) and 10 functions (the “1” indicates that the system can perform that function). The LP example is set up to select whether or not the system is used (1 – yes, 0 – no), and totals the cost as well as accounts for each of the functions satisfied (coverage row should equal the desired coverage). Additional constraints can be added if there is a threshold for duplicate functions being performed, so as to minimize the amount of duplication in the answer. The final result is shown with systems B, C, E, and F required for use to satisfy all functions with the minimum total cost. The systems engineer can use tools such as this to perform the “what‐if” analysis at the early phase of the systems engineering (SE) life cycle, in order to explore how the total system concept may look like.

Whether we use the system or not Six systems available

System type Use (Y/N) Single-role system A 0 Single-role system B 1 Single-role system C 1 Multi-role system D 0 Multi-role system E 1 Multi-role system F 1

Objective: Constraints:

Total cost based on selected system

“1” indicates the system can perform the function, while “0” indicates no performance

Ten functions that need to be satisfied

Cost of each system

Cost

Platform cost

2 3 4 8 12 15 Total cost

0 3 4 0 12 15 34

1 1 0 0 0 1 1 2 1 2

2 0 0 0 1 0 1 1 1 1

3 1 0 0 0 1 0 1 1 1

4 0 0 0 1 0 1 1 1 1

Function 5 0 0 0 0 1 0 1 1 1

6 0 0 1 0 0 0 1 1 1

7 0 0 0 1 0 1 1 1 1

8 0 1 0 0 0 0 1 1 1

9 0 0 0 0 0 1 1 1 1

10 0 0 1 0 0 0 1 1 1

coverage desired coverage duplicate threshold

Satisfy all functions while minimizing total cost Integer solution (> = 0) Meets or exceeds all desired threshold values Remains under the the desired duplicate

Figure 8.1.  Assignment problem to minimize number of machines used.

215

216

EVALUATION AND  SELECTION

Decision Making Decision making is a quantitative technique to identify the decision space (e.g. all the possible decisions) and the possible outcomes and likelihood of the decision path to occur. Using a graphical depiction of the decision tree may provide stakeholders with insight into what may be evaluated and considered, in order to see the full scope of decisions and which stakeholders may be affected. Decisions are developed to assist decision makers in identifying alternative decision paths and evaluating and comparing different courses of action. The concept utilizes probability theory to determine the value or utility of alternative decision paths. As the name suggests, a tree is used to formulate the decision space. Typically, two symbols are used – one for decisions and one for events that could occur, and are out of the decision maker’s control. Figure 8.2 depicts a simple decision tree in which two decisions and two events are included. The decisions are depicted by rectangles, and are lettered A and B; the events are depicted by circles, and designated E1 and E2. In this example, each decision has two possible choices. Events also have more than one outcome, with probabilities associated with each. Finally, the value of each decision path is shown to the right. A value can be anything that represents the quantitative outcome of a decision path. This includes money, production, sales, profit, etc. In this example, an engineer is faced with an initial decision, A. There are two choices, A1 and A2. If one chooses A2, then an event will occur that provides a value of either 100 or 30, with probability 0.1 or 0.9, respectively. If one chooses A2, you are immediately faced with a second decision, B, which also has two choices, B1 and B2. Choosing B2 will result in a value of 40. Choosing B1 will result in an event, E2, with two possible outcomes. These outcomes result in values of 70 and 30, with probabilities 0.3 and 0.7, respectively. Which decision path is the “best?” The answer to the last question is dependent on the objective(s) of the trade‐off study. If the study objective is to maximize the expected value of the decision path, then we can solve the tree using a defined method (which we would not go through in detail here). Basically, an analyst or engineer would start at the values (to the right) and work left. First, calculate the expected value for each event. Then at each decision point, 100

0.1 E1 A1

30

0.9

70

0.3

A A2

B1

E2

30

0.7

B B2

Figure 8.2.  Decision tree example.

40

217

OPERATIONS RESEARCH TECHNIQUES

choose the greatest expected value. The expected value is the weighted sum of the legs of the diagram, and select the winner and write the value in the circle or square. In our example, calculating the events yield an expected value of 100(0.1) + 30(0.9) = 37 for E1 and 70(0.3) + 30(0.7)  =  42 for E2. Thus, decision B is between choosing B1 and gaining a value of 42, over B2, with a value of 40. Decision A is now between two expected values: A1 yields a value of 37, while A2 yields an expected value of 42. Thus, choosing A2 yields the greatest expected value. The decision tree solution is depicted in Figure 8.3. Of course, the objective may not be to maximize expected value. It may be to minimize expected loss, or minimize the maximum loss, or even maximize value. If the objective was the last of these three, maximum value, then choosing A1 would be preferred, since only A1 yields a possibility of achieving a value of 100. Choosing A2 yields a maximum possible value of only 70. Thus, the objective of the trade‐off study determines how to solve the tree. An alternative method of using decision trees is to add a utility assessment. Basically, instead of using values, we use utilities. The reason we may want to substitute utilities for actual values is to incorporate risk into the equation. Suppose, for example, that we have the decision tree shown in Figure 8.4, already solved to maximize expected value. However, E1

100

0.1 37

A1

30

0.9 E2

42

42

B1

A2

70

0.3

30

0.7

42 B2

40

Figure 8.3.  Decision path. E1

100

0.2 12

A1

–10

0.8 E2

25 A2

B1

25 0.5

25

150

0.5

B2

Figure 8.4.  Decision tree solved.

–100 20

218

EVALUATION AND  SELECTION

the customer is extremely risk‐adverse. In other words, the customer would forego larger profits than lose large amounts of value (in this case, the value could be profits). It should be noted that numerous automated tools are available to facilitate these explorations (whether through multi‐attribute decision making or set‐based design). There is a large body of published work devoted to these topics; Trade‐off Analytics: Creating and Exploring the System Tradespace (by Parnell 2016) is a recent book that discusses these topics at a depth suitable for practicing systems engineers.

8.4  ECONOMICS AND AFFORDABILITY The systems engineer should be cognizant of affordability assessments that may help decision makers identify the optimum systems concept, understand the resource allocation process, help to quantify stakeholders’ expectations, and help to deliver portfolio outcomes that stay within budget estimates. Three main segments of affordability are discussed: cost estimating and analysis, investment decision analysis, and resource efficiencies.

Cost Estimating and Analysis Often, some initial questions can be asked on how to quantify life cycle costs. The most popular cost estimate is the Life Cycle Cost Estimate (LCCE), which provides a cradle‐ to‐grave estimate. This includes the initial RAD, production, operations/support, and disposal costs. The RAD costs include all program RAD equipment, personnel, facilities, and testing. The production costs include procurement of the initial materials to produce the system, the manufacturing facility, the labor force and training, spares, and any pre‐planned product improvements. The operations/support costs include operating and supporting the system during employment, to include personnel, maintenance, and sustaining investment. Generally, this is the largest portion of the cost in the LCCE. Finally, the disposal costs include demilitarization, detoxification, long‐term waste storage, and any environmental restoration efforts.

Investment Decision Analysis The systems engineer should also be cognizant of how much decisions cost, as well as what is the value of the investment and is it affordable? Typically, a cost–benefit analysis would help the decision makers understand the implications of comparing different alternatives performance and cost to help down selections or final selection decisions. Elements of a cost–benefit analysis can include: • •

Define the objective. It should be clear on what the desired outcome of the study should achieve. Understand problem. This should bind the problem with both the performance as well as the cost boundaries in order to develop clear, achievable, and measurable goals.

219

ECONOMICS AND  AFFORDABILITY

•

•

•

Formulate assumptions and ground rules. Similar to technical performance assumptions, there should also be economic assumptions that will help bound the problem, data collection, and analysis of the data. Identify and examine alternatives. Ideally, here should be a minimum of two alternatives: the existing (“as‐is”) system that provides a baseline of understanding and point of reference, and the future (“to‐be”) alternative that is proposed. There could be several alternatives that are under consideration. Develop cost and benefits estimates. These could be organized into monetary and nonmonetary benefits. Monetary benefits can be categorized into three areas. The first is cost savings, where selecting the alternative may generate a reduced budget requirement in the future. The second is cost avoidance, where the alternative provides a future cost savings or causes a reduction in future resource requirements. The third is improved productivity, where the alternative effects an improvement in ability, efficiency, and/or quality of getting work done.

Nonmonetary benefits can evaluate the system objectives, the criteria on how the objective is satisfied, and the measures by which to evaluate the performance of the alternatives. This may be more oriented toward the performance rather than the monetary aspect, and the systems engineer should ensure that these performance and cost elements are evaluated separately. An example of a lawn‐mower is provided in Figure 8.5 to evaluate performance. All alternatives can then be compared and ranked relative to each other to show the relative benefit to satisfying the objective. A scatterplot may be used to graphically display the performance and cost. Other means of comparing the alternatives may be using multi‐criteria decision analysis techniques in order to evaluate the weighting/ importance of the evaluation criteria, and to assist the decision makers on how the alternatives satisfied the most important criteria. Figure 8.6 provides an example of a scatterplot of cost savings vs. performance. The error bars in each axis can indicate the uncertainty in the calculations or show the range of performance and cost to the decision makers. Baseline systems should also be included in this chart, in order to provide a comparison of how well the alternatives perform and cost to the existing system. In this

Optimize lawn care

Objective

Criteria

Measures

Safety

Safety scores

Suitability

Human factors

Performance

Supportability

Time spent mowing lawn

Figure 8.5.  Nonmonetary benefits example.

220

EVALUATION AND  SELECTION

Baseline Alt 1

Alt 2 Alt 3

1 0.9 B e 0.8 n e 0.7 f i 0.6 t s 0.5 0.4 0

50

100

150

200

250

300

350

Net cost savings ($M/FY)

Figure 8.6.  Scatterplot of performance and cost comparison.

case, the alternative with the highest cost savings and highest performance (top right quadrant of this chart) would be the preferred alternative. Similar to performance evaluations where sensitivity analysis is conducted on selection criteria, the cost criteria may also be modified to determine the impact to the overall selection. Finally, a final recommendation must be made as well as providing justification to the selection choice.

Resource Efficiencies Questions that can be asked include: how do we make an efficient use of the resources, or what are the best courses of action to follow given a resource constrained environment? Again, a comparison from the baseline or current system is needed to help compare the relative benefit of the alternative. Identification of the most important performance/monetary criteria is also key to determine which alternative should be pursued. Defining the workflow of the system’s activities and usage of resources may also be needed in order to calculate how well different alternatives can provide comparative advantage over the baseline system. Sometimes a context diagram can assist the systems engineer to identify the different cost elements of a system, and then to calculate the most critical cost component, in order to perform the analysis. Figure 8.7 provides an example of a context diagram to discuss various healthcare costs, the inner circle represents the broad categories, and the outer circle represents different contributions. The systems engineer can then use this diagram to dialogue with decision makers to help identify which are the most important factors to examine for improvements of efficiencies.

Increased paperwork Tests Services

Care coordination

Greater administrative resource needs Administrative services

Fee for service

Market forces

Medicare

Unit prices Insurance consolidation

Aging population

Competition and consolidation

Provider consolidation

Access to info

Healthcare costs Information on cost and quality

Uninsured Payments for chronic disease

Private insurance Medicaid

Cultural and institutional biases

Medicare

Insurance design

Legal barriers

End of life services

Legal and regulatory

Medical malpractice

Advanced technology

Healthcare professional workforce

Practice restrictions Fraud and abuse

Medicare and medicaid participation Clinical specializations

Workforce shortage

Figure 8.7.  Example context diagram of healthcare costs. Source: Derived from Bipartisan Policy Center (2012).

221

222

EVALUATION AND  SELECTION

8.5  EVENTS AND DECISIONS FOR CONSIDERATION Typical Decisions Made During the SE Life Cycle Some of the decisions that are made throughout the SE life cycle will affect how the system will maintain its schedule for development and operation in the intended environment. Systems engineers should understand the decisions that are made during their system development and will affect the remainder of the project. Decisions can range widely concerning the project. We refer to several system acquisition references to identify the decision points on whether a system should proceed to the next step of development or to cease operations. As this chapter relates to evaluation and selection, we would focus the decision making on how well the candidate system concepts performed. We consider the system context diagram and can ask several questions regarding the performance, cost, and utility in order to evaluate selected decisions, which are found in Table 8.1. TABLE 8.1.  System Decision Questions Question regarding the system

Decision to be considered

Does the system satisfy the requirements?

Requirements acceptance or modification of requirements

Does the system address the users that will interact with the system?

User approval of system concept

Does the system satisfy the envisioned mission/ objective?

Selection of concept for further development

Does the system concept need to work with other systems/organizations?

Interoperability approval

Does the system perform its internal capabilities while performing the mission?

Integration approval

Does the system perform its internal capabilities while performing the mission?

Testing approval

Does the system complete the mission functions it was designed for?

Developmental test approval

Does the system perform under realistic operational conditions to provide an effective capability?

Operational test approval

Is the system safe for human interaction?

Safety approval

Is there appropriate programming and funding to support system acquisition?

Resource management decisions

Is the schedule for system development still on track?

Schedule modification

Is the project cost still on track?

Funding approval or modification

Are the technical risks still manageable and/or progressing with mitigation?

Manufacturing or technical approach approval/modification

EVENTS AND  DECISIONS FOR  CONSIDERATION

223

Other organizations may be concerned with different decisions, based on the industry, stakeholder responsibilities, public safety, or other factors. The Department of Defense (DoD) uses a series of Acquisition Milestones (MS) to evaluate system development progress, which are summarized briefly. MS A decides whether or not to invest in the technology maturation and preliminary design of a system concept. MS B decides whether to invest in product development, integration, and manufacturing. MS C decides to produce production‐representative units for operational testing. Refer to DoD’s Defense Acquisition Guidebook, Chapter  3 (Systems Engineering) (Defense Acquisition University) for additional information. NASA uses “Key Decision Points” (KDP) to determine whether or not the project/ program is allowed to enter the next life cycle phase. Broad phases include: expected maturity to address the need; expected state to determine if the mission/system architecture is credible; expected maturity of the project’s technical/cost/schedule; expected maturity with regard to project remaining on plan; expected state ready for launch; expected state to conduct mission operations and activities; and expected state for project decommissioning and disposal. Refer to NASA’s Space Flight Program and Project Management Requirements (2012) for further description of KDP. The Department of Homeland Security (DHS) uses an Acquisition Decision Event (ADE) to progress through the system development process. These closely follow the DoD process. The four main phases are: justify the need, analyze/select alternatives, obtain the alternative, and either produce/deploy/support the capability until it is retired. Refer to DHS’s Acquisition Management Directive 102‐01 and DHS Instruction Manual 102‐01‐001 (Guidebook) (DHS 2008, 2015) for additional information. Commercial developers may also evaluate the system development process with other decisions, such as market performance, previous customer experience, competitors focus, the overall economy, the cost to produce, the manufacturing process, to name a few. Based on the results of this exploration, companies may decide to proceed or halt the development of system concepts. INCOSE has a series of life cycle stages and decision gates on whether to progress to the next phase or not. Their life cycle stages start with exploratory (investigating new opportunities), concept (evaluating concepts and stakeholders needs), development (planning and risk management), production (producing and testing), utilization and support (operating and providing a sustainable capability), and retirement (storage or disposal). For additional information, refer to INCOSE Systems Engineering Handbook (Shortell 2015).

Types of Resources Affected During Decision Milestones Resources can come in different formats during the systems development. Some include people, organizations, technology, security, budgetary, development (hardware/software), integration, or testing. Resources are often linked to decisions made in the previous phases  –  the common example is the requirements development in early phases sets the resourcing for design and testing in the future phases; if the requirements are found to be developed incorrectly, that would cause an adverse impact to the future resource planning, and may cause project delays while revising the requirements.

224

EVALUATION AND  SELECTION

It is imperative that the resources types are planned and accounted for prior to the development phase or key decision point. Some of these resources, such as manufacturing materials or test ranges, require long lead times to coordinate. Plan for contingency actions if there are unforeseen delays in the project development and to have some utilization of the resources (such as people shifting to different projects or non‐dependent tasks within the project) while the project undergoes a delay. The systems engineer and decision makers can gain insight into the level of resources needed for these decisions through risk‐reduction events to examine the utility and assessment of the technology in the envisioned operational environment. This can help develop new concepts and develop requirements for new programs. Other prototyping efforts can evaluate the technical feasibility of a capability.

8.6  ALTERNATIVE CONCEPT DEVELOPMENT AND CONCEPT SELECTION The decisions in the process of concept definition center on the selection of a particular system configuration or concept in order to satisfy the functions it is to perform. These decisions do more to determine the ultimate performance, cost, and utility of the new system than those in any subsequent phase of the development. Further, in a competitive acquisition process, selection of who will develop the system is largely based on the evaluation of the proposed concept and the supporting documentation. For those reasons, developing the alternatives is of crucial importance to provide the decision makers with a feasible set of concepts to proceed with development. The SE method calls for such decisions to be made by a structured process that considers the relative merit of a number of alternatives before any one is selected. This process is called “trade‐off studies” or “trade‐off analysis,” and is used in decision‐ making processes throughout system development. Trade‐off analysis is most conspicuously employed during the concept definition phase, largely in the selection of the physical implementation of system components.

Formulation of Alternative Concepts In the early development phases, the alternative systems concept construction begins by allocating the functions identified to physical components of the system. In other words, we must determine how we will implement the functions. Of course, this might entail decomposing the top‐level functions in a functional block diagram (or other functional representation) into lower‐level functions. Many times, this activity provides insight into alternative methods of implementing each function. As we identify system components, beginning with subsystems, we are constantly faced with the question of whether multiple functions can and should be implemented by a single physical component. The converse is also an issue: should a single function be implemented by multiple subsystems? Ideally, a one‐to‐one mapping is our goal.

ALTERNATIVE CONCEPT DEVELOPMENT AND  CONCEPT  SELECTION

225

However, other factors may lead one to map multiple functions to a single component, or vice versa. A specific allocation of functions to physical components and the functional and physical interfaces that result from that allocation are considered a single alternative. Other allocation schemes will result in different alternatives. The trade‐offs mentioned above can occur at multiple levels, from the entire system to individual components. Many times these trade‐offs are part of the functional allocation process. An important objective is to ensure that no potentially valuable opportunities are omitted. The following paragraphs discuss issues with developing alternatives. The Predecessor System as a Baseline.  As noted earlier, most system developments are aimed at extending the capabilities or increasing the efficiency of some function that is presently being inadequately performed by an existing system. In cases where the functions of the current system are the same or similar to those of the new system, the current system provides a natural point of departure for system concept definition. Where the main driving force comes from serious deficiencies of limited portions of the current system, an obvious (partial) set of alternative approaches would begin with a minimum modification of the system, restricted to those subsystems or major components that are clearly deficient. Other alternatives would progressively modify or replace other subsystems that may be made obsolescent by modern technology. The general configuration of the system would be retained. In cases where there are new and improved technological advances at the component level, or when there are standard commercial off‐the‐shelf components that could be applied to the new system, the impetus for change to a new system would be technology driven. In this case, a commonly used approach is to introduce improvements sequentially over time as modifications to the current system configuration. Even when there are reasons against retaining any parts of the current system, as, for example, when moving from a conventional, manually controlled process to an automated and higher speed operation, the current system’s general functional configuration, component selection, construction materials, special features, and other characteristics usually provide a useful point of departure for alternative concepts. Technological Advances.  Some new system developments are driven more by advances in technology than by operational deficiencies in the previous system. These advances may arise either in exploratory RAD programs aimed at particular application areas, such as development of advanced jet engines, or may come from broadly applicable technology such as high‐speed computing and communication devices. Such advances are often incorporated into an existing system to achieve specific performance improvements. However, if their impact is major, the possibility of a radical departure from the previous configuration should be included among the alternatives. Beyond a certain point, the existing framework may overly constrain the achievable benefits and should therefore be abandoned. Thus, when advanced technology is involved, a wide range of choices for change should be examined.

226

EVALUATION AND  SELECTION

Original New Concepts.  In relatively rare instances, a really different concept is advanced to meet an operational need, especially when the need had not been previously met. In such instances, there is not likely to be a previous system to use for comparison so that different types of alternatives would need to be examined. Often, various versions of the new concept can be considered, differing in the degree of reliance on new and unproven technology in exchange for projected performance and cost.

Modeling of Alternatives For comparing alternative concepts, each must be represented by a model that possesses the key attributes on which the relative values of the alternatives will be judged. As a minimum, a functional flow block diagram of each should be constructed and a pictorial or other physical description produced for providing a more realistic view of the system candidate. Concept Selection.  The objective of trade‐off studies in the concept definition phase is to assess the relative “goodness” of alternative system concepts with respect to: • • • •

Operational performance and compatibility Program cost Program schedule Risk in achieving each of the above

The results are judged not only by the degree to which each characteristic is expected to be achieved but also by the balance among them. Such a judgment is of necessity highly program‐dependent because of the differing priorities that may be placed on the above characteristics. Design Margins.  In a competitive program, there is always a tendency to maximize system performance so as to gain an edge over competing system proposals. This often results in pushing the system design to a point where various design margins are reduced to a bare minimum. The term “design margin” refers to the amount that a given system parameter can deviate from its nominal value without producing unacceptable behavior of the system as a whole. A reduction in design margins is inevitably reflected in tighter restrictions on the environmentally induced changes in component characteristics during system operation and/or on the fabrication tolerances imposed in the production process. Either can lead to higher program risk, cost, or both. Accordingly, the issue of design margins should be explicitly addressed as an important criterion when selecting a preferred system concept. System Performance, Cost, and  Schedule. To the extent that stated performance requirements are quantified, are found to be an accurate expression of operational needs, and are within current system capabilities, they may be considered

ALTERNATIVE CONCEPT DEVELOPMENT AND  CONCEPT  SELECTION

227

a minimum baseline for the system. However, where they are found to stress the state of the art, or to be desirable rather than truly essential, they need to be considered elastic and capable of being traded‐off against cost, schedule, risk, or other factors. Unstated requirements found to be significant should always be included among the variables. Program cost must be derived from the system life cycle cost, which, in turn, must be derived from a model of the complete system life cycle. The appropriate relative weighting of the near‐term versus long‐term costs depends on the financial constraints of the acquisition strategy. Specific cost drivers should be identified wherever possible. The appropriate weighting of schedule requirements is program dependent and may be difficult to establish. There is an inherent tendency, especially in programs where competition among contractors is especially strong, to estimate both cost and schedule of a new acquisition on the optimistic side, making no provision for the unforeseen delays that always occur in new system developments and are often caused by “unk‐ unks.” This optimism factor also applies to the estimation of system performance and technical risk. Overall, it tends to slant the trade‐off process toward the selection of advanced concepts and optimistic schedules over more conservative ones. Program Risks.  The assessment of risk is another primary SE task. It involves estimating the probability that a given technical approach will not succeed in achieving the intended objective at an affordable cost. Such risk is present in every previously untried approach. In the development of new complex systems, there are many areas in which risk of failure must be explicitly considered and measures taken to avoid such risks or reduce their potential impact to manageable levels. Chapter 12, devoted to the subject of risk management, shows that program risk can be considered to consist of two factors: (i) probability of failure – the probability that the system will fail to achieve an essential program objective, and (ii) criticality of failure – the impact of the failure on the success of the program. Thus, the seriousness of each risk can be qualitatively considered as a combination of the probability of the failure weighted by its criticality to the system. For the purposes of this chapter, the following are examples of conditions that may result in a significant probability of program failure: • • • • •

A leading‐edge unproven technology is to be applied. A major increase in performance is required. A major decrease in cost is required for the same performance. A significantly more severe operating environment is postulated. An unduly short development schedule is imposed.

Selection Strategy.  The preceding discussion shows that the principal criteria involved in selecting a preferred system concept are complex, semiquantitative at best, and involve comparisons of incommensurables. This means that the evaluation of the relative merits of alternatives must be such as to expose and illuminate their most

228

EVALUATION AND  SELECTION

c­ ritical characteristics, and allow the maximum exercise of judgment throughout the evaluation process. Two additional guidelines for conducting complex trade‐off analyses may be useful: (i) to conserve analytical effort, use a staged approach to the selection process, in which only the most likely winners are subjected to the full system evaluation, and (ii) retain the visibility of the complete evaluation profile of each concept (against each critical measure of effectiveness) until the final selection, rather than combining the components into a single figure of merit, a practice that is often employed but that tends to submerge significant differences. In pursuing a staged approach, the following suggestions can serve as a checklist, to be applied where appropriate: 1. For the first stage of evaluation, make sure that a sufficient number of alternative approaches are considered to address all needs and to explore all relevant technical opportunities. 2. If the number of alternatives is larger than can be individually evaluated in detail, perform a preliminary comparison to winnow out the “outliers.” This is equivalent to qualifying the candidates. But be careful not to discard prematurely any candidates that present a new and unique technological opportunity, unless they are inherently incapable of qualifying. 3. For the next stage of evaluation, examine the list of performance and compatibility requirements and select a subset of the most critical ones that are also the most likely to reject unsuitable system concepts. Include consideration of growth capability and design margins as appropriate. 4. For each candidate concept, evaluate its expected compliance with each selected criterion. In the case of partial noncompliance, attempt to adjust the concept where possible to satisfy the criteria. Estimate the resultant performance, cost, risk, and schedule. In the event of conspicuous imbalance in the above, attempt to modify further the concept to achieve an acceptable balance for all requirements. 5. Assign weighting factors or priorities to the evaluation criteria including cost, risk, and schedule, and apply to the ranking of each concept. Avoid concepts that do not have a sound balance of the above factors. 6. For each evaluation criterion, rank order the several candidate concepts. 7. Look for and eliminate clear losers. 8. Unless there is a single clear winner, perform a significantly more detailed comparison among the two or three potential winners. To this end, develop a life cycle model for each concept, along with a work breakdown structure (WBS), and a risk abatement plan. In making the final system concept selection, review the evaluation profile of the merit of each candidate concept against each critical measure of effectiveness to ensure that the choice has no major weaknesses. Check for sensitivity of the result to reasonable variation of the weighting of individual criteria.

CONCEPT VALIDATION

229

8.7  CONCEPT VALIDATION The task of designing a model of the system environment to serve as the basis for concept validation builds on the set of parameters initially established for use in the trade‐off studies of the selection process.

Modeling the System and Its Environment Since the degree of system definition at this stage is largely functional, its validation must rely primarily on analysis rather than testing. The rapid growth of computer modeling and simulation in recent years is providing powerful tools for the validation of complex system concepts. System Effectiveness Models.  In complex operational systems, system effectiveness models are developed in the needs analysis and concept exploration phases to provide a fuller understanding of the effectiveness of existing systems in performing their missions and identifying deficiencies that need to be remedied. These are most often computer simulations that include provisions for varying key parameters to establish the sensitivity of overall performance to environmental and system parameter variations and to determine the nature and extent of system changes needed to offset any identified deficiencies. In the concept definition phase, the construction of system effectiveness models by the system developer depends on whether or not the models used in the previous phases are available, as in the case where the developer is also the customer. In that case, the models can be readily extended to conform to the selected system concept for the validation process. If not, the construction of the model becomes part of the concept definition task. For this and other reasons, the preparation for the competitive effort often begins months (and sometimes years) before the start of the formal competition. Computer models are also capable of validating a host of subsystem or component‐ level technical design features. Areas such as aerodynamics design, microwave antennae, hydrodynamics, heat transfer, and many others can be modeled for analysis through the use of special computer codes. Advances in computer capabilities have made such modeling more and more accurate in predicting system behavior for purposes of design and evaluation. Critical Experiments. When a proposed system concept relies on technical approaches that have not been previously proven in similar applications, their feasibility must be demonstrated. Often, this cannot be done credibly through analysis alone and must be subjected to experimental verification. This is difficult to accommodate in the limited time and constrained resources of a competitive acquisition, but must nevertheless be undertaken to support the proposed system concept. The term “critical experiment” is appropriate in such instances because it is related to the specific purpose of substantiating a critical feature of the design. It purposely stresses the proposed design feature to its extreme limits to ensure that it is not just

230

EVALUATION AND  SELECTION

marginally satisfactory. The term “experiment” rather than “test” is appropriate because it is performed for the purpose of obtaining sufficient data to understand thoroughly the behavior of the system element, rather than merely to measure whether or not the element operates within certain limits. By the same token, extensive data analyses are also performed to illuminate the system behavior.

Analysis of Validation Results The analysis of the results of system validation simulations can produce three different types of unsatisfactory findings that require remedial action: (i) deficiencies in the assumed characteristics of the system being modeled, (ii) deficiencies in the test model, or (iii) excessively stringent system requirements. It is the purpose of the analysis process to attribute the results of the simulation to one or more of the above causes. Beyond these findings, the analysis should also indicate what kind and degree of changes would eliminate the discrepancies. This latter finding usually requires a series of simulations or analyses that test the effect of alternative remedial actions. The feedback resulting from the validation analysis results in an iterative process in which the system model design and environmental model are refined as necessary to bring the system model in compliance with the requirements.

Iteration of System Concepts and Requirements The above description of the validation process implies that only one concept was found to be superior in the concept trade‐off evaluation, and that this concept was then validated against the full system requirements. Not infrequently, two and sometimes more concepts turn out to be nearly equal in preliminary rankings. In that case, each should be evaluated against the full requirements to see if the more rigorous comparison produces a clear discriminant for selecting the preferred concept. The system requirements should always be regarded as flexible up to a point. If the validation or trade‐off results show that one or more stated requirements appear to be responsible for unduly driving up system complexity, cost, or risk, they should be subjected to critical analysis, and if appropriate, highlighted for discussions with the customer by program management.

8.8  TRADITIONAL VS. AGILE SE APPROACH TO CONCEPT EVALUATION From a concept evaluation and selection perspective, traditional SE would proceed in a methodical approach to collect the system objectives, requirements, and functions, as well as the candidate alternative system concepts. By performing analysis of which alternatives will address which requirements and functions, the SE team can then select a concept to continue exploration with the design and interfaces. This approach works

SUMMARY

231

best if the requirements and functions are believed to be correct and few changes are effected. However, this approach may be time consuming in order to collect and analyze all the alternatives. If more promising alternatives emerged after this analysis phase has been done, then there may be wasted time returning to the analysis. An agile SE approach would perform similar actions with analysis of the alternatives, but perhaps look at a smaller segment of the system. This may be performed multiple times, in case additional candidates were discovered and considered, as well as how this may integrate with other portions of the system while the work is in progress. It is helpful to layout the concepts in similar fashion and appearance. Quickly turn around the analysis and if different groups are conducting the study, it may help to share feedback between the groups. This approach can respond well when there is a good deal of change within the system concept.

8.9 SUMMARY Evaluating and Selecting the System Concept Objectives of the evaluation phase are to analyze the range of options that were developed in the previous chapter when a system concept was under development. Decision makers will be cognizant of system performance, as well as development schedule and cost when making decisions regarding the concept to advance to design.

Alternatives Analysis The full alternative space should be considered when evaluating the design to satisfy the functional architecture developed in Chapter 7. After the functions for the system concept have been defined and validated, the systems engineer should then consider how the design may be developed in order to effectively execute the functions. Evaluating all possible combinations of designs may provide a starting point, and eventually provide the decision makers with a limited number of feasible system concepts to progress to design.

Operations Research Techniques The systems engineer may perform some analysis on the problem, in order to calculate the best performance and cost combination when considering the full alternative space. LP techniques seek to minimize or maximize the objective function. Decision analysis techniques can help to visualize the decision space possibilities when determining the best solution to pursue.

Economics and Affordability The systems engineer should be cognizant of affordability assessments which may help  decision makers understand the resource allocation process, helping to quantify

232

EVALUATION AND  SELECTION

stakeholders’ expectations, and helping to deliver portfolio outcomes that stay within budget estimates. Elements of affordability to be considered at this stage of system development include cost estimating and analysis, investment decision analysis, and resource efficiencies.

Events and Decisions for Consideration Some of the decisions that are made throughout the SE life cycle will affect how the system will maintain its schedule for development and operation in the intended environment. Systems engineers should understand the decisions that are made during their system development and will affect the remainder of the project.

Alternative Concept Development and Concept Selection Systems engineers will compile all of their work to present to decision makers regarding the different alternatives that have emerged through analysis, prototyping, and initial conceptual design. System concepts are evaluated in terms of (i) operational performance and compatibility, (ii) program cost and schedule, and (iii) risks in achieving each of the above. Program risk can be considered to consist of a combination of two factors: likelihood that the system will fail to achieve its objectives, and impact of the failure on the success of the program. Program risks can result from a number of sources: • • • • •

Unproven technology Difficult performance requirements Severe environments Inadequate funding or staffing An unduly short schedule

Trade‐off analysis is fundamental in all systematic decision making.

Concept Validation In concept selection, trade‐off analysis should be: • • • • •

Organized – set up as a distinct process Exhaustive – consider the full range of alternatives Semiquantitative – use relative weightings of criteria Comprehensive – consider all major characteristics Documented – describe the results fully

Justification for the development of the selected concept should:

PROBLEMS

• • • • • • •

233

Show the validity of the need to be met. State reasons for selecting the concept over the alternatives. Describe program risks and means for containment. Give evidence of detailed plans, such as WBS, SEMP, and so on. Give evidence of previous experience and successes. Present life cycle costing. Cover other relevant issues, such as environmental impact.

Traditional vs. Agile SE Concept evaluation needs attention by the systems engineer in order for the outcomes to be known in a timely manner. Agile approaches may help by presenting the competitive concepts in a similar manner, sharing views between analysis teams, and effectively performing quantitative evaluation of the leading candidates.

PROBLEMS 8.1 Explain why it is necessary to examine a number of alternative system concepts prior to defining a set of system performance requirements for the purpose of competitive system acquisition. Given the topic of public transportation, generate three to five alternative system concepts. 8.2 In considering potential system concepts to meet the operational requirements for a new system, there is frequently a particular concept that appears to be an obvious solution to the system requirements. Knowing that premature focusing on a “point solution” is poor SE practice, describe two approaches for identifying a range of alternative system concepts for consideration. 8.3 Discuss how LP concepts could be applied to the systems engineer working on a public transportation system concept. Describe two objectives that the transportation system would achieve. Describe three variables that the public transportation system would need to consider in order to achieve these objectives. 8.4 Discuss how decision analysis concepts could be applied to the systems engineer working on a public transportation system concept. Describe two objectives that the transportation system would achieve. Describe three decision variables that the public transportation system would need to consider in order to achieve these objectives. 8.5 Given the personal automobile as the predecessor system to transport users from their homes to their offices, develop five to seven alternative concepts. Organize them by technology used and develop three to five criteria for which to compare all alternatives.

234

EVALUATION AND  SELECTION

REFERENCES Bipartisan Policy Center (2012). “What Is Driving US Health Care Spending.” America’s Unsustainable Health Care Cost Growth. Washington, DC: Bipartisan Policy Center. Defense Acquisition University. Defense Acquisition Guidebook. https://www.dau.edu/ guide books/Shared Documents HTML/Chapter  3 Systems Engineering.aspx (accessed 2 February 2018). Department of Homeland Security (2008). Acquisition Instruction/Guidebook 102‐01‐001, Version 1.9. Department of Homeland Security (2015). DHS Directives System 102‐01, Acquisition Management Directive. NASA (2012). NASA Procedural Requirements NPR 7120.5E, NASA Space Flight Program and Project Management Requirements w/Changes 1–16. Parnell, G.S. (ed.) (2016). Trade‐Off Analytics: Creating and Exploring the System Tradespace. Wiley. Shortell, T.M. (ed.) (2015). INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 4e. Wiley.

FURTHER READING Baker, L., Clemente, P., Cohen, B. et al. Foundational concepts for model driven system design. INCOSE Model Driven Design Interest Group Paper. https://www.opengroup.org/togaf (accessed 2 February 2020). Balmelli, L., Brown, D., Cantor, M., and Mott, M. (2006). Model‐driven systems development. IBM Systems Journal 45 (3): 569–585. Blanchard, B. and Fabrycky, W. (2013). Systems Engineering and Analysis, 5e. Prentice Hall. Donndelinger, J. (2007). Information flow and decision‐making in advanced vehicle development. https://www.mne.psu.edu/simpson/courses/me546/lectures/me579.Cafeo.GM.slides.pdf (accessed 23 December 2018). Estefan, J.A. (2008). Survey of Model‐Based Systems Engineering (MBSE) Methodologies, INCOSE Technical Document INCOSE‐TD‐2007‐003‐02, Revision B. INCOSE. Fowler, M. (2004). UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3e. Addison‐Wesley. Hillier, F. and Lieberman, G. (2009). Introduction to Operations Research, 9e. McGraw‐Hill. Hoffmann, H. (2008). SysML‐Based Systems Engineering Using a Model‐Driven Development Approach. Telelogic White Paper, Version 1. http://www.ccose.org/media/upload/SysML_ based_systems_engineering‐08.pdf (accessed 2 February 2020). Sage, A.P. and Armstrong, J.E. Jr. (2000). Introduction to Systems Engineering. Wiley, Chapter 3. Taha, H. (2017). Operations Research: An Introduction, 10e. Pearson. United States Government Accountability Office (2009). GAO Cost Estimating and Assessment Guide: Best Practices for Developing and Managing Capital Program Costs, GAO‐09‐3SP. US Government. Winston, W. (2003). Operations Research: Applications and Algorithms, 4e. Cengage Learning.

9 SYSTEMS ARCHITECTING

9.1  ARCHITECTURE INTRODUCTION When we think of the word “architecture,” for many people, architecture refers to buildings, and an architect is someone who designs buildings. Over two decades ago, though, a professor at the University of Southern California challenged that notion. He reasoned that as systems grew in complexity, the top‐level design, or more accurately the conceptual design of a system, as defined at the time, was insufficient to guide engineers and designers to accurate and efficient designs. He looked to the field of architecture to understand how complex systems (i.e. buildings) could be created and developed, and (as far as we understand) coined the term “systems architecting.” That man was Eberhardt Rechtin. Architecture is associated with structures, their relationships, and expectation for their design. This applies to complex systems, such as aircraft, power plants, and spacecraft, as much as buildings. Therefore, Rechtin’s premise was to apply the principles from the field of architecture to systems engineering, not as a replacement, but as part of developing a system.

Systems Engineering Principles and Practice, Third Edition. Alexander Kossiakoff, Samuel J. Seymour, David A. Flanigan, and Steven M. Biemer. © 2020 John Wiley & Sons, Inc. Published 2020 by John Wiley & Sons, Inc.

235

236

SYSTEMS ARCHITECTING

Dr. Rechtin defined the term systems architecting in this way: The essence of architecting is structuring. Structuring can mean bringing form to function, bringing order out of chaos, or converting the partially formed ideas of a client into a workable conceptual model. The key techniques are balancing the needs, fitting the interfaces, and compromising among the extremes.

Read closely, the principles of concept development and definition are within his definition. Conceptual design and components of architecting were once lumped into the phrase, “preliminary design.” That term has been replaced by the more extensive “architecting.”

Role of Systems Architect Within Systems Engineering The systems architect’s role is to liaise with the stakeholders and the engineering team to interpret the stakeholders’ vision for the system and then to translate that vision into a recognizable form for the designers that will develop the system. This requires the architect to see the problem from different perspectives in order to faithfully carry out the original system vision. Typically, the architect will be heavily involved at the start of the project, as the system concept is developing and maturing. The systems architect may be part of the team throughout the entire project as teams change and designers and other organizations may enter and leave the project. Hopefully, the systems architect can remain as part of the original team and retain the corporate knowledge from the origins of the system for indoctrination of new team members as well as providing sufficient perspective during critical decision points.

9.2  TYPES OF ARCHITECTURE As there are numerous architecture frameworks, we will concentrate on the three main types of architecture that the systems engineer will focus on: the functional, physical, and allocated. Throughout this section, we will use a notional example of a glucose meter that is used in the healthcare domain, so as to demonstrate the development of the three types of architecture. The glucose meter is used to calculate how much glucose is in a patient’s bloodstream, allowing the patient to then determine the next course of action.

Functional Architecture The functional architecture is performed mainly at the start of the systems engineering project effort. It describes the functions, or actions, that must be performed while completing the system’s objective or mission. This typically will be system or solution agnostic, and will rather focus on describing the verbs (e.g. functions) that

237

TYPES OF  ARCHITECTURE

will describe what needs to be done. These functions may then be organized by mission phase, and also separated by the responsible organization/system/person that will be performing these functions, often called “swimlanes.” The linkage between the functions is often what type of information or data is being exchanged between the functions, and is often a noun. These provide a graphical representation of the lines of responsibility, and serve as conversation between the stakeholders to ensure which organization or system would be responsible to execute these functions. As we are still in the conceptual phase, the system may be more of a system concept than an actual system. For the functional architecture development, we start with identifying the different functions that the glucose meter will perform, how it will interact with the environment, how it will interact with the patient, etc. The 12 functions identified are: F1

Invert voltage

F2

Apply negative voltage

F3

Accept glucose solution

F4

Accept negative voltage

F5

Generate electrical current

F6

Provide reference voltage

F7

Convert current to voltage

F8

Amplify signal

F9

Filter noise

F10

Read voltage

F11

Consult look‐up table

F12

Provide glucose reading

Figure 9.1 provides an example of the glucose meter functional architecture.

Physical Architecture The next phase is the physical architecture, where the actual system components and subsystems are developed. These are typically in a physical block diagram that shows the actual components that make up the system. For this purpose, this is the actual system. The components may also be grouped together that make up the subsystem. The subsystems may also be grouped together to make up the system. The interfaces between the components and subsystems are the physical interfaces, such as wiring, internet connections, Ethernet connections, or wireless connections. In the event of software components, this may be thought of as a class diagram to show the data structures and the different types of information exchanged between the classes.

238

SYSTEMS ARCHITECTING

F5. Generate electrical current

F3. Accept glucose solution

F4. Accept negative voltage

Function Function–function interface

F8. Amplify signal

F7. Convert current to voltage

F6. Provide reference voltage

F9. Filter noise

F10. Read voltage

F2. Apply negative voltage

F11. Consult look-up table

F1. Invert voltage

F12. Provide glucose reading

Figure 9.1.  Glucose meter example functional architecture.

For the physical architecture development, we focus on the physical components of the glucose meter, as well as any components that interact with the environment and the patient. The eight components identified for the glucose meter are: P1

Voltage inverter

P2

Strip reference electrode

P3

Reference electrode

P4

Test strip

P5

Transimpedance amplifier

P6

Operational amplifier

P7

Low‐pass filter

P8

User interface

Figure 9.2 provides an example of the glucose meter physical architecture.

Allocated Architecture This is where the functions and physical architectures merge, in order to determine if we have all the functions and physical components properly allocated. This is a simple accounting of which functions are performed by which components within the system. An ideal allocation is one function is performed only by one component. However,

239

TYPES OF  ARCHITECTURE

P5 Transimpedance amplifier

P4 Test strip

P6 Operational amplifier

P7 Lowpass filter

P8 User interface

P3 Reference electrode

P2 Strip reference electrode

P1 Voltage inverter

Component Component–component connection

Figure 9.2.  Glucose meter example physical architecture.

in complex systems, this may not be the case, as we would have multi‐function components, where one component may perform more than one function. There is some caution in this approach if the component fails that may cause many functions to be unable to perform. Another approach is multiple components completing the same function – in this case, it may be either a cooperative effort or a redundancy of components (e.g. spares ready to perform the function in the case that the leading component fails). In the case of the cooperative effort, it is imperative that the components must complete their functions, as some of them may be time or sequence dependent, in order to succeed. The main purpose of the allocated architecture is to ensure that no function is left behind so that a component in the physical architecture must satisfy the function. Otherwise, the function is left unperformed, which may jeopardize the entire systems’ objective. Conversely, the allocated architecture seeks to ensure that each component is gainfully employed and has some function to perform. Otherwise, the component may be useless to the entire system and may be a waste of resources. During the allocated architecture phase, we look to match up the functions to the physical components. Ideally, there will be a one‐to‐one mapping, but not all the time. The important concept is to make sure that all functions and all components are accounted for. If there are not, then we must go back to either the functional or physical architecture to determine where functions/components should be combined, modified, added, or deleted. Table 9.1 provides the allocation of our glucose meter functions and components, as well as identifying the frequency of how often the functions would be executed by the components. Figure 9.3 provides a visual example of the glucose meter allocated architecture, where the functions are the light‐colored blocks and connected

TABLE 9.1  Glucose Meter Example Allocated Architecture List Physical components P1

P2

P3

Voltage Strip reference Reference inverter electrode electrode Functions F1 F2

Invert voltage 60 Hz Apply negative voltage F3 Accept glucose solution F4 Accept negative voltage F5 Generate electrical current F6 Provide reference voltage F7 Convert current to voltage F8 Amplify signal F9 Filter noise F10 Read voltage F11 Consult look‐up table F12 Provide glucose reading

240

P4 Test strip

P5

P6

P7

P8

Transimpedance Operational Low pass User amplifier amplifier filter interface

60 Hz 1 second 60 Hz 60 Hz 60 Hz 60 Hz 60 Hz 60 Hz 1 second 5 seconds 1 second

241

ARCHITECTURE FRAMEWORKS

P5 Transimpedance amplifier

F5. Generate electrical current

P4 Test strip

F3. Accept glucose solution

Function Component

F4. Accept negative voltage

F8. Amplify signal

F7. Convert current to voltage F6. Provide reference voltage F2. Apply negative voltage

F1. Invert voltage

Function–function interface Component–function allocation

P3 reference electrode

P2 Strip reference electrode

P1 Voltage inverter

F9. Filter noise

P6 Operational amplifier P7 Low-pass filter

F10. Read voltage F11. Consult look-up table

P8 User interface

F12. Provide glucose reading

Figure 9.3.  Glucose meter example allocated architecture.

by arrows, and the physical components are labeled as the grey blocks and allocated to the functions with the dashed lines.

9.3  ARCHITECTURE FRAMEWORKS Architectures are used extensively now in large, complex systems development programs. Once system architecture is requested, the architect and his team have large latitude in developing and integrating products. This initially led to architectures that were technically accurate but diverse in their structure. In order to standardize the architecture development effort, and the products associated with architectures, many organizations developed and mandated the use of architecture frameworks. An architecture framework is a set of standards that prescribes a structured approach, products, and principles for developing system architecture. Two early frameworks that emerged were the Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (C4ISR) Architecture Framework mandated by the US DoD, and The Open Group Architecture Framework (TOGAF) developed for commercial organizations. Both of these early frameworks have evolved significantly and are expected to continue to evolve. The early frameworks were focused on individual systems and their architectures. Newer versions, however, have expanded into the field of enterprise architecture, a subset

242

SYSTEMS ARCHITECTING

of enterprise engineering, or enterprise systems engineering. All of the current versions, including DODAF and TOGAF, have enterprise editions of their frameworks. Many architecture frameworks exist that can be applied to systems development, even if the primary purpose is enterprise architecting. Below is a selected list of architecture frameworks: • • • • • • • • •

DOD Architecture Framework (DODAF) The Open Group Architecture Framework (TOGAF) The Zachman Framework Ministry of Defense Architecture Framework (MODAF) Federal Enterprise Architecture Framework (FEAF) NATO Architecture Framework (NAF) Treasury Enterprise Architecture Framework (TEAF) Integrated Architecture Framework (IAF) Purdue Enterprise Reference Architecture Framework (PERAF)

DODAF.  Although by no means more important or “better” than any other framework, we discuss the basic products of the DODAF to illustrate the basic components of a framework. The DOD framework, like all frameworks mentioned, is divided into a series of perspectives or viewpoints. Figure 9.4 depicts these viewpoints using a figure from the DODAF description. The viewpoints can be observed in three bundles. The first consists of four viewpoints that describe the overall system and its environment: Capability, Operational, Services, and Systems. The intent for this bundle is that the system concept development starts at the beginning with the Capability viewpoints, in order to define what broad capabilities the system should have. This may be a means to solicit initial stakeholders on what types of capabilities should be considered. After the capabilities are completed, the architect then moves on to develop the Operational viewpoints, in which different scenarios and concepts of operations area are explored to further develop the system’s role in the operational environment. After this is complete, then the different Services viewpoints are derived from the operational insight, which defines the different services that may be needed from the system. Finally, the Systems viewpoints may be developed after understanding what is required from the three previous viewpoints. The second bundle consists of the underlying principles, infrastructure, and standards: All, Data and Information, and Standards. The All viewpoints provide some configuration control and establish the overall intent of the architecture. The Data and Information ­viewpoints define the types of data that would be expected to be exchanged throughout the system. Finally, the Standards viewpoints catalog the different standards that may be applicable to the entire system architecture. The second bundle is portrayed sideways, as it is intended to be continually applied and refined at each part of the architecture, as it progresses from Capability viewpoints down to the Systems viewpoints.

243

ARCHITECTURE FRAMEWORKS

Services viewpoint Articulate the performers, activities, services, and their exchanges providing for, or supporting, DoD functions

Systems viewpoint Articulate the legacy systems or independent systems, their composition, interconnectivity, and context providing for, or supporting, DoD functions

Project viewpoint

Articulate operational scenarios, processes, activities, and requirements

Describes the relationships between operational and capability requirements and the various projects being implemented; details dependencies between capability management and the Defense Acquisition System process

Operational viewpoint Standards viewpoint

Articulate applicable operational, business, technical, and industry policy, standards, guidance, constraints, and forecasts

Data and Information viewpoint

Articulate the data relationships and alignment structures in the architecture content

All viewpoint

Overarching aspects of architecture context that relate to all views

Capability viewpoint Articulate the capability requirement, delivery timing, and deployed capability

Figure 9.4.  DODAF Version 2.0.2 viewpoints.

The final bundle is the Project viewpoint, which serves to provide structure in the form of project management as the system architecture is under development. Similar to the second bundle, this will be updated throughout the entire architecture development. Version 2 of this framework is easily scalable from the system level to the enterprise level, where multiple systems are under development and would be integrated into legacy systems architecture. In fact, each of the three major system‐level architecture frameworks, DODAF, MODAF, and TOGAF, are now compatible with enterprise development efforts. Furthermore, with the addition of a Services viewpoint, Service‐ Oriented architectures are now possible within the DODAF. Within each viewpoint, a set of views is defined. A total of 52 views are defined by DODAF, organized within the 8 viewpoints. For each view, a variety of methods and techniques are available to represent the view. For example, one view within the Operational viewpoint is the Operational Activity Model. This view can be represented by a variety of models, such as the functional flow block diagram. Other models can be used to represent the Operational Activity Model, such as an IDEF0 diagram or a combination of diagrams. Thus, an architecture framework will typically have three layers of entities: a set of viewpoints that define the framework, a set of views that define each viewpoint, and a set of models that can represent the view. Every large system development effort must have a minimum set of architecture views. Rarely will system architecture contain all 52 architecture views. Pertinent views

244

SYSTEMS ARCHITECTING

are decided before hand by the systems engineer and system architect, depending on the intended communication and the appropriate stakeholders. The key to developing successful system architectures is to understand the purpose of the architecture. Although each system development effort is different, depending on the magnitude and complexity of the system, all architectures have at least one common purpose: to communicate information. Choosing which framework to use, which viewpoints within the framework, which views within the viewpoint, and which models within the view all depends on the purpose the architect is trying to achieve. DODAF Version 2.0.2 emphasizes “fit for purpose,” which encourages the systems architect to produce only the viewpoints and views that are applicable to the system development at that particular time. It does no good to generate all the views if they are neither needed nor applicable to the system. As the systems architect understands and learns more about the system, then additional views may be added to the architecture. The existing frameworks define the superset of viewpoints and views that may be included within the architecture. Within each view, the framework typically suggests candidate models, which can be used to represent the view. A hallmark of the current frameworks, however, is the flexibility inherent within each view. If the architect desires to use a model not included in the candidate list, he can – as long as he does not violate the overall framework constraints. For example, many of the current frameworks were initially defined using traditional, structured analysis models (e.g. IDEF0, FFBD, and data flow diagrams) to define their views. However, engineers familiar with object‐oriented (OO) models began to use a combination of OO and structured analysis models to represent views. As the trend increased, the organizations responsible for the common architecture frameworks revised the available models to include OO models that can represent the views. As of this publication, the Unified Architecture Framework (UAF) has been released and supplants DODAF; it is more amenable to integration with SysML models and commercial applications.

9.4  ARCHITECTURAL VIEWS The notion of architectural views is to develop representations of a system from multiple perspectives, or views, to assist the stakeholders in understanding a system concept (and making those valuable trade‐off decisions) before extensive development has occurred. While many different architecture development methods and guidelines exist today, all have a very common set of these perspectives. In general, system architecture will present three common views of a system.

Operational View This representation is from the users’, or operators’, perspective. This view would include products that address operational system phases, scenarios, and task flows. Information flow from the users’ perspectives might also be addressed. User interfaces

ARCHITECTURAL VIEWS

245

would also be described. Example products that might be included in this view would be operational figures or graphics, scenario descriptions (including use cases), task flow diagrams, organization charts, and information flow diagrams.

Logical View This representation is from the manager’s or customer’s perspective. The logical view would include products that define the system’s boundary with its environment and the functional interfaces with external systems, major system functions and behaviors, data flow, internal and external data sets, internal and external users, and internal functional interfaces. Example products for this view would be functional flow block diagrams, context diagrams, N2 diagrams, IDEF0 diagrams, data flow diagrams, and various stakeholder‐specific products (including business‐related products).

Physical View This representation is from the designers’ perspective. This view would include products that define the physical system boundary, the system’s physical components and how they interface and interact together, the internal databases and data structures, the IT infrastructure of the system and the external IT infrastructure with which the system interfaces, and the standards in force in its development. Example products include physical block diagrams down to a fairly high level of detail, database topologies, interface control documents (ICDs), and standards. Different architectural guidelines and standards may use different names, but all three of these perspectives are included in every architectural description. A common question from someone just introduced to the concept of systems architecting is, “What is the difference between architecting and designing?” A convenient method of answering that question is to delineate the uses of architecture versus a design. System architecture is used • • • •

To To To To

discover and refine operational and functional requirements drive the system to a specific use or purpose discriminate between options resolve make/buy decisions

A system design is used • • •

To develop system components To build and integrate system components To understand configuration changes as the system is modified

246

SYSTEMS ARCHITECTING

The nature of these uses suggests there is a difference between architecting and engineering. Systems architecting is largely an inductive process that focuses on functionality and behavior. Consequently, architecting deals with unmeasurable parameters and characteristics as much if not more than measureable ones. The toolset is largely un‐quantitative and imprecise  –  diagramming is a large component of the architect’s toolset. Heuristics typically guide an architect’s decisions rather than algorithms. Design engineering can be contrasted with architecting, since it relies on deductive processes. Engineering focuses on form and physical decomposition and integration. Consequently, design engineering deals with measurable quantities, characteristics, and attributes. Thus, analytical tools derived from physics are the engineer’s primary tools. Given these characteristics of the two fields (which should certainly not be considered loosely coupled), the architect tends to be active in the early phases of the system development life cycle. The architect tends to be rather dormant during the detailed design, fabrication, and unit testing phases. Integration and system testing will see the architect emerge again to ensure requirements and top‐level architectures are being followed. In contrast, the design engineer’s activity peaks during the architect’s dormant phases.

Architecting in the Engineering Hierarchy With the differences between architecting and engineering, it is obvious the two activities are separate. An obvious question then arises: who works for whom? Although there are exceptions, systems architecting is a subset of systems engineering. This is different from the role and place of the traditional architect, which is typically at the top. When a new building is designed, developed, and constructed, the architect plays the primary role in the building’s design and continues with that prominent role throughout development and construction. In systems development, the systems engineer holds the prominent technical position.

9.5  ARCHITECTURE DEVELOPMENT Systems engineers must have some knowledge of how systems architectures are developed, in order to effectively communicate between the different teams: stakeholders, users, designers, maintainers, etc. A brief approach that systems engineers can take while developing some of the architecture types is listed below. As the stakeholders have some vision of how their intended system will operate, the architect interfaces with them and learns on what system concept should perform. Utilizing drawings and descriptions of the operational environment, the stakeholders can then paint a picture of what the environment looks like; what the system must do; what it must face, collaborate, combat, or overcome; and what the envisioned end state would look like after successful completion of its objective. During this description, the functional architecture starts to come to life by documenting the various functions that are being performed, both by the principal system, but also by the collaborating systems as well as the adversary systems. Stakeholders are consulted to ensure that the correct functions are being described, as well as the linkage between various functions.

ARCHITECTURE TRACEABILITY

247

The architecture development continues to the physical perspective to define the actual components within the system that will perform these functions. The physical architecture will continue to be constructed as multiple components will be grouped to the subsystems, and then grouped in turn to form the system. This process will continue for the collaborating and adversary systems as well, possibly uncovering specific interoperability features (e.g. correct data fields, data formats, periodicity) that must be resolved between different systems. The architecture development concludes with consulting between the two existing architecture products to properly allocate all functions and components. This may be an iterative exercise as the designers and functional architects require some coordination to ensure all components and functions are accounted for. If not, then a rework of the requirements, functions, or design may be necessary to solve the allocation problem.

9.6  ARCHITECTURE TRACEABILITY After each stage of the architecture development is complete, there should be some traceability between the various systems engineering artifacts. Functional architecture will link to the requirements that they satisfy. Physical architecture will link to the functions that they execute. Other nonfunctional requirements may also be identified to what part of the physical system must be evaluated (e.g. safety, durability, resilience, maintainability, interoperability requirements). Eventually, all parts of the architecture may be traceable to other parts. The current commercial toolsets provide this feature, so the systems engineer does not have to manually create and maintain this traceability, which is fortunate in the event that the system complexity increases. Traceability is also valuable when changes are made to the architecture, design, tests, or requirements: what happens when one part is changed? How much of the other parts need to be modified to adapt to that change? To manually review each element that is affected every time a change occurs would be an extraordinary effort. Existing toolsets can automatically identify what is affected (and often perform the modification) when a change occurs within the architecture. Stakeholders can also use the traceability to show where their vision and direction has impacts on the architecture development. Architects can also use the traceability to ensure that the direction is faithfully implemented, while following constraints, standards, and other stakeholder competing needs. It is precisely this form of traceability that could promote understanding among competing stakeholders to show how the system concept will be developed, which may promote additional cooperation.

Architecture Allocation As mentioned before regarding the allocation of functions to components, the architecture traceability may satisfy the allocation, in addition to automatically alerting the architect if too many functions are levied on one component, so as to avoid a single point of failure. Evaluating how the allocation between functions and components may  also give a sense of importance on certain functions and components, in which

248

SYSTEMS ARCHITECTING

additional resiliency to failure may be warranted. Some of the resiliency may come in the form of redundant components, ready spares, additional logics, or other means to ensure that the system continues to function when confronted with some form of degradation. Allocation can then be used in a form of simulation or analysis to ensure that the architecture under development can handle the various environments and threats that the system was designed to confront.

Toolsets Many commercial toolsets are available to develop architecture products. When considering the selection of the toolsets, systems engineers should consider several factors. The primary choice is the expertise of the architect in order to generate the desired products for the stakeholders. The architect must be confident in their ability to produce the artifacts, promote interoperability, and evaluate the development when presented the operational environments and challenges the system would face. The next important choice is the collaboration potential within the project: if organizations within the team are using the same tool, there is likely a greater chance of communication efficiencies to be gained, and less chance of confusion on terminology that may be tool‐specific. Mutual understanding and a more robust system design should be expected if the team is working with the same toolset. Other factors to consider toolsets may be stakeholder familiarity with the toolsets, either by reputation or previous experience, where a knowledgeable stakeholder can be powerful in describing their system vision and capabilities. Additional features that can assist the systems engineer and the systems architect are exportable formats, such as images or reports that describe the technical details of the architecture. Digital data exports can provide additional interoperability and understanding of the architecture, in terms of collaboration with the team. Many toolsets have the ability to create an interactive website that users can walk through the architecture, but do not require the actual tool to read the products.

9.7  ARCHITECTURE VALIDATION Validating the architecture depends on the purpose, audience, and products developed. If the architecture is intended to capture existing processes and capabilities of existing systems in order to document and educate others, then this may be a relatively straightforward task, as there should be current users that are familiar with the system that can help verify that the product is an accurate representation of the system. When different users of the same system come together for their critique, it may be enlightening for all parties to appreciate their peers (which may or may not be known) on how the system is being used. It is also instructional for current users as well as new stakeholders that wish to understand how the system works.

SUMMARY

249

If the architecture is intended to portray a future “to‐be” system concept, this may be more of a challenge to find the right stakeholders to help validate the concept, particularly if the system is a radical departure from existing designs and missions. The systems architect must seek out the right type of stakeholder that holds an open mind, is willing to accept other ideas (which may be radically different than their own), and have a sense of trust to allow the system architecture to develop and evolve to attain the future objective. Representative users should also be carefully selected, as some users will revert back to the current way of operations, and may not be willing to provide sufficient critical thoughts to see how the future system would operate. It is important to have stakeholders and partners to keep in mind future operations, environments, threats, partnerships, and opportunities to envision a realistic future system concept for which to develop. Validation of the concept may emerge when a sufficient sampling of the population of users, maintainers, and stakeholders have been exposed to the architecture. This may be realized during exercises or limited utility experiments where future concepts are tested in a future operational environment. It is here that the architecture can be tested and evaluated on whether it holds promise in the future world, or can be evaluated and discarded/modified if the results are not satisfactory. Collection of objectives, exercise data, and questions to evaluate the architecture concept may be used to determine the utility of the architecture.

9.8 SUMMARY Architecture Introduction The systems architect’s role is to liaise with the stakeholders and the engineering team to interpret the stakeholders’ vision for the system and then to translate that vision into a recognizable form for the designers that will develop the system. This requires the architect to see the problem from different perspectives in order to faithfully carry out the original system vision.

Types of Architecture As there are numerous architecture frameworks, we will concentrate on the three main types of architecture that the systems engineer will focus on: the functional, physical, and allocated. The functional architecture is performed mainly at the start of the systems engineering project effort. It describes the functions, or actions, that must be performed while completing the system’s objective or mission. The next phase is the physical architecture, where the actual system components and subsystems are developed. These are typically a physical block diagram that shows the actual components that make up the system. This is where the functions and physical architectures merge, in order to determine if we have all the functions and physical components properly

250

SYSTEMS ARCHITECTING

allocated. This simple accounting of functions is performed by which components are within the system.

Architecture Frameworks An architecture framework is a set of standards that prescribes a structured approach, products, and principles for developing system architecture. Every large system development effort must have a minimum set of architecture views. The key to developing successful system architectures is to understand the purpose of the architecture. Although each system development effort is different, depending on the magnitude and complexity of the system, all architectures have at least one common purpose: to communicate information.

Architectural Views Architecture frameworks define the structure and models used to develop and present system architecture. These frameworks are meant to ensure consistency across programs in articulating the various perspectives. In general, system architecture will present three common views of a system: • • •

Operational view: This representation is from the users’, or operators’, perspective. Logical view: This representation is from the manager’s or customer’s perspective. Physical view: This representation is from the designers’ perspective.

Architecture Development As the stakeholders have some vision of how their intended system will operate, the architect interfaces with them and learns on what system concept should perform. The architecture development continues to the physical perspective to define the actual components within the system that will perform these functions. The architecture development concludes with consulting between the two existing architecture products to properly allocate all functions and components.

Architecture Traceability After each stage of the architecture development is complete, there should be some traceability between the various systems engineering artifacts. Functional architecture will link to the requirements that they satisfy. Physical architecture will link to the functions that they execute. Other nonfunctional requirements may also be identified to what part of the physical system must be evaluated (e.g. safety, durability, resilience, maintainability, interoperability requirements). Eventually, all parts of the architecture may be traceable to other parts.

FURTHER READING

251

Architecture Validation It is vital to identify the purpose of the architecture in order to properly validate it. If the architecture is intended to portray a future “to‐be” system concept, this may be more of a challenge to find the right stakeholders to help validate the concept, particularly if the system is a radical departure from existing designs and missions. If the architecture is intended to capture existing processes and capabilities of existing systems in order to document and educate others, then this may be a relatively straightforward task, as there should be current users that are familiar with the system that can help verify that the product is an accurate representation of the system.

PROBLEMS 9.1 Develop functional architecture views for a public transportation system concept; generate a functional architecture that contains eight to ten functions. 9.2 Develop physical architecture views for a public transportation system concept; generate a physical architecture that contains eight to ten components. 9.3 Develop allocated architecture views for a public transportation system concept; generate an allocated architecture that is based on 9.1 and 9.2 products. 9.4 Describe how the systems architect would use the architecture during concept development. Describe how the systems engineer would use the architecture during concept development. In what ways are the architect and engineer similar? How are they different? 9.5 Compare and contrast how DODAF and TOGAF are similar and different in terms of users, usage, and application. 9.6 Describe how architecture validation would be performed in the case of the public transportation architecture. Who would need to be consulted? What are some questions to ask? What would be a successful outcome?

FURTHER READING Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Modeling Language. Addison‐Wesley Professional. Department of Defense, Chief Information Officer (2010). The DoDAF Architecture Framework Version 2.02. https://dodcio.defense.gov/Library/DoD‐Architecture‐Framework (accessed 25 December 2018). Estefan, J.A. (2008). Survey of Model‐Based Systems Engineering (MBSE) Methodologies. INCOSE Technical Document INCOSE‐TD‐2007‐003‐02, Revision B. International Council on Systems Engineering (2015). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, Version 4.0. Wiley.

252

SYSTEMS ARCHITECTING

Maier, M. and Rechtin, E. (2009). The Art of Systems Architecting. CRC Press. The Open Group (2009). TOGAF Version 9 Enterprise Edition. Document Number G091. http:// www.opengroup.org/architecture. Yanez, M. (2013) Glucose Meter Fundamentals and Design. Freescale Semiconductor.

10 MODEL‐BASED SYSTEMS ENGINEERING (MBSE)

10.1  MBSE INTRODUCTION “Model Based Systems Engineering (MBSE) is an emerging new paradigm for improving the efficiency and effectiveness of systems engineering through the pervasive use of integrated descriptive representations of the system to capture knowledge about the system for the benefit of all stakeholders” (Noguchi 2016). As MBSE becomes the typical way to execute systems engineering, systems engineers will be increasingly expected to develop proficiency in system modeling tools, languages, and methods. MBSE does not replace sound systems engineering principles; it increases their impact through by its inherent rigor, consistency, and fidelity. With the advent of formal modeling languages, such as the Unified Modeling Language (UML) and the Systems Modeling Language (SysML), and system architecture frameworks, such as the Unified Architecture Framework (UAF), Department of Defense Architecture Framework (DoDAF), and The Open Group Architecture Framework (TOGAF), the ability of systems engineers to create high‐ fidelity representations of system requirements, behaviors, and structures has never been greater. The exploration and definition of system concepts have now been formalized Systems Engineering Principles and Practice, Third Edition. Alexander Kossiakoff, Samuel J. Seymour, David A. Flanigan, and Steven M. Biemer. © 2020 John Wiley & Sons, Inc. Published 2020 by John Wiley & Sons, Inc.

253

254

MODEL‐BASED SYSTEMS ENGINEERING (MBSE)

and a subset of systems engineering, systems architecting, has risen to greater ­significance. In broad terms, the system architecture can be thought of as a descriptive model of the system or the system concept. After the first formal version of UML was released, The Object Management Group (OMG) provided the first version of the model‐driven architecture (MDA). This architecture recognized the shift from a code‐centric software development paradigm to an object‐centric paradigm, enabled by the then‐de facto standard for software engineering model languages  –  UML. The MDA presented a set of standard principles, concepts, and model definitions that allowed for consistency in defining object models across the software community. The MDA delineated between the “real” system and its representation by a set of models. These models, in turn, conform to a metamodel definition, which would, in turn, conform to a meta‐metamodel definition. Several concepts, processes, and techniques were presented in the literature using this concept, although the names differed: model‐driven development, model‐driven system design, and model‐driven engineering. They all were based on focusing on a model and its metamodel to represent the system from the early stages of development through deployment and operation. With attempts to merge software and systems engineering processes and principles underway, model‐driven development was applied to systems development in various forms. In 2001, the International Council on Systems Engineering (INCOSE) established a Model‐Driven Systems Design workgroup to customize UML for systems ­engineering. By 2006, INCOSE and the OMG adopted OMG SysML.

Need for MBSE Modern systems are increasingly complicated and complex, with emergent behavior driven by the interaction of hardware, electronics, software, and users. Systems designs are often developed across multiple organizations who need to collaborate and easily exchange data. Traditional document‐intensive systems engineering (DISE) approaches depend upon the readers of disconnected documents to mentally integrate them. They also rely on inherently human‐readable text to convey intent instead of a purpose‐built language with crisp semantics. “What distinguishes MBSE from traditional implementations of systems engineering (SE) is that the process of progressively developing the requirements baseline, functional architecture, and physical architecture is structured around the incremental refinement of an integrated set of increasingly detailed descriptive models. These models become the principal means of knowledge capture and communication about a system over its lifetime, replacing the large number of discrete documents that become inconsistent as each independently evolves over time” (Noguchi 2016). In 2018, the United States Department of Defense released its Digital Engineering Strategy; this strategy is intended to reform defense acquisition to allow military systems to be released at the “speed of relevance.” The traditional waterfall approach to create thousands of requirements and the years‐long development cycle may soon

MBSE INTRODUCTION

255

give way to an MBSE‐supported, concept‐to‐Preliminary Design Review (PDR) (Cohen 2019). The Digital Engineering Strategy has five goals: • • • • •

Formalize the development, integration, and use of models to inform enterprise and program decision making. Provide an enduring, authoritative source of truth. Incorporate technological innovation to improve the engineering practice. Establish a supporting infrastructure and environment to perform activities, collaborate, and communicate across stakeholders. Transform the culture and workforce to adopt and support digital engineering across the life cycle.

MBSE Use in the SE Life Cycle MBSE adds value wherever it is used within a life cycle; errors and inconsistencies between disconnected source documents and artifacts can be readily identified as a model is constructed and matured. The greatest value is typically gained when MBSE is applied from project inception; this allows all relevant data to be modeled as they are created (rather than reformatted and refactored later). It also permits the development team to see early value (as inconsistencies are identified and the inherent rigor of the modeling effort structures the team’s efforts). The lead systems engineer has an added responsibility to define where modeling fits into the project development plans and architecture. By having the model as a resource throughout the development journey, teams gain a sense of ownership rather than a feeling that an external framework is being imposed on their work. If MBSE is implemented later in the life cycle, there are diminishing returns for the effort. However, just as converting engineering drawings to CAD can provide benefits for the sustainment and maintenance of legacy systems, a late‐stage MBSE effort can add significant value in reverse‐engineering or upgrading a legacy system to extend its life. Ancillary tools for analysis and management facilitate the unification of the descriptive system model with product line engineering (PLE), product lifecycle management (PLM), and product data management (PDM) to provide the ability to share as‐conceived, as‐designed, as‐built, as‐maintained, and as‐disposed information about a system. This has significant implications for improving long‐term maintenance and logistical support of consumer goods (such as automobiles) in addition to aerospace, health, network, and defense systems.

Differences Between MBSE and Traditional Document‐Intensive SE The basic notion behind MBSE is that a model of the system is developed early in the process and grows organically over the system development life cycle until the model becomes the build‐to baseline. Early in the life cycle, the models have low levels of

256

MODEL‐BASED SYSTEMS ENGINEERING (MBSE)

fidelity and are used primarily for decision making. As the system is developed, the level of fidelity increases until the models fully represent the architecture. “Architecting defines what to design, while design defines what to build” (Sillitto 2014). Although this approach may appear similar to the traditional systems engineering approach, several significant differences exist between the two; the foremost difference is the products created by each approach. In traditional systems engineering (including either of the structured analysis or object‐oriented approaches), the primary products early in the system development life cycle are static representations of the system in hardcopy or softcopy format. In MBSE, the primary products are models: integrated collections of information (elements, attributes, and relationships), which can be queried, displayed, error‐checked, and executed. Reviewing a model‐driven system design (at any point in the life cycle) involves interrogating a set of models or reviewing an automatically generated set of derived work products (such as tables, matrices, or diagrams). Additional process improvements are also possible; because the traditional, text‐ based requirement was formerly the primary method of communicating design intent, large numbers of requirements were created. This directly contributed to administrative challenges; change control and “wordsmithing” of requirements that did not directly add intellectual content to the development effort. The number of text‐based requirements may be reduced if stakeholders are able to consume model content directly; this inherently reduces the resource drain associated with stewarding the requirements. Just as there is no reason to translate a circuit diagram or construction blueprint into text stating how to wire a resistor or where to place a window, property‐based descriptions or well‐ formed model elements (such as a state machine) can clearly communicate design intent and engineering direction. A relatively small set of user needs, goals, measures of effectiveness (MoEs), and key performance parameters (KPPs) can be used to shape the system model; detailed authoring of system, subsystem, and component requirements can be deferred until the relevant portions of the model are suitably mature. This defers and reduces the significant overhead of requirements management and permits the system model to be used to rapidly facilitate analysis and communication of intent between stakeholders. In addition, automated comparison of value‐based requirements with analysis results can immediately highlight shortfalls and deviations. Requirements that simply duplicate model content in textual form could be eliminated if stakeholders accept and understand the equivalent model representations and products. Because SysML models are essentially graph databases of elements, attributes, and relationships, they are machine‐readable and can be used to “drive” analyses and may be subjected to automated analysis. For example, the use of validation tools can error‐check models either automatically or on‐demand. By incorporating rules based on desired modeling conventions (an organization’s “style guide”), these validation tools can provide immediate feedback to modelers about errors and gaps. Some errors can be eliminated completely by careful customization of the modeling language. For example, power usage relationships may be created to connect power scenarios with part properties that are consuming power during a given scenario. By customizing the

MBSE INTRODUCTION

257

language so that the only legal source of a power usage relationship is a power scenario and the only legal target is a part property, a modeler effectively prohibits the creation of illegal relationships. In addition, on‐demand queries can be created to answer key program or systems engineering questions and enable stakeholders to gain insights about the system being modeled.

Systems Modeling and Elegance The creation of an authoritative system model provides opportunities to improve the development process. A competently executed model should represent a given element of information once and reference it throughout the rest of the model as needed; this elimination of redundancy avoids potential conflict and improves efficiency. Madni (2012) discusses elegance in modeling and its applicability to designs; it is a term typically applied to solutions that are simple but effective. He proposes 12 key metrics for elegance: 1.  Purposivity (accomplishes purpose or goal with minimum side effects/negative consequences, given priorities) 2.  Parsimony (accomplishes intended purpose with a minimum number of components, resources, and interventions in routine/contingency situations) 3.  Transparency (inspectable system behavior during operation or use) 4.  Scalability (design scales linearly with increase in complexity) 5.  Sustainability (endure cost‐effectively in the face of anticipated and unanticipated change) 6.  Bonding (visceral/emotional connection with users/operators) 7.  Efficiency (accomplish desired outcome with minimum resources, effort, and waste) 8.  Evolveability (adapt/extend seamlessly to meet new market/operational demands) 9.  Affordability (total costs within customer’s acceptance threshold) 10.  Usability (ease of use with negligible errors and error rate) 11.  Utility/Impact (monetary/non‐monetary net positive effect achieved for investment made) 12.  Predictability (system behavior can be determined in a variety of future contexts and scenarios) Well-formed system models support design elegance; metrics can be developed for a given model to directly assess its parsimony and efficiency. In addition, behaviors can be broken down and the interconnectivity of these functions can then be analyzed (by design structure matrices or other methods) and they can be partitioned using a variety of algorithms. This allows the system model to directly support nonarbitrary segmentation and allocation of functions to individual components.

258

MODEL‐BASED SYSTEMS ENGINEERING (MBSE)

The Elegance Equation Following Madni’s (2012) work, Vinarcik, M. (2018) proposed that: Every modeling effort has several factors that may be used to describe it: η = Efficiency factor = output/input (0