Chapter 19: Architecturally Significant Requirements (ASRs)

Welcome to Last Minute Lecture.

This free chapter overview is designed to help students review and understand key concepts.

These summaries supplement not replaced the original textbook and may not be redistributed or resold.

For complete coverage, always consult the official text.

Welcome back to the Deep Dive.

Today we're tackling what feels like the true starting point for any successful software project.

You know, Bjarne Stroustrup famously said, the most important single aspect of software development is to be clear about what you were trying to build.

Yeah, and that clarity.

That's exactly what we're digging into today.

We're focusing on identifying architecturally significant requirements or ASRs for short.

These aren't just any requirements.

They're the ones that fundamentally shape the system.

Get them wrong and well, the project's probably in trouble no matter how good the code is.

Okay, so ASRs.

Let's nail down the basics.

What makes a requirement architecturally significant compared to, say, just a regular user story?

They all affect the final system, right?

They do, yeah, but it's about the level of impact.

And ASR is a requirement that has a profound effect on the architecture.

Meaning, if you suddenly remove that ASR, your whole design approach would have to change, maybe dramatically.

And often, though not always, these ASRs show up as quality attribute requirements.

Things like performance, security, modifiability, availability, you know,

the influences the architecture somehow.

Where's the line?

What makes it profound?

That's a fair question.

Think of it in terms of necessity and risk.

A standard functional requirement usually dictates what the system does, like a user needs to submit this form.

An ASR, though, often dictates how the system has to be built to support that function reliably or under certain conditions.

For example, the system must handle 10 ,000 users submitting that form at the same time with less than one second response time.

See, that how forces you into major structural decisions, maybe redundancy, different database strategies, specific communication patterns.

Those choices are the architecture.

Got it.

So the architect's job isn't just designing, it's uncovering these critical hows early on.

And they probably can't just wait for a perfect requirements document to land on their desk.

They need to talk to people, the stakeholders.

Exactly.

Which brings us neatly to our first point.

The problem with relying solely on formal requirements documents.

Hashtags tags tag one.

The flaw in formal requirements documents.

19 .1.

It's a bit ironic, isn't it?

The most obvious place to look, the requirements spec, the user stories, is often the least helpful for finding ASRs.

Architects usually have to start designing while requirements are still shifting, and these documents tend to fail them in, well, two main ways.

Okay, let's break down those failures.

The first one, you mentioned it's common, is that most of the document is just about features, the functionality.

Right, and functionality, surprisingly, often shapes the architecture the least.

It tells you what the system needs to do, sure.

But it's the quality attributes, making sure that function is fast or secure or easy to change later.

That's what forces the big structural decisions, how you break down the components.

Features are like the skin, but the QAs are the skeleton holding it up.

Okay, so that's failure one.

What's the second?

Is it attributes do get mentioned?

Precisely.

They get mentioned, but often in these really vague, unhelpful ways, like you'll see things written down such as the system needs to be modular, or it should have high usability.

Right, those sound good, but what do they actually mean in practice?

You can't really test high usability easily.

Exactly.

They're not testable, not falsifiable.

The source material actually has a good take on this.

Don't just ignore them, treat them as invitations for conversation.

It signals that someone cares about modularity or usability, but the architect's job is then to go talk to that stakeholder and pin down what that really means in a measurable way.

What's the actual ASR behind the wish?

So the architect needs to be a bit of a detective then, actively sniffing out these ASRs, even if they're hidden within functional descriptions or vague statements.

What kind of clue should they be looking for in those documents?

Are there specific categories?

Definitely.

They need to scan for specifics that at structural needs or constraints.

The first couple of categories are things like usage details about who the users are, different roles, maybe internationalization needs,

and time, anything about response times, deadlines, coordination between steps, sequencing.

Okay, usage and time.

What else?

Looking outward, maybe?

Yeah, exactly.

Look for mentions of external elements, specific hardware it needs to talk to, external API sensors, protocols, and obviously networking details, how components communicate, bandwidth constraints, that sort of thing.

