As all systems engineers know, successful systems engineering requires modeling every aspect of a system and using every capability of our MBSE tools. Anything short of that is a failure, right? Wrong!
Model-based systems engineering (MBSE) takes traditional, very often Microsoft Office-documented, systems engineering to the next level. But there isn’t a single next level. There are several. In my mind, MBSE addresses requirements analysis, behavior analysis, architectural analysis, traceability, consistency, decision tracking, and risk establishment and tracking—so there are lots of potential tasks systems engineers can perform to make our designs better. But just because they exist doesn’t mean one has to do them all.
For example, in organizations that implement initial designs using Microsoft Office, conducting a true requirements analysis represents a huge leap forward. I know organizations that parse specifications into Excel spreadsheets, have an administrator conduct a high level spot check to make sure the information is reasonable, and then said administrator turns the spreadsheet over to the actual systems engineering team. The requirements are massaged in the spreadsheet, never to return to the dedicated systems engineering tool. I contend that systems engineers who establish requirements hierarchies and decompositions advance systems engineering in their organizations if that effort is part of a journey towards systems engineering and not simply a destination. There is certainly an opportunity to go further and broaden the benefit of systems engineering, but taking the step is a beginning.
So why do organizations shortchange systems engineering and MBSE? Because people feel better paying for hard, tangible stuff. Because their customers want to know why they are paying for paper. More than a few engineering organizations—and good engineering organizations at that—drive straight to detailed design, setting loose the mechanical, electrical, and software engineers to “go build something.” Some program leaders rationalize this approach by claiming that it will “all come together in integration.”
However, that’s not necessarily the case. I have personal experience observing that paradigm from the outside and seeing executive and senior engineering managers lose their jobs because of enormous project cost overruns. In one instance, the systems parts worked independently as designed, but during final assembly, the device overstressed the power supply, resulting in a redesign. In my opinion, a more thorough systems engineering approach would have budgeted the power needs across the subsystems and managed them more aggressively. Instead, the power system had to be reengineered, delaying delivery and overrunning budgets.
I do have a bias. I currently work for a systems engineering company, and I have been using MBSE tools for 30 years, so I’ve seen how MBSE applied correctly finds otherwise overlooked or erroneous design details early in the design cycle. Systems engineers face a huge challenge in proving the reasons for success. It’s easy to see systems blow up, crash or otherwise get destroyed, and conclude that some aspect of engineering was at fault. What’s not so easily seen is why a system works, what in the design process and journey made the system successful. 
In the successful scenario, I’m sure there were untold aha moments by engineers reflecting early insight, collective wisdom, and early problem detection, but all of these pass with little notice or fanfare.
Following the all or nothing thought-path, engineers are tempted to instantiate all the nuances and practices of their chosen approach to MBSE on day one. But systems engineers can progressively expand the application of MBSE as an intentional journey rather than tackling everything at once. For example, start with requirements analysis. Parse the originating requirements specification, but don’t stop there. Break each requirement into a single, clearly stated and testable statement maintaining a relationship to the original specification.
A requirement that reads, “Do this, that, and the other thing,” is actually three requirements, not one. One of the benefits of breaking requirements statements into multiple atomic statements is that it enables testing of the requirements at multiple phases. We don’t want to artificially wait to test a requirement during a later phase just because one aspect of it must be tested later in the design or manufacturing process.
In addition, we should relate requirements and establish hierarchies. The hierarchy will help focus (meaning limit) the impact analysis associated with an engineering change proposal. The hierarchy will also tell us what can be excluded, resulting in cost savings, because we won’t expend resources to eliminate clearly un-impacted areas.
When we’re ready, we can take another step toward the complete adoption of good systems engineering practices (as tailored and appropriate for the situation at hand). We can expand MBSE by performing a functional/behavioral analysis based on customer-specified and derived requirements. Further expansions might include conducting an architectural analysis considering multiple strategies or evaluating how a system is partitioned or how and by whom it is to be built or maintained or how it is to be tested. As we approach the “ALL” state, we will reap the benefits of finding complex interactions that we can’t discover viewing Microsoft Office artifacts, nor find with disparate engineering tools. MBSE drives other model-based engineering environments so that mechanical, electrical, and software engineers design and build the system their customers need and want.
Many times, the successful journey is one of many smaller deliberate steps, not one great leap.
Good luck, and happy engineering!
