Addressing Model Complexity in Automotive System Development

Selection of System Model Elements for Allocation of Requirements

Grischa Liebel

, Andreea Olaru

, Henrik L¨onn

, Henrik Kaijser

, Sunith Rajendran

Urban Ingelsson

and Richard Berntsson Svensson

Software Engineering Division, Chalmers | University of Gothenburg, Gothenburg, Sweden

Semcon Sweden AB, Gothenburg, Sweden

Volvo Group, Advanced Technology and Research, Gothenburg, Sweden

Semcon Sweden AB, Link¨oping, Sweden

Blekinge Institute of Technology, Karlskrona, Sweden

Keywords:

System Modelling, EAST-ADL, EATOP, Requirements Allocation, Requirements Engineering, Requirements

Traceability, Tool Design, Empirical Research.

Abstract:

Modern automotive embedded systems are developed by Original Equipment Manufacturers (OEM) together

with multiple suppliers. A key problem for a supplier is to allocate an OEM’s requirements speciﬁcation to

their own subsystem design. This is a difﬁcult manual task especially on complex systems and it requires ex-

pert knowledge about the system design. To address this problem, this paper presents a design science research

to develop and evaluate a Requirements Allocation Assistant tool (RAA). The tool provides functionality to

search through and ﬁlter requirements and system models to enable efﬁcient requirements allocation even in

the presence of complexity. RAA is built on top of the EATOP/Eclipse framework using EAST-ADL as sys-

tem modelling language. The tool was evaluated and validated during a qualitative usability study with 17

engineers active in the Swedish automotive industry. Key ﬁndings are that searching is used to learn about a

system, whereas ﬁltering is used to narrow down a set of candidate elements of the system design. Engineers

request further support in narrowing down a set of candidate elements and in checking that an allocation is

correct.

1 INTRODUCTION

The trend towards embedding electronic and

software-based control systems into vehicle functions

continues, leading to ever more complex systems.

In particular, textual requirements speciﬁcations of

vehicle functions often span thousands of pages. The

challenge at hand is to make system development

competitively correct, cheap and quick in the pres-

ence of high complexity. This includes addressing

manual tasks in the system development process.

One important way to address complexity is to

enable reuse of system components. To do so, one

of the key manual tasks in the development of em-

bedded systems in collaboration between multiple or-

ganisations is requirements analysis. In requirements

analysis, engineers allocate requirements to an exist-

ing subsystem design, to see whether the design can

satisfy them. Complexity may obscure the engineer’s

insight into the subsystem design and make require-

ments analysis inefﬁcient.

In cognitive load theory, it is found that structure

of information is important and support for ﬁnding

relevant information is helpful (Passera, 2015). Ap-

plied to the issue of complexityinrequirementsanaly-

sis, three orthogonaldimensions of support from tools

can be considered, namely the visual representation,

the structure of the presented information, and re-

stricting the presented information to a manageable

subset. In this paper we address complexity, not

by attempting to reduce it, but by investigating how

the manual task of requirements analysis can be sup-

ported by tools, mainly by exploiting the structure of

the information and allowing the presented informa-

tion to be restricted.

Considering the wide application of model-based

engineering in the automotive domain (Liebel et al.,

2014), it should be considered how modelling can

168

Liebel, G., Olaru, A., Lönn, H., Kaijser, H., Rajendran, S., Ingelsson, U. and Svensson, R.

Addressing Model Complexity in Automotive System Development - Selection of System Model Elements for Allocation of Requirements.

DOI: 10.5220/0005652101680175

In Proceedings of the 4th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2016), pages 168-175

ISBN: 978-989-758-168-7

be employed to address complexity during require-

ments analysis. Using a well-known modelling lan-

guage can ease understanding of the modelled system

through the semantics of the language.

An upcoming modelling language is EAST-

ADL (EAST-ADL Association, 2015), an architec-

ture description language for automotive embedded

systems. EAST-ADL speciﬁes how to represent a ma-

jority of the system description. A key beneﬁt of rep-

resenting a system design in a structured information

model such as EAST-ADL is that predeﬁned view-

points can be applied to visualise information in a

way that complexity becomes less of an obstacle. Fur-

thermore, a similar structure could be enforced for re-

quirement speciﬁcations and for system models, thus

increasing the sense of recognition.

Prior work on tool support for source code vi-

sualisation has suggested searching and ﬁltering as

valuable tool features (Bassil and Keller, 2001). By

