Leanpub Header

Skip to main content
Go to Leanpub.com
MBSE4U

Pain-Free MBSE

A Rigorous Yet Simple Approach to SysML Modeling

Doug Rosenberg and Brian Moberley

Pain-Free MBSE is a practical guide to applying SysML without the unnecessary pain. Too often, MBSE gets a bad reputation for being slow, rigid, or overly complex. This book changes that. Using the Lunar Lander as a running example, it exposes high-pain modeling practices and introduces simpler, more effective alternatives. You'll learn how to apply the Value-to-Pain Ratio (VPR) to streamline your process, improve collaboration, and build models that work in the real world. Whether you’re a systems engineer, software developer, or decision-maker, Pain-Free MBSE helps you model with confidence — and without the headaches.

Minimum price

$75.00

$75.00

You pay

$75.00
$

...Or Buy With Credits!

You can get credits with a paid monthly or annual Reader Membership, or you can buy them here.
PDF
EPUB
About

About

About the Book

The Pain-Free Manifesto

By Doug Rosenberg and Brian Moberley

As veterans of the MBSE community, we’ve spent decades immersed in the world of SysML modeling, working on some of the most complex engineering challenges across industries. Along the way, we’ve seen a troubling trend: too many “high-pain” approaches that complicate the modeling process, frustrate practitioners, and hinder the adoption of Model-Based Systems Engineering.

We declare today that SysML modeling does not need to be painful.

We believe that

  1. Thoroughness and completeness can coexist with simplicity. A well-structured model does not require unnecessary layers of complexity.
  2. The purpose of MBSE is to solve problems, not create them. SysML should empower engineers to focus on design and analysis, not struggle with the tools and techniques.
  3. Pain is not a requirement for precision. Clear methodologies and pragmatic practices can achieve results without introducing unnecessary friction.
  4. Rigor in modeling does not need to be accompanied by rigor mortis. Precision and clarity can be achieved without stifling progress or creativity.

Our Commitment

We vow to promote low-pain approaches to MBSE by:

  • Identifying the specific practices that cause unnecessary pain and offering actionable alternatives.
  • Demonstrating how SysML can be applied effectively without sacrificing thoroughness or completeness.
  • Sharing practical, real-world examples like our lunar lander case study to show how MBSE can deliver value without the headaches.

Our Vision

We envision a world where MBSE is not viewed as a cumbersome obligation but as a powerful, approachable methodology that engineers embrace with confidence and enthusiasm. Together, we can move beyond “high-pain” practices and unlock the true potential of SysML modeling.

Share this book

Categories

Systems Engineering

Feedback

Email the Authors

Author

About the Authors

Doug Rosenberg

Doug Rosenberg is the founder and CEO of Parallel Agile Inc., with over three decades of experience in software and systems engineering. As a pioneer in object-oriented design and a leader in MBSE, Doug brings invaluable insights into the integration of AI and systems engineering. AI Assisted MBSE is Doug's 9th book on software and systems engineering.

Doug provides training on AI Assisted MBSE (AIM Process) through Parallel Agile in both online and on-site formats.

More details about AIM Training are available on the parallelagile website

Brian Moberley

Brian Moberley is a Senior Systems Engineer for Innovative Defense Technologies, LLC. His Systems Engineering experience spans DoD as well as commercial projects. Brian is the creator and host of the MBSE iNsights YouTube channel where he creates instructional videos to teach the Systems Engineering community the ins and outs of the practice. As a veteran of the U.S. Air Force and commercial pilot, Brian's diverse background and experience bring a unique perspective to the Systems Engineering community.

Contents

Table of Contents

About MBSE4U

About Us

Foreword by Rick Hefner

Preface

  1. Artificial Intelligence
  2. Download Lunar Lander Module Model
  3. Acknowledgment

10% of the Practices Cause 90% of the Pain

  1. Pain Point: Forgetting that “The Perfect is the Enemy of the Good”
  2. Pain Point: Forgetting that “Everything Should Be as Simple as Possible, but No Simpler”
  3. Pain Point: Dogmatic Modeling – “My Karma Ran Over Your Dogma”
  4. Pain Point: Believing SysML Equals Object-Oriented Design
  5. Pain Point: Not Avoiding the Department of Redundancy Department
  6. Summary
  7. Glossary

Ignoring Software: A Guarantee of Systems Engineering Pain

  1. Pain Point: Misalignment Between Systems and Software
  2. Pain Point: Inconsistent Vocabulary
  3. Pain Point: Not Doing Domain-Driven Logical Architecture
  4. Pain Point: The Software Team Ignores the SysML Model (including Requirements)
  5. Pain Point: Treating Software as an Afterthought Creates Brittle Architectures
  6. Pain Point: Failure to Leverage Software’s Flexibility
  7. Summary
  8. Glossary

