3. 需求分析与建模：用例图、用户故事、领域模型、需求优先级排序（MoSCoW）、需求验证与确认
需求分析是软件架构设计的起点，也是决定项目成败的关键环节。架构师的核心职责并非直接编写代码，而是将模糊、碎片化的业务诉求转化为清晰、可验证、可追踪的技术需求基线。本章将围绕需求分析与建模的五大核心实践展开：用例图与用户故事用于捕获行为需求，领域模型用于统一业务语言，MoSCoW方法用于优先级排序，需求验证与确认则确保需求基线的正确性与完整性。我们将结合一个真实的"智能仓储管理系统"案例，展示从原始需求到可架构设计的完整转化过程。
上图展示了需求分析在软件工程中的核心链路：从需求来源出发，经过捕获、建模、优先级排序、验证确认，最终形成需求基线，作为架构设计的输入。同时，架构设计过程中发现的技术约束和可行性问题，会通过反馈回路反哺需求调整。这张图贯穿了本章所有核心概念，后续内容将逐一展开。
3.1 核心原理：需求分析的本质与建模价值
需求分析的本质是问题域与解域之间的翻译层。业务方描述的是"要什么"（问题域），而架构师需要回答"怎么建"（解域）。如果跳过需求建模直接进入架构设计，常见的后果包括：系统模块划分与业务边界错位、关键业务规则遗漏、非功能需求（性能、安全、可用性）在架构阶段无法落地。需求建模的价值在于：
- 消除歧义：通过用例图和领域模型，将自然语言中的模糊描述（如"快速处理订单"）转化为可验证的量化指标（如"订单处理P95延迟小于500ms"）。
- 建立共同语境：领域模型中的术语（如"库存台账""波次策略"）成为业务方、架构师、开发团队之间的"通用语言"，避免"你说的库存和我理解的库存不是一回事"的经典冲突。
- 支撑架构决策：需求中的性能指标、并发量、数据一致性要求，直接决定架构风格（如微服务vs单体）、缓存策略、数据库选型。
- 提供验证基准：需求基线是后续架构评审、测试验收、变更控制的唯一依据。
需求分析不是一次性的"需求调研"活动，而是一个持续迭代的过程。在敏捷开发中，需求以用户故事的形式持续涌现，但架构师必须在每个迭代周期开始时，对需求池进行"架构影响评估"，确保技术债不会因需求快速变化而失控。
3.2 需求捕获与建模方法
3.2.1 用例图：从用户视角定义系统边界
用例图（Use Case Diagram）是UML中用于描述系统功能与参与者关系的视图。它回答两个核心问题：谁在使用系统？系统提供哪些价值？用例图的关键要素包括：
- 参与者（Actor）：与系统交互的外部角色，可以是人、外部系统或定时器。例如"仓库操作员""WMS外部系统""定时任务"。
- 用例（Use Case）：系统提供的一个完整功能单元，必须对参与者产生可观察的价值。例如"创建入库单""执行库存盘点"。
- 关系：包含（include）表示公共步骤抽取，扩展（extend）表示可选行为，泛化（generalization）表示用例或参与者的继承。
绘制用例图时，架构师应避免两个极端：一是用例过粗（如"管理库存"），导致无法指导设计；二是用例过细（如"输入商品条码"），退化为界面操作清单。一个良好的用例应包含前置条件、主成功场景、扩展场景、业务规则。例如"创建入库单"用例的主场景包括：操作员扫描到货商品→系统校验采购单→生成入库建议→操作员确认上架位置→系统更新库存台账。
3.2.2 用户故事：敏捷语境下的需求切片
用户故事（User Story）是敏捷开发中捕获需求的标准格式："作为<角色>，我希望<功能>，以便<价值>"。与用例图相比，用户故事更强调价值导向和对话驱动。一个高质量的用户故事应满足INVEST原则：
| 原则 | 含义 | 示例（智能仓储） |
|---|---|---|
| Independent | 故事之间尽量独立，便于排期 | "上架推荐"不依赖"波次规划" |
| Negotiable | 故事是对话的起点，而非合同 | 具体上架策略可协商 |
| Valuable | 对用户产生明确价值 | 减少操作员找货时间 |
| Estimable | 团队能估算工作量 | 需要明确涉及库位数量级 |
| Small | 能在1-3天内完成开发 | 拆分为"按SKU推荐"和"按批次推荐" |
| Testable | 有明确的验收标准 | "推荐准确率≥95%" |
用户故事与用例图并非互斥。实践中，架构师可以用用例图建立全局功能地图，再用用户故事细化每个用例的实现路径。例如，用例"执行库存盘点"可以拆分为用户故事："作为仓库经理，我希望系统生成盘点差异报告，以便快速定位账实不符的SKU。"
3.2.3 领域模型：统一业务语言与规则
领域模型（Domain Model）是业务概念及其关系的可视化表示，通常用UML类图或实体关系图（ERD）表达。它不关注技术实现（如数据库表结构），而是聚焦业务概念、属性、关联和业务规则。领域模型的价值在于：
- 识别核心实体：如"商品""库位""库存记录""入库单""出库单"。
- 定义实体关系：如"库位"与"库存记录"是1:N关系，"入库单"与"入库单明细"是聚合关系。
- 暴露业务规则：如"一个库位只能存放一种SKU（单品库位）"或"库存冻结期间不允许出库"。
构建领域模型时，建议采用事件风暴（Event Storming）工作坊：业务人员和开发团队一起，用橙色便签贴出领域事件（如"库存已锁定""出库单已创建"），用蓝色便签贴出命令（如"锁定库存""创建出库单"），用黄色便签贴出聚合（如"库存台账"）。这种方法能快速暴露业务规则中的矛盾点。例如，业务方可能同时提出"允许超卖"和"库存必须实时扣减"，这两个规则在领域模型中会产生冲突，需要进一步澄清。
3.3 需求优先级排序：MoSCoW方法实战
需求优先级排序是架构设计前必须完成的关键步骤。MoSCoW方法将需求分为四类：
| 优先级 | 全称 | 含义 | 架构影响 |
|---|---|---|---|
| Must Have | 必须有 | 系统上线的基本条件，缺失则项目失败 | 必须纳入架构核心，不可妥协 |
| Should Have | 应该有 | 重要但可临时绕过，需提供变通方案 | 架构需预留扩展点，但可延迟实现 |
| Could Have | 可以有 | 期望功能，有资源则实现 | 架构上保持兼容，不引入额外复杂度 |
| Won't Have | 本次不做 | 明确排除，避免范围蔓延 | 架构设计时明确边界，防止过度设计 |
MoSCoW排序不是简单的投票，而应基于三个维度综合评估：业务价值（对核心目标的影响）、交付风险（技术难度、依赖关系）、成本（开发工作量、运维成本）。架构师应引导干系人进行"价值-成本"四象限分析：高价值低成本的需求优先纳入Must Have；高价值高成本的需求需要进一步拆解或寻找简化方案；低价值高成本的需求直接归入Won't Have。
3.4 需求验证与确认：确保需求基线的质量
需求验证（Verification）是检查需求文档是否符合标准（完整性、一致性、可测试性），需求确认（Validation）是确保需求真正满足干系人期望。两者缺一不可。常用的验证与确认手段包括：
- 需求评审会：邀请业务方、架构师、测试负责人、开发代表参加，逐条评审需求条目。评审重点包括：需求是否明确（无"等""之类"模糊词）、是否可测试（有量化指标）、是否存在冲突（如两个需求对同一数据源要求不一致）。
- 原型走查：通过低保真或高保真原型，让用户直观感受系统行为。原型走查特别适合验证用户故事中的交互细节，例如"上架推荐"的界面展示逻辑。
- 验收标准定义：每个用户故事或用例必须有明确的验收标准（Acceptance Criteria），格式为Given-When-Then。例如："Given 库存中有100件商品A，When 操作员创建出库单数量为150件，Then 系统提示库存不足并阻止提交。"
- 需求追踪矩阵（RTM）：建立需求与架构组件、测试用例之间的映射关系，确保每个需求都有对应的架构实现和测试覆盖。
3.5 案例拆解：智能仓储管理系统的需求分析实战
我们以"智能仓储管理系统（WMS）"为例，完整展示需求分析全过程。项目背景：某电商企业拥有3个区域仓库，日均订单量5万单，SKU数量约10万。当前使用Excel管理库存，存在账实不符率高（3%）、拣货效率低（人均每小时80件）、库存积压严重等问题。目标是在6个月内上线新WMS系统，将账实相符率提升至99.5%以上，拣货效率提升至人均每小时150件。
第一步：需求捕获。通过访谈仓库经理、操作员、IT运维、财务人员，结合现场观察，我们收集到原始需求描述。例如："希望系统能自动推荐上架库位""盘点时能自动生成差异单""需要支持按批次先进先出"。这些描述存在大量模糊点，如"自动推荐"的算法逻辑、"先进先出"的粒度（按SKU还是按批次）。
第二步：用例图与用户故事建模。我们绘制了包含12个核心用例的用例图，包括"入库管理""出库管理""库存盘点""库位管理""报表分析"等。以"出库管理"为例，拆解出用户故事："作为拣货员，我希望系统按波次分配拣货任务，以便减少行走路径。"该故事的验收标准为："波次任务包含不超过20个订单，且按库位顺序排序。"
第三步：领域模型构建。通过事件风暴工作坊，我们识别出核心实体：商品（SKU）、库位（Location）、库存记录（Inventory）、入库单（InboundOrder）、出库单（OutboundOrder）、波次（Wave）。关键业务规则包括：
- 一个库位只能绑定一种SKU（单品库位），但一个SKU可分布在多个库位。
- 库存记录包含可用数量、冻结数量、在途数量三个字段。
- 出库扣减顺序遵循"先进先出"（FIFO）策略，按入库时间排序。
第四步：MoSCoW优先级排序。我们组织了干系人评审会，对32条功能需求进行排序。结果如下：
| 优先级 | 需求示例 | 排序理由 |
|---|---|---|
| Must Have | 实时库存扣减、波次拣货、盘点差异生成 | 直接影响核心指标（账实相符率、拣货效率） |
| Should Have | 智能上架推荐、库存预警、多仓调拨 | 提升效率但可通过人工变通 |
| Could Have | 大屏可视化看板、语音拣货 | 锦上添花，不影响核心流程 |
| Won't Have | 与供应商EDI对接、计费系统 | 超出本期范围，避免范围蔓延 |
第五步：需求验证与确认。我们进行了两轮原型走查。第一轮走查发现，操作员对"波次任务"的界面展示有异议——他们希望看到每个订单的优先级标签（如加急、普通），而原型中只显示了库位顺序。我们及时调整了用户故事，增加了"订单优先级展示"的验收标准。第二轮走查确认了所有核心流程。最终，我们建立了包含45条功能需求、12条非功能需求的需求基线，并生成了需求追踪矩阵。
结果与复盘：项目上线后，账实相符率提升至99.6%，拣货效率提升至人均每小时165件，超出预期目标。复盘时我们发现，成功的关键在于领域模型阶段充分暴露了"库存冻结"与"波次分配"之间的业务规则冲突，避免了开发阶段的返工。同时，MoSCoW排序帮助团队在6个月工期内聚焦核心功能，没有因范围蔓延导致延期。
3.6 常见误区与总结复盘
在需求分析与建模实践中，以下误区需要特别警惕：
- 误区一：用例图=功能清单。用例图的核心是"参与者-目标-场景"，而非简单的功能罗列。如果用例图没有描述前置条件和业务规则，就无法指导架构设计。
- 误区二：领域模型=数据库设计。领域模型关注业务概念和规则，数据库设计关注存储和性能。过早引入数据库外键、索引等细节，会污染业务语言。
- 误区三：MoSCoW排序由业务方单方面决定。架构师必须提供技术可行性评估，例如"智能上架推荐"虽然业务价值高，但需要机器学习算法支持，在6个月工期内风险较大，应降级为Should Have。
- 误区四：需求验证只做一次。需求验证应贯穿整个项目周期，尤其在架构设计完成后，需要重新审视需求是否被架构正确覆盖。