Situational Factors Affecting Requirement Engineering ... - IEEE Xplore

2013 IEEE Conference on Open Systems (ICOS), December 2 - 4, 2013, Sarawak, Malaysia

Situational Factors Affecting Requirement Engineering Process in Global Software Development Huma Hayat Khan , Mohd. Naz’ri bin Mahrin , Suriayati bt Chuprat Advanced Informatics School Universiti Teknologi Malaysia (UTM) Kuala Lumpur, Malaysia

PREview [7-9] is a Viewpoint-Oriented Approach (VOA) [10] that considers the information related to a problem from different viewpoints [7] taking place due to distinct responsibilities, goals, etc. of sources of information. This approach harmonizes the standard concept of viewpoints with the organizational concerns. Fundamental to the NFR Framework [11] is the notion of soft goal: a goal neither having a clear definition nor having defined criteria for determining as if the goals are satisfied. Soft goals are related to nonfunctional requirements; because these types of requirements have distinct meaning and fulfillment criteria for distinct people. Some times same person have distinct meaning and satisfaction criteria when working on different projects. The Problem Frames (PF) approach [12] offers to decompose multifaceted problems into controlled sets of simpler, recognizable classes of sub-problems. These sub problem classes should be known from problem analysis [13]. The original problem description or solution is actually the description or solutions of the sub problems. [14-15] relates to a general RE process model which is developed for splitting perfective and imperfective aspects of requirements with that of their composition rules. A concrete instantiation of the model is also provided. Theme/Doc [16- 17] is the RE element of the Theme approach. ThemE/Doc supports “aspect identification and analysis in requirements documentation” in which aspects marked them as “descriptions of behaviors that are intertwined, and woven throughout” [17].

Abstract— A most favorable Requirement Engineering process is considered to be subject of situational characteristics of Software Requirement Engineering settings. These characteristics are related to organizations, project, process, requirements, stakeholders etc. However, list of situational factors affecting the Requirement Engineering process during Global Software Development is presently not available. The lack of such study is challenging as it not only restrain the ability to improve Requirement Engineering process, but also it can undermine the competence of Requirement Engineering team to determine the core constraints and characteristics of developing software. To address this scarcity, we have merged a considerable related research into an initial list of situational factors that affect the Requirement Engineering Process during Global Software Development. We have performed Systematic Literature Review for situational factors identification. To carry on data merging, we have used thorough data coding techniques adopted from Grounded Theory. The initial list of situational factors consists of 37 factors, which is the sound initial reference list for Requirement Engineering process definition in Global Software Development environment. The outcome of this study symbolizes a significant contribution to the Requirement Engineering body of knowledge. Keywords—Software Requirement Engineering (RE); process definition; Global Software Development (GSD)

I.

INTRODUCTION

GSD deals with either working within a company that is multi- site- development or in collaboration between multiple companies in different locations. RE is one of the phases for developing software and it occurs after the project initiates, followed by coding, testing, operation, and maintenance phases. When RE is performed in GSD environment then it is said to be globally distributed RE. RE is difficult, complex and challenging when it takes place within one organization in co located environment, but it becomes even more complex and challenging when performed in GSD environment. Increase in complexity and challenging nature of RE in GSD is due to the number of challenges it faces; like: difference in stakeholders tacit knowledge, different time zones, social and cultural aspects, technical aspects etc. [1-6]. Many alternative approaches for RE process have been proposed for overcoming such RE challenges.

978-1-4799-0285-9/13/$31.00 ©2013 IEEE

Irrespective of the individual characteristics of each of the approach, it is evident that no single approach of RE is universally useful [18]. Now the question arises that why it is so that no single approach is universally useful? For that we first need to understand the basic requirement of RE process in GSD environment. The requirements of the system are always informed by the situational context and therefore the most appropriate RE process is subject to the context [19]. It is very important to evaluate the contextual factors before selecting the appropriate process for any project [20]. Similarly [21] argues that approaches should be selected in accordance with the conditions, goals of organizations etc. “One size fits all” becomes a myth when we talk about RE process definition and one of the main reason behind is large variations in situational contexts. Although situational context is reported as a key concern during software development but

118


there is no study discussing and identifying various situational circumstances that affect the RE process in GSD environment. Therefore we analytically review relevant contributions and came up with an initial list of situational factors that affect RE process in GSD environment.

III.