employing a modelling language, the semantics can

be employed to create various types of search (ﬁlter)

queries. Queries can apply to speciﬁc modelling el-

ement types, attributes and relationships, as well as

to exploit traceability. To our knowledge, no prior

work has investigated the use of searching and ﬁlter-

ing tool features employing the semantics of a struc-

tured modelling language to reduce the cognitive load

when performing requirements allocation.

Therefore, our contribution in this paper is to:

• express the need for tool support that reduces

the cognitive load when performing manual tasks

(speciﬁcally requirements analysis) to enable ef-

ﬁcient collaborative development of complex em-

bedded systems.

• present a tool prototype called Requirement Allo-

cation Assistant (RAA) that enables searching and

ﬁltering of requirements speciﬁcations and system

models represented in EAST-ADL. RAA is im-

plemented within the EATOP open source tool.

• provide an evaluation of RAA by applying

qualitative techniques from usability engineer-

ing (Faulkner, 2000).

• present increased understanding of the process of

requirements allocation, that may be formulated

as a theory to guide further effort towards tool

support.

While it is an ambitions goal to provide tool sup-

port for requirements analysis to reduce the manual

effort, the scope of this paper is restricted to studying

two tool features, namely searching and ﬁltering, mo-

tivated by a suggestion by (Bassil and Keller, 2001).

We formulated two research questions to evaluate the

two tool features ant to compare them, to gain under-

standing of how they align to the manual (cognitive)

process of requirements analysis.

RQ 1: How can the use of searching and ﬁltering

tool features aid requirement allocation in a sys-

tem development effort in terms of intuitiveness,

helpfulness and decision support?

RQ 2: Which tool feature, searching or ﬁltering, is

best aligned to support requirements analysis and

why?

2 RELATED WORK

This section discusses the literature and the concepts

that are related to this paper. I.e., EAST-ADL is pre-

sented as a prerequisite to understanding our tool pro-

totype presented in Section 4 and related publications

to this paper are presented thereafter.

2.1 EAST-ADL

EAST-ADL (EAST-ADL Association, 2015) is an ar-

chitecture description language that has been speci-

ﬁed over the last decade. The ambition is to stan-

dardise a structured information model that can be

employed to represent an automotive embedded sys-

tem model from concept level to implementation

level (Blom et al., 2013). It is aligned with AU-

TOSAR for software architecture (AUTOSAR, 2015)

and with ISO 26262 (ISO, 2011). When developing

a system in accordance with ISO 26262, the scope

of modelling and requirements speciﬁcation covers

the whole system on each abstraction level, with cor-

responding traceability. Consequently, each vehicle

feature is realised by functions that are in turn realised

by design-level components and so on. Similarly re-

quirements of vehicle features are speciﬁed into func-

tional requirements and further into requirements and

design. These requirements are allocated to the corre-

sponding system model elements by adding a Satisy

relationship. The Satisfy relationship connects a re-

quirement to system model elements that satisfy it.

The requirements modelling package of EAST-ADL

is aligned with SysML (Object Management Group,

2015).

2.2 Related Publications

Tool support to reduce the cognitive challenge im-

posed by complexity has been considered before, es-

pecially in the realm of software design. Architectural

viewpoints which show a particular aspect of a soft-

ware architecture and excludes other information are

Addressing Model Complexity in Automotive System Development - Selection of System Model Elements for Allocation of Requirements

169

a well-known concept (Kruchten, 1995; ISO, 1998)

These viewpoints enable engineers to easily recognise

key aspects of the software architecture.

In the realm of requirement analysis, (Hofmeis-

ter et al., 2005) argue that the complexity of require-

ments analysis is impacted by a conceptual gap be-

tween requirements and architecture. This means that

to perform requirements analysis one must ﬁrst learn

about the system design. To lessen this gap, the au-

thors present an approach, based on four viewpoints,

guiding the architecture design process. The tool sup-

port considered in this paper is complementary to the

viewpoints in (Hofmeister et al., 2005), with the nov-

elty of exploiting a structured modelling language.

Telea et al. (Telea et al., 2010) conduct a review

of architectural visualisation tools based on three user

categories. They report that technical users consider a

visualisation tool useful if it provides IDE integration

and generates desired custom viewpoints with as few

operations as possible. They report that architecture

visualisation tools should provide interactive ways to

compare, correlate and search data. The authors men-

tion that requirements allocation viewpoints are much

