The Missing Link between Requirements Engineering

and Architecture Design for Information Systems

Karl-Heinz Krempels

1,2

, Fabian Ohler

1,2

and Christoph Terwelp

Fraunhofer Institute for Applied Information Technology, Aachen, Germany

RWTH Aachen University, Aachen, Germany

Keywords:

Software Architecture, Architecture Design, Design Methodology, Information Systems, Requirements

Engineering, Software Engineering.

Abstract:

Methodologies for the design of software architectures based on identiﬁed system requirements differ in pro-

cedure, phases, and artifacts. Furthermore, the consideration of functional and quality requirements during the

design process leads to diverse software architecture models varying in their capability regarding adaptivity

to new or changed user or quality requirements. The paper discusses a novel methodology for the design of

software architecture for information systems based on user and quality requirements. The distinctiveness

from methodologies discussed in the literature is given in the comprehensible and traceable deduction of a

domain model for the software system architecture from user requirements. The methodology was evaluated

and adapted iteratively in many R&D projects.

1 INTRODUCTION

Designing software architectures for large, distributed

information systems is a challenging and complex

task. To design the software architecture we have to

consider a high number of user and quality require-

ments, the application domain for the developed sys-

tem, and software architecture design patterns. There-

fore, we have to involve domain experts, requirements

engineers, system architects, system operators, and

users in the design process.

Due to the fact that every existing system is based

on an architectural plan and that we have a large num-

ber of existing systems, it seems that everybody is

able to design a system. However, even if this is

the case we can state that differences on architec-

tural structures exist regarding their clear functional

description of internal components, design paradigm

for interfaces, and the capability of the structure

to be used for different distributed systems design

paradigms (client-server, service orientation, agent

technology, cloud systems, etc.) for implementation

and deployment purposes. Due to the complexity

of the design task, resulting from the high number

of user and quality requirements, the diverse knowl-

edge background of the design team, and the different

design methodologies, it seems unrealistic to obtain

a comprehensible and traceable software architecture

structure with the same user and quality requirements.

So, we can feel that the design process of a good

software architecture is also a question of system

modeling, design expertise, and the system architects’

capability to express metaphorically. The result of

a design process is always a software architecture,

varying in structural readability, technical applicabil-

ity, and adaptability to new requirements. Designing

software architectures is the art of designing software

systems. Our experience in the development of infor-

mation systems lead to a methodology to design an

architecture for large information systems and plat-

forms (consisting of a business model and an infor-

mation system implementing it). The methodology

was designed based on existing ﬁndings in the litera-

ture and our expertise.

In this paper, we describe the novel methodology

for the design of architectures for large software sys-

tems. The distinctiveness from methodologies dis-

cussed in the literature is located in the comprehen-

sible and traceable deduction of a domain model for

the software system architecture from user require-

ments. To fulﬁll the given quality requirements the

resulting domain model is extended by suitable archi-

tectural design patterns for every quality requirement.

Section 2 discusses the state of the art for methodolo-

gies for requirements and software system engineer-

ing. In Section 3, the precursor method is introduced

Krempels, K., Ohler, F. and Terwelp, C.

The Missing Link between Requirements Engineering and Architecture Design for Information Systems.

DOI: 10.5220/0008381701610166

In Proceedings of the 15th International Conference on Web Information Systems and Technologies (WEBIST 2019), pages 161-166

ISBN: 978-989-758-386-5

161

which was already used and evaluated. Previous eval-

uation and validation steps are presented in Section 4.

In Section 5, the revised methodology is discussed fo-

cusing on the procedures leading to the artifacts. Sec-

tion 6 concludes the paper and addresses future eval-

uation scenarios.

2 STATE OF THE ART:

DESIGNING A SOFTWARE

SYSTEM ARCHITECTURE FOR

INFORMATION SYSTEMS

Pohl (Pohl, 2010) deﬁnes requirements engineering

as the process to ﬁnd out and record what a planned

