第二章 需求分析：把用户的话翻译成系统能懂的语言
很多人觉得需求分析就是“用户说啥我做啥”。这么想就太天真了。
我做了十几年项目，见过太多“用户满意交付，三个月后推翻重来”的案例。为什么？因为用户描述的是他眼里的症状，我们要诊断的是背后的病因。
这一章，我们就聊聊怎么把模糊的需求变清晰。怎么说白了——就是学会问“为什么”。
2.1 挖掘业务需求：别只盯着用户表面说的话
我说个真实的事。一次电商项目，运营提了个需求：“订单列表加个批量导出功能”。
如果你直接开发，那就踩坑了。
多问一句“为什么”，发现真相是：运营每天要核对500+订单的发货状态，原系统不能按“待发货”筛选，她只能手动翻页。导出到Excel后自己过滤。
我建议的解法是什么？不是加导出，而是加“按状态筛选”。工作量少一半，还能实时查看。
这就是需求捕获的核心——穿透表面语言，找到业务痛点。
2.2 需求挖掘的四个层次
我经验里，业务需求通常藏在这四个层次里。你挖到哪一层，决定了系统能走多远。
| 层次 | 用户表述 | 真实需求 | 挖掘方法 |
|---|---|---|---|
| 第1层 | “我要一个导出按钮” | 快速获取数据 | 问“导出后怎么用？” |
| 第2层 | “导出字段要包含收货地址” | 物流对账需要地址信息 | 问“地址参与什么流程？” |
| 第3层 | “每天导出两次” | 分波次拣货，业务节奏如此 | 问“为什么是这个频率？” |
| 第4层 | “导出格式要和XX系统一致” | 需要和外部系统做数据对接 | 问“对接的上下游是谁？” |
别笑。我遇到过从第一层直接跳进开发，做完了用户说“不对”。为什么？因为第三层和第四层的逻辑他没说，我也没问。
2.3 需求优先级排序：哪件事值得现在做？
资源永远有限，老板永远想要全部。排序不是技术活，是博弈活。
我个人惯用两套模型，组合起来效果不错。
模型一：价值-成本矩阵
把需求放进四个象限：
模型二：Kano模型（我简化版）
需求分三类：
- 基本型需求（不满足就投诉）：登录、数据不丢、响应别太慢。你不做，用户直接掀桌。
- 期望型需求（做得好用户夸）：搜索精确、操作流畅。用户会主动说出来。
- 兴奋型需求（没有无所谓，有就惊喜）：智能推荐、一键迁移。用户没想到，你做了就加分。
你看，优先级不能一刀切。核心业务功能（基本型）必须优先，哪怕成本高。而那些“锦上添花”、“老板面子工程”的兴奋型需求，我建议等到架构稳定后再做。
2.4 非功能性需求的识别
业务需求往往看得见摸得着。非功能性需求却常常被忽略——直到系统崩了才想起来。
我总结出四大典型非功能性需求，建议你在需求文档里明确定义。
| 维度 | 常见问题 | 我建议的量化方式 |
|---|---|---|
| 性能 | “系统有点慢” | PV/并发量/TPS 三个数字说清楚 |
| 安全性 | “数据要安全” | 加密等级、审计日志范围、认证方式 |
| 可用性 | “别老宕机” | SLA 99.9%? 还是 99.99%？成本差很远 |
| 扩展性 | “以后可能要加功能” | 未来半年预计业务量增长比例 |
嗯，这里要注意。很多人直接把“高并发”当非功能性需求。但“高”是多少？500并发还是5万并发？技术方案选型完全不同。
我以前一个同事，客户说“用户量很大”，他直接上了微服务+分布式缓存。结果上线后日均PV才3000——单机MySQL跑得很欢。你说尴尬不尴尬？
所以我会在需求确认阶段就逼着业务方敲数字：
- 日活预估多少？峰值并发多少？
- 数据保留周期多长？总数据量多大？
- 允许的最大响应时间是多少（秒/毫秒）？
- 一年内有多少次线上变更窗口？
这些数字不落地，你做的架构就是盲人摸象。
2.5 需求分析的最终产出
说了这么多，落到纸面上应该有什么？我习惯至少包含三样东西：
- 需求列表（功能点 + 业务价值 + 优先级序号）
- 非功能性需求矩阵（量化指标，不接受模糊描述）
- 用例/用户故事（描述谁通过系统完成什么事，带来什么价值）
有了这三样，开发和测试都能明确边界。就算需求中途变了，你也有依据回溯——为什么当初定了A而不是B。
这一套流程下来，我敢说，项目后期至少减少50%的“这个功能我提过啊”的扯皮。
你记住：需求分析做得越细，后面改代码的次数就越少。这句话值多少钱？值你整个项目的加班时间。