The methodology used in this study is systematic literature review (SLR) adapted from the work of Kitchenham [33]. We designed an SLR protocol base upon which, situational factors are identified and then classified as shown in Table II. The list of situational factors with their classification was then gone through a data filtration process. In order to ensure the uniqueness of the situational factors and their classification (identified from SLR), we used the data coding techniques (constant comparison, and memoing) adopted from Grounded Theory [35]. Constant comparison technique is chosen as this technique not only allows comparison of data with data and category but also allows category to be compared with category, which is considered to be essential for analysis of data [36]. In our research we had to compare various situational factors gathered from various sources for their similarities and differences until we get the core situational factors and their categories. For identifying the similarities we performed filtration on basis of explicit and implicit duplications. Explicit duplication is the clear duplication e.g. if factor team experience will be found more than once then we consider them as explicit duplication. Such factor or categories are included once. Similarly factor team knowledge and team awareness have implicit duplication as their meaning is same. Such factors and categories are also written once by giving them a unique name. It was very hard to keep track on all these modifications, so in order to do that we used memoing technique [37]. This technique helped us in recording our analysis in written form. Table I shows the form with example, we have used in tracking the modifications related to situational factors.

The rest of the paper comprises of Section II describing the background, Section III describes the Research Methodology, Section IV describes the Results, Section V shows the discussions, limitations and future work and Section VI is conclusion. II.

RESEARCH METHODOLOGY

BACKGROUND

Studies have emphasized the importance of changing situations for successful software development. [22-27] argued that situations during software development vary considerably and as a consequence, it has an influence on RE. When RE is performed in GSD environment by considering the changing situations, then it is said to be situational RE in GSD. The factors due to which the situations vary are called situational factors. Weerd et al. [28] defined situational factors as “A situational factor (SF) is any factor relevant for product development and product services. Examples are company size, branch and the number of submitted requirements per month, whether or not currently a waterfall-based method is used for product software development, etc”. Recently Paul Clarke et al. [29] have identified the situational factors for software development and formulated them into a framework. They have generated an initial list of situational factors which can influence software development and be a progressive development in state of knowledge. Similarly Bekkers et al. [30] also came up with some list of situational factors for software product management. These factors are considered to influence the software product management. Samuel Fricker et al. [31] worked on contextual factors based on product line context like historical, organizational etc and allow taking decision about the design of RE process. These product line contextual factors considered to affect the RE process design, duration, cost estimation etc. There is another list of contextual factors identified by Dallman et al. [32]. The study consist of three contextual factors which can influence the RE creativity in terms of individuals and teams creativity.

TABLE I.

Although we come across studies that supports the importance of considering the changing situations while performing RE. However, none of the existing study identifies the situational factors that changes the situations for RE in GSD environment. Lack of such studies is challenging as it not only restrain the ability to improve the RE, but also it can undermine the competence of RE team to determine the core constraints and characteristics of developing software. Therefore, this study focuses on identification of the situational factors which affect RE in GSD environment.

"The authors would like to thank ‘The Ministry of Higher Education (MOHE)’ and Research Management Centre, Universiti Teknologi Malaysia for supporting this research work via Grant Number: 07J53" 119

SUMMARY OF FACTORS INFLUENCING RE IN GSD

Data unit

Similarity type

Data units having similarity

Study id

Suggested names of data units

Category/ Factor/subfactors

Explicit

Team experience

[std1], [std2]

Team members experience

Category/ Factor/subfactors

Implicit

Team knowledge, Team awareness

[std3], [std4]

Team members knowledge

Reasons

Awareness and knowledge have same meanings (synonyms), hence we suggest to modify them into a single factor “team members knowledge”


IV.

CLASSIFICATION

RESULTS

FACTORS Defect Occurrence Testing Accuracy

List of classified situational factors has been identified after removing explicit or implicit duplications among them. The list is then forwarded to expert from the academia specifically working in RE field. We then performed modifications base upon the reviewer recommendations. Factor Staff/ team are recommended not to be combined and should be used separately, either staff or either team. Similarly factor understanding and stating requirement is recommended to be renamed as requirement realization. A factor technical aspect is recommended to rename as organization technical maturity.

Factors shown in Table II are considered to be the situational factors which can lead to varying situations during RE in GSD environment. We take “Organization Resource” as an example to further explain the concept, that how situational factor can lead to varying situations. We say that Organization Resource is a situational factor and it can change the situations among the RE participants in GSD environment. Different organizations have different level of resources, when they work together for a single project then different level of resources changes the situations among organizations. Resources of organization can be Team members, Hardware, Finance etc. we take another example of varying situation where some of the RE participants may have updated hardware (systems) having very high internet access which is helping them to quickly and frequently contact with the client for requirements understanding, where as other RE team members may have old systems having slow internet services. Now these two different situations can affect the timely completion as well as clear understanding of the requirements. In order to overcome the issues due to varying situations among RE team members, accurate definition of RE process is important.

