guides them to identify the most influential situational factors for each RE activity. Keywords-situational requirement engineering; global software development ...
2014 IEEE 2014 International Conference on Computer, Communication, and Control Technology (I4CT 2014), September 2 - 4, 2014 - Langkawi, Kedah, Malaysia
Situational Requirement Engineering Framework for Global Software Development Huma Hayat Khan , Mohd. Naz’ri bin Mahrin , Suriayati bt Chuprat Advanced Informatics School Universiti Teknologi Malaysia (UTM) Kuala Lumpur, Malaysia Abstract— In order to have a successful software development in Global Software Development (GSD) environment, GSD community needs to define RE process by considering the situational characteristics. Currently Requirement Engineers (RE) are facing challenges in identification of the possible situational factors that can influence RE activities. There is a lack of such framework which can help requirement engineers in identifying the situational factors that affect the RE activities the most. In order to overcome this gap, we explored the situational factors that can influence RE activities. We conducted a survey in industry and performed a statistical analysis in order to identify the most influential factors, which were then formulated into situational RE framework. This framework not only helps RE process participants to identify the situational factors but also guides them to identify the most influential situational factors for each RE activity. Keywords-situational requirement engineering; global software development; process definition
I.
INTRODUCTION
When context based requirement engineering (RE) is performed in global software development (GSD) environment, then it is named as globally distributed situational RE. Studies are already focusing on importance of changing situations for successful software development. Lie Feiler and colleague described about the basic software development process requirement; that it “should fit the needs of the project” [1]. Similarly it was argued that the software developers and process managers must first “evaluate a wide range of contextual factors before deciding on the most appropriate process to adopt for any given project” [2]. It was also concluded, that the process definition claim of “one size fits all” is a myth [3] and it is due to the variation in situations [4]. These varying situations should be considered and known while identifying the project needs [5] as they have strong influence on RE process [6]. The factors due to which the situations vary are called situational factors and are defined 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”[7].
978-1-4799-4555-9/14/$31.00 ©2014 IEEE
224
From the above discussion, we conclude that the varying situations are most influential on software RE phase. These varying situations are a result of situational factors, which further need to be explored. There is a lack of such studies that explores and describes the most influential situational factors for each RE activity. Therefore our research focuses on the identification of most influential factors that can affect RE activity the most in GSD environment. We conducted a survey in industry and performed a statistical analysis. The results were formulated into a situational RE framework. The rest of the paper is structured as follows. Section II describes the background of the study, section III illustrates the methodology of the study, section IV comprises of results, section V consists of discussion and section VI is the conclusion of the study.
II.
BACKGROUND
Requirement engineers face challenges in dealing with distributed team members and clients for communicating the requirements of the developing software. These challenges are faced due to ignoring the contextual characteristics. There are few studies found, which focuses on contextual characteristics or factors. Like The most recent work on situational factor is done by Paul Clarke et al. They came up with a situational factors base framework for software development process. Researchers argued that optimal software development process is regarded as being dependent on the situational characteristics of individual software development settings however, there is no comprehensive reference framework for this. Hence they came up with a Software process development framework based on the situational factors affecting the software development process. Although this framework was the first step towards situational software development but its scope was too general and did not give details at software development phase’s level. Similarly the identification of factors was done irrespective of geographical locations aspects [4]. The geographic locations play a vital role in success and failure of any software. Specifically when we talk about RE phase, it is well known that RE becomes more complex when it is performed in GSD environment. Ghosh et al. tackled the issue, but had only focused their work to requirement management. They argued that requirements management is a complex task specifically when it goes to global platform. So
they came up with a C-FaRM framework designed to help managing requirements knowledge from requirements artifacts. Although this framework was only for requirements management activity of RE, but it focused on GSD and situational aspects [8]. We came across another framework formulated by Marko Bajec et al. They developed a framework by considering the need for the organizations to re-engineer their existing ways of working. Besides this their work established formalized methods that are organization-specific and are auto adjustable to specifics of their projects. Although the framework helped software companies to establish formalized methods that would be technically and socially sound with their needs, but it did not covers the situational contexts for RE both at general and activity level. Besides this their work also ignores the GSD aspects while developing the framework [9]. Researchers have also worked on behavior and argued that there is a lack of adequate means of accounting for such contextual and situational factors which influence behavior. Hughes came up with a framework which is specifically focusing the Information system domain. The framework was named as, “The Ability Motivation Opportunity (AMO) framework”. This framework talks about the situational factors but only focuses on behaviors in general, hence does not deal with software RE in specific along with missing the GSD aspects [10]. Similarly another framework related to information system development projects was formulated by Mirbel et al. They argued that the engineering situation of each information system development project is different due to the reason that engineering methods need to be adapted and then transformed or enhanced to satisfy the project situation. For that they came up with a framework which is specific for the Information system software domain. This framework is focusing SME based on combining an assembly based approach for project specific method construction and a road map approach for engineering specific method construction but lacking the contextual support for software RE and GSD [11] . Although the above mentioned studies have identified the situational factors and formulated them in a framework but none of the above mentioned framework focuses on situational requirement engineering for GSD environment. Besides this they were unable to find the most influential situational factors. Our situational RE framework not only describes the situational factors that can affect RE process but also identifies the most influential factors for each RE activity in GSD environment. III.
Target Audience: This study focused on the software organizations working in global software development environment. The target audience for our research was the requirement engineers from software development organizations working in global environment. Sampling: A sample is the subset of total population, having characteristics of the population. In this study, the questionnaire was sent to the globally distributed software organizations listed in official portal of multimedia development corporation Malaysia (MSC) and Pakistan software export board (PSEB). These directories were utilized because they are considered as the authentic source for registered software development companies. A purposive sample of 62 globally distributed software development companies was drawn. We used purposive sampling strategy because our target audience was a specific group and was not possible to specify the population as we could not know all of them, hence accessing them were difficult. Respondents title (e.g. Human Resource Managers) were selected, so that the questionnaire could be forwarded to the relevant department and accurate feedback could be gathered. Questionnaire Development: A questionnaire was designed for identification of the most influential situational factors for each of the RE activity. The questionnaire was divided into two main sections. The first section of the questionnaire was aimed to identify the respondent’s personal information, their current position in organization, RE activity they are working on, their experience in RE and overall experience in GSD. In second section of the questionnaire they were given a list of situational factors which was from our previous research which was performed to identify the situational factors that affect RE process in GSD environment [13]. We used the five point Likert scale; strongly influential = 5, influential = 4, moderate = 3, weakly influential = 2, Not influential = 1. Influence for each RE activity: Requirement elicitation (RE), Requirement Analysis (RA), Requirement Specification (RS), Requirement Validation (RV), and Requirement Management (RM) were asked in the questionnaire. Figure 1 shows the example snap shot of the questionnaire.
Figure 1. Example of the questionnaire
METHODOLOGY
A survey through questionnaire approach was conducted. We followed the work of Kasunic, published by Software Engineering Institute (SEI), as it is most commonly and widely used handbook for conducting effective survey in field of software engineering [12]. Objectives of Survey Conduction: To identify the most influential situational factors for each RE activity.
225
Pilot Test Questionnaire: The questionnaire development process included a pilot study, which was used for modifications and eliminations, until the final questionnaire was designed. We conducted the pilot study for validation and improvement of the questionnaire, in terms of the statements, wordings, sequencing along with the potential interests of the participants. The questionnaire was forwarded to some of the members of the target audience. We managed
to get 23 responses from target audience. The comments were generally related to wordings of the questions and statements. Some of the respondents commented that they faced difficulty in understanding the definition of situational factors. Similarly some have shown concerns related to questions descriptions. Base upon their comments and suggestions the questionnaire was modified and improved. The questions and statements were corrected and improved for their clear and accurate understandings. Questionnaire Distribution and Data Collection: After completing the pilot study the questionnaire was sent to the target participants, listed in the directories of multimedia development corporation Malaysia (MSC) and Pakistan software export board (PSEB). In this study we used online survey to get data from multiple respondents irrespective of their geographical location. The survey was sent to the target companies in early May 2013. Of the 62 mails sent, a total of 25 responded and replied that the questionnaire is forwarded to the appropriate department to respond. 21 companies who responded were from the directory of Pakistan software export board (PSEB) and 4 companies from the directory of multimedia development corporation Malaysia (MSC). 37 packages were returned due to incorrect email-addresses. The follow up emails were sent to the non- respondents of the 25 companies about one month after the first email. This process continued and we kept on getting responses slowly. After three and a half months we got 54 responses, which were still very low in percentage. In an attempt to increase the response rate we planned to visit some of the companies featured in the multimedia development corporation Malaysia (MSC) portal. We managed to visit and get appointment from some of the software development companies located in Cyberjaya and Kuala Lumpur. After they agreed, we forwarded the survey by email and managed to get 60 more responses with in this duration. Finally with combining all the responses, a total of 114 responses were received. 31 among the total responses were not usable due to incomplete answers, thus resulting in 83 complete responses that were used in our data analysis. Test of Response Bias: Assessment of the potential response biasness was performed by examining the data gathered from the early and late respondents. We followed the guide by Lineback et al., who have reported the ways to deal with responses biasness [14]. In actual, this type of time base comparison, late respondents (respondents responded after many follow-up attempts) can be considered as alternative or substitute for non-respondents [14]. In this study the data gathered from the respondents were decomposed into two parts based upon their receiving dates. The respondents from the first email till sending the online questionnaire were considered as early respondents and the responses we got from the companies we visited physically were considered as late respondents. The t-test was performed on the responses gathered from these two groups. We performed our analysis for each RE activity. The homogeneity of responses for; requirement elicitation is 92.5%, requirement analysis is 94.16%, requirement specification is 96.66%, requirement
226
validation is 96.66% and requirement management is 97.5%. Hence we found that there was no significant difference among early and late respondent’s responses. As a result it came out with no probable biasness due to sampling sources. IV.
RESULT
The data gathered from industry was then analyzed and the mean influential values were calculated. It can be seen that the mean influential values of sub-factors of each factor for; requirement elicitation ranged from 1.8625 to 5.0000, requirement analysis ranged from 1.8625 to 5.0000, requirement specification, validation and management ranged from 1.3133 to 5.0000. In order to come up with most influential factors, we calculated a composite mean value for each factor. The factors whose composite mean values are equal to or above 4.000 are considered as most influential factors for particular RE activity. The most influential factors based upon their composite mean values for each RE activity are shown in Figures 2-6.
Figure 2. Most Influential Factors for Requirement Elicitation
Figure 3. Most Influential Factors for Requirement Analysis
Figure 4. Most Influential Factors for Requirement Specification
etc. Our ongoing research activity is to develop a web based situational RE framework in order to have an electronic situational requirement engineering guide, that will also allow to requirement engineers to access their RE process for the situational factors that can affect their RE process. VI.
CONCLUSION
Contextual characteristics or factors play a vital role in defining accurate RE process. In this research we have statistically analyzed the factors and came up with a list of most influential factors for each RE activity. The results were further formulated into a situational requirement engineering framework not only helps RE process participants to identify the situational factors but also guides them to identify the most influential situational factors for each RE activity.
Figure 5. Most Influential Factors for Requirement Validation
REFERENCES Figure 6. Most Influential Factors for Requirement Management
1.
Based upon the most influential situational factors for each RE activity we formulated a situational RE framework. This framework not only describes the set of all situational factors that can influence RE in GSD but also guides about the most influential factors for each RE activity from rank of highest to lowest. The framework is attached in the Appendix. V.
2.
3. 4.
DISCUSSION
A. Utilization of Situational RE Framework The situational RE framework acts as a reference guideline and checklist that is a step further towards RE body of knowledge, as it provides information about the situational factors that are influential for any RE activity. By influential situational factors, we mean that these are the factors that influence the RE process definition in GSD environment. This situational RE framework is the novel step towards situational RE in GSD environment. It not only helps practitioners and academicians to identify the factors and sub-factors that can influence RE process in GSD but also shows their mapping or association to each RE activity. The association or mapping feature of situational RE framework shows the most influential factors for each RE activity. Appendix shows the situational RE framework where the situational factors and sub-factors for each category are shown besides with its mapping to RE activities. The framework also presents the outcome of the mapping activity in terms of situational factors that influence the respective RE activity in most. This deep rooted knowledge of situational factors at RE activity level helps the requirement engineers to carefully define their RE process by considering the situational characteristics. B. Future Work This situational framework is specific to Requirement Engineering phase of software Development Life Cycle (SDLC), which in future can be extended to other phases of SDLC e.g. software analysis, construction, implementation
227
5. 6.
7.
8.
9. 10. 11. 12. 13.
14.
Feiler, P. and W. Humphrey, Software process development and enactment: concepts and definitions. , in Second International Conference on the Continuous Software Process Improvement. 1994. MacCormack, A. and R. Verganti, Managing the Sources of Uncertainty: Matching Process and Context in Software Development. Journal of Product Innovation Management, 2003. 20(3). Subramanian, G.H., et al., Balancing four factors in system development projects. Commun. ACM, 2009. 52(10): p. 118-121. Clarke, P. and R.V. O’Connor, The situational factors that affect the software development process: Towards a comprehensive reference framework. Information Software Technology, 2012. 54(5). Benediktsson, O., D. Dalcher, and H. Thorbergsson, Comparison of software development life cycles: a multiproject 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). Weerd, I.v.d., et al., A situational implementation method for webbased content management system-applications: method engineering and validation in practice. Software Process: Improvement and Practice, 2006. 11(5). Ghosh, S., A. Dubey, and S. Ramaswamy. C-FaRM: A collaborative and context aware framework for requirements management. in Managing Requirements Knowledge (MARK), 2011 Fourth International Workshop on. 2011. Bajec, M. and D. Vavpoti, A Framework and Tool-Support for Reengineering Software Development Methods. Informatica, 2008. 19(3). Hughes, J. The Ability-Motivation-Opportunity Framework for Behavior Research in IS. in 40th Annual Hawaii International Conference on System Sciences. HICSS 2007. Mirbel, I. and J. Ralyté, Situational method engineering: combining assembly-based and roadmap-driven approaches. Requirements Engineering, 2006. 11(1). Kasunic, M., Designing an Effective Survey. 2005: Software Engineering Institute. Khan, H.H., M.N.r. Mahrin, and S.b. Chuprat, Situational Factors Affecting Requirement Engineering Process in Global Software Development, in IEEE Conference on Open Systems(ICOS 2013), IEEE, Editor. 2013. Lineback, J.F. and K.J. Thompson, Conducting Nonresponse Bias Analysis for Business Surveys Journal of Services Marketing, 2010.
228
Strategic partnership, Industrial network, Organization structure policy, Control and reward incentives, Business management strategy, Management practices
Hardware, Software, Economic Aspect, Data/ Information, Resource Availability, and Funding
Application emphasis, Goal understanding and assessment, Requirement precedence, Time to market
Problem domain complexity, Problem domain fuzziness, Solution type
Task time interval, Activity multiplicity, Activities sequence
Task
Project Characteristics
Problem Domain Conflicting needs, Requirement change frequency, Requirement change magnitude, Add-on’s
Requirement evolution
Client availability, Client commitment, Client social relationship, Client skills
Team motivation , Team experience, Workplace awareness, Job security, Carrier stage , Team historical context, Roles multiplicity, Guidance, Personal attributes, Team cohesion, Team performance, Priority to situation urgency, Team leadership skills, Team level of receiving help with heavy workload, Team socio-culture background, Perceived job alternatives, Team members view points, Team familiarity with each other, Team technical expertise, Team learning exposure, Team relevant domain background, Team effort, International work experience, Team member assumptions of social and industrial relations
Estimation skills, Estimation process, Estimation checklist, Estimation training, Estimation tools and techniques, Reporting templates
Requirement estimation
Project
Client
Team
Tools or technology advancements, Tools or technology selection
Technical Maturity
Requirement specification format, Quality of reviewed requirement, Customer needs, Requirement techniques and approaches, Requirement traceability, Requirements artifacts multiplicity
Risk monitoring, Risk assessment and manageme nt, Change control
Process models, Process features, Organizati onal support for process selection
Process Selection
Interaction skills, Interaction language, Interpretation skills, Project information understanding
Understanding and Stating Requirement
Requirements
Organization priority for mode of interaction, Interaction mode preference base on temporal or quality desires
Stakeholder Interaction Mode
Organization nature, Social aspects of workplace and working organization, Social interactions, Politics, Utility values, Team inter group culture
Culture
Risk
Standard selection criteria, Outcome quality measures, Organization regulations and deregulations Resource Availability and Funding
Standard
Stakeholder
Strategies
Resource
Organization
Defect prediction approach and technique, Quality metrics
Defect Occurrence
Testing
Management coordination skills, Management competence, Management commitment
Management Performance
Testing effort, Test planning, testing environment, testing process, testing accuracy
Defects
Management techniques awareness, Business management awareness, Knowledge management awareness, Configuration management awareness, Resource management awareness
Management Awareness
Management
Organizational structure, External power relation with partners, environment Change adaptability, Working atmosphere, Environment, operational aspects, Departmental interfacing, Environmental stimuli and events
Environment
229 Situational Requirement Engineering (SRE) Framework
Most Influential Factors for Each RE Activity when Performed In GSD Environment
RE Process Mapping
Sub-Factors
Factors
Classificatio
Most Influential Factors
RE
