第三章 需求分类与建模：功能性需求与非功能性需求、业务规则、数据需求，以及如何使用用例图进行建模
好，咱们进入第三章。说实话，需求分析这个阶段，最怕的就是「一团乱麻」。你想想看，客户说了一堆，产品经理记了一堆，开发一看——「这到底要我做什么？」
我个人习惯，拿到一堆原始需求后，第一件事不是急着写文档，而是先分类。就像整理衣柜，你得先把衣服分成「上衣、裤子、袜子」，才能知道怎么叠、怎么挂。需求也一样，分好类，后面的建模工作才能有条不紊。
3.1 功能性需求与非功能性需求
这是最基础、也最容易混淆的一对概念。我见过不少团队，把「系统响应要快」写进了功能列表里——嗯，这其实是个典型的非功能性需求。
功能性需求，说白了就是「系统要做什么」。用户登录、下单支付、生成报表……这些都是功能。它描述的是系统对外提供的具体行为。
非功能性需求，则是「系统做得怎么样」。性能、安全性、可扩展性、可用性……这些不直接对应某个按钮或操作，但决定了系统的质量。
一个简单的判断方法：
如果需求可以用「系统能够……」开头，大概率是功能性需求。
如果需求可以用「系统应该……」开头，大概率是非功能性需求。
举个例子，我之前做过一个电商项目。客户说：「用户下单后要能收到短信通知。」这是功能性需求。他又说：「短信通知要在3秒内送达。」这是非功能性需求。你看，同一个场景，两个维度。
| 类型 | 定义 | 典型例子 |
|---|---|---|
| 功能性需求 | 系统必须提供的功能或服务 | 用户注册、商品搜索、订单支付 |
| 非功能性需求 | 系统运行时应具备的质量属性 | 响应时间 < 2秒、支持1000并发、99.9%可用性 |
我的小技巧： 在需求文档里，我会用不同的颜色标记这两类需求。功能性需求用蓝色，非功能性需求用橙色。这样评审时，大家一眼就能看出哪些是「做什么」，哪些是「做多好」。
3.2 业务规则与数据需求
好，接下来聊两个容易被忽视、但特别容易踩坑的点。
业务规则，是业务层面的约束和逻辑。它不是系统功能，而是功能背后的「规矩」。比如：「满100减20」「VIP用户免运费」「同一手机号每天只能注册一次」。这些规则往往来自行业规范、法律法规或公司政策。
我曾经在一个金融项目中吃过亏。客户说「用户提现需要审核」，我们做成了「管理员手动审核」。结果上线后才发现，真正的业务规则是：「单笔提现超过5000元需要审核，5000元以下自动通过」。你看，业务规则没搞清楚，功能就做偏了。
数据需求，则关注系统需要管理哪些数据，以及数据之间的关系。比如用户信息、订单记录、商品库存……数据需求决定了数据库怎么设计，接口怎么定义。
注意： 业务规则和数据需求往往是交织的。比如「VIP用户免运费」这条规则，就要求数据模型中必须有一个字段来标识用户是否为VIP。所以，分析时一定要联动考虑。
我习惯用一张表来梳理数据需求：
| 数据实体 | 关键属性 | 关联规则 |
|---|---|---|
| 用户 | 用户ID、姓名、手机号、VIP等级 | VIP等级 >= 1 时免运费 |
| 订单 | 订单ID、用户ID、总金额、状态 | 状态为「已支付」才能发货 |
| 商品 | 商品ID、名称、价格、库存 | 库存 > 0 才能加入购物车 |
3.3 使用用例图进行建模
好了，分类做完了，规则和数据也理清了。接下来怎么把这些东西「画」出来，让团队一目了然？我推荐用用例图。
用例图是UML里最直观的一种图。它不关心内部实现，只关心「谁」和「系统」之间有哪些交互。说白了，就是画清楚「演员」和「用例」之间的关系。
举个例子，一个简单的电商系统，用例图大概长这样：
你看，这张图里，用户能「注册账号」「浏览商品」「下单支付」，管理员能「管理商品」。简单明了，谁都能看懂。
画用例图时，有几个要点：
- 演员：不是指具体的人，而是「角色」。比如「用户」和「管理员」是两个不同的角色，哪怕同一个人在不同场景下扮演不同角色。
- 用例：是一个完整的功能单元。不要拆得太细，比如「输入用户名」「点击登录按钮」这些步骤不应该作为用例，而「用户登录」才是一个用例。
- 关系：用例之间可以有「包含」和「扩展」关系。比如「下单支付」包含「选择支付方式」和「确认支付」两个子步骤。
避坑指南： 我曾经见过一个团队，把用例图画成了「流程图」，里面全是「如果……那么……」的分支。记住，用例图不是流程图，它只展示「谁做什么」，不展示「怎么做」。流程细节留给活动图或序列图去处理。
3.4 从分类到建模的完整思路
好，咱们把这一章的内容串起来。我个人习惯的完整流程是这样的：
- 收集原始需求：从客户、用户、文档中收集所有需求描述。
- 分类整理：分成功能性需求、非功能性需求、业务规则、数据需求四类。
- 提炼核心用例：从功能性需求中提取出「谁」要「做什么」，形成用例列表。
- 绘制用例图：把演员和用例画出来，标注关系。
- 补充细节：为每个用例编写用例描述，包括前置条件、后置条件、主流程、异常流程。
举个例子，假设我们有一个需求：「用户下单后，系统自动发送确认邮件，邮件需在5秒内到达。」
- 功能性需求：用户下单、发送确认邮件
- 非功能性需求：邮件5秒内到达
- 业务规则：只有已支付的订单才发送确认邮件
- 数据需求：订单表、邮件发送记录表
然后，用例图中就会出现「用户」这个演员，以及「下单支付」和「接收确认邮件」这两个用例。嗯，这里要注意，「接收确认邮件」其实是系统自动触发的，所以用例图中可以把它作为「下单支付」的扩展用例。
核心原则： 需求分类不是目的，目的是让团队对「要做什么」达成共识。用例图就是达成共识的最好工具之一。画图的过程，本身就是一次需求澄清的过程。
好了，这一章就到这里。下一章我们会深入聊一聊如何编写高质量的用例描述，以及如何用活动图来梳理业务流程。到时候我会分享一个我踩过的坑——关于「异常流程」的，保证让你印象深刻。