A Requirements Management Method for Global Software Development

A Requirements Management Method for Global Software Development Richard Lai, Naveed Ali

A Requirements Management Method for Global Software Development Richard Lai, Naveed Ali Department of Computer Science and Computer Engineering, La Trobe University, Victoria 2086, Australia [email protected], [email protected]

Abstract To perform requirements management, effective communication and collaboration between stakeholders is necessary. Global Software Development (GSD), where software teams are located in different parts of the world, has become increasingly popular. However, geographical distance between stakeholders creates difficulties for stakeholders in engaging in effective communication. Taking into consideration the factors involved in GSD, previous research shows that the ways by which requirements management is being performed in collocated software development projects cannot be used effectively for GSD projects. To address this issue, in this paper we present a requirements management method for GSD. The method consists of four stages: (1) establishing and maintaining a requirements repository; (2) generating a requirements traceability matrix; (3) communicating and discussing requirements; and (4) requirements change management. To validate our method, we implemented it in a controlled laboratory environment using a case study of an online shopping system.

Keywords: Requirements Management, Global Software Development, Distributed Teams 1. Introduction Requirements management is an organized process of documenting, tracking, managing and prioritizing scattered pieces of requirements. It is a continuous process which runs throughout software development and requires participation from all stakeholders to come to an agreement on potential changes in requirements [16]. Due to the activities involved in requirements management, it is one of the most collaboration-dependent processes in software development. The factors which are crucial to successful requirements management include: communication and coordination between the stakeholders [7] [26]; establishment and management of shared repositories for requirements [5] [9] [19] [27]; traceability of requirements; and requirements change management [18] [25] [28]. Global Software Development (GSD), where software teams are located in different parts of the world, has increasingly become popular [3] [10]. To gain the benefit of lower costs of software development and access to international talent, GSD is a good solution for many organizations [6] [17]. The number of organizations engaged in GSD is increasing and a considerably large amount of funds has been poured into it [14]. Despite the benefits, GSD has introduced issues for stakeholders which are not present in software projects developed in the same location (collocated projects) [9] [12] [29]. Due to development teams being in different geographical locations, differences in cultures and time zones [13] [22] adversely impact communication and coordination processes. Consequently, the frequency of communication, coordination and trust between the development teams decreases [11]. In addition, dissimilar approaches and processes of software development, technical capabilities of remotely distributed team members, and less visibility of development work carried out at different sites create additional issues for stakeholders to tackle. Of the major issues facing successful GSD, requirements management is of greatest significance. The presence of cultural, lingual, social, temporal and geographical differences not only impacts the communication process in GSD, but also introduces challenges for development teams in establishing and managing shared repositories for requirements. These repositories are a common place for different development teams to record and share project details with other teams. Although the establishment and management of these repositories appears to be a simple process, due to dissimilar processes and standards of software development, data recorded by one team often becomes incompatible with data recorded by other teams, and therefore cannot be effectively used for requirements tracking and further development processes. Similarly, to manage changes in

Advances in Information Sciences (AIS) Volume1, Number1,March 2013 doi:10.4156/ais.vol1.issue1.3

38


requirements, in addition to the requirements change management (RCM) process, communication and coordination between stakeholders is required, which is difficult to achieve in GSD. Requirements management is difficult and challenging in a GSD environment. The aforementioned issues are not adequately addressed by the existing methods of requirements management [2, 23]. In this paper, we present an ontology-based requirements management method for GSD projects. Ontology, in software engineering, is used to specify requirements in a software requirements specification (SRS) document, examine system design, organize software system into sub-systems, store information in a requirements repository and evaluate requirements for inconsistencies, as well as to facilitate knowledge acquisition and retrieval, requirements communication, and system maintenance [20]. Our method assists stakeholders to undertake the following activities: (1) establish and maintain a requirements repository; (2) generate a requirements traceability matrix to establish two-way links between the requirements and non-requirements artefacts; (3) communicate and discuss project knowledge between the development teams; and (4) manage changes in requirements. Past researchers used student groups in a university environment to play the roles of stakeholders in experiments in GSD studies [4] [15] [21] [28]. Likewise, we validate our method by applying it to a case study of an online shopping system, where the roles of client, requirements engineer, project analyst and developers were played by a group of students. Throughout the paper, we refer to these groups of people as “stakeholders”.

2. Our method The requirements management method is divided into four stages: stage 1- establish and maintain a requirements repository; stage 2- generate a requirements traceability matrix; stage 3- communicate and discuss requirements; and stage 4- manage changes in requirements. In the following sub-sections, we explain these stages in detail.

2.1. Establishing and maintaining a requirements repository A requirements repository for GSD projects will be established and later maintained in two steps: step 1 – establishing a requirements repository; and step 2 - maintaining data in a requirements repository.

2.1.1. Establishing a requirements repository The process begins with gathering information on the requirements and non-requirements of the software projects from SRS. The requirements cover information on functional and non-functional requirements, the graphical representation of requirements, and related design documents. However, non-requirements contain information on project name, project description, starting and completion dates, allocated budget, and development teams involved in the software project. The information obtained will then be recorded in the requirements repository by using the principles of requirements ontology (refer Figure 1). Throughout the paper, f denotes “functional requirements”, n “nonfunctional requirements”, UML “unified modelling language”, m “main requirements”, s “sub requirements”, c “requirements category”, d “requirements description”, r “relationship between requirements”, cr “validation criteria”, vp “validation properties”, d “ general details”, t “teams”, nm “project name”, pd “project description”, sc “starting and completion dates of project”, ab “allocated budget”, l “locations”, rl “roles and responsibilities”, cd “contact details”, rel “relationship between modules”, and k ”key people from different teams”.

39


