1 Introduction

Global software development (GSD) is multi-site software development with software teams scattered across different places around the world [3, 10]. Despite the promising benefits of the lower costs of software development and access to international talent [8, 18, 25], GSD has introduced challenges for stakeholders which are not present in software projects developed in the same location (collocated projects) [9, 14, 38]. Due to development teams being in different geographical locations, differences in cultures, time zones and knowledge management practices adversely impact communication and coordination processes [1, 15, 19, 31]. Consequently, the frequency of communication, coordination and trust between the development teams decreases [2, 13]. In addition, dissimilar processes of software development, differing technical capabilities of remotely distributed team members, and the low visibility of development work carried out at different sites create additional challenges for stakeholders to tackle. Of the major challenges to successful GSD, devising a quality SRS is of greater significance.

Achieving customer satisfaction on delivered services is one of the primarily goals of every business. Of the many factors which assist stakeholders to achieve customer satisfaction, the quality of SRS plays an important role. When requirements specifications are badly written, development teams often face difficulties in obtaining the required knowledge at the right time. In collocated environments, this issue can be resolved by engaging in face-to-face communication [16, 34]; however, the social, lingual, geographical and cultural differences in GSD exacerbate the problem by introducing communication pauses and delays. Consequently, many software projects fail to complete within the allocated resources, resulting in a deterioration in the relationship between customers and suppliers [11, 26, 27, 32, 35].

The issues which introduce challenges for distributed development teams in preparing and later validating the SRS document are as follows: (i) the use of dissimilar vocabulary and terminologies: development teams in different locations use different keywords to represent a similar type of requirement. As a result, requirements are often misinterpreted by remote development sites [5, 7, 24]; (ii) difficulties in knowledge exchange and transfer: the presence of geographical boundaries, different vocabularies and dissimilar standards create difficulties for development teams in exchanging and transferring project knowledge between remote development sites [29]; (iii) difficulties in handling requirements specifications: the use of different requirements specification standards brings additional challenges for development teams in handling and processing SRS documents [29, 37]; and (iv) requirements validation: the influence of culture, time zones, knowledge management and communication features of GSD also affect the requirements validation activities across geographical boundaries. As a result, development teams face difficulties in validating the contents of SRS [12, 38].

The above-mentioned challenges are not adequately addressed by the conventional methods of requirements specification and validation. In addition, the international standards of SRS do not cover GSD aspects [17], although these are marginally covered in a few textbooks [6, 36]. Thus, in this paper, we present a method of software requirements specification and validation for GSD projects. Our method facilitates stakeholders in accomplishing the following activities: (i) the systematic organization of requirements via a requirements graph helps GSD teams understand software requirements with respect to different time zones and distance, and the GSD sites at which the requirement(s) are developed; (ii) the preparation of a requirements specification document with cooperation from the members of different GSD sites; and (iii) obtaining assurance that the requirements written in the SRS document are consistent and meet the needs of stakeholders in a globally distributed environment.

Past researchers used student groups in a university environment to play the roles of stakeholders in experiments in GSD studies [4, 21, 30, 35]. Likewise, we validate our method by applying it to a case study of an online shopping system, where the roles of requirements engineers, project analysts and designers were played by a group of students. Throughout the paper, we refer to these groups of people as “stakeholders”.

2 Our requirements specification and validation method

Our method is divided into five stages: (i) generation of requirements graph; (ii) preparation of SRS document; (iii) reviewing, updating and finalizing the SRS document at different GSD sites; (iv) requirements validation at different GSD sites; and (v) requirements validation between different GSD sites. The process begins with organizing the software requirements by generating a detailed requirements graph for them in stage 1. As a result, the requirements present in the requirements graph will be systematically organized with respect to the main and sub-requirements, and the GSD sites at which the requirement(s) are developed. In stage 2, the information obtained from stage 1 will be recorded in a requirements specification document and then will be circulated between different GSD sites for review, update and finalization of the contents of the specification document in stage 3. Finally, the requirements written in the specification document will be validated by generating and comparing validation matrices at different GSD sites in stages 4 and 5, respectively. The method as depicted in Fig. 1 is explained in detail in the following subsections.

Fig. 1
figure 1

Our method of software requirements specification and validation for GSD

Full size image

2.1 Stage 1: Generation of requirements graph

