From Requirements to Decisions: Why Architecture Design Isn’t Just Drawing Boxes

01 Put the problem statement into four boxes

Architecture design inputs are divided into four categories:

Business goals – e.g., launch in six months, onboard 20 hospitals, cut operating costs, meet regulatory requirements.

Functional requirements – e.g., query slots, submit registration, process payment, cancel appointments.

Quality attributes – e.g., 10,000 concurrent registrations with 95% responses under 2 seconds; core registration remains available if a service instance fails.

Constraints – e.g., must integrate existing HIS, patient data must stay on‑premise, use specific protocols or platforms, limited to existing data center.

02 What are architecture‑driving factors

A driving factor is a high‑priority requirement, quality attribute, or constraint that would cause project failure if unmet, significantly changes the system structure, or impacts multiple components or quality attributes.

Rounded button corners – not a driving factor; does not affect overall structure.

User can change avatar – not a driving factor; impact is limited.

10,000 concurrent registrations – driving factor; influences cache, scaling, load‑balancing, and database design.

Medical data must stay on‑premise – driving factor; influences data, deployment, and security architecture.

03 ABSD – Architecture‑Based Software Design

ABSD is driven by the combination of business, quality, and functional requirements.

Three foundations

Functional decomposition – break a complex system into subsystems and components (e.g., user, registration, payment, notification, statistics, HIS integration).

Choose an architectural style – e.g., layered for responsibility isolation, event‑driven for decoupling actions.

Use software templates – reusable structures, component roles, and connections (not a Word template).

Three characteristics

Top‑down: refine the whole system down to components and classes;
Recursive refinement: each subsystem can be further decomposed;
Iterative: requirements and design feedback each other continuously.

Design can start before requirements are fully finished, but analysis must continue in parallel.

04 The textbook five‑step design process

Propose model → Map components → Analyze interaction → Generate architecture → Conduct review

Propose architecture model – select an appropriate style and build an initial model.

Map components – place identified components into the architecture.

Analyze interaction – define who calls whom, data passed, interfaces, and failure handling.

Generate architecture – refine components and relationships into a complete architecture.

Design review – check that the architecture satisfies functional, quality, and constraint requirements.

The third step (interaction analysis) is often missed; arranging boxes alone is insufficient.

05 ADD – Attribute‑Driven Design

ADD emphasizes quality‑attribute scenarios and high‑priority driving factors.

Seven‑step process

1. Review design inputs;
2. Choose driving factors and set the round’s goal;
3. Select system elements to refine;
4. Choose design concepts that satisfy the driving factors;
5. Allocate responsibilities and define interfaces;
6. Draw views and record decisions;
7. Analyze and evaluate the current design.

After a round, another element can be refined; thus ADD is also recursive and iterative.

Quality‑attribute tactics (examples)

Performance – cache, load balancing.

Availability – heartbeat, fail‑over.

Security – authentication, authorization, audit.

Modifiability – abstract interfaces, adapters.

Styles (layered, event system) are high‑level; tactics (cache, heartbeat, adapter) are concrete measures.

06 ABSD vs. ADD

Chinese name – ABSD: 基于架构的软件设计; ADD: 属性驱动设计.

Driving focus – ABSD: combination of business, quality, functional requirements; ADD: quality‑attribute scenarios and high‑priority driving factors.

Main handles – ABSD: functional decomposition, architectural style, software templates; ADD: patterns, tactics, responsibilities, interfaces.

Common points – both use top‑down, recursive, iterative approaches.

ABSD is a more complete architecture‑driven design method; ADD specifically stresses quality‑attribute scenarios and driving factors.

07 Constraints vs. Decisions

Constraints are external or environmental boundaries that cannot be freely changed. Decisions are choices made within those boundaries.

Constraint: Must integrate the hospital’s existing MySQL;
Decision: Add a Redis cache in front of MySQL.

A complete architecture decision record (ADR) should include:

Context – what problem is faced;
Decision – which solution is chosen;
Alternatives – other options considered;
Rationale – why this choice;
Consequences – benefits gained and costs incurred.

