需求分析的核心目标：明确业务目标、识别干系人、定义系统边界、确定功能与非功能需求

说实话，我见过太多项目翻车，根源都在需求分析这一步没走稳。你想想看，地基都没打牢，楼盖得再漂亮也是白搭。今天咱们就聊聊需求分析的四个核心目标，这些都是我踩过坑之后才真正理解的。

一、明确业务目标——别让技术人自嗨

我刚开始带项目那会儿，犯过一个特别蠢的错误。客户说“我们要做个电商平台”，我二话不说就开始画架构图、选技术栈。结果做了三个月，客户一看说：“我要的是B2B的，你给我做成B2C了。”——嗯，这就是典型的没搞清楚业务目标。

业务目标说白了就一句话：这个系统到底要帮谁解决什么问题？

我个人习惯，在需求阶段一定会追问三个问题：

• 现状是什么？——现在没有系统的时候，业务是怎么跑的？
• 痛点在哪里？——哪些环节效率低、成本高、容易出错？
• 期望的收益是什么？——上线后希望看到什么变化？

你看，目标一旦明确，后面所有的设计都有了判断标准。这个功能要不要做？看它是不是服务于这个目标。不做？那就砍掉。

二、识别干系人——谁说了算？谁在用？谁买单？

干系人识别这件事，我吃过不少亏。有一次做内部管理系统，我只跟业务部门聊需求，结果系统上线第一天，财务部的人直接拍桌子：“这报表格式不对，我们没法做账！”——原来财务部才是真正的关键干系人，我居然把他们漏了。

干系人通常分这么几类：

角色	关注点	典型问题
出资方/决策者	ROI、成本、时间	“这系统能省多少钱？”
业务负责人	流程效率、管理可控	“能不能实时看到数据？”
最终用户	易用性、响应速度	“操作会不会很复杂？”
运维团队	可维护性、稳定性	“出问题了怎么排查？”
合规/安全部门	数据安全、审计	“数据存储合规吗？”

为什么会这样？因为不同干系人的诉求往往是冲突的。业务想要功能多，运维想要系统稳，老板想要成本低。你作为架构师，得学会平衡。

三、定义系统边界——什么该做？什么不该做？

系统边界，说白了就是划清界限。哪些功能是系统内部的？哪些是外部系统负责的？数据从哪里来？到哪里去？

我曾经接手过一个项目，需求文档写了200页，什么功能都想做。结果呢？开发了半年，连核心流程都没跑通。后来我重新梳理边界，把非核心功能全部砍掉，三个月就上线了。

定义边界时，我一般用这个方法：

1. 画上下文图——系统是一个黑盒，只画它和外部系统的交互。
2. 明确输入输出——系统接收什么数据？产出什么结果？
3. 标记外部依赖——哪些功能依赖第三方服务？哪些是自研？

四、确定功能与非功能需求——功能是骨架，非功能是血肉

功能需求大家都懂，就是“系统能做什么”。比如“用户能下单”、“管理员能查看报表”。但非功能需求，很多人容易忽略。

非功能需求，说白了就是“系统做得怎么样”。包括：

• 性能——并发量多少？响应时间多长？
• 可用性——全年可用时间99.9%？还是99.99%？
• 安全性——数据加密？权限控制？防SQL注入？
• 可扩展性——未来用户量翻10倍，架构扛得住吗？
• 可维护性——代码好不好改？日志好不好查？

我见过最典型的翻车案例：一个系统功能做得特别全，但上线第一天就崩溃了。为什么？因为没做性能测试。客户说“大概100人同时用”，结果上线当天来了1000人，直接宕机。

五、总结一下

需求分析的四个核心目标，其实是一个递进关系：

1. 先搞清楚为什么做（业务目标）
2. 再搞清楚谁说了算（干系人）
3. 然后划清做什么不做什么（系统边界）
4. 最后细化到什么程度（功能+非功能）

你想想看，这四个问题都回答清楚了，需求分析才算真正到位。否则，后面所有的设计、开发、测试，都是在沙滩上盖房子。

嗯，今天就聊到这儿。下一章咱们聊聊“如何高效获取需求”，我会分享一些我在访谈和调研中积累的实战技巧。