Alignment and granularity of requirements and architecture in agile development: A functional perspective

TLDR: In this article, the authors propose the Requirements Engineering for Software Architecture (RE4SA) model to assist in analyzing the alignment and the granularity of functional requirements and architectural components.

Abstract: Context: Requirements engineering and software architecture are tightly linked disciplines The Twin Peaks model suggests that requirements and architectural components should stay aligned while the system is designed and as the level of detail increases Unfortunately, this is hardly the case in practical settings Objective: We surmise that a reason for the absence of conjoint evolution is that existing models, such as the Twin Peaks, do not provide concrete guidance for practitioners We propose the Requirements Engineering for Software Architecture (RE4SA) model to assist in analyzing the alignment and the granularity of functional requirements and architectural components Methods: After detailing the RE4SA model in notation-independent terms, we propose a concrete instance, called RE4SA-Agile, that connects common artifacts in agile development, such as user stories and features We introduce metrics that measure the alignment between the requirements and architecture, and we define granularity smells to pinpoint situation in which the granularity of one high-level requirement or high-level component is not uniform with the norm We show two applications of RE4SA-Agile, including the use of the metrics, to real-world case studies Results: Our applications of RE4SA-Agile, which were discussed with representatives from the development teams, prove to be able to pinpoint problematic situations regarding the relationship between functional requirements and architecture Conclusion: RE4SA and its metrics can be seen as a first attempt to provide a concrete approach for supporting the application of the Twin Peaks model We expect future research to apply our metrics to additional cases and to provide variants for RE4SA that support different concrete notations, and extend the perspective beyond the functional perspective of this research, similar to what we did with RE4SA-Agile in this paper