ogies, therefore, can be expected to be of common interest to a very large community of systems developers, encompassing both 1.1 Why Another Modelling Language? industry and the academic world-and indeed they are. That does, however, not mean that this community has managed to agree on a minimum set of common lan- guages and modelling principles for systems engineering, although much work has been done to that regard, primarily by the defence industry and by organizations such as the International Council on Systems Engineering (INCOSE). In 1998 I attended a seminar where an expert in the field of systems engineering stated that: There is still no commonly accepted definition of "systems engineering", though there are 75 academic programs to that regard in the USA alone. There are over 25 textbooks on systems engineering, most of them, however, dealing with process aspects, not with modelling. There are over 350 computer-based tools and languages, classified as tools for systems engineering applications, which, unfortunately, cannot communicate with each other. If we consider software engineering, the picture looks different. The major opposing modelling methods in the early 1980s were methods based on functional decomposition and methods based on object orientation. By the end of the 1980s a large number of different object-oriented modelling methods existed. During the later part of the 1990s, the industry has focused on achieving consensus (through standardization) on a few object-oriented methods for modelling real-time software systems. The OMG unified modelling language, UML, see OMG (1999), and the ITU-T specification and description language, SDL, see the ITU-T recommenda- tion Z.100, are examples of such modelling languages. Thus, it has been possible to reach a high level of consensus on modelling lan- guages and methods for software engineering in a rather short time, compared to the situation in systems engineering. This is mainly because software engineering is a discipline of interest to most syste