Requirements Eng (2017) 22:191–214

DOI 10.1007/s00766-015-0240-4

ORIGINAL ARTICLE

A method of software requirements specification and validation

for global software development
Naveed Ali1 • Richard Lai1

Received: 20 January 2015 / Accepted: 28 October 2015 / Published online: 19 November 2015
 Springer-Verlag London 2015

Abstract Global software development (GSD), where method by applying it to a case study of an online shopping
software teams are located in different parts of the world, system, where the roles of stakeholders were played by a
has become increasingly popular. To devise a high-quality group of students.
software requirements specification (SRS), effective com-
munication and collaboration between stakeholders are Keywords Software requirements specification  Global
necessary for GSD. However, geographical distance, cul- software development  Distributed teams  Requirements
tural diversity, differences in time zones and language validation
barriers create difficulties for stakeholders in engaging in
effective collaboration. Taking into consideration the fac-
tors involved in GSD, previous research showed that the 1 Introduction
ways by which requirements are documented and validated
for collocated software development projects cannot be Global software development (GSD) is multi-site software
used effectively for GSD. In this paper, we present a development with software teams scattered across different
method of GSD requirements specification and validation. places around the world [3, 10]. Despite the promising
Our method begins with generating a requirements graph to benefits of the lower costs of software development and
understand details of the software requirements with access to international talent [8, 18, 25], GSD has intro-
respect to different GSD sites. The information obtained duced challenges for stakeholders which are not present in
from a requirements graph is to be contained in a software projects developed in the same location (collo-
requirements specification document, and then be circu- cated projects) [9, 14, 38]. Due to development teams
lated between different GSD sites for reviewing, updating being in different geographical locations, differences in
and finalizing its content. Finally, the requirements con- cultures, time zones and knowledge management practices
tained in the specification document are to be validated by adversely impact communication and coordination pro-
generating and comparing validation matrices at different cesses [1, 15, 19, 31]. Consequently, the frequency of
GSD sites. Past researchers used student groups in a uni- communication, coordination and trust between the
versity environment to play the roles of stakeholders in development teams decreases [2, 13]. In addition, dissim-
experiments in GSD studies. We therefore validate our ilar processes of software development, differing technical
capabilities of remotely distributed team members, and the
low visibility of development work carried out at different
& Richard Lai sites create additional challenges for stakeholders to tackle.
[email protected] Of the major challenges to successful GSD, devising a
Naveed Ali quality SRS is of greater significance.
[email protected] Achieving customer satisfaction on delivered services is
1 one of the primarily goals of every business. Of the many
Department of Computer Science and Information
Technology, La Trobe University, Melbourne, VIC 3086, factors which assist stakeholders to achieve customer sat-
Australia isfaction, the quality of SRS plays an important role. When

123
192 Requirements Eng (2017) 22:191–214

requirements specifications are badly written, development experiments in GSD studies [4, 21, 30, 35]. Likewise, we
teams often face difficulties in obtaining the required validate our method by applying it to a case study of an
knowledge at the right time. In collocated environments, online shopping system, where the roles of requirements
this issue can be resolved by engaging in face-to-face engineers, project analysts and designers were played by a
communication [16, 34]; however, the social, lingual, group of students. Throughout the paper, we refer to these
geographical and cultural differences in GSD exacerbate groups of people as ‘‘stakeholders’’.
the problem by introducing communication pauses and
delays. Consequently, many software projects fail to
complete within the allocated resources, resulting in a 2 Our requirements specification and validation
deterioration in the relationship between customers and method
suppliers [11, 26, 27, 32, 35].
The issues which introduce challenges for distributed Our method is divided into five stages: (i) generation of
development teams in preparing and later validating the requirements graph; (ii) preparation of SRS document; (iii)
SRS document are as follows: (i) the use of dissimilar reviewing, updating and finalizing the SRS document at
vocabulary and terminologies: development teams in dif- different GSD sites; (iv) requirements validation at differ-
ferent locations use different keywords to represent a ent GSD sites; and (v) requirements validation between
similar type of requirement. As a result, requirements are different GSD sites. The process begins with organizing the
often misinterpreted by remote development sites [5, 7, software requirements by generating a detailed require-
24]; (ii) difficulties in knowledge exchange and transfer: ments graph for them in stage 1. As a result, the require-
the presence of geographical boundaries, different vocab- ments present in the requirements graph will be
ularies and dissimilar standards create difficulties for systematically organized with respect to the main and sub-
development teams in exchanging and transferring project requirements, and the GSD sites at which the require-
knowledge between remote development sites [29]; (iii) ment(s) are developed. In stage 2, the information obtained
difficulties in handling requirements specifications: the use from stage 1 will be recorded in a requirements specifica-
of different requirements specification standards brings tion document and then will be circulated between different
additional challenges for development teams in handling GSD sites for review, update and finalization of the con-
and processing SRS documents [29, 37]; and (iv) require- tents of the specification document in stage 3. Finally, the
ments validation: the influence of culture, time zones, requirements written in the specification document will be
knowledge management and communication features of validated by generating and comparing validation matrices
GSD also affect the requirements validation activities at different GSD sites in stages 4 and 5, respectively. The
across geographical boundaries. As a result, development method as depicted in Fig. 1 is explained in detail in the
teams face difficulties in validating the contents of SRS following subsections.
[12, 38].
The above-mentioned challenges are not adequately 2.1 Stage 1: Generation of requirements graph
addressed by the conventional methods of requirements
specification and validation. In addition, the international To facilitate GSD teams in understanding software
standards of SRS do not cover GSD aspects [17], although requirements with respect to different time zones and dis-
these are marginally covered in a few textbooks [6, 36]. tance, and the GSD sites at which the requirement(s) are
Thus, in this paper, we present a method of software developed, a requirements graph will be generated in two
requirements specification and validation for GSD projects. steps by using the concept of requirements ontology. The
Our method facilitates stakeholders in accomplishing the basic definition of requirement ontology is adopted from
following activities: (i) the systematic organization of Lee and Zhao [20] who used ontological principles to
requirements via a requirements graph helps GSD teams extract domain requirements by considering mutual
understand software requirements with respect to different exclusion as the predicted relationship. In real-life sce-
time zones and distance, and the GSD sites at which the narios, cross-cutting (also called intersecting) requirements
requirement(s) are developed; (ii) the preparation of a often exist which are not covered in their work. To
requirements specification document with cooperation incorporate the feature of cross-cutting requirements and to
from the members of different GSD sites; and (iii) add details on GSD projects, we extend their work by
obtaining assurance that the requirements written in the defining necessary postulates for them. Ontology is a six-
SRS document are consistent and meet the needs of element set consisting of concepts, relationships, postu-
stakeholders in a globally distributed environment. lates, locations and time zones of GSD teams. We deal
Past researchers used student groups in a university mainly with finite space (resulting in finite sets); therefore,
environment to play the roles of stakeholders in mentioning it as an element in the definition of

123
Requirements Eng (2017) 22:191–214 193

Fig. 1 Our method of software requirements specification and validation for GSD

requirements ontology is not important. Thus, ONT = (- multiple classes (CON1, CON2, CON3…) correspond with
CON, REL-CON, POST, REL-POST, GLOC, GTZONE), exactly one class (CON1)
where CON is the collection of concepts/requirements, Postulate 3: For all CON1, CON2, CON3… CON, a many-
REL-CON is the relationship between concepts, POST is to-many relationship (REL) exists between them, only if
the set of rules for CON and REL, REL-POST is the rela- multiple classes (CON1, CON2, CON3…) correspond with
tionship exists in postulates (REL1-POST  REL-POST), other multiple classes (CON1, CON2, CON3…)
GLOC = location of GSD team, and GTZONE = time Postulate 4: For all CON1 and CON2  CON, a symmetrical
zone of GSD team. We consider four different relationships relationship (REL) exists between them, only if
between concepts: association (i.e. pre/post conditions), CON1 ðREL ÞCON2 ) CON2 ðREL ÞCON1
composition (i.e. part/whole), mutual exclusion and inter-
Or
section. The postulates (POST) and the relationships
expressed in postulates (REL-POST) are defined below: REL ðCON1 ; CON2 Þ ¼ REL ðCON2 ; CON1 Þ

Postulate 1: For all CON1, CON2  Postulate 5: For all CON1, CON2, CON3  CON, a transitive
CON, a one-to-one relationship (REL) exists between relationship (REL) exists between them, only if
them, only if exactly one CON1 relates with exactly one CON1 ðREL ÞCON2 ; CON2 ðREL ÞCON3 ) CON1 ðREL ÞCON3
CON2 (i.e. direct functional), or vice versa.
Or
Postulate 2: For all CON1, CON2, CON3…  CON, a many-
to-one relationship (REL) exists between them, only if REL ðCON1 ; CON2 Þ; REL ðCON2 ; CON3 Þ ) REL ðCON1 ; CON3 Þ

123
194 Requirements Eng (2017) 22:191–214