information system should do. He distinguishes

among functional requirements, quality requirements,

and regulations (technical, legal, organizational, eth-

ical, etc.). ISO25010 (ISO/IEC, 2011) deﬁnes the

quality requirements categories functional suitability,

performance efﬁciency, compatibility, usability, reli-

ability, security, maintainability, and portability. Re-

quirement records describe a goal of the planned in-

formation system, an interaction scenario between

the user and the planned system, an internal scenario

among the components of the planned system, or a

context scenario without user and information system

interaction, but capturing the regulations. These sce-

narios can be described using natural language, struc-

tured lists (enumerations, multi-level enumerations),

tables, UML sequence diagrams, UML activity dia-

grams, or any other suitable modeling language for

event and interaction ﬂows.

Studying well known approaches from Agent

Technologies (Lind, 2001b; Lind, 2001a; Giorgini

et al., 2003; Zambonelli et al., 2003; Weiß et al.,

2009) we can state there is a common mapping pro-

cess between identiﬁed requirements for a software

system and system services. Lockemann et al. (Lock-

emann et al., 2006) deduce a design methodology fol-

lowing the divide and conquer paradigm for the de-

sign of software architectures for agent systems.

Lichter and Ludewig (Jochen Ludewig and Horst

Lichter, 2013) discuss a few architectural design

paradigms like information hiding, separation of con-

cerns, and hierarchical grouping. The paradigms are

discussed more with the objective to classify and de-

scribe resulting software architectures and not as a

how to instruction to design it.

Sommerville (Sommerville, 2016) discusses re-

quirements engineering, system modeling and ar-

chitectural design processes. System modeling is

discussed following event-driven, data-driven and

model-driven paradigms, mixing the software system

domain model and the system architecture design pro-

cess. The out-dated traditional abstraction views for

system architectures for information systems, namely

architecture in the large and architecture in the small,

are also discussed. Sommerville discusses the consid-

eration and implementation of quality requirements in

a system architecture using well known architectural

patterns for software systems for the requirement of

discourse. However, there is a missing link between

the requirements engineering phase and the software

system engineering phase for an information system,

especially a clear methodology.

Finally, in the ISO/IEC/IEEE 12207 Standard

(ISO/IEC/IEEE, 2017) describes and deﬁnes the soft-

ware life cycle processes for systems and software en-

gineering. In the architecture deﬁnition process, the

activities and tasks are deﬁned. However, for the de-

sign of the software architecture, the task is deﬁned as

Select, adapt, or develop models of the candidate ar-

chitectures of the software system. The methodology

is missing.

3 PRECURSOR METHOD

In this section a ﬁrst approach to address the identi-

ﬁed shortcomings of established methods for require-

ments engineering and software engineering is pre-

sented brieﬂy. For a more detailed discussion of the

method, see (Beutel et al., 2018b). The additional

support for the development of a reference architec-

ture was incorporated as required by the projects the

method was to be used in. An overview over the

artifacts of this process is given in Figure 1. First

actor scenarios (interactions among actors), interac-

tion scenarios (interactions between actors and the

system), and system scenarios (system internal in-

teractions) are created in story form (Alexander and

Maiden, 2004) to describe the system requirements.

Based on the scenarios, user and system tasks are de-

duced. The tasks are grouped into roles and their re-

lationships. By analyzing possible role distributions

on actors, cooperation scenarios are deﬁned. This

enables the development of a reference architecture

which can be adapted to the identiﬁed cooperation

scenarios and their hybrids. Based on the coopera-

tion scenarios, the limits of the system and points of

contact to external systems can be determined. Taking

the system limits into account, the tasks are detailed to

activity ﬂows describing the steps required to achieve

a system task. The activities are again detailed into

function ﬂows focusing on inputs and outputs of func-

tions. The components of the system architecture are

WEBIST 2019 - 15th International Conference on Web Information Systems and Technologies

162

cooperation

scenarios

tasksroles

role

relationship

model

activity

