Requirements Engineering for Global Systems: Cultural, Regulatory and

Technical Aspects

Maria Spichkova and Heinz Schmidt

School of Science, RMIT University, Melbourne, Australia

Keywords:

Software Engineering, Requirements Engineering, Cultural Aspects, Formal Methods.

Abstract:

In this paper we present a formal framework for analysis and optimisation of the requirements speciﬁcations

of systems developed to apply in several countries. As different countries typically have different regula-

tions/laws as well as different cultural restrictions, the corresponding speciﬁc requirements might differ in

each particular case. Our framework provides a basis for (1) systematic and formal analysis of the diver-

sity and interdependencies within the sets of the requirements, to avoid non-compliance, contradictions and

redundancies; (2) corresponding systematic process for change management in the case of global system de-

velopment.

1 INTRODUCTION

Software solutions are applied in many areas of our

life. In many cases, users of a system have diverse

backgrounds, both cultural and technical. The di-

versity is especially high if the system is developed

for application in several organisations or countries.

In that case, the overall set of requirements expands

by the diverse sets of organisation or country spe-

ciﬁc requirements, regulations and restrictions. More-

over, cultural diversity might lead to the diversity of

culture-related requirements also within a single or-

ganisation or country.

Requirements engineering (RE) activities have a

critical impact on whether the developed system will

satisfy user needs as well as regulations and laws of

the countries/organisations, where the system will be

applied. RE activities provide a basis for all other

activities within the software development life cycle,

such as testing, design, architecture, etc., and the er-

rors within them are a major cause of the issues with

the delivery of the product on time as well as of the

budget overruns, see e.g., (van Lamsweerde, 2008;

Pretschner et al., 2007; Rinke and Weyer, 2007).

Thus, the task is already complicated even when con-

ducting RE activities for a system that is developed

for application within a single country or organisa-

tion. When the system should rely on the standards,

legal regulations, cultural aspects, etc. that are not

uniform, a corresponding solution is required to deal

with the related issues in a systematic and scalable

way, see e.g., (Prikladnicki et al., 2003).

A number of studies demonstrated that the cul-

tural diversity has to be taken into account to make

the system sustainable and applicable in a global con-

text, see (Alsanoosy et al., 2018a; Alsanoosy et al.,

2018b; Borchers, 2003; Govender et al., 2016; Shah

et al., 2012). In the proposed approach, we investigate

how to manage the diversity of cultural and technical

aspects (as well as the correlations between them).

The core goals of the proposed framework are

(1) to optimise the process of requirements speciﬁ-

cation and the corresponding change management, as

well as (2) to ensure that the system requirements are

fulﬁlled in a global development context, where also

diversity in the cultural and regulatory requirements is

taken into account. The framework provides method-

ological structuring of the requirements for the geo-

graphically distributed product development and ap-

plication. The purposed approach will

• help to analyse the relations between require-

ments formally,

• facilitate the tracing of requirements’ changes in

a global context, and

• provide an input for the TOPSIS (Technique for

Order of Preference by Similarity to Ideal So-

lution, see (Mairiza et al., 2013; Mairiza et al.,

2014)), which would allow to identify the most

preferable solutions with respect to the conﬂicting

requirements.

Outline: The rest of the paper is organised as fol-

Spichkova, M. and Schmidt, H.

Requirements Engineering for Global Systems: Cultural, Regulatory and Technical Aspects.

DOI: 10.5220/0007781105630569

In Proceedings of the 14th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2019), pages 563-569

ISBN: 978-989-758-375-9

563

...

L1 LN

Cultural

Aspects

Cultural

Aspects

RLG

RCG

RLSN

RCSN

RLS1

RCS1

Cultural

Aspects

min

RFG

RFS1

RFSN

Software System

RL RF

RC* RL* RF*

min

TOPSIS

Figure 1: RE framework: Requirements structuring based on the cultural, legal and technical aspects.

lows. Sections 2 presents the proposed framework.

Related work is introduced in Section 3. Section 4