Postulate 6: For all CON1 and CON3  CON-A, and CON2  GLOC = location of GSD team, GTZONE = time zones of
CON-B, an injective relationship exists between them, GSD team.
only if
2.1.2 Step 2: Decomposition of the main requirements
fCON1 ðREL ÞCON2 g and
fCON3 ðREL ÞCON2 g ) CON1 = CON2
The requirements identified in step 1 are decomposed into
Postulate 7: For CON1  CON, a reflexive relationship sub-requirements, and appropriate relationships are estab-
(REL) exists between them, only if lished between them (refer to Fig. 2). The process of
CON1 ðREL ÞCON1 requirements decomposition is conducted on the basis of
ontological principles and continues until no further divi-
Postulate 8: For all CON1, CON2, CON3  CON, a sion is possible. Thus, we can say that:
composite relationship (REL) exists between them, only
REQUIREMENTS ¼ fCON ; REL-CON ; POST ; REL-POST ;
if
GLOC ; GTZONE g
FðCON1 Þ ¼ i¼1 \2 CONi
where CON = collection of concepts/requirements, REL-
GðCONi Þ ¼ i¼1 \2 CONij
  CON = relationship between concepts, which can be asso-
ðFðREL ÞGðCONi ÞÞ ¼ FðGðCONi ÞÞ ¼ F i¼1 \2 CONij ciation (i.e. pre/post conditions), composition (i.e. part/
¼ i¼1 \2 j¼1 \2 CONij whole), mutual exclusion and intersection. POST = set of
rules for CON and REL, REL-POST = relationship exists in
Postulate 9: For all CON1, CON2, CON3  CON, a distributive postulates, which can be one-to-one, many-to-one, many-to-
relationship (REL) exists between them, only if many, symmetrical, transitive, injective, reflexive, com-
posite, distributive and associative relationships, GLOC =
fCON1 ðREL-A ÞðCON2 ðREL-B ÞCON3 Þg
location of GSD team, GTZONE = time zones of GSD team.
¼ fðCON1 ðREL-A ÞCON2 ÞðREL-B ÞðCON1 ðREL-A ÞCON3 Þg; Figure 2 presents the structure of a requirements graph
Here, REL-A = Intersection operation ð\Þ; (G) which contains a collection of nodes (N) and edges (E),
and REL-B = Union operation ðUÞ such that G = (N, E). In graph G, each node provides
Or information on a particular requirement, which could be
either a main or sub-requirement, and the locations and
fCON1 \ ðCON2 [ CON3 Þg
time zones of GSD teams at which the requirements are
¼ fðCON1 \ CON2 Þ [ ðCON1 \ CON3 Þg developed. However, each edge represents a relationship
between two requirements. The information therefore
Postulate 10: For all CON1, CON2, CON3  CON, an obtained from the requirements graph will be recorded in a
associative relationship (REL) exists between them, only tabular format, where a numeric value will be assigned to
if each requirement for tracking purposes.
fCON1 ðREL ÞðCON2 ðREL ÞCON3 Þg
¼ fðCON1 ðREL ÞCON2 ÞðREL ÞCON3 Þg 2.2 Stage 2: Preparation of SRS document

After generating the requirements graph, details on the

2.1.1 Step 1: Identification of main requirements technical and non-technical aspects of the software project
will be recorded in a requirements document, using the
The graph generation process begins with the identification prototype for software requirements specification. The
of the main requirements and the locations and time zones prototype presented is based on [17] and later modified to
of GSD sites, at which these requirements could possibly cover GSD aspects. The following information is new in
be developed, from the information gathered during our requirements document: (i) information about the GSD
requirements elicitation and analysis. Thus, we can say sites where the requirements are developed; (ii) the loca-
that: tions and time zones of each GSD team; (iii) the list of
communication modes, mechanisms and tools used by each
Project ¼ fREQUIREMENTS ; REL-CON ; PRO-DOMAIN ;
GSD team for communication purposes; (iv) details about
GLOC ; GTZONE g the development teams responsible for the development of
where REQUIREMENTS = main functional and non-func- certain aspects of a GSD project; (v) the list of directly and
tional requirements, REL-CON = part/whole relationship, indirectly affected project modules; and (vi) the non-
PRO-DOMAIN = problem domain that is finite in nature, functional requirements which are affected due to the

123
Requirements Eng (2017) 22:191–214 195

P
lingual, temporal, cultural and geographical aspects of ða  aÞðb  bÞ 
GSD. A detailed description of the elements of the proto- CCpAB ¼ qffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi
P ffi ð2Þ
type is presented in Table 1. ða  aÞ2 ðb  bÞ 2

In Eq. 2, A and B are the requirements property matrices

2.3 Stage 3: Finalization of SRS document
generated at different GSD sites, a is the list of elements in
the matrix A, a is the mean of all elements in matrix A, and
Once the initial version of the SRS document is generated, it  The result of the correlation coeffi-
the same for b and b:
will be communicated along with the requirements graph to
cient falls between -1 and 1, where results close to -1
other development sites to review its content and later update
indicate that a significant difference exists between the
different elements of the requirements graph and SRS, if
outcomes of different GSD sites, and the requirements
required. This process will be continued until the contents of
written in SRS do not satisfy the validation properties listed
SRS are finalized between the different GSD sites.
in Sect. 2.4. However, results close to 1 indicate that a
minor difference exists between the outcomes of different
2.4 Stage 4: Validation at different sites
GSD sites, and the requirements written in SRS satisfy
most of the validation properties listed in Sect. 2.4.
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
3 The online shopping system (OSS) case study
requirement must be acceptable to the stakeholders
responsible for it; ambiguity—every requirement must
Client XYZ is located in Australia and has been involved in
have only one interpretation; completeness—the require-
the merchandising business for the last several years,
ments written in the SRS document should be complete;
selling products to the Australian market. The client con-
verifiability—every requirement must have an associated
siders the needs of the customer to be very important and
acceptance criterion to verify them after implementing the
wants to ensure a positive relationship exists with them.
requirement; understandable—every requirement must be
The client’s motive is ‘‘to sell reliable and quality products
clear to all groups of stakeholders.
to a broad range of customers at affordable prices’’. Due to
Two matrices A and B of m 9 n elements will be gen-
team work, dedication, a clear focus and well-defined
erated at different GSD sites, where m indicates the total
marketing strategies, the client holds a respectable position
number of requirements which need to be validated and n
in the Australian merchandising arena.
indicates the total number of properties which will be used
Client XYZ wants to develop an online shopping system
to validate the requirements (refer to Eq. 1). Depending on
for their organization. In the shopping system, the fol-
the results of the validation process, these matrices will be
lowing features are required: (i) facilitate customers/end-
filled with values ‘‘1’’ and ‘‘0’’, where 1 means ‘‘property is
users in purchasing different products, tracking their
satisfied’’ and 0 ‘‘property is not satisfied’’.
orders, viewing sellers’ information, and make payments

ð1Þ

2.5 Stage 5: Validation between different sites via a secure payment platform; (ii) facilitate XYZ in:
selling different products, managing information about
The matrices generated in stage 4 will be compared by customers (i.e. shoppers) and wholesale merchandisers (i.e.
computing the correlation coefficient (CCpAB) for them sellers), manage all the orders made by the customers, and
(refer to Eq. 2) [28].

123
196 Requirements Eng (2017) 22:191–214

Fig. 2 Structure of a requirements graph

manage information about the products sold or still avail- 4 Applying our method to the case study
able; and (iii) easy-to-use graphical user interface (GUI).
The software organization ALPHA designs, defines and Past researchers used student groups in a university envi-
delivers a broad range of IT solutions which include: ronment to play the roles of stakeholders in experiments in
software development; hardware and software installations; GSD studies [4, 21, 30, 35]. Hence, we simulated the
network maintenance and management; desktop support development of GSD requirements of XYZ using our
and maintenance; and technological upgrades. The main method by creating a virtual environment for GSD within
site (headquarters) of ALPHA is located in Australia, and the vicinity of La Trobe University, Australia. In this vir-
the offshore sites are located in India and China. Since its tual environment, the roles of the stakeholders were played
beginning, ALPHA has proven itself to be a highly com- by a group of students. With the limitations of a controlled
mitted organization which wants to deliver the best possi- GSD experiment, the differences in language and cultural
ble IT solutions at affordable prices. setups were simulated by ensuring maximal participation
Client XYZ contacted the software development of students from different cultures and backgrounds.
organization ALPHA for the development of an online Moreover, the geographical difference was simulated by
shopping system. Based on conversations with the client, ensuring that the students who performed the roles of the
the analysts and requirements engineers of ALPHA requirements engineer and analyst have never met the
gathered and analysed details about the shopping system. students who performed the role of the designer, and can
After collecting and analysing the requirements of the only talk via the identified communications tools.
shopping system, the analysts, requirements engineers and We selected 8 undergraduate and graduate students from
designers of ALPHA started the process of software the Department of Computer Science and Computer
requirements specification and validation. The client, Engineering, La Trobe University, Australia, and divided
requirements engineers and project analysts of ALPHA them into three teams. The teams consisted of 2, 3 and 3
are located in Australia, and the designers are located in students who played the roles of the analyst, the require-
India. ments engineers and the designers, respectively. Basic

123
Requirements Eng (2017) 22:191–214 197

Table 1 Prototype for software requirements specification

Item Description

Introduction Purposea Describe the overall purpose of SRS and provide details about the different types of persons
who will read or use the SRS document, such as document writers, developers, designers,
project analysts or managers, testers and users
Scopea Provide details about the name, scope, goals and benefits of the software product that will be
described in SRS
Acronyms and definitionsa Define the necessary terminologies, acronyms and list of abbreviations that will be used
throughout the SRS document
Referencesa Provide details about the documents or any external pieces of information that are referred to
in the SRS document. Details provided in this regard should be significant enough for a
reader to access each reference
Overview of SRSa Describe the structure of the SRS document to assist the readers
General Product perspectivea Describe the overall context of the software product being detailed in SRS. Particularly, if the
description specified software product is a new release of the existing software, a modification to the
existing systems, or a part of a larger system, then details regarding these aspects should be
clearly stated in SRS
Product functionsa Briefly explain the main functionalities of the software product that will be performed either
by the product itself or by the user. Later, provide detailed descriptions of these
functionalities in the subsequent sections
User classes and Provide details about the different user classes that could possibly use the software product,
characteristicsb including a list of the most and least important user classes
Locations and time zonesb Record the geographical, temporal and contact details of each user class
Communication medium used Provide details about the communication modes, mechanisms and tools that will be used for
by user classesb communication purposes between different user classes
Operating environmenta Provide a list of software and hardware platforms that will be required to operate the software
product
Design and implementation Provide details about the government policies, hardware and software limitations, language
constraintsa requirements, security issues and design conventions that could possibly limit the
functionality of the software product
User documentationa Provide details about the user manuals and tutorials that will be delivered along with the
software product
Assumptions and List all the assumptions and dependencies that could possibly affect the requirements
dependenciesa specified in the SRS document
Specific requirements
Functional Introductiona Provide a short description of each functional requirement
requirements Requirements ida State the identification number of each requirement
Prioritya State the priority of each requirement
Child and parent Provide details about the list of child and parent requirements
requirementsa
Inputa List all the possible sources of input, work deadlines, valid inputs, control requirements and
references to interface specifications
Processinga Define the set of operations that could be performed on input data and the parameters to
achieve output. The operations include validity test for input data, execution flow, system
behaviour for normal and abnormal situations, and an approach to transform input into
output
Outputa Provide details about the output state, including range of valid and invalid outputs, references
to the interface specification document, timing to achieve output, and list of possible error
messages
Developed at user classb Record details about the role and location of the user class that is responsible for the
development of each requirement
Direct and indirect project Keep track of project modules, including the role and location of the responsible user class
modulesb that will be affected either directly or indirectly, if potential changes will occur in software
product requirements

123
198 Requirements Eng (2017) 22:191–214

Table 1 continued
Item Description

External
Interface
Usera Specify the list of characteristics that the software should maintain for each user interface
Hardwarea Specify the list of devices that should be supported and the ways by which they are meant to be supported
Softwarea Specify the list of additional software products that should be required
Comm.a Specify the list of network protocols that should be used for interfacing purposes
Non-functional Performanceb Provide details about all the performance aspects of the software product
requirements Safety b
List any possible damages or losses that could affect the software product. In addition, details about the
necessary steps to prevent damage should also be listed
Securityb Specify privacy and security requirements that could affect the software product
Qualityb Provide details about quality characteristics for the software product that will be significant for
stakeholders. These characteristics include availability, usability, reliability, robustness, correctness,
interoperability, flexibility, maintainability, adaptability and testability
Other requirementsa Describe any piece of requirement that is not covered elsewhere in the specification document
a b
Generic attributes, GSD-specific attributes

knowledge about the experimentation process, their roles different functional requirements in Fig. 3 are listed in
and responsibilities, and the list of things which was Table 3.
expected from them were given to them via information
sessions. Interaction between the different student teams 4.2 Stage 2: Preparation of the SRS document
was performed via by a set of synchronous and asyn-
chronous collaboration tools. In the following subsections, After generating the requirements graph, the members of
we describe how our method is implemented using the the requirements engineers and analyst teams started the
student groups. preparation of the SRS document for the online shopping
system. Thereafter, these teams prepared the initial version
4.1 Stage 1: Generation of requirements graph of the document (refer to ‘‘Appendix 2’’).

To initiate the process of software requirements specifica- 4.3 Stage 3: Finalization of the SRS document
tion and validation, the members of the requirements
engineers and the analyst teams used the requirements of a Following the processes of graph generation and the
shopping system. From the information obtained, they preparation of the SRS document, the members of the
extracted details about the main functional and non-func- requirements engineers and analyst teams contacted the
tional requirements of the OSS, and details on the GSD members of the design team to discuss the project
sites at which these requirements could possibly be requirements. They organized a videoconferencing session
developed. In addition, they defined possible type(s) of and explained the content of the requirements graph and
relationship(s) which could exist among requirements. the SRS document to the members of the design team.
After the identification of the main requirements, they During this process, all the members examined the
decomposed the entire set of main requirements into their requirements in a detailed manner. As a result, they were
constituent sub-requirements on the basis of ontological able to identify areas that required further clarification and
principles. The process continued until all the sub-re- attention. For instance, details regarding input, output and
quirements were obtained and organized to form a external interfaces of the ‘‘make payment’’ and ‘‘payment
requirements graph (refer to Fig. 3). mechanism’’ requirements were not clear in the SRS doc-
All the functional requirements in the requirements ument. All the team members made an effort to address this
graph have an associated non-functional requirement(s), a issue. Similarly, the team members identified different
relationship(s) which exists with other requirement(s), and issues from the requirements graph and the SRS document,
the location and time zones of the potential GSD teams. addressed them in additional videoconferencing sessions,
The functional and non-functional requirements and details and finalized the content of the SRS document. In total,
on the locations and time zones of GSD teams are listed in they organized four videoconferencing sessions of
Table 2. However, details on the relationships between the approximately 30 min each.

123
Requirements Eng (2017) 22:191–214 199

Fig. 3 Requirements graph of an online shopping system

4.4 Stage 4: Validation at different sites with 1 and 0, where 1 indicates ‘‘validation property is
satisfied’’ and 0 ‘‘validation property is not satisfied’’.
After finalizing the content of the SRS document, the
members of the requirements engineers, the analyst and the 4.5 Stage 5: Validation between different sites
design teams began the process of requirements validation.
They evaluated each requirement, written in the SRS Finally, the members of the requirements engineers, the
document, by evaluating them with respect to the proper- analyst and the design teams organized a videoconferenc-
ties mentioned in Sect. 2.4. Using Eq. (1), the requirements ing session to compare their matrices (refer to Tables 4 and
engineers and the analyst teams generated matrix-1 (refer 5). During the session, they considered one requirement at
to Table 4) and the design team generated matrix-2 (refer a time and compared their results by computing the cor-
to Table 5). Depending on the results of the requirements relation coefficient for them. The results obtained after
validation, the team members populated Tables 4 and 5 applying Eq. (2) are presented in Table 6. The results vary

123
200 Requirements Eng (2017) 22:191–214

Table 2 Functional and non-functional requirements of the online shopping system

Requirement Functional Associated non-functional requirements Location of GSD team Time zone of GSD team
identifier requirements

1 – Performance, safety, security, usability, support, Client = Australia Australia = GMT ? 10

availability, localizability, reliability Requirements India = GMT ? 5.30
2 Service module Performance, safety, security, usability, support, engineer = Australia China = GMT ? 8.00
availability, localizability, reliability Analyst = Australia
3 Purchase Performance, safety, security, availability, usability Designers = India
4 Browse Performance, availability Development team-
catalogue 1 = India
5 Select product Performance, availability Development team-
6 Make payment Performance, availability, safety, security, reliability 2 = China
7 Place order Performance, security, usability, support, availability,
localizability
8 Order tracking Performance, availability, reliability, security
9 Provide order Security, safety, availability
details
10 Track orders Performance, security, safety
11 Seller Performance, availability, usability
information
12 Select seller Performance
13 View Availability, usability
information
14 Payment module Performance, safety, security, usability, support,
availability, localizability, reliability
15 Payment Performance, security, safety, availability, usability,
mechanism reliability
16 Payment via Performance, security, safety, availability, reliability
credit card
17 Supply card Security, safety, availability, reliability
details
18 Verify card Performance, security, safety, reliability
details
19 Authentication Performance, security, availability, reliability
mechanism
* Refer ‘‘Appendix 1’’ for details on non-functional requirements

between -1 and 1, where -1 indicates that a significant issues. It took 2.5 h to complete this videoconferencing
difference exists between the outcomes different GSD session.
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 dif- 5 Applying the conventional method to the case
ferent GSD sites, and the requirements written in SRS study
satisfy most of the validation properties.
From the results in Table 6, the teams identified that the To evaluate the effectiveness of the proposed requirements
overall correlation for the two matrices is 0.75, which specification and validation method, the conventional RE
means that the matrices generated by the different teams method that does not consider GSD specifics was used for
are approximately similar and satisfied most of the vali- the same GSD project. To avoid learning effect, a different
dation properties. In addition, there were three require- group of 8 undergraduate and graduate students from the
ments in the SRS document that were not validated. The Department of Computer Science and Computer Engi-
correlation coefficients for these requirements are 0.61 for neering, La Trobe University, Australia, were selected and
requirement identifier 3, 0.66 for requirement identifier 8, later divided into three teams. The teams consisted of 2, 3
and 0.66 for requirement identifier 16. All the teams and 3 students who played the roles of the analysts, the
analysed each of these requirements and addressed the requirements engineers and the designers, respectively.

123
Requirements Eng (2017) 22:191–214 201

Table 3 Relationship between the requirements of the OSS

Functional requirements Source/destination Relationship types
requirements

2. Service module Project (S) Service module is a part of project (SR)

Purchase (D) Purchase is a part of service module (DR)
3. Purchase Service module (S) Purchase is a part of service module (SR)
Browse catalogue (D) Browse catalogue is a pre-condition of purchase (DR)
Select product (D) Select product is a pre-condition of purchase (DR)
Make payment (D) Make payment is a pre-condition of purchase AND a part of payment via
Place order (D) credit card (DR)
Place order is a pre-condition of purchase (DR)
4. Browse catalogue Purchase (S) Browse catalogue is a pre-condition of purchase (SR)
Not applicable (D) – (DR)
5. Select product Purchase (S) Select product is a pre-condition of purchase (SR)
Not applicable (D) – (DR)
6. Make payment Purchase (S) Make payment is a pre-condition of purchase
Payment via credit card (S) Make payment is a part of (intersection) payment via credit card (SR)
Payment via credit card (D) Make payment is a part of payment via credit card (DR)
7. Place order Purchase (S) Place order is a pre-condition of purchase (SR)
Not applicable (D) – (DR)
8. Order tracking Service module (S) Order tracking is a part of service module (SR)
Provide order details (D) Provide order details is a pre-condition of order tracking (DR)
Track orders (D) Track orders is a pre-condition of order tracking (DR)
9. Provide order details Order tracking (S) Provide order details is a pre-condition of order tracking (SR)
Not applicable (D) – (DR)
10. Track orders Order tracking (S) Track order is a pre-condition of order tracking (SR)
Not applicable (D) – (DR)
11. Seller information Service module (S) Seller information is a part of service module (SR)
Select seller (D) Select seller is a pre-condition of seller information
View information (D) View information is a pre-condition of seller information
12. Select seller Seller information (S) Select seller is a pre-condition of seller information (SR)
Not applicable (D) – (DR)
13. View information Seller information (S) View information is a pre-condition of seller information
Not applicable (D) – (DR)
14. Payment module Project (S) Payment module is a part of project (SR)
Payment mechanism (D) Payment mechanism is a part of payment module (DR)
Authentication Authentication mechanism is a part of payment module (DR)
mechanism (D)
15. Payment mechanism Payment module (S) Payment mechanism is a part of payment module (SR)
Payment via credit card (D) Payment via credit card is a part of payment mechanism (DR)
16. Payment via credit card Make payment (S) Payment via credit card is a part of make payment and payment mechanism
Payment mechanism (S) (SR)
Make payment (D) Make payment/supply card details/verify card details is a pre-condition of
Supply card details (D) payment via credit card (DR)
Verify card details (D)
17. Supply card details Payment via credit card (S) Supply card details is a pre-condition of payment via credit card (SR)
Not applicable (D) – (DR)
18. Verify card details Payment via credit card (S) Verify card details is a pre-condition of payment via credit card (SR)
Authentication mechanism (S) Verify card details is a pre-condition of authentication mechanism (SR)
Not applicable (D) – (DR)

123
202 Requirements Eng (2017) 22:191–214

Table 3 continued
Functional requirements Source/destination Relationship types
requirements

19. Authentication mechanism Payment module (S) Authentication mechanism is a part of payment module (SR)
Verify card details (D) Verify card details is a pre-condition of authentication mechanism
Note S = source requirement, D = destination requirement, SR = relationship (in italics) between functional and source requirements,
DR = relationship (in italics) between destination and functional requirements

Table 4 Validation matrix

Requirements identifier Validation properties
generated by the requirements
engineers and analyst teams Acceptability Ambiguity Completeness Verifiability Understandable

1 1 1 1 1 1
2 1 1 1 1 1
3 1 1 1 1 0
4 1 1 1 1 1
5 1 1 1 1 1
6 1 1 1 1 1
7 1 1 1 1 1
8 1 0 0 1 0
9 1 1 1 1 1
10 1 1 1 1 1
11 1 1 1 1 1
12 1 1 1 1 1
13 1 1 1 1 1
14 1 1 1 1 1
15 1 1 1 1 1
16 1 0 0 1 1
17 1 1 1 1 1
18 1 1 1 1 1
19 1 1 1 1 1

Basic knowledge about the experimentation process, their 5.2 Requirements validation
roles and responsibilities, and the list of things which was
expected from them was given to them via information After completing the requirements specification process,
sessions. Interaction between different student teams was the requirements engineers, the analysts and the designers
performed via by a set of synchronous and asynchronous began the requirements validation process in a videocon-
collaboration tools. ferencing session. During the process, they evaluated each
In the following, we describe how the student groups requirement, written in the SRS document, using the tra-
used the conventional RE method to perform requirements ditional contract-style requirements list by evaluating them
elicitation and analysis in GSD environment. with respect to the following properties of requirements
validation: acceptability—every requirement must be
5.1 Requirements specification acceptable to the stakeholders responsible for it; ambigu-
ity—every requirement must have only one interpretation;
After gathering and analysing the requirements, the completeness—the requirements written in the SRS docu-
requirements engineers and the project analysts prepared ment should be complete; verifiability—every requirement
the SRS document using [17]. Details of the SRS document must have an associated acceptance criteria to verify them
are presented in ‘‘Appendix 3’’. after implementing the requirement; understandable—

123
Requirements Eng (2017) 22:191–214 203

Table 5 Validation matrix

Requirements identifier Validation properties
generated by the design team
Acceptability Ambiguity Completeness Verifiability Understandable

1 1 1 1 1 1
2 1 1 1 1 1
3 1 0 1 1 0
4 1 1 1 1 1
5 1 1 1 1 1
6 1 1 1 1 1
7 1 1 1 1 1
8 1 0 0 1 1
9 1 1 1 1 1
10 1 1 1 1 1
11 1 1 1 1 1
12 1 1 1 1 1
13 1 1 1 1 1
14 1 1 1 1 1
15 1 1 1 1 1
16 1 0 0 1 0
17 1 1 1 1 1
18 1 1 1 1 1
19 1 1 1 1 1

every requirement must be clear to all groups of stake- working with the other teams. In step 3, we asked the teams
holders [22] (refer to Table 7). They populated Table 7 to state the frequency of conflicts which occurred during
with 1 and 0, where 1 indicates ‘‘validation property is requirements specification and validation. In step 4, we
satisfied’’ and 0 ‘‘validation property is not satisfied’’. interviewed the teams about the number of rounds per-
Thereafter, by scanning the outcomes of Table 7, they formed for requirements validation during the used RE
came to conclusion that there are many requirements in the methods. In step 5, we interviewed the teams about the
SRS document, for which some of the validation properties time spent on different activities of requirements specifi-
are not satisfied yet. cation and validation. Finally, we analysed and discussed
To validate the non-validated requirements, all the the data obtained during these steps.
stakeholders (i.e. requirements engineers, project analysts
and designers) organized three videoconferencing sessions 6.1 Usefulness of our RE methods
at the agreed time to discuss and resolve the outstanding
issues in requirements validation. To determine the level of usefulness of the proposed and
the conventional requirements specification and validation
methods, we asked members of the requirements engineer,
6 Discussions of the results analyst and design teams, in both project settings, to rate
the different activities (also called aspects) of the used
To validate our work, we used a case study of an OSS. A method on a scale of 1 to 4, where 1 indicates ‘‘not useful’’,
detailed description of the case study settings and a step- 2 ‘‘less useful’’, 3 ‘‘useful’’ and 4 ‘‘very useful, based on
by-step demonstration of the proposed and the conven- their level of involvement in the various aspects. To ana-
tional RE methods were detailed in Sections 4 and 5. After lyze the data gathered in this step, we used Descriptive
completing the requirements specification and validation statistics to determine the level of usefulness. The results
processes for both methods, we interviewed the student obtained after applying the Descriptive statistics are pre-
teams in five steps about their experiences in relation to the sented in Tables 8 and 9.
different aspects of the used methods. In step 1, we inter- From the results shown in Tables 8 and 9, it can be seen
viewed teams about the level of usefulness of the different that overall, the respondents from different teams rated the
aspects of requirements specification and validation. In step different aspects of the proposed requirements specification
2, we investigated the level of comfort felt by each team in and validation as either useful or very useful for the

123
204 Requirements Eng (2017) 22:191–214

accomplishment of the above-mentioned aspects. The pri- about the GSD sites at which the requirements were
mary reasons why our method was considered useful than developed. As a result, the GSD teams found our method
the conventional method are as follows: (i) the information useful to interpret and understand the software require-
in the requirements graph helped GSD teams in different ments in a consistent manner; (ii) in comparison with
geographical locations to identify the main and sub-re- conventional requirements specification methods, the pro-
quirements, the relationships between them, and details posed 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
Table 6 Correlation coefficient for requirements validation by each group of stakeholders for communication pur-
Requirements identifier Correlation coefficient poses, to provide details about the development teams
responsible for the development of certain aspects of a
1 1
GSD project, and to produce a list of directly and indirectly
2 1 affected project modules as well as a list of non-functional
3 0.612372 requirements that could be affected due to the lingual,
4 1 temporal, cultural and geographical differences between
5 1 GSD teams; and (iii) it helped the teams validate the
6 1 contents of the SRS document and ensure the quality of the
7 1 requirements written in the SRS document.
8 0.666667
9 1 6.2 Level of comfort working with other teams
10 1
11 1 To determine the level of comfort student teams felt in
12 1 working with other teams, the members of the requirements
13 1 engineer, analyst and design teams were asked to rate their
14 1 level of comfort on a scale of 1 to 4, where 1 indicates ‘‘not
15 1 comfortable’’, 2 ‘‘less comfortable’’, 3 ‘‘comfortable’’ and
16 0.666667 4 ‘‘very comfortable’’, based on their level of involvement
17 1 in the GSD project. To analyze the data gathered in this
18 1 step, we used the Descriptive statistics to determine the
19 1 level of comfort. The results obtained after applying the
Overall coefficient 0.754965 Descriptive statistics are presented below.

Table 7 Requirements
Functional requirements Validation properties
validation via contract-style
requirements list Acceptability Ambiguity Completeness Verifiability Understandable

Service component 1 1 1 1 1
Purchase goods 1 1 1 1 1
Browse catalogue 1 1 1 1 1
Select product 1 1 1 1 1
Make payment 1 0 0 0 0
Order placement 1 1 1 1 1
Supply order details 1 1 1 1 1
Order tracking 1 1 1 1 1
Information about seller 1 1 1 1 1
View seller information 1 0 0 0 0
Payment component 1 0 0 0 0
Payment procedure 1 0 0 0 0
Payment using credit card 1 1 1 1 1
Supply card details 1 1 1 1 1
Authentication mechanism 1 0 0 1 1

123
Requirements Eng (2017) 22:191–214 205

Table 8 Mean level of

Different aspects N Mean Median Minimum Maximum
usefulness of different aspects
of the proposed requirements Interpreting requirements 8 3.625 4 3 4
specification and validation
method Understanding requirements 8 3.75 4 3 4
Validating requirements 8 3.625 4 3 4

Table 9 Mean level of

Different aspects N Mean Median Minimum Maximum
usefulness of different aspects
of the conventional Interpreting requirements 8 1.714 2 1 2
requirements specification and
validation method Understanding requirements 8 1.571 2 1 2
Validating requirements 8 1.571 2 1 2

Table 10 Mean level of comfort expressed by the requirements Table 11 Mean level of comfort expressed by the requirements
engineers on the other teams in the proposed method engineers on the other teams in the conventional RE method
N Mean Median Minimum Maximum N Mean Median Minimum Maximum

Analyst 3 4 4 4 4 Analyst 3 1.66 2 1 2

Designers 3 3.33 3 3 4 Designers 3 1.33 1 1 2

Requirements engineers versus other teams: Tables 10 conflicting to organize the obtained pieces of software
and 11 present details regarding the level of comfort the requirements with respect to the GSD sites at which the
requirements engineers team expressed on the other teams requirement(s) are developed; (ii) the systematic organi-
in the proposed and the conventional methods of RE, zation of software requirements helped the teams in
respectively. establishing and maintaining a consistent interpretation of
Analysts versus other teams: Tables 12 and 13 present software requirements across different time zones and
details regarding the level of comfort the analyst team geographical locations; (iii) the availability of informa-
expressed on the other teams in the proposed and the tion on all aspects of the prospective software system in
conventional methods of RE, respectively. GSD environment helped the teams in obtaining the
Designers versus other teams: Tables 14 and 15 present required piece of information at the right time, which is
details regarding the level of comfort the design team even not available in the IEEE requirements specification
expressed on the other teams in the proposed and the document [17]; (iv) although there was a lack of face-to-
conventional methods of RE, respectively. face contact among the teams, the identification of suit-
able communication modes, mechanisms, tools and a
6.3 Frequency of conflicts mutually convenient time for communication helped the
teams engage in discussion in a virtual environment; and
In step 3, we asked each team to state the frequency of (v) the matrix-based process facilitated the teams to
conflicts which occurred during the different activities of validate the requirements, initially at their local site, then
RE in relation to the proposed and conventional RE evaluate the outcomes of validation process with other
methods on a scale of 1 to 4, where 1 indicates ‘‘rarely’’, 2 teams by computing correlation coefficient, and at last
‘‘occasionally’’, 3 ‘‘less frequently’’ and 4 ‘‘very fre- identify and re-validate the non-validated requirements in
quently’’. To analyze the data obtained during this step, we a collaborative environment.
applied the Descriptive statistics. The results are presented
in Tables 16 and 17. 6.4 Number of rounds performed for requirements
From the results shown in Tables 16 and 17, it can be validation
seen that overall, the respondents from the different
teams indicated less conflicts during requirements speci- In step 4, we interviewed the relevant student teams in
fication and validation in the proposed method, mainly relation to the number of rounds performed for require-
due to the following: (i) as a result of the requirements ments validation during the different aspects of the pro-
gathered and analysed with respect to different time posed and conventional methods of RE. In Table 18,
zones and distance, the teams find it easier and non- details regarding the number of requirements validated at

123
206 Requirements Eng (2017) 22:191–214

Table 12 Mean level of

N Mean Median Minimum Maximum
comfort expressed by the
analysts on the other teams in Requirements engineers 2 4 4 4 4
the proposed method
Designers 2 3.5 3.5 3 4

Table 13 Mean level of

N Mean Median Minimum Maximum
comfort expressed by the
analysts on the other teams in Requirements engineers 2 2 2 2 2
the conventional RE method
Designers 2 1.5 1.5 1 2

Table 14 Mean level of

N Mean Median Minimum Maximum
comfort expressed by the
designers on the other teams in Requirements engineers 3 3.33 3 3 4
the proposed method
Analysts 3 3.33 3 3 4

Table 15 Mean level of

N Mean Median Minimum Maximum
comfort expressed by the
designers on the other teams in Requirements engineers 3 1.33 1 1 2
the conventional RE method
Analysts 3 1.33 1 1 2

Table 16 Mean frequency of

Different aspects N Mean Median Minimum Maximum
conflicts which occurred during
different aspects of the proposed Interpreting requirements 8 1.25 1 1 2
requirements specification and
validation method Understanding requirements 8 1.5 1.5 1 2
Validating requirements 8 1.375 1 1 2

Table 17 Mean frequency of conflicts which occurred during different aspects of the conventional requirements specification and validation
methods
Different aspects N Mean Median Minimum Maximum

Interpreting requirements 8 3.62 4 3 4

Understanding requirements 8 3.5 4 3 4
Validating requirements 8 3.62 4 3 4

Table 18 Details on the number of requirements validated

Round # of requirements validation Proposed method Conventional RE method

1 16 out of 19 requirements 10 out of 15 requirements

2 3 out of the remaining 3 requirements 2 out of the remaining 5 requirements
3 – 2 out of the remaining 3 requirements
4 – 1 out of the remaining 1 requirement
Total number of requirements validated 19 15

different rounds of requirements validation are presented. requirements validation. However, the students who
From the results shown in Table 18, it can be seen that the implemented the conventional RE method validated the
students who implemented the proposed method validated total number of 15 requirements in four rounds of
the total number of 19 requirements in two rounds of requirements validation.

123
Requirements Eng (2017) 22:191–214 207

Table 19 Time spent on requirements specification and validation to establish a consistent interpretation and understand-
Activities Time spent using the Time spent using the
ing of software requirements, and later validate the
proposed method conventional RE method software requirements in a geographically distributed
environment.
Requirements 400 Did not generate
graph In comparison with the findings made about the students
SRS report 550 who used the conventional RE method, the following
Validate 180 400 observations are made about the students who used the pro-
requirements posed method of requirements specification and validation.
Total time 581 min 950 min
(minutes) • The use of graph in our method helps GSD teams
Total time 9.66 h 15.83 h understand software requirements with respect to
(hours) different time zones and distance, and the GSD sites
at which the requirement(s) are developed. Thereafter,
6.5 Time spent on different activities of RE it helps GSD teams across different time zones and
locations in the preparation of the software require-
In step 5, we interviewed the relevant student teams in ments specification.
relation to the time spent on the different activities of RE • The requirements specification template, proposed as
using the proposed and conventional methods of RE. In part of the requirements specification and validation
Table 19, details regarding the time spent on requirements method, helped students (GSD teams) prepare an SRS
specification and validation are presented. From the results document. Our SRS document therefore contains
shown in Table 19, it can be seen that the students who information about the traditional aspects of a software
implemented the proposed method of requirements speci- project [17] and the peculiarities involved in GSD,
fication and validation spent 400 min to generate the which are missing in the IEEE specification guidelines.
requirements graph and prepare the software requirements • The matrix-based validation helps GSD teams examine
specification document, and 180 min to validate require- the requirements with respect to the validation proper-
ments written in the specification document, that makes the ties at different GSD sites, compare the outcomes of the
total of 580 min (9.66 h). However, the other groups of validation process with other teams by computing the
students who implemented the conventional RE method correlation coefficients, identify the requirements
took 550 min to prepare the requirements specification which do not satisfy the validation properties, and re-
document and 400 min to do requirements validation, thus evaluate the non-validated requirements in a globally
giving a total of 950 min (15.83 h). distributed environment.
Overall, the students rated different aspects of the pro-
6.6 Summary of the results
posed method as either useful or very useful for GSD,
expressed a higher level of comfort working with other
After analysing the results presented in the earlier sections,
teams, and the frequency of conflicts which occurred dur-
the following observation is made about the students who
ing the requirements specification and validation processes
used the conventional RE method.
was comparatively lower than the conventional RE
• Due to the non-availability of GSD-related information method. Considering the fact that students performed
in the SRS document, the student teams find it difficult additional activities to perform requirements specification
to gather information about the GSD sites at which the and validation, they are still able to finish the entire process
requirement(s) are developed, the locations and time in less time, than the groups of students who implemented
zones of each GSD team, the list of communication the conventional RE method. Thus, we can say that our
modes, mechanisms and tools used by each GSD team method is especially useful for those groups of stakeholders
for communication purposes, details about the devel- who are taking part in GSD for the first time or are not
opment teams responsible for the development of aware of the fundamental aspects and issues of RE in GSD.
certain aspects of a GSD project, the list of directly
and indirectly affected project modules, and the non- 6.7 Threats to validity
functional requirements which are affected due to the
lingual, temporal, cultural and geographical aspects of Our work has the following validity threats. We have
GSD. Also, the scattered presence (availability) of selected undergraduate and postgraduate students from the
requirements, gathered during requirements elicitation Department of Computer Science and Information Tech-
and analysis, made it challenging for the student teams nology, La Trobe University. The difference in educational

123
208 Requirements Eng (2017) 22:191–214

qualification can be a selection bias threat. The experiments As a result of the contributions of this related work, the
in this demonstration case study lasted for several months; following conclusions are made: (1) due to the lack of
events (examination pressure, work commitments, personal requirements specification methods in [23, 29], a judgement
issue etc.) occurred during this period could affect partici- about how to use these proposals and patterns to prepare an
pant’s behaviour and performance. None of the participants SRS document for a GSD project cannot be made; (2) in
have previous knowledge of GSD; the results obtained in [39], the authors examined the impact of different GSD
this experimental setup could be a threat to validity. factors on the traditional methods of requirements validation
When applying our method to the case study, the stu- and suggested that new methods are required for GSD
dents were from one university. Although we selected projects; and (3) although, the decision tree facilitates
students from different cultural backgrounds, the work stakeholders in the selection and utilization of appropriate
involving students from different universities with dis- practices for requirements validation, due to the lack of a
similar cultural backgrounds needs to be examined. Situ- methodical approach in [12], a judgement about how to use
ational specifics (e.g. location, time, supervision and role of this proposal to validate the requirements of industrial
investigator) can potentially limit the generalizability of projects cannot be made.
results. Researcher’s expectations and experiment bias can In the light of these findings, it can be said that these
also be a threat to validity. contributions lack methodical approaches to generate and
validate the SRS document. We have therefore addressed
these aspects in our work.
7 Related work

In the literature, only two papers have been published on 8 Conclusions and future work
GSD requirements specifications. In [23], the authors pre-
sent a five-step process of requirements specifications for The quality of software requirements specification is vital
geographically distributed software projects. As a part of to project success. Due to the influence of cultural differ-
these steps, the authors suggest that the requirements ences, language and communication barriers, difficulties in
specification document be circulated back and forth knowledge management and differences in time zones on
between the onshore and offshore development teams, until software development, the ways by which requirements are
all the details in the requirements document are finalized. documented and validated in collocated software devel-
However, the authors in [29] proposed the use of patterns opment cannot be used effectively in a globally distributed
to prepare the SRS document for GSD projects. These environment. To date, there are very few research papers
patterns are mainly related to defining use cases, collabo- available which describe the work done on GSD require-
ration among the analysts throughout the RE process and ments specification and validation. In this paper, we have
mapping business-related terminologies to the entity attri- therefore presented a method for this.
bute. With the help of these patterns, the authors aimed to Our method is beneficial for GSD teams in the following
address the following issues: the multiple definitions of use ways: (i) the use of graph in our method helped GSD teams
cases which often lead to misinterpretation; the challenges understand software requirements with respect to different
involved in knowledge transfer between development sites; time zones and distance, and the GSD sites at which the
and the difficulties in understanding and processing the requirement(s) are developed; (ii) it helped GSD teams
requirements specification document. In addition to these across different time zones and locations in the preparation
papers, two papers have been published on requirements of the SRS document. Our SRS document therefore con-
validation in GSD. In Yousuf et al. [39], a survey on the tains information about the traditional aspects of a software
existing methods of requirements validation is presented. project [17] and the oddness involved in GSD, which are
Based on the survey findings, the authors suggested that the missing in the IEEE specification guidelines; and (iii) the
factors of communication, control, knowledge sharing, matrix-based validation helped GSD teams examine the
delay and trust impact traditional methods of requirements requirements with respect to the validation properties at
validation and therefore cannot be used effectively for different GSD sites, compare the outcomes of the valida-
validation purposes in GSD projects. In [12], a proposal to tion process with other teams by computing the correlation
select and utilize practices for the early validation of coefficients, identify the requirements which do not satisfy
software requirements is presented. The authors presented the validation properties, and re-evaluate the non-validated
a decision tree to facilitate stakeholders in the selection and requirements.
utilization of different techniques and practices for To validate our method, we applied it to a case study of
requirements validation, where decisions are made on the an online shopping system, where the roles of stakeholders
familiarity and non-familiarity of requirements. were played by a group of students. Furthermore, we used

123
Requirements Eng (2017) 22:191–214 209

the conventional requirements specification and validation Appendix 2: Software requirements specification
method that does not consider GSD specifics for the same of online shopping system (Developed by using
GSD project, so that a comparison between the results proposed method)
could be made. The results showed that the proposed
method helped the student teams in preparing and vali- Introduction
dating the contents of SRS document for the requirements
of the online shopping system. As a result, the chances of Purpose of SRS: The SRS document describes the
requirements being misunderstood and misinterpreted by requirements for the online shopping system. For corre-
development teams could be possibly minimized, and the spondence purposes, the reference number of this SRS
time spent searching for information about the different document is V101-Online Shopping.
aspects of a GSD project could be reduced. The persons who will use this document are the
To examine how scalable our method is, we aim to find requirements engineers, project analysts, designers, devel-
a commercial partner, which would be prepared to col- opers and users from client XYZ. Any possible changes
laborate with us in experimenting our method in a real-life made in the requirements of the online shopping system
environment. will be recorded in the SRS document, and the latest ver-
sion will then be used by these groups of people.
Acknowledgments This work is supported by a La Trobe Univer- Scope of SRS: Client XYZ wants to develop a software
sity Postgraduate Write-up scholarship.
product called an ‘‘online shopping system’’ for their
organization by which they can sell different products to a
broad range of customers. The shopping system must be
Appendix 1
able to: (1) facilitate customers/end-users in purchasing
different products, tracking their orders, viewing sellers’
See Table 20.

Table 20 Description of non-functional requirements

Non-functional Description
requirements

Performance Response time- The system should be able to retrieve order details within 10 s
Workload- The system should be able to support 4 pages/second
Scalability- The system should be capable of supporting no less than 50 customers at a time when implemented
Platform- The system should be able to operate in Internet Explorer (v. 7 and later), Mozilla Firefox (v. 2 and later),
Google Chrome, and Opera
Security The shopping system must ensure that data about different types of transactions must be processed in a secured channel
Usability End-users with different background knowledge can easily place orders
Support Helpdesk support- Regardless of the time difference between Australia and offshore sites, 24/7 support will be required
for six months from the offshore sites
Network support- Should be provided 24/7 despite geographical dispersion
Application support- Should be provided 24/7 despite geographical dispersion
Database support- Should be provided 24/7 despite geographical dispersion
Administration support- Should be provided 24/7 despite geographical dispersion
Security support- Should be provided 24/7 despite geographical dispersion
Training support- Should be provided 24/7 despite geographical dispersion
Availability Orders can be placed 24/7. In case of unstable internet connection, the information necessary to place orders could be
send again
Localizability Although the system will be developed at offshore locations, localizability must be ensured with respect to Australian
traits
Safety To prevent possible data damages or losses, the shopping system must have a data recovery procedure
Reliability The system must be able to store database information on different computers to prevent it from possible losses and
damage

123
210 Requirements Eng (2017) 22:191–214

Table 21 List of acronyms and definitions XYZ and end-users. Requirements engineers, project ana-
Acronyms Meanings
lysts and designers are assumed to have detailed knowl-
edge of the overall requirements, and developers are more
FAQ Frequently asked questions aware about the development and technical aspects.
CRM Customer relationship management However, easy-to-use graphical user interfaces and user
IEEE The institute of electrical and electronics engineers documentation will be provided to educate client XYZ and
SRS Software requirements specification other end-users about how to use the shopping system.
GUI Graphical user interface Locations and time zones of user classes: Details about
HTTP Hyper text transfer protocol the location and time zones of each user class are given in
Table 22.
Communication modes, mechanisms and tools used by
information, and making payments via a secure payment user classes: Details about the communication modes,
platform; and (2) facilitate XYZ in selling different prod- mechanisms and tools that will be used by each user class
ucts, managing information about customers (i.e. shoppers) are mentioned in Table 23.
and wholesale merchandisers (i.e. sellers), managing all the Operating environment: The shopping system is a
orders made by the customers, and managing information website and should be able to operate in Internet Explorer
about the products sold or still available. (v.7.0 and later), Mozilla Firefox (v.2.0 and later), Google
Acronyms and definitions: (Table 21). Chrome and Opera.
References: The following references are used in the Design and implementation constraints: Details about
SRS document. the design and implementation constraints are given in
Table 24.
• IEEE 830 [17] standard for writing SRS document. User documentation: Four different types of documen-
• List of scenarios and use cases tation will be produced during the software development
• Sommerville [33] life cycle.
Overview of SRS: The remaining sections of the SRS • High-level description of the most important software
document are organized as follows. processes
• Section 4.2.2 defines the product perspective, func- • Data specification report for purchase orders, order
tions, user classes and characteristics, locations and tracking, seller information, and payment and authen-
time zones of user classes, list of communication tication mechanisms
modes, mechanisms and tools used between user • Online help about how to use the shopping system
classes, operating environment, design and implemen- • Feedback and error-reporting mechanisms to be used
tation constraints, user documentation, and assumptions by the system administrator
and dependencies. Assumptions and dependencies: The following assump-
• Section 4.2.3 specifies the details about functional and tions are made about the online shopping system
non-functional requirements.
• User and management-related processes are combined
at a central site, accept input and provide different
General description services to different users at different locations
• ASP.Net will be used as a development platform and
Product perspective: The online shopping system is a new the SQL server to store database
and stand-alone software product. Therefore, it is not a part • The shopping system will be easy to use by different
of a larger system or a modification of the existing systems. groups of users
There are two basic modules/components in the online • The performance of shopping system depends on the
shopping system. The first module is responsible for the speed of the internet
different types of services offered by the shopping system.
However, the second module covers the security aspect of
the shopping system. A detailed description of these Specific requirements
modules and their functionalities is listed in Sect. 4.2.3.
User classes and characteristics: The users who will There are different types of services and payment mecha-
interact with the shopping system are the requirements nisms in the online system. Detailed descriptions about
engineers, project analysts, designers, developers, client their associated requirements are listed below.

123
Requirements Eng (2017) 22:191–214 211

Table 22 Locations and time zones of user classes

User class Departments Managers Contact details Duties

Clients Information Technology Mr. ABC Australia, GMT ? 10, [email protected] Technology head
Sales/Pre-sales Mr. DEF Australia, GMT ? 10, [email protected] Senior sales officer
Marketing Mr. GHI Australia, GMT ? 10, [email protected] Marketing manager
Human Resource Mr. JKL Australia, GMT ? 10, [email protected] Human resource manager
Finance Mr. MNO Australia, GMT ? 10, [email protected] Senior financial officer
Analysts Information Technology Mr. PQ Australia, GMT ? 10, [email protected] Technology manager
Business Mr. RS Australia, GMT ? 10, [email protected] Business executive
Requirement engineers Information Technology Mr. TU Australia, GMT ? 10, [email protected] Requirements engineering
Information Technology Mr. VW Australia, GMT ? 10, [email protected]
Business Mr. XY Australia, GMT ? 10, [email protected]
Designers Information Technology Mr. AA India, GMT ? 5.30, [email protected] Product analysis and designing
Mr. BB India, GMT ? 5.30, [email protected]
Mr. CC India, GMT ? 5.30, [email protected]
Developers Information Technology Mr. DD India, GMT ? 5.30, [email protected] Development
Mr. EE China, GMT ? 8, [email protected]
End-users Could be any person from any part of the world

Table 23 List of communication modes, mechanisms and tools used by user classes
Communication task Communication User classes
aspect
Client Requirement Analysts Designers Developers
engineers

Project discussion Mode Verbal Verbal Verbal Verbal Verbal

Mechanism Audio/ Audio/video Audio/video Audio/video Audio/video
video
Tool Skype Skype Skype Skype Skype
Knowledge transfer Mode Written Written Written Written Written
and exchange Mechanism Messaging Messaging Messaging Messaging Messaging
Tool Emails Emails and instant Emails and instant Emails and instant Emails and instant
messaging messaging messaging messaging

Table 24 Design and implementation constraints

Constraints Definition

User rights and privileges Controlled via security groups and privileges for different user classes
Back-end database Information about services, security and management processes must be stored in a database
Training Management processes must provide training about how to use the software product in different scenarios
HTML compliance The product must be HTML compliant
User passwords Depending on privilege, passwords must be assigned to each group of users

Functional requirements Child requirement: Purchase, order tracking and seller

information
I. Services Parent requirement: Online shopping system
Introduction: Three different types of services are Input: Purchase details, order tracking information,
required: purchase; order tracking; and seller information sellers’ specification
Requirement id: 2 Processing:
Priority: High

123
212 Requirements Eng (2017) 22:191–214

• Purchase details browse catalogue, select product, Quality attributes:

payment, and place order.
• Usability End-users with different background knowl-
• Order tracking tracking criteria and shipping
edge can easily use the shopping system
information
• Support Regardless of the time difference between
• Sellers’ specification user rating and history
Australia, India and China, 24/7 helpdesk, network,
Output: application, database, administration, security and
training supports will be required for 6 months from
• Purchase details catalogue browsing, product selection,
the offshore sites
make payment and order placement.
• Reliability The system must be able to store database
• Order tracking track orders
information on different computers to prevent it from
• Sellers’ specification view seller information
possible losses and damage
Developed at user class: India • Localizability Although the system will be developed in
Direct and indirect affected requirements: Changes in India and China, localizability must be ensured with
the requirements of the service module will affect the respect to Australian traits
requirements of the payment module, developed at the • Availability The shopping system should be accessible
Chinese site. to users 24/7, except the specified maintenance period
External interfaces:
• User interface All the GUI’s must follow a similar Other requirements
theme and have a clear structure.
• Hardware interfaces The shopping system is a web- For further details, the user should refer to the following
based software product that should run easily on the documents.
aforementioned web browsers, and will be hosted on a
Use case documentation
Windows server.
• Software interfaces Any operating system capable of
running different web browsers could be used.
• Communication interfaces HTTP protocols must be Appendix 3: Software requirements specification
used to facilitate communications between client and of online shopping system (Developed by using
server machines. existing method)
II. Purchase
Introduction
Similarly, the requirements engineers and analysts
document details about other functional requirements.
Purpose: The SRS document provides information on the
requirements of the OSS. The reference number of the SRS
Non-functional requirements
document is SRS00-1/ONS.
The people who will use this document are the
Performance requirement:
requirements engineers, project analysts, designers, devel-
• Response timeThe system should be able to retrieve opers and users from client XYZ.
order details within 10 s Scope: Client XYZ wants to develop a software product
• Workload The system should be able to support 4 called an ‘‘online shopping system’’ for their organization.
pages/second The shopping system must be capable of providing the
• Scalability The system should be capable of supporting following functionalities:
no less than 50 customers at a time when implemented
• Facilitate customers/end-users in purchasing different
• Platform The system should be able to operate in
products, tracking their orders, viewing sellers’ infor-
Internet Explorer (v. 7 and later), Mozilla Firefox (v. 2
mation, and making payments via a secure payment
and later), Google Chrome and Opera.
platform.
Safety requirement: To prevent possible data damages • Facilitate XYZ in selling different products, managing
or losses, the shopping system must have a data recovery information about customers (i.e. shoppers) and whole-
procedure. sale merchandisers (i.e. sellers), managing all the orders
Security requirement: The shopping system must ensure made by the customers, and managing information
that data about different types of transactions must be about the products sold or still available.
processed in a secured channel. • Easy-to-use graphical user interface (GUI).

123
Requirements Eng (2017) 22:191–214 213

Table 25 List of acronyms and definitions used in the SRS document Processing: To process different types of
Acronyms Definition
inputs, the following mechanisms will be used:
Details of purchase- browse catalogue, select
FAQ Frequently asked questions product, make payment,
GUI Graphical user interface Information to track orders supply order details
IEEE The Institute of Electrical and Electronics Engineers Sellers’ specifications- seller history
SRS Software requirements specification Output: For each input, one of the following
TCP/IP Transfer communication protocol/internet protocol outputs will be generated.
Details of purchase order will be placed after
Definitions, acronyms and abbreviations: The following browsing the available catalogue
acronyms are used in the SRS document (refer to Information to track orders- order tracking
Table 25). Sellers’ specifications- view information about
References: The following reference is used in the SRS the seller’s rating and past history
document. External interfaces: For each of the external
interfaces, the specifications listed below will
• IEEE 830 [17] standard to write the SRS document. be used.
Overview of SRS: The SRS document is organized as User interface a clear and consistent theme
follows. should be used in all GUI’s
Hardware interface a Windows server
• A general description presents details on the product 2008–2010 will be used to host the OSS.
perspective and functions, user characteristics, design Software interface the versions of Mozilla
and implementation constraints, and assumptions and Firefox, Google Chrome and Internet Explorer
dependencies. released after the year 2005 will be used to run
• A specific requirements list which details the functional the OSS.
and non-functional requirements. Communication interface TCP/IP and HTTP
protocols must be used for communication
General description purposes.
(ii) Purchase
Product perspective: This is a new system which is neither Likewise, the requirements engineers and the
an extension of an old system nor a component of a larger project analysts documented details about the
system. other functional requirements.
Product function: The overall system has two main b. Performance requirements
modules that cover the different functionalities of services The overall performance of the shopping system
and payment features of the shopping system. mainly depends on the aforesaid hardware and soft-
User characteristics: The users who will interact with ware specifications.
the OSS are the requirements engineers, project analysts, c. Design constraints
designers, developers, and users from the client. Each of the developed subsystems must be traced back to
Design and implementation constraints: Depending on its associated use case and non-functional requirements.
the nature of the interaction, the rights and privileges must d. Attributes
be ensured for each group of users. Security- The possible transactions that occur in the
Assumptions and dependencies: The shopping system shopping system must be processed in a secured and
must be easy to use by different groups of users. encrypted channel.
Safety- To minimize data loss, safety measures must
Specific requirements be taken to prevent data.
Availability- The shopping system should be available
a. Functional requirements 24 h a day, 7 days a week.
(i) Services Reliability- The shopping system should be reliable
Introduction: The three types of services that
will be required are: purchase, order tracking
and seller information. Other requirements
Input: Details of purchase, information to track
orders, and sellers’ specifications. For further clarification, contact the project analyst.

123
214 Requirements Eng (2017) 22:191–214

References 21. Lloyd WJ, Rosson MB, Arthur JD (2002) Effectiveness of elic-
itation techniques in distributed requirements engineering. In:
1. Ali N, Lai R (2014) Managing requirements change in global IEEE joint international conference on requirements engineering
software development. In: IEEE international conference on data proceedings, pp 311–318
22. Lobo OL, Arthur JD (2005) Effective requirements generation:
and software engineering, Indonesia
2. Ali N, Lai R (2016) A method of requirements change manage- synchronizing early verification and validation, method and
ment for global software development. Inf Softw Technol methods selection criteria, Virginia Tech
70:49–67 23. Lopes L, Prikladnicki R, Audy J, Majdenbaum A (2005)
Requirements specification in distributed software development:
3. Atkins D, Handel M, Hersleb J, Mockus A, Perry D, Wills G
(2001) Global software development, the bell labs co-laboratory a process proposal. In: Proceedings of the 38th Hawaii interna-
in international conference on software engineering, Toronto tional conference system sciences (HICSS 05)
4. Babar MA, Kitchenham B, Jeffery R (2008) Comparing distributed 24. Paasivaara M, Durasiewicz S, Lassenius C (2008) Distributed
and face-to-face meetings for software architecture evaluation: a agile development: using scrum in a large project. In: IEEE
controlled experiment. Empir Softw Eng 13(1):39–62 international conference on global software engineering
5. Bartholomew R (2008) Globally distributed software develop- (ICGSE’08), pp 87–95
ment using an immersive virtual environment. In: IEEE inter- 25. Prikladnicki R, Audy JLN, Damian D, Oliveira TC (2007) Dis-
national conference on electro/information technology (EIT’08), tributed software development: practices and challenges in dif-
pp 355–360 ferent business strategies of off-shoring and on-shoring. In:
6. Berenbach B, Paulish DJ, Kazmeier J, Rudorfer A (2009) Soft- Second IEEE international conference on global software engi-
neering, pp 262–274
ware & systems requirements engineering. In Practice, Mcgraw-
Hill Professional 26. Prikladnicki R, Audy JLN, Evaristo R (2003) Global software
7. Brockmann PS, Thaumuller T (2009) Cultural aspects of global development in practice lessons learned. Softw Process Improv
requirements engineering: an empirical chinese-german case Pract 8(4):267–281
study. In: Fourth IEEE international conference on global soft- 27. Rickman DM (2001) A new process for requirements under-
ware engineering (ICGSE ‘09), pp 353–357 standing. In 20th Conference on digital avionics system, pp 4D4/
8. Conchuir EO, Holmström H, Ågerfalk PJ, Fitzgerald B, (2006) 1–4D4/6
Exploring the assumed benefits of global software development. 28. Rodgers JL, Nicewander WA (1988) Thirteen ways to look at the
In: Proceedings of the 1st international conference on global correlation coefficient. Am Stat 42(1):59–66
software engineering, pp 159–168 29. Salger F, Englert J, Engels G (2010) Towards specification pat-
9. Damian D, Zowghi D (2003) Requirements engineering chal- terns for global software development projects—experiences
from the industry. In: Seventh international conference on the
lenges in multi-site software development organizations. Requir.
Eng J 8:149–160 quality of information and communications technology (QUA-
10. Ebert C, Neve PD (2001) Surviving global software development. TIC), pp 73–78
IEEE Softw 18(2):62–69 30. Shami NS, Bos N, Wright Z, Hoch S, Kuan KY, Olson J, Olson G
(2004) An experimental simulation of multi-site software devel-
11. Elliott J, Raynor-Smith P (2000) Achieving customer satisfaction
through requirements understanding. Softw Process Technol opment. In: Proceedings of the 2004 conference of the centre for
1780(20020):203–219 advanced studies on collaborative research, pp 255–266
12. Heinonen S, Tanner H (2010) Early validation of requirements in 31. Shewell C (2000) Good business communicates across cultures: a
distributed product development: an industrial case study. In: practical guide to communication. Mastek Publications, Bristol
Proceedings of the 2010 international conference on the move to 32. Smite D (2007) Project outcome predictions: risk barometer
meaningful internet systems, pp 279–288 based on historical. In: Proceedings of the 2nd international
13. Herbsleb JD, Mockus A (2003) An empirical study of speed and conference on global software engineering (ICGSE’07),
communication in globally-distributed software development. pp 103–112
IEEE Trans Software Eng 29(6):481–494 33. Sommerville I (2007) Software engineering, 8th edn. Addison-
14. Herbsleb JD, Moitra D (2001) Global software development. Wesley, England
34. Sommerville I, Sawyer P (1997) Requirements engineering: a
IEEE Softw 18(2):16–20
15. Hsieh Y (2006) Culture and shared understanding in distributed good practice guide. Wiley, New York
requirements engineering. In: International conference on global 35. Walle VD, Campbell C, Deek FP (2007) The impact of task
software engineering; brazil, pp 101–108 structure and negotiation sequence on distributed requirements
16. Hull E, Jackson K, Dick J (2010) Requirements engineering. negotiation activity. Conflict, and Satisfaction, published by
Springer Science & Business Media LNCS vol 4495, pp 381–394
17. IEEE Standard 830 (1998) Recommended practice for software 36. Wiegers KE (2003) Software requirements. Microsoft Press,
requirements specifications. The Institute of Electrical and Redmond
Electronics Engineers, Inc. New York 37. Wolf T, Dutoit AH (2005) Supporting traceability in distributed
18. Johri A (2011) Sociomaterial bricolage: the creation of location- software development projects. In: Proceedings of international
spanning work practices by global software developers, special workshop on distributed software development
38. Wongthongtham P, Chang E, Dillon T (2007) Multi-site dis-
issue on ‘‘Studying work practices in Global Software Engi-
neering’’. Inf Softw Technol 53(9):955–968 tributed software development: issues, solutions, and challenges.
19. Lai R, Ali N (2013) A method of requirements management for In: Proceedings of the 2007 international conference on compu-
global software development, Advances in Information Sciences, tational science and its applications, pp 346–359
39. Yousuf F, Zaman Z, Ikram N (2008) Requirements validation
Human and Science Publication, Volume 1, Issue 1, pp 38–58
20. Lee Y, Zhao W (2006) Domain requirement elicitation and techniques in GSD: a survey. In Proceedings of the IEEE multi-
analysis- an ontology based approach, Volume 3994/2006. In: topic conference, pp 553–557
Workshop on computational science in software engineering
(CSSE’06)

123