And internally, inside the system itself.

Right, you're looking for orchestration details, complex processing steps or workflows,

specific security properties, encryption standards, access control rules, also data requirements, how persistent does data need to be, how up -to -date accuracy levels.

And finally, resources, anything about concurrency limits, scalability needs, memory footprint constraints, it's about connecting those functional dots to the implied system load.

And it's not just about how things are now.

Right.

The source mentions evolution.

Absolutely crucial point.

If there are known plans or even just anticipated changes, like the database is expected to grow tenfold or a new processing timeline will be added next year that anticipated future state is also architecturally significant, you might need to build in flexibility for it today.

Hashtag tag two.

Eliciting ASRs by engaging stakeholders,

19 .2.

Okay, so documents are often flawed.

That leads us naturally to talking directly with stakeholders.

Yeah.

But what happens when you ask that stakeholders say, how available does this system need to be?

And they just shrug, I don't know, just make it available.

Yes, the classic I don't know response.

That's actually a really important moment for collaboration.

Often, stakeholders genuinely don't know the requirement, especially for quality attributes, because they don't understand the cost or the trade -offs involved.

So the architect needs to educate them, provide options.

Exactly.

The architect can provide that critical feedback.

They can say something like, okay, we can aim for 247, never down availability.

But that means we need three redundant data centers, which adds X million to the budget and Y months to the schedule.

Or they might continue.

We could aim for 99 .9 % availability, which allows for maybe a few hours of planned maintenance per year.

And that costs significantly less.

That forces the stakeholder to weigh the benefit of extreme availability against the cost and make an informed decision.

It becomes a negotiation.

That makes sense to help structure that negotiation and get everyone on the same page.

The source talks about a specific technique, the quality attribute workshop or QAW.

Yes, the QAW is a really valuable tool.

It's basically a facilitated meeting, very structured, involving key stakeholders.

The whole goal is to generate, prioritize and refine those crucial quality attribute scenarios before the architecture gets set in stone.

It's about building consensus early.

Can you walk us through the steps?

How does a QAW generally unfold?

Sure.

It typically follows a sequence.

First, someone presents the business or mission context.

Why are we building the system?

What are the overall goals and constraints?

Then the architect presents the current architectural plan, just the initial thinking, the high level ideas.

Next, the group works together to identify the architectural drivers.

This is about reaching a consensus on which quality attributes matter most for this system.

Performance, security,

modifiability.

Okay.

Context, plan, drivers.

Then what do they start writing requirements?

Sort of.

The next step is scenario brainstorming.

This is where each stakeholder gets to voice concerns or goals in the form of a scenario, like what happens if a hacker tries this or users need to be able to do that within X seconds.

After brainstorming, you usually have a lot of scenarios, so the next step is scenario consolidation, grouping similar ones.

Then comes scenario prioritization.

This is key.

Stakeholders usually get a limited number of votes to allocate to the scenarios they feel are most critical.

This forces focus on what truly matters most to the business.

Votes make sense.

And the final step, refining the top ones.

Exactly.

The highest priority scenarios go through scenario refinement.

This is where they get fleshed out into that very specific six -part format.

You need the source of the stimulus, the stimulus itself, the artifact, the part of the system affected, the environment, the conditions, the response needed, and the response measure, how you quantify success.

Why such rigor?

Source, stimulus, artifact, environment, response, response measure.

This is a lot of detail.

It's all about making the requirement unambiguous and crucially testable.

It takes you from a vague wish like the system needs to be secure to something concrete.

An external attacker, source, attempts a denial of service attack with 10 ,000 requests per second stimulus targeting the login service artifact during normal operation environment.

The system must detect and throttle the attack response within five seconds, maintaining service for legitimate users.

Response measure.

See?

No wiggle room.

That clarity is powerful.

I also like the anecdote in the book about getting a number when the stakeholder says, I don't know, the play dumb tactic.

Huh.

Yes, that's a great practical tip.

When they genuinely don't know, say, the required response time, the architects can push the boundaries.

