Systems Engineering is from Venus, MBSE is from Mars?

By Alex Stevenson, Principal Consultant, Objektum Solutions Limited

Before I receive any irate diatribes (assuming anyone reads this) on the title of this post I urge you to look back at the aforementioned title and note the question mark. My title was selected not because it represents an opinion that I hold but rather one that I am often faced with. While many engineers that I have encountered have embraced and adopted MBSE practises there are still those who would rather stick with the document centric SE approach. While I will always advocate the use of MBSE I also recognise that it is not a cure for all that ails your projects.

The INCOSE Systems Engineering Handbook © INCOSE (www.incose.org) defines systems engineering as follows:

“Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing and disposal. Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.”

In addition the handbook quotes Howard Eisener’s Essentials of Project and Systems Engineering Management which refers to SE as a process.

In A Practical Guide to SysML: The Systems Modeling Language the authors (Sanford Friedenthal, Alan Moore and Rick Steiner) define MBSE as follows:

  

“Model-based systems engineering is the formalized application of modelling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.

  

The key difference for me is that systems engineering is a process while MBSE is a method. 

As the lead systems engineering trainer for Objektum Solutions I spend many hours discussing these concepts and it is my style is to educate through questions. I do this for two primary reasons; firstly it allows me to establish what the level of understanding amongst my delegates is but, more importantly, it affords them the opportunity to guide them through their own discovery rather than simply dictate what I believe they should thin. Although this medium does not afford me the same opportunity I urge you to ask yourself; what is the difference between a process and a method. For those who do not have time to have this discussion with themselves or are concerned about the mental health implications of talking to yourself; read on immediately and I shall share my thoughts.

  

As I’ve said, Systems Engineering is, for me, a process but what does that actually mean? The dictionary defines a process as a series of actions or steps taken in order to achieve a particular end but in an engineering context that is too vague. I would elaborate that definition by adding that a process defines a generic set of actions or activities must be undertaken to evolve the development of a system. These steps identify key development stages together with required inputs and deliverables while remaining independent of implementation. In other words a process describes what you must do but does not mandate how you should achieve it. For example; a process might tell you to analyse stakeholder requirements and produce a systems specification without detailing the artefacts to be produced or the method of analysis. A good systems engineering process should be applicable to all projects and be able to be realised by a number of different approaches (e.g. document centric or MBSE).

A method, on the other hand, represents the realisation of a process and details the techniques to be used and artefacts to be produced during the development effort. While a process is often mandated, within an organisation, projects should be free to select the most suitable method for the task at hand. The only constraint on the selected method is that it fully satisfies the process. Like processes; methodologies can be introduced at an organisation level however, an organisation’s method should always be a recommendation that individual projects can tailor to suit their specific needs. That being said, I do not believe that projects should be free to do what suits them in the moment. A projects method should always be fully documented prior to its implementation and that documentation must be maintained as the method evolves and grows.

Any MBSE method that I adopt will, until something better emerges, be based around the OMG’s Systems Modeling Language. Rather than detail the specifics of how and why I choose to use SysML I shall, over the coming weeks, discuss the key features of the language as well providing guidance on recommended usage. I shall not, however, be detailing my full MBSE methodology. It would, after all, be economic suicide if I gave away all of my secrets.