A Structured Approach to Support Collaborative Design, Speciﬁcation

and Documentation of Communication Protocols

Fabian Ohler

, Markus C. Beutel

1,2

, Sevket G

okay

1,2

Christian Samsel

1,2

and Karl-Heinz Krempels

1,2

Fraunhofer Institute for Applied Information Technology FIT, Aachen, Germany

Information Systems, RWTH Aachen University, Aachen, Germany

Keywords:

Collaboration, Documentation, Protocols, Requirements Engineering, Speciﬁcation, Tool Support.

Abstract:

Especially in complex software development projects, involving various actors and communication interde-

pendencies, the design of communication protocols is crucially important. In this work, a structured approach

to support the design, speciﬁcation and documentation of communication protocol standards is presented. To

do so, we refer to a complex use case, dealing with the integration of multiple mobility services on a sin-

gle platform. This endeavor requires the development of a large number of independently usable protocol

standards which adhere to a multitude of quality aspects. A structured approach is required to speed up and

simplify development and also to enable synergies between these protocols. Our requirements analysis metho-

dology consists of interviewing domain experts to identify important aspects and shortcomings of the current

development process and to elicit potential improvements. These intermediate results are prioritized and in-

corporated into a requirements speciﬁcation for a standardized communication protocol development process.

Furthermore, we assess existing software solutions in terms of their applicability.

1 INTRODUCTION

An intermodal personal mobility platform allows tra-

velers to query, book, use and pay any combination of

mobility services (Beutel et al., 2016). This might

include, but is not limited to public transportation,

vehicle rental services, vehicles sharing services, par-

king, charging (of electric vehicles), ride sharing, etc.

To simplify taking part on such a platform and foster

innovation, open and standardized access is required

(Beutel et al., 2014). This can be achieved by sup-

plying formal and comprehensive design documents,

speciﬁcations and documentation for the respective

communication protocols and application program in-

terfaces (APIs). As a large number of such artifacts

is required, we ought to simplify and speed up the

creation process by providing integrated support to

all involved stakeholders. As a ﬁrst step, interviews

with domain experts to understand the current process

for developing communication protocols, e.g., which

phases it is composed of, which tools are used and

so on, have been conducted. Furthermore, we try to

identify both beneﬁts and shortcomings to elicit po-

tential areas of improvement.

The rest of this work is organized as follows: The re-

quirements analysis, including methodology, results

and analysis is presented in Section 2. Moreover,

Section 3 comprises a survey of current support tools.

Related work is listed in Section 4. In Section 5, we

critically discuss the experiences so far and give an

outlook of the next steps.

2 REQUIREMENTS ANALYSIS

In this section, we present our approach to identify

issues in the development process of communication

protocols and the respective results.

2.1 Methodology

To better understand the workﬂow of protocol deve-

lopment projects and identify the problems that arose

in this context in the past, the ﬁrst step of the ana-

lysis phase comprised interviewing domain experts.

Instead of providing relatively strict response catego-

ries in a classical questionnaire, during an interview,

experts are able express their ideas and answers freely

using their own professional terminology (Mieg and

Ohler, F., Beutel, M., Gökay, S., Samsel, C. and Krempels, K.

A Structured Approach to Support Collaborative Design, Speciﬁcation and Documentation of Communication Protocols.

DOI: 10.5220/0006787503670375

In Proceedings of the 13th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2018), pages 367-375

ISBN: 978-989-758-300-1

367

af, 2005). We used the semi-structured approach

(Fylan, 2005) to be able to delve into topics of inte-

rest, to ﬁnd out more about the why on the one hand

and to be able to compare the results between the

experts on the other hand. Before the actual inter-

views, we prepared an interview guide and evaluated

it in a pre-test with a senior software engineer with

a couple of years of experience in the ﬁeld of inte-

rest. The structure of the interviews contained a ge-

neral introduction, collecting demographic data and

the participants’ experience as a starting point. To le-

arn more about the general processes and approaches

employed, the experts were asked to identify deve-

lopment phases in past projects. For each of the po-

tentially mentioned phases, general questions regar-

