Requirements Engineering Aspects of a Geographically Distributed

Architecture

Maria Spichkova and Heinz Schmidt

RMIT University, Melbourne, Australia

Keywords:

Requirements Engineering, Geographically Distributed Development, Software and Systems Engineering.

Abstract:

We present our ongoing work on requirements speciﬁcation and analysis for the geographically distributed

software and systems. Developing software and systems within/for different countries or states or even

within/for different organisations means that the requirements to them can differ in each particular case. These

aspects naturally impact on the software architecture and on the development process as a whole. The chal-

lenge is to deal with this diversity in a systematic way, avoiding contradictions and non-compliance. In this

paper, we present a formal framework for the analysis of the requirements diversity, which comes from the

differences in the regulations, laws and cultural aspects for different countries or organisations. The frame-

work also provides the corresponding architectural view and the methods for requirements structuring and

optimisation.

1 INTRODUCTION

Globalisation of the software and systems develop-

ment offer great opportunities for the development

industry. However, they also mean new challenges

coming from the diversity of requirements on dif-

ferent locations, especially in the sense of legal re-

quirements and regulatory compliance. The reasons

for the differences in software and systems require-

ments within different countries, states and organisa-

tions are the cultural and economics diversity, as well

as the diversity in standards, legal regulations and

laws. These challenges have some similarities with

the problems of product customisation and the devel-

opment of product lines, but the core of the architec-

ture requirements is different due the speciﬁc nature

of the relations between the requirements for the geo-

graphically and organisationally distributed develop-

ment and application of software.

Requirements engineering (RE), i.e., require-

ments elicitation, evaluation, speciﬁcation, and de-

sign producing the functional and non-functional re-

quirements, is one of the key disciplines in the soft-

ware development domain. It has a critical impact on

the product’s quality. Requirements-related errors are

often a major cause of the delays in the product de-

livery and development costs overruns, cf. e.g., (van

Lamsweerde, 2008; Pretschner et al., 2007; Rinke and

Weyer, 2007). There are several methodologies on

development of software systems from requirements,

also enclosing CASE tools support, e.g., (Broy and

Slotosch, 2001; H

olzl et al., 2010; Spichkova, 2011;

Spichkova et al., 2012). The RE task is challeng-

ing even in the case of a local (non-distributed) de-

velopment of a product for application within/for a

single country or organisation, i.e. where the sys-

tem acts within an environment with a uniform set

of standards, legal regulations, etc. Thus, in the case

of global development we need to have an approach

that deals the corresponding issues in a systematic

and scalable way. There are several approaches that

check requirements for compliance (Breaux et al.,

2008; Maxwell and Anton, 2009; Siena et al., 2009b)

or ensuring the compliance of the outcomes of busi-

ness processes against outcome-focused regulations

(Yin et al., 2013). We are going a step further, aiming

to cover the RE aspects for the geographically dis-

tributed development and application. To minimise

the overall effort while specifying and also ensuring

required software and system requirements in a global

development context, we elaborated a logical frame-

work. The framework provides methodological struc-

turing the requirements for the geographically dis-

tributed product development and application, as well

as developing of the corresponding global architec-

ture requirements. The purposed approach will help

to analyse the relations between requirements and to

trace requirements’ changes in a global context.

276

Spichkova M. and Schmidt H..

Requirements Engineering Aspects of a Geographically Distributed Architecture.

DOI: 10.5220/0005465802760281

In Proceedings of the 10th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE-2015), pages 276-281

ISBN: 978-989-758-100-7

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

Outline. The rest of the paper is structured as fol-

lows: Section 2 overviews related work on integration

architecture and RE as well as on regulatory com-

pliance within the ﬁeld of software engineering. In

Section 3 we present our view on the architectural

dependencies for the requirements for a global de-

velopment and geographically distributed product ap-

plication. In Section 4 we introduce the core ideas

of requirements structuring process and requirements

analysis in a global context. Section 5 concludes the

paper by highlighting the main contributions of the

paper and describing the future work directions.

2 RELATED WORK

Glinz (2007) surveyed the existing deﬁnitions of

non-functional requirements (NFR), highlights and

discusses the problems with the current deﬁnitions,

