ms, since the systems we design today are increasingly software intensive. An enormous amount of work has also been invested in software engineering technologies the last 15 years. The languages for software systems modelling available today consider aspects such as distribution and real-time behaviour, but that's about all, where architec- tural principles and domain specific issues are concerned. The systems we design, produce, install, operate and maintain are, however, not just software systems. Except for pure information systems, the software of a system deals primarily with the control aspect of the systems. The fact that this functionality is implemented mainly as software is just a (natural) design choice, implying that most control functions will be performed by a computer in the system by executing a piece of software. However, from a systems users point of view, the primary function of the system is not necessarily to handle information. It may well be to produce outputs that are some kind of matter or energy, to keep a missile on track, or, as in the tele- com domain, to manage communication paths between users. This indicates that there must be other types of components in the system as well, besides software and control functions. Software implementation is often implied for major system functions. To make implementational assumptions when expressing requirements 1 Introduction to Systems Modelling on the system and its components is a restraining factor that confuses the problem of selecting implementation technologies with the problems of understanding and specifying the goals, the functions and the characteristics of a system as a whole, and providing a structural and functional solution that can satisfy those require- ments. People have looked for implementation-independent languages for modelling and specifying complex systems for a long time. In addition to the efforts of INCOSE previously mentioned, an admirable interdisciplinary academic move- ment grew during the 1970s and 1980s around the