sets

system

architecture

function

sets

system

components

interfaces

actor

scenarios

system

scenarios

deployment

system

limits

interaction

scenarios

Figure 1: Artifacts of the method used in the development

of a reference architecture for open mobility platforms.

derived by grouping the functions by topic and the re-

quired information for execution. The interfaces be-

tween these components consist of all function calls

between them. The combination of components and

interfaces form the reference architecture.

4 EVALUATION SCENARIOS

In the projects econnect Germany (Krempels, 2015)

and Mobility Broker (Beutel et al., 2014; Beutel

et al., 2016), we realized the importance of separat-

ing the functional architecture of an information sys-

tem from its deployment architecture. Lacking a suit-

able method in the literature, we developed and ap-

plied the method presented in Section 3 during the

project DiMo-OMP for the development of a refer-

ence architecture for mobility platforms (Beutel et al.,

2018b). The artifacts of the development process

were published in (Steinert et al., 2018) (scenarios

and use cases) and (Beutel et al., 2018a) (roles, role

relationship model, cooperation scenarios). The re-

sulting components, system architecture, and inter-

faces are currently in the process of standardization by

the association of German transport companies (Ver-

band Deutscher Verkehrsunternehmen VDV) and will

be published accordingly. The method and its arti-

facts were evaluated during several workshops with

experts from mobility providers, potential platform

providers, large software companies, research insti-

tutes, and federal authorities (Terwelp, 2019). The

role relationship model, the identiﬁed components,

their functional description, and the identiﬁed inter-

faces were rated as very important by all participants;

they were able to match the concepts to their exist-

ing systems and use the artifacts for the planning of

future systems. The association of German transport

companies recommends the use of the resulting refer-

ence architecture in projects developing mobility plat-

forms. Summing up, our approach and results were

validated.

Afterwards, we reviewed and reﬁned the method

with a special focus on the interaction protocol design

phase. The adapted method improves the separation

of the functional from the technological aspects of the

interaction protocols. It is presented in the next sec-

tion.

5 PROPOSED METHOD

The method presented in the following aims at devel-

oping a system architecture instead of a reference ar-

chitecture. An integration of the additional steps (e.g.,

involving cooperation scenarios) might be performed

in the future. An overview of the relevant steps and

artifacts to be presented is given in Figure 2.

Step 1: Use Case Development. Create use cases

(e.g., based on scenarios in story form) and docu-

ment them in a structured way (e.g., in tabular form or

using sequence or activity diagrams). Identify qual-

ity requirements (e.g., concerning suitability, perfor-

mance, efﬁciency, compatibility, usability, reliability,

security, maintainability, and portability) and general

requirements.

Main artifacts: use cases, quality requirements, gen-

eral requirements

Step 2: System Task Identiﬁcation. Identify the

system tasks. Every interaction in the use cases in-

volves a system task. At this point, we have docu-

mented what the system offers to the user.

Main artifacts: system tasks

The Missing Link between Requirements Engineering and Architecture Design for Information Systems

163

tasks

use cases

general

requirements

quality

requirements

components activities

restrictions

system

architecture

interaction

protocols

Use Case

Development

System Task

Identification

Topical

Grouping

Task

Decomposition

Integration of

Quality and General

Requirements

Interaction

Protocol Definition

components

step

artifact

Figure 2: Steps and artifacts of the new method.

Step 3: Topical Grouping. Topically group the

tasks to components.

Main artifact: components and their tasks

Step 4: Task Decomposition. This step focuses on

the question of how the system offers its tasks. De-

compose the identiﬁed tasks into activities. An activ-

ity is characterized by its semantically graspable ef-

fect on the system. Analyze the activities with respect

to information needs and label them as internal or ex-

ternal to the component. Such a label is based on:

• does the activity belong to the component topi-

cally?

• is the information needed available within the re-

spective component when considering all of its

tasks?

Deﬁne new tasks for the new external activities to

meet the information needs or to support the com-

