Keywords

1 Introduction

Requirements elicitation is the first activity in the Requirements Engineering (RE) process and one of the most important and critical phases in software and systems development that has direct influence on quality and cost. The elicitation process is a communication intensive process that involves critical activities required to accurately capture the requirements/needs of diverse stakeholders who have a business interest in the system under development.

In today’s competitive business environment organizations struggle for survival, sustainability, and growth and as a result increasingly large numbers of organizations use distributed teams in their international operations with the aims to share responsibilities, decrease costs and gain access to experts. However, in Global Software Development (GSD), when stakeholders, of a system to be developed, are distributed in different locations the challenges usually are exaggerated due to distance, time, and cultural gaps. Divergent values of stakeholders in national, organizational, and professional cultures influence negatively on communication needed for successful requirement elicitation. Sometime the users are even out of organizational reach.

Requirements or needs elicitation is a process in which information related to the proposed system is gathered from all relevant stakeholders. Communication is a two-way process. Success is attained when all involved parties have the same understanding of what has been communicated. Several iterations in the communication process of requirements elicitation may be needed before mutual understanding is reached. It includes discovering, surfacing, and learning. The information and knowledge to be captured, understood, and validated includes wishes and interests in natural language of every stakeholder connected to the system that will be built, and is encapsulated in the User Requirements Document (URD). The URD is an early artefact of plan driven approaches that also describes organization policy, business processes and rules and is used as a reference for contract agreement and for tracing requirements throughout the software development process [1]. The URD is further developed into the requirements specification, which includes a more systemic viewpoint and aims to help requirements engineers to understand the problems to be solved. Understanding end-users, their needs and how they operate i) within the context of the proposed system, and ii) as part of the wider organizational settings, is likely to increase the probability of increased real-world accuracy and completeness of the requirements, and ultimately successful projects [2].

1.1 Types of Requirements

Functional requirements are related to specific business functions, tasks, or behaviors that a system under development is expected to support [3]; hence they aim to capture the intended behavior of the system to be developed. Use cases have become a widespread practice for capturing functional requirements. Non-functional requirements are requirements that are not directly related to specific functions of the system, but relate to quality characteristics such as reliability, availability, and security. Failing to meet non-functional requirements can, as in the case of functional requirements, be a cause of failure. Non-functional requirements, such as security, amongst others, are also a legal requirement of systems. For example, the General Data Protection Regulation (GDPR), a regulation in EU law, places a legal obligation for all systems to adhere to integrity and confidentiality (security) [4]. Non-functional requirements are considered problematic as users often state them in terms that are overly vague [3]. They are basically constraints placed on various attributes of business functions or tasks, and they arise from the operating environment, the user(s), and competitive products [3]. Domain requirements refer to domain concepts or specialized domain terminology. Linguistic ambiguity due to terminological discrepancies may occur between stakeholders that belong to different technical domains [5]. Since domain requirements are very specialized and requirements engineers find it difficult to understand how they are related to other system requirements, domain experts may leave information out of requirements simply because it is so obvious to them [3].

1.2 Actors of Requirements Elicitation

A human, social, and cultural problem in RE, that is addressed by this paper, is the challenge invoked by the heterogeneity of actors in the requirements elicitation process. All actors involved in requirements elicitation have different roles, objectives, backgrounds, domain knowledge, preferences, and priorities. However, there are basically two key players during the requirements elicitation process, namely users (all stakeholders that have an interest in the end-product) and requirements engineer (who needs to understand the users’ expectations of the system). Hence two professional cultures are involved, namely the user who views the system from a business perspective and the requirements engineer who views the system from a technological perspective. Thus, a communication gap is inherited in the communication process. In global settings, with actors coming from different organizational and national cultures the communication gap is exaggerated.

1.2.1 Dispersed Multicultural Stakeholders

Organizations increasingly rely on collaborative virtual teams to perform recurrent and collaborative tasks. However, when collaboration exceeds a certain context (e.g., multicultural environments) and when it relates to projects of substantial size, it reveals noteworthy challenges to meet individual needs. Dispersed multicultural stakeholders may be requirements engineers who work together as a virtual team or there may be customers/users that are spread across different cultures and locations or both. To overcome the challenges that distance brings it is important to be alert at an early stage for potential human, social and cultural mismatches and communication gaps between the requirements engineer on one side and the other stakeholders on the other. Preventive actions, such as organizing and training collaborating teams based on suitable reconciliation approaches as well as definition of suitable processes to support and encourage collaborative tasks of stakeholders of the system are imperative in order to reap the benefits of collaboration in an effective way.