and contributes concepts for overcoming these prob-

lems. In our work, we are mainly focusing on NFR in

the sense of legal aspects and regulatory compliance,

also taking into account human factor aspects of the

requirement modelling (Spichkova, 2012).

Integrating Architecture and Requirements En-

gineering. The main purpose of the requirements

speciﬁcation (RS) is to elicit and to document the

given problem (product/software/system) using con-

cepts from the problem domain, i.e. on the RE phase

we are speaking only on the problem statement. In

contrast to this, the aim of a software architecture

(SA) is to design a draft of the solution for the prob-

lem described in the RS, at a high level of abstrac-

tion. Thus, there are tight interdependencies between

functional/non-functional requirements and architec-

tural elements, which makes the integration of the RE

and architecture crucial (In et al., 2001; Egyed et al.,

2001). The results of the empirical study conducted

by Ferrari and Madhavji (2007) also have shown that

the software architects with the knowledge and expe-

rience on RE perform better, in terms of architectural

quality, than those without these knowledge end ex-

perience.

Nuseibeh (2001) described a spiral model-like de-

velopment cycle of requirements and architecture.

Pohl and Sikora (2007) went further and have pro-

vided methodical guidance for the co-design. An

experience-based approach for integration architec-

ture and RE is presented by Paech et al. (2003).

This approach that supports the elicitation, speciﬁca-

tion and design activity by providing experience in

terms of questionnaires, checklists, architectural pat-

terns and rationale that have been collected in earlier

successful projects and that are presented to develop-

ers to support them in their task.

The REMseS approach (Braun et al., 2014) aims

at supporting RE processes for software-intensive em-

bedded systems. The authors introduced fundamen-

tal principles of the approach and gave a structural

overview over the guide and the tool support.

In contrast to these approaches, our research cov-

ers the regulatory compliance aspects and is oriented

on legal requirements representation and analysis in

the scope of the global software development.

Regulatory Compliance. A survey of efforts to sup-

port the analysis of legal texts in the context of soft-

ware engineering is presented in (Otto and Anton,

2007). The authors discuss the role of law in require-

ments and identify several key elements for any sys-

tem to support the analysis of regulatory texts for re-

quirements speciﬁcation, system design, and compli-

ance monitoring. Nekvi et al. (2011) also identiﬁed

key artefacts, relationships and challenges in the com-

pliance demonstration of the systems requirements

against engineering standards and government regu-

lations, also providing This work provides a basis for

developing compliance meta-model.

Kiyavitskaya et al. (2008) investigated the prob-

lem of designing regulation-compliant systems and,

in particular, the challenges in eliciting and manag-

ing legal requirements. Breaux et al. (2006) reported

on an industry case study in which product require-

ments were speciﬁed to comply with the U.S. federal

laws. Maxwell and Anton (2009) performed a case

study using our approach to evaluate the iTrust Medi-

cal Records System requirements for compliance with

the U.S. Health Insurance Portability and Account-

ability Act. Siena et al. (2009a) presented the guiding

rules and a framework for for deriving compliant-by-

construction requirements, also focusing on the U.S.

federal laws.

In contrast to these approaches, our research is ori-

ented on global software development, dealing with

diversity in standards, legal regulations, etc. within

different countries and organisations.

3 GEOGRAPHICALLY

DISTRIBUTED

ARCHITECTURE

Suppose that we have to develop M products (soft-

ware components/systems) P

,...,P

. We denote the

set of products by P. Each product P

, 1 ≤ i ≤ M has

the corresponding set of requirements R

. However,

RequirementsEngineeringAspectsofaGeographicallyDistributedArchitecture

277

in the case the legal requirements and the regulatory

compliance are taken into account, the set of require-

ments will depend on the regulations and laws of the

country/state the product is developed for.

In the case of global and remote develop-

ment (Spichkova et al., 2013), we have to deal with

cultural and economics diversity, which also has an

inﬂuence on the software and system requirements.

Suppose the products P

,...,P

are developed for

application in N countries C

,...,C

with the corre-

sponding

• regulations/laws RegulC

,...,RegulC

and

• cultural/economics, i.e., human factor (Borchers,

2003), inﬂuences HFC