summarises the paper and the future work directions.

2 COVERING THE DIVERSITY

In the case of global development, the software sys-

tem requirements have to we have to cover not only

the technical aspects, but also aspects related to the

diversity in culture and country-speciﬁc regulations.

Figure 1 presents a logical architecture of the pro-

posed framework for methodological requirements

structuring based on the cultural, legal and technical

aspects.

Let us assume that we have to develop a software

system for application in N countries (or states, organ-

isations, etc.), which we denote S

, . . . , S

. With each

country/state/organisation S

, 1 ≤ i ≤ N, we associate

• set L

of regulations/laws, and

• set C

of cultural inﬂuences.

• set R

of functional and nonfunctional require-

ments to be valid for the country S

, which de-

pends on the sets Reg

and C

The complete set of requirements is then deﬁned by

R =

[

j=1

R might contain inconsistencies, i.e. some require-

ments R might contradict to each other, which should

be identiﬁed on the early development phases. Thus,

in the case i 6= j, we might have a situation where

• L

6= L

, and/or

• C

6= C

which will also imply R

6= R

. This also means that

we can divide the sets L

and C

into two subsets each

to represent

• general components, i.e., regulations/laws and

cultural inﬂuences common for all countries S

1 ≤ i ≤ N:

– LG

, where LG

= LG

for any 1 ≤ i, j ≤ N.

– CG

, where CG

= CG

for any 1 ≤ i, j ≤ N.

In both cases, we can also omit the bottom index

for simplicity and denote the corresponding sets

by LG and CG.

• speciﬁc components, i.e., regulations/laws and

cultural inﬂuences that are speciﬁc for some of the

countries S

, 1 ≤ i ≤ N:

ENASE 2019 - 14th International Conference on Evaluation of Novel Approaches to Software Engineering

564

– LS

, so that for all sets LS

, 1 ≤ i ≤ N, holds

∀x ∈ LS

. ∃1 ≤ i ≤ N. ∃y ∈ L S

. contr(x, y)

– CS

, so that for all sets CS

, 1 ≤ i ≤ N, holds

∀x ∈ CS

. ∃1 ≤ i ≤ N. ∃y ∈ CS

. contr(x, y)

The predicated contr(x, y) denotes the fact that

there is a contradiction between x and y , which

are in two regulations/laws or cultural inﬂu-

ences.

Thus, for all 1 ≤ i ≤ N holds

= LG ∪ LS

= CG ∪CS

Respectively, the set of functional and nonfunctional

requirements R

to be valid for the country S

can be

divided in three (disjoint) subsets.

• set RL

of regulations/laws-based requirements,

where some requirements might be country-

speciﬁc in the case the corresponding regula-

tions/laws are country-speciﬁc. Thus, we can

specify it by

= RLG ∪ RLS

(1)

where

– RLG is a subset of regulations/laws-based re-

quirements elaborated on the basis of LG, i.e.,

∀r ∈ RLG. elaboratedFrom(r, RLG)

– RLS

is a subset elaborated on the baseis of LS

i.e.,

∀r ∈ RLS

. elaboratedFrom(r, RLS

)

• set RC

denotes the requirements reﬂecting on cul-

ture and economics related aspects, which could

be country-speciﬁc:

= RCG ∪ RCS

(2)

where

– RCG is a subset of culture-based requirements

elaborated on the basis of CG, i.e.,

∀r ∈ RCG. elaboratedFrom(r, RCG)

– RCS

is a subset elaborated on the basis of CS

i.e.,

∀r ∈ RCS

. elaboratedFrom(r, RCS

)

• RF

denotes the functional and non-functional re-

quirements on the system. These requirements do

not depend on the cultural aspects or the regula-

tions and laws directly, but might depend on them

indirectly, via the restrictions from the require-

ments RL

and RC

= RFG ∪ RFS

(3)

We have to build the corresponding ontologies and

structure the sets of requirements taking into account

the country-speciﬁc aspects. In the case RC contains

a requirement that is a stronger version of another re-

quirement from RC, i.e. is a reﬁnement of it (denoted

by ), the weaker versions should be removed. For

example, r

, r

∈ RC

, r

6= r

, r

implies that r

should be removed as redundant.

While analysing the sets of relevant regulations

, . . . , L

, the following options are possible:

1. LG =

0. This means RLG =

0, i.e.,

∀i. 1 ≤ i ≤ N. RL

= RLS

In this case, we have to analyse all sets RLS

espe-

cially carefully, as it is possible only if the sets of

regulations are completely different for all coun-

tries S

, . . . , S

. This case is very unlikely.

Similarly, the case CG =

0, where the cultural as-

pects and restrictions are completely different for

, . . . , S

, is also very unlikely.

2. If the sets of applicable regulations/laws are iden-

tical for all countries S

, . . . , S

, i.e., L

= ··· =

, we have the situation when

LG = L

= ··· = L

and

∀i. 1 ≤ i ≤ N. LS

which also means

∀i. 1 ≤ i ≤ N. RL

= RLG

If all requirements in RLG do not change over the

time (i.e., are static), the case is the simplest one

for the software development: the system can be

developed on the basis of RLG to use it within

, . . . , S

. The same holds for the sets of cultural

aspects and restrictions: if

CG = C

= ··· = C

we can develop a software system on the basis

of RCG to use it within S

, . . . , S

, as the sets of

corresponding country-speciﬁc cultural aspects is

empty

∀i. 1 ≤ i ≤ N. CS

3. If the sets of regulations/laws are not completely

identical for S

, . . . , S

, but have some similari-

ties, i.e.,

LG 6=

and

∀i. 1 ≤ i ≤ N. RC

= RCS

∪ RCG

Requirements Engineering for Global Systems: Cultural, Regulatory and Technical Aspects

565

where

∃ j. 1 ≤ j ≤ N. RCG

This is the most common case for the sets of reg-

ulations/laws, as well as for the sets of cultural

aspects and restrictions, where CL 6=

0 and there

are differences in the cultural aspects.

If these requirements are static (which could be

the case for culture-inﬂuenced requirements, but

hardly can be assumed for regulations/laws), a

component-based solution would especially efﬁ-

cient: the components implementing the require-

ments out of the set RCG can be separated from

the components implementing RCS

, . . . , RCS

As the regulations/laws are typically a subject to

change, it is risky to assume that the set RLG

will have no changes in the case some RLS

have

changes.

The following optimisation and reduction of the sets

RC and RL might increase efﬁciency of the analysis:

• RC

min

and RL

min

denote the sets of cultural and

legal requirements, which should be fulﬁlled by

any software system (within the corresponding

domain) developed for application in the country

• RC

∗

and RL

∗

denote the strongest sets of the

cultural and legal requirements for the country S

(within the corresponding domain). We can say

that these sets are optimisations of RC

, and RL

We propose to analyse the sets of requirements based

on the optimised views on the sets, i.e., where all re-

dundant (weaker) versions of the requirements are re-

moved, keeping the focus on the cultural and regu-

latory/legal aspects. As these aspects have different

nature, we cannot apply the same strategy to each of

them. For example, the sets of cultural aspects are

usually static, where the regulation/laws are subject

to change over time. While identifying RC

min

, RL

min

and RF

min

, we will analyse which components of the

system under development can be reused later. This

will allow us to have:

• an efﬁcient process for the development,

• provide a solution for traceability of the require-

ments changes that were caused by changes in the

regulations in S

, . . . , S

Thus, if there are some changes in r ∈ R

, which be-

comes r

in the new version, the following options are

possible:

1. The changes affect some r ∈ RLS

, this might lead

to the following cases:

(a) r

is still speciﬁc for S

only, i.e, only the com-

ponents implementing the country-speciﬁc re-

quirements S

are affected.

(b) r

is now (semantically) identical to the corre-

sponding requirements for all S

, 1 ≤ j ≤ N,

j 6= i, which means that

• r

should now belong to RLG, and all

RLS

, . . . , RLS

should be updated respec-

tively;

• we might reuse here the corresponding com-

ponents developed earlier for S

2. The changes affect some r ∈ RLG, this might in-

ﬂuence the system as whole. The following cases

are possible:

(a) r

is still general for all S

, . . . , S

, i.e, the cor-

responding components implementing the gen-

eral requirements are affected.

(b) r

becomes speciﬁc for some S

or for all coun-

tries, as not all RL

, 1 ≤ i ≤ N, are affected by

these changes. This implies the following

• we need to revise RL

, . . . , RL

to identify for

each of the S

, 1 ≤ j ≤ N, which of the ver-

sions – r

or r – should now belong to RLS

;

• if RLS

is now extended by r, no changes are

required for the components developed for S

;

• if RLS

is now extended by r

, the correspond-

ing changes have to be implemented for the

components developed for S

Speciﬁcation of RC

∗

, RL

∗

and RF

∗

, can provide us a

global view on the the system requirements, which is

not overloaded with the redundant requirements, as all

weaker versions are identiﬁed and removed. Respec-

tively, these sets will provide an input for the TOPSIS

framework to identify the most preferable solutions

with respect to the conﬂicting requirements. On the

TOPSIS level, the focus will be on general conﬂict

decision analysis, assuming that the cultural and reg-

ulatory diversity issues are already resolved.

In some cases, we might have even different hier-

archy levels to conduct a detailed analysis:

1. Organisational level, where the organisational

regulations and the corresponding cultural aspects

have to be take into account;

2. State level, where the state regulations/laws and

state-speciﬁc cultural aspects have to be taken into

account,

3. National level, where

• the national regulations/laws and country-

speciﬁc cultural aspects, and

• requirements based on the regulations/laws and

cultural aspects of the corresponding states

have to be taken into account.

ENASE 2019 - 14th International Conference on Evaluation of Novel Approaches to Software Engineering

566

Thus, in each country S

, 1 lei ≤ N, we might have

M(i) states State

, . . . , State

M(i)

, where M is a map-

ping from i to the corresponding natural number that

speciﬁes the state identiﬁer.

The organisational level might be seen

(1) either as a reﬁnement of a state level, where in

each State

, 1 ≤ k ≤ M(i), we deal with T (i)

organisations Org

, . . . , Org

T (i)

, where T (i) is a

mapping from M(i) to the corresponding natural

number that speciﬁes the organisation identiﬁer;

(2) or as a level that is orthogonal to the state and na-

tional levels, i.e., we assume that all companies

that will be using the product are global.

The second option can be used in a very limited num-

ber of cases: typically, global companies are pre-

sented by their country-based units which might differ

from each other in the terms of rules, regulations, etc.

This would imply, that each country-based units can

be treated as an organisation. Thus, the option (1) is

more realistic in general.

3 RELATED WORK

Glinz (Glinz, 2007) presented a survey on the existing

deﬁnitions of non-functional requirements (NFRs).

The survey also includes a comprehensive discussion

of the problems with the current deﬁnitions as well as

of promising solutions to overcome these problems.

In our approach, we analyse NFRs from the side of

cultural and legal/ regulatory compliance aspects.

Nekvi et al. (Nekvi et al., 2011) introduced a com-

pliance meta-model as well as identiﬁed a number of

key artefacts and relationships to demonstrate com-

pliance demonstration of the system’s requirements

against engineering standards and government regu-

lations.

Several other approaches on compliance vali-

dation of requirements we introduced by Breaux

et al. (Breaux et al., 2008), Maxwell and An-

ton (Maxwell and Anton, 2009), and Siena et

al. (Siena et al., 2009).

Breaux et al. (Breaux et al., 2015) also elaborated

techniques for modelling multi-party data ﬂows re-

quirements and verifying the purpose speciﬁcation as

well as limitation principles.

Yin et al. (Yin et al., 2013) proposed an approach

for compliance validation of the outcomes of business

processes against outcome-focused regulations.

Sleimi et al. (Sleimi et al., 2018) proposed a con-

ceptual model for extraction of semantic metadata us-

ing natural language processing, to provide a basis for

the analysis of legal requirements. In our future work,

we would like to investigate these approaches more

deeply, to identify which of them can be incorporated

or reused in the proposed framework within the step

of analysis RL

wrt. L

, RC

wrt. C

, as well as RF

with respect to RL

and RC

Levy at al. (Levy et al., ) presented a method-

ology for knowledge management solutions within

RE process, which covers both technical and so-

cial aspects. Spichkova and Schmidt (Spichkova and

Schmidt, 2015) analysed the RE aspects of a geo-

graphically distributed architecture in general. This

analysis was then further reﬁned by Spichkova et

al. (Spichkova et al., 2015) with the focus on regu-

latory aspects and variances in compliance. In the

presented approach we went further, by taking into

account cultural aspects as well as providing a formal

basis for change management procedure and analy-

sis of interdependencies among requirements, restric-

tions/laws and cultural aspects.

Alharthi et al. (Alharthi and Spichkova, 2016; Al-

harty et al., 2018) analysed individual and social (in-

cluding cultural) requirement aspects of sustainable

systems, focusing on educational domain (so-called

eLearning systems).

Mairiza et al. (Mairiza et al., 2013; Mairiza

et al., 2014) introduced the TOPSIS framework,

which adopts Multi Criteria Decision Analysis ap-

proach for NFRs and could assist software develop-

ers select the most preferable design solutions with

respect to the conﬂicting NFR. TOPSIS does not take

into account possible diversity in cultural and regu-

latory aspects, focusing on general conﬂict decision

analysis. In our future work we are going to integrate

the TOPSIS in the proposed framework.

4 CONCLUSIONS

In the case of global system development, we have

to take into account that different countries typically

have different regulations/laws as well as different

cultural restrictions, which also implies the corre-

sponding speciﬁc requirements might differ in each

particular case.

In this paper, we present a formal framework that

allows

(1) to structure and optimise the sets of requirements,

as well as

(2) to have a systematic process for change manage-

ment in the case of global system development,

where the diversity in cultural and legal/ regula-

tory compliance aspects in taken into account and

analysed especially carefully.

Requirements Engineering for Global Systems: Cultural, Regulatory and Technical Aspects

567

We also discussed in this paper our ongoing work

on the analysis of interdependencies between the

sets of requirements, cultural inﬂuences, and regula-

tions/laws.

Future Work: In our future work we are going

to analyse, which of the discussed in Section 3 ap-

proaches will be the best ﬁt to expand or framework

for interdependency and validity analysis of RL

wrt.

, RC

wrt. C

, as well as RF

with respect to RL

and

Another direction of our future work is to integrate

the proposed framework with TOPSIS to allow for ef-

fective conﬂict decision analysis.

REFERENCES

Alharthi, A. and Spichkova, M. (2016). Individual and so-

cial requirement aspects of sustainable elearning sys-

tems. In International Conference on Engineering

Education and Research (ICEER 2016), pages 1–8.

Western Sydney University.

Alharty, A., Spichkova, M., Hamilton, M., and Alsanoosy,

T. (2018). Gender-based perspectives of elearning

systems: An empirical study of social sustainability.

In 27th International Conference on Information Sys-

tems Development (ISD 2018), pages 1–12. Associa-

tion for Information Systems.

Alsanoosy, T., Spichkova, M., and Harland, J. (2018a). Cul-

tural inﬂuences on requirements engineering process

in the context of saudi arabia. In ENASE 2018: Vol-

ume 1, pages 159–168. SciTePress.

Alsanoosy, T., Spichkova, M., and Harland, J. (2018b). Cul-

tural inﬂuences on the requirements engineering pro-

cess: Lessons learned from practice. In 2018 23rd

International Conference on Engineering of Complex

Computer Systems (ICECCS), pages 61–70. IEEE.

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

of cultural factors on multi-cultural software devel-

opment teams. In 25th International Conference on

Software Engineering (ICSE), pages 540–547. IEEE

Computer Society.

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

(2008). Legal requirements, compliance and practice:

An industry case study in accessibility. In 16th IEEE

Conference on International Requirements Engineer-

ing (RE ’08), pages 43–52.

Breaux, T. D., Smullen, D., and Hibshi, H. (2015). De-

tecting repurposing and over-collection in multi-party

privacy requirements speciﬁcations. In 23rd Inter-

national Requirements Engineering Conference (RE),

pages 166–175. IEEE.

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

IEEE International Requirements Engineering Con-

ference (RE ’07), pages 21–26.

Govender, S., Kritzinger, E., and Loock, M. (2016). The

inﬂuence of national culture on information security

culture. In IST-Africa Week Conference, pages 1–9.

IEEE.

Levy, M., Hadar, I., and Aviv, I. A requirements engineering

methodology for knowledge management solutions:

integrating technical and social aspects. Requirements

Engineering, pages 1–19.

Mairiza, D., Zowghi, D., and Gervasi, V. (2013). Con-

ﬂict characterization and analysis of non functional

requirements: An experimental approach. In 12th

Int. Conference on Intelligent Software Methodolo-

gies, Tools and Techniques (SoMeT), pages 83–91.

Mairiza, D., Zowghi, D., and Gervasi, V. (2014). Utilizing

TOPSIS: A Multi Criteria Decision Analysis Tech-

nique for Non-Functional Requirements Conﬂicts. In

Zowghi, D. and Jin, Z., editors, Requirements Engi-

neering, volume 432 of Communications in Computer

and Information Science, pages 31–44. Springer.

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

quirements for compliance with law using a produc-

tion rule model. In Int. Workshop on Requirements

Engineering and Law (RELAW), 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 Int. Workshop

on Requirements Engineering and Law (RELAW),

pages 74–77.

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

(2007). Software engineering for automotive systems:

A roadmap. In Future of Software Engineering, FOSE

’07, pages 55–71. IEEE Computer Society.

Prikladnicki, R., Nicolas Audy, J. L., and Evaristo, R.

(2003). Global software development in practice.

lessons learned. Software Process: Improvement and

Practice, 8(4):267–281.

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, volume 4542 of

LNCS, pages 335–340. Springer.

Shah, H., Nersessian, N. J., Harrold, M. J., and Newstet-

ter, W. (2012). Studying the inﬂuence of culture in

global software engineering: thinking in terms of cul-

tural models. In 4th international conference on Inter-

cultural Collaboration, pages 77–86. ACM.

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

Towards a framework for law-compliant software re-

quirements. In 31st International Conference on Soft-

ware Engineering, pages 251–254.

Sleimi, A., Sannier, N., Sabetzadeh, M., Briand, L., and

Dann, J. (2018). Automated extraction of semantic

legal metadata using natural language processing. In

26th International Requirements Engineering Confer-

ence (RE), pages 124–135. IEEE.

Spichkova, M. and Schmidt, H. (2015). Requirements engi-

neering aspects of a geographically distributed archi-

tecture. In International Conference on Evaluation of

Novel Software Approaches to Software Engineering,

pages 276–281. IEEE.

Spichkova, M., Schmidt, H. W., Nekvi, M. R. I., and

Madhavji, N. H. (2015). Structuring diverse regula-

tory requirements for global product development. In

Int. Workshop on Requirements Engineering and Law

(RELAW), pages 57–60. IEEE.

ENASE 2019 - 14th International Conference on Evaluation of Novel Approaches to Software Engineering

568

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

From craft to discipline. In 16th ACM SIGSOFT Inter-

national Symposium on Foundations of Software En-

gineering, pages 238–249. ACM.

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

proach for ensuring regulatory compliance of process

outcomes. In Int. Workshop on Requirements Engi-

neering and Law (RELAW), pages 21–24.

Requirements Engineering for Global Systems: Cultural, Regulatory and Technical Aspects

569