1.2.2 End-Users Out of Organizational Reach

The methods used for identifying and involving stakeholders in RE require that stakeholders can be identified and that these stakeholders will participate in the collaborative elicitation and prioritization process. Nowadays, globally available platforms, such as Facebook and Instagram, with millions of users have emerged. Stakeholders of these systems, such as end-users and people affected by the system, are numerous, location-independent, and extremely heterogeneous as well as outside organizational reach. Stakeholders out of reach may either be unknown or cannot be easily identified in order to participate in RE activities. Current RE approaches try to deal with stakeholders outside organizational reach by online polls, questionnaires, or pilot studies. Siakas and Siakas [6] state that social media can be used in the process of RE, providing an active, creative, and social collaboration process between developers and customers/users. Also, crowd-based approaches have been proposed by Groen et al. [7]. In the social networking context, the word ‘crowd-sourcing’ is used, meaning the act of outsourcing tasks or business activity, traditionally performed by an employee or a contractor, to a large group of external people in a self-selected network of undefined individuals or community (a crowd) that use different social media for collaboration, through an open call [6]. Crowdsourcing is an emerging paradigm that utilizes the power of the crowd for gathering knowledge, information and solving problems [8, 9] and can support requirements elicitation for systems used by a wide range of users (crowd) working in a dynamic context where requirements evolve regularly.

1.2.3 Actors in Global Software Development