You ask something deliberately slow, like, so would 30 seconds be okay for that search result?

The stakeholder will likely recoil.

No way.

That's far too slow.

Then you work backwards.

Okay.

How about 10 seconds?

Five seconds.

Eventually they'll land on a range they can live with.

Even getting a range, like knowing whether you need sub second or maybe five, 10 seconds is okay.

Makes a huge difference in architectural choices.

It gives you a starting point.

Hashtag tag tag tag three, connecting ASRs to business goals.

19 .3.

Okay.

So we've covered documents, flawed, and stakeholders essential, but need guidance.

The source also highlights another major driver for ASRs.

The organization's business goals.

The fundamental reason the system exists.

Absolutely.

Business goals are often the ultimate source of ASRs.

The chapter outlines sort of three ways this connection works.

The first one is pretty straightforward.

A business goal can directly lead to a quality attribute requirement.

For instance, if a business goal is to differentiate a product by being the fastest on the market, that directly translates into a demanding performance ASR.

Right.

That makes sense.

And the third way is also simple.

Some goals just don't impact architecture, right?

Like deciding to save energy costs by turning down the thermostat.

Exactly.

Non -architectural solutions for business goals.

But it's the second relationship that's fascinating and maybe a bit counterintuitive for purely technical folks.

Business goals can directly shape the architecture without necessarily creating a specific quality attribute requirement.

This is where organizational politics or business realities come into play.

Ah, you're talking about that key example from the book, The Architect, who designed a system perfectly well without a database, but then was forced to add one.

That's the one.

It's such a great illustration.

Technically, functionally, the system didn't need a traditional database, but the manager insisted because the company had a whole team of expensive database administrators who were currently idle.

They needed work assigned to them.

So the business goal wasn't performance or data integrity.

It was resource utilization, keeping the database team busy.

That organizational need directly forced a major architectural change, adding a database component purely for non -technical business reasons.

Wow.

That's a powerful reminder that architects need to understand the business context, the organizational structure, not just the technical problem.

You'd never find that requirement in a spec sheet.

So how do you systematically capture these broader business drivers?

The source mentioned something called Palem.

Right.

Palem process for architecting systems using lenses methods.

It's a more structured approach specifically designed to elicit and capture these business goals, often framing them as business goal scenarios.

It helps guide conversations with leadership by using specific categories to brainstorm goals, things like growth and continuity, or meeting financial targets, managing market position, responding to environmental changes.

The idea is to ensure you're considering the full business picture, not just the immediate technical needs when thinking about what drives the architecture.

Hashtag tag tag three, capturing ASRs in a utility tree, 19 .4.

Okay.

So we have documents, stakeholders, and business goals.

But what if you're in a situation maybe early on where you just don't have good access to stakeholders or the documents are truly useless?

The architect still needs to make progress.

That's a very real scenario.

And that's where the architect needs a way to structure their own best judgment.

This is where the utility tree comes in.

Think of it as the architect's strategic safety net.

It's a top -down model where the architect lays out what they believe are the most critical quality attribute -related ASRs for the system's success.

It's basically prioritizing based on experience and risk assessment.

So is the architect's professional hypothesis visualized?

Can you describe the structure?

How does this tree look?

Sure.

It starts at the top.

The root node is simply labeled utility, representing the overall goodness or value of the system.

Branching down from that, the next level lists the major quality attributes the architect thinks are important.

You know, performance, modifiability, security, usability, et cetera.

Then each of those QAs can be refined further down the tree.

So performance might split into subnodes like latency and throughput.

Modifiability might break down into ease of adding features or ease of changing components.

At the very bottom, the leaves of the tree.

Those are the specific ASRs, ideally expressed as concrete, measurable scenarios.

These might be scenarios gathered from early discussions, maybe adapted from the QAW format, or even just scenarios the architect invents based on potential risks they foresee.

Okay, so you build this tree representing your best guess of what matters.

What's the next step, just looking at it?

No, the critical part is scoring the scenarios at the leaves.

