Combining system models with SpecIF

Lately I have often heard about the GfSE reported. And in today's interview, I also talk to someone who is involved in the GfSE: Dr. Oskar von Dungern helped to launch the SpecIF initiative. He also talks about the recent Interview with Dr. Siegmund Priglinger presented modeling group.

Dr.-Ing. Oskar von Dungern is Managing Consultant at adesso AG in Berlin. He advises manufacturers on methodological and organizational issues relating to product design and development. As an engineer and manager, he has gained a wide range of experience in the realization of mechatronic products and software. His successes include the sustainable improvement of product and process quality, as well as the consolidation of development organizations following company mergers. "Innovation with software" and "software engineering" are among his main professional interests.

SpecIF emerged from the GfSE's "PLM4MBSE" working group. In your words, what is SpecIF and who needs SpecIF?

SpecIF is a convention for the semantics of system models. In my experience, there are many different technical formats and solutions for transporting models and using them in subsequent development steps, but in practice it only works with the greatest of difficulty and therefore rarely. There are standardized notations such as BPMN and SysML, but there is no semantics at application level that actually allows us to communicate using models, as we know it from the mature engineering disciplines of mechanical and electrical engineering.

SpecIF helps everyone who wants to transport and use system models independently of technology

SpecIF fills this vacuum in the overarching system design by developing a vocabulary and a logical information model. It is about which types of model elements are used, what they are called and which logical relationships are established between them. All from a practical point of view, so that in the end useful statements can be made about the system that improve understanding and collaboration. SpecIF therefore helps anyone who wants to transport and use system models in a technology-independent way, for example when coordinating product manufacturers and their suppliers. Today, it is no longer enough to agree on long lists of requirements; it is about a comprehensive concept with system function, structure and behavior, as well as interactions between the disciplines.

There are already similar approaches in this direction. Specifically, I have to think of OSLC or EMF. There is also a lot in the proprietary area. Can a new approach compete with this?

SpecIF does not compete with technical formats and solutions, but complements them with a professional, content-related dimension.

OSLC has started to define a vocabulary for requirements and relies on Dublin Core. Of course, SpecIF takes up these suggestions as well as others. However, as things stand today, OSLC stops one step too early by defining the names of the requirement attributes, but not the names of the objects themselves: Nowhere have we found an identifier oslc_rm:requirement or similar.

SpecIF takes a comprehensive view of system models by placing requirements in context with process steps, system components and other artifacts. Or by creating a connection between processes, system structure and behavior. A comprehensive vocabulary and a statement logic are developed. SpecIF therefore proves its value when someone comes along and names and structures the contents of their system model according to SpecIF in an OSLC tool network. The same applies to EMF/Ecore from the Eclipse world.

OSLC stops one step too early. SpecIF is used to develop an overarching vocabulary and propositional logic.

Can you give a concrete example of how SpecIF creates added value? You also said that SpecIF is already being used in industrial projects: can you quantify the added value?

Over the past 12 years, we (and I would like to expressly thank some of our long-standing business partners) have continuously developed the methodology on which SpecIF is based. In 2012, we were able to carry out a pioneering project for a manufacturer of regional trains, in which an integrated model of the landscape of business processes, IT systems and requirements, each with actual and target status, was created. This made it immediately clear what impact this or that process change would have on the systems, or which processes would be affected if island systems and media disruptions were to be eliminated. Later, the method was also used in the design of mechatronic systems. A manufacturer of home automation devices was faced with the task of developing an architecture for a new generation of networked devices - 120 in total. With the help of integrated system modeling, this was achieved in just 5 months, even though the organization was still reeling from the horror of a failed project on this very topic. Both projects used the "Fundamental Modeling Concepts" (FMC) that emerged from the Hasso Plattner Institute in Potsdam.

Over the past 12 years, we have continuously developed the methodology on which SpecIF is based.

Nevertheless, I find it difficult to quantify the added value. It's about quality through better insight into the interrelationships, it's about discovering gaps and contradictions in the concept at an early stage, it's about overcoming technical constraints from the tool landscape, sometimes it's about failing or not failing. Nevertheless, anyone who enjoys interdisciplinary thinking and working and has experienced the benefits will not want to give it up. At the same time, there is resistance from many who prefer to stick to familiar ways of working. Conservative industries that are used to success are finding it particularly difficult.

What are the next steps regarding SpecIF? And how can interested readers find out more?

Following the successes with FMC, we want to show in the coming months that SpecIF also brings added value, especially when using common notations such as UML/SysML and BPMN. Today, the exchange of models between different UML/SysML tools is rarely successful, even if an international standard such as XMI is used. SpecIF aims to change this. We are therefore looking for further practical use cases in order to advance vocabulary and structure at application level and demonstrate their suitability for everyday use. Despite all the practical orientation, we want to ensure that SpecIF is methodologically well-founded so that the mapping to existing and future "technical carriers" is actually successful. This is why we want to make a concrete contribution to the GfSE working group "Formalizing modelling", which was initiated and is supported by Siegmund Priglinger. For practical reasons, we currently use the Requirement Interchange Format (ReqIF) as a technical carrier in order to be able to use the corresponding interfaces of various systems. There is also an implementation with JSON, but this is rather experimental due to the lack of available interfaces. As discussed, OSLC or later "linked-data" should also be usable.

We want to show that SpecIF also brings added value, especially when used with notations such as SysML.

The claim is very high and so I can understand if some are rather skeptical: On first contact, SpecIF sounds like a promise of salvation, of which there are already too many. But in my experience, it helps if you first ignore the artificial limitations of real systems and concentrate on the task to be solved: What do I want my system model to express, which notations do I want to use and which abstraction will help me in the collaboration of the participants? This is definitely possible.

The current status of the work is presented on specif.de published. We look forward to critical discussion and contributions, especially use cases, which help us to smooth and ultimately polish the still edgy stone.