What are Architecturally Significant Requirements?

Recently, I posted a video about the five "easy" steps to architecting software. Of course, it isn't so easy. A big portion of an architect's job is to identify and articulate concise and testable architecturally significant requirements. This video attempts to demystify these kinds of requirements.

What is an ASR?
So… what is an Architecturally Significant Requirement (or ASR)? Sounds Fancy, but, not so much. Put simply, an ASR is any requirement that can have a profound effect on your system’s architecture. Any requirement.

OK, but how is that different from what we already refer to as quality attributes, non-functional requirements, “ilities”, constraints, technical requirements, etc., etc. “Why are you making me learn a new word?” Well… it’s subtle. Let’s break it down.

ASRs are a sort of superset or umbrella of any kind of requirement that has an effect on the shape of your system. They’re requirements that point us towards HOW we want to build the thing. Without ASRs, we could develop software any number of ways! Without ASRs, there would be no wrong way to write code. There would be no tradeoffs or consequences!

Alright, so let’s dig into the kinds of requirements that make up an ASR.

Functional Requirements
First, let’s start with Functional Requirements. These are the requirements that tell us what we want the system to do. Typically, these requirements include the who, the what, and the why. That’s who we’re building this thing for (the persona). What it is we’re building (the system’s behavior). And why we’re building it (the expected outcome for when we build the thing). Let’s try it out:

As a student, I want to be able to order textbooks, so that I may do my class assignments.

As a patient, I want to see the results of my lab work, so that I may discuss possible treatments with my physician.

As a software developer, I want to compile my code, so that I may run my program.

You might not always get requirements that are so cut and dry. You’re going to have to collaborate with the requirements engineer, or your stakeholders, to flesh 'em out.

For the most part, Functional Requirements don't dictate the architecture. But, an architect’s got to make a decision about which part of the system is responsible for that new functionality. If you’ve got a monolith, no big deal. Just plop it into the big box. (We’ll deal with maintaining that beast later!) If you’ve already got a modular or distributed system, you’ll have to figure out which part of the system you’re going to crack open and change.

Beyond that, an architect needs to take a close look at each Functional Requirements and think about how it’s going to affect the other qualities of the system. For example: You want to add functionality that pulls in data from Texas to Turkey. That’s definitely going to impact your system's performance!

Quality Attribute Requirements
And that leads me the second kind of requirement that makes up an ASR: Quality Attribute Requirements. (We sometimes call these Non-Functional Requirements.) These are the requirements that qualify the functional requirements or the overall system. In other words, if a functional requirement describes what the system is supposed to do, the quality attribute requirement describes the way in which the system is supposed to do it. It’s the desired property, or quality, of the system. Let me give you an example:

As a student, I want to be able to order textbooks reliably, so that I can be sure to get my books on time – before class starts.

As a patient, I want to see the results of my lab work securely, so other patients can’t see my test results – I want to keep that information private!

As a software developer, I want to compile my code quickly, so that I can execute my unit tests seamlessly – test driven development, baby!

Now, this is where it gets interesting: There’s two kinds of quality attributes. First, there’s the kind, like I was just talking about – those that describe how the system behaves while it’s running. But, then there’s the kind that describe how we are able to actually develop the system. That’s right! In this case, the “who” can be developers, system administrators, or the folks in operations. Here we go:

As a developer, I want to be able to make changes to the software easily, so that I can keep the costs of adding new functionality down to a minimum.

As a system administrator, I’d like to be able to configure the deployed system efficiently, so that I can keep downtime to a minimum, when I upgrade the system.

As someone monitoring the system at runtime, I’d like to receive notifications, when the system goes down, instantly, so I can fix the problem as quickly as possible.

Now, the examples I just gave aren’t so good. Why is that? Quality Attribute Requirements have got to be crystal clear… and testable. I’m going to say that again for the folks in the back: Quality Attribute Requirements have got to be crystal clear… and testable!