To facilitate GSD teams in understanding software requirements with respect to different time zones and distance, and the GSD sites at which the requirement(s) are developed, a requirements graph will be generated in two steps by using the concept of requirements ontology. The basic definition of requirement ontology is adopted from Lee and Zhao [20] who used ontological principles to extract domain requirements by considering mutual exclusion as the predicted relationship. In real-life scenarios, cross-cutting (also called intersecting) requirements often exist which are not covered in their work. To incorporate the feature of cross-cutting requirements and to add details on GSD projects, we extend their work by defining necessary postulates for them. Ontology is a six-element set consisting of concepts, relationships, postulates, locations and time zones of GSD teams. We deal mainly with finite space (resulting in finite sets); therefore, mentioning it as an element in the definition of requirements ontology is not important. Thus, ONT = (CON, REL-CON, POST, REL-POST, GLOC, GTZONE), where CON is the collection of concepts/requirements, REL-CON is the relationship between concepts, POST is the set of rules for CON and REL, REL-POST is the relationship exists in postulates (REL1-POST \(\epsilon\) REL-POST), GLOC = location of GSD team, and GTZONE = time zone of GSD team. We consider four different relationships between concepts: association (i.e. pre/post conditions), composition (i.e. part/whole), mutual exclusion and intersection. The postulates (POST) and the relationships expressed in postulates (REL-POST) are defined below:

  • Postulate 1: For all CON1, CON2 \(\epsilon\)

    CON, a one-to-one relationship (REL) exists between them, only if exactly one CON1 relates with exactly one CON2 (i.e. direct functional), or vice versa.

  • Postulate 2: For all CON1, CON2, CON3… \(\epsilon\) CON, a many-to-one relationship (REL) exists between them, only if multiple classes (CON1, CON2, CON3…) correspond with exactly one class (CON1)

  • Postulate 3: For all CON1, CON2, CON3…\(\epsilon\) CON, a many-to-many relationship (REL) exists between them, only if multiple classes (CON1, CON2, CON3…) correspond with other multiple classes (CON1, CON2, CON3…)

  • Postulate 4: For all CON1 and CON2 \(\epsilon\) CON, a symmetrical relationship (REL) exists between them, only if

    $$\begin{aligned} & {\text{C}}_{\text{ON1}} \left( {{\text{R}}_{\text{EL}} } \right){\text{C}}_{\text{ON2}} \Rightarrow {\text{C}}_{\text{ON2}} \left( {{\text{R}}_{\text{EL}} } \right){\text{C}}_{\text{ON1}} \\ & Or \\ & {\text{R}}_{\text{EL}} \left( {{\text{C}}_{\text{ON1}} , {\text{C}}_{\text{ON2}} } \right) = {\text{R}}_{\text{EL}} \left( {{\text{C}}_{\text{ON2}} , {\text{C}}_{\text{ON1}} } \right) \\ \end{aligned}$$

  • Postulate 5: For all CON1, CON2, CON3 \(\epsilon\) CON, a transitive relationship (REL) exists between them, only if

    $$\begin{aligned} & {\text{C}}_{\text{ON1}} \left( {{\text{R}}_{\text{EL}} } \right){\text{C}}_{\text{ON2}} , {\text{C}}_{\text{ON2}} \left( {{\text{R}}_{\text{EL}} } \right){\text{C}}_{\text{ON3}} \Rightarrow {\text{C}}_{\text{ON1}} \left( {{\text{R}}_{\text{EL}} } \right){\text{C}}_{\text{ON3}} \\ & {\text{Or}} \\ & {\text{R}}_{\text{EL}} \left( {{\text{C}}_{\text{ON1}} , {\text{C}}_{\text{ON2}} } \right) , {\text{R}}_{\text{EL}} \left( {{\text{C}}_{\text{ON2}} , {\text{C}}_{\text{ON3}} } \right) \Rightarrow {\text{R}}_{\text{EL}} \left( {{\text{C}}_{\text{ON1}} , {\text{C}}_{\text{ON3}} } \right) \\ \end{aligned}$$

  • Postulate 6: For all CON1 and CON3 \(\epsilon\) CON-A, and CON2 \(\epsilon\) CON-B, an injective relationship exists between them, only if

    $$\left\{ {{\text{C}}_{\text{ON1}} \left( {{\text{R}}_{\text{EL}} } \right){\text{C}}_{\text{ON2}} } \right\}\quad {\text{and}}\quad \left\{ {{\text{C}}_{\text{ON3}} \left( {{\text{R}}_{\text{EL}} } \right){\text{C}}_{\text{ON2}} } \right\} \Rightarrow {\text{C}}_{\text{ON1}} {\text{ = C}}_{\text{ON2}}$$

  • Postulate 7: For CON1 \(\epsilon\) CON, a reflexive relationship (REL) exists between them, only if

    $${\text{C}}_{\text{ON1}} \left( {{\text{R}}_{\text{EL}} } \right){\text{C}}_{\text{ON1}}$$

  • Postulate 8: For all CON1, CON2, CON3 \(\epsilon\) CON, a composite relationship (REL) exists between them, only if

    $$\begin{aligned} {\text{F}}\left( {{\text{C}}_{\text{ON1}} } \right) &= {}_{i = 1} \cap^{2} {\text{C}}_{\text{ONi}} \hfill \\ {\text{G}}\left( {{\text{C}}_{\text{ONi}} } \right) &= {}_{i = 1} \cap^{2} {\text{C}}_{\text{ONij}} \hfill \\ \left( {{\text{F}}\left( {{\text{R}}_{\text{EL}} } \right){\text{G}}\left( {{\text{C}}_{\text{ONi}} } \right)} \right) = {\text{F}}\left( {{\text{G}}\left( {{\text{C}}_{\text{ONi}} } \right)} \right) &= {\text{F}}\left( {{}_{i = 1} \cap^{2} {\text{C}}_{\text{ONij}} } \right) = {}_{i = 1} \cap^{2} {}_{j = 1} \cap^{2} {\text{C}}_{\text{ONij}} \hfill \\ \end{aligned}$$

  • Postulate 9: For all CON1, CON2, CON3 \(\epsilon\) CON, a distributive relationship (REL) exists between them, only if

    $$\begin{aligned} \left\{ {{\text{C}}_{\text{ON1}} \left( {{\text{R}}_{\text{EL}\text{-}\text{A}} } \right)\left( {{\text{C}}_{\text{ON2}} \left( {{\text{R}}_{\text{EL}\text{-}\text{B}} } \right){\text{C}}_{\text{ON3}} } \right)} \right\} = \left\{ {\left( {{\text{C}}_{\text{ON1}} \left( {{\text{R}}_{\text{EL}\text{-}\text{A}} } \right){\text{C}}_{\text{ON2}} } \right)\left( {{\text{R}}_{\text{EL}\text{-}\text{B}} } \right)\left( {{\text{C}}_{\text{ON1}} \left( {{\text{R}}_{\text{EL}\text{-}\text{A}} } \right){\text{C}}_{\text{ON3}} } \right)} \right\}; \hfill \\ {\text{Here, R}}_{\text{EL}\text{-}\text{A}} {\text{ = Intersection operation }}\left( \cap \right) , {\text{ and R}}_{\text{EL}\text{}\text{-}\text{}\text{B}} {\text{ = Union operation }}\left( {\text{U}} \right) \hfill \\ {\text{Or}} \hfill \\ \left\{ {{\text{C}}_{\text{ON1}} \cap \left( {{\text{C}}_{\text{ON2}} \cup {\text{C}}_{\text{ON3}} } \right)} \right\} = \left\{ {\left( {{\text{C}}_{\text{ON1}} \cap {\text{C}}_{\text{ON2}} } \right) \cup \left( {{\text{C}}_{\text{ON1}} \cap {\text{C}}_{\text{ON3}} } \right)} \right\} \hfill \\ \end{aligned}$$

  • Postulate 10: For all CON1, CON2, CON3 \(\epsilon\) CON, an associative relationship (REL) exists between them, only if

    $$\left\{ {{\text{C}}_{\text{ON1}} \left( {{\text{R}}_{\text{EL}} } \right)\left( {{\text{C}}_{\text{ON2}} \left( {{\text{R}}_{\text{EL}} } \right){\text{C}}_{\text{ON3}} } \right)} \right\} = \left\{ {\left( {{\text{C}}_{\text{ON1}} \left( {{\text{R}}_{\text{EL}} } \right){\text{C}}_{\text{ON2}} } \right)\left( {{\text{R}}_{\text{EL}} } \right){\text{C}}_{\text{ON3}} )} \right\}$$

