On the Role of Early Architectural Assumptions in Quality Attribute Scenarios: A Qualitative and Quantitative Study

Architectural assumptions are fundamentally different from architectural decisions because they can not be traced directly to requirements, nor to domain, technical or environmental constraints, they represent conditions under which the designed solution is expected to be valid. Early architectural assumptions are similar in nature, with the key difference that they are not made during architectural design but during requirement elicitation, not by the software architect (a solution-oriented stakeholder), but by the requirements engineer (a problem-oriented stakeholder). They represent initial assumptions about the system's architecture, and allow the requirements engineer to be more precise in documenting the requirements of the system. The role of early architectural assumptions in the current practice of quality attribute scenario elicitation and related development activities in the transition to architecture is unknown and under-investigated. In this paper, we present the results of an exploratory study that focuses on the role and nature of these assumptions in the early development stages. We studied a reasonably large set of quality attribute scenarios for a realistic industrial case, a smart metering system. Our study (i) confirms that quality attribute scenario elicitation in practice does rely heavily on early architectural assumptions, and (ii) shows that they do influence the perceived quality of the requirements body as a whole, in some cases positively, in other cases negatively. These findings provide empirical arguments in favor of making such assumptions explicit already during the requirements elicitation activities. Especially in the context of iterative software development methodologies such as the Twin Peaks model, a well-defined and -documented set of assumptions could smoothen the transition between successive development iterations.