Swiss Systems Engineering Day 2015

On the way to Zurich, the closed cloud cover opened and a blue sky with a few clouds welcomed me to Switzerland when I was approaching Lake Constance for attending the Swiss Systems Engineering Day (SWISSED) 2015 the next day. The Swiss Society of Systems Engineering SSSE and INCOSE Swiss Chapter started a year ago with a first one-day conference, and demonstrated impressive growth for the second event. The attendance increased by approximately fifty percent. An impressive long list of sponsors supported the event. Thus, the weather resembled the prospects of the conference. As a multi-lingual country, the Swiss INCOSE Chapter had decided not to favour any of the four local languages. They have chosen again English as the conference language. For this reason, they attracted not only systems engineers living in Switzerland, but also presenters and audience from other European countries.

The conference programme featured two keynotes, four separate paper tracks and an exhibition of the sponsors. The first keynote was presented by Tim Weilkiens, the CEO of oose and a renowned expert in the field of Model-Based Systems Engineering. His talk was titled Requirement Engineering with MBSE. He followed a currently not uncommon theme to resolve the antagonism between requirement engineering and model-based systems engineering. For years, the promoters of MBSE had claimed that MBSE will lead to a completely different way of systems engineering. A few years ago, it was worth to travel to the US for attending an INCOSE International Workshop just to hear from Sandy Friedenthal, one of the father figures of SysML, that MBSE just helps us to do things better in systems engineering that we have done and have to do in systems engineering anyhow. From this first insight, it still seems to take a long way to bridge the gap between requirement engineering and model-based systems engineering by appropriate process and method integration.

Tim Weilkiens approached the problem from the MBSE point of view. He stated that no real improvement has been seen in requirement engineering over the last twenty years. After reviewing the new version of ISO 15288, I have to say that he is mainly right with this judgement. When ISO 29148 on requirements engineering was published in 2011, I had some hope that requirement engineering would overcome some of its deficits soon. But obviously, this standard had little impact on the further systems engineering standardisation at ISO.

Nevertheless, requirements are important in systems engineering. Tim Weilkiens referred to the so called CHAOS reports of the Standish Group that blame a lack of user input, incomplete and unclear requirements, and changing requirements as most frequent risks encountered by failing IT projects. For me, it is not surprising that standardising the wording of requirements and improving requirement engineering tools alone do not cure the root problem: If you want to solve a problem, you need to understand the problem first. And, before being able to understand a problem you need to find it. Unfortunately, you may become a certified requirement engineer without having any particular application domain knowledge. At least, this was my conclusion when I was browsing the IREB curriculum.

A lack of user input as well as incomplete and unclear requirements are mainly a communication issue with deep roots in linguistics. Every stakeholder domain develops over time a specific terminology and corresponding semantics that is not fully comprehensible for people with little knowledge and experience regarding the particular application domain. Furthermore, expert knowledge is stored in the cerebral cortex of the human brain in a network topology. In contrast, any cause-effect based reasoning applies a sequential narrative pattern. An expert may generate a lot of narratives out of her or his semantic memory. These are issues that are not considered in the scope of requirement engineering at all. The fact that no clear distinction between a stakeholder need and a stakeholder requirement is defined in requirement engineering – and, of course, systems engineering as well – illustrates the ignorance of the psychological communication context.

The issue of changing requirements is not so surprising at all when working on innovative technical solutions. Neither any stakeholder nor any contributing development engineer will be able to imagine upfront all issues that may arise when setting all design criteria and solution alternatives into context to each other. A view that systems engineering would at best be a deductive exercise managed in a command and control fashion is an idealisation that has little to do with the real course of life. You know that you can do it after you have done. The whole adventure of engineering innovative systems is a story of continuous learning. Thus, systems engineering has to manage the learning instead of focussing just on the outcome. The second keynote from Larry Leifer provides evidence that systems engineering may become fun, if reality is accepted as the normal case. Kevin Forsberg likes to say: It is as easy to derive a design from requirements as to walk over water, if both – the requirements and the water – are frozen. But the majority of people do not live in regions with perpetual ice, and the ice shields at the north and south poles of the earth show a trend of melting due to climate change.

Will be continued

Will be continued