A reflection on agile requirements engineering

Abstract

The software development industry has rapidly accepted agile methods. Empirical studies suggest that due to their flexible and emergent nature, agile methods brought solutions to several chronic problems of traditional software development methods. One among the many is the acceptance of requirements changes at later stages of development. However, knowledge about the solutions that agile brought to requirements engineering (RE) is fragmented. Also, little is known about whether the agile philosophy, while introducing solutions to well-known RE problems from the past, has unintentionally opened new challenges. This paper offers a reflection on this matter. Based on the results of our recently published systematic review on agile RE, we reflect on the differences of 'traditional' and agile RE and the practices adopted by the latter, on the solutions and challenges of agile RE, and on some implications that agile RE might have posed for research and practice.

Agile Quality Requirements Engineering Challenges: First Results from a Case Study

“…Previous studies have reported the engineering of QRs in Agile as a challenge [3][4] [5][8] [9]. Other studies indicated the lack of empirical studies regarding Agile QRs [5][6].…”

“…Our recent SLR [6] on engineering QRs indicated the lack of empirical research specifically devoted to the challenges that Agile practitioners face when dealing with QRs as a whole in ALSD [6]. However, there are studies reporting Agile RE challenges [5][8][9] [3], which we summarize as follows: The SLR of Inayat et al [5] focused on the differences between traditional and Agile RE and the challenges of Agile RE. These authors identified seven challenges brought by Agile, one of…”

“…While the traditional approach aims to fully identify the requirements up-front by following sequential practices [1], requirements in ADMs are collected just in time (JIT) based on face-to-face communication sessions with the business representative [2] who communicates the elicited requirements towards the Agile teams. The Agile practices used to engineer the requirements are criticized for focusing only on functional requirements (FRs) and neglecting quality requirements (QRs) [3][4] [5]. Neglect of QRs may result in systems that do not meet the user expectations.…”

Quintessence of Traditional and Agile Requirement Engineering

“…The traditional RE is facing many a challenges such as communication gaps, over scoping, requirement prioritization, validation and customer involvement [45]. These issues are resolved by Agile practices such as face to face communication for minimizing documentation and communication gaps, gradual detailing of requirements for reducing over scoping, requirement prioritization by customer based on the worth of business to deal with requirements validation and close interaction on the part of team and customer in order to avoid lack of customer participation [46]. Issues caused by the traditional RE and the solutions provided by the Agile RE are described in Table 2.…”

Integrating design thinking into extreme programming

“…User stories generation is an ongoing process in the XP iterative approach. Therefore, involving the customer in user story creation and gathering also ease the chances of incoming change requests (Inayat et al 2015). To make a realistic customer expectation from the output of each iteration, we recommend including 'empathy' and 'define' practices of DT along with user 'persona' to create a DT-user story.…”