2.1.1 Step 1: Identification of main requirements

The graph generation process begins with the identification of the main requirements and the locations and time zones of GSD sites, at which these requirements could possibly be developed, from the information gathered during requirements elicitation and analysis. Thus, we can say that:

$$\text{P} {\text{roject}} = \left\{ {{\text{R}}_{\text{EQUIREMENTS}} , {\text{R}}_{\text{EL}\text{-}\text{CON}} , {\text{P}}_{\text{RO}\text{-}\text{DOMAIN}} , {\text{ G}}_{\text{LOC}}, {\text{ G}}_{\text{TZONE}} } \right\}$$

where REQUIREMENTS = main functional and non-functional requirements, REL-CON = part/whole relationship, PRO-DOMAIN = problem domain that is finite in nature, GLOC = location of GSD team, GTZONE = time zones of GSD team.

2.1.2 Step 2: Decomposition of the main requirements

The requirements identified in step 1 are decomposed into sub-requirements, and appropriate relationships are established between them (refer to Fig. 2). The process of requirements decomposition is conducted on the basis of ontological principles and continues until no further division is possible. Thus, we can say that:

$$ {\text{R}}_{\text{EQUIREMENTS}} = \left\{ {{\text{C}}_{\text{ON}} , {\text{R}}_{\text{EL}\text{-}\text{CON}} , {\text{P}}_{\text{OST}} , {\text{R}}_{\text{EL}\text{-}\text{POST}} , {\text{G}}_{\text{LOC}} , {\text{G}}_{\text{TZONE}} } \right\} $$

where CON = collection of concepts/requirements, REL-CON = relationship between concepts, which can be association (i.e. pre/post conditions), composition (i.e. part/whole), mutual exclusion and intersection. POST = set of rules for CON and REL, REL-POST = relationship exists in postulates, which can be one-to-one, many-to-one, many-to-many, symmetrical, transitive, injective, reflexive, composite, distributive and associative relationships, GLOC = location of GSD team, GTZONE = time zones of GSD team.

Fig. 2
figure 2

Structure of a requirements graph

Full size image

Figure 2 presents the structure of a requirements graph (G) which contains a collection of nodes (N) and edges (E), such that G = (N, E). In graph G, each node provides information on a particular requirement, which could be either a main or sub-requirement, and the locations and time zones of GSD teams at which the requirements are developed. However, each edge represents a relationship between two requirements. The information therefore obtained from the requirements graph will be recorded in a tabular format, where a numeric value will be assigned to each requirement for tracking purposes.

