. The models they produce may be viewed as intuitive and ad-hoc by oth- ers, but that is of less importance. The activity is rather short-lived (months), and there is not necessarily any need to maintain systems models after the activity is closed, since the activity might not result in a product development project. These kind of activities are not a primary target for rigorous modelling methods. Modelling tools that are frequently used are general purpose drawing tools, as e.g. Microsoft PowerPoint, or special purpose tools, e.g. for simulating some particular system characteristic. However, if a domain-specific, general purpose modelling method is available, it is often a good idea to use it, in particular if the intention of the activity is to propose a product development project. I have also seen many early phase activities that spent an disproportionate amount of time discussing modelling concepts and methods for describing the system, instead of actually designing it. The results of very early phase activity may lead to the decision to start a devel- opment project. The intuitively and (most likely) incompletely described system concept must now be explained in a way that can be understood by a much larger group of people who were not involved in the very early phase. One common way to do that is to write reports, give seminars, become consultants and participate in on-the-job training activities. Although this might work some times, it is not a very productive method. Again, much time is spent explaining the modelling method and language, instead of explaining the system solution and the reasoning behind it. The presenters also represent a scarce resource that might be better utilized in other very early phase activities. Besides, system designers are not necessarily good at writing and explaining their ideas. This is when a rigorous systems modelling method, based on some common domain specific language, is needed. The fact that the language is "common" means only that the language is well-known by thos