ponent. In case new tasks are identiﬁed, go back to

Step 3, otherwise continue with Step 5. The result

comprises a functional domain model that should be

re-usable for different contexts.

Main artifacts: set of activities and set of external

tasks

Step 5: Integration of Quality and General

Requirements. Following the ‘task dependency

graph’ resulting from the decomposition of tasks to

activities to creating new tasks, propagate the qual-

ity requirements (e.g., performance, reliability, secu-

rity, usability) and annotate tasks appropriately. Tasks

used by several other tasks (directly or indirectly)

may be annotated with different quality requirements.

Thus, the information sources should be noted, too.

The quality requirements can, for example, have im-

plications on the viable interaction type: e.g., tasks

have to provide a continuous up-to-date stream of in-

formation instead of fetching information on-demand.

Well known software architecture design pat-

terns (Sommerville, 2016; Hohpe and Woolf, 2004;

Thomas Erl, 2009; Erl, 2008) lend themselves to the

integration of quality requirements into the system ar-

chitecture. Evaluate and apply suitable patterns and

solve potentially emerging conﬂicts weighing the al-

ternatives with respect to the quality requirements.

In doing so, components may need to be anno-

tated with restrictions. These, for example, refer to

localization: components have to reside, e.g., on the

smartphone of the customer or within the own system

borders.

The application of design patterns should be struc-

tured in some manner. Aspects inﬂuencing the order

in which the requirements are addressed are, for ex-

ample, affected number of tasks, volatility of the re-

quirements in respect to future changes, and coarse-

ness of the applied patterns.

The previous design steps can be done in three dif-

ferent ways:

1. Postponing the general requirements, annotate

tasks with quality requirement and apply design

patterns to fulﬁll them.

Intermediate artifact: domain model satisfying the

functional and quality requirements

Integrate general requirements and apply design

patterns to fulﬁll them.

Beneﬁt: The intermediate domain model can be

used as a basis for different general requirements

(e.g., to develop a system used in two different

parts of the world).

2. Postponing the quality requirements, annotate

tasks with general requirement and apply design

patterns to fulﬁll them.

Intermediate artifact: domain model satisfying the

functional and general requirements

WEBIST 2019 - 15th International Conference on Web Information Systems and Technologies

164

Integrate quality requirements and apply design

patterns to fulﬁll them.

Beneﬁt: The intermediate domain model can be

used as a basis for different quality requirements

(e.g., in case the quality requirements are ex-

pected to be changing more drastically than the

general requirements).

3. Integrate general requirements and quality re-

quirements in a single step.

Beneﬁt: Prevents working with the effects of pat-

terns in intermediate domain models that are dis-

carded when considering the postponed require-

ments.

Main artifacts: quality requirements per task and re-

strictions per component; components

Step 6: Interaction Protocol Deﬁnition. Settle the

interactions to respect the requirements regarding the

tasks and their encasing components. Deﬁne inter-

action protocols documenting the component interac-

tions. In case different components impose incom-

patible requirements on a task, different interaction

pattern may have to be used alongside each other re-

sulting in multiple implementations.

Main artifacts: interaction protocols and – since the

components are known, too – the system architecture

In case the system to be designed is supposed to

provide its services to the user via a mobile appli-

cation, the ﬁrst two steps consider the interaction of

the user with this application and the system tasks are

tasks offered by the mobile application. This way,

the required ﬂexibility to decide where a component

should reside is available in the follow-up steps.

6 CONCLUSION

This paper presents our current efforts to bridge the

gap between requirements engineering and software

engineering. It presents a reﬁned method to develop a

system architecture based on requirements in a com-

prehensible and traceable way. Our work is supposed

to complement the existing literature, which describes

the requirements engineering and software engineer-

ing activities but leaves out a clear methodology for

the design of the system architecture. We thus present

the artifacts on the way to the architecture as well as

the steps needed to produce these.

Future research involves integrating the steps ad-

ditional to the development of a reference architecture