2.2 Stage 2: Preparation of SRS document

After generating the requirements graph, details on the technical and non-technical aspects of the software project will be recorded in a requirements document, using the prototype for software requirements specification. The prototype presented is based on [17] and later modified to cover GSD aspects. The following information is new in our requirements document: (i) information about the GSD sites where the requirements are developed; (ii) the locations and time zones of each GSD team; (iii) the list of communication modes, mechanisms and tools used by each GSD team for communication purposes; (iv) details about the development teams responsible for the development of certain aspects of a GSD project; (v) the list of directly and indirectly affected project modules; and (vi) the non-functional requirements which are affected due to the lingual, temporal, cultural and geographical aspects of GSD. A detailed description of the elements of the prototype is presented in Table 1.

Table 1 Prototype for software requirements specification
Full size table

2.3 Stage 3: Finalization of SRS document

Once the initial version of the SRS document is generated, it will be communicated along with the requirements graph to other development sites to review its content and later update different elements of the requirements graph and SRS, if required. This process will be continued until the contents of SRS are finalized between the different GSD sites.

2.4 Stage 4: Validation at different sites

Lobo [22] provides a checklist of properties which should be satisfied to validate the requirements written in the SRS document. These properties include: acceptability—every requirement must be acceptable to the stakeholders responsible for it; ambiguity—every requirement must have only one interpretation; completeness—the requirements written in the SRS document should be complete; verifiability—every requirement must have an associated acceptance criterion to verify them after implementing the requirement; understandable—every requirement must be clear to all groups of stakeholders.

Two matrices A and B of m × n elements will be generated at different GSD sites, where m indicates the total number of requirements which need to be validated and n indicates the total number of properties which will be used to validate the requirements (refer to Eq. 1). Depending on the results of the validation process, these matrices will be filled with values “1” and “0”, where 1 means “property is satisfied” and 0 “property is not satisfied”.

(1)

2.5 Stage 5: Validation between different sites

The matrices generated in stage 4 will be compared by computing the correlation coefficient (CCpAB) for them (refer to Eq. 2) [28].

$$CC_{{p^{AB} }} = \frac{{\sum {(a - \bar{a})(b - \bar{b})} }}{{\sqrt {\sum {(a - \bar{a})^{2} (b - \bar{b})^{2} } } }}$$
(2)

In Eq. 2, A and B are the requirements property matrices generated at different GSD sites, a is the list of elements in the matrix A, \(\bar{a}\) is the mean of all elements in matrix A, and the same for b and \(\bar{b}.\) The result of the correlation coefficient falls between −1 and 1, where results close to −1 indicate that a significant difference exists between the outcomes of different GSD sites, and the requirements written in SRS do not satisfy the validation properties listed in Sect. 2.4. However, results close to 1 indicate that a minor difference exists between the outcomes of different GSD sites, and the requirements written in SRS satisfy most of the validation properties listed in Sect. 2.4.

3 The online shopping system (OSS) case study

Client XYZ is located in Australia and has been involved in the merchandising business for the last several years, selling products to the Australian market. The client considers the needs of the customer to be very important and wants to ensure a positive relationship exists with them. The client’s motive is “to sell reliable and quality products to a broad range of customers at affordable prices”. Due to team work, dedication, a clear focus and well-defined marketing strategies, the client holds a respectable position in the Australian merchandising arena.

Client XYZ wants to develop an online shopping system for their organization. In the shopping system, the following features are required: (i) facilitate customers/end-users in purchasing different products, tracking their orders, viewing sellers’ information, and make payments via a secure payment platform; (ii) facilitate XYZ in: selling different products, managing information about customers (i.e. shoppers) and wholesale merchandisers (i.e. sellers), manage all the orders made by the customers, and manage information about the products sold or still available; and (iii) easy-to-use graphical user interface (GUI).

The software organization ALPHA designs, defines and delivers a broad range of IT solutions which include: software development; hardware and software installations; network maintenance and management; desktop support and maintenance; and technological upgrades. The main site (headquarters) of ALPHA is located in Australia, and the offshore sites are located in India and China. Since its beginning, ALPHA has proven itself to be a highly committed organization which wants to deliver the best possible IT solutions at affordable prices.

Client XYZ contacted the software development organization ALPHA for the development of an online shopping system. Based on conversations with the client, the analysts and requirements engineers of ALPHA gathered and analysed details about the shopping system. After collecting and analysing the requirements of the shopping system, the analysts, requirements engineers and designers of ALPHA started the process of software requirements specification and validation. The client, requirements engineers and project analysts of ALPHA are located in Australia, and the designers are located in India.

4 Applying our method to the case study

Past researchers used student groups in a university environment to play the roles of stakeholders in experiments in GSD studies [4, 21, 30, 35]. Hence, we simulated the development of GSD requirements of XYZ using our method by creating a virtual environment for GSD within the vicinity of La Trobe University, Australia. In this virtual environment, the roles of the stakeholders were played by a group of students. With the limitations of a controlled GSD experiment, the differences in language and cultural setups were simulated by ensuring maximal participation of students from different cultures and backgrounds. Moreover, the geographical difference was simulated by ensuring that the students who performed the roles of the requirements engineer and analyst have never met the students who performed the role of the designer, and can only talk via the identified communications tools.

