RE challenges in multi-site software development organisations

The increasing globalisation of the software industry demands an investigation of requirements engineering (RE) in multi-site software development organisations. Requirements engineering is a task difficult enough when done locally—but it is even more difficult when cross-functional stakeholder groups specify requirements across cultural, language and time zone boundaries. This paper reports on a field study that investigated RE challenges introduced by the stakeholders' geographical distribution in a multi-site organisation. The goal was to examine RE practices in global software development, and to formulate recommendations for improvement as well as to provide directions for future research on methods and tools. Based on the empirical evidence, we have constructed a model of how remote communication and knowledge management, cultural diversity and time differences negatively impact requirements gathering, negotiations and specifications. Findings reveal that aspects such as a lack of a common understanding of requirements, together with a reduced awareness of a working local context, a trust level and an ability to share work artefacts significantly challenge the effective collaboration of remote stakeholders in negotiating a set of requirements that satisfies geographically distributed customers. The paper concludes with recommendations for improving RE practices in this setting.

A Process Framework for Global Software Engineering Teams

ContextGlobal Software Engineering (GSE) continues to experience substantial growth and is fundamentally different to collocated development. As a result, software managers have a pressing need for support in how to successfully manage teams in a global environment. Unfortunately, de facto process frameworks such as the Capability Maturity Model Integration (CMMI®) do not explicitly cater for the complex and changing needs of global software management.ObjectiveTo develop a Global Teaming (GT) process area to address specific problems relating to temporal, cultural, geographic and linguistic distance which will meet the complex and changing needs of global software management.MethodWe carried out three in-depth case studies of GSE within industry from 1999 to 2007. To supplement these studies we conducted three literature reviews. This allowed us to identify factors which are important to GSE. Based on a gap analysis between these GSE factors and the CMMI®, we developed the GT process area. Finally, the literature and our empirical data were used to identify threats to software projects if these processes are not implemented.ResultsOur new GT process area brings together practices drawn from the GSE literature and our previous empirical work, including many socio-technical factors important to global software development. The GT process area presented in this paper encompasses recommended practices that can be used independently or with existing models. We found that if managers are not proactive in implementing new GT practices they are putting their projects under threat of failure. We therefore include a list of threats that if ignored could have an adverse effect on an organization’s competitive advantage, employee satisfaction, timescales, and software quality.ConclusionThe GT process area and associated threats presented in this paper provides both a guide and motivation for software managers to better understand how to manage technical talent across the globe.     

A field study of the requirements engineering practice in Australian software industry

Empirical studies have demonstrated that requirements errors introduced during software development are most numerous in the software life-cycle, making software requirements critical determinants of software quality. This article reports an exploratory study which provides insight into industrial practices with respect to requirements engineering (RE). A combination of both qualitative and quantitative data is collected, using semi-structured interviews and a detailed questionnaire from 28 software projects in 16 Australian companies. The contribution of this RE study is threefold: Firstly, it includes a detailed examination of the characteristics of the RE activities involved in the projects. Secondly, it reconstructs the underlying practiced process models. Thirdly, it compares these models to one another and with a number of well-known process models from RE literature to give insight into the gap between RE theory and practice.     

Guest Editors' Introduction: Stakeholders in Requirements Engineering

The growing attention being paid to stakeholders' needs and desires reflects the growing importance of requirements engineering (RE) in software and systems development. This introduction reviews the RE process: identifying the stakeholders in a project, determining who and how important they are, prioritizing the identified stakeholder roles, and selecting representative individuals or groups from the identified and prioritized stakeholder roles with whom the development team can elicit and validate system requirements. The authors then mention each article in the issue in the context of today's latest thinking on RE. This article introduces a special issue on stakeholders in requirements engineering.     

Impediments to requirements engineering during global software development

Developing software when team members are located in widely distributed geographic locations poses many challenges for developers, particularly during the requirements engineering (RE) phase. Using a case study of a large software development project with users located in the UK and software developers from an international software house based in New Zealand, the paper argues that while global RE using electronic communication media may be desirable in achieving economy of resources, social and cultural aspects of RE need to be considered so that lasting relationships with clients may be formed, and RE activities achieved. The main impediments to the process of RE during global software development are communication resulting from differences in shared meanings and context associated with the following: distribution of the clients and the development team; distribution of the development team; cultural differences between the clients and the development team; and cultural differences among the development team.     

Overcoming Requirements Engineering Challenges: Lessons from Offshore Outsourcing

