Agile requirements engineering practices and challenges: an empirical study

Abstract

This 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.

Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation

“…In large-scale projects the alignment challenge is considerable because different stakeholder groups have been found to have different priorities (Barney and Wohlin 2009). Further, a fragmented view of the system that each customer representative may have is likely to impact the project negatively (Ramesh et al 2010), and the dependence on the on-site customer may cause project failure if the on-site customer is misaligned with the stakeholder goals (Vinekar et al 2006). While each project in a large-scale effort may have success at the project level, there could still be overall failure at the program level if the projects are not aligned.…”

“…Having multiple on-site customers in a large-scale project increases the risk of failure because of the challenge of establishing a common understanding among all customer representatives. A fragmented view of the system that each customer may have is likely to have a negative impact on the project (Ramesh et al 2010). Further, when different stakeholder groups have different priorities, there is a need for open and transparent dialogue and cross stakeholder group communication in large-scale agile projects (Barney and Wohlin 2009).…”

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

“…This is further complicated by requirements documentation rarely being updated (Lethbridge 2003), leading to potentially outdated acceptance tests. In agile development, automated acceptance tests drive the implementation and address these issues by documenting requirements and expected outcomes in an executable format (Ramesh 2010, Haugset 2008). This agile practice is known, among others, as customer tests, scenario tests, executable/automated acceptance tests, behaviour-driven and story-test-driven development (Park 2010).…”

“…Face-to-face communication is prioritised over written requirements documentation and customers are expected to convey their needs directly to the developers (Beck 2001, Ramesh 2010). However, weak customer communication in combination with minimal documentation is reported to cause problems in customer participation and with scaling and evolving software for agile projects (Ramesh 2010).…”

“…Face-to-face communication is prioritised over written requirements documentation and customers are expected to convey their needs directly to the developers (Beck 2001, Ramesh 2010). However, weak customer communication in combination with minimal documentation is reported to cause problems in customer participation and with scaling and evolving software for agile projects (Ramesh 2010). Requirements specifications are used for different purposes and support the main requirements activities of eliciting and validating stakeholders" requirements, software verification, tracing and managing requirements, and for contractual purposes by documenting customer agreements.…”