Module 5: Stakeholders and Quality Attributes

4. Architecturally significant requirements: the signal and the noise

Next →

Overview

By the end of this lesson you'll know how to separate, from the avalanche of requirements that reach an architect, the very few that really shape the architecture from the very many that don't —and why spending your energy on the wrong ones is the most common way for an architect to become irrelevant or a bottleneck—. A Mercado product gets hundreds of requirements per quarter: "the buy button must be green", "isolate each vendor's data", "show the rating with yellow stars", "support 10x the traffic", "add a nickname field to the profile", "comply with PCI-DSS for the card data". All are legitimate requirements. But only some are architecturally significant: the ones that, if you ignore them at the start, force you to redo half the system later. Those are called architecturally-significant requirements (ASRs), and the criterion to recognize them is a three-question test: does it shape the system's structure? is it expensive to change later? is it high-risk (business or technical)? "Isolate each vendor's data" passes all three —it decides the entire data structure, it's very expensive to retrofit, and a leak is a disaster—. "The green button" passes none —it doesn't touch the structure, it changes in one line of CSS, and getting it wrong risks nothing—. You'll execute a filter that takes eight Mercado requirements and separates them: five turn out ASR (the signal) and three, noise for the architect (they matter to the product, not the structure).

This matters because an architect's time and attention are a team's scarcest resource, and the trap is treating all the requirements as if they deserved that resource equally. The architect who gets into deciding the button's color, the text of a message, or whether the field is called "nickname" or "alias" is stealing time from the decisions that are irreversible and expensive, and —worse— they're becoming the bottleneck module 4 taught to avoid: everything passes through them, even what shouldn't. At the same time, the architect who does not identify an ASR in time —who treats "isolate each vendor's data" as a detail to be resolved later— condemns the team to a painful refactor when they discover, with the system already built, that multi-tenancy had to be designed from day one. The ASR is the tool that tells the architect where to get in and where not: get in deep on the five requirements that shape the structure; leave the other three to the product team, who knows better than you what color the button should be. Distinguishing the signal from the noise isn't an intellectual luxury: it's what lets you be an architect who enables instead of one who gets in the way.

Connection with the module: this lesson is the filter that makes everything before manageable. Lesson 2 prioritized the attributes; lesson 3 turned them into measurable scenarios. But if you had to write a six-part scenario for every requirement that arrives, you'd drown —and most don't deserve it—. The ASR is the criterion that decides on which requirements the heavy work (prioritize, write the scenario, design the structure) is worth doing and which are dispatched without ceremony. It's the funnel between "everything the business asks for" and "the few things that shape the architecture". The lessons that follow lean on it: lesson 5 discovers implicit ASRs no one wrote (the attributes the business took for granted); and lessons 6 and 7 are the conversations about those few ASRs that matter —you won't negotiate the button's color with the VP, you'll negotiate the isolation level and its cost—. The frontier stays: here you identify which requirement is significant; how the solution for that ASR is decided —what multi-tenancy architecture, with what trade-offs— is architecture-decisions's method.

The structure inspector who ignores the paint color

Think about it with the house again, but now with the inspector who reviews a remodel. The owners have a very long list of changes they want: knock down a wall to join the living room and the dining room, change the wall color to blue, move the ground-floor bathroom to the other side of the house, put in new curtains, add a second floor, change the door knobs. The structural inspector arrives and does something that seems cold but is pure wisdom: they completely ignore the color, the curtains, and the knobs, and concentrate on three things —knocking down the wall, moving the bathroom, adding the floor—. Why? Because those three touch the structure: knocking down a wall can affect a load; moving the bathroom implies rethinking all the plumbing and drainage; adding a floor changes the foundations. Getting any of the three wrong means redoing the house, with enormous costs and real risk that something falls. The wall color, by contrast, is changed on a Saturday with a brush; the curtains, in an afternoon; the knobs, in ten minutes. If the inspector spent their attention approving the shade of blue, they'd be doing the wrong job and —worse— delaying the owners on decisions they can make alone.