harder to implement in a tool because this activity re-

quires the user’s active participation.

Bassil and Keller (Bassil and Keller, 2001) present

an evaluation of tools for visualising source code to

software engineers. Key aspects of these tools include

browsing based on the code structure and searching to

identify relevant parts of the code.

In this paper we address the challenge to imple-

ment a viewpoint for requirements allocation. To

bridge the conceptual gap between requirements and

system design, we take on the challenge to implement

a viewpoint for requirements allocation. The purpose

is to support engineers to use their expert knowledge

and quickly learn about the system. In contrast to

architectural viewpoints, we cannot generally deﬁne

what information is needed when analysing any given

requirement, so it becomes necessary to allow an en-

gineer to use their expert knowledge. Consequently,

we develop two tool features, namely searching and

ﬁltering, to make the engineer efﬁcient in deﬁning the

relevant information, and integrate into an IDE called

EATOP. Further, we are exploiting the structure im-

posed by EAST-ADL to further aid engineers to learn

about a given system design.

3 RESEARCH METHODOLOGY

This section presents the research methodology em-

ployed in the work presented in this paper, with the

purpose of enabling continued research on the same

topic with the same or improved methodology.

The investigation presented in this paper was car-

ried out using a design science research approach

(Hevner et al., 2004). Design science research is the

study of artfacts in a context (Hevner et al., 2004) by

adding a problem-solving cycle to a theory-building

cycle. Design science research aims to develop and

evaluate an artefact to meet a speciﬁc business need.

We followed Hevner’s Design Science framework

(Hevner et al., 2004), which consists of two main

steps, namely development of an artefact followed

by its evaluation. The general idea is to use existing

knowledge to develop/build theories/artefacts, where

the development step is based on the business needs

that originate from the study’s environment, which

consists of the people, the organisation, and the tech-

nology.

3.1 Knowledge Base

The knowledge base was collected from the litera-

ture described in Section 2 as well as from knowledge

about Eclipse plug-in development and the EATOP

project.

3.2 Environment

The study was conducted in the automotive engineer-

ing department of Semcon, a global company pro-

viding engineering services, as a contribution to the

research project Synligare

. Semcon provides engi-

neering services to automotive Original Equipment

Manufacturers (OEMs) and to their tier-1 suppliers.

Sometimes, Semcon helps tier-1 suppliers in allocat-

ing requirements from their OEM customer to their

own system models. This collaborative development

strategy, where requirements and an existing system

model are originating from two different companies,

is nowadays common practice in the automotive do-

main and therefore not unique to Semcon.

3.3 Development Process

RAA was developed as a plug-in extending EATOP. It

was developed from a given speciﬁcation by a small

team consisting of a computer programmer, an expert

on the Eclipse platform, and a number of industrial

and academic advisors. The development process was

informal and contained informal peer review of de-

sign and code. The design of RAA is described in

detail in Section 4.

www.synligare.eu

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

170

3.4 Evaluation Process

The evaluation of RAA was carried out using usabil-

ity evaluation techniques (Faulkner, 2000). That is,

the evaluation was focused on answering how intu-

itive and helpful RAA is, as well as how RAA pro-

vides decision support.

We conducted a usability study with 17 engineers

from the case company and from the consortium of

the Swedish research project Synligare. It started with

a presentation of EAST-ADL, RAA and concrete ex-

amples of using the tool features. After the presen-

tation, the participants were provided with an instal-

lation of RAA together with a sample requirements

model and system model. During the study, the ques-

tions and reﬂection of the participants were written

down in order to be used for analysing the results.

Each participant ﬁlled in an anonymous question-

naire containing 13 questions. It started with a sec-

tion gathering demographic data, and the participants’

experience regarding requirements tools with alloca-

tion functionality. This part was followed by speciﬁc

questions about the two searching and ﬁltering tool

features.

We analysed the data starting with coding the free-

text answers by theme or category, followed by iden-

tifying the set of data relevant for each research ques-

tion. This data provides the reactions to RAA and

can be used as evidence of existence of opinions, but

it does not tell how representative the opinion is. To

get an overview of the data, tabulation (Runeson and

H¨ost, 2009) was used as an analysis technique, i.e. ar-

ranging the data in tables based on the research ques-

tions. In addition, graphs were used to visualise the

data. The analysis results are presented in Section 5.

3.5 Validity Threats

The threats to validity of the study and the claims