After a successful registration, the system must send SMS, update statistics, and record audit. To avoid slowing the main flow, an event system publishes a “registration success” event, allowing services to handle these actions asynchronously. This reduces coupling and eases adding consumers, but introduces duplicate‑message handling, loss handling, and eventual‑consistency concerns.

08 Walk through an Internet‑Hospital design

Known conditions

Business goal: launch in six months, gradually onboard 20 hospitals;
Functional requirements: query slots, register, pay, cancel, notify;
Performance: 10,000 concurrent registrations, 95% responses < 2 s;
Availability: core registration must stay up if a service instance fails;
Constraints: must integrate existing HIS, patient data must stay on‑premise.

Identify driving factors

High‑peak concurrency & 2 s response;
Core registration service must stay available;
Need to onboard many hospitals;
Must be compatible with HIS;
Data must remain on‑premise.

Architecture decisions

Cache hot slot data

Problem solved: database peak pressure.

Benefit: faster queries.

Cost: cache invalidation & consistency handling.

Deploy registration service with multiple instances

Problem solved: single‑instance failure & load pressure.

Benefit: higher availability & scalability.

Cost: more complex deployment, monitoring, state management.

Use an event system for notifications

Problem solved: post‑process actions slow the main flow.

Benefit: decoupling, asynchronous expansion.

Cost: eventual consistency, duplicate consumption.

Integrate HIS via an adapter

Problem solved: different hospital interfaces.

Benefit: isolation of change.

Cost: need to maintain the adapter layer.

This demonstrates deriving architecture from requirements rather than starting with a list of trendy technologies.

09 How to answer case‑study questions

First analyze business goals, functional requirements, quality attributes, and constraints to find the most impactful driving factors. Then decompose responsibilities, identify main components, choose appropriate styles, patterns, and tactics, map components, define interactions and interfaces, document the decision, alternatives, rationale, benefits, and costs, and finally review and iterate.

For a question specifically about ABSD:

ABSD is driven by business, quality, and functional requirements. Its three foundations are functional decomposition, architectural‑style selection, and software‑template reuse. It proceeds top‑down, recursively, and iteratively, refining the system into subsystems, components, and classes.

For a question about ADD:

ADD takes quality‑attribute scenarios, primary functional requirements, and constraints as input, selects high‑priority driving factors, and recursively refines system elements using patterns and tactics, assigning responsibilities, defining interfaces, creating views, recording decisions, and evaluating the design.

10 Output tasks

Doodle

Business goal ─┐
Functional req ─┼→ Driving factor → Style/Pattern/Tactic
Quality attr ─┤                     ↓
Constraint ─┘                Component → Interface → View
                              ↓
                              Decision + Rationale + Benefit + Cost

3‑minute talk points

Four types of input.

How to spot architecture‑driving factors.

ABSD’s three foundations.

Why ADD is called attribute‑driven.

Difference between constraints and decisions.

Why decisions must include costs.

11 Ten self‑test questions and reference answers

ABSD’s English full name?

Which three requirement types drive ABSD?

What are ABSD’s three foundations?

What are ABSD’s three characteristic processes?

What are the textbook’s five architecture‑design steps?

ADD’s English full name?

What input best represents ADD?

What is an architecture‑driving factor?

Difference between a constraint and an architecture decision?

Why is “use Redis” alone not a complete architecture decision?

1. Architecture‑Based Software Design.
2. Business requirements, quality requirements, functional requirements.
3. Functional decomposition, choose architectural style, use software templates.
4. Top‑down, recursive refinement, iterative.
5. Propose model, map components, analyze interaction, generate architecture, conduct review.
6. Attribute‑Driven Design.
7. Quality‑attribute scenarios and high‑priority driving factors.
8. High‑priority requirements, quality attributes, and constraints that most affect structure.
9. Constraints are non‑negotiable boundaries; decisions are choices made within those boundaries.
10. It lacks context, rationale, alternatives, benefits, and costs.

12 Passing criteria

Answer at least 8 of the 10 self‑test questions correctly;
Explain ABSD’s three foundations in a closed‑book setting;
Do not treat ABSD and ADD as the same method;
Derive at least two design measures from a single quality‑attribute scenario;
Write a technology choice as “problem + decision + rationale + benefit + cost”.