Addressing Model Complexity in Automotive System Development
Selection of System Model Elements for Allocation of Requirements
Grischa Liebel
1
, Andreea Olaru
2
, Henrik L¨onn
3
, Henrik Kaijser
3
, Sunith Rajendran
4
,
Urban Ingelsson
4
and Richard Berntsson Svensson
5
1
Software Engineering Division, Chalmers | University of Gothenburg, Gothenburg, Sweden
2
Semcon Sweden AB, Gothenburg, Sweden
3
Volvo Group, Advanced Technology and Research, Gothenburg, Sweden
4
Semcon Sweden AB, Link¨oping, Sweden
5
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 specification to
their own subsystem design. This is a difficult 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 filter requirements and system models to enable efficient 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 findings are that searching is used to learn about a
system, whereas filtering 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 specifications 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 inefficient.
In cognitive load theory, it is found that structure
of information is important and support for finding
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
Copyright
c
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
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 specifies how to represent a ma-
jority of the system description. A key benefit of rep-
resenting a system design in a structured information
model such as EAST-ADL is that predefined 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 specifications and for system models, thus
increasing the sense of recognition.
Prior work on tool support for source code vi-
sualisation has suggested searching and filtering as
valuable tool features (Bassil and Keller, 2001). By
employing a modelling language, the semantics can
be employed to create various types of search (filter)
queries. Queries can apply to specific 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 filter-
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
(specifically requirements analysis) to enable ef-
ficient collaborative development of complex em-
bedded systems.
present a tool prototype called Requirement Allo-
cation Assistant (RAA) that enables searching and
filtering of requirements specifications 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 filtering, 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 filtering
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 filtering, 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-
fied 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 specification 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 specified 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 first 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 define
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
filtering, to make the engineer efficient in defining 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 specific 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 studys 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
1
. 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 specification 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.
1
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 reflection of the participants were written
down in order to be used for analysing the results.
Each participant filled 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 specific
questions about the two searching and filtering 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
filled 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 findings 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 influenced 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
2
) 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
identification 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 effi-
cient.
2
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 specification (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
specification on the left and the system model on the
right.
The building blocks for RAAs key tool features
are SearchAndFilterOperation and AllocationOpera-
tion. The former is instantiated on both hierarchi-
cal views, enabling searching and filtering for the re-
quirement specification 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 specific attribute. An example is search-
ing the requirements specification 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 filtering consists of an element type
and a value for a specific attribute, such that elements
of the chosen element type are included in the result
except if the specific 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 specification 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 satisfied by
those three model elements. This allocation would
create one Satisfy element, containing the reference
to the satisfied requirement, and three satisfiedBy el-
ements, each pointing at one of the model elements
that the requirement is satisfied 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 filtering 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 find 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 filtering
are intuitive and that they help to find relevant infor-
mation. This may explain the fact that there are many
agreements to the statements. For searching and fil-
tering, one reply each voiced disagreement. This may
be due to the fact that the searching and filtering 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 filtering. 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 filter queries to be applied in combination,
as present in related tools such as DOORS
3
.
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
1 4 12
14 3
3 13 1
1
943
1 8 7 1
Strongly
Agree
Agree
Disagree
Strongly
Disagree
Undecided
Figure 6: Intuitiveness, helpfulness and decision support of
RAA.
Considering the reactions to the statements that
searching and filtering respectively helps making de-
cisions about allocation, there are more undecided
3
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 filtering 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 filtering 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 filtering. They were
asked to compare the tool features with respect to
how efficiently they could be employed to find rele-
vant information. Six experienced participants con-
sider searching to be more efficient as compared to
filtering. Comments from these participants include
that it is “more intuitive to search for what you need”
and that “searching for a specific 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 finding relevant information is more effi-
ciently done by filtering. 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 filtering equally useful
when facing high complexity. One of them stated
that “searching is useful to make a quick search and
filtering 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 first 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 benefits 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, filtering is necessary.
Lastly, the participants were asked if their prefer-
ence between tool features depends on if they were
considering a requirements specification or a system
model. Figure 7 shows how the participants an-
swered. Possible answers are “searching”, “mostly
searching”, “equal use”, “mostly filtering” or “fil-
tering”. The two columns for each possible answer
represent the answers for a requirements specifica-
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 filtering for both require-
ments specifications and system models. In fact, only
ve participants made a difference between require-
ments specifications and system models. Comments
from these five include that the choice of tool feature
should be flexible “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 specifications. It could
be that the structure of a system model can be expe-
rienced as more tangible as compared to the structure
of requirements specifications. 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 filtering on requirements spec-
ifications and system models, with the purpose to
make requirements analysis involving allocation ef-
ficient – 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 specifi-
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 identified, preferably also by
searching. For large information sets, filtering 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/Specification/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 specifica-
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