MBSE can get you a dead Earth over a sad moon landscape

Published 22 days ago • 2 min read

How to sell the benefits of MBSE to your Boss (or business)?

My mentee raised an interesting question and I thought the answer was obvious. Hint: it wasn't ..

Any questions? Drop me an email. And share with others.

Remember: you can always schedule a free 30-minute exploration call to chat about any career, engineering & leadership development support you need! (for yourself or your org).

This is a brief glimpse.

But first I need to show you why.

I should liven up my living room. My guest would think I'm a suspicious alien.

So I went on a painting course to learn to ... paint. And slat some personalised and authentic visuals on my walls to make it cosy.

To learn technique. And I learned to use pencil and brush. I got very good to draw different kinds of lines and shapes.

Can I paint now? NO!

It was a failure.
I'll tell you why ...

I was so proud of myself after learning to draw all these different kinds of elements. I thought now is the time to put them together and get my first great painting.

It was supposed to be a sunset over the sea.

After a 5 hours session of work: Disaster !

SHOCKER:

I got a sad moon landscape with a dead Earth looming over the horizon ...

What happened? I mastered technique, no?

It's not enough! I didn't master Outcome.

Would be better if I knew what I wanted to get first and sketch it at a high level instead of detailing one corner.

Do a low resolution overview sketch that I can iterate. And validate it's looks like the end result I wanted ...

Frequent checks at a high level would help validating you get what you want. While you put in more and more detail!

The same happens when eliciting and capturing your Technical Requirements.

Classical approach:

to write your requirements then draw the functional architecture. The functions (and architecture) are implied.

Don't believe me? I could write a long article on that ...

Doing with a MBSE approach turns it on its head:

you model the Functional Architecture first then derive the technical requirements out of it.

With the benefits of:

no (or at least much less) iteration of requirements because the Functional Architecture (and flows, and behavior) is already validated. Your model is iterated visually (and quick and cheap).
Right requirements first time captured clearly and uniformly (especially when paired with something like EARS or auto-generation).
No contradicting req's or gaps.
So Verified AND Validated requirements ready to send off for those who needs them in textual format.
Avoid finding that you didn't build what your Customer wanted AFTER you built it. And so avoid the cost of rework. You validate the model together with them and the requirements are just the translation into a textual format.
Opens up a massive opportunity for requirement generation automation. Especially now in the age of AI!

Of course I simplify a lot here. And there is much more to this. But doing just this will get you a loooong way. And I'm afraid most are not even aware, much less doing something about it.

Some call this part of "Left-shifting".

Others directly jump into designing a solution. Then pay the huge cost of redesign and implementation change when they find out in testing that they built the WRONG thing.

Make sure the outcome is that what you and your stakeholders wanted. Not just whatever emerges.

P.S.: I'm offering free advice but well ... I won't refuse a coffee ⏬ if you appreciate it :)

P.P.S.: I'm also offering full 1:1 coaching but don't worry if that's not your thing. Just reply to this email and ask what's bothering you. Like so many others do. I'm also curious and happy to help.

P.P.P.S: Still reading?? Than you may appreciate this post that reminded me that not everything is obvious.