Subsystem (O-O) Decomposition Is Less Painful Than Functional Decomposition

  1. Pain Point: Confusing “Functional Architectures” with Solution-Space Architectures
  2. Pain Point: No Clear Guidance on When to Stop Decomposing Functions
  3. Pain Point: Deep Function Trees Are Not Resilient to Changing Requirements
  4. Pain Point: Functional Decomposition Slows Everything Down
  5. Pain Point: Black Box Architecture is Painfully Difficult
  6. Pain Point: Free-Floating Functions are Architecturally Ambiguous
  7. Summary
  8. Glossary

Swiss Cheese Requirements: Patching the Holes

  1. Pain Point: Believing You’ve Found All the Requirements
  2. Pain Point: Over-Specifying How Instead of What
  3. Pain Point: Requirements with Undefined or Ambiguous Terms
  4. Pain Point: Poorly Written Requirements
  5. Pain Point: Not Baselining Requirements or Using Version Control
  6. Pain Point: Not Exploring Requirements on a Subsystem-by-Subsystem Basis
  7. Pain Point: Requirements That Fail to Map to System Structure
  8. Pain Point: Not Exploring Requirements for Interfaces Between Subsystems
  9. Pain Point: Not Exploring Requirements on a Use Case-by-Use Case Basis
  10. Pain Point: Not Exploring Requirements for Alternate and Exception Scenarios
  11. Pain Point: Not Exploring Software Requirements
  12. Pain Point: Not Exploring Embedded Software Requirements
  13. Pain Point: Not Exploring User Interface Software Requirements
  14. Pain Point: Not Specifying Performance Requirements Properly
  15. Summary
  16. Glossary

Ending Use Case Abuse

  1. Pain Point: Skipping Use Cases Entirely
  2. Pain Point: Using Use Cases to Represent System Functions
  3. Pain Point: Skipping Use Case Narratives
  4. Pain Point: Failing to Link Use Cases to Behavior Models
  5. Pain Point: Excessive Detail in Use Case Templates
  6. Pain Point: Ignoring Alternate and Exception Behavior in Use Cases
  7. Pain Point: Not Tracing Use Cases to Requirements
  8. Pain Point: Failing to Wireframe the User Interface
  9. Pain Point: Doing Functional Decomposition on Use Case Diagrams
  10. Pain Point: Not Naming Use Cases as Verb Phrases
  11. Pain Point: Not Writing Use Cases in Active Voice from the User Perspective
  12. Pain Point: Obsessing Over Includes and Extends
  13. Summary
  14. Glossary

Activity Diagrams for Logic and Requirements Discovery

  1. Pain Point: Skipping Requirements Discovery
  2. Pain Point: Turning Logic Flow Diagrams into Data Flow Diagrams
  3. Pain Point: Using Object Flows on Activity Diagrams
  4. Pain Point: Allocating Behavior Too Early
  5. Pain Point: Doing Behavior Allocation and Dataflow Analysis at the Same Time
  6. Pain Point: Splitting Hairs Between Too Many Types of Actions
  7. Pain Point: Not Simulating the Activity Diagram
  8. Pain Point: Failing to Model Asynchronous Behavior
  9. Summary
  10. Glossary

Sequence Diagrams for Behavior Allocation

  1. Pain Point: Skipping Sequence Diagrams Entirely
  2. Pain Point: Moving to Sequence Diagrams Too Soon
  3. Pain Point: Not Scoping the Sequence Diagram to a Use Case
  4. Pain Point: Not Allocating Operations and Signal Receptions to Blocks
  5. Pain Point: Not Keeping the Focus on Allocating Behavior
  6. Pain Point: Overusing Fragments to Model Logic Instead of Allocating Behavior
  7. Pain Point: Not Understanding Object-Oriented Design
  8. Pain Point: Not Tracing Messages to Requirements
  9. Pain Point: Getting Confused by Activations
  10. Pain Point: Confusing Self-Messages with Recursive Operations
  11. Pain Point: Lifeline Titles from the Department of Redundancy Department
  12. Summary
  13. Glossary

Pain-Free State Modeling

  1. Pain Point: Not Understanding What State Machines Are For
  2. Pain Point: Not Understanding How Substates Work (and When to Use Them)
  3. Pain Point: Misunderstanding Entry, Exit, and Do Behaviors
  4. Pain Point: Misunderstanding Internal Transitions
  5. Pain Point: Not Understanding History Pseudostates
  6. Pain Point: Failing to Connect States and Transitions to Requirements
  7. Pain Point: Misunderstanding Transitions
  8. Pain Point: Not Understanding Available Event Types
  9. Pain Point: Not Understanding Transition Effects and Their Execution Flow
  10. Pain Point: Not Understanding Parallel Behavior in Orthogonal States
  11. Pain Point: Trying to Generate State Machine Code Before Simulating
  12. Summary
  13. Glossary