ding activities and their corresponding outcomes were

prepared. Furthermore, the supporting software tools

utilized for speciﬁcation, documentation and commu-

nication were investigated. In particular, the experts

were to identify the weaknesses and deﬁciencies of

the tools employed. An additional goal of the inter-

views was to determine how the results during the dif-

ferent phases were formalized. We also asked about

the responsibility assignment considering tasks and

roles during the protocol speciﬁcation process. Since

we expected the experts to identify phases akin to the

phases in a classic software development process, the

interview guide contained further phase-speciﬁc que-

stions to be asked in case the expert identiﬁed that

particular phase.

Our interview aimed at being systematizing

(in

contrast to exploratory or theory-generating inter-

views, cf. (Bogner and Menz, 2009)). We were able

to interview ﬁve experts, of which we consider four

to be elite according to the remarks in (Littig, 2009),

where the author distinguishes between the elite, cha-

racterized by formative power, and the experts, cha-

racterized by interpretative power, with both groups

overlapping strongly. According to other research,

this quantity seems acceptable for qualitative studies

(van Heek et al., 2017; Karlsson et al., 2002; Neu-

feldt et al., 1996). Since the experts were spread all

over Germany, we performed the interviews mostly

by phone and tape-recorded all of them. The dura-

tion of the interviews varied between about 35 to 75

“Semi-structured interviews are simply conversations

in which you know what you want to ﬁnd out about – and

so have a set of questions to ask and a good idea of what

topics will be covered – but the conversation is free to vary,

and is likely to change substantially between participants.”

(Fylan, 2005)

“This kind of expert interview is an attempt to obtain

systematic and complete information. The expert enlightens

the researcher on objective matters.” (Bogner and Menz,

2009)

minutes.

An overview over the participants is presented in

Table 1. All participants have experience in protocol

speciﬁcation and standardization. Participants B and

C also have taken part in international standardization

bodies for communication protocols.

In a second step, the uniﬁed results of the inter-

views where presented to a larger group of experts

(n = 15) for a focused discussion. After the presen-

tation of the results, the group was asked to order the

identiﬁed issues, based on their severity. While not

being fully validated, this prioritization of most pres-

sing issues guides the decision process for the further

development and forms the assessment metrics for the

survey of existing tools (Section 3).

2.2 Qualitative Results

In this section, the results of the aforementioned in-

terviews including the phases distinguished by the ex-

perts and the corresponding tasks and artifacts are pre-

sented. Furthermore, an overview over the issues ex-

perienced and ﬁnally derived requirements for ade-

quate tool support is given.

Table 3 at the end of this work lists a selection of

key statements by the interviewees that we reference

using S01. . . S13.

Development Phases

The experts identiﬁed the following tasks and phases,

which resemble a consolidation of steps mentioned in

(Nuseibeh and Easterbrook, 2000):

1. Analysis: In this phase, a catalog of the roles, per-

sonas, scenarios, use cases, and a glossary is cre-

ated. The results are ﬁled in the form of text and

tables.

2. Architecture design: In this phase, sequence,

component, and deployment diagrams are crea-

ted. The results are (usually) ﬁled in the form of

text and UML (Uniﬁed Modeling Language) do-

cuments.

3. Protocol design: In this phase, data types, interfa-

ces and data ﬂows are speciﬁed. The results are

(usually) ﬁled in the form of text and XML (Ex-

tensible Markup Language) documents.

4. Validation: In this phase, reviews, functional and

integration tests in a sandbox environment and de-

monstrations are conducted.

Issues Identiﬁed

For these phases, the experts identiﬁed the following

problems (the solution approaches additionally speci-

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

368

Table 1: Interview participant overview.

Interviewee Age Sex Position Area Experience

A 62 f Manager Electronic Ticketing 39y

B 46 m Division head Real-time Passenger Information 15y

C 55 m Department head Public Transport Information Systems 15y

D 32 f Research fellow Media Production 4y

E 45 m Department head Public Transport Information Systems 22y

ﬁed were partially already mentioned by the experts

during the interviews):

