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

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

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

这样说可能有点抽象，我们可以来拿一个例子进行说明。

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

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

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

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

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

小结一下我的想法：在项目中，用户的字典里是单证、收入、报表、审核等，而开发人员的字典里则是键值、索引、按钮、事件这些，而需求分析就像是一位翻译，把用户的语言和开发人员的语言融合到一起，让双方准确理解对方的意思，从而在开始开发工作之前让双方都真正明白对方的思路。

对于需求分析中关键的因素，我自己的体会主要有如下三点：

一、深刻理解业务

需求分析人员需要对用户的业务有非常深刻的理解。所谓非常深刻的理解，就是说你能和用户的管理层就他们的业务问题谈笑风生。如果做金融产品不懂风险管控，做论坛不懂SEO，做人事系统不懂组织行为，如何能对业务有深刻的理解呢?

有人看到这里要说了，用户给我讲明白需要做什么功能就行了，我对他的行业了解那么深有什么必要呢?我想说的是，做需求分析也是分很多层次的，层次越高，需要对业务的理解越深。

我再举一个例子吧。某个项目要开发一套企业管理系统，客户是一个企业集团，下属很多分公司，都在做多条产品线业务，集团对分公司的业务管理一盘散沙的问题很头疼。之前的做法是每个分公司每个月底将每条产品线的业务报表传真到集团，然后集团进行业务统计。现在客户提出的需求是，在每个分公司都部署一套和集团一样的业务管理系统，并在集团的平台中做一个数据上报模块，让各个分公司都可以从自己系统中导出电子版数据并上传给集团，从而提高接收和统计的效率。

“还可以”的需求分析能够把这个需求准确描述，严谨定义，让开发人员开发出用户满意的功能。“比较好”的需求分析则可以更进一步，和用户探讨是否可以做成一套大集中的系统，分公司无须上报就可以让集团随时看到各个分公司的业务状况，从而杜绝虚报瞒报数据的问题。“更好的”需求分析也许可以和用户探讨通过信息系统的支持实现矩阵化的业务管理，在不改变组织结构(因为组织结构问题已经超出需求分析的范畴，甚至超过了项目范围了)的情况下，提高集团对各条业务线的宏观管理能力，从而更好地落实集团对于各条产品线的战略。

也许有人还有“更更好的”业务分析，但你可以看到，越深入业务的分析结果对于用户的价值越大，用户对整个开发团队的认可程度也会更高。这对于项目的成功是非常重要的。如果客户很感谢你提出了让他能加强业务管控能力的方案，他还会和你纠缠菜单的颜色够不够好看么?

二、充分和用户沟通

首先要搞清楚你有哪些用户，他们之间的关系是怎样的。有句老话叫众口难调，用户之间的观点也会有冲突。比如高管希望采集的数据越多越好，现在用不上将来可能弄个数据挖掘工具就突然有奇效了也说不定;负责采集数据的一线用户当然希望数据越少越好，只要自己够用就行了。有些业务部门不希望自己的业务数据被太多人知道，有些项目甚至会让一些部门失去权力，一些领导丢掉职位。所以在一个项目里，需求讨论会上往往会有各种各样的声音。声音后面是立场，立场后面是利益。缺乏经验的需求分析人员很容易迷失在这些声音里，最后做出来的需求成了四不像，而这正是某些用户希望看到的结果。

这时候怎么办呢?老码农俺有一个祖传秘方：找用户最大的领导讨论项目的整体思路，然后按大领导的意见把用户需求筛选一遍，凡是和大领导思路明显冲突的一律扔到一边，把符合大领导思路的那些需求充分细化。啥叫大领导?不是什么IT部经理、信息处处长、客户项目经理之类的，而是能拍板决定和这个项目相关的业务问题的人，比如做人事系统，大领导至少是人力总监，做财务系统至少是财务总监，当然能再往上让一把手积极参与进来就更好了。和大领导讨论的过程，既是了解大领导思路的过程，也是筛选需求的过程，更重要的是，获取大领导支持的过程。有了大领导的支持，再开会的时候，底下吵吵嚷嚷，你也能气定神闲，胸有成竹。

