INTEROPERABLITY REQUIREMENTS ELICITATION,

VALIDATION AND SOLUTIONS MODELLING

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.

1 INTRODUCTION

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

152

Abbas Petersen S., Lillehagen F. and Anastasiou M. (2006).

INTEROPERABLITY REQUIREMENTS ELICITATION, VALIDATION AND SOLUTIONS MODELLING.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 152-159

DOI: 10.5220/0002488601520159

 SciTePress

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

interoperability.

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.

2 ATHENA INTEROPERABILITY

REQUIREMENTS

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.

INTEROPERABLITY REQUIREMENTS ELICITATION, VALIDATION AND SOLUTIONS MODELLING

153

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

Validation

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

issue.

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.

3 RAIS METHODOLOGY AND

REQUIREMENTS MODEL

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

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

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

154

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

Requirement.

• A Solution fulfils a Requirement.

• A Solution solves an Interoperability

issue.

• 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.

4 EXAMPLE

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

interoperability

INTEROPERABLITY REQUIREMENTS ELICITATION, VALIDATION AND SOLUTIONS MODELLING

155

T7b. Model driven generation of interoperable

custom and role-based workplaces

T8a. Communication / collaboration

infrastructure integration / interoperability

T8b. Exchanged and/or shared data integration /

interoperability

T8c. Distributed data and data access

synchronization

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.

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

156

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,

high).

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

INTEROPERABLITY REQUIREMENTS ELICITATION, VALIDATION AND SOLUTIONS MODELLING

157

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

correlation.

Figure 8: Requirements impacted by one Interoperability

Issue.

Figure 9: Matrix to show impact of one Interoperability

Issue.

5 DISCUSSION AND FUTURE

WORK

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.

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

158

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.

ACKNOWLEDGEMENTS

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

work.

REFERENCES

ATHENA (2004) Advanced Technologies for

Interoperability of Heterogeneous Enterprise Networks

and their Application, URL: http://www.athena-ip.org/

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:

http://europa.eu.int/information_society/eeurope/2005/

doc/all_about/com_eeurope_en.doc

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 (2004) URL: http://www.interop-noe.org/

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

http://www.trouxmetis.com/

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.

INTEROPERABLITY REQUIREMENTS ELICITATION, VALIDATION AND SOLUTIONS MODELLING

159