在项目中，用户的字典里是单证、收入、报表、审核等；
而开发人员的字典里则是键值、索引、按钮、事件这些；
而需求分析就像是一位翻译，把用户的语言和开发人员的语言融合到一起，让双方准确理解对方的意思，从而在开始开发工作之前让双方都真正明白对方的思路。
(引用：伯乐在线：老码农#关于需求分析的几点体会)

如图：

需求分析是很有必要的！

简而言之：

需求分析就是一份不懂代码的用户和不懂业务的开发者都能看懂彼此想法的文档。

开发者通过需求分析了解用户需要一个什么样的结果，而用户也通过需求分析明白开发者将会开发出一个什么样的软件出来。

故事#

在我们的项目开发过程中，发生并会经常发生如下的故事。

项目初期形成的需求分析中有这样一段描述：

应用系统能够根据预先定义的个性化模板，定期自动对每条用户的数据生成对应的pdf报告文件，并发送到在用户信息中预先设定好的电子邮箱中

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

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

开发人员认为：

这是对需求的变更，需求里没有提到要做这么个界面嘛!这样会导致项目的进度、预算都需要调整，也许有人还会要求用户增加开发费用；

用户会认为：

这是开发的工作没做好，怎么能做个功能出来让用户自己编辑xml呢?一百个用户里也难找出一个用户知道xml是啥东西，更别说编辑它了。所以双方就会在这个问题上纠缠不清。而这只是整个项目中很小的一块需求，一叶而知秋，其他部分的问题也肯定少不了。

其实都不是，问题出在需求定义得不严谨。

如果开发人员在需求分析过程中和用户交流过模板的格式问题，用户会在第一时间明确模板编辑的需求，这样写出来的需求可能会是这样的：

应用系统能够提供pdf模板编辑功能，让用户以所见即所得的方式自行定义个性化模板，根据该模板定期自动对每条用户的数据生成对应的pdf报告文件，并发送到在用户信息中预先设定好的电子邮箱中。

这样的需求就更严谨，事后出现争议的问题就减少了。

当然，你还可以在里面找出一些不够严谨的地方，比如“定期”是什么概念，固定一周一次还是一月一次，还是用户可以自定义，或者是提供几个标准选项让用户自选?所有这些不明确的定义，都是需求分析过程中要重视的。除非你对于它的不确定性及其可能带来的最坏结果有充分的把握，否则忽略它就会在未来给项目带来麻烦。

如何写出这样的需求分析文档呢？