Book Image

Agile Model-Based Systems Engineering Cookbook Second Edition - Second Edition

By : Dr. Bruce Powel Douglass
Book Image

Agile Model-Based Systems Engineering Cookbook Second Edition - Second Edition

By: Dr. Bruce Powel Douglass

Overview of this book

Agile MBSE can help organizations manage change while ensuring system correctness and meeting customers’ needs. But deployment challenges have changed since our first edition. The Agile Model-Based Systems Engineering Cookbook’s second edition focuses on workflows – or recipes – that will help MBSE practitioners and team leaders address practical situations that are part of deploying MBSE as part of an agile development process across the enterprise. In this 2nd edition, the Cameo MagicDraw Systems Modeler tool – the most popular tool for MBSE – is used in examples (models are downloadable by readers). Written by a world-renowned expert in MBSE, this book will take you through systems engineering workflows in the Cameo Systems Modeler SysML modeling tool and show you how they can be used with an agile and model-based approach. You’ll start with the key concepts of agile methods for systems engineering. Next, each recipe will take you through initiating a project, outlining stakeholder needs, defining and analyzing system requirements, specifying system architecture, performing model-based engineering trade studies, all the way to handling systems specifications off to downstream engineering. By the end of this MBSE book, you’ll learn how to implement systems engineering workflows and create systems engineering models.
Table of Contents (9 chapters)
6
Other Books You May Enjoy
7
Index
Appendix A: The Pegasus Bike Trainer

Why aren’t textual requirements enough?

There are many reasons why textual requirements by themselves fail to result in usable, high-quality systems.

First, it is difficult to ensure all the functionality is present:

  • All normal (sunny day) functionality?
  • All edge-cases?
  • All variations of inputs, sequences, and timings?
  • All exception, error, and fault cases?
  • Qualities of service such as performance, range, precision, timing, safety, security, and reliability?
  • All stakeholders appropriately represented?

Getting that much detail is a daunting task indeed. But even beyond that, there is an “air gap” between realizing a possibly huge set of “shall” statements and actually meeting the stakeholder needs. The stakeholder believes that if the system performs a specific function, then in practice, their needs will be met. Experience has shown that this is not always true. Customers often ask for features...