Characterizing architecturally significant requirements

At the heart of any engineering discipline is the interplay between problem and solution development. In software engineering, the effectiveness of a software solution is determined with respect to a problem, yet the nature of the problem and its scope may be very dependent on what solutions already exist or what solutions are plausible and cost-effective. This iterative and concurrent development and trade off between software problems and solution characterise the ‘twin peaks’ model of software development [1]. For the development of many large scale software intensive systems, the software architecture is a fundamental part of a software solution [2]. It has a significant impact on software quality and cost. However, not all of a system’s requirements have equal impact on the software architecture [3]. In many cases, only some requirements actually determine and shape a software architecture [4], and we term these Architecturally Significant Requirements (ASRs). If ASRs are wrong, incomplete, inaccurate, or lack details, then a software architecture based on these is also likely to contain errors. Unfortunately, in practice, ASRs are frequently not expressed nor communicated effectively to architects, to enable them to make informed design decisions [4]. This is partly due to a lack of an authoritative, evidence-based discourse characterising ASRs. To address this, we carried out an empirical study using Grounded Theory [5] to help characterize ASRs. The study involved interviews with 90 practitioners who together have more than 1448 years of accumulated software development experience in more than 500 organizations. Based on the study's results, this article presents an evidence-based framework for systematically characterizing ASRs. Our findings may help practitioners better understand and deal with ASRs. Our findings also provide researchers with a framework for discussing, and conducting further research on ASRs, and can inform researchers' development of technologies for dealing with ASRs. Finally, our findings also enrich our understanding of requirements and architecture interactions, allowing the 'twin peaks' to move from aspiration to reality