We selected 8 undergraduate and graduate students from the Department of Computer Science and Computer Engineering, La Trobe University, Australia, and divided them into three teams. The teams consisted of 2, 3 and 3 students who played the roles of the analyst, the requirements engineers and the designers, respectively. Basic knowledge about the experimentation process, their roles and responsibilities, and the list of things which was expected from them were given to them via information sessions. Interaction between the different student teams was performed via by a set of synchronous and asynchronous collaboration tools. In the following subsections, we describe how our method is implemented using the student groups.

4.1 Stage 1: Generation of requirements graph

To initiate the process of software requirements specification and validation, the members of the requirements engineers and the analyst teams used the requirements of a shopping system. From the information obtained, they extracted details about the main functional and non-functional requirements of the OSS, and details on the GSD sites at which these requirements could possibly be developed. In addition, they defined possible type(s) of relationship(s) which could exist among requirements. After the identification of the main requirements, they decomposed the entire set of main requirements into their constituent sub-requirements on the basis of ontological principles. The process continued until all the sub-requirements were obtained and organized to form a requirements graph (refer to Fig. 3).

Fig. 3
figure 3

Requirements graph of an online shopping system

Full size image

All the functional requirements in the requirements graph have an associated non-functional requirement(s), a relationship(s) which exists with other requirement(s), and the location and time zones of the potential GSD teams. The functional and non-functional requirements and details on the locations and time zones of GSD teams are listed in Table 2. However, details on the relationships between the different functional requirements in Fig. 3 are listed in Table 3.

Table 2 Functional and non-functional requirements of the online shopping system
Full size table
Table 3 Relationship between the requirements of the OSS
Full size table

4.2 Stage 2: Preparation of the SRS document

After generating the requirements graph, the members of the requirements engineers and analyst teams started the preparation of the SRS document for the online shopping system. Thereafter, these teams prepared the initial version of the document (refer to "Appendix 2").

4.3 Stage 3: Finalization of the SRS document

Following the processes of graph generation and the preparation of the SRS document, the members of the requirements engineers and analyst teams contacted the members of the design team to discuss the project requirements. They organized a videoconferencing session and explained the content of the requirements graph and the SRS document to the members of the design team. During this process, all the members examined the requirements in a detailed manner. As a result, they were able to identify areas that required further clarification and attention. For instance, details regarding input, output and external interfaces of the “make payment” and “payment mechanism” requirements were not clear in the SRS document. All the team members made an effort to address this issue. Similarly, the team members identified different issues from the requirements graph and the SRS document, addressed them in additional videoconferencing sessions, and finalized the content of the SRS document. In total, they organized four videoconferencing sessions of approximately 30 min each.

4.4 Stage 4: Validation at different sites

After finalizing the content of the SRS document, the members of the requirements engineers, the analyst and the design teams began the process of requirements validation. They evaluated each requirement, written in the SRS document, by evaluating them with respect to the properties mentioned in Sect. 2.4. Using Eq. (1), the requirements engineers and the analyst teams generated matrix-1 (refer to Table 4) and the design team generated matrix-2 (refer to Table 5). Depending on the results of the requirements validation, the team members populated Tables 4 and 5 with 1 and 0, where 1 indicates “validation property is satisfied” and 0 “validation property is not satisfied”.

Table 4 Validation matrix generated by the requirements engineers and analyst teams
Full size table
Table 5 Validation matrix generated by the design team
Full size table

4.5 Stage 5: Validation between different sites

Finally, the members of the requirements engineers, the analyst and the design teams organized a videoconferencing session to compare their matrices (refer to Tables 4 and 5). During the session, they considered one requirement at a time and compared their results by computing the correlation coefficient for them. The results obtained after applying Eq. (2) are presented in Table 6. The results vary between −1 and 1, where −1 indicates that a significant difference exists between the outcomes different GSD sites, and the requirements written in SRS do not satisfy the validation properties. However, results close to 1 indicate that minor differences exist between the outcomes of different GSD sites, and the requirements written in SRS satisfy most of the validation properties.

Table 6 Correlation coefficient for requirements validation
Full size table

From the results in Table 6, the teams identified that the overall correlation for the two matrices is 0.75, which means that the matrices generated by the different teams are approximately similar and satisfied most of the validation properties. In addition, there were three requirements in the SRS document that were not validated. The correlation coefficients for these requirements are 0.61 for requirement identifier 3, 0.66 for requirement identifier 8, and 0.66 for requirement identifier 16. All the teams analysed each of these requirements and addressed the issues. It took 2.5 h to complete this videoconferencing session.

5 Applying the conventional method to the case study

To evaluate the effectiveness of the proposed requirements specification and validation method, the conventional RE method that does not consider GSD specifics was used for the same GSD project. To avoid learning effect, a different group of 8 undergraduate and graduate students from the Department of Computer Science and Computer Engineering, La Trobe University, Australia, were selected and later divided into three teams. The teams consisted of 2, 3 and 3 students who played the roles of the analysts, the requirements engineers and the designers, respectively. Basic knowledge about the experimentation process, their roles and responsibilities, and the list of things which was expected from them was given to them via information sessions. Interaction between different student teams was performed via by a set of synchronous and asynchronous collaboration tools.

