Q-Modelino – 10 Steps

In the first step, it is important to grasp the purpose of modelling and to involve all necessary stakeholders. Modelling is never an end in itself and should be embedded in the software development process and offer added value. Therefore, it should already be clarified in this phase what interest is being pursued with the modelling and what goal is to be achieved. Who can contribute to the achievement of the goal and who can contribute what information. To identify the purpose, we offer a simple questionnaire that provides a rough orientation. For example, are there concrete framework conditions for the modelling? Which language should be used? Is there already a requirements description for the system to be modelled? Back

Every system has a system context in which it is embedded. The system context is a part of the environment of a system. The system context includes all aspects that have a relationship to the system. Possible aspects can be, for example, users, processes, documents or other third-party systems. The aim of this step is to identify the system context as precisely as possible. Back

A system is often used by different stakeholders. The aim of this step is first to take the different perspectives of the individual actors. The result is to first get an overview of the application scenarios of the different actors and to describe them. The system is seen here as a so-called black box. We first describe only what the stakeholders can do with this BlackBox. Back

A system can be described by different concepts. We use object orientation in our method. This means we describe the system through objects. In this step we therefore identify classes and interfaces that could provide functions of the system. Back

A system performs functions or services for its users. To perform these tasks, data is often needed or used. The goal in this step is to describe the data used. This step also includes consideration of how data should be managed by the system and how the data can be accessed. Back

A system consists of different parts, components and subsystems. The goal in this step is therefore to describe the individual structural components of the system. The aim is also to identify which functionality can be provided by which component. Identifying the relationship between the components is also an important aspect of this step. Back

A system provides functions and services that are realised through various activities. The aim of this step is to describe the exact sequences (processes) of the system's activities that are necessary for the provision of functions and services. The process description specifies a sequence and describes which decisions or data are necessary for a certain activity. Likewise, procedures also describe an expected end result. Back

The components of a system are interconnected to varying degrees. There are components or services that use functions from other components. Components can therefore be dependent on each other. The goal in this step is to describe the dependencies between the individual components or system parts. We can also identify dependencies on upstream requirements and downstream tests. Back

System descriptions can also contain detailed information about the internal processes of individual components. In this step, the internal processes or the reaction of the system to certain events are described. The internal behaviour of a system can be described at different levels of abstraction. In addition to describing where and how a certain behaviour should take place, concrete algorithms can also be described. The right choice of the level of detail is strongly dependent on the purpose of the modelling. For example, the generation of source code requires a different level of detail than the rough description of the processes for a tender. Back

An important aspect of the method is the constant review of the work. Various approaches are available for evaluating the concepts. Besides the classical analysis by reviewing modelling guidelines and design guidelines, the concept of instantiation offers a good possibility for early review. While modelling guidelines aim at static aspects, instantiation can enable a "trying out of the concepts". In addition to classical instance descriptions, tool-supported procedures are also used here. Back