On the Impact of Evolving Requirements-Architecture Dependencies: An Exploratory Study

Abstract

Architecture design plays a significant role in the evolution of software systems, as it provides the prime realization of the driving requirements and their inter-dependencies. With the increasing volatility of software requirements nowadays, it is necessary to understand the correlation between evolving classical requirements dependencies and their impact on the architectural decomposition. In the context of this analysis, two questions arise: (i) what are the conventional categories of requirements dependencies that are more architecturally significant in terms of change impact? and (ii) to what extent those evolving dependencies tend to generate ripple effects through architectural modules and interfaces. In order to address these two questions, this paper first presents an analysis model that categorizes requirements dependencies. Second, we have performed an exploratory study, based on the change history analysis of a real-life Web-based information system, in order to gather the most architecturally-significant requirements dependencies from our model. We have systematically analyzed ten system releases, based on some qualitative and quantitative indicators, with respect to how the requirementsarchitecture dependencies and compositions evolved.

Uncovering quality-attribute concerns in use case specifications via early aspect mining

“…To evaluate the advice of the QAMiner approach regarding quality attributes, we applied the tool in two case studies. The first case-study is called the HWS [18,24], and the second one is a public IBM case-study called course registration system (CRS) [7]. In the experiments, we were interested in the predictive output of the tool, that is, its ability to recover relevant (candidate) quality attributes from a use case specifications, given a set of early aspects and quality attributes identified beforehand.…”

“…This judgment was performed based on the descriptors (i.e., verb-object pairs) and intent of each early aspect. At last, the rightmost column contains the system quality attributes, that is, the actual quality attributes as interpreted from the case-study documentation [18,24,42]. The lines between identified and actual quality attributes highlight the correspondences between them.…”

“…The system in this diagram is an excerpt from the health watcher system (HWS) [18]. A Persistence aspect crosscuts several use cases dealing with data storage/retrieval, so that this functionality should be segregated to a single artifact [24].…”

“…The question to answer here was whether the candidate quality attributes have correspondences with the quality attributes considered in solutions to the case studies. In practice, several authors have proposed architectures for the HWS problem [24,42], so we directly took the quality attributes stated and addressed by those architectures. For the CRS case-study, unfortunately, there is no published architectures, and we had to infer the relevant quality attributes from the problem context.…”

A case study on co-evolution of software artifacts using integrated views

“…The approach is quantitative answering the question how much effort is needed in order to realize a given evolution scenario. Khan et al [4] also provided a case study on evolution of an architecture based on the type of dependency between requirements and architecture. The different types are: Goal and infrastructure, Task, Service, Temporal and Conditional.…”