The inspector applies, without naming it, the ASR test: does it touch the structure? is it expensive to change later? is it high-risk? The wall, the bathroom, and the floor pass all three; the color, the curtains, and the knobs pass none. And the consequence is double, just like in software. First, the inspector gets in deep only in the three structural decisions —they study them, calculate them, make sure the house doesn't fall—. Second, and less obvious: by not getting into the color and the curtains, they return those decisions to the owners, who are the ones who should make them —the inspector has no business weighing in on the blue—. The software architect is that inspector. Of the list of requirements that arrive, most are "the paint color" —important for the product, trivial for the structure— and a few are "knock down the wall" —the ASRs, where the architect must put all their attention—. Confusing the two is the mistake: neither get into the color (you get in the way), nor ignore the wall (the house falls).

Worked example: filtering the ASRs from the noise

We'll execute the three-question test over eight requirements that reached Mercado's architect. For each one, three binary signals: does it shape the structure? (0/1), is it expensive to change later? (0/1), is it high-risk? (0/1). We sum the three to get a "signal" from 0 to 3, and apply the rule: a requirement with signal ≥ 2 is an ASR; the rest is noise for the architect. The ≥ 2 rule (instead of demanding all three) is deliberate: a requirement can be significant even if it doesn't mark all three —the fast checkout, for example, shapes the structure and is expensive to change even if it's not high business risk—.

# Not every requirement shapes the architecture. An ASR (architecturally-significant
# requirement) is one that DOES shape it. Criterion of 3 questions:
#   (1) does it shape the structure?  (2) is it expensive to change later?  (3) is it high-risk?
# A requirement with >=2 "yes" is an ASR: the signal. The rest is noise (matters to the
# product, but not to the structure).

requirements = [
    # requirement                                  shapes  costly  high
    #                                              struct  change  risk
    ("isolate each vendor's data",                    1,     1,     1),
    ("support 10x the traffic in 18 months",          1,     1,     1),
    ("don't lose an order if the gateway goes down",  1,     1,     1),
    ("comply with PCI-DSS for card data",             1,     1,     1),
    ("checkout in under 2 seconds",                   1,     1,     0),
    ("the buy button must be green",                  0,     0,     0),
    ("show the rating with yellow stars",             0,     0,     0),
    ("add a nickname field to the profile",           0,     0,     0),
]

print(f"{'requirement':<46}{'signal':>7}{'ASR?':>6}   classification")
asrs, noise = [], []
for req, shapes, costly, risky in requirements:
    signal = shapes + costly + risky
    is_asr = signal >= 2
    (asrs if is_asr else noise).append(req)
    tag = "ASR (shapes the arch.)" if is_asr else "noise (non-arch.)"
    print(f"{req:<46}{signal:>5}/3{('YES' if is_asr else 'no'):>6}   {tag}")

print()
print(f"Of {len(requirements)} requirements: {len(asrs)} are ASR and {len(noise)} are noise.")
print("The architect spends their energy on the ASRs. The rest the product decides,")
print("and changing it later is cheap: that's why it doesn't shape the architecture.")

What to expect. Running it:

requirement                                   signal  ASR?   classification
isolate each vendor's data                       3/3   YES   ASR (shapes the arch.)
support 10x the traffic in 18 months             3/3   YES   ASR (shapes the arch.)
don't lose an order if the gateway goes down     3/3   YES   ASR (shapes the arch.)
comply with PCI-DSS for card data                3/3   YES   ASR (shapes the arch.)
checkout in under 2 seconds                      2/3   YES   ASR (shapes the arch.)
the buy button must be green                     0/3    no   noise (non-arch.)
show the rating with yellow stars                0/3    no   noise (non-arch.)
add a nickname field to the profile              0/3    no   noise (non-arch.)

Of 8 requirements: 5 are ASR and 3 are noise.
The architect spends their energy on the ASRs. The rest the product decides,
and changing it later is cheap: that's why it doesn't shape the architecture.

