Architecturally Significant Requirement

An architecturally significant requirement (ASR) is one that, if it changed, would make you redraw the diagram. Everything else is a feature, and features are the responsibility of design, not architecture.

The point of naming the category is triage. A large programme produces hundreds of requirements and an architect who treats them equally will produce a document nobody reads and a structure that happens by accident.

The test

For each candidate requirement ask three questions:

1. Would a change here move a boundary? New data-residency rules move storage boundaries. A new report does not.
2. Does it constrain more than one component? Auditability constrains every write path. A date-picker does not.
3. Is it expensive to satisfy late? Multi-tenancy, auditability, latency percentiles and residency are all far cheaper to design in than to retrofit.

Two yeses make it significant. Three make it page one.

Why it matters

Requirements that fail the test still get built; they simply do not deserve architectural attention. Requirements that pass and get missed do not simply cost more later — they frequently cannot be satisfied at all without rebuilding.

Implementation patterns

• The ASR register. A short list, each with the volume or threshold it implies, its source, and the structural consequence it forces. Reviewed at every major milestone.
• Quality attribute scenarios. Convert each ASR into stimulus → environment → response → measure, so it is testable rather than adjectival.
• Traceability from ASR to decision. Every architecture decision record names the ASRs it serves. An ADR serving no ASR is either undocumented rationale or an unnecessary decision.

Industry example

An SAP-based finance transformation was scoped around performance and integration volume — both genuine ASRs. Auditability was captured as a compliance requirement in an annex and never treated as structural.

It was the most significant requirement in the programme. Establishing who changed a financial record, from what value, under whose authority, requires the acting principal to be carried through every interface, batch load and support correction, and requires immutability and retention beyond the life of the row. Those are properties of the write path, and the write path is everywhere.

By the time the gap was found, most financial mutations were attributed to service accounts, the attribution data for the historical period did not exist, and reports had already been issued from the un-auditable state. The remediation was a re-platforming, not a change request.

Failure scenarios

• The annex problem. An ASR filed under compliance, security or "non-functional" and never translated into structure. This is the single most common way large programmes fail late.
• Adjective capture. "The system must be secure and highly available" passes review and constrains nothing.
• Silent expiry. An ASR derived from a volume assumption that has since moved by an order of magnitude, with no alarm attached to the assumption itself.
• Over-inclusion. Declaring forty ASRs, which is the same as declaring none.

Trade-offs

Treating a requirement as significant costs design time, review time and usually money — you are buying structural properties before you have proof they are needed. Treating it as insignificant buys speed and risks an unbuildable retrofit. The asymmetry is what decides: getting an ASR wrong in the cautious direction costs a quarter, and in the other direction costs a rewrite.

Interview question

"Give me five requirements for a payments platform. Now tell me which two are architecturally significant, and what specifically about the structure each one determines."