Analysis. The distributed nature of the collaborative

work on documents caused problems, which were

particularly mentioned by interviewees A and D,

cf. S01 to S05 in Table 3. The exchange of docu-

ments (mostly via e-mail) was cumbersome and

often led to conﬂicts while merging the changes.

These problems can be mitigated by using a cen-

tral document storage and management. They

could further be solved by enabling to collabora-

tively work on documents. Additionally, the ex-

perts found a weak degree of formalization of the

results to be problematic, especially interviewees

B and D, cf. S09. This could be improved by em-

ploying suitable tools and well-established tem-

plates for use cases, personas, etc.

Architecture and protocol design. The separated

documentation in the form of text and UML

/ XML documents using different tools led to

duplicate maintenance, thus to additional effort

and frequently to inconsistencies (stressed by

interviewees B and C, cf. S07). By integrating

the formal speciﬁcation and the corresponding

documentation in a single tool, editing can be

eased signiﬁcantly (this was already employed

in projects of E, but changes made were hard to

merge after parallel work, cf. S04).

Validation. The poor tool support for testing and va-

lidation was identiﬁed to be the main problem

in this phase. An automated mechanism to test

implementations for speciﬁcation conformity was

lacking. Using the sequence diagrams speciﬁed in

the previous phase, test templates could be gene-

rated. In addition, the diagrams could be augmen-

ted in such a way, that actual test cases could be

generated from them. Interviewees C and E found

this to be an important aspect. Generally spea-

king, the earlier phases should be adjusted such

that the artifacts created there are furnished with

as much additional information as possible to be

able to use these for testing and validation. Furt-

hermore, the experts noted, that a certiﬁcation (in

terms of a conﬁrmation of a correct protocol im-

plementation), if offered at all, was perceived as

very expensive and that there were no options for

a self-certiﬁcation. By means of tools for con-

formity checks, such a self-certiﬁcation might be

possible.

Across the phases, the following additional problems

were addressed:

• The deﬁcient documentation of decisions lead to

insufﬁcient traceability of these in the course of

the projects (S13). By intensifying the documen-

tation using suitable methods such as issue trac-

kers this can be counteracted.

• The documents edited were versioned often only

by convention. By integrating the version control

into the tools, suitable software support could be

realized.

• A history of the documents providing transpa-

rency over which changes were made by whom

was mostly non-existent (interviewee A). Integra-

ted version control in the tools could also help

here.

• The fact that the working groups mostly docu-

mented their results in German whereas the im-

plementation is typically in English again led to

duplicate maintenance and the corresponding pro-

blems. A multilingual documentation thus seems

worthwhile.

Furthermore, interviewee C (cf. Table 1) remarked

that cloud-based tools often could not be used due

to regulations and only solutions under the complete

control of projects partners could be used. He would

also like the tool support to be easy to use (without

naming tangible metrics such as training time), even

for occasional users (S10). Interviewee B emphasized

the aspect of reviews in the last development phase,

especially in standardization projects. Additionally,

E mentioned that, during protocol design, it would

be nice to provide for a way to test a server running

an implementation w.r.t. whether it is fully functio-

nal (i.e. all necessary functional components are re-

ady and working) and not only whether it responds to

ping.

A Structured Approach to Support Collaborative Design, Speciﬁcation and Documentation of Communication Protocols

369

Issue Prioritization

Since the described problems entail an extremely high

amount of work to address them, they were prioritized

with respect to the protocol development process to-

gether with experts after the results of the interviews

were processed. This prioritization was used by us

to plan the next steps regarding how to improve an

upcoming development process. Not all of the inter-

viewed experts were present, but other software engi-

neers with experience in the ﬁeld attended leading to

an even higher participation. This different set of par-

ticipants may explain the low rating of the testing and

validation support below. Here, priority values from

P1 (very low) to P5 (very high) were used:

P5 – Separated documentation in form of text, UML

and XSD (XML Schema Deﬁnition) documents

P4 – Lacking central availability / management of

documents

– Problems while merging documents after paral-

lel editing

