How do you identify architecturally significant requirements (ASRs) from a large backlog of requirements and stakeholder statements?
answer
- ASR = change it, change the structure
- six-part scenario with a response measure
- utility tree: importance x difficulty
- constraints and business goals, not just the backlog
- high/high leaves drive design
basics
~20 sLook past feature lists for requirements that constrain structure: measurable quality goals (latency, uptime, scale, security), hard constraints (regulation, deadlines, existing systems), and the few features that touch everything. Turn vague wishes into testable scenarios, then prioritise by business value and technical difficulty.
solid answer
~50 sASRs are the requirements that, if changed, would change the architecture. I harvest them from three sources: stated requirements and quality goals, business context and constraints (compliance, cost ceilings, deadlines, mandated platforms, team topology), and implicit expectations nobody wrote down. Each candidate is rewritten as a quality-attribute scenario with six parts — source, stimulus, artifact, environment, response, response measure — so "must be fast" becomes "during peak traffic, 99th-percentile checkout response is under 800 ms." Untestable statements are not usable ASRs. I then organise them in a utility tree (quality attribute → refinement → scenario) and prioritise each leaf twice: business importance and estimated technical difficulty. The high/high leaves are the ASRs that drive structure; they become the drivers for design, the criteria in architecture evaluation, and later the basis of automated fitness functions. Functional requirements qualify only when they are cross-cutting or exercise a risky path.
go deeper
Say that you look for quality requirements and constraints rather than features, and that a good requirement has a number attached so it can be tested.
Present the six-part quality-attribute scenario and the utility tree with importance and difficulty ratings; explain which functional requirements also qualify (cross-cutting ones).
Cover elicitation from business goals, constraints and non-product stakeholders; growth horizons; using ASRs to drive prototypes for the risky items and as evaluation scenarios; converting them into automated checks.
Frame it as portfolio-level prioritisation: negotiating conflicting stakeholder qualities, making explicit which qualities you are deliberately sacrificing, tying ASRs to business outcomes and cost, and institutionalising periodic re-derivation as strategy changes.
## What an ASR is An **architecturally significant requirement (ASR)** is a requirement whose satisfaction depends on the architecture — change the requirement and you must change the structure. Most functional requirements are not ASRs: many different architectures can support "a user can rename a document." What discriminates between candidate architectures is mostly **quality attributes** plus **constraints**. ## Where ASRs come from 1. **Requirements documents / backlog** — but stated quality goals are usually vague ("must be scalable"). 2. **Business goals** — entering a regulated market, halving infrastructure cost, supporting a new sales channel. Business goals imply qualities nobody has written as requirements. 3. **Constraints** — decisions already fixed and not up for negotiation: regulation and data residency, an immovable launch date, a mandated cloud or vendor, an existing system you must integrate with, the skills and shape of the teams. 4. **Stakeholder interviews / workshops** — operations, security, support and finance stakeholders surface qualities the product owner never mentions (deployability, observability, recoverability, cost per transaction). ## Making them testable: quality-attribute scenarios A usable ASR is expressed as a **six-part scenario**: - **Source** — who or what generates the stimulus (a user, an attacker, a failing node) - **Stimulus** — the event (10x traffic spike, disk failure, credential-stuffing attempt) - **Artifact** — the part affected (checkout service, the whole system) - **Environment** — the operating state (peak load, degraded mode, during deployment) - **Response** — what the system should do - **Response measure** — the number that makes it verifiable "The system must be highly available" becomes "if one availability zone fails during business hours, the ordering API keeps serving with no more than 30 seconds of degraded latency and zero acknowledged-order loss." The measure is what makes it an engineering target rather than an aspiration. ## Organising and prioritising: the utility tree A **utility tree** is a top-down structure: root "utility", then quality attributes (performance, availability, security, modifiability, ...), then refinements (availability → data durability), then concrete scenarios as leaves. Each leaf gets two ratings, typically High/Medium/Low: - **business importance** (from stakeholders) - **technical difficulty / risk** (from architects) **(High, High)** leaves are your ASRs: they matter and they are hard, so they must drive design and be evaluated explicitly. (High, Low) is reassurance; (Low, High) is where teams burn budget on things nobody needs. ## Functional requirements that are ASRs Some are: those that are cross-cutting (multi-tenancy, an audit trail of every change, offline operation, undo across aggregates), those on the critical path of a hard quality target, and those that fix an external contract. A good filter: does satisfying this require a mechanism that appears in more than one component? ## Common failure modes - **Unmeasurable qualities** — "fast", "secure", "scalable" with no number, no load profile and no time horizon. - **Everything is priority one** — without relative ranking there is no basis for the trade-offs architecture must make. - **Missing the growth dimension** — ASRs need a horizon (today's 1k orders/day versus an expected 100k in 18 months) because architecture is sized against the future, not the present. - **Ignoring operational and organisational qualities** — deployability, observability, cost and team autonomy are ASRs even though no customer asks for them. - **Treating constraints as requirements to be traded away** — constraints reduce the design space; record and respect them rather than silently optimising against them. ## What you do with the list The ASR list becomes: the input to design (each ASR needs an identified mechanism), the agenda for architecture evaluation, the source of prototypes and spikes for the risky ones, and eventually automated checks — load tests, chaos experiments, dependency rules — that keep the system honest over time.
- A stakeholder says the system must be scalable. How do you turn that into an ASR?Ask what scales, along which dimension, to what number, by when, and at what cost and latency target. Produce something like: 'concurrent active sessions grow from 5k to 50k within 12 months; the system sustains 50k with p99 under 300 ms and no worse than linear infrastructure cost growth.' Then rate importance and difficulty.
- How do ASRs relate to architecture evaluation methods such as ATAM?They are its raw material. ATAM builds the utility tree, walks the top-priority scenarios against the proposed architecture, and records sensitivity points, trade-off points, risks and non-risks. Without prioritised, measurable ASRs there is nothing objective to evaluate against.
saying these in an interview costs you the question
- Listing only functional features and calling them the architectural drivers
- Accepting quality goals with no response measure or load/time horizon
- Prioritising by business value alone, ignoring technical difficulty, so risky items are never surfaced
- Forgetting constraints (regulatory, organisational, vendor, deadline) that shrink the design space
- Assuming the ASR list is fixed — it must be revisited as business goals and scale change