made based on the collected data are presented here

together with possible countermeasures taken to in-

crease validity.

Construct Validity: To avoid misleading or con-

fusing usability study participants, the questionnaire

was reviewed by two researchers involved in the study

and improved based on their feedback. The usabil-

ity study was performed using a single station to give

all participants the same experience. Consequently,

RAA could be used by one participant at a time. This

could give the participants the feeling that they were

evaluated, making evaluation apprehension a realistic

threat. To alleviate this threat, the questionnaire was

ﬁlled in anonymously at a separate desk, unassisted

and unobserved.

External Validity: This study involved partici-

pants with various backgrounds and experience from

different companies in the automotive industry in

Sweden. The participants are potential target users

for RAA and their companies do requirements analy-

sis in the context of collaborative development. Thus,

the ﬁndings of this study may be valid for companies

facing similar problems in the automotive and the em-

bedded systems domain. However, organisational and

regional culture could have affected the outcomes.

We will address this threat in the future by replicating

the usability study with engineers of different back-

ground.

Internal Validity: Each subject participated only

once in the study, which alleviates maturation threats.

A possible threat is the participants’ lack of knowl-

edge about EAST-ADL, which may distract from

achieving an untainted experience of the usability of

RAA. To alleviate this threat, we showed each par-

ticipant an example of a requirement and a system

model element such that both contain enough infor-

mation for a feasible allocation. We also gave a short

overview of EAST-ADL.

Conclusion Validity: Usability issues in RAA,

other than those considered in the research questions,

could have inﬂuenced the participants. This threat

was alleviated by ensuring clarity in the question-

naire, such that the questions are aligned with the re-

search questions.

4 RAA

RAA is built as a plugin to the EAST-ADL Tool Plat-

form (EATOP

) RAA adds tool features on top of

EATOP and can be combined with other plugins.

4.1 Architectural Design

RAA is intended to aid requirements analysis in the

context of collaborative development of complex au-

tomotive embedded systems. It does so by easing the

identiﬁcation of relevant information in system mod-

els and by assisting engineers in allocating require-

ments to elements of existing system models. RAA

is developed as a proof of concept of how to employ

a structured information model to bridge the concep-

tual gap between requirements and system design, so

that engineers doing requirements allocation can eas-

ier learn about the system design and be more efﬁ-

cient.

https://www.eclipse.org/eatop/

Addressing Model Complexity in Automotive System Development - Selection of System Model Elements for Allocation of Requirements

171

Figure 1: Design overview of RAA.

Figure 2: Main user interface of RAA.

The design of RAA, including the extensions of

EATOP and the main selection and allocation tool fea-

tures, is illustrated in Figure 1.

RAA is an extension of the EATOP Example Edi-

tor, which contains a hierarchical view for navigating

system model elements. This view (EastADLCon-

tentsTree) is instantiated twice in RAA, for showing a

requirements speciﬁcation (RequirementTreeSection)

and a system model (ModelTreeSection). An exam-

ple of the visual appearance of the hierarchical views

in RAA is given in Figure 2, with the requirements

speciﬁcation on the left and the system model on the

right.

The building blocks for RAA’s key tool features

are SearchAndFilterOperation and AllocationOpera-

tion. The former is instantiated on both hierarchi-

cal views, enabling searching and ﬁltering for the re-

quirement speciﬁcation and for the system model in-

dependently. The latter involves elements from both

hierarchical views. Therefore, it is architecturally

associated with RequirementsAllocationTreePage, a

container that holds both hierarchical tree views in-

stances. In the user interface, the AllocationOpera-

tion is represented by a button marked Allocate (see

Figure 2).

Figure 3: Searching among requirements.

Figure 4: Filtering among model elements.

4.2 Tool Features

A query for searching consists of an element type and

a value for a speciﬁc attribute. An example is search-

ing the requirements speciﬁcation for all requirements

(element type) that have in the requirement text (at-

tribute) the string “speed limit” (attribute value) (see

Figure 3).

A query for ﬁltering consists of an element type

and a value for a speciﬁc attribute, such that elements

of the chosen element type are included in the result

except if the speciﬁc attribute has the given value.

The example in Figure 4 includes all Design Func-

tion Type elements but excludes those that have the

word “break” in their name.

In RAA, allocation is performed by pressing the

allocation button after selecting at least one require-

ment in the requirements speciﬁcation and at least

one element in the system model. EAST-ADL of-