SRS → Requirements and non-requirements data Requirements data → Functional requirements (f1, f2, f3…) Non-functional requirements (n1, n2, n3…); n Є f Requirements graph; contains information about f and n Design documents; supporting UML diagrams Functional requirements → Main requirements (m1, m2, m3…); ∑m makes requirements Sub-requirements (s1, s2, s3…); ∑s makes m Requirements category (c1, c2, c3…); c Є (s, m) Requirements description (d1, d2, d3…); d Є (s, m) Relationship between requirements (r1, r2, r3…); r exist between (s, m) Non-functional requirements → Validation criteria (cr1, cr2, cr3…); cr Є n Validation properties (vp1, vp2, vp3…); vp Є n Non-requirements data → General details (d1, d2, d3…) Teams (t1, t2, t3…); ∑t makes t General details → Project name (nm1, nm2, nm3…) Project description (pd1, pd2, pd3…); pd Є nm Project dates (sc1, sc2, sc3…); sc Є nm Allocated budget (ab1, ab2, ab3…); ab Є nm Teams → Locations (l1, l2, l3…); l Є t Roles (rl1, rl2, rl3…); rl Є t Contact details (cd1, cd2, cd3…); c Є t

Figure 1.Ontology-based architecture of a requirements repository for GSD projects

2.1.2. Maintaining data in a requirements repository After establishing a requirements repository, issues regarding data consistency and timing conflicts will be addressed by defining ontology-based data maintenance patterns (refer Figures 2 and 3), where a denotes “aspects” and d “data status”. Depending on the roles and privileges assigned to development teams by the project administrator/manager, details regarding software projects could be read and written by them team members in different geographical locations and time zones using the maintenance patterns. To read data from a repository, different developments teams can simultaneously access the repository and the required project details. However, to write information on a certain aspect of the software project inside the repository, only one person is allowed to edit information at a time. During the write operation, the aspect of the software project which is being edited will be frozen, preventing other development teams from accessing the same data for modification purposes at the same time. Taking into consideration the nature of the write operation, development teams whose work could be affected by the changes made in the requirements repository will be notified via the available communication mechanism. Read data → Aspects (a 1, a 2 ); a1 Є requirements data, a2 Є non-requirements data Details; detailed descriptions of a 1, a 2

Figure 2.Maintenance pattern for reading data from a repository Edit data → Aspects (a 1 , a 2); a1 Є requirements data, a2 Є non-requirements data Details; detailed descriptions of a1, a2 Data status (d1, d 2 ); d1 Є freeze data, d2 Є free data Notify; inform teams about changes in repository

Figure 3.Maintenance pattern for editing data in a repository

40


As a result, problems which might occur due to data inconsistency and attempts made by different development teams to edit the same piece of information concurrently will be minimized.

2.2. Requirements traceability Requirements traceability is considered a sub-part of requirements management. It is primarily responsible for documenting project requirements in a matrix form and providing two-way links between different sets of requirements. The process of requirements traceability begins with gathering project details from the centralized repository. The information available will then be used to document details regarding the functional and non-functional requirements, possible relationships between requirements, and additional project details in the traceability matrix. The underlying schema of the traceability matrix is illustrated in Figure 4 (refer Appendix-1), where a collection of classes represents different aspects of a software project. Brief descriptions of the significant components of the traceability matrix are presented below.       

    

Project name: complete name of the project Project description: brief description of the project Starting date: commencement date of the project Completion date: target completion date of the project Requirements id: a numerical value assigned to track requirements throughout the SDLC Related id: an identifier used to classify main and sub-requirements by using a number format (1, 1.1, 1.1.1…), where 1 indicates project name, 1.1 main requirements, and 1.1.1 sub requirements Functional requirements: composed of several attributes which include: main and subrequirements, corresponding requirements categories, requirements description, and relationship between requirements. o Main requirements: details on main project requirements o Sub-requirements: details on project sub-requirements o Corresponding requirements category: details regarding the classification of requirements into different categories o Description: brief details on requirements o Relationships: details on the association with other requirements Assigned teams: group of users involved in the software development project Status: current status of requirements, which can be either started, in-process, withheld, or completed. Design documents: different types of UML diagrams (i.e. use case, sequence, class) associated with the requirements Non-functional requirements: criteria for evaluating the behaviour of functional requirements Final comments: overall comments on project requirements

In Figure 4, details regarding the development teams, underlying requirements of the software system, and potential changes in requirements will be traced via the ontology-based tracking patterns which are defined in the following sub-sections.

2.2.1. Tracking details on the development teams To track information on the roles and responsibilities, locations and contact details of the development teams in different geographical locations, the pattern presented in Figure 5 will be used. Project → Non-requirements data Non-requirements data → Teams (t1, t2, t3…) ; ∑t makes t Teams → Locations (l1, l2, l3…); l Є t Roles (rl1, rl2, rl3…); rl Є t Contact details (cd1, cd2, cd3…); cd Є t

41


Figure 5. Pattern to track details on the development teams

2.2.2. Tracking details regarding requirements To track information on the underlying sets of functional and non-functional requirements, the pattern presented in Figure 6 will be used. Project → Requirements data Requirements data → Modules (mod 1 , mod 2, mod 3…); rel exists between mod Modules → Functional requirements (f1, f2, f3…) Non-functional requirements (n1, n2, n3…); n Є f Functional requirements → Main requirements (m1, m2, m3…); ∑m makes requirements Sub-requirements (s1, s2, s3…); ∑s makes m Requirements category (c1, c2, c3…); c Є (s, m) Requirements description (d1, d2, d3…); d Є (s, m) Relationship between requirements (r1, r2, r3…); r exist between (s, m) Non-functional requirements → Validation criteria (cr1, cr2, cr3…); cr Є n Validation properties (vp1, vp2, vp3…); vp Є n

Figure 6.Pattern to track details on functional and non-functional requirements