into the method. This has been deferred for evaluation

purposes, as most situations demand a system archi-

tecture. One is rarely lucky enough to be asked to

develop a reference architecture.

We are looking forward to employing and evalu-

ating the proposed method in the EU project Sharing

and Automation for Privacy Preserving Attack Neu-

tralization (SAPPAN), in the development of the next

version of the electronic fare management system ar-

chitecture for Germany and in augmenting the results

of the project DiMo-OMP with data and platform

management tasks. In our expectation, the main bene-

ﬁt is the separation of the functional and the technical

(deployment, implementation) architecture. This is to

be conﬁrmed in the upcoming evaluation. The expe-

rience gained during the planned applications of the

method will be integrated into a more detailed elabo-

ration of the process steps.

ACKNOWLEDGEMENTS

This work was funded by the German Federal Min-

istry of Economic Affairs and Energy (BMWi) for

the project Mobility Broker (Grant Id: 01ME12136),

by the German Federal Ministry of Transport and

Digital Infrastructure (BMVI) for the projects Digi-

talisierte Mobilit

at – Die Offene Mobilit

atsplattform

(DiMo-OMP) (Grant Id: 19E16007B) and Digital-

isierte Mobilit

at – Fahrzeug und Haltestelle (DiMo-

FuH) (Grant Id: 19E16009G), and by Ford Motor

Company for the Projects Autonomy Mobility Living

Lab Aachen (Grant Id: 160812).

We would like to thank to all the industrial and

academic partners from the research projects Mobil-

ity Broker, DiMo-OMP, and DiMo-FuH for their co-

operation, support, problem related discussions, and

ﬁnally their great hospitality for project meetings and

visionary discussions. Special thanks to Sjef Janssen,

Elke Fischer, Michael Bauer, Oliver Waltes, Claus

Dohmen, Peter Kehren, Johan van Ieperen, Dirk

Weißer, Bert Lange, Tobias Steinert, Werner Kohl,

Berthold Radermacher, Detlef Kuck, Markus Beutel,

Christian Samsel, David Thulke, Felix Schwinger, as

well as all related contributors and project partners.

REFERENCES

Alexander, I. F. and Maiden, N. (2004). Scenarios, Stories,

Use Cases: Through the Systems Development Life-

Cycle. Wiley Publishing, 1st edition.

Beutel, M. C., G

okay, S., Ohler, F., Kohl, W., Krempels,

K.-H., Rose, T., Samsel, C., Schwinger, F., and Ter-

welp, C. (2018a). Mobility service platforms - cross-

The Missing Link between Requirements Engineering and Architecture Design for Information Systems

165

company cooperation for transportation service in-

teroperability. In Proceedings of the 20th Interna-

tional Conference on Enterprise Information Systems,

ICEIS 2018, Funchal, Madeira, Portugal, March 21-

24, 2018, Volume 1., pages 151–161.

Beutel, M. C., G

okay, S., Jakobs, E., Jarke, M., Kasugai,

K., Krempels, K., Ohler, F., Samsel, C., Schwinger, F.,

Terwelp, C., Thulke, D., Vogelsang, S., and Zieﬂe, M.

(2018b). Information system development for seam-

less mobility. In Donnellan, B., Klein, C., Helfert,

M., and Gusikhin, O., editors, Smart Cities, Green

Technologies and Intelligent Transport Systems - 7th

International Conference, SMARTGREENS, and 4th

International Conference, VEHITS 2018, Funchal,

Madeira, Portugal, March 16-18, 2018, Revised Se-

lected Papers, volume 992 of Communications in

Computer and Information Science, pages 141–158.

Springer.

Beutel, M. C., G

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

sel, C., and Terwelp, C. (2014). Product oriented in-

tegration of heterogeneous mobility services. In In-

telligent Transportation Systems (ITSC), 2014 IEEE

17th International Conference On, pages 1529–1534.

IEEE.

Beutel, M. C., G

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