fers the possibility to allocate one or many require-

ments to one or many system model elements through

satisfy relationships. For example, allocating one re-

quirement to three elements from the system model

means that the selected requirement is satisﬁed by

those three model elements. This allocation would

create one Satisfy element, containing the reference

to the satisﬁed requirement, and three satisﬁedBy el-

ements, each pointing at one of the model elements

that the requirement is satisﬁed by.

As our tool handles relationships between two

models, there are multiple options on where to store

the newly created model elements. The newly cre-

ated model elements, called Relations and Satisfy1 in

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

172

E xis ting Elements

A dded by Tool

RequirementsModel

S tru cturalMod el

Reqs

Req1

Req2

Req3

Top

P art1

P art2

Relations

S atisfy1

E xis ting Elements

+S atisfiedBy

+S atisfiedRequirement

Figure 5: Storage of newly created model elements.

Figure 5, could be stored in the requirements model,

in the system model or in a separate model. Addi-

tionally, both models could be combined into a sin-

gle model, including the newly created relationships.

Even though we currently only support storage in the

requirements model, the remaining scenarios are rel-

evant and will be added in future versions of RAA.

5 EVALUATION

Demographic data of the study participants is pre-

sented in Section 5.1, followed by the answers to the

research questions in the remaining sections.

5.1 Demographic Data

All participants were engineers in the automotive in-

dustry, with various specialisations such as system en-

gineering or management. Eleven of them were from

Semcon and six from other companies. The partic-

ipants had between three and 19 years work experi-

ence, with twelve out of 17 participants having prior

experience in requirements engineering.

We asked the participants which tool features they

deemed important in a tool supporting requirements

allocation. All of the practitioners answered that

traceability is important. Further, 16 out of 17 an-

swered that searching and ﬁltering tool features are

important. Seven participants answered that high-

lighting information is an important tool feature.

5.2 Aiding Requirements Allocation

Considering Research Question RQ1, the intuitive-

ness, helpfulness and decision support provided by

RAA was evaluated by asking the participants to an-

swer direct questions from the questionnaire. There

was also opportunity for the participants to leavecom-

ments about these aspects of RAA. In the evalua-

tion questionnaire, the participants’ opinions regard-

ing the two features were gathered based on three as-

pects: intuitiveness, helpfulness to ﬁnd relevant infor-

mation, and helpfulness in making requirements allo-

cation decisions.

Figure 6 summarises the data regarding the three

measured aspects. The count of participants who dis-

agree with the statements is shown in blue and the

count of participants who agreed in green. Undecided

participants are coloured grey. There are no partic-

ipants that strongly disagree with any statement. It

could be thought obvious that searching and ﬁltering

are intuitive and that they help to ﬁnd relevant infor-

mation. This may explain the fact that there are many

agreements to the statements. For searching and ﬁl-

tering, one reply each voiced disagreement. This may

be due to the fact that the searching and ﬁltering fea-

tures requires search queries that involve specifying

an element type and an attribute name. This could be

less intuitive as, e.g., free text queries applied to all

attributes of all elements, especially for someone who

is not familiar with the element types in EAST-ADL.

Further, it can be seen that there is more hesitation

regarding ﬁltering. Some undecided participants left

comments saying that they “usually look for some-

thing in particular”, rather than attempting to exclude

irrelevant information. This observation may reveal a

key insight into the thought processes of an engineer

performing requirements analysis, leading to a possi-

ble answer to the “how” of RQ1. Searching may be

intuitive and helpful because it aligns well with the

thought processes of the engineer. Filtering, however,

is seen as intuitive but used more seldom – a tool fea-

ture to use when searching attempts were not success-

ful. A further comment suggested to enable several

search and ﬁlter queries to be applied in combination,

as present in related tools such as DOORS

It is intuitive to use seaching

It is intuitive to use ltering

Seaching helps to nd relevant inf.

Filtering helps to nd relevant inf.

Seaching helps making allocation dec.

Filtering helps making allocation dec.

Answers Count

14 2

1 4 12

14 3

3 13 1

943

1 8 7 1

Strongly

Agree

Disagree

Strongly

Disagree

Undecided

Figure 6: Intuitiveness, helpfulness and decision support of

RAA.

Considering the reactions to the statements that

searching and ﬁltering respectively helps making de-

cisions about allocation, there are more undecided

http://www.ibm.com/software/products/sv/ratidoorfami

