需求分析与架构设计：从需求到架构的映射方法、质量属性场景（QA场景）、架构驱动因素

需求分析是架构设计的起点，但需求与架构之间并非简单的线性翻译关系。架构师面临的核心挑战在于：业务需求往往以功能描述为主，而架构决策却需要以质量属性（性能、可用性、安全性、可修改性等）为约束。本章围绕“从需求到架构的映射方法”“质量属性场景（QA场景）”“架构驱动因素”三个核心主题，建立一套可操作的需求分析框架，帮助架构师在需求不完整、冲突或模糊的情况下，仍能做出有依据的架构决策。

3.1 核心原理：需求与架构的映射本质

需求与架构之间的映射不是“需求文档→架构图”的简单翻译，而是一个多轮迭代、权衡取舍的决策过程。其本质可以概括为三个层次：功能需求决定“系统做什么”，质量属性需求决定“系统做得怎么样”，约束条件决定“系统在什么边界内做”。架构设计的目标就是在这些需求之间寻找最优平衡点。

从需求到架构的映射方法通常包括以下步骤：

1. 需求分类与优先级排序：将需求分为功能需求（FR）、质量属性需求（QR）和约束条件（Con），并使用MoSCoW方法（Must/Should/Could/Won't）确定优先级。
2. 识别架构驱动因素：从需求中提取对架构影响最大的因素，通常包括核心业务功能、关键质量属性、技术约束和业务目标。
3. 构建质量属性场景：将模糊的质量属性需求转化为可度量的QA场景，为架构评估提供依据。
4. 候选架构方案生成：基于驱动因素，结合架构风格（如分层、微服务、事件驱动）和模式（如CQRS、Saga）生成候选方案。
5. 架构评估与迭代：使用ATAM（Architecture Tradeoff Analysis Method）等方法对候选方案进行评估，验证其是否满足QA场景。

3.2 质量属性场景（QA场景）的构建方法

质量属性（如性能、可用性、安全性）往往是架构设计中最关键也最容易被误解的需求。QA场景提供了一种结构化的方式，将模糊的质量属性需求转化为可验证的、具体的场景描述。一个完整的QA场景包含六个要素：刺激源、刺激、环境、制品、响应、响应度量。

构建QA场景的流程如下：

• 第一步：收集质量属性需求。从利益相关者访谈、需求文档、业务目标中提取质量属性关键词（如“快”“稳定”“安全”）。
• 第二步：将模糊描述转化为场景。例如“系统要快”转化为“在1000并发用户下，订单查询接口的P99响应时间不超过500ms”。
• 第三步：验证场景的可度量性。每个场景必须包含明确的响应度量指标，否则无法用于架构评估。
• 第四步：确定场景优先级。并非所有QA场景都同等重要，需要结合业务价值和技术风险进行排序。

3.3 架构驱动因素的识别与优先级排序

架构驱动因素（Architecturally Significant Requirements, ASRs）是指那些对架构形态产生决定性影响的需求。识别ASRs是需求分析阶段最重要的产出之一。ASRs通常包括：

• 核心功能需求：系统必须实现的关键业务能力，如电商系统的“订单支付”功能。
• 关键质量属性：对业务成功至关重要的质量属性，如金融系统的“安全性”和“可用性”。
• 技术约束：必须遵守的技术限制，如“必须使用Java技术栈”“必须部署在私有云”。
• 业务目标：驱动架构决策的业务战略，如“支持未来3年用户量增长10倍”。

识别ASRs的常用方法包括：

1. 需求走查：与业务方、产品经理逐条走查需求，标记对架构有影响的需求。
2. 场景风暴：通过头脑风暴构建QA场景，从中提取高频出现的质量属性。
3. 约束分析：明确技术栈、部署环境、合规要求等硬性约束。
4. 业务目标对齐：将架构驱动因素与业务战略对齐，确保架构支持长期发展。

3.4 案例拆解：电商订单系统的需求到架构映射

以下通过一个电商订单系统的案例，展示从需求到架构的完整映射过程。

背景与约束：某电商平台计划重构订单系统，现有系统采用单体架构，面临性能瓶颈和扩展性差的问题。业务目标是在未来3年内支撑订单量增长5倍，同时保证大促期间的可用性。技术约束包括：必须使用Java技术栈，数据库需兼容MySQL，部署环境为私有云。

初始现象与目标：现有系统在双11大促期间出现订单超时、库存扣减不一致等问题。目标是将订单系统的峰值吞吐量提升至5000 TPS，可用性达到99.99%，并支持水平扩展。

关键输入数据：

• 当前订单系统峰值TPS：800
• 大促期间目标TPS：5000
• 可用性目标：99.99%（年停机时间≤52.6分钟）
• 数据一致性要求：库存扣减与订单创建必须强一致

分析判断过程：

1. 识别ASRs：核心功能为订单创建、库存扣减、支付回调；关键质量属性为性能（高TPS）、可用性（99.99%）、一致性（强一致）；约束为Java技术栈、MySQL、私有云。
2. 构建QA场景：例如性能场景“在5000 TPS的订单创建请求下，订单服务平均响应时间≤100ms，P99≤300ms”；可用性场景“在数据库主节点故障时，系统自动切换至备节点，RTO≤30s，RPO≤5s”。
3. 候选架构方案：方案A为微服务架构（订单服务、库存服务、支付服务独立部署）；方案B为模块化单体+读写分离；方案C为事件驱动架构（引入消息队列异步处理）。
4. 架构评估：使用ATAM评估三个方案。方案A在扩展性和可用性上最优，但引入了分布式事务复杂度；方案B实现简单但扩展性受限；方案C在性能上最优，但一致性保障难度大。

实际操作步骤：

• 选择方案A（微服务架构），并引入分布式事务框架（如Seata）解决库存扣减与订单创建的一致性问题。
• 将订单服务拆分为订单查询和订单写入两个独立服务，分别优化读写性能。
• 引入Redis缓存热点商品库存，降低数据库压力。
• 设计数据库分库分表方案，按用户ID取模分片。

结果对比：重构后系统在压测中达到5200 TPS，P99响应时间280ms，可用性达到99.99%。相比原系统，性能提升6.5倍，可用性提升0.05个百分点（对应每年减少约4.4小时停机时间）。

风险与代价：微服务架构引入了运维复杂度，需要额外的服务监控、链路追踪和容器编排能力。分布式事务框架带来一定的性能开销（约5%-10%）。团队需要学习微服务相关技术栈。

复盘经验：需求到架构的映射过程中，QA场景的构建质量直接决定了架构评估的有效性。本案例中，如果未将“库存扣减强一致”转化为具体的QA场景，可能会选择事件驱动架构，导致数据不一致风险。

3.5 常见误区与总结复盘

在需求分析与架构设计的实践中，架构师常犯以下错误：