The Hamburg Systems Engineering GetTogether

On 22.9. the SE GetTogether organized by OOSE took place at their premises. These evening events are a great opportunity for Systems Engineers in the Hamburg area to exchange ideas. The free SE Get Togethers are organized About Xing announced.

This get-together was well attended with around 25 participants and was a Word Café organized. For those who are not familiar with it, a World Café is a type of workshop in which various topics are discussed at different tables. The topics come from the participants. In this case, there were enough participants for four groups, and all the proposed topics revolved around modeling in some way. I myself moderated a table on the topic of "Modeling requirements". I am pleased that the topic of modeling is gaining momentum again. There was also a lot of interest in the Modeling Craftmanship Barcamp in Hanover confirms this.

The oose Campus

The premises at oose are ideal for such get-togethers: The large, inviting atrium could easily accommodate all participants. There were plenty of moderation materials available and the tables were already supplied with large sheets of paper. The oose campus is also the venue for the Hamburg SE Barcamp in December.

Modeling requirements

I have often said that, in my opinion, modeling brings the greatest added value to requirements, which has also been empirically proven by Daniel M. Berry. In this respect, everything at my table revolved around requirements modeling: what exactly is it, what needs to be considered, how do you achieve the greatest added value? We came up with a total of three results. Although these are not surprising, they are certainly helpful for newcomers to the topic:

There are two possible uses of requirements modeling: (1) The model supplements the requirements, or (2) The model replaces the requirements. In the first case, the model can be used to verify and improve the requirements. In particular, new requirements can also be derived from the model. In the second case, traditional requirements are completely eliminated, as the model can fulfill the role of the requirements in full.

It was not easy to answer the question of what requirements modeling actually means. In particular, the same facts can be expressed with the same expression in different languages. a simple example (simplified): "When switches A and B are closed, lamp L lights up". This is already a model in natural language. It could be written using the symbols of logic as follows: A ∧ B ⇒ L. (Of course, A, B and L must also be modeled.)

This is important in practice, as it is easy to say: "We model in SysML". Although the language is there, nothing is said about the way it is expressed. And this in turn has many aspects that are too numerous to list here. Keywords here are architecture, design pattern, selection of language elements, etc.

Two statements can also be found in this insight. Firstly, modeling must be used correctly. Even if this seems obvious, I am convinced that this is one of the main reasons for the acceptance problems of modeling. Too many people have turned away from modeling in frustration because the hoped-for benefits did not materialize. But modeling is difficult. This is also one of the reasons for organizing the Modeling Craftsmanship Camp.

The second point is that there is great potential for modeling if it is used correctly. The points identified in the session were:

• Capture information graphically/visually
• Eliminate redundancies
• Communicating, especially at a high flight level
• Understand the problem precisely
• Systematic "breakdown" of problems
• Traceability, both "horizontal" and "vertical"
• Different views of the model
• Systematic verification

The topics addressed here could easily provide material for a few dozen articles.

Thanks to oose

One of the participants, Piotr Malecki, put it in a nutshell: "The level of community support that oose provides here is by no means a matter of course. I would like to take this opportunity to thank oose once again for their support. I must emphasize this even more in this case, as oose is also providing the premises for the GfSE Barcamp in December.

GetTogether or Barcamp?

I couldn't avoid the Modeling Craftsmanship Camp and the Systems Engineering Barcamp North to mention. One of the reasons for this is that barcamps and get-togethers have a lot in common: Both formats take the influence away from the organizers and give control to the participants. This enables a level of engagement with the participants that is rarely realized in traditional conferences. In addition, GetTogethers and BarCamps are usually very inexpensive (or free). They also often take place outside of working hours. As a result, there are real enthusiasts who also like to deal with the topic in their free time. The main difference between the formats is actually only the length: while the GetTogether lasts an evening, a Barcamp usually lasts a day.