Addressing Model Complexity in Automotive System Development - Selection of System Model Elements for Allocation of Requirements

173

replies. For searching, there are three disagreeing

replies. Indeed a participant commented that neither

searching nor ﬁltering helps making decisions about

allocation. This participant voiced the need for a tool

feature to “check if the selected element matches the

requirement” and to highlight possible elements in the

model that may match the selected requirement. This

indicates that while searching and ﬁltering are intu-

itive and helpful tool features and in this way support

decision making, they are not in themselves consid-

ered to provide decision support in a strict sense. An-

other possible insight could be that the perceivedchal-

lenges in requirements analysis include picking can-

didate elements for allocation of a requirement and

checking if selected elements match a requirement.

It could be speculated that the participant with these

comments expects that some aspects of requirements

analysis could be automated.

5.3 Comparison

To collect data to relate to RQ2, participants were

asked to compare searching and ﬁltering. They were

asked to compare the tool features with respect to

how efﬁciently they could be employed to ﬁnd rele-

vant information. Six experienced participants con-

sider searching to be more efﬁcient as compared to

ﬁltering. Comments from these participants include

that it is “more intuitive to search for what you need”

and that “searching for a speciﬁc type helps nar-

rowing down” the displayed information. Further, it

was again commented that “usually you are looking

for something in particular and seldom you are aim-

ing to exclude”. One participant took the opposing

view, that ﬁnding relevant information is more efﬁ-

ciently done by ﬁltering. Inexperienced participants

are mostly ambivalent.

Next, the participants were asked to compare the

tool features with respect to which tool feature they

would use when facing high complexity. Eight par-

ticipants found searching and ﬁltering equally useful

when facing high complexity. One of them stated

that “searching is useful to make a quick search and

ﬁltering is useful to look at details”. Another com-

mented that “for large sets both would be needed

for easy overview”. These comments may reveal the

approach that an engineer performing requirements

analysis would take, namely to learn about the sys-

tem design ﬁrst by searching for information, and then

narrow down the set of candidate elements based on

what was learned. In this process of narrowing down

the set of candidate elements, we speculate that the

engineer beneﬁts from obtaining an overview. Indeed,

for a small set of elements, searching may be enough

to achieve an overview, whereas for large sets of ele-

ments, ﬁltering is necessary.

Lastly, the participants were asked if their prefer-

ence between tool features depends on if they were

considering a requirements speciﬁcation or a system

model. Figure 7 shows how the participants an-

swered. Possible answers are “searching”, “mostly

searching”, “equal use”, “mostly ﬁltering” or “ﬁl-

tering”. The two columns for each possible answer

represent the answers for a requirements speciﬁca-

tion and a system model respectively. The colours

of the bars show the answers that are given by par-

ticipants that are experienced as requirements engi-

neers and the participants who are not requirements

engineers. It can be seen that experienced partici-

pants prefer searching over ﬁltering for both require-

ments speciﬁcations and system models. In fact, only

ﬁve participants made a difference between require-

ments speciﬁcations and system models. Comments

from these ﬁve include that the choice of tool feature

should be ﬂexible “according to the situation”. How-

ever,they chose searching for system models, because

when considering them you “more often know what

you want”. From this, it can be seen that at least one

engineer had a different expectation of system models

as compared to requirements speciﬁcations. It could

be that the structure of a system model can be expe-

rienced as more tangible as compared to the structure

of requirements speciﬁcations. A well-made system

model has a clear hierarchy in terms of components

with interfaces and a structure that comes from real-

ising functions. In the ideal case, the requirements

should also have such a clear structure – something

that might be helped by having a structured infor-

mation model like EAST-ADL or by putting effort

into maintaining traceability among requirements. In-

deed, after the manual task of requirements analysis

involving allocation, the structure of the requirements

should be more clearly seen through the structure of

the system model that the requirements become allo-

cated to.

6 CONCLUSIONS

In this paper, we presented the requirements alloca-

tion assistant tool RAA, developed using a reusable

design science methodology. RAA was developed to

enable searching and ﬁltering on requirements spec-

iﬁcations and system models, with the purpose to

make requirements analysis involving allocation ef-

ﬁcient – even in the presence of high complexity. The

way that this work addressed complexity was by al-

lowing the displayed information to be restricted to a

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

174

Modelling Elements (Requirement Engineers)

Modelling Elements (Not Requirement Engineers)

Requirements (Requirement Engineers)

Requirements (Not Requirement Engineers)

