Agile Requirements Engineering Research Articles

Investigation of Adherence Degree of Agile Requirements Engineering Practices in Non-Agile Software Development Organizations

Requirements are critical for the success of software projects. Requirements are practically difficult to produce, as the hardest stage of building a software system is to decide what the system should do. Moreover, requirements errors are expensive to fix in the later phases of the software development life cycle. The rapidly changing business environment is highly challenging traditional Requirements Engineering (RE) practices. Most of the software development organizations are working in such dynamic environment, as a result, either by or without their awareness agile methodologies are adopted in various phases of their software development cycles. The aim of this paper is to investigate the adherence degree of agile RE practices in various software development organizations that are classifying themselves as adopting traditional (i.e. non-agile) software development methodologies. An approach is proposed for achieving this aim and it is applied on five different projects from four different organizations. The result shows that even the non-agile software development organizations are applying agile RE practices by different adherence degrees.

A comparative study of software tools for user story management

ContextUser stories have become widely accepted in agile software development. Consequently, a great number of software tools that provide, inter alia, support for practices based on user stories have emerged in recent years. These tools may have different features and focus in terms of support for agile requirements engineering (RE) concepts and practices. ObjectiveThe present study aims to provide a deep insight into the current capabilities and future trends of software support for agile RE practices based on user stories. MethodA comparative qualitative study of a set of agile software tools has been conducted according to the following criteria: coverage of the key functional requirements, support for basic agile RE concepts and practices, and user satisfaction with the tool. The criteria for tool selection were: diversity of software tools, high rating on the user-stories community Web site (http://www.userstories.com), and availability for review. ResultsThe results show a generally good coverage of key functional requirements related to management of user stories and epics, high-level release planning and low-level iteration planning. On the other hand, user-role modeling and persona support have not been addressed at all, and it has been found that requirements for acceptance testing support were completely covered by only one tool. More importantly, the study has revealed significant differences in the way different tools support agile RE concepts and practices (if at all). Finally, qualitative analysis of user reviews has demonstrated that practitioners prefer tools that are easy to set up, easy to learn, easy to use, and easy to customize, over more sophisticated but simultaneously more demanding tools. ConclusionAlthough the progress that has been made since the inception of these tools is quite clear, there is still room for improvements in terms of support for various agile RE practices within a specific agile process.

A Survey of Agile and Traditional Requirements Engineering

In the past few years, there has been an increasing awareness of the important role of requirements engineering (RE) in a project’s success, in both research and industry. Developing consistent requirements specifications that meet the customers’ needs, in traditional development, is likely to be infeasible. For one reason, customers do not usually have a clear picture of what they really want. Secondly, the business domain could be changing quickly, especially if it heavily depends on technologies. Agile software development (ASD), on the other hand, supports iterative and incremental development and emphasises customers’ involvement in the development process. We argue that adopting ASD in RE overcomes the limitations of the traditional development. ASD, however, is no silver bullet and its adoption comes at a price. This paper helps the reader to: (1) get a quick yet a comprehensive grasp of RE in traditional and ASD; (2) understand the synergies/commonalities between the two approaches in handling RE; (3) recognise the associated challenges of adopting ASD; and (4) identify the current prominent agile RE research areas.

Agile requirements engineering practices and challenges: an empirical study

AbstractThis paper describes empirical research into agile requirements engineering (RE) practices. Based on an analysis of data collected in 16 US software development organizations, we identify six agile practices. We also identify seven challenges that are created by the use of these practices. We further analyse how this collection of practices helps mitigate some, while exacerbating other risks in RE. We provide a framework for evaluating the impact and appropriateness of agile RE practices by relating them to RE risks. Two risks that are intractable by agile RE practices emerge from the analysis. First, problems with customer inability and a lack of concurrence among customers significantly impact agile development. Second, risks associated with the neglecting non‐functional requirements such as security and scalability are a serious concern. Developers should carefully evaluate the risk factors in their project environment to understand whether the benefits of agile RE practices outweigh the costs imposed by the challenges.

Editorial

Our first paper by Rajiv Sabherwal and Varun Grover (2010) looks at information system development (ISD) politics, that is, political maneuvers that impact on the success or otherwise of the information system. The paper uses 89 ISD projects to develop a taxonomy of political processes which identifies three distinct types (representing three clusters in the data): Tug of War, wherein multiple parties strive to gain control of the project; Obstacle Race, which involves efforts to both resist and pursue the project; and Empire Building, wherein the project is used as an instrument to enhance political or resource bases. As a look at the list of references makes clear, the ISJ has published a series of articles emphasizing the role of power in information systems (see, for example, Silva 2007) and the Journal has a strong history publishing research into non-technical causes of success and failure. Like most papers the process towards acceptance was not short. The original submission was in April 2008, and following reviews, resubmissions took place in November 2008, May 2009, and July 2009 before final acceptance. We hope that our procedures are not seen as an Obstacle Race but a genuine attempt at working with the authors to improve a paper so that it is most useful to readers when published. As usual, we thank our senior editor, associate editor, and referees for playing their part in ensuring this process of improvement. Taking an interpretive multi-case study approach, the paper of Balasubramaniam Ramesh, Lan Cao and Richard Baskerville (2010) looks into agile requirements engineering (RE) practices. Based on an analysis of data collected in sixteen U.S. software development organizations, the authors identify six agile practices and seven challenges that are created by the use of these practices. They also analyze how this collection of practices helps mitigate some, while exacerbating other risks in requirements engineering. The paper provides a framework for evaluating the impact and appropriateness of agile RE practices by relating them to RE risks. Two risks that are intractable by agile RE practices emerge from the analysis. First, problems with customer ability to generate shared understanding and a lack of concurrence among customers significantly impact agile development. Second, risks associated with neglecting non-functional requirements such as security and scalability are a serious concern. Tero Päivärinta, Maung Sein and Tuomo Peltola look at how systems development methods (SDMs) are used in practice. Again, possibly reflecting the research interests of two of the ISJ editors, the Journal has a strong history in publishing qualitative research into information systems development. The authors show how SDMs are adapted and modified to meet project exigencies, which results in unique methods-in-use in each project. In particular the research suggests that SDM modifications happen due to mismatches between the paradigmatic values inherent in the SDM, the method users and the organizational context. This is illustrated through case study research. These three papers are large, each around twice our ‘norm’ of around 6–8000 words. However, we feel that sometimes explanation and detail are warranted, as in these cases. This has necessitated restricting the number of papers to only three in this issue.

Agile Requirements Engineering Practices: An Empirical Study

An analysis of data from 16 software development organizations reveals seven agile RE practices, along with their benefits and challenges. The rapidly changing business environment in which most organizations operate is challenging traditional requirements-engineering (RE) approaches. Software development organizations often must deal with requirements that tend to evolve quickly and become obsolete even before project completion. Rapid changes in competitive threats, stakeholder preferences, development technology, and time-to-market pressures make prespecified requirements inappropriate.