sel, C., Terwelp, C., and Wiederhold, M. (2016). Het-

erogeneous travel information exchange. In Internet

of Things. IoT Infrastructures: Second International

Summit, IoT 360

◦

2015, Rome, Italy, October 27-29,

2015, Revised Selected Papers, Part II, pages 181–

187. Springer.

Erl, T. (2008). SOA – Principles of Service Design. Prentice

Hall.

Giorgini, P., Kolp, M., Mylopoulos, J., and Pistore, M.

(2003). The tropos methodology: an overview. In

Bergenti, F., Gleizes, M.-P., and Zambonelli, F., ed-

itors, Methodologies and Software Engineering For

Agent Systems, pages 1–20, New York. Kluwer Aca-

demic Publishing.

Hohpe, G. and Woolf, B. (2004). Enterprise Integration

Patterns. Addison-Wesley.

ISO/IEC (2011). Systems and software engineering – sys-

tems and software quality requirements and evalua-

tion (SQuaRE) – system and software quality models.

ISO/IEC 25010, European Committee for Standard-

ization.

ISO/IEC/IEEE (2017). Systems and software engineering –

software life cycle processes. ISO/IEC/IEEE 12207,

European Committee for Standardization.

Jochen Ludewig and Horst Lichter (2013). Software En-

gineering: Grundlagen, Menschen, Prozesse, Tech-

niken. Dpunkt.Verlag GmbH.

Krempels, K.-H., editor (2015). Abschlussbericht der

RWTH Aachen zum Verbundvorhaben ,,econnect Ger-

many”, Stadtwerke machen Deutschland Elektromo-

bil, von Aachen bis Leipzig, vom Allg

au bis Sylt. Ap-

primus.

Lind, J. (2001a). The conceptual framework of massive.

In Lind, J., editor, Iterative Software Engineering for

Multiagent Systems: The MASSIVE Method, volume

1994 of Lecture Notes in Computer Science, page 97.

Springer.

Lind, J. (2001b). Massive views. In Lind, J., editor, It-

erative Software Engineering for Multiagent Systems:

The MASSIVE Method, volume 1994 of Lecture Notes

in Computer Science, page 121. Springer.

Lockemann, P. C., Nimis, J., Braubach, L., Pokahr, A., and

Lamersdorf, W. (2006). Architectural design. In Kirn,

S., Herzog, O., Lockemann, P. C., and Spaniol, O.,

editors, Multiagent Engineering, Theory and Applica-

tions in Enterprises., pages 405–429. Springer.

Pohl, K. (2010). Requirements Engineering - Fundamen-

tals, Principles, and Techniques. Springer, Heidelberg

New York.

Sommerville, I. (2016). Software Engineering. Pearson, 9

edition.

Steinert, T., Koreng, R., Mayas, C., Cherednychek, N.,

Dohmen, C., H

orold, S., Krempels, K.-H., Kehren,

P., Kohl, W., Ohler, F., Terwelp, C., van Ieperen, J.,

and Wiegand, A. (2018). Deﬁnition und Dokumen-

tation der Nutzeranforderungen an eine offene Mo-

bilit

atsplattform.

Terwelp, C. (2019). Development of a Reference Model for

Mobility Platforms. PhD thesis.

Thomas Erl (2009). SOA – Design Patterns. Prentice Hall.

Weiß, G., Pomberger, G., Beer, W., Buchgeher, G.,

Dorninger, B., Pichler, J., Pr

ahofer, H., Ramler, R.,

Stallinger, F., and Weinreich, R. (2009). Software

Engineering – Processes and Tools, pages 157–235.

Springer Berlin Heidelberg, Berlin, Heidelberg.

Zambonelli, F., Jennings, N., and Wooldridge, M. (2003).

Developing multiagent systems: the gaia methodol-

ogy. ACM Transactions on Software Engineering and

Methodology, 12(3).

WEBIST 2019 - 15th International Conference on Web Information Systems and Technologies

166