Sobah Abbas Petersen
Norwegian University of Science & Technology, Norway
Frank Lillehagen
Troux Technology AS, Norway
Maria Anastasiou
IntracomSA, Greece
Keywords: Interoperability Requirements, Interoperability Issues, Model-based Visualisation, Requirements Validation.
Abstract: This paper describes a methodology and a model-based approach for supporting the requirements elicitation
and validation work in the ATHENA project. Numerous interoperability requirements have been gathered
by four industrial partners and these requirements are validated against interoperability issues. The process
of obtaining requirements from industrial users and developing solutions for them involves several
communities such as the users, stakeholders and developers. A model-based methodology and approach are
proposed to support the analysis of the requirements and for incorporating the different perspectives and
views that are desired by everyone. An example from the telecommunications sector is used to illustrate the
methodology and a matrix-based validation approach is supported using a model developed in the Metis
modelling environment.
Advances in technology have facilitated the use of
technology in all aspects of life, from business to
health care, from education to manufacturing as well
as in our everyday lives. The role of ICT and
communication are becoming increasing significant
in our lives. Computers and systems no longer
operate as single, isolated bits of technology used by
a single operator. Rather, the trend has been for one
system to communicate with another or depend on
input from another and for people and businesses to
share information and collaborate.
We live in a diverse world and this diversity is
no doubt reflected in the technology that we use. We
often find ourselves trying to transfer data across
heterogeneous systems, attempting to get two
incompatible devices to communicate or wondering
how our business partners’ concepts and
terminology map to ours. Standardisation efforts
have helped address some of these issues. However,
there is still a long way to go before we are able to
collaborate with our partners without facing
interoperability problems.
Interoperability, in particular, technical
interoperability is not a new issue. However, focus
on areas such as e-business, e-government, e-health
and e-learning has created a greater interest in
interoperability. This is evident from the updated
eEurope 2005 Action Plan where there is an
emphasis on increasing interoperability in all these
areas, (COM, 2004). Interoperability has been
recognised as fundamental to achieving Australia’s
e-government aims, (Australian Government, 2003)
and the National Institute of Standards and
Technology in the US has estimated the cost of
inadequate interoperability in some industries to be
as much as $15 billion per year, (Gallaher et al.,
2004). Thus, there is a global awareness on the
significance of interoperability and a need to
increase interoperability for improved business
collaboration. One approach to address
interoperability and produce solutions for
interoperability problems is by identifying and
Abbas Petersen S., Lillehagen F. and Anastasiou M. (2006).
In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 152-159
DOI: 10.5220/0002488601520159
analysing interoperability requirements that are
posed by industry.
Two projects that are focussed on
interoperability are EU Integrated Project 507849
ATHENA (Advanced Technologies for
Interoperability of Heterogeneous Enterprise
Networks and their Application), (ATHENA, 2004),
and IST-508011 INTEROP Network of Excellence,
(INTEROP, 2004). Both these projects conduct
research on interoperability for networked
enterprises. The INTEROP project focuses on
theoretical research while the ATHENA project
considers interoperability in industry by analysing
the interoperability requirements from four different
industry sectors and by developing solutions for
The process of obtaining requirements from
industrial users and developing solutions for them
involves several communities such as the users,
stakeholders and developers. The analysis of the
requirements also involves several communities and
numerous discussions. It is often difficult to keep
track of the stages in this process and to take care of
the knowledge that is created in this process that
adds to the value of the solutions. One of the
problems that have been identified during this
process is fostering understanding among the
different communities that are involved, (Christel
and Kang, 1992). The facilitation of this process in
itself poses interoperability problems! The
requirements elicitation and validation processes are
often seen in isolation by the solution developers
and the views of the industrial user or the
stakeholder are often overlooked. There is a need to
consider the lifecycle of the requirement as a whole
and take into account the views of the various
communities that are involved in the different stages
in the lifecycle.
This paper is based on research conducted in
both the ATHENA and INTEROP projects. We
propose the RAIS methodology and a model-based
approach for eliciting and validating the
interoperability requirements. The RAIS
methodology takes into account the user and the
stakeholders’ views as well as the solution
developer’s view. The Active Knowledge Modelling
(AKM) approach facilitates modelling and inter-
relating the different views and visualising them
from different perspectives, (Lillehagen, 2003). We
focus on the requirements eliciting and validation
work conducted in the ATHENA project using the
modelling approach and how this approach can
support modelling interoperability solutions that will
be developed in the project.
The approach described in this paper provides a
flexible way of analysing a large number of
requirements (interoperability as well as other types
of requirements) using model-based visualisation
techniques. This is not a new method for
requirements elicitation or validation. Rather, it is a
complementary approach where existing
requirements elicitation or validation methods can
be used. This approach can then be used to provide
visual support for the methods.
The rest of this paper is structured as follows:
Section 2 describes the ATHENA project and
interoperability requirements; Section 3 describes
the RAIS methodology and the model for analysing
and validating the interoperability requirements;
Section 4 illustrates the methodology and the model
with the help of an example and Section 5 discusses
the advantages of this approach and our directions
for continuing this work in the future.
The ATHENA project defines interoperability as
seamless business interaction across organisational
boundaries. It distinguishes between technical
interoperability and business interoperability.
Research into technical interoperability is conducted
by Action Line A projects while the Action Line B
projects conduct research on business
interoperability by analysing scenarios from four
industry sectors; aerospace, automotive, furniture
and telecommunications, see Figure 1. ATHENA
emphasises on the mutual dependence of the
technical and business aspects of interoperability in
producing good solutions. In addition to providing
interoperability solutions, one of the activities of
Action line A projects has been to identify
interoperability issues or problems concerned with
interoperability which are used to validate against
the requirements provided by the industrial partners
in the Action Line B projects.
Figure 1: ATHENA Overview.
The ATHENA B4 project deals with
interoperability requirements and one of the main
tasks is to provide a way to easily validate the
interoperability requirements by analysing them
against the interoperability issues and the solutions.
2.1 Requirements Elicitation and
Interoperability requirements from four industry
sectors have provided a rich and diverse set of
requirements. These requirements were derived by
analysing different business scenarios, e.g. supply-
chain management from the automotive industry and
project portfolio management (PPM) from
telecommunications. One of the main tasks that are
currently being undertaken is the identification of
requirements that are common to all these industries,
similarities and differences in the requirements from
the different sectors and using this information in the
design of solutions.
A mapping approach has been defined for the
validation of the requirements and solution against
the interoperability issues to ensure that all the
issues that have been identified have been addressed.
This mapping approach also considers weighting to
rank the impact of a particular issue on a
requirement and the relevance of a solution to an
Some important criteria in requirements
validation that have been taken into account are:
1. Ensure that all requirements and interoperability
issues are considered.
2. Ensure that all requirements and interoperability
issues have proposed solutions.
3. Facilitate the analysis of the above two points,
e.g. by supporting matrices to do this.
4. Ensure that requirements can be represented,
viewed and analysed in different points of views
and interests. e.g. the stakeholders’ view or the
users’ view.
The large number of requirements that have been
provided by the industrial users (~450) and
managing and analysing them have been a
challenge. The requirements are formulated in
natural language and sorting or searching through
them or identifying relationships among the
requirements demands sophisticated techniques and
technological support. The model-based approach
supports the management of the large number of
requirements and their relationships to the other
aspects such as interoperability issues and solutions.
The RAIS methodology is described in Figure 2,
where the different concepts that relate to the
requirements and interoperability issues and how
they relate (or influence) are illustrated, (ATHENA
WDB4.6.2, 2005) and (INTEROP DTG6.1, 2005).
Figure 2: RAIS Methodology.
RAIS – Requirements, Architecture,
Interoperability issues and Solutions, which are the
main concepts of RAIS, bring together all the
aspects of requirements engineering and analysis for
the design and development of appropriate solutions.
The main components are:
Requirements: These are interoperability
requirements obtained from the industrial users.
Architecture: This is about the structure of
entities, either systems or enterprises, their
components, and how the components fit and
work together to fulfill some purpose.
Interoperability Issue: These are problems
concerning interoperability extracted and
elicited from analysis of business scenarios.
Solution: These are the solutions that are
designed by the ATHENA project as well as
appropriate solutions that are available today.
These four components help us to address the
what-how dimensions of a system; e.g. what is
desired and how the desire is achieved (Soderborg et
al., 2003). In addition to these, it is possible to
incorporate other aspects such as who desire the
functionality, i.e. the stakeholders’ view, or where in
the business process is this relevant, i.e. the business
and enterprise architecture view. By bringing these
components together in a cohesive methodology, we
are able to see the dependencies among these
concepts and how they influence and impact one
another. This can be done by modelling the
dependencies among these different concepts. We
have used AKM technology and the Metis modelling
environment, (Metis, 2005).
3.1 Modelling Concepts
In Metis, the notion of a metamodel is used to define
the elements of a model. The main components of
the RAIS methodology, requirement, architecture,
interoperability issue and solution are represented as
an entity-relationship model, see Figure 3, where the
different components are represented as objects and
can be related to one another. The relationships
between the different objects are obtained by
adapting the RAIS methodology to the mapping
approach described in the project (ATHENA
WDB4.6.1, 2005).
The main concepts and relationships are:
An Interoperability issue impacts a
A Solution fulfils a Requirement.
A Solution solves an Interoperability
A Solution is relevant to an
Interoperability issue.
An Architecture structures Requirements.
An Architecture impacts an
Interoperability issue.
An Architecture defines a Solution.
An Architecture implements a Solution.
Figure 3: RAIS Metamodel.
3.2 Requirements Model
A Metis model of all the interoperability
requirements is available from the ATHENA
Dynamic Requirements Definition System (DRDS),
(Solheim et al., 2005). The DRDS has a web-based
front end for the user to provide the requirements
and a database that could be used to generate a
model in the Metis modelling environment for
requirements elicitation, validation and visualisation.
Figure 4: Weighting on Relationships.
In Metis, a requirement is represented as an
instance of the object type requirement. We have
enriched this model by modelling the
interoperability issues and solutions and creating
relationships between them to indicate correlations.
Weighting of correlations are implemented by
defining a property on the relationship that indicates
the impact of a correlation. For example, the impact
of an interoperability issue may be low (=1 or
yellow), medium (=2 or orange) or high (=3 or red),
see Figure 4.
The mapping approach defined for validation of
requirements uses matrices to analyse correlations of
requirements and issues and solutions and issues.
The model supports automatic generation of these
matrices where a relationship between two objects or
sets of objects (which represent the two axes of the
matrix) is marked on the corresponding cell on the
matrix. We have used numerical values as well as
colour coding to support the visualisation of this.
In this paper, we focus on the interoperability issues
identified by the telecoms sector by Intracom S.A.,
Greece and the interoperability requirements
provided by them. Some of these interoperability
issues are:
T4. Provision of (near) real-time aggregated
views of key business information.
T7a. Legacy applications integration and
T7b. Model driven generation of interoperable
custom and role-based workplaces
T8a. Communication / collaboration
infrastructure integration / interoperability
T8b. Exchanged and/or shared data integration /
T8c. Distributed data and data access
While these issues have been identified by the
telecoms sector, they are not confined to this
particular industry sector alone. Some of these
issues, such as “T7b, model driven generation of
interoperable custom and role-based workplaces”,
are likely to be issues that are relevant to other
industry sectors as well.
The requirements and the interoperability issues
from this sector have been modelled and the
correlations between them have been established. A
screen shot of this model is shown in Figure 5.
Figure 5: Requirements and Interoperability Issues.
Figure 6: Requirements and Interoperability Issues: Correlation Matrix.
Figure 7: Impact of Interoperability Issues on Requirements.
4.1 Validation Matrices
A matrix of the requirements against interoperability
issues is shown in Figure 6 and Figure 7. (Note that
although identifiers of requirements and
interoperability issues have been displayed on the
matrices in the figures, it is also possible to display
their names and descriptions.) The matrix shown in
Figure 6 shows the correlations between the
requirements and interoperability issues and the
colour code used to indicate the level of the impact
is shown in the cell corresponding to each
correlation. This is for quick, visual assessment of
the impact of issues on requirements. The level of
impact can also be shown as a quantitative value
(Figure 7) or as a qualitative value (low, medium,
By observing the matrix, it is possible to have an
overview of the requirements–issues landscape. A
correlation indicates that there is an impact. The
values or the colours on the matrix indicate the level
of the impact. And most importantly, it will indicate
if there are no requirements that address a specific
issue or the other way around:
An interoperability issue that does not have a
relationship to a requirement or does not impact
any requirement indicates that new
requirements must be considered so that this
issue is addressed and will be considered in the
development of solutions.
A requirement that is not impacted by an
interoperability issue indicates that it must be
verified if this requirement is really an
interoperability requirement.
Matrices can also be generated for the other
elements in the model. For example, a matrix can be
generated to validate the solutions against
interoperability issues and to assess the relevance of
each solution for an interoperability issue. The
solutions can be existing solutions, based on state of
the art, or new solutions developed by the ATHENA
project. A matrix of existing solutions against
interoperability issues will identify problem areas
where innovative new solutions can be proposed by
ATHENA. Similarly, a matrix containing both
existing and new solutions can be used to identify
solutions developed by ATHENA where the solution
may be an improvement or an alternative to an
existing solution.
4.2 Selective Viewing
One of the advantages in using a visual modelling
environment is the possibility to do selective
viewing of the data. For example, select one
interoperability issue and see the requirements or
solutions that are related to this issue. For example,
the issue “T7b, model driven generation of
interoperable custom and role-based workplaces”
impacts several requirements. A selective view of
this generated from the model is shown in Figure 8.
A matrix of this view can also be generated and this
is shown in Figure 9.
This capability is particularly important when
there are several communities involved in the work.
For example, the industrial users are interested in
identifying the issues and ensuring that there are
requirements addressing all these issues. Solution
developers are interested in ensuring that they
provide solutions to relevant issues as well as meet
the requirements from the industrial users. The
stakeholders are interested in seeing the benefit that
is achieved by adopting a particular solution. For
example, in a situation where there are two
alternative solutions that meet their needs, they will
select the one that is most beneficial for them.
4.3 Editing the Model
One of the activities during the elicitation and
validation process is changing or updating the
information in the model. For example, we might
want to have additional correlations, delete a
correlation or change the value of the impact. The
matrices can be used to change the correlations or
edit the relationships as shown in Figure 9. It is
easier and more efficient to conduct an analysis on a
selective view of the information and then use the
menus available on the matrices to make changes.
For example, we might want to have a correlation
between the requirement PPM17 and interoperability
issue T7b. Similarly, we might want to change the
value of impact on a particular correlation. These
changes can be easily achieved using the matrix, e.g.
establish a new correlation between a requirement
and an interoperability issue, delete an existing
correlation and change the value of the impact of the
Figure 8: Requirements impacted by one Interoperability
Figure 9: Matrix to show impact of one Interoperability
This paper describes a methodology and a model-
based approach for supporting the requirements
elicitation and validation work in the ATHENA
project. Numerous interoperability requirements
have been gathered by four industrial partners and
these requirements are validated against
interoperability issues. The analysis of these
requirements supports the design and development
of solutions. The use of matrices has been identified
as a means to support the validation of requirements.
The model-based approach facilitates easy
viewing of the relevant concepts and provides
enhanced visualising capabilities such as
automatically generated matrices, selective views
and colour coding on relationships to indicate a level
or a degree of an impact or relevance. The model
supports easy extension of the concepts as well as
easy integration of work done in the other parts of
the project. It also supports easy and efficient
changing or updating of the model contents during
the validation work.
We are currently enhancing our model with
requirements and interoperability issues for the other
industrial users in the project and mapping the
solutions that have been developed in the ATHENA
project against the interoperability issues. We plan
to extend the model by adding new concepts such as
the classification structure of the requirements which
will further support the elicitation process and the
identification of common requirements among the
different industries. Another important view that we
plan to implement is that of the stakeholder and the
business value. This is particularly important in the
design and validation of solutions, which is the next
phase of our work.
In the future, we see these interoperability
requirements, issues and solutions utilised by
industry as well as other sources as a means of
quickly assessing their interoperability problem(s)
and finding or designing solutions in a fast and
efficient manner.
This work has been carried out as part of the
ATHENA B4 project. ATHENA Integrated Project
is funded by the European Commission under the
FP6 IST Programme. The authors would like to
thank Dag Karlsen for his support in the
development of the modelling template and the
members of the B4 project, in particular Dario Leo
and Giorgio Sobrito, and the ATHENA consortium
for the interesting discussions that have inspired this
ATHENA (2004) Advanced Technologies for
Interoperability of Heterogeneous Enterprise Networks
and their Application, URL:
ATHENA WDB4.6.1 (2005) ATHENA Mapping
Approach Definition between Requirements and
Interoperability Issues, V. 2.0, June 2005.
ATHENA WD B4.6.2 (2005) ATHENA Mapping
Approach Validation Report, V. 1.0, Sept. 2005.
Australian Government (2003) Interoperability Technical
Framework for the Australian Government, June 2003.
Christel, M. and Kang, K. (1992) Issues in Requirements
Elicitation, Technical Report CMU/SEI-92-TR-012,
September 1992.
COM (2004) 380 final, eEurope 2005 Action Plan: An
Update, 17.5.2004, URL:
Gallaher, M. P., O’Connor, A. C., Dettbarn Jr., J. L. and
Gilday, L. T. (2004) Cost Analysis of Inadequate
Interoperability Analysis in the U.S. Capital Facilities
Industry, NISC GCR 04-867, August 2004.
H. Solheim, F. Lillehagen, S. A. Petersen, H. Jørgensen,
M. Anastasiou, (2005) Model-Driven Visual
Requirements Engineering, 13th IEEE Requirements
Engineering Conference, 29 Aug. – 2 Sept. 2005,
Paris, France.
INTEROP (2005) DTG6.1 State of the Art: Exploration of
Methods and Method Engineering Approaches, V. 1,
Oct. 2005.
Lillehagen, F. (2003) The Foundation of the AKM
Technology, Concurrent Engineering: Enhanced
Interoperable Systems, eds. Jardim-Goncalves, Cha
and Steiger-Garcão, Balkema, The Netherlands, 2003,
pp. 700-715.
Metis (2005) More information available from
Soderborg, N. R., Crawley, E. F. and Dori, D. (2003)
System Function and Architecture: OPM-Based
definitions and operational Templates,
Communications of the ACM, Vol. 46, No. 10,
October 2003, pp. 67-78.