– Absence of glossary (including early agreement

on deﬁnitions between project partners, avoi-

ding to elongate the usage of imprecise terms)

P3 – Lack of decision documentation / traceability

P2 – Lack of templates for use cases, personas, etc.

– Lack of tools for testing

P1 – Lack of conformity checks (self-certiﬁcation)

The problems contemplated, especially those with

high priority, stem from a low support for collabo-

ration in the different tools employed and the lack of

integration between the different tools. We think, that

the best way to tackle these problems is to start with a

tool supporting collaborative work and to integrate as

many aspects of the protocol development process as

possible.

Derived Requirements

We derived the following mainly functional requi-

rements for the protocol development tool support

from the interviews and the problems discussed above

(with order not implying priority):

General requirements regarding the development

process workﬂow:

R1.1 Integrated tool support: The fact that informa-

tion was more or less unrelated and scattered

over different tools was seen as an important

problem (see S07 and S08 in Table 3 and the

top priority problem above)

R1.2 Cooperative and parallel editing: To miti-

gate problems arising from parallel work, e.g.,

merge conﬂicts (see S01 to S04 and the ﬁrst two

problems with priority 4).

R1.3 Displaying active users with their work focus:

Best practice in tools supporting cooperative

editing (see S03).

R1.4 A history of changes: Being able to see what

changed between versions was perceived as im-

portant, see 3rd additionally identiﬁed problem.

R1.5 Decision documentation refers to documenting

how decisions, e.g., for a speciﬁc technology,

have been made throughout the development.

Based on S13, we assume that not only the out-

come of a decision is to be documented, but also

the initial problem and potential alternatives.

R1.6 Commenting the elements: Important in review

phase and to discuss issues, see S08.

R1.7 Creating snapshots for setting milestones or re-

leases: Carrying over the versioning concepts

to the project scope, cf. second additional pro-

blem.

R1.8 Tool support should be easy to learn (within a

few hours): Statement S10 emphasizes that tool

support should also be easy to learn and use for

occasional users. This has to be reﬁned to a me-

tric usable for validation.

Requirements regarding the documentation scope:

R2.1 Multilingualism: As mentioned in S12 as well

as via the 4th additional problem, protocols of-

ten have to be documented in more than one