We performed modifications according to the reviewer recommendations and generated a unique list of 37 situational factors under 5 classifications that can influence RE in GSD environment. TABLE II.

SITUATIONAL FACTORS INFLUENCING RE IN GSD

CLASSIFICATION ORGANIZATION

FACTORS Organization Resource Organization Strategies Organization Standards Organization Culture Power Relations

We say that considering the situational characteristics by RE team members while defining RE process in GSD can further help them not only for timely completion of requirements phase but also to improve RE process.

Organization Learning Exposure Organization Politics Organization Practices Organization Technical Maturity Organization Regulations Organization Environment Organization Structure

V.

Organization Size STAKEHOLDER

Client

A. Utilizing Situational Factors A list of situational factors which can influence RE in GSD environment is identified. This research provides a sound contribution to software engineering body of knowledge (SEBOK) specifically to RE body of knowledge (REBOK) and GSD community. We believe that it can support GSD community to achieve its objective of assessing the real world problems in distributed environment. We believe that this study help RE participants to improve RE process in GSD environment as well as to determine the core constraints and characteristics of developing software in GSD environment.

Stakeholder Relationship Stakeholder Interaction Mode Requirements Realization Stakeholder Performance PROJECT

Problem Domain Project Characteristics Requirement Evolution Project Goals Requirements Estimation Project Risks Project Requirements

PROCESS

DISCUSSIONS

Team

B. Limitations The identification of situational factors is done based on literature; hence ignoring the feedback from software development industry. We made every effort to cover all the related papers discussing situational RE, but still it is possible that we may miss any published work. The threat of misinterpretation can not be ignored, as it is one of the must factor in every literature review, although we tried our best to overcome these aspect by dealing it carefully.

Tasks Techniques Process Selection Process Maturity Tools Management Knowledge Management Performance Management Decision Quality Metrics

120


[13]

C. Future Work In future a more comprehensive list can be generated by surveying software development industry, which is one of our ongoing research objectives. Besides this, a comprehensive situational RE framework can be generated for global software development environment which can act as a reference guide for the practitioners. This work identifies situational factors for RE phase that sets the ground for the researchers to extend this research by exploring situational factors for other software development phases in GSD environment.

[14]

[15]

[16] [17]

VI.

CONCLUSION [18]

Situations during software development vary considerably and as a consequence, it has an influence on RE. This can restrain the ability of RE team to improve RE process and can undermine their competence to determine the core constraints and characteristics of developing software. To address this issue, we have merged considerable research and identified the initial list of situational factors that affect the RE Process during GSD. We have performed SLR for situational factors identification and identified 37 situational factors. We consider the list of situational factors as a sound initial reference list for RE process definition in GSD environment.

[19] [20]

[21] [22]

REFERENCES [1] [2] [3]

[4] [5] [6] [7] [8] [9]

[10] [11] [12]

[23]

Nuseibeh, B. and S. Easterbrook, Requirements engineering: a roadmap, in Proceedings of the Conference on The Future of Software Engineering. 2000, ACM: Limerick, Ireland. p. 35-46. Damian, D. and D. Zowghi, RE challenges in multi-site software development organizations. Requirements Engineering, 2003. 8(3): p. 149-160. Hanisch, J. and B. Corbitt. Requirements Engineering During Global Software Development: Some Impediments To The Requirements Engineering Process – A Case Study in Proceedings of the Twelfth European Conference on Information Systems. 2004. Bhat, J.M., M. Gupta, and S.N. Murthy, Overcoming Requirements Engineering Challenges: Lessons from Offshore Outsourcing. Software, IEEE, 2006. 23(5): p. 38-44. Cheng, B.H.C. and J.M. Atlee, Research Directions in Requirements Engineering, in 2007 Future of Software Engineering. 2007, IEEE Computer Society. p. 285-303. Parviainen, P., Global software engineering Challenges and solutions framework, VTT Science. 6, Editor. 2012. p. 106 -150. I. Sommerville and P. Sawyer, "PREview Viewpoints for Process and Requirements Analysis," Lancaster University, Lancaster REAIMS/WP5.1/LU060, 29 May 1996. I. Sommerville and P. Sawyer, "Viewpoints: Principles, Problems and a Practical Approach to Requirements Engineering," Lancaster University, Lancaster SEG/15/1997, 1997. P. Sawyer, I. Sommerville, and S. Viller, "PREview: tackling the real concerns of requirements engineering." Cooperative Systems Engineering Group, Computing Department, Lancaster University, Lancaster, Technical Reports No: CSEG/5/96, 1996. A. Finkelstein and I. Sommerville, "The Viewpoints FAQ." L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos, Non- Funcitonal Requirements in Software Engineering: Kluwer Academic Publishers, 2000. M. Jackson, Problem Frames: Analyzing and Structuring Software Development Problems: ACM Press, 2001.