Figure 7: Tool feature preferences for requirements speciﬁ-

cations and for system models.

level that can be managed manually, not by reducing

the complexity of the system design. Further, the se-

mantics of a structured information model like EAST-

ADL may help to make a system model more under-

standable and better structured.

To evaluate RAA and learn how requirements

analysis can be further supported, a qualitative usabil-

ity study was conducted with 17 engineers. From this,

we can form a preliminary theory of the typical pro-

cess. The process starts by learning about the system

model based on considering a given requirement, us-

ing the main tool feature. Subsequently, a set of el-

ements for allocation is identiﬁed, preferably also by

searching. For large information sets, ﬁltering is also

used. Finally, the requirements and the system ele-

ments are checked to assure that the allocation is cor-

rect. In the last two steps, multiple study participants

requested further tool support.

This preliminary theory forms the basis for future

work. We will include a wider selection of partici-

pants in the usability study. Additionally, we will ex-

tend the tool in order to suggest a possible set of can-

didate elements for allocation to a given requirement

or to check the correctness of a given allocation.

ACKNOWLEDGEMENTS

We would like to thank the engineers who participated

in the evaluation of the prototype. This work was sup-

ported by VINNOVA under the FFI programme. This

work was conducted as part of the Synligare Project.

This paper reports on results that were conducted as a

Master Thesis project at Chalmers University of Tech-

nology, Sweden (Olaru, 2015).

REFERENCES

AUTOSAR (2015). AUTOSAR. http://www.autosar.org/.

Bassil, S. and Keller, R. (2001). Software visualization

tools: survey and analysis. In Program Comprehen-

sion, 2001. IWPC 2001. Proceedings. 9th Interna-

tional Workshop on.

Blom, H., L¨onn, H., Hagl, F., Papadopoulos, Y., Reiser,

M.-O., Sj¨ostedt, C.-J., Chen, D.-J., Tagliab`o, F.,

Torchiaro, S., Tucci, S., and Kolagari, R. T. (2013).

EAST-ADL: An architecture description language for

automotive software-intensive systems. In Embedded

Computing Systems. IGI Global.

EAST-ADL Association (2015). EAST-

ADL v2.1.12. http://www.east-

adl.info/Speciﬁcation/V2.1.12/html/index.html.

Faulkner, X. (2000). Usability engineering. Palgrave.

Hevner, A. R., March, S. T., Park, J., and Ram, S. (2004).

Design science in information systems research. MIS

Q., 28(1):75–105.

Hofmeister, C., Nord, R., and Soni, D. (2005). Global anal-

ysis: moving from software requirements speciﬁca-

tion to structural views of the software architecture.

Software, IEE Proceedings -, 152(4):187–197.

ISO (1998). ISO/IEC 10746-1:1998 Information tech-

nology – Open Distributed Processing – Reference

model: Overview. ISO/IEC 10746-1:1998, pages 1–

76.

ISO (2011). ISO 26262-1:2011 Road vehicles – Functional

safety. ISO 26262-1:2011, pages 1–23.

Kruchten, P. B. (1995). The 4+ 1 view model of architec-

ture. Software, IEEE, 12(6):42–50.

Liebel, G., Marko, N., Tichy, M., Leitner, A., and Hansson,

J. (2014). Assessing the state-of-practice of model-

based engineering in the embedded systems domain.

In Proc. of ACM/IEEE 17th International Conference

on Model Driven Engineering Languages and Sys-

tems. Springer International Publishing.

Object Management Group (2015). SysML 1.3.

http://www.omg.org/spec/SysML/1.3/.

Olaru, A. G. (2015). Visualizing relevant information dur-

ing requirements allocation to system model elements.

Master’s thesis, Chalmers University of Technology,

Sweden.

Passera, S. (2015). Beyond the wall of text: How infor-

mation design can make contracts user-friendly. In

Design, User Experience, and Usability: Users and

Interactions. Springer International Publishing.

Runeson, P. and H¨ost, M. (2009). Guidelines for conduct-

ing and reporting case study research in software engi-

neering. Empirical Software Engineering, 14(2):131–

164.

Telea, A., Voinea, L., and Sassenburg, H. (2010). Vi-

sual tools for software architecture understanding: A

stakeholder perspective. Software, IEEE, 27(6):46–

53.

Addressing Model Complexity in Automotive System Development - Selection of System Model Elements for Allocation of Requirements

175