In GSD the life cycle activities in systems development are increasingly dispersed among virtual distributed teams and team members across different locations. There are several challenges and risks involved in GSD environments that include communication issues (time zone difference, different cultural impediments, lack of informal communication, etc.), strategic issues (incompatible processes, problem in task allocation and follow-up), technical issues (incompatibility of Information and Communication Technologies (ICTs), and knowledge management (poor knowledge sharing, documentation etc.).

Identifying potential business partners and developing business links with organizations in other countries has become easier for organizations that are experienced in monitoring web-based information sources and are able to combine tacit knowledge with new knowledge sources that are enabled by ICTs. Explicit knowledge is transferable through formal languages. Tacit or implicit knowledge is context-specific, personal, and subjective including cognitive elements and thus difficult to formalize and communicate [10]. In a global context the difficulties in requirements elicitation are intensified due to the distance, the fact that people rarely meet, and due to diverse values of stakeholders that come from different national cultures. Several organizations may also be involved (outsourcing or joint ventures), hence different organization cultures are involved.

1.2.4 Structure of this Paper

The remainder of this paper is structured as follows: In Sect. 2 we discuss national, organizational, and professional culture and their influence on the requirements elicitation process in GSD. This is demonstrated in Sect. 3, which also provides examples from requirements in high Power Distance, Uncertainty Avoidance and Collectivistic cultures as defined by Hofstede [14] and discuss the influence of culture on communication and knowledge sharing, two important factors in requirements elicitation. Section 4 examines communication challenges in Requirements Engineering and finally Sect. 5 examines how identified communication gaps in RE are addressed in the SPI Manifesto. The paper concludes with recommendations for minimizing communications gaps in GSD, conclusion, and further work.

2 What is Culture?

There is no common understanding or agreement on the definition of culture [11]. In 1952 Kroeber and Kluckhohn [12] identified 164 different definitions of culture. In 1980 Hofstede [13] argued that “there is no commonly accepted language to describe a complex thing, such as a culture”. The lack of clarity in definitions and meanings of different terms commonly used in a cultural context depends on the fact that in cultural studies many different academic disciplines are involved, where the same terms have different meanings and also different terms are used for the same concept. Hofstede [14] emphasizes that culture is a collection of shared characteristics created by similar backgrounds, socialization practices, life experiences and educational procedures. He argues that a typical child is imbued with them up to the age of ten years old. Fang [15] argues that culture can be compared to an ocean with visible wave patterns on the surface of the ocean in a given context at a given time but also numerous ebbs and flows underneath the surface. The visible wave patterns can be compared to visible superficial cultural artefacts and the ebbs and flows underneath can be compared to deep difficultly changing cultural values. Hofstede et al. [16] argue that within each collective entity, there is a variety of mindsets. Despite all this, culture is kept together with a stable structure that serves as a basis for common understanding of individuals of the entity.

In the Software Process Improvement (SPI) approach, with a rigid in-front requirements engineering process, the SPI manifestoFootnote 1, which governs personal behavior in relation to SPI work was formulated and published in 2009 [17]. It can be understood in the context of the three values espoused, namely: People (Must involve people actively and affect their daily lives); Business (Is what you do to make business successful); and Change (we changed the explanation of the SPI Manifesto “Is inherently linked with change” to “Enable continuous improvement through adaptability”).

These three values are further elaborated into ten principles that can serve as a foundation for action. The principle in line with our viewpoints is ‘Know the culture and focus on needs’. In this principle it is mentioned that the culture of an organization is fundamentally embedded in human behavior and expressed through norms (explicit or implicit rules) that the organization uses to express behavioral expectations and indications of appropriate and inappropriate attitudes and behaviors. These rules also affect interactions with others. Hence, culture is of the utmost importance in any organization, and it cannot be ignored particularly in multicultural settings. It is the basis for how people behave and communicate. In Breske and Schweigert [18] revisited the SPI Manifesto and stated that “the SPI Manifesto was outdated when written. Therefore, it had no practical impact and remained an academic footnote. Something for expert clubs and did not have real impact” and what is needed is “Empowerment of People” and “The Customer as a New Factor in SPI Projects”. According to our understanding the SPI approach is based on the Total Quality Management (TQM) philosophy, which adopts a disciplined approach focusing on customers. In requirements elicitation the customer-user viewpoint is imperative. Our opinion is that the heavy weight mechanism has been a spoke in the wheel. Fuentes-Fernandez et al. [19] state that “the human context within which a software system will operate is fundamental for its requirements”, hence, the requirements engineers need to take into consideration the human context of customer/user and its influence on the requirements, the design and the behavior of the system under development. Recognizing that culture is of the utmost importance in the human context we analyze how culture and communication influence requirements elicitation. We adopt Hofstede’s definition of culture.

2.1 National Cultures

It is widely recognized that nations possess distinct and relatively stable cultures. Hofstede’s model of differences in national culture is a static model that reflects an anthropological viewpoint of culture where every cultural dimension represents independent preferences for one situation over another. Hofstede’s model provides a macro-level framework for studying cultural factors. Four dimensions of a national culture [namely Power Distance Index (PDI), Individualism versus Collectivism (Ind-Coll), Uncertainty Avoidance Index (UAI), Masculinity versus Femininity (MAS-FEM)], were initially proposed and a further two (Long-term versus Short-term Orientation (LT-ST) and Indulgence versus Restraint (IVR)) were appended over time [14, 15, 21]. Hofstede’s cultural model is the most widely cited of all existing cultural models. Despite the broad acceptance of his model, many researchers have criticized his work throughout the years [15, 22,23,24,25] without much success. The main critiques of Hofstede’s approach include the viewpoint that the model is oversimplified and static. One of the most common criticisms concerns the research methodology which uses a survey of 116.000 questionnaires in one organization with branches across more than 70 countries. Hofstede et al. [16] responded to this and encouraged researchers to offer proposals to determine additional or different dimensions.

2.2 Organization Cultures

Researchers and practitioners have identified and discussed the importance of culture for organizations. Cameron and Quinn [26] developed the “Competing Values Framework”, an organization culture framework, which refers to whether an organization has a predominant internal or external focus, and whether it strives for flexibility and individuality or stability and control. It is also based on four dominant culture types (i.e., clan, adhocracy, market, and hierarchy). Schein [27] argues that the culture within organizations is formed in due course over time as the employees experience various changes, adapt to the external environment, and solve problems. They gain from their past experiences and start practicing it every day thus forming the culture of the workplace. Schein believed that there are three levels in an organization culture: Artefacts, Values and Assumed Values. Hofstede [14] argue that particularly two national dimensions, namely PDI (expressed as structure) and UAI (expressed as degree of rules and regulations) apply to organization culture. He depicts different layers of organization culture in the form of an onion, indicating that values represent the deepest level of culture followed by rituals, heroes and symbols that are characterized as practices and are easily identifiable by outsiders. Symbols are the most superficial manifestation of cultures and can easily be changed and copied by other cultural groups. Their cultural meaning is invisible and lies in the way these practices are interpreted by the insiders.

2.3 Professional Cultures

In the requirements elicitation process, there are a minimum of two different professional cultures involved. On one side, we have the requirements engineer who tries to understand the system from a systems development viewpoint; hence from a functional and a technological perspective regarding the problem area (which includes the users, the work context, and the wider organization in which the problem area is situated). On the other side there are the stakeholders from the side of the end-user, who usually see the system from a business point of view. Often also different language and jargon are used depending on the background of the two sides. Because of different viewpoints there is inevitably a communication gap inherited in the communication process. The degree of understanding depends on the way that requirements are communicated.

3 Cultural Influences on the RE Process

Alsanoosy et al. [28] carried out a systematic literature review regarding the influence of culture on RE activities and conclude that there are considerable gaps in the literature. They argue that studies regarding the relationship between culture and RE practices are still immature and that very few studies are carried out. Studies on Western cultures are lacking, obviously because standard RE practices are mainly defined by Western culture and in particular in the United States; hence they are compatible with Western cultures. They observed that most of the studies investigated in their review had been conducted within high PDI, UAI, and IDV cultures. We also provide results on requirements elicitation from high PDI, High UAI and Collectivistic countries.

3.1 Requirements Elicitation and High PDI

Alsanoosy et al. [28] argue that the PDI dimension seems to dominate RE activities. In low PDI countries lower ranking and higher-ranking employees consider each other as equals and decentralization is popular. On the other hand, high PDI countries subscribe to the authority of bosses and to centralization. Similar behaviors were found by Siakas and Mitalas [29] and Siakas et al. [30], from a laboratory course in Higher Education (HE) in Greece, (high PDI), where groups of four students in each group, simulated a real-life software development system. The educational system in Greece is highly teacher-centered and the students depend on the teacher who initiates all communication. This was also the challenge with the students who were responsible for the requirements elicitation; every requirement had to be confirmed by the teacher (this was a student-initiated request due to fear of making mistakes, and of not receiving approval by the ‘superior’); hence the whole requirements elicitation process was significantly slowed down. Our own experience from the Finnish KEMO projectFootnote 2 showed similar results. KEMO aimed to help companies that manufacture parceled goods to successfully begin their production in other counties by identifying, recognizing, and strengthening in advance factors and elements of successful production and logistics, and to eliminate potential risks. Eight managers in three different Finnish global organizations dealing with international operations with countries with high PDI, high UA and collective characteristics, were interviewed. The results revealed that the Finnish requirements engineers try to find out who is the highest ranked person in the hierarchy responsible for taking the final decision regarding the requirements and consult that person ‘because otherwise nothing will be decided in the meetings lower employees do not speak up, everything is always OK although it may not be’.

Our own experience from a software development project in Greece shows very similar results with the ‘defense’ aspect. The requirements engineer had to observe the end-users in their daily work because the manager’s decisions negatively affected the proposed solution. The difficulty that arose was to convince the manager that the end-users had more detailed context knowledge and their opinion needed to be taken into consideration, without creating a cultural conflict (disagreement feared to be interpreted as disrespect). Hence, we conclude that social status in high PDI negatively affect the outcomes and quality of requirements elicitation activity because lower-level stakeholders do not freely articulate their requirements since they are worried about conflicting with managers or receiving criticisms. Lack of trust has a negative impact on the requirements elicitation process because it reduces the transparency and communication among stakeholders. An interviewee in the KEMO project stated ‘In the Nordic counties trust is a value. In many other countries trust is not a value. The only way you can build trust is through action’. Nordic counties have low PDI. ‘As a requirement engineer it is also important that you sit somewhere higher up physically so that they respect and trust you, even if you are at the same hierarchical level. They call me by Mr. and my Surname’. We conclude that in the requirements elicitation process it is important that the requirements engineers build a trust relationship with stakeholders.

3.2 Requirements Elicitation and High UAI

The UAI aspects that Alsanoosy et al. [28] identified are recognition of uncertainty and avoidance of taking responsibility. They argue that uncertainty is one of the riskiest issues in RE. Our experiences from the simulation software development in HE in Greece (highest UAI on Hofstede’s scale) revealed that requirements engineers preferred precise objectives, detailed assignments and to follow instructions with low or no risk [29]. They avoided ambiguous situations and aspired to keep information and knowledge for themselves in order to be non-replaceable. They preferred and felt safe in a structured environment with precise rules and strict deadlines. Alsanoosy et al. [28] consider that for customers and other relevant stakeholders, uncertainty leads to significant decrease in their involvement because of their fear of unfamiliar situations or of making mistakes. This in turn leads to considerable challenges such as incomplete or inadequate requirements.

3.3 Requirements Elicitation and COLL Dimension

In collectivistic countries, such as Japan, people are conscious of the social context and there is a “shame culture” as opposed to a “guilt culture”. Shame is social in nature and depends on whether an infringement has become known by others [14]. The concept of “face” is also typical and describes the relationship with the social environment. Collectivism is a tight social framework in which people distinguish between in-groups and out-groups and expect their in-group to look after them. The concern is for the group and individuals to define their identity by relationships to others and group belonging, resulting in conflicts being avoided. Relationship-oriented behavior happens more often than work-oriented behavior; personal and family connections play an integral part in operations and opinions expressed by family members or in-group members who are taken more seriously into consideration. In the requirements elicitation process, stakeholders associate according to pre-existing in-group ties and protect their in-group members. Thanasankit and Corbitt [31] for example claim that Thai (high PDI) users, who believe that the system under development will be threatening their jobs, but also the job of a colleague tend to minimize their time available for providing the information the requirements engineer is trying to gather. Individuals from collectivistic societies predominantly work in groups. Thanasankit and Corbitt [31] claim that most Thai requirements engineers go out to gather requirements in pairs. The gathered requirements are then handed over to junior engineers; hence a group of requirements engineers is created. In the KEMO project one of the interviewees expressed his viewpoints about the Chinese (collectivistic country) ‘they do not build special expertise for themselves, instead they share their knowledge quite willingly in order to create a good and coherent team. If everybody knows everything you are not special. In China everything is documented, and the team is more important than the self. It is much better for the organization if people share knowledge willingly because then everybody understand more easily what you are talking about. Knowledge sharing is a win-win situation’. In requirements elicitation knowledge sharing is imperative for capturing complete and correct requirements. When key stakeholders, such as customers/end-users, belong to collectivistic environments it is important that the requirements engineer identifies any informal groupings (in-groups) in order to ensure fruitful collaboration.

3.4 Cultural Influences on Communication

A fundamental requirement for effective teamwork is good communication [32, 33]. We usually use the phrase “We are speaking the same language” meaning we understand each other well because of shared viewpoints, perceptions, ideas, and feelings. Miscommunication inevitably results in ambiguity, subjective understanding and misunderstandings among team members which lead to confusion, poor performance, hurt feelings, and lack of motivation [34]. Teamwork involves different types of communication depending on many factors, such as divergent values in national cultures [14], organization cultures [35] different professional cultures with own language, symbols, and arcane meanings [36]. In order to avoid miscommunication, it is necessary to define and use terms consistently and in a standard method [37] and to minimize miscommunication that originate in cultural divergence.

3.5 Cultural Influences on Knowledge Sharing

Despite the many technologies that support collaboration among distributed work groups, organizations still face difficulties building online work environments. What is lacking in most virtual workplaces is a proven methodology for identifying and converting individual expertise, skills, and experience into organizational knowledge and to strategically align organizational knowledge transfer and learning investment with organizational value outcome [38]. Knowledge evolves continuously as the individual and the organization adapt to influences from the external and the internal environment.

Knowledge sharing, through knowledge transfer, is the process where individuals mutually exchange both tacit (feel or sense for something), and explicit knowledge (codifiable knowledge) and jointly create new knowledge [39]. Tacit knowledge is difficult to grasp as it mainly exists unconsciously in the mind of individuals; it can be “the way we do things” without following written rules or regulations. In requirements elicitation the most difficult task is to elicit tacit knowledge, which however, can be very important.

De Long and Fahey [40] identified four issues influencing knowledge creation, sharing and use, namely:

  • Culture shapes assumptions about what knowledge is and which knowledge is worth considering.

  • Culture defines the relationship between individual, team, and organizational knowledge, determining who can utilize it, share it, control it and how it can be used in a certain situation.

  • Culture creates the context for social interaction.

  • Culture shapes the processes by which new knowledge is created, legitimated, and distributed.

Research regarding knowledge creation, capture, storage, and distribution, as well as regarding organizational learning denotes that communication, knowledge sharing and learning are profoundly influenced by cultural values of individual stakeholders [10, 14, 41,42,43].

4 Communication Challenges in RE

The requirements elicitation stage of a development project is characterized by intense communication activities between a diverse range of people who have different backgrounds, levels of skills, knowledge, and status. Coughlan and Macredie [2] articulate that ‘an increased amount of communicative effort is required to surpass the semantic gap that estranged parties, such as users and designers, inevitably foster'. These estranged parties are characterized by different professional cultures.

In addition, the increased complexity of systems and software, as well as volatility and vastness of requirements, has a considerable impact on communication, which has been extremely difficult to achieve and is a recurring problem in the elicitation of requirements [48]. The most important reason for the existence of communication problems lies in the fact that systems design and development is a behavioral process, where human and organizational elements have an important bearing on the elicitation process and the design [2]. The literature on RE has identified different problems in the requirements elicitation process [44, 49] mainly attributed to communication problems, as follows:

  • Missing requirements:

    • End-Users /stakeholders do not mention all requirements because lack of:

      • awareness of possible solutions that a new system can offer.

      • understanding of what is necessary.

      • interest in the proposed system (they forget to tell about some requirements).

    • The requirements engineer forgets to ask some specific questions.

  • Reluctant participation: stakeholders are not interested in participating in the requirements elicitation process because of:

    • sensitivities about the consequences of automation.

    • conflicts among stakeholders.

    • politics and disagreements regarding aim and objectives of the new system.

  • Misperception: requirements engineer incorrectly captures requirements because of:

    • different terminology arising from different professional, organizational or national culture.

    • linguistic ambiguity due to terminological discrepancies which may occur between stakeholders that belong to different technical domains [5], hence to different professional cultures. Robinson and Bannon [47] use the term Ontological Drift to describe the change in meaning of abstract terms as they are passed between different communities.

    • lack of cross-cultural awareness.

    • inadequate negotiation and communication skills.

    • insufficient transfer of implicit domain knowledge from stakeholders to requirements engineer.

    • inexperience of requirements engineers.

  • Disagreement: requirements engineer, and end-user/stakeholders disagree about certain requirements.

Misperception results in ambiguity of requirements and erroneous specification which in turn leads to failures of systems [52]. “Speaking the same language” is a common phrase which does not necessarily refer to a natural language like English, German, Chinese… but more significantly, it means common understanding and agreeing with each other. Lack of ambiguity is a fundamental requirement for common understanding and communication. Understanding one another takes place “because there exists a code, a sort of inner competence between you and me and there exist possible messages, performed as utterances and interpretable as a set of propositions”.

Communications challenges can be grouped in at least three different ways, namely articulation, understanding [49] and conflict [54]. Resolution of misunderstandings, misperceptions, disagreements, and conflicts originating from divergent cultural values, whether they are national, organizational, or professional, is usually left to the discretion of the requirements engineers utilizing their cross-cultural knowledge, interpersonal communication, and negotiation skills. Increasing cultural awareness will help requirements engineers to decrease the communication gap in requirements elicitation in multicultural settings.

5 How the SPI Manifesto Addresses the Identified Communication Gaps

A communication gap occurs when the message sent by the speaker/sender is not what is understood by the recipient. Differences in communication styles are prevalent in any kind of relationships, but as we have seen in the previous sections, communication gaps are particularly apparent in global collaborations and GSD. Communication between and among requirements engineers and different stakeholders is particularly critical for eliciting unambiguous, correct, and complete requirements. The context in each case dictates how explicitly or implicitly communication and knowledge (both explicit and tacit) sharing takes place.

Mapping the identified communication gaps (G1 to G5) to the three SPI Manifesto Values reveals the main manifestations (of the potential problems) which are shown in the cells of Table 1.

The identified gaps are shown as G1, G2, G3, G4 and G5. The three SPI Manifesto Values are V1: People, V2: Business and V3: Change. Table 1, below, highlights, per Communication Gap, what the detrimental effects and challenges are that are invoked in the context of each of the three SPI Manifesto Values.

Table 1. Communication gaps mapped to the three SPI Manifesto Values
Full size table

For each of the challenges brought about by communication gaps, identified in Table 1, above, this paper proposes respective strategies for the prevention and mitigation of the detrimental effects of the potential problems. These are presented in Table 2, below.

As shown above the values of the SPI Manifesto can inform and guide the identification of gaps in communication. In turn experiences from industry can be fed to the debate in the SPI Manifesto community thus contributing any extensions/refinements to the Manifesto itself.

The set of recommendations that our paper proposes will also assist companies implementing SPI (Software, System and Service Improvement) in getting a better understanding, and in addressing the challenges of cultural diversity in SPI. A requirements elicitation process that adopts one or several of these proposals can help alleviate the challenges invoked by stakeholders’ cultural diversity in the RE process, thus leading to systems development and deployment that much better reflects the requirements/needs of diverse stakeholders and users. In addition, our recommendations will contribute to the on-going debate on the review and extension of the SPI manifesto.

Table 2. Strategies for the prevention and mitigation of the detrimental effects of the potential problems
Full size table

6 Set of Recommendations

A number of recommendations, including the prevention and mitigation strategies presented in Table 2, are suggested below by the authors, which, if followed, are likely to lead to the cultural and communication challenges in requirements elicitation being addressed. The first three recommendations originate from these. There is often a clash of culture, lack of relevant knowledge or experience in actors in the requirements elicitation process. It is the computer professional’s duty to lead and instruct in such circumstances by using the appropriate technologies, platforms, methods, and frameworks suggested below:

  1. 1.

    Training: Three fundamental types of training that should be undertaken by participants in the elicitation process are:

    1. i)

      Cross-cultural Training covering national, organizational, and professional cultures for raising awareness of cultural dimensions as defined by Hofstede [14] for appreciation, tolerance, widening of thinking- horizons and conflict prevention. This is particularly true of Requirements Engineers. We propose a set of mitigation actions related to cultural differences in multicultural environments as described in Table 2.

    2. ii)

      Unconscious Bias Training for raising of awareness, self-assessment and reflection aiming to widening of own understanding, awareness and appreciation of cultural diversity, strengths, and weaknesses.

    3. iii)

      Familiarization with the context specific ontology and terminology so that all actors reach a level of common language. Georgiadou [51] argues that ambiguities in terminology can be addressed and minimized even eliminated using ontologies which are context specific. Ontologies reduce conceptual and terminological ambiguity, as they provide a framework for unification which in turn facilitates communication and knowledge sharing among diverse viewpoints, contexts, cultures and so on.

  2. 2.

    Use of Common process standards: Investments in structured key process areas (KPAs) as specified by Capability Maturity Models, such as CMMI and ISO/IEC 15504 were found to mitigate the negative effect of work dispersion on productivity and quality. Investments in conceptual learning contributed to improved quality; operational learning investments were associated with improved productivity [61].

  3. 3.

    Use of compatible ICTs: Powerful and versatile communication tools and ICTs increase organizational productivity by improving the effectiveness of face-to-face meetings.

  4. 4.

    Use of Natural Language Processing (NLP) approach: Ferrari and Esuli [5] argue that in order to effectively communicate and ultimately reach a shared understanding of the problem at hand in requirements elicitation, linguistic ambiguity due to terminological discrepancies between stakeholders that belong to different technical domains needs to be addressed. They suggest the use of a natural language processing approach to identify ambiguous terms between different domains and rank them by ambiguity score. We argue that this approach could be extended, beyond domains of interest, to differing stakeholders with dissimilar cultures. By building culture-specific language models, one for each stakeholders’ culture. Embedded words from each culture language model could be compared in order to measure the differences of use of a term, thus estimating its potential ambiguity across the domains of culture. Further research on the relationship between cultural domain knowledge and natural language ambiguity is required.

  5. 5.

    Use of Big Data Analytics: When social media is used in the process of product or service development, an active, creative, and social collaboration process between developers and customers/users takes place, facilitated by an organization [6]. Significant stakeholders of these systems, such as end-users and people affected by the system, are numerous, location-independent, and extremely heterogeneous and outside organizational reach. Current RE approaches try to deal with stakeholders outside organizational reach by online polls, questionnaires, or pilot customers. By additionally allowing this data to be captured in various formats: social media feeds, video, audio, etc., vast amounts of data could be collected from such data collection methods. Big data analytics using, one or a combination of: association rule learning, classification tree analysis, genetic algorithms, machine learning, regression analysis, sentiment analysis, and social network analysis could assist in gaining valuable insights into cultural background and requirements.

  6. 6.

    Conduct Organizational Feasibility Studies: The most important reason for the existence of communication problems lies in the fact that systems design, and development is a behavioral process, where human and organizational elements have an important bearing on the elicitation process and the design [2]. Avison and Fitzgerald [45] and Sommerville [46] explain reluctant participation in RE, where stakeholders are not interested in participating in the requirement elicitation process because of sensitivities about the consequences of automation; conflicts between stakeholders; and political disagreements regarding aims and objectives of new system. An operational feasibility study, the process of determining how a system will be accepted by people (assessing employee resistance to change, gaining managerial support for the system, providing sufficient motivation and training, and rationalizing any conflicts with organizational norms and policies) and how well it will meet various system performance expectations needs to be conducted. By doing so, the human and organizational elements could be better understood and thus lead to a betterment in the RE process.

  7. 7.

    Conduct Ethical Retrospectives: Having established a set of (non) functional requirements it is imperative that RE engineers conduct retrospectives, allowing the discovering, sharing, and passing along of the learning from the RE experience. This may well lead to revision of the requirements. Pivotal to holding ethical retrospectives are certain ground rules, including: 1) participants must respect and value alternative viewpoints and, seek, accept, and offer honest criticisms of work; 2) participants must be able to exercise freedom of expression. This will include the freedom to hold opinions and to receive and impart information and ideas without judgment and/or reprisal from others; 3) exercise the right to anonymity; and 4) invited participants to engage in retrospectives reflect a diverse representation. Such open discussion forums can focus on conflicts arising from cultural differences for reflection and prevention of conflicts.

  8. 8.

    Use decision logs: Kahneman [52] promotes the use of a ‘decision log’ as a way to eliminate hindsight bias. Whenever a strategic decision is made it should be logged publicly, along with the following information: 1) the rationale behind the decision; 2) the expected outcome; 3) how the decision-maker feels about the situation; and 4) a date to revisit the decision and to see what happened. The use of such logs permits an individual to begin to identify biases in their thought process, and by doing so, become more effective in decision-making. Kahneman states that the more decision logs we read, the more we are exposed to other mental modes, and the better our decision making becomes.

  9. 9.

    Use of social media/Communities of Practice: Siakas and Siakas [6] state that social media can be used in the process of product or service development enabling an active, creative, and social collaboration between requirements engineers and customers/users takes place. In requirements elicitation Communities of Practice (CoP) are often used, e.g., as a Wiki, where stakeholders virtually meet for knowledge sharing and requirements determination. CoP are defined by Lave and Wenger [53] as ‘an aggregate of people who come together around mutual engagement in an endeavor’ and by Bettoni et al. [as ‘the participative cultivation of knowledge in a voluntary informal social group’. Both definitions highlight a type of social construction or community leading to a kind of culture including common practices that emerge during the mutual endeavor. The community is usually born around a shared profession or a shared task, and usually outside of for the traditional structural boundaries.

  10. 10.

    Use of Gamification: A promising approach, using gamification, was presented by Kolpondinos and Glinz [55], who developed the GARUSO approach that uses a certain strategy for identifying a crowd of stakeholders outside organizational reach and subsequently use a social media platform that applies gamification for motivating these stakeholders to voluntarily participate in RE activities. Lombriser et al. [56] developed the gamified requirements engineering model (GREM) that relates gamification, stakeholder engagement, and RE performance. Focusing on agile requirements that are expressed as user stories and acceptance tests, their evaluation provided promising initial empirical insights, and lead to the hypothesis that competitive game elements are advantageous for RE elicitation.

7 Conclusions and Further Work

The aim, of the research presented here, was to report on the challenges of requirements elicitation in environments, where stakeholders of differing cultures cooperate. The focus was on the communication gaps that occur due to differences in cultures between the requirements engineer and the end-user/stakeholders, as well as among them, regarding a proposed system. The paper highlights that the cultural studies in the field of RE are insufficient and that more empirical studies are required. By looking at current solutions that are being adopted to assist in improving the cultural aspect of the requirements elicitation process and based on the indications from the mapping of communication gaps to the SPI Manifesto Values, we proposed a set of recommendations that could be exercised and fulfilled by stakeholders in RE in order for them to reduce communications gaps and to improve cultural considerations in the RE process. A more collaborative view of requirements elicitation and communication is required to include all stakeholders and to take the contextual, national, organizational, and professional cultures into account. Software Process Improvement (SPI) is core to the modern engineering of complex systems. By comprehensively and carefully taking the values of the SPI manifesto into consideration many discrepancies derived from communication gaps due to professional, organizational, and national diversity should, would and could be eliminated or at least bridged.

Further work will concentrate on the development of a multicultural requirements framework which will be evaluated by experts in the field. Various technologies, systems, applications, methods, and approaches will be identified and mapped across this multicultural framework in order to be applied in real life requirements engineering and requirements elicitation in particular.