一、需求分析入门：什么是需求分析、核心目标与系统设计中的位置
说实话，我见过太多项目死在需求分析这一步。
记得我刚带团队那会儿，有个项目做了三个月，代码写了两万多行。结果上线前一天，客户说：“这不是我要的东西啊。” 那一刻我整个人都懵了。后来复盘才发现，问题就出在需求分析阶段——我们根本没搞清楚客户到底想要什么。
所以今天这一章，咱们就来聊聊需求分析这件事。它听起来很基础，但恰恰是系统设计的命门。
1.1 什么是需求分析
需求分析，说白了就是搞清楚“你到底要做什么”。
很多人觉得需求分析就是“客户说啥我记啥”。嗯，我以前也这么想。但后来发现，客户说的往往不是他真正想要的。
举个例子：客户说“我要一个能下单的按钮”。你做了个按钮，他点了，订单生成了。但客户又说“不对，我要的是能批量下单”。你看，他一开始说的“下单按钮”，背后其实是“批量处理订单”的需求。
所以需求分析的本质是什么？是从用户的表述中，挖掘出真正的业务诉求。
需求分析 ≠ 需求记录
记录只是第一步，分析才是核心。你要问自己：用户为什么提这个需求？他背后的痛点是什么？
1.2 需求分析的核心目标
我个人习惯把需求分析的目标总结成三个词：清晰、一致、可行。
| 目标 | 说明 | 我踩过的坑 |
|---|---|---|
| 清晰 | 每个需求都要能被明确理解，没有歧义 | 曾经有个需求写“支持多种支付方式”，结果开发做了支付宝和微信，客户说“我还要银行卡转账” |
| 一致 | 需求之间不能相互矛盾 | 有一次需求里既要“实时同步”又要“降低服务器负载”，这俩本身就是冲突的 |
| 可行 | 在现有资源和技术条件下能实现 | 客户说要“毫秒级响应”，但数据源在海外，网络延迟就200ms了，这怎么搞？ |
你想想看，这三个目标缺一个，后面整个系统设计都会跑偏。
1.3 需求分析在系统设计中的位置
很多新手会问：需求分析到底算哪个阶段的事？
我的回答是：它是系统设计的起点，也是贯穿全程的线。
来看一张我常用的流程示意图：
业务想法 → 需求分析 → 架构设计 → 详细设计 → 编码实现 → 测试验证 → 上线部署
↑ ↓
└──────── 需求变更反馈 ──────────────────┘
看到了吗？需求分析不是做完就完事了。它会在后续每个阶段被反复验证和调整。
我的经验：在架构设计阶段，我至少会回头再看三遍需求文档。因为架构决策一旦做错，改起来成本极高。我曾经因为没仔细分析“数据量级”这个需求，选了关系型数据库做日志存储，结果三个月后磁盘就爆了。
1.4 需求分析常见的误区
这里我列几个自己踩过的坑，你注意避一避：
- 误区一：客户说什么就是什么 —— 客户说“我要搜索功能”，你得问清楚是全文搜索还是模糊匹配？搜索范围多大？响应时间要求多少？
- 误区二：需求越详细越好 —— 其实不是。太细的需求反而会限制设计空间。我建议先抓核心流程，细节可以迭代。
- 误区三：忽略非功能需求 —— 性能、安全、可扩展性这些，客户往往不会主动提。但你不问，后面就等着返工吧。
警告：我曾经接手过一个项目，需求文档写了200页，但全是功能描述。没有一条提到“系统要支持多少并发用户”。结果上线第一天，100个人同时访问，系统直接挂了。这就是忽略非功能需求的代价。
1.5 怎么做需求分析
嗯，这里我分享一个自己常用的四步法：
- 收集 —— 跟客户聊、看文档、观察业务流程。别光听，要去看他们实际怎么工作的。
- 整理 —— 把收集到的信息分类。我习惯用“功能需求”、“非功能需求”、“业务规则”三个维度来分。
- 验证 —— 把整理好的需求画成原型或者流程图，拿给客户确认。“你看，是不是这个意思？”
- 优先级排序 —— 哪些是必须做的？哪些可以后面再优化？我一般用MoSCoW方法（Must have, Should have, Could have, Won't have）。
说白了，需求分析就是一场和客户的深度对话。你问得越细，后面踩的坑就越少。
1.6 小结
这一章我们聊了需求分析是什么、它的核心目标、以及在系统设计中的位置。我个人觉得，需求分析做得好不好，直接决定了项目是“一次过”还是“反复改”。
下一章我们会深入聊聊如何收集和整理需求，包括用户访谈、问卷调查、用例分析这些具体方法。到时候我会拿一个真实的电商项目案例来拆解，你一定会觉得有用。
记住一句话：好的系统设计，从好的需求分析开始。