Goal-Based Domain Modeling as a Basis for Cross-Disciplinary Systems Engineering - Intentional Perspectives on Information Systems Engineering - page 89

Fig. 3 Common rail requirements example modeled with i ∗
alternatives to achieve goals ( means-ends ), and to specify qualitative contributions
towards softgoals ( help , make , break ,etc. contribution ). Figure 3 shows that “low
costs”, “flexibility”, and “safety” have been recognized as the most important non-
functional requirements of the “rail pressure controller”. The use of “fail safe
sensors” at the “rail pressure controller (hardware)” component is intended to sup-
port “safety” whereas the “parameterization” realized by the “rail pressure controller
(software)” contributes to the required “flexibility”.
In contrast to previous practice in control systems development, this i ∗ model
is able for the first time to capture not only the functional interdependencies of
controller and controlled system but also non-functional issues and various addi-
tional stakeholders within a combined, model-based view. Due to its origin, software
requirements can of course also be represented. Thus, the formalism is suitable as
an interdisciplinary approach to requirements engineering in the field of control
systems development [ 38] .
3.2 Domain Model Based Requirements Engineering
While the application of the i ∗ formalism addresses the basic challenges to inter-
disciplinarity, model-based development and the consideration of non-functional