IBDs and Interface Definition

  1. Pain Point: Not Understanding What IBDs Are For
  2. Pain Point: Not Understanding What You Have to Do Before You Start an IBD
  3. Pain Point: Misunderstanding the Relationship Between Blocks and Part Properties
  4. Pain Point: Not Understanding Ports (including Port Types and Conjugation)
  5. Pain Point: Not Knowing How to Start an IBD
  6. Pain Point: Not Understanding Interface Blocks, Signals, and Flow Properties
  7. Pain Point: Flow Properties Are Powerful—But Heavy
  8. Pain Point: Trying to Show Too Much at Once
  9. Summary: Clarity Is King
  10. Glossary

Pain-Free Parametrics Part 1: Fundamentals

  1. Pain Point: Math and Physics Are Hard
  2. Pain Point: Terminology is Confusing
  3. Pain Point: Constraint Blocks Appear on Both BDDs and Parametric Diagrams
  4. Pain Point: Confusing Pins, Constraint Parameters, and Constraint Expressions
  5. Pain Point: Not Understanding the Simulation Context
  6. Pain Point: Not Understanding the Cameo Simulation Console
  7. Pain Point: Not Knowing how to Send Signals to Trigger Events
  8. Pain Point: I run the simulation and nothing really seems to happen.
  9. Pain Point: Not Understanding Opaque Behaviors on Activity Diagrams
  10. Pain Point: Not Knowing how to use Python in a Simulation
  11. Pain Point: Not Understanding Value Types, Quantity Kind, Units, and Symbols
  12. Pain Point: Unit Mismatches (not understanding the ISO 80000 Library)
  13. Pain Point: Not Knowing how to Evaluate Performance Requirements
  14. Summary
  15. Glossary

Pain-Free Parametrics Part 2: Advanced Parametrics

  1. Pain Point: Not Understanding How to Use Time Series Charts
  2. Pain Point: Not Understanding How to Use User Interface Modeling Diagrams
  3. Pain Point: Not Using Simulation Configuration Diagrams
  4. Pain Point: Not Understanding How to Use Instance Tables
  5. Pain Point: Not Understanding How to Use Instances to Create Configurations (for Trade Studies)
  6. Pain Point: Not Realizing That Image Switchers Even Exist
  7. Pain Point: Not Understanding How to Run Monte Carlo Simulations
  8. Pain Point: Not Using Sequence Diagrams to Specify Test Cases
  9. Pain Point: Not Understanding Rollup Patterns
  10. Pain Point: Not Understanding How to Interface to Simulink and Matlab
  11. Pain Point: Misunderstanding Connectors: Binding vs Delegation
  12. Pain Point: The Trouble with Past-Tense Signal Names
  13. Summary
  14. Glossary

Pain-Free Parametrics Part 3: Landing on the Moon

  1. Time-Based Simulation Loop
  2. Summary

Appendix A – Auto Lander

  1. A.1 Introduction to PI Control Loops
  2. A.2 Auto Lander Overview
  3. A.3 Constraint Functions
  4. A.4 PI Control Loop for Auto Land
  5. A.5 Integrated Behavior
  6. A.6 When to Perform Calculations in Activities vs. Parametrics
  7. A.7 Summary

Appendix B - Lunar Lander V2 Model

  1. Lunar Lander V2 Model

Bibliography

Index

About the Publisher

About the Publisher

This book is published on Leanpub by MBSE4U

Lean Publishing for MBSE

MBSE4U is a lean publishing house specializing in MBSE books, providing up-to-date content that reflects the dynamic changes in the MBSE community and market.

MBSE4U aims to provide knowledge, practice, and more about MBSE. It offers publications about MBSE methodologies and methods such as SYSMOD, VAMOS, FAS, and MBSE craftsmanship.

The Leanpub 60 Day 100% Happiness Guarantee

Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.

You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!

So, there's no reason not to click the Add to Cart button, is there?

See full terms...

Earn $8 on a $10 Purchase, and $16 on a $20 Purchase

We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.

(Yes, some authors have already earned much more than that on Leanpub.)

In fact, authors have earned over $14 million writing, publishing and selling on Leanpub.

Learn more about writing on Leanpub

Free Updates. DRM Free.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Learn more about Leanpub's ebook formats and where to read them

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!

Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.

Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.

Learn more about writing on Leanpub