有人可能又要嘀咕了：大领导你想见就见，你以为自己是谁啊?这就又联系到我刚才谈的第一个问题，对业务理解的深度。项目启动的时候，大领导一般例行是要接见一下项目组的，你也会给大领导留下一个印象。如果你张口闭口就是数据库、表单、Java框架什么的，大领导和你没有交集，自然懒得见你，要是你能聊到们最大的竞争对手在这个项目相关的业务领域有哪些优势劣势，国外的业务管控经验等等，你也许能经常成为大领导的座上宾。所以说，对业务理解的深度是项目成功非常关键的。

和用户的沟通有多种形式，比如需求讨论会、高层访谈、用户讨论什么的。我觉得应该先做很多的一线用户讨论，问很多问题，把所有的业务环节都彻底摸清，顺便收集一些表单和数据作为需求分析的依据。然后再去做高层访谈，了解整体思路、战略、目标一类的宏观问题。需求讨论会一般在后期开，主要是针对某些争议比较大或者定义不清晰的问题，集思广益，实际上就是一种头脑风暴方法。在这些讨论中，需求分析人员都不应该只是做一个记录者，而应该多提问题和建议，用自己的思路去启发用户，大胆设想小心求证。但也要注意尊重用户的意见，不能觉得用户不懂技术所以我随便听听就行了，怎么实现是技术的事情，和用户没多少关系，这样往往在后期会出问题。

三、具备深厚的技术背景和严谨的思维

需求分析是业务和技术之间的桥梁，需求文档是一种对用户的承诺。在写需求文档的时候，就需要需求分析人员有相当的技术背景，了解每个需求对应的实现途径、难度、和大致工作量，并且能够把它以一种业务和技术人员都能无歧义理解的严谨表达方式进行描述。当然，这是建立在前面与用户(包括技术人员)充分沟通的基础之上的。

有的需求分析人员技术背景不是很强，是不是就做不好需求分析了呢?我觉得倒也未必，这时候就需要团队的力量了。如果有一个技术很强的开发人员作为后盾，能够和你搭档一起去讨论需求，并为你提供技术方面的意见，让你能充分发挥自己对业务的理解和沟通的能力，也会是不错的组合。

写文档就考验需求人员的文字功底了，有时候一句话、一个字都需要反复推敲，一不小心就有可能给自己挖坑，有点做律师的感觉是不是?要让业务和技术都看明白的确不容易，这里俺建议多画图，一张图有时候能抵几千字。什么流程图啊、数据流图啊、组织结构图啊、用户界面示意图啊什么的，能画图的地方就多画图，图加上文字，读者的理解就不容易跑偏。

最后，需求文档写完了，记得打印出来，核心用户一人给一本，告知几天内可以提出一次修改意见，只修改一次就会形成初始需求的定稿，以后再改要走变更控制流程。再印几本存档的，最后多一页签字确认页，让所有收到需求文档的用户最后都要签字确认，最后再给用户方的项目经理签字。有签字确认的存档就可以作为将来需求变更的依据了。

有人说，对方项目经理签字不就行了，为啥非要所有核心用户签字呢?因为领导们签字都是很慎重的。如果不需要签字，他拿着需求随便翻两下往抽屉里一扔，压根不会仔细看。但是如果三天后需要他一次性提出修改意见，没有修改意见就签字认可，这就不一样了。他就会仔细看，认真提出意见，因为很少有人会在自己没仔细看过的东西上签字的，对不?这样也是提前帮你检查了定义不够严谨、将来有可能产生争议的内容。所以通过这个过程，可以让核心用户对需求的理解和开发团队进行一次同步，真正形成需求的一个基准。

关于需求分析的体会，俺就说这么多吧。自己水平有限，唠叨了这么半天，也不知道有多少有用的东西，还请读者多多指正。最后其实俺还有一个想法，需求分析是项目经理义不容辞的工作，如果需求很复杂需要一个团队，项目经理也必须是这个团队的核心人员。关于项目管理俺也有一些体会，有时间再写一点东西，博读者一笑而已。各位看官，预知后事如何，且听下回分解。