Requirements engineering practices have changed significantly to address the needs of global software development characterized by teams working across geographies, time zones, and organizational boundaries. By sharing real-life case studies based on experience of an Indian IT services outsourcing firm, the authors provide insights into the root causes of RE phase conflicts within client-vendor offshore relationships. On the basis of this analysis, they propose a set of strategic success factors that potentially address a variety of RE challenges in the multiparty global software development context. They also propose a holistic framework of best practices across people-process-technology dimensions to achieve the success factors. This article is part of a special issue on Global Software Development.     

Data collection in global software engineering research: learning from past experience

Global Software Engineering has become a standard in today’s software industry. Research in distributed software development poses severe challenges that are due to the spatial and temporal distribution of the actors, as well as to language, intercultural and organizational aspects. These challenges occur in addition to “traditional” challenges of the domain itself in large-scale software projects, like coordination and communication issues, requirements volatily, lack of domain knowledge, among others. While several authors have reported empirical studies of global software development projects, the methodological difficulties and challenges of this type of studies have not been sufficiently discussed. In this paper, we share our experiences of collecting and analysing qualitative data in the context of Global Software Engineering projects. We discuss strategies for gaining access to field sites, building trust and documenting distributed and complex work practices in the context of several research projects we have conducted in the past 9 years. The experiences described in this paper illustrate the need to deal with fundamental problems, such as understanding local languages and different cultures, observing synchronous interaction, or dealing with barriers imposed by political conflicts between the sites. Based on our findings, we discuss some practical implications and strategies that can be used by other researchers and provide some recommendations for future research in methodological aspects of Global Software Engineering.     

A cost-value approach for prioritizing requirements

Developing software systems that meet stakeholders' needs and expectations is the ultimate goal of any software provider seeking a competitive edge. To achieve this, you must effectively and accurately manage your stakeholders' system requirements: the features, functions, and attributes they need in their software system. Once you agree on these requirements, you can use them as a focal point for the development process and produce a software system that meets the expectations of both customers and users. However, in real world software development, there are usually more requirements than you can implement given stakeholders' time and resource constraints. Thus, project managers face a dilemma: how do you select a subset of the customers' requirements and still produce a system that meets their needs? The authors developed a cost-value approach for prioritizing requirements and applied it to two commercial projects     

An empirically based terminology and taxonomy for global software engineering

Many organizations nowadays strive for utilization of benefits offered by global software engineering (GSE) and sourcing strategies are thus discussed more often. Since there are so many variations of the attributes associated with global software projects a large amount of new terms has been introduced. The diversity in sourcing jargon however has caused difficulties in determining which term to use in which situation, and thus causing further obstacles to searching and finding relevant research during e.g. systematic literature reviews. The inability of judging the applicability of the research in an industrial context is another important implication on the transferability of research into practice. Thus the need for accurate terminology and definitions for different global sourcing situations emerges as a way for the community to build upon each other’s work and hence making progress more quickly. In this paper we first investigate the state of the use of the GSE jargon concluding that terminology is very diverse (many synonyms used to describe the same phenomena), often confusing (same terms used to describe different phenomena) and occasionally ambiguous (few terms used to describe several phenomena). In order to address the identified problems, we conducted a Delphi-inspired study with ten well-established researchers in GSE and developed an empirically based glossary for the key concepts in global software engineering. We then propose a taxonomy for GSE by categorizing the selected terms based on generalization-specialization relationships and illustrate how the taxonomy can be used to categorize and map existing knowledge. The contribution targets future researchers, who will publish or synthesize further empirical work and practitioners, who are interested in published empirical cases. Therefore this work is expected to make a contribution to the future development of research in the GSE field, and alleviate understandability and transferability of existing and future knowledge into practice.     

PBURC: a patterns-based,unsupervised requirements clustering framework for distributed agile software development

Agile software development methodologies are increasingly adopted by organizations because they focus on the client’s needs, thus safeguarding business value for the final product. At the same time, as the economy and society move toward globalization, more organizations shift to distributed development of software projects. From this perspective, while adopting agile techniques seems beneficial, there are still a number of challenges that need to be addressed; among these notable is the effective cooperation between the stakeholders and the geographically distributed development team. In addition, data collection and validation for requirements engineering demands efficient processing techniques in order to handle the volume of data as well as to manage different inconsistencies, when the data are collected using online tools. In this paper, we present “PBURC,” a patterns-based, unsupervised requirements clustering framework, which makes use of machine-learning methods for requirements validation, being able to overcome data inconsistencies and effectively determine appropriate requirements clusters for optimal definition of software development sprints.     