2.2.3. Tracking changes in requirements Finally, information on the potential changes made to the existing set of requirements will be mapped using the pattern presented in Figure 7. Project → Requirements data Requirements data → Modules (mod 1, mod 2, mod3 …); rel exists between mod Modules → Changed requirements (cr 1, cr 2, cr3 …); cr Є (n, f), r exist between cr Changed requirements → Teams (t1, t2, t3…) Teams → Roles and responsibilities (rl1, rl2, rl3…), locations (l1, l2, l3…) Locations → Contact details (cd1, cd2, cd3…)

Figure 7. Pattern to track changes in requirements.

2.3. Requirements communication and discussion Requirements communication and discussion will be performed by defining ontology-based communication patterns in four steps: step 1– identify the items which need to be discussed and with whom; step 2– organise a meeting to discuss the issue; step 3– invite participants (team members) to the discussion; step 4 – finalize a time for the discussion and engage in the discussion via an available communication mechanism. The initial concept of requirements discussion has been taken from DOODLE1 and modified.

2.3.1. Identification of items for discussion The communication process begins by identifying the set of requirements, which requires discussion between the members of different teams. Based on the nature of the requirements, teams associated with the identified requirements will be chosen. To reduce conflicts, key people from each team will be given the authority to discuss project issues with other teams and make decisions, accordingly (refer Figure 8). On the basis of the identified requirements and contact persons from each team, a summary of issues for discussion will be generated in the next step, so team members can be prepared.

1

www.doodle.com

42


Project → Requirements Requirements → Teams (t1, t2, t3…); ∑t makes t Teams →Key people (k 1, k 2, k 3…); k Є t, d Є c Key people → Contact details (c1, c2, c3…); c Є t Locations (l1, l2, l3…); l Є t Roles (rl1, rl2, rl3…); rl Є t

Figure 8.Communication pattern for identification of items for discussion

2.3.2. Creating an event for discussion To discuss and negotiate requirements between the members of the teams, an event will be created. The information required for an event creation includes: a brief title to indicate the reason for holding the event; the location of the event, that is, where the event will be held; suggested time frames for the event; a concise message outlining the purpose of the event; and the contact details of the event organiser and invitees. An event will then be created after answering the following questions: what is the objective of the event and what will be gained from it?; who will attend the event and what benefit will they gain from it?; what will be the most convenient time to hold the event so that the majority of participants can attend?; where should the event be held so that it is convenient for the majority of participants?; and how should the event be conducted in order to ensure participants gain the maximum benefits from the event? (refer Figure 9). Event → Title Title → Location, key people, suggested time, message Key people → (k 1 , k 2, k 3…); k Є t, t Є (rl, c, l)

Figure 9.Communication pattern for creating an event

2.3.3. Inviting participants to the discussion After deciding to hold the event, invitations will be emailed to the selected participants, stating the event’s objectives. As meeting invitations will be sending via email, mail-synchronization should be activated both at the sender and recipient end before distributing the invitation; otherwise, the event notification will not be displayed. To ensure the attendance of all the invitees, reminder notifications will be sent after a certain period of time. In addition, to keep track of the acceptances, a log file will be maintained, which will enable the event organiser to keep track of who will be attending (refer Figure 10). Invitations → key people Key people → reminder notification Acceptance received → log file

Figure 10.Communication pattern for inviting participants

2.3.4. Finalizing details and engaging in discussion Decisions about the meeting time will be made in consultation with the invitees upon receipt of confirmation of attendance. If the proposed time for the event needs to be changed, an updated notification will be sent to the invitees. Online chat rooms and videoconferencing facilities will be used to conduct a meeting in a geographically distributed environment. Finally, the agreed time frame will be communicated and discussed by the invited participants, and appropriate decisions will be made (refer Figure 11).

43


Key people → acceptance Acceptance → mutual consensus Mutual consensus → decisions made

Figure 11.Communication pattern for finalizing details The overall process of requirements communication and discussion is illustrated in Figure 12.

Figure 12. Process of requirements communication and discussion

2.4. Requirements change management It is expected that there will be changes to requirements as a result of changes in user demands, increased understanding of the stakeholders, project vision, requirements specification and availability of technological solutions. Timely management of these changes is vital for successful software development, which can be achieved through a rigorous requirements change management (RCM) method. In our method, changes in requirements will be managed in three steps: step 1- change understanding; step 2- change analysis; and step 3- change finalization. These steps are explained in the following sub-section.

2.4.1. Understanding changes in requirements The RCM process begins by establishing a clear understanding of the requested change. For this reason, a complete set of project requirements, obtained from an SRS, will be represented in a graphical form to generate a detailed requirements graph for them. Thereafter, the requested changes in requirements will be understood by making appropriate changes in the requirements graph, where changes can be of any nature and are primarily related to the addition of new requirements, the deletion of existing requirements, and the modification of existing requirements (refer Figure 13).

44


Figure 13. Understanding changes in requirements via requirements graph

2.4.2. Analyzing changes in requirements Once the scope of the changes has been determined, change analysis will be performed with respect to the development work which could be affected by changes in the existing set of requirements. At this stage, changes will be analyzed to estimate the percentage change to the overall number of requirements (refer Equation 1), the percentage change to the number of affected requirements (refer Equation 2), and changes in the development cost (refer Equation 3).

COverall 

N Re quirements TRe quirements

…… (1)

where ∆Coverall = % change in overall number of requirements, Nrequirements = number of newly added requirements, Trequirements = total number of requirements

C Affected 

N Affected

requirements

TRe quirements

…… (2)

where ∆Caffected = % change in number of affected requirements, Nrequirements = number of requirements affected by change in requirements, Trequirements = total number of requirements

CD  E  WP …… (3) where ∆CD = change in development cost, E = expected development hours, WP = Wages of a software developer per hour 2.4.3. Finalizing changes in requirements Depending on the outcome of the change analysis, decisions regarding change finalization will be made after considering the results of Equation 4 and later recorded in the requirements repository for future correspondence so that stakeholders can decide whether the change will be implemented or not. If the change will be implemented, a new version of the SRS will be generated. Finally, the outcomes of change finalization will be communicated to those development teams whose work will be affected