Each scenario gets evaluated against two simple criteria, usually using a high, medium, low scale.

Criterion one is business value.

How important is meeting this scenario for the overall success of the project?

High means it's a must have.

Low means it's nice, but maybe not worth huge effort.

Criterion two is technical risk.

How difficult or uncertain is it to actually achieve this scenario?

High means it's keeping the architect up at night.

Low means they're pretty confident they know how to handle it.

HML for business value.

HML for technical risk.

Could you give an example?

Yeah, let's take one from the book's healthcare example.

A scenario like,

under peak load, a transaction completes in less than 0 .75 seconds.

That might be scored.

H.

H.

High business value, critical for user satisfaction, and high technical risk.

Achieving that speed under load might be really hard.

That H.

H.

flags it for immediate top priority attention.

Okay, and maybe another one.

Sure.

How about an availability scenario?

The database can be hot swapped for maintenance with zero user visible downtime.

That could be scored.

H.

L.

High business value, no downtime is great, but low technical risk if the team has a well understood, reliable mechanism for doing hot swaps.

It's important, but not scary from a technical perspective.

So this scoring instantly tells the architect where the real challenges and priorities lie.

Focus on the H.

H.

first.

Exactly.

And if you build this tree and find you have a whole cluster of scenarios scoring, well, that's a major red flag.

It might indicate the project, as currently envisioned, is extremely risky, or maybe even unachievable with the available resources or time.

It forces a reality check.

Hashtag, tag, tag five, the constant of change, 19 .5.

So we've gone through finding ASRs from documents, stakeholders, business goals, even the architect's own utility tree.

You prioritize them, you start designing,

and then everything's locked in, right?

Smooth sailing.

Oh, if only.

The final point the chapter makes, and it's a crucial one, is acknowledging the reality of change.

Requirements are almost never frozen.

There's that great quote, something like walking on water and developing software from a specification are easy if both are frozen, which of course they rarely are.

So true.

Requirements evolve, business needs shift, new constraints appear.

Absolutely.

Which means architects can't just gather requirements once and be done.

They need to be fantastic bi -directional communicators, constantly listening for changes, but also constantly feeding back the cost and impact of potential changes to stakeholders.

That communication channel has to stay wide open.

It's an ongoing dialogue, not a one -time task.

And ideally, it's even proactive.

If an architect anticipates a likely future change, maybe a new regulation is on the horizon or the business is hinting at expanding into a new area, it's often wise to do some preliminary design exploration for that change now.

Even just sketching out how you would accommodate it helps understand the implications.

Then you can share that cost and feasibility information with stakeholders before they formally ask for it.

It helps manage expectations and plan better.

Hashtag, tag, tag, atch for nitro.

This has been a really insightful look at what architecturally significant requirements truly are and made more importantly, how architects actually find them in the real world.

Just to quickly recap the core ideas, ASRs are those requirements with a profound impact on the structure and high business value.

Finding them is an active investigation.

Right.

And we talked about the four main places to look.

One, requirements documents, but read them critically, looking past the vague parts.

Two, stakeholder engagement, especially using structured methods like the quality attribute workshop.

Three, tracing requirements back to the fundamental business goals, maybe using something like Paul M.

And four, the architects own structured assessment using a utility tree when other sources are lacking.

It really underscores that the architect's role goes way beyond just technical design.

It's deeply investigative, collaborative, and strategic, focusing on the few things that truly make or break the system.

Absolutely.

And that leads to a final thought for you, our listeners, to consider based on the chapter's insights.

Imagine you had a really detailed, high quality requirements document for a complex system.

If you went through every single sentence, every bullet point, and categorized it as either green, definitely an ASR, yellow, maybe relevant, needs clarification, or red, functionality details, irrelevant to core architecture.

What percentage of that entire document do you honestly think would end up being green?

The answer is often surprisingly small, and it really tells you something profound about where an architect needs to focus their energy, often well beyond the bounds of that formal document.

A very provocative question, indeed.

Something definitely worth mulling over for your next project.

Thank you so much for joining us for this deep dive.