第三章：需求建模与表达
说实话，很多团队做项目，需求阶段就埋下了大坑。我见过太多开发说「需求不明确」，产品说「开发理解错了」。其实问题出在哪？出在需求没有「建模」，没有「可视化」。今天我们就来聊聊怎么把模糊的想法，变成清晰的系统蓝图。
用户故事：不只是「As a...I want...」
用户故事（User Story）是敏捷开发里最常用的需求表达方式。但很多人把它写成了「功能清单」。我刚开始带项目时也犯过这错——写了一大堆用户故事，结果开发看完还是不知道要做什么。
一个合格的用户故事，要包含三个要素：
- 角色（Who）：谁在用这个功能？
- 功能（What）：他想做什么？
- 价值（Why）：做这个对他有什么好处？
标准模板：
作为<角色>，我想要<功能>，以便<价值>。
举个例子，别写「用户能搜索商品」。这太笼统了。要写成：
作为购物者，我想要按价格区间搜索商品，以便快速找到我能买得起的东西。你看，加了「以便」之后，开发就知道这个搜索功能的核心是「价格筛选」，而不是「模糊匹配」或「按销量排序」。
用户故事的「三C原则」
嗯，这里要提一个重要的原则。我在项目中踩过坑，后来才明白的——用户故事不是写完了就完事。它需要持续沟通。
- 卡片（Card）：故事写在卡片上，不要太长。一张卡片就是一个独立功能。
- 交谈（Conversation）：卡片背后的细节，靠面对面沟通。别指望文字能说清楚一切。
- 确认（Confirmation）：验收标准要写清楚。怎么才算「做完」？要有明确的测试点。
我的习惯：每个用户故事后面，我都会加一个「验收条件」列表。比如：
- 输入价格范围0-100元，只显示该区间商品
- 价格范围为空时，显示全部商品
- 输入非法字符时，提示错误
这样开发自测、测试验收，都有据可依。
用例图：把故事画出来
用户故事是文字，用例图是图形。为什么需要图？因为一张图能说清文字几百字都讲不明白的关系。我建议团队里，产品经理画用例图，开发看用例图，这样沟通成本能降一半。
用例图的核心元素就这几个：
- 参与者（Actor）：小人图标，代表用户或外部系统
- 用例（Use Case）：椭圆，代表一个完整的功能
- 关系（Relationship）：连线，表示谁和谁有关系
举个例子，一个电商系统的用例图，大概长这样：
参与者：购物者、管理员、支付系统
购物者 —— 搜索商品
购物者 —— 下单购买
购物者 —— 查看订单
管理员 —— 管理商品
管理员 —— 处理退款
支付系统 —— 处理支付你想想看，如果这些用文字描述，得写多少？但一张图，几秒钟就看明白了。
用例图实战：注意边界
画用例图最容易犯的错，是把系统内部操作也画进去。比如「用户登录后验证密码」——这不该出现在用例图里。用例图关注的是「外部可见的功能」，不是内部实现细节。
我曾经踩过的坑：有一次画用例图，把「生成验证码」「发送短信」都画成了用例。结果开发说「这图太乱了，根本分不清哪些是用户能看到的」。后来我学乖了——用例图只画用户能感知到的功能，内部逻辑用活动图或时序图去表达。
活动图：把流程走一遍
用例图告诉我们「谁做什么」，但没告诉我们「怎么做」。活动图就是来解决这个问题的。它像一张流程图，把业务逻辑的每一步都画出来。
活动图的基本元素：
- 开始节点：实心圆
- 活动节点：圆角矩形，表示一个操作
- 判断节点：菱形，表示条件分支
- 结束节点：实心圆加外圈
- 泳道（Swimlane）：把不同角色的操作分开
举个例子，下单流程的活动图：
[购物者] [系统] [支付系统]
| | |
v | |
[提交订单] ------> [校验库存] |
| |
[有货?] |
/ \ |
是 否 |
| | |
v v |
[生成订单] [提示缺货] |
| |
v |
[请求支付] ----------> [处理支付]
|
[成功?]
/ \
是 否
| |
v v
[完成] [退款]你看，这样一画，整个流程就清清楚楚。开发照着这个写代码，基本不会跑偏。
活动图实战：泳道的重要性
我建议每个活动图都加上泳道。为什么？因为不加泳道，你分不清「这个操作是谁做的」。比如「校验库存」是系统做的，「提交订单」是用户做的。如果混在一起，开发会问「这到底是我写代码，还是用户自己操作？」
小技巧：泳道的顺序，从左到右按「用户→系统→外部系统」排列。这样读起来最自然。用户先操作，系统再响应，最后调用外部服务。
三种工具怎么配合使用？
说了这么多，你可能想问：这三个东西到底怎么配合？我一般这样用：
- 先写用户故事：把需求拆成一个个小功能，每个故事独立可交付。
- 再画用例图：把故事归类，看看哪些参与者涉及哪些功能，理清边界。
- 最后画活动图：挑出核心用例，把它的业务流程画出来，指导开发实现。
说白了，用户故事是「需求清单」，用例图是「功能地图」，活动图是「流程导航」。三个工具层层递进，从模糊到清晰，从抽象到具体。
避坑指南
最后分享几个我踩过的坑，你遇到了可以绕开：
- 用户故事别写太大：一个故事最好能在1-2天内开发完。如果太大，拆成更小的故事。
- 用例图别画太细：用例图是给非技术人员看的，太细反而看不懂。细节留给活动图。
- 活动图别画成代码流程图：活动图关注业务逻辑，不是代码实现。别把if-else都画进去。
嗯，需求建模这件事，说白了就是「把话说清楚」。工具只是手段，核心是让团队所有人都对需求有一致的理解。你想想看，如果产品、开发、测试看到的都是同一张图、同一个故事，那沟通成本能降多少？
下一章，我们会聊聊怎么把这些需求模型转化成系统架构。到时候你会发现，前面这些建模工作，其实都是在为架构设计打基础。