A multi-case study of agile requirements engineering and the use of test cases as requirements

ContextIt is an enigma that agile projects can succeed ‘without requirements’ when weak requirements engineering is a known cause for project failures. While agile development projects often manage well without extensive requirements test cases are commonly viewed as requirements and detailed requirements are documented as test cases.ObjectiveWe have investigated this agile practice of using test cases as requirements to understand how test cases can support the main requirements activities, and how this practice varies.MethodWe performed an iterative case study at three companies and collected data through 14 interviews and two focus groups.ResultsThe use of test cases as requirements poses both benefits and challenges when eliciting, validating, verifying, and managing requirements, and when used as a documented agreement. We have identified five variants of the test-cases-as-requirements practice, namely de facto, behaviour-driven, story-test driven, stand-alone strict and stand-alone manual for which the application of the practice varies concerning the time frame of requirements documentation, the requirements format, the extent to which the test cases are a machine executable specification and the use of tools which provide specific support for the practice of using test cases as requirements.ConclusionsThe findings provide empirical insight into how agile development projects manage and communicate requirements. The identified variants of the practice of using test cases as requirements can be used to perform in-depth investigations into agile requirements engineering. Practitioners can use the provided recommendations as a guide in designing and improving their agile requirements practices based on project characteristics such as number of stakeholders and rate of change.     

System requirements-OSS components: matching and mismatch resolution practices – an empirical study

Developing systems by integrating Open Source Software (OSS) is increasingly gaining importance in the software industry. Although the literature claims that this approach highly impacts Requirements Engineering (RE) practices, there is a lack of empirical evidence to demonstrate this statement. To explore and understand problems and challenges of current system requirement–OSS component matching and mismatches resolution practices in software development projects that integrate one or more OSS components into their software products. Semi-structured in-depth interviews with 25 respondents that have performed RE activities in software development projects that integrate OSS components in 25 different software development companies in Spain, Norway, Sweden, and Denmark. The study uncovers 15 observations regarding system requirements-OSS components matching and mismatch resolution practices used in industrial projects that integrate OSS components. The assessed projects focused mainly on pre-release stages of software applications that integrate OSS components in an opportunistic way. The results also provide details of a set of previously unexplored scenarios when solving system requirement–OSS component mismatches; and clarify some challenges and related problems. For instance, although licensing issues and the potential changes in OSS components by their corresponding communities and/or changes in system requirements have been greatly discussed in the RE literature as problems for OSS component integration, they did not appear to be relevant in our assessed projects. Instead, practitioners highlighted the problem of getting suitable OSS component documentation/information.     

The role of distances in requirements communication: a case study

Requirements communication plays a vital role in development projects in coordinating the customers, the business roles and the software engineers. Communication gaps represent a significant source of project failures and overruns. For example, misunderstood or uncommunicated requirements can lead to software that does not meet the customers’ requirements, and subsequent low number of sales or additional cost required to redo the implementation. We propose that requirements engineering (RE) distance measures are useful for locating gaps in requirements communication and for improving on development practice. In this paper, we present a case study of one software development project to evaluate this proposition. Thirteen RE distances were measured including geographical and cognitive distances between project members, and semantic distances between requirements and testing artefacts. The findings confirm that RE distances impact requirements communication and project coordination. Furthermore, the concept of distances was found to enable constructive group reflection on communication gaps and improvements to development practices. The insights reported in this paper can provide practitioners with an increased awareness of distances and their impact. Furthermore, the results provide a stepping stone for further research into RE distances and methods for improving on software development processes and practices.

     

Requirements engineering—exploring the influence of power and Thai values

This paper explores the impact of Thai social status and hierarchical decision-making processes during Requirements Engineering (RE) in business information systems development projects. The paper illustrates the interaction of RE processes and national culture and shows that culture can change the way processes are implemented, rather than process changing culture. Thai culture is naturally inherent in Thai daily life and Thais bring that into their work information practices. The concepts of power in Thai culture contributes toward hierarchical forms of communication and hierarchical relationships between systems analysts and decision-making process in Thai software houses, especially during RE, where information systems (IS) requirements need to be established for further development. The research shows that power significantly influences the decision making process and the construction of social status between clients and systems analysts in Thailand. The hierarchical structure of Thai organisations also contributes to a bureaucratic, elongated decision-making process during information systems development (ISD). Understanding the influence of power in Thai culture on RE will assist multinational IS consulting organisations to select, adapt, better manage, or change RE process methodologies.     

