3、需求分析与建模：使用用例图捕获功能需求、编写用例描述

好，咱们进入第三个主题。需求分析，说白了就是搞清楚「系统到底要干什么」。很多项目翻车，不是因为代码写得烂，而是从一开始就没搞明白需求。我见过太多团队，开发到一半才发现「哦，原来客户要的是这个」——那代价可就大了。

今天咱们聊两个核心工具：用例图（Use Case Diagram）和用例描述。一个负责画结构，一个负责写细节。两者配合，才能把需求说清楚。

3.1 用例图：一张图看懂系统边界

用例图是UML里最直观的图之一。它不关心系统内部怎么实现，只关心「谁」和系统交互，以及「做什么」。

我个人习惯，画用例图之前先问三个问题：

• 谁是用户？（角色/参与者）
• 用户想干什么？（用例）
• 系统边界在哪？（哪些事系统管，哪些不管）

举个例子。假设我们要做一个在线书店系统。参与者可能有：顾客、管理员、支付网关（外部系统）。用例包括：浏览商品、下订单、支付、管理库存等。

嗯，这里要注意：参与者不一定是人。外部系统、硬件设备、甚至时间触发器，都可以是参与者。我在项目中遇到过，有人把「数据库」也画成参与者——这其实不对。数据库是系统内部组件，不是外部交互方。

3.2 用例描述：把图变成文字

光有图不够。用例图只能告诉你「有什么功能」，但说不清「功能怎么执行」。这时候就需要用例描述了。

一个标准的用例描述，通常包含以下要素：

要素	说明	示例
用例名称	简洁描述功能	「下订单」
参与者	谁触发、谁参与	顾客
前置条件	执行前必须满足的条件	用户已登录、购物车不为空
后置条件	执行后的系统状态	订单生成、库存扣减
基本流程	正常情况下的步骤	1. 用户提交订单 2. 系统校验库存 3. 生成订单号 4. 返回成功
扩展流程	异常或分支情况	库存不足时提示用户

你想想看，如果没有这些描述，开发人员拿到用例图，只能猜「下订单」到底要做什么。我曾经接手过一个项目，用例图上就画了几个椭圆和火柴人，结果每个开发的理解都不一样——那叫一个乱。

3.3 避坑指南：我踩过的几个坑

讲几个实际教训，希望能帮你少走弯路。

3.4 实战：一个完整的例子

咱们拿「在线书店-下订单」这个用例，写一个完整的描述。你感受一下。

用例名称：下订单
参与者：顾客（主要参与者）、支付网关（外部系统）
前置条件：
  1. 顾客已登录
  2. 购物车中至少有一件商品
  3. 商品库存充足

基本流程：
  1. 顾客点击「结算」按钮
  2. 系统显示订单确认页面（含商品列表、总价、收货地址）
  3. 顾客确认信息并选择支付方式
  4. 系统生成订单（状态：待支付）
  5. 系统调用支付网关发起支付
  6. 支付网关返回支付成功
  7. 系统更新订单状态为「已支付」
  8. 系统扣减库存
  9. 系统向顾客发送订单确认通知
  10. 用例结束

扩展流程：
  2a. 库存不足：
    - 系统提示「某商品库存不足」
    - 顾客修改数量或移除商品
    - 返回步骤2
  5a. 支付超时：
    - 系统提示「支付超时，请重试」
    - 订单状态保持「待支付」
    - 顾客可选择重新支付或取消订单
  5b. 支付失败：
    - 系统提示支付失败原因
    - 顾客可选择其他支付方式

后置条件：
  1. 订单已生成（状态：已支付或待支付）
  2. 库存已扣减（仅当支付成功时）
  3. 顾客收到通知

你看，这样写出来，开发人员拿到手就知道「每一步该做什么」，测试人员也能根据流程写测试用例。说白了，用例描述就是需求和代码之间的桥梁。

3.5 什么时候该画用例图？

我个人经验，不是所有项目都需要完整的用例图。如果你在做一个小工具，或者一个内部API，用例图反而显得多余。但如果你面对的是一个多角色、多功能的复杂系统，用例图就是必需品。

我建议在以下场景一定要画：

• 系统有3个以上不同类型的用户角色
• 功能模块之间存在明显的依赖或扩展关系
• 需要和客户或非技术人员沟通需求
• 项目规模较大，需要分模块开发

嗯，最后说一句。用例图和用例描述不是一次写死的。随着项目推进，需求会变，用例也要跟着迭代。别想着一步到位，先画个大概，再慢慢细化——这才是工程化的做法。