需求分析心得
我们在之前几周完成了我们团队项目-楹联数字博物馆的需求分析，然后总结了一篇需求分析文档。我在这里谈一谈我们做的需求分析的心得体会。
首先，最重要的一个问题就是，为什么要做需求分析，或者说需求分析的意义是什么？每个人对这个问题可能都会有不同的体会。我的看法是，需求分析的意义在于准确无歧义地表达项目需要交付的产品，并且获得需求方的认可，从而为整个项目建立一个基准。指望需求不变化是几乎不可能的，不管是开发者还是需求方都有可能随着项目的进展提出变更的需求，所以需求分析（及变更管理）的目标不是定义一个不会再改变的需求，而是从开发开始到项目结束，双方对于需求（包括变更后的）的认知都是一致的。
比如项目初期形成的需求分析中有这样一段描述：“应用系统能够根据预先定义的个性化模板，定期自动对每条用户的数据生成对应的pdf报告文件，并发送到在用户信息中预先设定好的电子邮箱中。”
针对这条需求，开发人员找到了一个自动生成pdf文件的插件，这个插件会读取一个xml模板，然后根据传入的数据生成pdf文件。一段时间后，功能做好了，用户的项目经理看了生成的pdf觉得不错，项目进展顺利。
可是，到了阶段验收的时候，用户组织了一段时间的试用，对这个功能大家都觉得不满意，因为普通用户根本不会编辑xml模板，觉得很麻烦，而且容易出现格式错误。这时，用户提出应该提供一个编辑界面，让用户以所见即所得的方式来编辑模板，这也是很自然的。
问题就来了：开发人员认为这是对需求的变更，需求里没有提到要做这么个界面嘛！这样会导致项目的进度、预算都需要调整，也许有人还会要求用户增加开发费用。而用户会认为这是开发的工作没做好，怎么能做个功能出来让用户自己编辑xml呢？一百个用户里也难找出一个用户知道xml是啥东西，更别说编辑它了。所以双方就会在这个问题上纠缠不清。而这只是整个项目中很小的一块需求，一叶而知秋，其他部分的问题也肯定少不了。
由此可知，需求分析是如此的重要。如果需求分析做不好，那么不管你开发的多么快多么好，最后得到的结果也不可能是一个让双方都满意的结果。
一、深刻理解业务
我们开发人员在和用户进行需求分析的时候，一定要先理解需求方的业务是干什么，我们不能有技术人员只需要知道技术就行了这种想法，如果我们不知道不理解对方的业务，又怎么能做出一个让对方满意的结果呢，在之前的需求分析中，我们小组成员学习了大量的楹联相关知识，比如说楹联的分类啊、楹联的音律啊、楹联的背景、楹联的起源等等，也学习了他们楹联协会的一个申请加入会员、会员写楹联、会员之间交流心得体会等等的一些流程。这样我们就可以尽可能的用程序模拟出他们的这样一个业务。
二、充分和用户沟通
首先要搞清楚你有哪些用户，他们之间的关系是怎样的。有句老话叫众口难调，用户之间的观点也会有冲突。比如高管希望采集的数据越多越好，现在用不上将来可能弄个数据挖掘工具就突然有奇效了也说不定；负责采集数据的一线用户当然希望数据越少越好，只要自己够用就行了。比如我们楹联数据库的录入就需要他们湖南省楹联协会的支持，其中很大一部分的楹联数据可能需要通过书籍的扫描转化成PDF然后传进楹联数据库，这是一个比较庞大的工程，负责录入数据的用户当然是希望去掉这部分功能，但是我们如果完全听这一部分用户的意见那这个项目也不要做了。所以在一个项目里，需求讨论会上往往会有各种各样的声音。我们需要听取各种声音然后得出一个自己的需求分析报告。
三、具备深厚的技术背景和严谨的思维
需求分析是业务和技术之间的桥梁，需求文档是一种对用户的承诺。在写需求文档的时候，就需要需求分析人员有相当的技术背景，了解每个需求对应的实现途径、难度、和大致工作量，并且能够把它以一种业务和技术人员都能无歧义理解的严谨表达方式进行描述。当然，这是建立在前面与用户（包括技术人员）充分沟通的基础之上的。
写文档就是考验需求人员的文字功底，有时候一句话、一个字都需要反复推敲，一不小心就有可能给自己挖坑，有点做律师的感觉，要让业务和技术都看明白的确不容易。我们是先和我们的项目指导老师商量暂定了一个需求，然后做出来一个项目原型之后，再和他们湖南省楹联协会的会长开的一个会讨论最后的需求。见识到了甲方的需求确实是需求永无止境，看到一个想法觉得不错就会提到需求里面去，根本不考虑能不能实现。。。由于时间的原因，他提的一些需求压根就不现实，估计以后还得是老师手下的研究生来做。