,...,HFC

We denote the set of requirements to the product P

valid for the country C

by R

. The complete set of

requirements to the product P

is then deﬁned by

[

j=1

(1)

The sets of requirements R

might be different for

each product P

in different countries, i.e. R

is not

necessary equal to R

for the case j1 6= j2.

Figure 1 presents the corresponding architectural

dependencies for the requirements based on the regu-

lations and laws of the country C

. We divide the set

of requirements R

in two (disjoint) subsets. For each

of these subsets, we have to distinguish two separate

parts: general and country-speciﬁc:

• RL

denotes the requirements based or depend-

ing on the regulations and laws, which could

be country/state/organisation-speciﬁc. Require-

ments of this kind does not depend on the human

factor related aspects.

= RLgeneral

∪ RLspeci f ic

(2)

RLgeneral

= · · · = RLgeneral

(3)

• RFN

denotes the functional and non-functional

requirements that are independent from the regu-

lations and laws, but may depend on the human

factor related aspects, which could be country-

speciﬁc.

RFN

= RFNgeneral

∪ RFNspeci f ic

(4)

RFNgeneral

= · · · = RFNgeneral

(5)

For simplicity, we denote the general subsets by

RLgeneral

and RFNgeneral

respectively.

RPM

RP1

...

RCj

RLCj* RLCj

min

RegulCj

RFNP1 RFNPM

RLCj

RFNgeneralP1

RFNspeciﬁcPM

RFNspeciﬁcP1

RFNgeneralPM

HFCj

RLP1

RLgeneralP1

RLspeciﬁcP1

RLPM

RLgeneralPM

RLspeciﬁcPM

CjCj

Figure 1: Architectural dependencies for the requirements

based on the regulations and laws of the country C

Given the set RL

ALL

be the set of all legal require-

ments of the country C

, we can see the set RL

as a

projection of RL

ALL

to the product P

= RL

ALL

(6)

On this basis, we can say that the set of legal re-

quirements for the country C

related to the develop-

ment of products P

,...,P

is deﬁned as a union over

the corresponding requirements sets:

[

i=1

(7)

However, it is not efﬁcient to base the requirements

analysis for the geographically distributed develop-

ment on the sets RL

• The sets RegulC

,...,RegulC

could have a joint

subset Regul of the regulations/laws that are equal

for all countries C

,...,C

Regul = RegulC

∩ ··· ∩ RegulC

(8)

We denote for each RegulC

the corresponding

compliment to Regul (i.e. the country-speciﬁc

subset) by RegulC

= RegulC

\ Regul.

It it is important to identify these subsets as well

as the corresponding subsets of RL

,...,RL

, as

this helps to trace the RL-requirements’ changes

more efﬁciently.

ENASE2015-10thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

278

• Some requirements in RL

can be stronger ver-

sions of another requirements from this set. For

example, if req

∈ RL

and req

∈ RL

are not

equal, they both will belong to RL

, even if req

is a reﬁnement of req

. In this case, we call

req

a weaker version of req

and denote it by

req

Thus we need to have a structured architecture for the

legal requirements on the products P

,...,P

. For

this reason we build the corresponding sets RL

min

and RL

∗

, where RL

∗

denotes the strongest set of

legal requirements for the country C

(related to the

concrete products development), and RL

min

denotes

the set of legal requirements that should be fulﬁlled

by all the products P

,...,P

developed in the coun-

try C

min

= RL

∩ ··· ∩ RL

(9)

∗

is an optimisation of RL

, where all the weaker

versions of the requirements are removed using the

algorithm presented in Section 4.

4 REQUIREMENTS

STRUCTURING AND

ANALYSIS

In our framework, we perform the analysis based

on the optimised views on the requirements sets,

focusing on the regulatory/legal aspects. First of

all, we analyse the sets of relevant regulations

RegulC

,...,RegulC

. Three cases are possible:

• In the case Regul =

0, we have the situation when

the regulations are completely different for all

,...,C

. This also implies that RLgeneral

for all P

, 1 ≤ i ≤ M, i.e., RL

= RLspeci f ic

We have to trace all the sets RLspeci f ic

sepa-

rately: changes in RegulC

do not inﬂuence on the

global development process.

• The regulations are not completely identical for

,...,C

, but Regul 6=

0. If we can rely

on the statical nature of this requirements (i.e.

that these requirements do not change over the

time of the development and the application),

it would be beneﬁcial to apply the component-

based development paradigm (Crnkovi

c et al.,

2007): the requirements RLgeneral

or at

least the major part of them should corre-

spond to architectural components(s) that are

separate from the components corresponding to

RLspeci f ic

,...,RLspeci f ic

. However, if any

of regulations sets RegulC

has some changes, this

would inﬂuence on the development process as a

whole.

• In the case Regul = RegulC

= ··· = RegulC

we have the situation when the regulations are

completely identical for all C

,...,C

, which also

means RL

= RLgeneral

. If we can rely on

the statical nature of this requirements, we have

the simplest case for the development process:

we develop a single component (system) from

RLgeneral

to apply if for all C

,...,C

Thus, RL

min

is deﬁned on basis of Regul. The

corresponding product-centred view on the architec-

tural dependencies is presented on Figure 2. The al-

gorithm of constructing R

min

is trivial: we check all

the requirements in R

,...,R

to ﬁnd out those ele-

ments, which belong to each of the sets.

RPi

...

RegulC1' RegulCN'

HFC1

HFCN

RLgeneralPi

RNFgeneralPi

Regul

C1 CN

RPi*

RLspeciﬁcPi

RNFspeciﬁcPi

RLspeciﬁcPi

RNFspeciﬁcPi

Figure 2: Architectural dependencies for requirements

speciﬁed for the product P

Our approach is based on the ideas of reﬁnement-

based speciﬁcation and veriﬁcation. On the formal

level, we need to deﬁne which exactly kind of a reﬁne-

ment we mean, e.g., behavioural, interface or condi-

tional reﬁnement (Spichkova, 2008; Broy and Stølen,

2001). However, on the level of the logical architec-

ture and modelling of the dependencies between the

(sets of) requirements, we can abstract from these de-

tails.

In this paper, we present a simpliﬁed version of

the optimisation algorithm. It can be applied to build

the set RL

∗

on the basis of RL

(cf. Figure 1

for the country-centred view), to build the set R

∗

(cf. Figure 2 for product-centred view) as well as to

build the strongest global set of requirements R

∗

over

,...,C

(cf. Figure 3). We start the algorithm with

an empty set and build it up iteratively from the ele-

ments of the corresponding set.

RequirementsEngineeringAspectsofaGeographicallyDistributedArchitecture

279

...

RP1

RPM...

RC1

RC1* RC1

min

RP1

RPM...

RCN

RCN* RCN

R* R

min

...

RegulC1 RegulCN

HFC1 HFCN

RP1 RPM

Figure 3: Requirements structuring for the distributed de-

velopment of products P

,... ,P

Step 0: RL

∗

0, X = RL

Step 1: If X 6=

0, the RL

∗

is complete, otherwise

choose a requirement req ∈ X:

• If a copy of req already belongs to RL

∗

or r is

a weaker version of any requirement from RL

∗

the set should not be updated on this iteration:

(req ∈ RL

∗

∨ ∃y ∈ RL

∗

: req y) ⇒

∗

is unchanged

• If r is a stronger version of any requirement(s)

from RL

∗

, we add r to RL

∗

and remove all the

weaker requirements:

∃y

,...,y

∈ RL

∗

: y

req ∧ ··· ∧ y

req) ⇒

∗

= (RL

∗ ∪ req)\ {y

,...,y

}

• If r does not belong to RL

∗

and is neither

weaker nor stronger version of any requirement

from RL

∗

, we add it to RL

∗

and proceed the

procedure with the next requirement from RL

(req /∈ RL

∗

∧

6 ∃y ∈ RL

∗

: (req y ∨ y req) ⇒

∗

= (RL

∗

∪ req)

Step 2: The req element is deleted from the set X:

X = X \ req.

Steps 1 and 2 are then repeated until X =

While identifying RL

min

we will analyse which

products’ subcomponents can be build once and then

reused for the whole product set P

,...,P

. On

this basis, we will have more efﬁcient process for

the global software and systems development, also

having an efﬁcient tracing of requirements changes

that might come from the changes in the regula-

tions and laws for countries C

,...,C

. For example,

changes in RegulC

imply changes in RLspeci f ic

only, which means that only the country-speciﬁc part

of the architectural components for C

is affected,

where any changes in Regul might inﬂuence the

global architecture.

While identifying RL∗ we will obtain the global

view on the the products’ requirements, which is not

overloaded with the variants of the similar require-

ments, where some requirements are just weaker ver-

sions of other.

5 CONCLUSIONS

This paper introduces our ongoing work on require-

ments speciﬁcation and analysis for the geographi-

cally distributed software and systems. Developing

software and systems within/for different countries or

states or even within/for different organisations means

that the requirements to them can differ in each partic-

ular case, which naturally impacts on the software ar-

chitecture and on the development process as a whole.

Dealing with this diversity and avoiding contradic-

tions and non-compliance, is a very challenging and

complicated task. A systematic approach is required.

For this reason, we created a formal framework for

the analysis of the software requirements diversity,

which comes from the differences in the regulations

for different countries or organisations. In this paper,

we (i) presented our architectural dependency model

for the requirements on the distributed development

and application, (ii) introduced the core ideas of the

corresponding requirements structuring process and

requirements analysis in a global context. (iii) dis-

cussed the the research and industrial challenges in

this ﬁeld, as well as discussed our solutions and how

they are related to the existing approaches.

Future Work. In our future work we will investigate

how to extend the presented ideas to the software and

systems development that involves hierarchical de-

pendencies between the sets of regulations/laws. This

could be the case if see the set C

,...,C

not only as

the set of countries/states, but also as a set of organ-

isations having different internal regulations. Then

we have to deal with hierarchical dependencies with

many levels, e.g., (1) organisational regulations, (2)

state’s regulations and laws, (3) country’s regulations

and laws, where we also need to check which of the

regulations are applicable in each particular case.

ENASE2015-10thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

280

REFERENCES

Borchers, G. (2003). The software engineering impacts

of cultural factors on multi-cultural software develop-

ment teams. In International Conference on Software

Engineering, pages 540–545. IEEE Computer Soci-

ety.

Braun, P., Broy, M., Houdek, F., Kirchmayr, M., Mller,

M., Penzenstadler, B., Pohl, K., and Weyer, T.

(2014). Guiding requirements engineering for

software-intensive embedded systems in the automo-

tive industry. Computer Science - Research and De-

velopment, 29(1):21–43.

Breaux, T., Anton, A., Boucher, K., and Dorfman, M.

(2008). Legal requirements, compliance and practice:

An industry case study in accessibility. In IEEE Conf.

on Requirements Engineering, pages 43–52.

Breaux, T., Vail, M., and Anton, A. (2006). Towards regula-

tory compliance: Extracting rights and obligations to

align requirements with regulations. In IEEE Interna-

tional Conf. on Requirements Engineering, pages 49–

58.

Broy, M. and Slotosch, O. (2001). From requirements to

validated embedded systems. In Henzinger, T. A. and

Kirsch, C. M., editors, Embedded Software, volume

2211 of LNCS, pages 51–65. Springer.

Broy, M. and Stølen, K. (2001). Speciﬁcation and Develop-

ment of Interactive Systems: Focus on Streams, Inter-

faces, and Reﬁnement. Springer.

Crnkovi

c, I., Schmidt, H., Stafford, J., Heineman, G., and

Wallnau, K. (2007). Component-based software engi-

neering of trustworthy embedded systems. Journal of

Systems and Software, 80(5):641–642.

Egyed, A., Grnbacher, P., and Medvidovic, N. (2001). Re-

ﬁnement and Evolution Issues in Bridging Require-

ments and Architecture - The CBSP Approach. In

From Software Requirements to Architectures, pages

42–47.

Ferrari, R. and Madhavji, N. (2007). The impact of re-

quirements knowledge and experience on software

architecting: An empirical study. In The Work-

ing IEEE/IFIP Conference on Software Architecture,

pages 16–16.

Glinz, M. (2007). On non-functional requirements. In IEEE

Conf. on Requirements Engineering, pages 21–26.

olzl, F., Spichkova, M., and Trachtenherz, D. (2010). Aut-

oFocus Tool Chain. Technical Report TUM-I1021,

TU M

unchen.

In, H., Boehm, B., Rodger, T., and Deutsch, M. (2001). Ap-

plying winwin to quality requirements: a case study.

In Int. Conf. on Software Engineering, pages 555–564.

Kiyavitskaya, N., Krausova, A., and Zannone, N. (2008).

Why eliciting and managing legal requirements is

hard. In Workshop on Requirements Engineering and

Law, pages 26–30.

Maxwell, J. and Anton, A. (2009). Checking existing re-

quirements for compliance with law using a produc-

tion rule model. In Workshop on Requirements Engi-

neering and Law, pages 1–6.

Nekvi, R., Ferrari, R., Berenbach, B., and Madhavji, N.

(2011). Towards a compliance meta-model for system

requirements in contractual projects. In Workshop on

Requirements Engineering and Law, pages 74–77.

Nuseibeh, B. (2001). Weaving together requirements and

architectures. Computer, 34(3):115–117.

Otto, P. and Anton, A. (2007). Addressing legal require-

ments in requirements engineering. In IEEE Conf. on

Requirements Engineering, pages 5–14.

Paech, B., von Knethen, A., Drr, J., Bayer, J., Kerkow,

D., Kolb, R., Trendowicz, A., Punter, T., and Dutoit,

A. (2003). An experience-based approach for inte-

grating architecture and requirements engineering. In

Workshop on Software Requirements to Architectures,

pages 142–149.

Pohl, K. and Sikora, E. (2007). Structuring the co-design of

requirements and architecture. In Requirements Engi-

neering: Foundation for Software Quality, pages 48–

62. Springer.

Pretschner, A., Broy, M., Kruger, I. H., and Stauner, T.

(2007). Software engineering for automotive systems:

A roadmap. In Future of Software Engineering, pages

55–71. IEEE Computer Society.

Rinke, T. and Weyer, T. (2007). Deﬁning reference mod-

els for modelling qualities: How requirements engi-

neering techniques can help. In Sawyer, P., Paech,

B., and Heymans, P., editors, Requirements Engineer-

ing: Foundation for Software Quality, pages 335–340.

Springer.

Siena, A., Perini, A., Susi, A., and Mylopoulos, J. (2009a).

A meta-model for modelling law-compliant require-

ments. In Workshop on Requirements Engineering

and Law, pages 45–51.

Siena, A., Perini, A., Susi, A., and Mylopoulos, J. (2009b).

Towards a framework for law-compliant software re-

quirements. In International Conference on Software

Engineering. Companion Volume, pages 251–254.

Spichkova, M. (2008). Reﬁnement-based veriﬁcation of

interactive real-time systems. ENTCS, 214(0):131 –

157. BAC-FACS Reﬁnement Workshop.

Spichkova, M. (2011). Architecture: Requirements + De-

composition + Reﬁnement. Softwaretechnik-Trends,

31(4).

Spichkova, M. (2012). Human Factors of Formal Methods.

In IADIS Interfaces and Human Computer Interaction

(IHCI 2012), pages 307–310. IADIS Press.

Spichkova, M., H

olzl, F., and Trachtenherz, D. (2012).

Veriﬁed system development with the autofocus tool

chain. In Workshop on Formal Methods in the Devel-

opment of Software, EPTCS, pages 17–24.

Spichkova, M., Schmidt, H., and Peake, I. (2013). From

abstract modelling to remote cyber-physical integra-

tion/interoperability testing. In Improving Systems

and Software Engineering Conference.

van Lamsweerde, A. (2008). Requirements engineering:

From craft to discipline. In International Symposium

on Foundations of Software Engineering, SIGSOFT

’08/FSE-16, pages 238–249. ACM.

Yin, Q., Madhavji, N., and Pattani, M. (2013). Eros: an ap-

proach for ensuring regulatory compliance of process

outcomes. In Workshop on Requirements Engineering

and Law, pages 21–24.

RequirementsEngineeringAspectsofaGeographicallyDistributedArchitecture

281