Thinking outside the box

Let's consider this thinking inside and outside the box thing again... 'I'll tell you what I want it to do and you work out how it's going to meet my needs'. The reason we write requirements, after all, isn't because we like writing. It's because we want someone else to do something. Specs are a way we can try and conduct the work of multiple teams working in parallel. The intent being that when they all do their job well, we'll end up with a sum of parts that actually mean something. The same patterns apply to good MBSE with SysML.

The trouble, of course, is that systems engineers are engineers. They love the Chocolate of actually designing the system. Sometimes they can end up thinking inside the box, whereas perhaps they shouldn't. In some cases it's their role, but in other's it's not. Solid division of responsibility on the other hand allows us to get multiple teams working together in parallel. The simplest way by far to separate concerns between teams, whether internal or external, is for one team to work on what happens outside, while another team works out what happens internally, i.e the inside/outside the box division. This is very easy with diagrams in SysML such as Sequence Diagrams and Internal Block Diagrams, and arguably one of the key differences between how SysML techniques are applied in systems engineering vs how UML has been historically applied in software design.