In the following, we describe how the student groups used the conventional RE method to perform requirements elicitation and analysis in GSD environment.

5.1 Requirements specification

After gathering and analysing the requirements, the requirements engineers and the project analysts prepared the SRS document using [17]. Details of the SRS document are presented in "Appendix 3".

5.2 Requirements validation

After completing the requirements specification process, the requirements engineers, the analysts and the designers began the requirements validation process in a videoconferencing session. During the process, they evaluated each requirement, written in the SRS document, using the traditional contract-style requirements list by evaluating them with respect to the following properties of requirements validation: acceptability—every requirement must be acceptable to the stakeholders responsible for it; ambiguity—every requirement must have only one interpretation; completeness—the requirements written in the SRS document should be complete; verifiability—every requirement must have an associated acceptance criteria to verify them after implementing the requirement; understandable—every requirement must be clear to all groups of stakeholders [22] (refer to Table 7). They populated Table 7 with 1 and 0, where 1 indicates “validation property is satisfied” and 0 “validation property is not satisfied”. Thereafter, by scanning the outcomes of Table 7, they came to conclusion that there are many requirements in the SRS document, for which some of the validation properties are not satisfied yet.

Table 7 Requirements validation via contract-style requirements list
Full size table

To validate the non-validated requirements, all the stakeholders (i.e. requirements engineers, project analysts and designers) organized three videoconferencing sessions at the agreed time to discuss and resolve the outstanding issues in requirements validation.

6 Discussions of the results

To validate our work, we used a case study of an OSS. A detailed description of the case study settings and a step-by-step demonstration of the proposed and the conventional RE methods were detailed in Sections 4 and 5. After completing the requirements specification and validation processes for both methods, we interviewed the student teams in five steps about their experiences in relation to the different aspects of the used methods. In step 1, we interviewed teams about the level of usefulness of the different aspects of requirements specification and validation. In step 2, we investigated the level of comfort felt by each team in working with the other teams. In step 3, we asked the teams to state the frequency of conflicts which occurred during requirements specification and validation. In step 4, we interviewed the teams about the number of rounds performed for requirements validation during the used RE methods. In step 5, we interviewed the teams about the time spent on different activities of requirements specification and validation. Finally, we analysed and discussed the data obtained during these steps.

6.1 Usefulness of our RE methods

To determine the level of usefulness of the proposed and the conventional requirements specification and validation methods, we asked members of the requirements engineer, analyst and design teams, in both project settings, to rate the different activities (also called aspects) of the used method on a scale of 1 to 4, where 1 indicates “not useful”, 2 “less useful”, 3 “useful” and 4 “very useful, based on their level of involvement in the various aspects. To analyze the data gathered in this step, we used Descriptive statistics to determine the level of usefulness. The results obtained after applying the Descriptive statistics are presented in Tables 8 and 9.

Table 8 Mean level of usefulness of different aspects of the proposed requirements specification and validation method
Full size table
Table 9 Mean level of usefulness of different aspects of the conventional requirements specification and validation method
Full size table

From the results shown in Tables 8 and 9, it can be seen that overall, the respondents from different teams rated the different aspects of the proposed requirements specification and validation as either useful or very useful for the accomplishment of the above-mentioned aspects. The primary reasons why our method was considered useful than the conventional method are as follows: (i) the information in the requirements graph helped GSD teams in different geographical locations to identify the main and sub-requirements, the relationships between them, and details about the GSD sites at which the requirements were developed. As a result, the GSD teams found our method useful to interpret and understand the software requirements in a consistent manner; (ii) in comparison with conventional requirements specification methods, the proposed format helped GSD teams to document details about the locations and time zones of each stakeholder, to list the communication modes and the mechanisms and tools used by each group of stakeholders for communication purposes, to provide details about the development teams responsible for the development of certain aspects of a GSD project, and to produce a list of directly and indirectly affected project modules as well as a list of non-functional requirements that could be affected due to the lingual, temporal, cultural and geographical differences between GSD teams; and (iii) it helped the teams validate the contents of the SRS document and ensure the quality of the requirements written in the SRS document.

6.2 Level of comfort working with other teams

To determine the level of comfort student teams felt in working with other teams, the members of the requirements engineer, analyst and design teams were asked to rate their level of comfort on a scale of 1 to 4, where 1 indicates “not comfortable”, 2 “less comfortable”, 3 “comfortable” and 4 “very comfortable”, based on their level of involvement in the GSD project. To analyze the data gathered in this step, we used the Descriptive statistics to determine the level of comfort. The results obtained after applying the Descriptive statistics are presented below.

Requirements engineers versus other teams: Tables 10 and 11 present details regarding the level of comfort the requirements engineers team expressed on the other teams in the proposed and the conventional methods of RE, respectively.

Table 10 Mean level of comfort expressed by the requirements engineers on the other teams in the proposed method
Full size table
Table 11 Mean level of comfort expressed by the requirements engineers on the other teams in the conventional RE method
Full size table

