Agile Systems Engineering

Bruce Powel Douglass

• Publisher: Morgan Kaufmann
• Year: 2015
• ISBN:
  9780128023495
• Topic: Computer Science
• Subtopic: Software Development
• Index: Computer Science

Agile Systems Engineering presents a vision of systems engineering where precise specification of requirements, structure, and behavior meet larger concerns as such as safety, security, reliability, and performance in an agile engineering context.

World-renown author and speaker Dr. Bruce Powel Douglass incorporates agile methods and model-based systems engineering (MBSE) to define the properties of entire systems while avoiding errors that can occur when using traditional textual specifications. Dr. Douglass covers the lifecycle of systems development, including requirements, analysis, design, and the handoff to specific engineering disciplines. Throughout, Dr. Douglass couples agile methods with SysML and MBSE to arm system engineers with the conceptual and methodological tools they need to avoid specification defects and improve system quality while simultaneously reducing the effort and cost of systems engineering.

• Identifies how the concepts and techniques of agile methods can be effectively applied in systems engineering context
• Shows how to perform model-based functional analysis and tie these analyses back to system requirements and stakeholder needs, and forward to system architecture and interface definition
• Provides a means by which the quality and correctness of systems engineering data can be assured (before the entire system is built!)
• Explains agile system architectural specification and allocation of functionality to system components
• Details how to transition engineering specification data to downstream engineers with no loss of fidelity
• Includes detailed examples from across industries taken through their stages, including the "Waldo" industrial exoskeleton as a complex system

Chapter 1

What Is Model-Based Systems Engineering?

This chapter provides a short overview of systems engineering approaches, activities, and goals and how model-based systems engineering (MBSE) can help achieve them. The chapter makes the distinction between systems and discipline-specific engineering disciplines and then identifies and describes the primary systems engineering activities and their resulting engineering data. Following this, the three primary workflow models (V-Model, Incremental Model, and Hybrid V-Model) are discussed as means for sequencing the system engineering activities.

With that basic understanding in place, the chapter proceeds with the advantages of MBSE over traditional document-centric approaches—such as supporting deeper reasoning about system properties and providing a single source of engineering truth. A short discussion of how to move from traditional methods to MBSE is supplied in the section on “Adopting MBSE.” The chapter winds up with “The Rules of Modeling” to provide a set of guidelines for new practitioners.

Keywords

model-based systems engineering; MBSE; systems engineering; high-precision modeling; adopting MBSE; capability assessment; modeling rules

Chapter Outline

1.1 Key Systems Engineering Activities 3

1.1.1 Identifying Customer Needs 4

1.1.2 Specifying System Requirements 5

1.1.3 Assess Dependability 5

1.1.4 Evaluating Alternative Architectures and Technologies 6

1.1.5 Selecting Specific Architectures and Technologies 7

1.1.6 Allocating Requirements and Interfaces to Architectures 7

1.1.7 Hand Off to Downstream Engineering 7

1.1.8 Integrate Discipline-Specific Designs into System Composite 8

1.1.9 Verify System as a Whole 8

1.1.9.1 Syntactic verification 9

1.1.9.2 Semantic verification 10

1.1.9.3 System verification 12

1.1.10 System Validation 12

1.2 Systems Engineering Data 13

1.2.1 System Development Plan 13

1.2.2 Stakeholder Requirements 13

1.2.3 System Requirements 14

1.2.4 Certification Plan 14

1.2.5 Subsystem Requirements 14

1.2.6 Discipline-Specific Requirements 14

1.2.7 Safety Analysis 14

1.2.8 Reliability Analysis 15

1.2.9 Security Analysis 15

1.2.10 System Architecture 15

1.2.10.1 Subsystems 15

1.2.10.2 Deployment architecture 16

1.2.10.3 Dependability architecture 16

1.2.10.4 Distribution architecture 16

1.2.11 Integration Test Plan 17

1.2.12 Integration Tests 17

1.2.13 Verification Plan 17

1.2.14 Verification Tests 17

1.2.15 Validation Plan 18

1.2.16 Trace Matrix 18

1.2.17 Integration Test Results 19

1.2.18 Verification Results 19

1.2.19 Validation Results 19

1.3 Lifecycles of the Systems Engineer 19

1.3.1 V-Model Lifecycle 20

1.3.2 Incremental 21

1.3.3 Hybrid 23

1.4 Model-Based Systems Engineering (MBSE) 23