45


by the change. However, if change implementation is not required, the change request will be terminated.

0.85  C Overall | C Affected | C D  1.00

 less affect


 mild affect


 considerable affect


 extreme affect

…… (4 )

The entire process of RCM in globally distributed environments is pictorially represented in Figure 14.

Figure 14.Process of requirements change management

3. Case study 3.1. Organization details of client 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.

3.2. Problem description Client XYZ wants to develop an online shopping system for their organization. In the shopping system, the following functionalities are required: (1) assist customers/end-users in purchasing different products, tracking their orders, viewing sellers’ information, and make payments via a secure payment platform; (2) assist XYZ in: selling different products, managing information about customers

46


(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 (3) easy-to-use graphical user interface (GUI).

3.3. Organizational details of software organization 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.

3.4. Design of the case study 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 engineer of ALPHA extracted and analyzed details about prospective system requirements. As a result, they identified that there would be two modules in the project: one related to services (that is, purchases, order tracking, seller information) and one related to payment (that is, basic payment and authentication mechanisms). Thereafter, members from these teams established a repository to record details of the online shopping system, generated a requirements traceability matrix, sent project requirements to two offshore locations for GSD, and communicated and discussed changes in requirements with other development teams. The client, requirements engineer and project analysts of ALPHA are located in Australia; however the offshore teams are located in China and India. The Chinese and Indian teams are responsible for the development of the payment and service modules, respectively. Past researchers used student groups in a university environment to play the roles of stakeholders to conduct experiments on GSD [4] [15] [21] [28]. We also simulated the development of the GSD requirements of XYZ using our process by creating a virtual environment for GSD within the vicinity of La Trobe University, Australia. Due to the small time difference between the geographical locations of stakeholders, we were able to complete the case study during normal business hours. In this setup, the roles of the stakeholders were played by a group of students. For this purpose, we selected 9 students from La Trobe University, Australia, and divided them into four teams (refer Table 1). All teams were given the background information about XYZ, ALPHA and the GSD environment. Table 1: Student allocation in different teams Team # 1 2 3 4

Role played ALPHA RE Development team in India Development team in China

Number of participants 2 1 3 3

3.5. Case study findings In this case study, we validated the first three stages of our method and present the results in the following sub-sections.

3.5.1. Establishing and maintaining a requirements repository The members of the RE and analyst teams initiated the process of requirements management by establishing a requirements repository for the online shopping system2. To gather the required data for the repository, they obtained details regarding the requirements and non-requirements of the shopping system from the SRS document, and later recorded these in the repository (refer Figure 15).

2

To validate our work, we developed a prototype of a requirements repository.

47


Figure 15. Requirements repository for online shopping system In later stages, depending on the nature of the work and the defined set of privileges, members of the RE, analyst, and Chinese and Indian development teams used the requirements repository for data reading and writing purposes. In Tables 2 and 3, details on the data reading and writing operations are given. The results in Table 2 show that due to the straightforward mechanism of reading data, permission has been granted to all the teams to access the requested data from the repository at the same time. Table 2: Reading data from a requirements repository Operation type Read data

Operation requested by RE team Indian development team Chinese development team

Time of requested operation Simultaneously

Overall status Read access granted

48


However, when members of the Indian and Chinese teams made an attempt to modify the same pieces of information in the repository, only permission was granted to the Chinese team because they submitted the modification request prior to the Indian team (refer Table 3). Table 3: Writing data into a requirements repository Operation type Write data

Operation requested by Indian development team Chinese development team

Time of requested operation 17.02 (GMT+10) 17.00 (GMT+10)

Status of requested operation Access not granted Access granted and data frozen for the duration of the write operation

3.5.2. Requirements traceability After establishing the repository, the members of the RE and analyst teams generated the requirements traceability matrix by gathering information about the requirements and nonrequirements of the online shopping system. Based on the gathered information, they generated the traceability matrix (refer Table 4), where req. denotes “requirements”, rel. “related”, c “client, RE “requirements engineering”, a “analyst”, and dv “development”. Due to the limited amount of space, we did not include information about the location, roles and responsibilities, and contact details of the development teams, nor validation criteria for non-functional requirements in Table 4. Table 4: Requirements traceability matrix for online shopping system Project name: Online shopping system Starting date: 1st Jan, 2012 Completion date: 31st August, 2012 Project description: The client wants to develop a shopping system, by which they can sell their products Req. id 1

2

3

4 5 6 7 14

15 , 19

Rel. id

Traceability matrix number #:1

Functional requirements Teams Status Design document Sub Category Description Relationship requirements 1 - Service Required There will be service and Composition C, RE, A Started - Payment payment modules in the (Australia) (work in Use cases online system Dv (India, progress) (1-19) China ) Project Purchase Following services are 1.1 - Service Order tracking Required required: purchase; order Composition Use case 2 tracking; and seller Seller information information Browse catalogue To make a purchase, the 1.1.1 Service Select product Required following steps are - Purchase Make payment necessary: browse Composition Use case 3 Team in Started Place order catalogue; select product; India (work in make payment; and place progress) order 1.1.1.1 Purchase Browse catalogue Expected To view product Association Use case 4 - Browse catalogue information 1.1.1.2 - Select product Select product Expected To choose required Association Use case 5 - Make payment product 1.1.1.3 - Place order Make payment Expected To pay required amount Association, Use case 6 intersection 1.1.1.4 Place order Expected To finalize and place Association Use case 7 order 1.2

Main requirements Overall project

Project - Payment

1.2.1 Payment -Payment mechanism Payment 1.2.2 -Authentication mechanism

Payment mechanism Authentication mechanism Payment via credit card

Required Enable customers to make Composition their payments Required Customers can pay by credit card

Association

Verify card details

Validation criteria Required associated with payment method

Association, intersection

Team in China

Non-functional requirements Performance, security, usability, support, availability, localizability Performance, security, usability, availability, localizability Performance, security, availability, usability Performance, availability Performance, availability Performance, availability, security Performance, availability

Use case Performance, security, 14 usability, availability, localizability Started Use case Performance, security, (work in 15 availability, usability progress) Use case Performance, security, 19 availability

49


After establishing the requirements repository and traceability matrix, members of the RE and analyst teams sent the project requirements to the Chinese and Indian development teams for GSD. Thereafter, depending on the roles played by each team and the nature of the software development, members of the RE, analyst, and both the development teams used the traceability matrix to trace information on the development teams and the requirements of the online shopping system, before and after making changes to it. In Figures 16-18, how the members of the analyst team trace information using our method is illustrated. Online shopping system → Non-requirements data Non-requirements data → Teams, project details Teams → Development (India, China), Client, RE and Analyst (Australia) Client → Roles and responsibilities, contact details Information technology → Technology head → Australia, GMT+10, [email protected] Sales/Pre-sales → Senior sales officer → Australia, GMT+10, [email protected] Marketing → Marketing manager → Australia, GMT+10, [email protected] Human resource → Human resource manager → Australia, GMT+10, [email protected] Finance → Senior financial officer → Australia, GMT+10, [email protected]

Figure 16.Tracking details on the client team Project → Requirements data Requirements data → Service, payment; composition exists between service and payment Service → Purchase, order tracking, seller; composition exists between service and payment Purchase → Browse catalogue, select product, make payment, place order association exists between purchase and (browse catalogue, select product, make payment, place order) Order tracking → Provide order details, Track orders association exists between order tracking and (provide order details, track orders) Seller → Select seller, View information association exists between seller and (select seller, view information) Non-functional requirements → Performance, security, usability, support, availability, localizability Validation criteria → Performance (system should be able to retrieve order details within 10 seconds)

Figure 17.Tracking details on the requirements of online shopping system Project → Requirements data Requirements data → Service, payment; composition exists between service and payment Payment → Payment by Paypal; changes in the requirements of payment module Payment by pay pal → Chinese and Indian development team Chinese team → Roles and responsibilities, contact details Information technology → Manager programs→ China, GMT+5.5, [email protected] Indian team → Roles and responsibilities, contact details Information technology → Director operations → India, GMT+5.5, [email protected]

Figure 18. Tracking details about the changes in payment module

3.5.3. Requirements communication and discussions As things become clearer to the client with the passage of time, the client wants to make a few changes in the payment module of their project. In the initial set of requirements, end users can only use their credit cards for payment purposes in the shopping system. To provide flexibility to end users in making online payments, the client wants to make changes in the payment module by adding the “PayPal” facility so that the end users can have different options available for online payments. For this purpose, the managers of the client’s organization contacted members of the analyst team and discussed the required changes face-to-face. To further discuss the change in requirements, members of

50


the RE and analyst team executed the requirements communication and discussion process in the following four steps. In step 1, the team members began the communication process by extracting details from the project repository about the requirements relating to the payment module and the team(s) responsible for its development, discovering that this was being developed at the Chinese site, and Mr. JKL was the key person with whom to discuss potential changes. However, the team members also realized that change in the payment module also affects the development work going at the Indian site, and Mr. ABC was the key person with whom to discuss potential changes (refer Figure 19). Online shopping system → Payment by pay pal accounts Payment by pay pal accounts → Chinese and Indian teams Chinese team → Roles and responsibilities, contact details Information technology → Manager programs→ China, GMT+5.5, [email protected] Indian team → Roles and responsibilities, contact details Information technology → Director operations → India, GMT+5.5, [email protected]

Figure 19.Identification of items for requirements communication and discussion Following the identification of requirements and development teams, the team members created an event for requirements discussion in step 2. During the event creation, the team members prepared answers to the following: (1) title and location of event; (2) target audience; (3) suggested time for discussion; (4) message and contact details of the sender and target audience (refer Figure 20). Event → Discussing changes in requirements Discussing changes in requirements → Location (videoconferencing via SKYPE) Time (14.00 ‘o’ clock, GMT+10, 10 th Feb, 2012) Message (we would like to discuss and finalize changes in the payment module) Key people (Mr. JKL, [email protected]) (Mr. ABC, [email protected])

Figure 20.Creating an event for requirements communication and discussion Once the formalities for the created event were completed, the team members sent the event invitation to the development teams via email in step 3. To remind the invitees about the event, they sent a reminder notification after a certain period of time (refer Figure 21). Invitations → Mr. JKL, Mr. ABC Mr. JKL, Mr. ABC → reminder notification Acceptance received → log file

Figure 21.Inviting participants for requirements communication and discussion Finally, after receiving the replies from the invited participants, the team members finalized the details regarding the time and location of the event with Mr. JKL and Mr. ABC. As a result, it was decided to hold a meeting in a collaborative environment on 10th February, 2012 at 2.00 pm (GMT+10). For communication purposes, they decided to use SKYPE as the collaborative tool by which to discuss the project requirements. At the agreed time, the invitees took part in the discussion process, where the team members clarified the details on the changes in the payment module of the online shopping system (refer Figure 22). Mr. JKL, Mr. ABC → Received acceptance Acceptance → Mutual consensus Mutual consensus → decisions made

Figure 22.Finalizing details for requirements communication and discussion

51


3.6. Discussion After completing the requirements management process, we interviewed the stakeholders (i.e. members of the RE, analyst and development teams) in three steps about their experiences in relation to different aspects of the experiment. In step 1, we asked questions about their level of understanding of the proposed method. In step 2, we interviewed stakeholders about the level of comfort they experienced when performing different stages of requirements management. In step 3, we asked stakeholders to state the frequency of conflicts which occurred during the first three stages of requirements management. Tables 5-13 present the outcomes obtained during steps 1-3.

3.6.1. Level of satisfaction on the proposed method To identify the level of satisfaction in the stages involved in requirements management, we contacted members of the RE, analyst and development teams to rate these on a scale of 1 to 4, where 1 indicates “not satisfied”, 2 “less satisfied”, 3 “satisfied”, and 4 “completely satisfied”. To analyze the data obtained in this step, we used the Kruskal-Wallis (KW) test to determine the level of satisfaction. The results obtained after applying the KW test are presented in the following sub-sections. Considering that only members of the RE and analyst teams were involved in the first two stages of requirements management (i.e. establishing and maintaining a requirements repository, and generating a requirements traceability matrix), we asked them to rate their level of satisfaction on the following: (1) establishing and maintaining a requirements repository; and (2) generating a requirements traceability matrix. The results obtained after analyzing the responses are presented in Tables 5 and 6. Table 5.Mean ranks for the RE and analyst teams about level of satisfaction Aspects Establishing and maintaining a requirements repository Generating requirements traceability matrix

Mean Rank 3.00 4.00

Minimum 2.00 1.00

Maximum 4.00 4.00

Table 6. Statistics of KW test for the RE and analyst teams on level of satisfaction a. Kruskal Wallis Test b. Grouping Variable: Factors Statisticsa,b Chi-Square Degree of freedom (df) Asymptotic Significance

.556 1 .456

The results of the KW test revealed a statistically insignificant difference in the level of satisfaction (A1, n = 3: establishing a requirements repository; A2, n = 3: generating a requirements traceability matrix), x2 (1, n = 6) = .556, p = .456 (refer Table 6). In addition, the results of the mean ranks given in Table 5 show that the members of the RE and analyst teams expressed a higher level of satisfaction in relation to generating a requirements traceability matrix compared to establishing a requirements repository. The reason behind the lower satisfaction level on establishing a repository is mainly related to the amount of time and effort required to record details of the software project in a repository. Members of the RE, analyst and development teams were then asked to rate their level of satisfaction on the following: (1) requirements communication; and (2) requirements discussion. The results obtained after analyzing the responses are presented in Tables 7 and 8. Table 7.Mean ranks for the RE, analyst and development teams on level of satisfaction Aspects Requirements communication Requirements discussion

Mean Rank 10.39 8.61

Minimum 2.00 2.00

Maximum 4.00 4.00

52


Table 8. Statistics of KW test for the RE, analyst and development teams on level of satisfaction a. Kruskal Wallis Test b. Grouping Variable: Factors Statisticsa,b Chi-Square Degree of freedom (df) Asymptotic Significance

.604 1 .437

The results of the KW test revealed a statistically insignificant difference in the level of satisfaction (A1, n = 9: requirements communication; A2, n = 9: requirements discussion), x2 (1, n = 18) = .604, p = .437 (refer Table 8). In addition to these findings, the results of mean ranks from Table 7 show that stakeholders expressed an approximately similar level of satisfaction for requirements communication and discussion.

3.6.2. Level of comfort on the proposed method In step 2, we interviewed members of the RE, analyst and development teams to determine the level of comfort they felt in performing different aspects of requirements management. We asked stakeholders 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”. To analyze the data obtained during this step, we applied the KW test and present the results in the following sub-sections. Initially, members of the RE and analyst teams were asked to rate their level of comfort on the following aspects: (1) establishing and maintaining a requirements repository; and (2) generating a requirements traceability matrix. The results obtained after analyzing the gathered responses are presented in Tables 9 and 10. Table 9.Mean ranks for the RE and analyst teams on level of comfort Aspects Establishing a requirements repository Generating requirements traceability matrix

Mean Rank 3.17 3.83

Minimum 2.00 3.00

Maximum 4.00 4.00

Table 10. Statistics of KW test for the RE and analyst teams on level of comfort a. Kruskal Wallis Test b. Grouping Variable: Factors Statisticsa,b Chi-Square Degree of freedom (df) Asymptotic Significance

.222 1 .637

The results of the KW test revealed a statistically insignificant difference in the level of comfort (A1, n = 3: establishing a requirements repository; A2, n = 3: generating requirements traceability matrix), x2 (1, n = 6) = .222, p = .637 (refer Table 10). In addition to these observations, by analyzing the results of mean ranks from Table 9, we identified that members of the RE and analyst teams expressed a higher level of comfort in relation to generating a requirements traceability matrix compared to establishing a requirements repository due to the time and effort required to do this. Members of the RE, analyst and development teams were then asked to rate their level of comfort on the following: (1) requirements communication; and (2) requirements discussion. The results obtained after analyzing the responses are presented in Tables 11 and 12. Table 11.Mean ranks for the RE, analyst and development teams on level of comfort Aspects Requirements communication Requirements discussion

Mean Rank 10.39 8.61

Minimum 2.00 2.00

Maximum 4.00 4.00

53


Table 12. Statistics of KW test for the RE, analyst and development teams on level of comfort a. Kruskal Wallis Test b. Grouping Variable: Factors Statisticsa,b Chi-Square Degree of freedom (df) Asymptotic Significance

.720 1 .396

The results of the KW test revealed a statistically insignificant difference in the level of comfort (A1, n = 9: requirements communication; A2, n = 9: requirements discussion), x2 (1, n = 18) = .720, p = .396 (refer Table 12). In addition to these findings, we used the results of mean ranks from Table 11 to identify the aspects about which stakeholders felt more comfortable, finding that the level of comfort expressed by stakeholders on requirements communication and discussion was closely similar.

3.6.3. Frequency of conflicts In step 3, we contacted members of the RE, analyst and development teams and interviewed them to determine the frequency of conflicts which occurred during requirements management. We asked stakeholders to rate the frequency of conflicts on a scale of 1 to 4, where 1 indicates “very frequently”, 2 “less frequently”, 3 “occasionally”, and 4 “rarely”. To analyze the data obtained during this step, we applied the Descriptive Test and present these results in Table 13. Table 13.Frequency of conflicts in the proposed method of requirements management RE process Requirements management

Min. 2.00

Max. 4.00

Mean 3.2353

SD .56230

The results in Table 13 show that the participants from different groups of stakeholders reported a lower frequency of conflicts during requirements management. The reasons behind this are: (1) the availability of project knowledge in a requirements repository and traceability matrix enabled the development teams to use and/or track the details of technical and non-technical aspects of software systems, when required; and (2) taking stakeholders on board during requirements communication and discussion assisted stakeholders in making project decisions in a timely manner.

4. Comparison with the related work In the literature, five papers have been published on GSD requirements management. Sinha et al. developed a collaborative tool (called EGRET) for managing project requirements in a globally distributed environment [23]. EGRET facilitates informal communication between stakeholders throughout the requirements management process, including administering changes in software requirements, promoting awareness of the underlying issues, and knowledge management. Kumar and Kumar presented a framework for requirements management in GSD [1]. The authors used ontology to manage project knowledge and propose metrics to control software processes. Damian et al. suggested guidelines for promoting awareness in globally distributed requirements management as follows: gathering information about requirements and implementation details; assisting stakeholders in making decisions; and documenting the decisions for future correspondence [8]. Smite reported requirements management practices in one software organization in Latvia [24]. The practices included: creating software teams sensibly; reducing the differences due to cultural diversity; arriving at a mutual agreement on requirements analysis; developing a glossary of keywords to minimize challenges of misunderstanding and misinterpretation; clearly defining roles and responsibilities; encouraging communication; and recording activities in a version-controlled system. Ansari et al. used the concept of extreme programming (XP) to manage requirements, and presented a model for it [2]. Taking into consideration the abovementioned contributions, the following conclusions are made.

54




Although traceability and change management are provided in EGRET, information regarding the traceability matrix, the mechanism on which traceability is based, and how to analyze and finalize changes in requirements is not available. In addition, information regarding how to arrive at a mutually agreed time for requirements communication and discussion is missing in [23]. Consequently, it is hard to ensure the presence of the required stakeholders during the communication process. Not having all the stakeholders on board might delay the discussion process; it will also delay the decision-making process and affect later stages of software development.  In [8] and [24], the authors presented a list of guidelines and practices that should be included in GSD requirements management.  Ontology is used to address the issues of communication and knowledge management in [1], but information on how to communicate, as well as information on requirements traceability and a requirements repository is missing in their work.  The concept of XP is used in [2] to assists stakeholders in managing user stories, but details regarding a requirements repository, communication between stakeholders, and requirements traceability are defined at an abstract level. We therefore addressed these missing aspects in our work. As a result, our work is different from the existing literature in the following ways.  To establish and maintain a requirements repository, we present an ontology-based process. As a result, not only the details regarding software projects will be recorded in a centralized repository, issues related to data inconsistencies and timing conflicts will also be minimized while maintaining a repository.  To provide traceability between requirements, we present a class-based schema and ontologybased patterns to trace information on the development teams and requirements before and after making changes in the existing set of requirements.  To communicate and discuss requirements, we define ontology-based communication patterns to assist development teams to decide on a mutually agreed time and location for requirements communication and discussion, ensuring maximum attendance by the members of the development teams so that appropriate decisions on software development can be made in a timely manner.  Finally, we present a graph-based process to manage changes in requirements. Therefore, potential changes in requirements can be understood, analyzed and finalized between development teams.

5. Conclusion Requirements management is a difficult process when performed locally, and it is even more challenging for stakeholders when performed across different geographical locations and time zones. In this paper, we have presented a requirements management method for GSD projects. This method assists stakeholders in the following ways: (1) by establishing and maintaining a requirements repository, project details can be easily recorded and shared between development teams. As a result, the time spent searching for required data is considerably minimized; (2) documenting the requirements in the traceability matrix allows each requirement to be traced and managed throughout the software development life cycle; (3) by sending a communication agenda to the development teams prior to the scheduled meeting, the teams can prepare themselves for the discussion on the requirements. Consequently, requirements will be better communicated, discussed and finalized amongst stakeholders; and (4) by generating a requirements graph, changes in requirements will be better understood and analyzed with respect to cost and non-cost attributes, and decisions regarding change finalization will be made in a timely manner. To validate our work, we implemented our method in a controlled laboratory environment using a case study of an online shopping system. Based on the case study results, we can conclude that: (1) our method helped the development teams in establishing a requirements repository to record details on the software project and later use these when required; (2) the tracking patterns assisted the development teams in monitoring information about the teams, requirements and non-requirements of the software project, and changes in requirements; and (3) as requirements were communicated and discussed

55


amongst the development teams, the amount of time and effort usually spent on making decisions about software development was greatly minimized. Thus, managing requirements at the right time greatly increased the chance of project success by adding value services and minimizing the risks associated with them. When applying our method to the case study, we chose students from one university. Although we selected students from different cultural backgrounds and conducted the case study according to the time zones of different geographical locations, the validity of the work involving students from different universities with dissimilar cultural backgrounds needs to be examined. In addition, to examine how truly successful our method is, we aim to find a commercial firm which would be prepared to collaborate with us for experimentation purposes in a real-life environment. Finally, we would like to improve the proposed process of requirements change management in the future.

6. References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16]