[24]

[25] [26] [27]

[28]

[29]

[30]

[31]

[32]

121

E. Gamma, R. Helms, R. Johnson, and J. Vlissdes, Design Patterns: Elements of Reusable Object-Oriented Software: Addison-Wesley, 1995. A. Rashid, A. Moreira, and J. Araujo, "Modularisation and Composition of Aspectual Requirements," presented at 2nd International Conference on Aspect Oriented Software Development (AOSD), Boston, USA, 2003. A. Rashid, P. Sawyer, A. Moreira, and J. Araujo, "Early Aspects: a Model for Aspect-Oriented Requirements Engineering," presented at International Conference on Requirements Engineering (RE), Essen, Germany, 2002. E. Baniassad and S. Clarke, "Finding Aspects in Requirements with Theme/Doc," presented at Workshop on Early Aspects (held with AOSD 2004), Lancaster, UK, 2004. E. Baniassad and S. Clarke, "Theme: An Approach for AspectOriented Analysis and Design," presented at International Conference on Software Engineering, 2004. C. Jones, Development Practices for Small Software Applications, CrossTalk, the Journal of Defense Software Engineering, 21 (2) (2008) 9-13. O. Benediktsson, D. Dalcher, H. Thorbergsson, Comparison of software development life cycles: a multi project experiment, IEE Proceedings - Software, 153 (3) (2006) 87-101. A. MacCormack, R. Verganti, Managing the Sources of Uncertainty: Matching Process and Context in Software Development, Journal of Product Innovation Management, 20 (3) (2003) 217-232. G. H. Subramanian, G. Klein, J. J. Jiang, C. Chan, Balancing four factors in system development projects, Communications of the ACM, 52 (10) (2009) 118-121. Feiler, P.H. and W.S. Humphrey. Software process development and enactment: concepts and definitions. in Software Process, 1993. Continuous Software Process Improvement, Second International Conference on the. 1993. Kautz, K., Software Process Improvement in very Small Enterprises : Does it Pay off?. In: Software Process Improvement and Practice, 1999: p. 209-226. MacCormack, Alan, and Roberto Verganti. "Managing the Sources of Uncertainty: Matching Process and Context in Software Development." Journal of Product Innovation Management 20 (May 2003): 217–232. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed. 2003: Addison-Wesley Longman Publishing Co., Inc. 304. Benediktsson, O., D. Dalcher, and H. Thorbergsson, Comparison of software development life cycles: a multi project experiment. Software, IEE Proceedings -, 2006. 153(3): p. 87-101. Ågerfalk, P.J. and J. Ralyté, Situational Requirements Engineering Processes: reflecting on method engineering and requirements practice. Software Process: Improvement and Practice, 2006. 11(5): p. 447-450. Van de Weerd, I., et al., A situational implementation method for web-based content management system-applications: method engineering and validation in practice. Software Process: Improvement and Practice, 2006. 11(5): p. 521-538. Clarke, P. and R.V. O'Connor, The situational factors that affect the software development process: Towards a comprehensive reference framework. Inf. Software. Technology. 2012. 54(5): p. 433-447. Bekkers, W., et al. The Influence of Situational Factors in Software Product Management: An Empirical Study. in Software Product Management, 2008. IWSPM '08. Second International Workshop on. 2008. Stoiber, R., et al. Feature Unweaving: Refactoring Software Requirements Specifications into Software Product Lines. in Requirements Engineering Conference (RE), 2010 18th IEEE International. 2010. Shaun Dallman , J.L., Jacob Cybulski , Godfrey Hirst. Contextual factors which influence creativity in requirements engineering in The Proceedings of 13th European Conference on Information Systems ECIS 2005. 2005.


[33] [34]

[35] [36] [37]

Kitchenham, B. and S. Charters, Guidelines for performing Systematic Literature Reviews in Software Engineering. 2007. Azhar, D., E. Mendes, and P. Riddle, A systematic review of web resource estimation, in Proceedings of the 8th International Conference on Predictive Models in Software Engineering. 2012, ACM: Lund, Sweden. p. 49-58. B. Glaser, Basics of Grounded Theory Analysis, Sociology Press, California, USA, 1992. J. Corbin, A. Strauss, Basics of Qualitative Research, Sage Publications Limited, Thousand Oaks, CA, USA, 2008. L. Lempert, Asking questions of the data: Memo writing in the grounded theory tradition, in The SAGE Handbook of Grounded Theory, A. Bryant, K. Charmaz, Eds., Sage, Thousand Oaks, CA, USA, pp. 245-264, 2007.

122