第2章 业务需求到架构目标的映射：需求优先级分析、质量属性拆解、架构约束识别
在AI解决方案设计中，从原始业务需求到可落地的架构目标，必须经过三层严格的转换与过滤。缺少任何一层，架构都会陷入“技术驱动”或“需求驱动”的极端，导致交付后频繁返工或无法承载业务增长。本章聚焦需求优先级分析、质量属性拆解、架构约束识别，建立从业务语言到架构语言的标准化映射路径。
2.1 需求优先级分析
业务需求清单通常是杂乱且相互冲突的。架构师需要借助结构化方法对需求进行排序，避免在非核心特性上浪费架构资源。最常用的两种模型是 MoSCoW 与 Kano。
| 维度 | MoSCoW 分类 | Kano 模型 |
|---|---|---|
| 核心理念 | Must-have / Should-have / Could-have / Won't-have | 基本型 / 期望型 / 兴奋型 / 无差异型 / 反向型 |
| 适用阶段 | 版本规划、迭代排序 | 用户满意度驱动、特性创新 |
| 架构影响 | 决定模块是否纳入当前架构边界 | 识别差异化竞争力，影响非功能性设计权重 |
| 输出产物 | 优先级排序列表 + 版本路线图 | 特性分类矩阵 + 满意度权重 |
架构建议：在AI项目中，将“数据管道稳定性”和“模型推理延迟”归为 Must-have，将“多模态交互”归为 Could-have 或 Won't-have，可有效防止架构范围膨胀。
2.2 质量属性拆解
质量属性（Quality Attributes）是架构目标的核心载体。每个质量属性必须从定义、度量指标、架构决策点三个层次进行拆解，才能转化为可验证的架构目标。
| 质量属性 | 关键指标 | 典型架构决策 | 冲突关系 |
|---|---|---|---|
| 可用性 | SLA 99.9%+、MTBF、MTTR | 冗余部署、故障转移、无状态设计 | 与成本负相关 |
| 性能 | P99 延迟 < 200ms、吞吐量 QPS | GPU 推理优化、边缘缓存、异步流水线 | 与可扩展性正相关 |
| 安全性 | 数据加密、访问审计、模型防注入 | API 网关认证、推理沙箱、数据脱敏 | 与性能负相关 |
| 可扩展性 | 水平扩展能力、模块解耦度 | 微服务拆分、事件驱动、无状态设计 | 与可用性正相关 |
| 可维护性 | 代码复用率、文档覆盖率、构建时间 | 分层架构、标准化接口、CI/CD 流水线 | 与性能负相关 |
常见误区：试图在所有质量属性上同时达到最优。架构师必须根据业务优先级做出权衡，例如“推荐系统”优先保障性能与可扩展性，“金融风控”优先保障可用性与安全性。
2.3 架构约束识别
约束是架构设计中不可协商的边界条件，通常来自组织、技术栈、合规与时间成本四个维度。忽略任何一项约束，都可能导致架构方案被否决或无法通过验收。
- 技术栈约束：已有基础设施（云平台、GPU 机型）、编程语言生态、第三方依赖版本。例如团队仅熟悉 Python + PyTorch，则不应强行引入 Java + TensorFlow Serving。
- 组织约束：团队规模、技能分布、跨部门协作模式。例如数据科学团队与工程团队分离时，需要定义清晰的模型交接契约。
- 合规约束：数据主权（GDPR / 《数据安全法》）、行业认证（PCI-DSS / HIPAA）、模型可解释性要求。合规约束直接影响数据流向与推理链路。
- 时间与成本约束：交付 deadline、预算上限、人力投入。决定了架构的“最小可行范围”与“技术债容忍度”。
将约束提前文档化并纳入架构评审检查清单，可避免在详细设计阶段被迫推翻核心假设。建议使用“约束矩阵”将每条约束与受影响的质量属性、模块进行关联。
映射框架总览
下图将上述三层映射整合为可操作的流程框架，展示从业务需求输入到架构目标输出的完整转换链路：
落地检查清单：
① 是否所有 Must-have 需求都有对应的质量属性指标？
② 质量属性之间是否存在未处理的冲突（如性能 vs 安全性）？
③ 约束矩阵是否已覆盖技术、组织、合规、时间成本四个象限？
④ 架构目标是否可量化、可验证、可追溯到具体业务需求？
① 是否所有 Must-have 需求都有对应的质量属性指标？
② 质量属性之间是否存在未处理的冲突（如性能 vs 安全性）？
③ 约束矩阵是否已覆盖技术、组织、合规、时间成本四个象限？
④ 架构目标是否可量化、可验证、可追溯到具体业务需求？
完成上述三层映射后，架构团队将获得一份 “结构化需求-目标映射文档”，其中包含优先级排序列表、质量属性指标集、约束清单以及三者共同推导出的架构目标基线。这份文档是后续进行架构边界划分、系统分层与组件职责定义的唯一输入依据。