Kumar, S.A., Kumar, T.A., “Study the Impact of Requirements Management Characteristics in Global Software Development Project: An Ontology Based Approach”, International Journal of Software Engineering and Application, vol. 2, no. 4, 2011. Ansari, A.K., Sharafi, S.M., Nematbaksh, N., “A Method for Requirements Management in Distributed Extreme Programming Environment”, Journal of Theoretical and Applied Information Technology, vol. 20, no. 1, 2010. Atkins, D., Handel, M., Hersleb, J., Mockus, A., Perry, D., Wills, G., “Global Software Development”, The Bell Labs Co-laboratory in International Conference on Software Engineering, Toronto, 2001. Babar, M.A., Kitchenham, B., Jeffery, R., “Comparing distributed and face-to-face meetings for software architecture evaluation: A controlled experiment”, Empirical Software Engineering, vol. 13, no. 1, pp. 39–62, 2008. Boden, A., Avram, G., Bannon, L., Wulf, V., “Knowledge Management in Distributed Software Development Teams - Does Culture Matter?”, Fourth IEEE International Conference on Global Software Engineering, pp. 18-27, 2009. Conchuir, E.O., Holmström, H., Ågerfalk, P.J., Fitzgerald, B., “Exploring the assumed benefits of global software development”, in Proceedings of the 1st International Conference on Global Software Engineering, pp. 159–168, 2006. Damian, D., “Stakeholders in Global Requirements Engineering: Lessons Learned from Practice”, IEEE Software, vol. 24, no. 2, pp. 21-27, 2007. Damian, D., Chisan, J., Allen, P., Corrie, B., “Awareness Meets Requirements Management: Awareness Needs in Global Software Development”, proceedings of International Conference of Software Engineering, 2003. Damian, D., Zowghi, D., “Requirements Engineering Challenges in Multi-site Software Development Organizations”, Requirements Engineering Journal, vol. 8, pp. 149-160, 2003. Ebert, C., Neve, P.D., “Surviving Global Software Development”, IEEE Software, vol. 18, no. 2, pp. 62–69, 2001. Herbsleb, J.D., Mockus, A., “An Empirical Study of Speed and Communication in GloballyDistributed Software Development”, IEEE Transactions on Software Engineering vol. 29, no. 3, 2003. Herbsleb, J.D., Moitra, D., “Global software development”, IEEE Software, vol. 18, no. 2, pp. 16-20, 2001. Hsieh, Y., “Culture and Shared Understanding in Distributed Requirements Engineering”, in International Conference on Global Software Engineering, Brazil, pp. 101-108, 2006. Johri, A., “Sociomaterialbricolage: The creation of location-spanning work practices by global software developers”, special issue on “Studying work practices in Global Software Engineering” in Information and Software Technology, vol. 53, no. 9, pp. 955-968, 2011. Lloyd, W.J., Rosson, M.B., Arthur, J.D., “Effectiveness of elicitation techniques in distributed requirements engineering”, IEEE Joint International Conference on Requirements Engineering Proceedings, pp. 311- 318, 2002. Oberg, R., Probasco, L., Ericsson, M., “Applying Requirements Management with Use Cases”, Rational Software White Paper, Cupertino, CA, 2000.