1.4.1 The Modeling Advantage 25

1.4.1.1 Precision of engineering data 25

1.4.1.2 Data consistency across work products and engineering activities 25

1.4.1.3 A common source of engineering truth 26

1.4.1.4 Improved visualization and comprehension of engineering data 27

1.4.1.5 Ease of integration of disparate engineering data 27

1.4.1.6 Improved management and maintenance of engineering data 27

1.4.1.7 Early verification of the correctness of engineering data 28

1.4.2 High-Precision Modeling with UML and SysML 28

1.4.2.1 The fundamental truth of modeling: drawing≠modeling 28

1.4.3 Modeling Is Essential for Agile Systems Engineering 29

1.4.3.1 The fundamental truth of agile systems engineering: verifiable models are required for agile systems engineering 29

1.4.4 Adopting Modeling in Your Organization or Project 31

1.4.4.1 Antipatterns of adopting MBSE 31

1.4.4.2 Recommend approaches for adopting MBSE 31

1.4.5 The Rules (of Modeling) 36

1.5 Summary 39

References 39

Systems engineering is an interdisciplinary activity that focuses more on system properties than on specific technologies and has the overall goal of producing optimized systems to meet potentially complex needs. This focus includes specification of necessary system properties (requirements), large-scale system organizational principles (systems architecture), definition of flows and events that travel between the system and elements in its environment as well as between large-scale architectural elements comprising the system (interfaces)—and the selection of key approaches and technologies through optimization analysis (trade studies).

In short,

Systems engineering is an interdisciplinary approach to building complex and technologically diverse systems.

Systems engineering is involved throughout the system specification, development, and verification activities. It provides crucial systems-level oversight of the project. We will focus on the specification activities in this book, but systems engineering encompasses far more.

Systems engineering is distinct from discipline-specific engineering, known collectively as “downstream engineering.” These engineering disciplines include mechanical, electronic, chemical, optical, nuclear, and software engineering. Thus, while systems engineering may define requirements allocated to these specific engineering disciplines, they shouldn’t specify the design or technologies used within them, except, perhaps, at a high level.

1.1 Key Systems Engineering Activities

Figure 1.1 shows the primary aspects of systems engineering, connected in a “traditional” or “classical” flow.

Figure 1.1 Basic systems engineering activities.

There is, of course, much more to systems engineering than this, and we will cover many of them in this book. For now, this provides a useful set of high-level discussion points. For a more formal definition of systems engineering, readers are referred to the INCOSE Systems Engineering Handbook [1].

The following sections will discuss the purpose and intent of the activities but not how or when they are carried out (that will come in subsequent chapters). Since the focus of this book is to describe how the goals of systems engineering can be achieved in an agile way, how these task are performed will differ from this simplistic discussion. We’ll talk about agile methods in general in Chapter 2 and detail specific best practices for agile methods in subsequent chapters.

1.1.1 Identifying Customer Needs

Ultimately, the reason we create a system is to meet a coherent set of customer’s needs. This is normally captured as a set of stakeholder requirements or customer requirements. I prefer the former term because the set of stakeholders goes beyond the purchaser or even the primary user. We must satisfy the needs of a wide variety of stakeholders, such as

• Purchaser

• User¹

• Evaluator

• Marketer

• Seller

• Trainer

• Manufacturer

• Acquirer

• Installer

• Maintenance staff

• Support services

• Operations management

• Certification agencies

• Customer support

• Disposal services

The most common way to represent the stakeholder needs is in a textual stakeholder requirements specification² but models may be used alone or in combination with textual requirements. It is important to understand that stakeholder requirements must be precise statements about what the stakeholder needs.

1.1.2 Specifying System Requirements

Whereas st...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Dedication
• About the Author
• Preface
• Acknowledgments
• Chapter 1. What Is Model-Based Systems Engineering?
• Chapter 2. What Are Agile Methods and Why Should I Care?
• Chapter 3. SysML Introduction
• Chapter 4. Agile Stakeholder Requirements Engineering
• Chapter 5. Agile Systems Requirements Definition and Analysis
• Chapter 6. Agile Systems Architectural Analysis and Trade Studies
• Chapter 7. Agile Systems Architectural Design
• Chapter 8. The Handoff to Downstream Engineering
• Appendix A. T-Wrecks Stakeholder Requirements
• Appendix B. T-Wrecks System Requirements
• Index