language (e.g. VDV 301-2-13

R2.2 Templates, styles, etc. for personas, scenarios,

requirements, etc.: Integrating well established

templates for the analysis phase artifacts may

help mitigate the problems mentioned in S09

and the ﬁrst problem with priority 2.

R2.3 Glossary for the domain terms used (including

a blacklist): Maintaining a glossary for the re-

levant domain terms is critical for unambiguous

communication (cf. third problem with priority

4, S05 and S06).

R2.4 Glossary for the concepts used (e.g. use case,

role, persona): Maintaining a glossary for the

relevant concepts helps clarify tasks and results

(cf. third problem with priority 4, S05 and S06).

Requirements regarding the documentation functio-

nality:

https://www.vdv.de/301-2-13-sds.PDFx

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

370

R3.1 Import functionality for resources such as ﬁgu-

res, logos, etc.: This requirement was derived

from outcomes of previous standardization pro-

jects.

R3.2 Rich text editing including enumerations, ta-

bles, comments, and ﬁgures: This requirement

was derived from outcomes of previous standar-

dization projects.

R3.3 UML diagrams (at least a subset including use

case and sequence diagrams): This requirement

was mentioned as an artifact.

R3.4 An export functionality of the documentation in

Microsoft Word format: This requirement was

mentioned as an artifact and as a prerequisite

for standardization bodies, cf. S07.

Technical requirements regarding the implementation

workﬂow:

R4.1 XML / XSD to specify data types: This requi-

rement was mentioned as an artifact.

R4.2 Importing existing schema deﬁnitions (e.g.,

from previous projects or in case a project con-

sists of sub-projects): This requirement was de-

rived from outcomes of previous standardiza-

tion projects.

3 EVALUATION OF EXISTING

TOOLS AND APPROACHES

By means of the requirements derived above, we eva-

luated several existing open source tools (such as

Papyrus

and UML Designer

, which are based on

Eclipse Modeling Framework) and commercial tools

(in particular those tools that came up in the expert

interviews: Microsoft Word

, Sparx Systems Enter-

prise Architect

, Altova XMLSpy

). An overview

over these products is given in Table 2.

Across all of them, the following commonalities

can be observed:

• All of them are desktop applications.

• There is no support for multilingual documenta-

tion.

• The user experience could be improved as using

the tools is non-intuitive or the usability suffers

from the great functional extent.

https://www.eclipse.org/papyrus

https://www.umldesigner.org

https://www.ofﬁce.com

https://www.sparxsystems.com/products/ea

https://www.altova.com/xmlspy-xml-editor

• Collaborative editing of documents is only possi-

ble using additional systems or support for coope-

rative development is very limited.

• The functional coverage with respect to testing

and validation is insufﬁcient.

Additionally, the tools with the highest requirements

coverage are commercial products and can thus not

be modiﬁed or extended beyond their current features

set. On the other hand, the requirements coverage of

the open source tools is relatively low – especially in

the context of the high priority of cooperative editing

of documents, which is tackled by none of the tools in

a sufﬁcient way. While Microsoft Word has a high de-

gree of collaborative support, the near-real time colla-

boration relies on a proprietary cloud-based solution,

which is often in conﬂict with (company) regulations

and thus cannot be taken advantage of.

4 RELATED WORK

Most software engineering projects include highly

collaborative tasks during all project phases from re-

quirements analysis to validation. Therefore, tools

supporting such projects should facilitate collabora-

tive work in an adequate way, i.a. through the use of

social media (Storey et al., 2010). In this paper, we

focused on framework, library and protocol develop-

ment, where the target audience needs to be supplied

with a formal speciﬁcation of the API / protocol and

a documentation, e.g., of the data types, the interre-

lationships, and the big picture. Thus, maintaining

the documentation in accordance with changes in the

speciﬁcation is of particular importance and poses ad-

ditional challenges (Dagenais and Robillard, 2010).

Yet, over the years, collaboration found its way

into many aspects of professional life. Therefore, ge-

neral purpose collaborative tool support (often refer-

red to as groupware) such as BSCW (Bentley et al.,

1997), supporting, e.g., ﬁle exchange, version control

and project management tasks, has been around for

some time now.

With special focus on collaborative software deve-

lopment, various tools emerged over time supporting

different aspects of the development process. Exam-

ples include version control systems, issue trackers,

or collaborative development environments (such as

GitHub

). An overview over the broad spectrum in

this area is given by (Lanubile et al., 2010). Com-

plementing these tools with a new approach to com-

munication are team communication platforms (such

https://github.com

A Structured Approach to Support Collaborative Design, Speciﬁcation and Documentation of Communication Protocols

371

Table 2: Overview over the tools and their support for speciﬁc aspects of protocol development projects.

Papyrus

UML

Designer

Microsoft

Word

Sparx Systems

Enterprise

Architect

Altova

XMLSpy

Altova

UModel

1. Analysis

Personas, scenarios, use cases yes yes no yes no yes

Requirements yes no no yes no yes

Glossary no no no yes no no

2. Architecture Design

Architecture, component, de-

ployment diagrams

yes yes no yes no yes

Sequence diagrams yes yes no yes no yes

3. Protocol Design

Function and protocol deﬁnition yes yes no yes yes yes

Data type deﬁnition yes yes no yes yes yes

4. Validation

Generating documentation no no no yes yes yes

Reviews no no yes yes no no

Functional and integration tes-

ting

yes no no yes no no

Across the phases

Decision documentation no no no no no no

Multilingual documentation no no no no no no

Cooperative work support

File format compatible with ex-

ternal version control

yes yes no no no no

Conﬂict resolution and merging

support

no no yes yes yes yes

Traceability of changes no no yes yes yes yes

Near-real time collaboration no no yes no no no

as Slack

). The potential beneﬁts and use cases of

platforms like these are evaluated in (Anders, 2016).

Moreover, there are scientiﬁc approaches with a

more top level focus on tool support for collabora-

tive design. Examples here include the approach pre-

sented in (Thomas and Scheer, 2006) for the area

of computer-aided management of reference models

in business engineering projects or for the collabora-

tive construction of ontologies (Farquhar et al., 1997).

Currently, works in the ﬁeld of cooperative tool sup-

port take that concept to the next level incorpora-

ting support for shared near-real time editing not only

of text, but of models. The Community Application

Editor presented in (de Lange et al., 2017) supports

model-driven web engineering in a collaborative man-

ner. In (Nicolaescu et al., 2016), users are presen-

ted as being able to collaboratively design a meta-

model used to generate collaboration-enabled editors

https://slack.com

for model instances.

5 DISCUSSION

This work describes initial and fundamental steps on

a path towards a structured approach for collabora-

tive design, speciﬁcation and documentation of proto-

col standards. By the help of systematized expert in-

terviews, we characterized the protocol development

process. Moreover, core requirements for a software

tool, that supports such collaborative processes, were

identiﬁed and existing solutions in the area of interest

were analyzed.

According to the importance of suitable proto-

col speciﬁcations in software development, a structu-

red collaborative approach, consisting of a process as

well as tool support, seems valuable in various areas.

An approach that considers the requirements presen-

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

372

ted beforehand, might foster efﬁcient and high-quality

protocol design and speciﬁcation, not only in the area

of personal mobility. In particular, the collaborative

design aspect plays a major role in, but not limited to,

complex development projects and offers interesting

potentials. Considering information interdependen-

cies and exchanges among system boundaries, col-

laboration support seems very fruitful. In the same

step with fostering collaboration, progress and results

become more transparent to participants. This crea-

tes comprehensibility that might be beneﬁcial or even

adversely in speciﬁc cases.

Some of the above identiﬁed requirements seem

demanding towards a tool implementation. Hence,

there is a need to strike a balance between adequate

functionality and contemporary realization. Given

the fact, that there are also individual best practi-

ces and tools, the willingness to use a collaborative

tool across organization boundaries might be an ob-

stacle in the future. Another drawback might be, that

the sustainability of newly developed tool support is

unknown and potentially inferior to established com-

mercial products.

While the focus of this paper is on the develop-

ment processes for communication protocols, many

aspect might also be valid for general software de-

velopment projects. Even though many organizati-

ons already use tools like GitHub and Google Docs

there are still a lot of companies that do not rely on

services hosted by third parties for various reasons in-

cluding data privacy concerns, sustainability doubts,

or to avoid being dependent on third party decisi-

ons. Self-hosted solutions are used to ﬁll some of the

blanks, but are then often only available for internal

use and can not be employed in inter-organizational

endeavors such as the protocol development projects

considered here for security and administrative rea-

sons. We are thus looking forward to enable the stan-

dardization bodies to provide projects aiming at sub-

mitting drafts with a collaborative development plat-

form by making the tool envisioned by us available to

them.

Current Work and Outlook

Based on our ﬁndings, we concluded that currently

available tools only inadequately support our recom-

mended workﬂow and its phases. According to our

set requirements and prioritization, we started de-

veloping a dedicated tool set to support the design,

speciﬁcation and documentation of communication

protocols. Special attention is given to improve

inter-organizational collaboration, as this requirement

https://www.google.de/intl/en/docs/about/

promises a large improvement over current soluti-

ons. We surveyed current existing libraries and soft-

ware components for the cooperative editing of docu-

ments. Most of these are based on web technologies

(XHTML, CSS, JavaScript), which lead us to decide

that a web-based tool is the best option. Furthermore,

existing JavaScript libraries were examined w.r.t. re-

quirements coverage, which could be integrated into

the targeted tool support, in the areas of UML, XML

and rich text editors. These existing libraries and soft-

ware components were evaluated w.r.t. their compati-

bility with the shared near real-time editing approach.

In doing so, we identiﬁed a set of libraries as starting

point for the actual development of our tool.

As soon as the to-be-developed tool reaches a usa-

ble state, we aim to apply it in our project to improve

the development process. Based on potential feed-

back of future users, we will iteratively change and

evaluate both the development process as well as the

supporting tool. We will apply both qualitative, e.g.

more interviews, as well as quantitative methods, e.g.

a usability study, to do so.

ACKNOWLEDGEMENTS

This work was partially funded by the German Fe-

deral Ministry of Transport and Digital Infrastructure

(BMVI) for the project “Digitalisierte Mobilit

at – die

Offene Mobilit

atsplattform” (19E16007B). The aut-

hors want to thank Felix Schwinger and Andreas Heu-

vels for their support in conducting the interviews.

REFERENCES

Anders, A. (2016). Team communication platforms and

emergent social collaboration practices. International

Journal of Business Communication, 53(2):224–261.

Bentley, R., Horstmann, T. C., and Trevor, J. (1997). The

world wide web as enabling technology for CSCW:

the case of BSCW. Computer Supported Cooperative

Work, 6(2/3):111–134.

Beutel, M. C., G

okay, S., Kluth, W., Krempels, K., Samsel,

C., and Terwelp, C. (2014). Product oriented integra-

tion of heterogeneous mobility services. In 17th In-

ternational IEEE Conference on Intelligent Transpor-

tation Systems, ITSC 2014, Qingdao, China, October

8-11, 2014, pages 1529–1534.

Beutel, M. C., G

okay, S., Kluth, W., Krempels, K.-H.,

Ohler, F., Samsel, C., Terwelp, C., and Wiederhold,

M. (2016). Information integration for advanced tra-

vel information systems. Journal of Trafﬁc and Trans-

portation Engineering, 4(4):177–185.

Bogner, A. and Menz, W. (2009). The Theory-Generating

Expert Interview: Epistemological Interest, Forms of

A Structured Approach to Support Collaborative Design, Speciﬁcation and Documentation of Communication Protocols

373

Knowledge, Interaction. In Bogner, A., Littig, B., and

Menz, W., editors, Interviewing Experts, chapter 2,

pages 43–80. Palgrave Macmillan.

Dagenais, B. and Robillard, M. P. (2010). Creating and

evolving developer documentation. In Proceedings of

the eighteenth ACM SIGSOFT international sympo-

sium on Foundations of software engineering - FSE

'10. ACM Press.

de Lange, P., Nicolaescu, P., Klamma, R., and Jarke, M.

(2017). Engineering web applications using real-time

collaborative modeling. In Gutwin, C., Ochoa, S. F.,

Vassileva, J., and Inoue, T., editors, Collaboration and

Technology - 23rd International Conference, CRIWG

2017, Saskatoon, SK, Canada, August 9-11, 2017,

Proceedings, volume 10391 of Lecture Notes in Com-

puter Science, pages 213–228. Springer.

Farquhar, A., Fikes, R., and Rice, J. (1997). The onto-

lingua server: a tool for collaborative ontology con-

struction. International Journal of Human-Computer

Studies, 46(6):707 – 727.

Fylan, F. (2005). Semi-structured interviewing. In Miles, J.

and Gilbert, P., editors, A Handbook of Research Met-

hods for Clinical and Health Psychology, chapter 6,

pages 65–78. Oxford University Press Oxford.

Karlsson, L., Dahlstedt,

A. G., Dag, J. N. O., Regnell,

B., and Persson, A. (2002). Challenges in market-

driven requirements engineering - an industrial inter-

view study. In Proceedings of the Eighth International

Workshop on Requirements Engineering: Foundation

for Software Quality (REFSQ'02).

Lanubile, F., Ebert, C., Prikladnicki, R., and Vizca

ıno, A.

(2010). Collaboration tools for global software engi-

neering. IEEE Software, 27(2):52–55.

Littig, B. (2009). Interviewing the Elite Interviewing Ex-

perts: Is There a Difference? In Bogner, A., Littig,

B., and Menz, W., editors, Interviewing Experts, chap-

ter 4, pages 98–113. Palgrave Macmillan.

Mieg, H. A. and N

af, M. (2005). Experteninter-

views (2.Auﬂ.). Institut f

ur Mensch-Umwelt-Systeme

(HES), ETH Z

urich.

Neufeldt, S. A., Karno, M. P., and Nelson, M. L. (1996). A

qualitative study of experts' conceptualizations of su-

pervisee reﬂectivity. Journal of Counseling Psycho-

logy, 43(1):3–9.

Nicolaescu, P., Rosenstengel, M., Derntl, M., Klamma,

R., and Jarke, M. (2016). View-based near real-time

collaborative modeling for information systems engi-

neering. In Advanced Information Systems Engineer-

ing - 28th International Conference, CAiSE 2016, Lju-

bljana, Slovenia, June 13-17, 2016. Proceedings, pa-

ges 3–17.

Nuseibeh, B. and Easterbrook, S. (2000). Requirements en-

gineering: a roadmap. In Proceedings of the Confe-

rence on the Future of Software Engineering, pages

35–46. ACM.

Storey, M.-A., Treude, C., van Deursen, A., and Cheng, L.-

T. (2010). The impact of social media on software

engineering practices and tools. In Proceedings of the

FSE/SDP workshop on Future of software engineer-

ing research - FoSER '10. ACM Press.

Thomas, O. and Scheer, A.-W. (2006). Tool support for

the collaborative design of reference models - a busi-

ness engineering perspective. In Proceedings of the

39th Annual Hawaii International Conference on Sy-

stem Sciences 2006 (HICSS’06).

van Heek, J., Arning, K., and Zieﬂe, M. (2017). Differen-

ces between laypersons and experts in perceptions and

acceptance of CO2-utilization for plastics production.

Energy Procedia, 114:7212–7223.

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

374

Table 3: A selection of key statements made by the interviewees.

No. Interviewee Statement

S01 D “I consider cooperative activities as the greatest shortcoming of both tools we used.”

S02 D “In our case [in the context of parallel work], there were a lot of single documents, which

needed to be merged in a relatively time-consuming way.”

S03 D “It would make sense to have an exchange platform which everyone can consistently access

at all times and where you can work on documents together, to transparently give everyone

insight into the current activities, to give everyone the possibility to inspect the results and

to enable parallel work on the documents.”

S04 E “When several people worked collaboratively on the same, common ontology

, we had no

way of merging that.”

S05 E “We found out that we repeatedly interviewed [domain] experts, where we used the same

wording, but meant different things. We write down, what we understood. As soon as this

goes back to him [the expert], he sees and clariﬁes it. [. . . ] [cooperative tool support] would

allow us to invite several domain experts to work on a record [of an interview].”

S06 B “Even when you only leave your own system vendor and talk to other partners, you often

use a different terminology. As soon as you start using a foreign language, it becomes hard

for the partners involved to be precise in the terminology such that everyone understands

exactly what others mean.”

S07 B “Currently, there is a duplicate maintenance in the tools, e.g., in Enterprise Architect and in

the Word documentation. If you would manage to do both with one tool, the documentation

as well as the actual speciﬁcation activities [. . . ] that would be a goal.”

S08 D “One could deﬁnitely improve the structured reviews of the architecture design since the

links between the architecture and the requirements were rather scattered. For there were

two completely separated – let’s say – worlds in terms of documentation, I personally saw

this as a major obstacle that needed to be overcome.”

S09 B “A more consistent format would deﬁnitely be desirable. Such a more formal approach

would generally help to guarantee portability of the results, but also to ensure that all aspects

of a use case were considered and nothing was forgotten.”

S10 C “Another problem here is not just maintenance of the tools, but also keeping the know-how.

At least for us that was the case, as when you work with it very rarely, the usage it is rather

hard.”

S11 A “[The tools] still produce documents one has to rework; which don’t have the form one

imagined. At this point there is still a lot to do, I think.”

S12 C “Keep in mind that various documentations need to be bilingual.”

S13 A “Many things were discussed that were discarded over the time. One should have docu-

mented this even more.”

a set of concepts and categories in a subject area or domain that shows their properties and the relations between them.

A Structured Approach to Support Collaborative Design, Speciﬁcation and Documentation of Communication Protocols

375