4. 需求分析

需求分析这步，很多人觉得不就是读文档吗？

其实没那么简单。我做过不少项目，发现很多问题都出在这一关——需求没吃透，后面验证全白搭。今天咱们就聊聊怎么把功能需求和一致性要求梳理清楚。

4.1 需求分析到底在分析什么？

说白了，需求分析就是搞清楚两件事：

• 系统要干什么 —— 功能需求
• 系统得干得多好 —— 一致性要求

功能需求好理解，就是那些“用户能点这个按钮、系统返回那个结果”之类的东西。一致性要求呢？嗯，这玩意儿稍微抽象一点，它关心的是行为是否可预测、是否符合预期标准。

我个人习惯把这两类需求拆开来看，再合并到一起做交叉检查。为什么呢？因为我吃过亏。

4.2 功能需求的拆解方法

功能需求拆得好不好，直接决定测试用例的覆盖率。我常用的方法就三步：

1. 提取行为描述 —— 也就是从文档里找出所有“系统应……”的句子。
2. 明确输入输出 —— 每个行为都对应什么输入？预期输出是什么？
3. 识别边界和异常 —— 正常路径之外，非法输入、边界值、并发场景也得考虑进去。

举个例子，假设有这么个需求：“系统应支持用户通过邮箱注册”。拆开来看：

你想想看，如果不这么拆，测试的时候很可能漏掉“已注册邮箱”这种常见问题。

4.3 一致性要求的分类梳理

一致性要求比功能需求更隐蔽。我把它分成三类：

• 数据一致性 —— 同一个数据在不同模块、不同接口里的值是否一致？
• 行为一致性 —— 同样的操作在不同场景下是否产生相同的结果？
• 规范一致性 —— 实现是否符合行业标准、公司规范或协议要求？

我曾经在一个项目中遇到过数据不一致的坑。前端展示的订单状态是“已支付”，但后端订单表里状态还是“待付款”。原因就是缓存和数据库没及时同步。这种问题，如果不在需求分析阶段就识别出数据一致性要求，到了测试阶段根本补不全。

4.4 怎么把功能需求与一致性要求联动起来？

功能需求拆完了，一致性要求也列出来了。但它们是两张皮吗？当然不是。我个人习惯做一张映射表：

这张表做出来之后，你会发现一个功能可能对应多个一致性要求。这时候就要排序了——哪些是必须保证的？哪些可以容忍？

4.5 需求分析的输出产物

分析做完，得输出能用的东西。我一般交付以下三件套：

• 功能需求清单 —— 每个功能点拆成输入、操作、预期输出、边界条件
• 一致性需求矩阵 —— 标出每个一致性要求对应的检查点
• 风险标注 —— 哪些需求实现难度大、哪些一致性要求容易被忽略

这里我想说一个经验：别把所有东西混在一起。功能清单和一致性矩阵分开写，更容易让开发和测试人员快速定位。但一定要在两者之间建立可追溯的关系——也就是刚才说的那个映射表。

# 示例：功能需求条目格式
功能ID: FR-004
描述: 用户在个人中心修改头像
前置条件: 用户已登录
输入: 图片文件（jpg/png，≤5MB）
操作流程:
  1. 点击修改头像
  2. 选择文件
  3. 确认上传
预期输出:
  - 成功：头像更新成功提示
  - 失败：具体错误原因（格式/大小/网络）
关联一致性要求: 头像 URL 在各页面保持一致

4.6 整体流程一览

讲了这么多，来张图总结一下需求分析的核心逻辑。这张图我在很多项目里都用过，每次都能帮团队快速对齐思路。

这张图想表达的是：需求输入拆成两条线——功能需求往下走提取过程，一致性要求从分类开始。两者最终汇聚到输出成果上。这里没有交叉箭头，因为在实际项目中，功能需求和一致性要求是并行分析的，而不是串行的。

4.7 避坑指南

最后分享几个我踩过的坑：

• 别绕开业务方 —— 我曾经以为文档已经够详细了，结果做出来的东西业务方根本不认。为什么？因为文档里写的“用户”和他们想的不一样。所以，需求分析阶段一定要拉上业务方做一次确认会。
• 一致性要求别靠猜 —— 有人问：“规范一致性没写怎么办？”我的回答是：没写不代表没有。你得主动去查行业标准、公司规范。比如做支付相关的系统，PCI DSS 标准就是隐形的约束。
• 别忽略隐式需求 —— “系统应快速响应”——快速是多快？这种隐式需求很容易漏掉。我的做法是：凡是出现模糊用语的，都标记为待澄清，不给它滑过去的机会。
• 输出要可追溯 —— 功能需求和一致性要求之间建立映射，别做成两张表各管各的。否则后期需求变更时，那边改了一个功能点，这边的一致性要求没人更新，测试就全白做了。