Requirements Engineering Artifacts in Agile Development

In Agile software development (ASD) projects requirements are incrementally and iteratively defined, with customer needs frequently expressed in User Stories (USs). However, minimal documentation has been identified as a key challenge for Requirements Engineering (RE) in ASD. Including too little information makes tracing and estimating USs more difficult, while including too many details limit the developer in their solution. In addition, development teams mainly rely on information contained in issue tracking systems, rather than speaking with their customer on a regular basis. To summarize, development teams are highly dependent on few artifacts. This PhD dissertation studies how development teams create and use RE artifacts such as requirements and acceptance criteria, guided by the following main research question: How are Requirements Engineering artifacts used in Agile Software Development? First, we introduce the RE4SA model as a means to support communication between requirements engineers and software architects, recognizing that requirements and architectural components should be designed in tandem. In practice, however, this alignment is difficult to achieve, often due to a lack of concrete guidance in existing models. The RE4SA model addresses this by expressing requirements as epic stories and USs, which are linked to architectural modules and features, respectively. The model is further instantiated as RE4SA-Agile, which connects common agile artifacts and introduces metrics to measure the alignment and granularity between requirements and architecture. These metrics help identify problematic situations, such as when the granularity of requirements or architectural components is inconsistent with the norm. Then, we focus on the definition of key concepts in the field of RE. Concepts, such as those in the RE4SA model, are often interpreted in different ways. To clarify fundamental concepts in software engineering, we propose the Concept Definition Review (CDR) method. The CDR method was formalized in a second iteration, in which we defined and compared the terms “non-functional requirement” and “quality requirement”, which revealed the existence of dozens of definitions, many nearly identical, and highlighting the importance of systematic conceptual analysis for effective communication. We also explored the impact of RE artifacts on efficiency of agile teams, focusing on the use of USs and acceptance criteria by teams. Our empirical studies show that while the quality of USs does not directly correlate with timely completion, the existence of acceptance criteria does improve efficiency; we found evidence for an increase in on-time completion and reduced completion time. Our Canonical Action Research study shows that interventions based on the Quality User Story (QUS) framework can improve the quality of USs, but practitioners sometimes find value in deviating from strict guidelines. This suggests that while guidelines are useful, they must be adaptable to the context and practitioner needs. Finally, the challenge of specifying non-functional requirements (NFRs) is addressed; practitioners expressed a need for support in defining NFRs. Unlike functional requirements, NFRs lack a widely adopted writing format and are notoriously difficult to quantify. A new NFR template is developed and validated, based on requirements from practitioners, incorporating fit criteria to make NFRs more measurable.