Why to Distinguish Architecturally Significant Requirements

Requirements are decisions that are made about “what does the system do”. Architecturally Significant Requirements (ASRs) are those requirements that “have a measurable impact on the software system’s architecture [1]”. In this sense, requirements are considered from a solution perspective. As a matter of fact, nowadays requirement decision-making is better not to be separated from the solution space.  Here why I think we should distinguish ASRs will be explained from the following two aspects:

Why the traditional and popular distinction of functional requirements and non-functional requirements is not good enough. To address this aspect, at least two points can contribute to that.

Firstly, capturing requirements in terms of functional requirements and non-functional requirement is not enough for architecting. To make architectural decisions, one needs to consider functional requirements and non-functional requirements more or less simultaneously. However, the current practice often separates them in the requirements specification and very often emphasizes functional requirements at the cost of non-functional requirements. Moreover, most of what is in a requirements specification do not impact the architecture while the critical requirements get ignored. Consequently, the resulting specification presents neither adequate information nor good structure to ease architects’ efforts for design.

Secondly, the categorization as functional requirements and non-functional requirements can cause confusions. To begin with, a requirement can belong to both types – interchangeable. For example, “The system shall encrypt all communication data going through the Internet” – this requirement addresses both security concerns and also functionality. Furthermore, both types of requirements can be interleaved. For example, a usability requirement stating that “the system shall provide help within 3 seconds if a user asks for help in a particular context” may very likely raise a functional requirement as “the system shall provide a link to the help subsystem in every user interface”. Last but not the least, both types of requirements share the same set of anchors of influences. Those anchors include conceptual components, layers, the whole or sub system, or technically a concrete class, a method or a set of methods within the same class or across different classes. Those characteristics between functional and non-functional requirements do not provide architects a straight-forward and clear view of requirements that matter for architecting.

What benefits we can get when distinguishing ASRs. So far, I think there are at least two benefits.

Firstly, distinguishing ASRs facilitates the utilization of the relationship between ASRs and Architectural Design Decisions (ADDs) so that advances the co-development of requirements and architecture. Let me explain this here. The changing context today enlarges the overlapping between the problem space and the solution space and hence necessitates better model for software requirements and architecture co-development (For details, please click ).  To better the co-development, the relationship between ASRs and ADDs merits investigation. ADDs are design decisions that determine the architecture of the to-be system(s). Imposed by the changing context, inherited design decisions from earlier versions or legacy systems now become constraints (usually as ASRs) for new projects today. What’s more, a well elaborated requirement often contains design details (i.e. ASRs can be transformed into ADDs easily and smoothly). If a concrete relationship between ASRs and ADDs can be built, then requirements practice and architectural design can be potentially largely improved.

Secondly, distinguishing ASRs is to alert BAs / requirements engineers of this concept and consciously write requirements especially those ASRs in a way that makes requirements better match with what architects really need for architecting. No matter the requirements are functional or non-functional, or ASRs or non-ASRs, they are meant to be implemented. But at least thinking in terms of ASRs and non-ASRs makes the gap between requirements and architecture closer. Besides, there has to be guidance on how to identify ASRs for BAs / requirements engineers – it’s another story.

The concept of architecturally significant requirements has been mentioned for more than ten years. Even though not many researches have been done in this area up to date, not to mention industrial practices, today we enter into a new context that may force us to pay attention to it more than ever. And I hope I could contribute to that a little bit.