Analysts versus other teams: Tables 12 and 13 present details regarding the level of comfort the analyst team expressed on the other teams in the proposed and the conventional methods of RE, respectively.

Table 12 Mean level of comfort expressed by the analysts on the other teams in the proposed method
Full size table
Table 13 Mean level of comfort expressed by the analysts on the other teams in the conventional RE method
Full size table

Designers versus other teams: Tables 14 and 15 present details regarding the level of comfort the design team expressed on the other teams in the proposed and the conventional methods of RE, respectively.

Table 14 Mean level of comfort expressed by the designers on the other teams in the proposed method
Full size table
Table 15 Mean level of comfort expressed by the designers on the other teams in the conventional RE method
Full size table

6.3 Frequency of conflicts

In step 3, we asked each team to state the frequency of conflicts which occurred during the different activities of RE in relation to the proposed and conventional RE methods on a scale of 1 to 4, where 1 indicates “rarely”, 2 “occasionally”, 3 “less frequently” and 4 “very frequently”. To analyze the data obtained during this step, we applied the Descriptive statistics. The results are presented in Tables 16 and 17.

Table 16 Mean frequency of conflicts which occurred during different aspects of the proposed requirements specification and validation method
Full size table
Table 17 Mean frequency of conflicts which occurred during different aspects of the conventional requirements specification and validation methods
Full size table

From the results shown in Tables 16 and 17, it can be seen that overall, the respondents from the different teams indicated less conflicts during requirements specification and validation in the proposed method, mainly due to the following: (i) as a result of the requirements gathered and analysed with respect to different time zones and distance, the teams find it easier and non-conflicting to organize the obtained pieces of software requirements with respect to the GSD sites at which the requirement(s) are developed; (ii) the systematic organization of software requirements helped the teams in establishing and maintaining a consistent interpretation of software requirements across different time zones and geographical locations; (iii) the availability of information on all aspects of the prospective software system in GSD environment helped the teams in obtaining the required piece of information at the right time, which is even not available in the IEEE requirements specification document [17]; (iv) although there was a lack of face-to-face contact among the teams, the identification of suitable communication modes, mechanisms, tools and a mutually convenient time for communication helped the teams engage in discussion in a virtual environment; and (v) the matrix-based process facilitated the teams to validate the requirements, initially at their local site, then evaluate the outcomes of validation process with other teams by computing correlation coefficient, and at last identify and re-validate the non-validated requirements in a collaborative environment.

6.4 Number of rounds performed for requirements validation

In step 4, we interviewed the relevant student teams in relation to the number of rounds performed for requirements validation during the different aspects of the proposed and conventional methods of RE. In Table 18, details regarding the number of requirements validated at different rounds of requirements validation are presented. From the results shown in Table 18, it can be seen that the students who implemented the proposed method validated the total number of 19 requirements in two rounds of requirements validation. However, the students who implemented the conventional RE method validated the total number of 15 requirements in four rounds of requirements validation.

Table 18 Details on the number of requirements validated
Full size table

6.5 Time spent on different activities of RE

In step 5, we interviewed the relevant student teams in relation to the time spent on the different activities of RE using the proposed and conventional methods of RE. In Table 19, details regarding the time spent on requirements specification and validation are presented. From the results shown in Table 19, it can be seen that the students who implemented the proposed method of requirements specification and validation spent 400 min to generate the requirements graph and prepare the software requirements specification document, and 180 min to validate requirements written in the specification document, that makes the total of 580 min (9.66 h). However, the other groups of students who implemented the conventional RE method took 550 min to prepare the requirements specification document and 400 min to do requirements validation, thus giving a total of 950 min (15.83 h).

Table 19 Time spent on requirements specification and validation
Full size table

6.6 Summary of the results

After analysing the results presented in the earlier sections, the following observation is made about the students who used the conventional RE method.

  • Due to the non-availability of GSD-related information in the SRS document, the student teams find it difficult to gather information about the GSD sites at which the requirement(s) are developed, the locations and time zones of each GSD team, the list of communication modes, mechanisms and tools used by each GSD team for communication purposes, details about the development teams responsible for the development of certain aspects of a GSD project, the list of directly and indirectly affected project modules, and the non-functional requirements which are affected due to the lingual, temporal, cultural and geographical aspects of GSD. Also, the scattered presence (availability) of requirements, gathered during requirements elicitation and analysis, made it challenging for the student teams to establish a consistent interpretation and understanding of software requirements, and later validate the software requirements in a geographically distributed environment.

In comparison with the findings made about the students who used the conventional RE method, the following observations are made about the students who used the proposed method of requirements specification and validation.

  • The use of graph in our method helps GSD teams understand software requirements with respect to different time zones and distance, and the GSD sites at which the requirement(s) are developed. Thereafter, it helps GSD teams across different time zones and locations in the preparation of the software requirements specification.

  • The requirements specification template, proposed as part of the requirements specification and validation method, helped students (GSD teams) prepare an SRS document. Our SRS document therefore contains information about the traditional aspects of a software project [17] and the peculiarities involved in GSD, which are missing in the IEEE specification guidelines.

  • The matrix-based validation helps GSD teams examine the requirements with respect to the validation properties at different GSD sites, compare the outcomes of the validation process with other teams by computing the correlation coefficients, identify the requirements which do not satisfy the validation properties, and re-evaluate the non-validated requirements in a globally distributed environment.