Read the table top to bottom and you'll see two clearly separated worlds. At the top, the five ASRs: "isolate each vendor's data" marks 3/3 —it shapes the structure (decides how the data is partitioned, how each request is authorized, maybe how each tenant is deployed), it's very expensive to change later (retrofitting multi-tenancy to a single-tenant system is one of the most painful refactors that exist), and it's high-risk (a leak between vendors is a legal and reputational disaster)—. "Comply with PCI-DSS" the same: it defines where and how the card data lives, it's very expensive to add late, and the regulatory risk is enormous. These are the "walls" of the house: the architect has to get in deep, because getting it wrong means redoing the system.

At the bottom, the three noise ones: "the buy button must be green", "yellow stars", "nickname field" —all 0/3—. They don't touch the structure (they're presentation details or one more field in a table), they change in minutes, and getting them wrong risks nothing serious. Watch the word "noise": it doesn't mean they don't matter. The button color can affect conversion, and that's money; the nickname field can be exactly what an important customer asked for. They're legitimate and valuable requirements for the product. "Noise" is strictly from the architect's point of view: they're decisions that don't shape the architecture and that, therefore, the architect shouldn't hog. The product team knows better than the architect what color the button should be —they have the conversion data, they understand the users—. That the architect gets in there is doubly bad: it makes the decision worse (it's not their expertise) and it turns them into a bottleneck. The classification doesn't despise those requirements; it puts them in the right hands.

Stop at the interesting case, the one that teaches why the rule is "≥ 2" and not "= 3": "checkout in under 2 seconds" marks 2/3 and is an ASR. It shapes the structure (a sub-2-second checkout can demand caching decisions, async processing, how the calls to services are ordered) and it's expensive to change later (if you designed it without thinking about latency, tightening it later can require restructuring the flow). But we do not mark it high-risk: if checkout takes 2.5 seconds instead of 2, it's bad for conversion but it's not a disaster like a data leak. A requirement can be architecturally significant by shaping the structure and being expensive to change, without being catastrophically high-risk. That's why the threshold is 2 of 3: demanding all three would leave out requirements that do shape the architecture. The three questions are independent signals of significance, and two are enough for the architect to have to pay attention. This case teaches you not to turn the test into a rigid dogma: it's a criterion with nuances, not a checkbox of three mandatory boxes.

An honest nuance about the binary signals. In the example, "shapes the structure", "expensive to change", and "high-risk" are 0 or 1 —a simplification—. In reality they're degrees: "isolate the data" shapes the structure a lot; "fast checkout" shapes it quite a bit; "a cache for reports" maybe shapes it a little. You could use a scale (0-3) instead of binary and tune the threshold. But the binary captures the essential and avoids false precision: for 90% of the requirements, the answer to "does it touch the structure?" is a fairly clear yes or no, and the borderline cases (like the checkout) are resolved with the other two questions. The tool doesn't pretend to be an exact algorithm that replaces judgment; it pretends to force the three right questions on each requirement, so that none slips through without the architect having consciously decided whether it deserves their attention or not. The value isn't in the final number; it's in having asked.

Deep dive: why these three questions, and the ASR that arrives in disguise

It's worth understanding why these three questions —and not others— define architectural significance, because each one captures a different reason a requirement deserves the architect's attention.

"Does it shape the structure?" is the question of form. An architecturally significant requirement is one that, to be met, forces you to organize the system a certain way —to partition the data this way, to separate these services, to put this queue here—. "Isolate each vendor's data" isn't met with a function; it's met with a form of the system (how it's partitioned, authorized, deployed). The button color imposes no form: the system can have any structure and still paint the button green. If a requirement can be satisfied without changing how the system's pieces are organized, it doesn't shape the structure.

"Is it expensive to change later?" is the question of irreversibility. Here it connects with the whole sister guide architecture-decisions: the decisions that matter are the expensive-to-revert ones. A requirement that can be satisfied late, painlessly, doesn't need the architect's attention at the start —it can be deferred—. One that, if you don't consider it from day one, forces a massive refactor, is an ASR precisely because the moment to decide it is now. Retrofitting multi-tenancy, security, or scalability to a system that didn't contemplate them is among the most expensive things there is; painting the button another color, among the cheapest. The question separates what has to be decided early from what can wait.

"Is it high-risk?" is the question of the cost of the error. Some requirements, if done wrong, produce disasters —a payment data leak, an outage on Black Friday, a regulatory violation—. Others, if done wrong, produce nuisances —an ugly button, a confusing message—. The architect must put their attention where the cost of getting it wrong is catastrophic, because that's where their experience prevents the disaster. A high-risk requirement deserves architectural attention even if its structure is simple, because what's at stake is big.

Now, the real danger: the ASR that arrives disguised as a trivial requirement. The test is easy when the requirement shouts its significance ("isolate each vendor's data" obviously shapes everything). It's treacherous when an ASR arrives dressed as an innocent detail. Classic example: the product team asks for "add support to show prices in the buyer's local currency". It sounds like a presentation feature —like the button color—. But if you think about it with the three questions, it can be an ASR: does it shape the structure? Maybe a lot (where are the exchange rates stored? are they recomputed on each request or cached? is the price stored in a base currency and converted, or in several? do the taxes change by country?). Is it expensive to change later? Yes, if you designed it assuming a single currency. Is it high-risk? Charging the wrong price because of a conversion error is serious. What looked like "the button color" turns out to be "knocking down a wall". The craft isn't just applying the test to the requirements that obviously deserve it; it's smelling which apparently trivial requirements hide a structural decision, and running the test on them before dispatching them as noise. The most expensive mistake isn't getting into the button's color; it's not getting into the "presentation detail" that was actually multi-currency.

And the frontier, once more. The ASR test tells you which requirements shape the architecture and deserve your attention. It doesn't tell you what architecture to choose to satisfy them —what multi-tenancy scheme, what scaling strategy, what multi-currency architecture—. Identifying that "isolate each vendor's data" is an ASR is this lesson's work; deciding between the isolation options (database per tenant, schema per tenant, row per tenant with filtering) weighing their trade-offs is architecture-decisions's method. The ASR is the what deserves a decision; the matrix and the ADR are the how that decision is made. This lesson teaches you to build the architect's agenda —the short list of what really matters—; the other guide teaches you to resolve each item on that agenda.

Common mistakes

Treating all requirements as if they deserved architectural attention (of hogging). What happens: the architect reviews and weighs in on everything that arrives —the button color, the message text, the field name— and becomes the bottleneck every decision passes through, even the trivial ones. The team stalls waiting for their blessing on things they could decide alone. Why it happens: the feeling that "a good architect is involved in everything", or the discomfort of letting go of control. How to spot it: if the team can't decide a button's color without you, you're hogging. How to fix it: run the ASR test and explicitly let go of what gives 0/3 —tell the team "this is yours, don't ask me"—; your value is in the five ASRs, not the three noise ones.

Not running the test on the disguised requirement (of hidden significance). What happens: a requirement arrives dressed as a trivial detail ("show prices in local currency", "allow export to Excel", "let users delete themselves") and the architect dispatches it as noise without thinking —until, months later, it turns out it hid a structural decision (multi-currency, an export pipeline, cascade deletion and GDPR compliance)—. Why it happens: the test is applied only to what seems significant, and the disguised one slips through. How to spot it: if you dispatched a requirement as noise without asking yourself the three questions, you didn't filter it —you assumed it—. How to fix it: run the test on every requirement that touches data, money, identity, or external integrations, however trivial it sounds; that's where the disguised ASRs hide.

Turning the test into a "3 of 3" dogma (of rigidity). What happens: the architect demands that a requirement mark all three boxes to consider it an ASR, and thus leaves out "checkout in under 2 seconds" (2/3) because it's not high-risk —and treats it as noise, without designing for latency—. When the checkout turns out slow and the flow has to be restructured, the refactor is expensive. Why it happens: a criterion of three questions invites treating them as a strict AND. How to spot it: if you're discarding requirements that shape the structure just because they're not catastrophic, you hardened the rule too much. How to fix it: the three questions are independent signals; two are enough, and sometimes one very strong one (a requirement that shapes the structure massively is an ASR even if it's cheap and low-risk). The threshold is a guide, not a lock —judgment decides the borderline cases—.

Exercises

Exercise 1 — Run the test. Mercado's architect gets three new requirements: (a) "let buyers leave reviews with photos"; (b) "change Mercado's logo to the Christmas-season version"; (c) "comply with GDPR's right to be forgotten: when a user requests it, delete all their personal data within 30 days". For each one, answer the three questions (does it shape the structure? expensive to change? high-risk?) and classify it as ASR or noise.

See solution

(a) Reviews with photos.

  • Does it shape the structure? Yes. Storing and serving photos isn't trivial: where are they stored (object storage)?, are they moderated (moderation pipeline)?, are they resized (processing)?, how are they served at scale (CDN)? It introduces new structural pieces.
  • Expensive to change later? Yes, more or less. If you start storing photos "any way" and then need moderation and CDN, there's rework.
  • High-risk? Medium. Offensive or illegal photos are a reputational and legal risk.
  • Classification: ASR (at least 2/3). The "with photos" is what makes it significant —"text-only reviews" would be much less—.

(b) Christmas logo.

  • Does it shape the structure? No. It's an asset that gets replaced.
  • Expensive to change? No. Minutes.
  • High-risk? No.
  • Classification: noise (0/3). Marketing/product decision; the architect doesn't get in.

(c) Right to be forgotten (GDPR).

  • Does it shape the structure? Yes, a lot. Deleting "all of a user's personal data within 30 days" forces knowing where each piece of personal data lives —in how many tables, in which services, in which backups, in which logs, in which cache, in which analytics system—. That can require a data inventory, a cascade-deletion mechanism, and decisions about backups and logs. It's deeply structural.
  • Expensive to change later? Very expensive. Retrofitting "delete all trace of a user" to a system that scattered personal data everywhere without control is one of the most painful refactors.
  • High-risk? Extremely. Violating GDPR means millions in fines.
  • Classification: ASR (3/3). And it's the teaching case: it looks like a product feature ("a delete-my-account button") and it's one of the heaviest structural decisions that exist. The disguised ASR from the deep dive, in the flesh.

Exercise 2 — The disguised requirement. A product manager tells you, in passing: "oh, and we need the reports to be exportable to Excel, it's just a little button". Would you dispatch it as noise or run the test on it? Argue what questions you'd ask to decide, and give a scenario in which that "little button" turns out to be an ASR.

See solution

I wouldn't dispatch it as noise without running the test on it. "Export to Excel" is exactly the kind of requirement that arrives disguised as trivial ("it's just a little button") and can hide a structural decision. The questions I'd ask:

  • How much data does it export, and where does it come from? If it's a 50-row table already on screen, it's trivial (noise). If it's a report of millions of rows that have to be aggregated from several sources, generating the file can take down the server if done synchronously —which forces an async pipeline, a queue, background generation, notification when it's ready—. That's structure.
  • How often and how many users at once? An occasional export is one thing; a thousand users exporting large reports at month-end close is a load problem that shapes the architecture.
  • What data goes in the file? If the export includes personal or payment data, a security and audit topic appears (who exported what? is the file encrypted? where is it stored temporarily?).

Scenario where the "little button" is an ASR: the CFO needs to export the report of all the quarter's transactions —several million rows— for their financial analysis, and they do it right at month-end close when everyone else is also running their reports. If the export is synchronous, the request takes minutes, keeps a connection and a chunk of memory occupied, and several at once can degrade the whole system. The right solution —generate the file asynchronously in a worker, store it in object storage, and notify the CFO with a link when it's ready— is an architectural decision: it introduces a queue, a worker, temporary storage, and a notification flow. The "little button" turned out to be knocking down a wall. The lesson: requirements that touch data volume, integrations, or sensitive data deserve the test even if the PM presents them as trivial.

Exercise 3 — The architect's agenda. You have a list of 20 requirements for the next quarter. Running the test on them, 4 turn out ASR and 16 noise. A colleague tells you: "so 80% of the requirements don't matter to you, how convenient". Explain why that reading is wrong, what the classification really means, and how it changes your way of working with each group.

See solution

The reading "80% doesn't matter to you" is wrong because it confuses "doesn't require architectural attention" with "doesn't matter". The 16 noise requirements do matter —to the product, to the business, to the users—; they simply don't require the architect to decide them, because they don't shape the structure, they're cheap to change, and they're low-risk. That a requirement is noise for the architect is a statement about who should decide it (the product/development team), not about whether it's worth it.

What the classification really means: it's the architect's agenda. The 4 ASRs are where the architect puts their time, their experience, and their energy —they study them in depth, write their scenarios (lesson 3), design the structure, document the decisions—. The 16 noise ones are where the architect gets out of the way —they trust the team, don't review them one by one, don't turn them into a bottleneck—.

How it changes your way of working with each group:

  • With the 4 ASRs: deep involvement. You prioritize, write measurable scenarios, weigh options, document in ADRs, talk with the stakeholders about their trade-offs. This is where you earn your salary.
  • With the 16 noise ones: enablement and trust. You let the team decide and execute them. At most, you define general guardrails once (style guides, patterns, principles) so the team has something to decide with without you —the enabling of module 4—. You don't review them case by case.

This is, exactly, the architect who enables instead of the one who gets in the way (module 1) and who avoids the bottleneck (module 4). Distinguishing the signal from the noise isn't to disregard the 80%; it's to be able to really attend to the 20% only you can attend to, and to return to the team the 80% they decide better than you. An architect who treats the 20 requirements equally does the 4 important decisions badly (no time left) and gets in the way on the 16 trivial ones (not their expertise). The classification is what lets you be useful on both fronts.

Summary and next step

In this lesson you learned to separate the signal from the noise: from the avalanche of requirements that reach an architect, which are architecturally-significant requirements (ASRs) —the ones that shape the structure, are expensive to change, and are high-risk— and which aren't. With the inspector who ignores the paint color and concentrates on the wall, the bathroom, and the floor you saw that the craft is double: get in deep on the structural and get out of the way on the trivial. You filtered it by executing: eight Mercado requirements, five ASR and three noise, with "checkout in under 2 seconds" (2/3) teaching why the threshold is "≥ 2" and not "3 of 3". You understood that "noise" doesn't mean "worthless" but "not the architect's to decide", that the three questions capture three independent reasons for significance (form, irreversibility, cost of the error), and that the real danger is the ASR disguised as a trivial detail —the "little button" of Excel export that turns out to be an async pipeline, the "delete my account" that turns out to be GDPR—.

Before moving on you should be able to: run the three-question test on any requirement and classify it as ASR or noise; explain why a noise requirement still matters (but not to the architect); smell which apparently trivial requirements hide a structural decision; and use the classification to build the architect's agenda —where to get in and where to let go—.

What follows is the blind spot we've been mentioning. So far you worked with requirements and goals that someone asked for —the business put them on the table, you translated, prioritized, measured, and filtered them—. But there's a whole class of requirements that no one asks for and everyone expects: that a charged order isn't lost or duplicated, that every money transaction can be audited, that personal data is protected, that if something goes down at 3am someone finds out. They're the tacit contract of the domain, and an architect who only delivers what was asked for will discover them when they blow up. In lesson 5 you'll learn to discover the implicit attributes before they explode: you'll execute the gap between what the explicit goals named and what a marketplace that handles money and third-party data must always meet —six attributes no one asked for and that must be delivered anyway—.

Resources

← Previous3. The quality attribute scenario: making the vague measurableNext →5. The implicit attributes nobody asked for