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

captured by the domain model. Like Rolland in [34] we established a classification
of the various kinds of evolution of the different types of knowledge within a
domain model [ 27] .
All these kinds of changes to the domain model are supported in our approach.
Initial considerations or externally driven advances can simply be entered to the
domain model and are immediately available for use. For project-driven changes,
the support is more sophisticated. The indication for changes results here from a
number of earlier projects. If a similar project-specific extension has been added
several times or if parts of the domain model have always been deleted within
the recent past, these are obviously good candidates for extensions and reductions,
respectively. While reductions can be identified quite easily, the detection of similar
project-specific extensions is much more complicated. The operational support uses
a heuristics based approach to compute potential candidates but still relies on man-
ual intervention by an experienced engineer. First details on this are given in [ 28]
but otherwise the issue is subject to current research.
Uncontrolled changes to the domain model can harm the accuracy of the
similarity search. Therefore, counter measures have been established. First, the
domain model based queries are reformulated to be more robust against changes.
This includes favoring object identifiers over names and making more use of the
advanced feature of the underlying Telos formalisms (e.g. generic queries [18] ).
Secondly, limited support for updating earlier projects according to domain model
changes is provided. A formerly project-specific extension might need to be slightly
reformulated to fit with the current version of the domain model where this exten-
sion has been included as a change. Only after such adaptations, the domain model
based queries of the similarity search are able to correctly identify the old project as
being related [ 27] .
4 Discussion
Figure 5 summarizes the support that our domain model based requirements engi-
neering approach provides. An interdisciplinary methodology allows for capturing
control as well as software requirements. Non-functional requirements from both
disciplines can be considered. Possible solutions can be investigated irrespective
to what is realized in hard- or software. The approach seamlessly integrates with
and completes the now fully model-based development approach for control sys-
tems. With the support of domain models, the SME is able to capture consolidated
engineering knowledge originating in former customer projects. This immediately
improves the situation for any new customer. Furthermore together with the similar-
ity search this provides a means to support reuse and to cope with variability while
still remaining customer- and project-oriented at the core.
Dedicated work on requirements engineering in the context of automotive soft-
ware development has been carried out by Geisberger and Schätz [ 13] by developing
AutoRAID, a tool for capturing automotive software requirements. While they also