7 tips for pragmatic systems engineering
Yesterday, on June 17, 2020, I gave a talk entitled "Pragmatic Systems Engineering through Modeling" as part of the GfSE webinar series. I captured the pragmatism in the form of 7 tips, which are summarized here for those who missed the webinar.
The Video recording and further links I have included on a separate page.
1. select the best of all approaches
Over the past decades, we have found various approaches to make systems engineering more efficient. It started in the 90s with element-based requirements management (instead of using documents as before). At the beginning of the 2000s, agility was introduced as a new approach and then MBSE at the end of the 2000s.
These three approaches are not mutually exclusive, on the contrary. It is therefore right and important to use the best ideas from the three approaches and to combine them.
2. direction ("compass") + small steps
The big goal of MBSE is a centralized model that represents all aspects of development and is used by all stakeholders. However, few teams have the maturity to get there in a single step, no matter where they currently are. It is therefore important to have a clear goal in mind, the compass. This goal must be aligned with the company's business goals, otherwise it will be difficult to get the resources needed. The SYSMOD Intensitymodel shows nicely how MBSE can be expanded step by step.
3. not an end in itself / added value for all stakeholders
Especially when a few employees show a lot of enthusiasm, modeling can unfortunately quickly backfire. Such people easily overestimate the skills and interest of their colleagues. It is therefore important that all stakeholders recognize the benefits of modeling for their daily work. If the added value for each individual is clear, then the team will also be motivated.
4. make full use of existing ER models
An entity-relationship model is a simple data structure with element types and links between them. A typical requirements management tool uses an ER model, which enables, for example, the linking of user needs and system requirements. This is nothing new and has been used in development for 30 years. Furthermore, every database works with entities (tables) and relations, which means that every database-based system uses an ER model.
In my experience, such systems, especially requirements management tools, are often not fully utilized. Even the most obvious things, such as maintaining traceability, are sometimes only done as an afterthought and for compliance. I have summarized what you can do with a traceability here. Whether systematic reuse or a dashboard for management, ER models have an extremely wide range of possible applications that are just waiting to be used.
5. use only the part of a notation that is needed
Especially when a team starts to use a formal notation such as SysML there is a temptation to try everything. But especially at the beginning it is helpful to use only a small part. Which part this is should depend on the planned use of the modeling. A goal should therefore be defined first, for example to reduce redundancies in the specification. Based on this, the part of the language that supports this goal can be selected.
I have explained what this can look like in concrete terms in this Case study where an IT system was documented with UML.
6. train stakeholders, distinguish reading & writing
It should be clear that new approaches also require training. However, it is sometimes forgotten that not all stakeholders need the same training. In particular, it is much more time-consuming to teach someone how to model than how to read models. In practice, however, most stakeholders only need to understand the models, not create them themselves. A short, concise training course is sufficient for them. However, this should be carried out in any case, as it can drastically increase the acceptance of a new approach.
7. use and adapt an existing procedure/method
And finally: Modeling, and MBSE in particular, requires a systematic approach and maturity in terms of methodology within the team. If there is a need for an appropriate approach when introducing MBSE, we should definitely resist the temptation to develop something ourselves. There are a large number of ready-made process models and these can be easily adapted. A lightweight one is ICONIXat the other end of the spectrum, the FAS method.
Conclusion
The most important point is: In the company, we are practitioners, not academics. Pragmatism is therefore the order of the day. Whatever we do, we have to understand why. An end in itself is one of the biggest dangers here. If we take this to heart, we can achieve a lot with little effort.
Photo by Aron Visuals on Unsplash