Managing Knowledge in Global Software Development Efforts: Issues and Practices

The knowledge-intensive nature of current global software development efforts poses interesting challenges. Organizations must manage knowledge in all stages of software development efforts—from encapsulating design requirements to creating and testing programs, installation, and maintenance. Knowledge even extends to the improvement of organizational software development processes and practices. This article examines knowledge management practices in more than 50 software organizations over the last three years, describing the major findings in the context of knowledge management in software development efforts on a global scale.This article is part of a special issue on Global Software Development.     

An Empirical Study of the Complex Relationships between Requirements Engineering Processes and Other Processes that Lead to Payoffs in Productivity, Quality, and Risk Management

Requirements engineering is an important component of effective software engineering, yet more research is needed to demonstrate the benefits to development organizations. While the existing literature suggests that effective requirements engineering can lead to improved productivity, quality, and risk management, there is little evidence to support this. We present empirical evidence showing how requirements engineering practice relates to these claims. This evidence was collected over the course of a 30-month case study of a large software development project undergoing requirements process improvement. Our findings add to the scarce evidence on RE payoffs and, more importantly, represent an in-depth explanation of the role of requirements engineering processes in contributing to these benefits. In particular, the results of our case study show that an effective requirements process at the beginning of the project had positive outcomes throughout the project lifecycle, improving the efficacy of other project processes, ultimately leading to improvements in project negotiation, project planning, and managing feature creep, testing, defects, rework, and product quality. Finally, we consider the role collaboration had in producing the effects we observed and the implications of this work to both research and practice.     

Eliciting and prioritizing quality requirements supported by ontologies: a case study using the ElicitO framework and tool

As software complexity grows and clients demand higher quality software, quality requirements can no longer be considered to be of secondary importance. Thus, eliciting, specifying, prioritizing and validating quality requirements is a prerequisite to the development of effective and efficient information systems. Despite the critical importance of quality requirements, there is a considerable gap in the breadth and depth of quality requirements engineering (RE) support in most RE approaches. In practice, it is often the case to have quality requirements considered as an afterthought in the systems development process. While there is a wealth of modelling techniques and tools for functional requirements, there is very limited support for quality requirements in RE. Support for quality requirements is usually ad‐hoc, without clear guidelines on how to capture, specify and manage quality requirements and also without proper usage of standardized terminologies based on established quality models such as the ISO/IEC 9126 quality model. In this paper, we discuss a quality‐driven RE framework and tool that applies knowledge management techniques and quality ontologies to support RE activities. The ontology implements the quality characteristics and metrics prescribed by the ISO/9126 quality model, providing a common vocabulary to address quality concerns/aspects across RE activities. We empirically validate how the framework and tool can be used to effectively support the requirements elicitation and prioritization activities through a case study addressing the development of an intranet portal project at the University of Manchester.     

Managing Software Engineering Projects: A Social Analysis

Managing software engineering projects requires an ability to comprehend and balance the technological, economic, and social bases through which large software systems are developed. It requires people who can formulate strategies for developing systems in the presence of ill-defined requirements, new computing technologies, and recurring dilemmas with existing computing arrangements. This necessarily assumes skill in acquiring adequate computing resources, controlling projects, coordinating development schedules, and employing and directing competent staff. It also requires people who can organize the process for developing and evolving software products with locally available resources. Managing software engineering projects is as much a job of social interaction as it is one of technical direction. This paper examines the social arrangements that a software manager must deal with in developing and using new computing systems, evaluating the appropriateness of software engineering tools or techniques, directing the evolution of a system through its life cycle, organizing and staffing software engineering projects, and assessing the distributed costs and benefits of local software engineering practices. Ths purpose is to underscore the role of social analysis of software engineering practices as a cornerstone in understanding what it takes to productively manage software projects.     

Guest Editors' Introduction: Global Software Development: How Far Have We Come?

Global software development efforts have increased in recent years, and such development seems to have become a business necessity for various reasons, including cost, availability of resources, and the need to locate development closer to customers. However, there's still much to learn about global software development before the discipline becomes mature. This special issue aims to assess the gap between the state of the art and the state of the practice. It presents five articles that cover various aspects of global software development, including knowledge management strategies, distributed software development, requirements engineering, distributed requirements, and managing offshore collaboration. A Point/Counterpoint department discusses whether global software development is indeed a business necessity.This article is part of a special issue on Global Software Development.