在前几天看到一篇博客《如何写出让自己满意的代码》中，有读者在评论中提到了用户需求不确定导致在总体设计阶段总是无的放矢的问题。在产品设计设计中，需求分析当然是非常重要的，甚至在某些情况下比总体设计还更重要。那么，如何理解需求分析呢？

Google一下关键字“需求分析”，网上已经有很多相关的文章了，有不少已经写得像教科书一样全面准确，还提供了一些最佳实践的分类方法。我这篇就从个人经验方面谈一点自己的体会好了。

首先，最重要的一个问题就是，为什么要做需求分析，或者说需求分析的意义是什么？每个人对这个问题可能都会有不同的体会。我的看法是，需求分析的意 义在于准确无歧义地表达项目需要交付的产品，并且获得需求方的认可，从而为整个项目建立一个基准。指望需求不变化是几乎不可能的，不管是开发者还是需求方 都有可能随着项目的进展提出变更的需求，所以需求分析（及变更管理）的目标不是定义一个不会再改变的需求，而是从开发开始到项目结束，双方对于需求（包括 变更后的）的认知都是一致的。

这样说可能有点抽象，我们可以来拿一个例子进行说明。比如项目初期形成的需求分析中有这样一段描述：“应用系统能够根据预先定义的个性化模板，定期自动对每条用户的数据生成对应的pdf报告文件，并发送到在用户信息中预先设定好的电子邮箱中。”

针对这条需求，开发人员找到了一个自动生成pdf文件的插件，这个插件会读取一个xml模板，然后根据传入的数据生成pdf文件。一段时间后，功能做好了，用户的项目经理看了生成的pdf觉得不错，项目进展顺利。

可是，到了阶段验收的时候，用户组织了一段时间的试用，对这个功能大家都觉得不满意，因为普通用户根本不会编辑xml模板，觉得很麻烦，而且容易出现格式错误。这时，用户提出应该提供一个编辑界面，让用户以所见即所得的方式来编辑模板，这也是很自然的。

问题就来了：开发人员认为这是对需求的变更，需求里没有提到要做这么个界面嘛！这样会导致项目的进度、预算都需要调整，也许有人还会要求用户增加开 发费用。而用户会认为这是开发的工作没做好，怎么能做个功能出来让用户自己编辑xml呢？一百个用户里也难找出一个用户知道xml是啥东西，更别说编辑它 了。所以双方就会在这个问题上纠缠不清。而这只是整个项目中很小的一块需求，一叶而知秋，其他部分的问题也肯定少不了。

这里面到底是用户不讲理，还是开发人员偷懒？其实都不是，我觉得问题出在需求定义得不严谨。如果开发人员在需求分析过程中和用户交流过模板的格式问 题，用户会在第一时间明确模板编辑的需求，这样写出来的需求可能会是这样的：“应用系统能够提供pdf模板编辑功能，让用户以所见即所得的方式自行定义个 性化模板，根据该模板定期自动对每条用户的数据生成对应的pdf报告文件，并发送到在用户信息中预先设定好的电子邮箱中。”这样的需求就更严谨，事后出现 争议的问题就减少了。当然，你还可以在里面找出一些不够严谨的地方，比如“定期”是什么概念，固定一周一次还是一月一次，还是用户可以自定义，或者是提供 几个标准选项让用户自选？所有这些不明确的定义，都是需求分析过程中要重视的。除非你对于它的不确定性及其可能带来的最坏结果有充分的把握，否则忽略它就 会在未来给项目带来麻烦。