56


[17]

[18] [19] [20] [21] [22] [23] [24] [25] [26] [27]

[28] [29]

Prikladnicki, R., Audy, J.L.N., Damian, D., Oliveira, T.C., “Distributed Software Development: Practices and challenges in different business strategies of offshoring and onshoring”, Second IEEE International Conference on Global Software Engineering, pp. 262274, 2007. Prikladnicki, R., Audy, J.L.N., Evaristo, R., “Global software development in practice lessons learned”, Software Process Improvement and Practice, vol. 8, no. 4, pp.267–281, 2003. Prikladnicki, R., Audy, J.L.N., Evaristo, R., “A Reference Model for Global Software Development: Findings from a Case Study”, International Conference on Global Software Engineering, pp. 18-28, 2006. Ruiz, F., Hilera, J., “Ontologies for Software Engineering and Software Technology”, chapter Using Ontologies in Software Engineering and Technology, Springer-Verlag Berlin Heidelberg, pp. 49–102, 2006. Shami, N.S., Bos, N., Wright, Z., Hoch, S., Kuan, K.Y., Olson, J., Olson, G., “An experimental simulation of multi-site software development”, Proceedings of the 2004 conference of the Centre for Advanced Studies on Collaborative research, pp.255 – 266, 2004. Shewell, C., “Good Business Communicates Across Cultures: A Practical Guide to Communication”, Bristol: Mastek Publications, 2000. Sinha, V., Sengupta, B., Chandra, S., “EGRET: a collaborative tool for distributed requirements engineering”, IEEE journal, vol. 23, no. 5, pp. 52-61, 2006. Smite, D., “Requirements Management in Distributed Projects”, journal of Universal Knowledge Management, vol. 1, no. 2, pp. 69-76, 2006. Smite, D., “Project Outcome Predictions: Risk Barometer Based on Historical”, in the Proceedings of the 2nd International Conference on Global Software Engineering, pp. 103– 112, 2007. Sodhi, J., Sodhi, P., “Managing IT system requirements”, Management Concepts, 2003. Taweel, A., Delaney, B., Arvanitis, T.N., Lei, Z., “Communication, Knowledge and Coordination Management in Globally Distributed Software Development: Informed by a scientific Software Engineering Case Study”, Fourth IEEE International Conference on Global Software Engineering, pp. 370-375, 2009. Walle, V.D., Campbell, C., Deek, F.P., “The Impact of Task Structure and Negotiation Sequence on Distributed Requirements Negotiation Activity, Conflict, and Satisfaction”, published by LNCS, vol. 4495, pp. 381–394, 2007. Wongthongtham, P., Chang, E., Dillon, T., “Multi-site Distributed Software Development: Issues, Solutions, and Challenges”, proceedings of the 2007 International Conference on Computational Science and its Applications, pp. 346-359, 2007.

57


Figure 4.Schema of a requirements traceability matrix

Appendix-1

58