Overall, the students rated different aspects of the proposed method as either useful or very useful for GSD, expressed a higher level of comfort working with other teams, and the frequency of conflicts which occurred during the requirements specification and validation processes was comparatively lower than the conventional RE method. Considering the fact that students performed additional activities to perform requirements specification and validation, they are still able to finish the entire process in less time, than the groups of students who implemented the conventional RE method. Thus, we can say that our method is especially useful for those groups of stakeholders who are taking part in GSD for the first time or are not aware of the fundamental aspects and issues of RE in GSD.

6.7 Threats to validity

Our work has the following validity threats. We have selected undergraduate and postgraduate students from the Department of Computer Science and Information Technology, La Trobe University. The difference in educational qualification can be a selection bias threat. The experiments in this demonstration case study lasted for several months; events (examination pressure, work commitments, personal issue etc.) occurred during this period could affect participant’s behaviour and performance. None of the participants have previous knowledge of GSD; the results obtained in this experimental setup could be a threat to validity.

When applying our method to the case study, the students were from one university. Although we selected students from different cultural backgrounds, the work involving students from different universities with dissimilar cultural backgrounds needs to be examined. Situational specifics (e.g. location, time, supervision and role of investigator) can potentially limit the generalizability of results. Researcher’s expectations and experiment bias can also be a threat to validity.

7 Related work

In the literature, only two papers have been published on GSD requirements specifications. In [23], the authors present a five-step process of requirements specifications for geographically distributed software projects. As a part of these steps, the authors suggest that the requirements specification document be circulated back and forth between the onshore and offshore development teams, until all the details in the requirements document are finalized. However, the authors in [29] proposed the use of patterns to prepare the SRS document for GSD projects. These patterns are mainly related to defining use cases, collaboration among the analysts throughout the RE process and mapping business-related terminologies to the entity attribute. With the help of these patterns, the authors aimed to address the following issues: the multiple definitions of use cases which often lead to misinterpretation; the challenges involved in knowledge transfer between development sites; and the difficulties in understanding and processing the requirements specification document. In addition to these papers, two papers have been published on requirements validation in GSD. In Yousuf et al. [39], a survey on the existing methods of requirements validation is presented. Based on the survey findings, the authors suggested that the factors of communication, control, knowledge sharing, delay and trust impact traditional methods of requirements validation and therefore cannot be used effectively for validation purposes in GSD projects. In [12], a proposal to select and utilize practices for the early validation of software requirements is presented. The authors presented a decision tree to facilitate stakeholders in the selection and utilization of different techniques and practices for requirements validation, where decisions are made on the familiarity and non-familiarity of requirements.

As a result of the contributions of this related work, the following conclusions are made: (1) due to the lack of requirements specification methods in [23, 29], a judgement about how to use these proposals and patterns to prepare an SRS document for a GSD project cannot be made; (2) in [39], the authors examined the impact of different GSD factors on the traditional methods of requirements validation and suggested that new methods are required for GSD projects; and (3) although, the decision tree facilitates stakeholders in the selection and utilization of appropriate practices for requirements validation, due to the lack of a methodical approach in [12], a judgement about how to use this proposal to validate the requirements of industrial projects cannot be made.

In the light of these findings, it can be said that these contributions lack methodical approaches to generate and validate the SRS document. We have therefore addressed these aspects in our work.

8 Conclusions and future work

The quality of software requirements specification is vital to project success. Due to the influence of cultural differences, language and communication barriers, difficulties in knowledge management and differences in time zones on software development, the ways by which requirements are documented and validated in collocated software development cannot be used effectively in a globally distributed environment. To date, there are very few research papers available which describe the work done on GSD requirements specification and validation. In this paper, we have therefore presented a method for this.

Our method is beneficial for GSD teams in the following ways: (i) the use of graph in our method helped GSD teams understand software requirements with respect to different time zones and distance, and the GSD sites at which the requirement(s) are developed; (ii) it helped GSD teams across different time zones and locations in the preparation of the SRS document. Our SRS document therefore contains information about the traditional aspects of a software project [17] and the oddness involved in GSD, which are missing in the IEEE specification guidelines; and (iii) the matrix-based validation helped GSD teams examine the requirements with respect to the validation properties at different GSD sites, compare the outcomes of the validation process with other teams by computing the correlation coefficients, identify the requirements which do not satisfy the validation properties, and re-evaluate the non-validated requirements.

To validate our method, we applied it to a case study of an online shopping system, where the roles of stakeholders were played by a group of students. Furthermore, we used the conventional requirements specification and validation method that does not consider GSD specifics for the same GSD project, so that a comparison between the results could be made. The results showed that the proposed method helped the student teams in preparing and validating the contents of SRS document for the requirements of the online shopping system. As a result, the chances of requirements being misunderstood and misinterpreted by development teams could be possibly minimized, and the time spent searching for information about the different aspects of a GSD project could be reduced.

To examine how scalable our method is, we aim to find a commercial partner, which would be prepared to collaborate with us in experimenting our method in a real-life environment.