A Systematic Mapping Study on Security in Agile Requirements Engineering

[Background] The rapidly changing business environments in which many companies operate is challenging traditional Requirements Engineering (RE) approaches. This gave rise to agile approaches for RE. Security, at the same time, is an essential non-functional requirement that still tends to be difficult to address in agile development contexts. Given the fuzzy notion of “agile” in context of RE and the difficulties of appropriately handling security requirements, the overall understanding of how to handle security requirements in agile RE is still vague. [Objective] Our goal is to characterize the publication landscape of approaches that handle security requirements in agile software projects. [Method] We conducted a systematic mapping to outline relevant work and contemporary gaps for future research. [Results] In total, we identified 21 studies that met our inclusion criteria, dated from 2005 to 2017. We found that the approaches typically involve modifying agile methods, introducing new artifacts (e.g., extending the concept of user story to abuser story), or introducing guidelines to handle security issues. We also identified limitations of using these approaches related to environment, people, effort and resources. [Conclusion] Our analysis suggests that more effort needs to be invested into empirically evaluating the existing approaches and that there is an avenue for future research in the direction of mitigating the identified limitations.

💡 Research Summary

The paper presents a systematic mapping study that investigates how security requirements (SR) are handled within agile requirements engineering (RE) practices. Recognizing that rapidly changing business environments have pushed organizations away from traditional, documentation‑heavy RE toward agile methods, the authors note that security—a critical non‑functional requirement—remains difficult to integrate into agile development cycles. To clarify the state of research, they performed a systematic mapping of primary studies published between 2005 and 2017, ultimately selecting 21 papers that met their inclusion criteria.

The authors first review related secondary studies on agile RE and on security requirements, highlighting that none of these prior works combine the two topics. They then formulate six research questions (RQs) to structure their analysis: (1) which agile methods have been used for SR handling; (2) which RE phases are addressed; (3) how SR are treated in each approach; (4) the research type of each study; (5) the kind of empirical evaluation performed; and (6) the limitations reported for each approach.

Search strategy: a hybrid approach was adopted. The authors built a Boolean search string—“(Agility OR Agile OR Scrum OR Extreme Programming) AND (Security AND Requirements)”—and applied it to Scopus (titles, abstracts, keywords) in October 2017. To capture studies not indexed in Scopus, they performed backward and forward snowballing using Google Scholar. Inclusion criteria required that a paper explicitly describe a method for handling SR in an agile context; exclusion criteria eliminated non‑English papers, gray literature, and works lacking any SR discussion.

Findings: Scrum dominates the landscape, being the agile method most frequently associated with SR approaches; XP and Kanban appear only sporadically. The identified approaches fall into three broad categories: (a) Process modification – inserting security‑focused sprints, checklists, or “security spikes” into existing agile workflows; (b) Artifact extension – introducing new work items such as “abuser stories,” “threat stories,” or dedicated vulnerability analysis artifacts that embed security concerns directly into the backlog; and (c) Guideline provision – offering sets of security best‑practice guidelines, threat modeling procedures, or policy documents to be consulted during agile ceremonies.

Regarding RE phases, most contributions target the specification and verification stages, especially the elicitation of security concerns early (through abuser stories) and the validation of security controls during sprint reviews. Fewer studies address requirements tracing, maintenance, or post‑deployment monitoring.

Research type classification (based on Wieringa et al.) shows that 12 of the 21 papers (≈57 %) are solution proposals, while the remainder comprise evaluation research, experience reports, philosophical discussions, or opinion pieces. Empirical evaluation is limited: only about a third of the studies report any form of validation, and those that do rely on small case studies, prototype implementations, or controlled experiments. No large‑scale industrial longitudinal studies were identified.

Limitations reported across the primary studies cluster around four themes: (1) Environmental constraints – organizational culture, regulatory context, and project size affect the feasibility of adding security activities; (2) People factors – lack of security expertise within agile teams and resistance to “heavy” security processes; (3) Effort and resources – additional time and effort required for threat modeling or security testing can clash with the agile emphasis on rapid delivery; and (4) Methodological tensions – the agile principle of “working software over comprehensive documentation” conflicts with the need for detailed security specifications and evidence.

The authors conclude that while a variety of creative solutions exist—particularly the introduction of new artifacts that make security visible to developers—the field suffers from a paucity of rigorous, empirical validation. They call for future work that (i) conducts extensive industrial case studies to assess scalability and effectiveness, (ii) integrates automated security tooling (e.g., static analysis, continuous security testing) into agile pipelines, and (iii) develops standardized validation techniques for security requirements that align with agile’s iterative cadence. By addressing these gaps, the community can move toward robust, evidence‑based practices for embedding security into agile RE.