在一个项目的历程中，需求工作的重要性不言而喻。在哈项目过程中，我们在需求分析中犯了不少错误，也总结了一些经验教训。现在我们就这些问题进行总结，并进行分析，以让大家从这些错误中吸取教训，避免犯相同的错误，做好需求分析工作(需求分析工作比较复杂，这些是我的个人看法)。
做好一个业务系统的需求，第一步就是要熟悉这个业务的相关知识。
只有熟悉相关的业务知识，才能和用户进行沟通，才能听懂用户所讲的问题。那么当作需求分析的人不了解其相关的业务知识或者和用户沟通有困难的时候应该怎么办呢？
1. 看相关的书籍。比如书店有相关业务知识的书籍，先从概念了解其相关的工作。读这种书，只需要略读，不必追求细节，只要能够了解大概既可。
2. 看国家、行业以及这个单位相关的文件，从文件中分析和了解相关业务。
3. 不耻下问。一开始，为了掩饰自己对相关业务知识的不了解，不懂装懂，和用户沟通一般都是一知半解，听到有些名词，只按照自己的理解去了解，不去问为什么，导致双方对同一个问题没有达成共识。
如果问甲方项目负责人感觉有困难的话，那么自己开辟多个渠道，多认识几个朋友，通过聚会，喝酒，聊天去了解对方单位的管理现状和业务情况。
4. 听其言，观其行。当相关人员在那儿讨论关于业务方面的事情之时，留意听，当听到自己感兴趣但不了解的东西的时候，插几句话，一起参与讨论，从讨论中加深了解，并注意观察在相关业务处室他们的行为，看看他们平常都在干什么，讨论什么，抱怨什么，从他们对语言和行为去了解业务。
5. 做需求分析的时候去了解。
了解相关人员的业务背景
一般主持项目的是这个单位的信息中心相关人员，他们会发表很多关于业务方面的见解。一开始，你会言听计从，因为你不懂其相关的业务知识，只能去听，而不会去怀疑。
但是事实情况是：信息中心讲这个业务的时候，是从自己的角度去理解的，他们不是天天和业务处室沟通，一些相关知识和经验已经过时或者是错误的，但是最终这个系统是业务处室去使用的，当按照信息中心的人要求做好后，当拿到业务处室的时候，他们居然对有些你以为很正确的名词，业务提出质疑，导致需求变更的产生。所以，做需求的时候，不要偏听偏信，并要知道这个系统最终的使用者是谁，谁最终要用这个系统处理业务。
了解与你做需求分析人员的业务背景和喜好，需求分析人员一定要了解系统要实现那些业务，从整体考虑问题。
比如哈项目信息中心的相关人员在供热方面有丰富的经验，他们对此业务可以比较清晰的解释其相关业务，并且一直会强调自己所知道的，这就造成一开始我们在供热方面投入了巨大的精力，对物业和房租没有太多的关注。导致需求不能平衡进行。这个问题也说明，在需求分析之前，项目人员还没有搞清楚自己到底要干什么，心中没有整体的目标，没有最终的目标导向。
多问为什么
当用户提出一个需求的时候，要多问为什么，要有怀疑精神，不能因为是用户提的，你就认为是正确的。在整个需求过程中，通过不断的吃亏和教训，我给自己总结出了相关的提问顺序和方式：
1. 有什么意义？
旨在了解这个需求的必要性。因为用户有时总会一激动，就有一些想法，当问这个问题的时候，如果这个需求只是一时兴起，那么这个需求在是否有意义的阶段就停止了。在和用户沟通意义问题的时候，用户也会意识到这个需求可能对这个业务系统意义不大。同时用户会自己放弃这个想法，而不是被需求分析人员拒绝，这是一个很圆通的处理方式。
2. 谁提出的？
因为一般都是和信息中心的人沟通需求，他们的需求来源可能是别的相关业务人员或者别的什么人，搞清楚这个需求的原始提出者有助于别人对系统的看法以及出发点。如果是下面最底层的业务人员提出的，你就需要考虑这个需求是否有普遍性，是他们这家遇到这个问题还是所有的业务人员都遇到这个问题。如果只是个别现象，那么就要按照这个系统所要达到的目标去说服用户，要优化管理，统一业务，规范业务行为。如果是普遍的问题，那么就要进一步沟通，搞清楚他们在什么情况下遇到这样的问题，理清这个问题，看看如何处理。
3. 开发出来能解决什么问题?
这也是了解业务的一个方式。当用户提出一个需求的时候，就要
刨根究底的问这么做能解决什么问题，在这样的沟通过程中，你就能了解其相关业务，还能从系统的角度给用户提出建议，显得更加专业。
4. 真的是这样吗？实际中也是这么做的吗？
这个提问让大家有点不接受，感觉不相信人，伤别人的自尊。但是当你问这样的问
题的时候，你会发现你问对了。用户会告诉你“大概是”，“也许”，“我觉得是这样”你会从回答中知道原来用户对自己的回答也拿不准，看来这个问题得谨慎。
这个问题不会让你气急败坏的跑到用户那里，告诉他：“上次你这么说的，但是下面根本就不是这样的”。
举个例子，关于空房也得在物业中算户数的问题，一开始物业处室振振有词：“空房也收物业费(从开发商那里收)，空房得算上户数，国家规定”。国家都规定了，马上实现吧，别犹豫。这个需求实现了，群里人开始说了，“不对呀，我们的物业户数多了，没把空房刨出去”。再去物业处室问，经典的回答开始了“嗯，我们企业现在很多人连物业费都收不上，空房的更不可能，虽然是国家规定，但是执行不下去，唉”。
对于需求，就要有一种抱着怀疑精神打破砂锅问到底的精神。
挖掘需求
“挖掘”这个词，感觉简直是没事找事，提的需求都做不完，还敢挖掘。
但是套用《无间道》里面的一句话：“出来混，迟早要还的”。是的，迟早要还。当用户提出一个需求，当你有更好的想法和更加完备的处理意见时，请提出，并协助用户更加全面和细致的考虑这个问题，因为现在不做，迟早你得补上(但是记住要有度，是在项目范围内的)。
所以，挖掘需求是有必要的。你现在挖掘，人家感觉你很专业，觉得这个团队的员工素质高，能为用户所着想。客户也会对项目组有好的评价(记住，不要不在乎评价，有好的印象，那么为我们争取下次的项目有很大的促进作用)，同时，利用用户的相关知识，开发出好用的软件，大家能从中得到快乐，也是我们项目组最大的成功。
报表的需求
当看到大张大张报表的时候，你会郁闷。但是如果把报表的需求做不好，项目有多长时间，你就会痛苦多长时间。针对我们在这次报表需求中遇到的问题，特总结如下，在后期的需求工作中，取得了良好的效果：
1. 报表名称准确吗？是否要统一考虑？(不要相信原来报表的名称，当这些报表
进入系统后，他们会发现它们的报表的名字多么的乱，就有想统一名称的强烈需求，不如一开始统一考虑，制定原则,“统计表”“汇总表”“明细表”它们是有区别的，请记住)
2. 此报表想用哪些条件进行统计？如果条件是时间，那么是时间段还是单独一
日期？如果是时间段，那么这个时间段的前后日期有没有特殊规定？
3. 报表四角遵循现在的格式还是根据现在报表做特殊考虑？报表统一格式遵循
(hrbgr\开发文档\01.系统需求\04.需求变更\071018-071121\报表共性问修改v071105)[报表四角不要忽视，对于正规单位，它有它的要求，要遵循]
4. 对于这个报表，有没有缺列，多列？有没有合并的列？有没有不合理的列？对
某些列的取值有没有特殊的要求？列的名称是否合理？(这个是挖掘需求的过程，在以前手工的操作方式下，数据量大，难以统计，有很多逼不得已的报表设计，用户上这个系统，就是要利用计算机的优势，进行快速大数据量的统计，在计算机的协助下，有些以前难以实现的统计和汇总成为现实。这也是我们要提供给用户的价值，用户没有用过系统的经验，直接会把报表给我们，我们不经过思考，就会照此实现，当用户用了一段时间，发现它们以前实现不了的统计在计算机中很容易实现时，就会提出要求，这也是我们产生了大量报表需求变更的原因。所以一定要问当初报表为什么这么设计，到底想从这些报表中得到什么样的信息，并且注意观察用户如何使用这个报表的，它们会用excel的高级筛选功能进行分类汇总，那么你就要提供建议，这个可以作为报表的一个条件，以后可以直接得到这些信息，有些报表以前是手工方式，有些数据要手工填写，比如“年计划..”,每年每个公司都不一样，那么当你考虑到让每个人公司每年填写这些数据不太妥当时，就要提出建议“这个列还要吗？”。还要讲清楚为什么要这么问，有什么困难，避免最后用户说，这个报表字段没有来源，去掉吧，那么又一个需求产生了，本可以一开始就可以避免的)
5. 有没有按照某个条件进行分页的要求？
6. 有没有分页合计的要求？
7. 在报表大小上有没有特殊规定？如果没有，按照每列可能填写的字数规定报表
大小，报表大小只有两种情况，a3或者a4。(这里涉及一个被我们忽略但是重要的问题，就是打印问题，就是我们只管做报表，不管这个报表打印的效果，结果报表打印惨不忍睹，在做报表的时候一定要注意打印的设置)
8. 对于这张报表，集团，子公司方面是否需要？如果需要，请设计具体的报表样
式上传到版本控制上.(设计的时候请注意条件设定)
9. 对于集团报表，是否有看子公司、分公司报表的需求？
10.对于数字保留几位小数有什么要求？是先四舍五入还是最终
得出结果再四舍五入？
11.如何对齐其中的字段，数字靠那边，文字靠那边，那些要居
中，单位是什么，当有多个单位时，四角用哪个单位？单位用汉字，还是英文字母？
需求的杀手：“我以为”
做需求，最大的问题就是以自己的经验和想象，自以为是，犯用想象和想当然的毛病，代替别人思考。需求是用户客观存在的需要解决的问题，这个一定要和相关的人员沟通，千万不能偷懒或者自作聪明。
当发现我们需求完成之后，用户告诉我们，不是这样的，我们第一句话是“我以为….”,请做需求的人以后禁止在做需求的时候用这句话，客观存在的事实不是“以为”出来的。 比如“我以为空房不收供热费”来考虑这个问题(这完全是自认为的，因为根据自己的经验，房子没人住，怎么可能收供热费呢？)，但是最终用户告诉我们，空房的供热费是要从开发商那里收取的。
比如“同一个房间两个单位掌握的使用面积应该一样”，这个确实应该是客观事实，这么想没有错，但是没有考虑这个单位实际的管理现状，同时，这也是上这个系统需要我们达到的目标之一。这也是上面讲到的沟通需求的时候，要多问为什么，不要拿自己的经验和想象去替代客观存在的事实。
所以，“我以为”是做需求的杀手，是自己找来的冤家，一定要和客户沟通，哪怕这个问题你认为及其明显，也要问出自认为很简单的问题，你会发现这个简单的问题背后可能不是那么简单。
从以上的总结中，你会发现，做需求的人应该是个“怀疑主义者”，怀疑一切，质问一切，要有“打破砂锅问到底”的精神，脸皮要厚，简单的问题也要敢于发问。(但是这个简单的问题也要有度,不要问“为什么你要收供热费”这样的问题)。
要有从只言片语中了解信息的能力，分析的能力，思考的能力，沟通的能力，还有文字表达的能力。
需求的书写
说到文字表达能力，那就是如何把自己脑子中所认识到的事情清楚的写给别人(这个其实很不简单，我本人能力有限，只能谈谈我自己的感受)
1. 首先，自己要清楚自己要讲的问题，这是根本。有些人一知半解就开始写，看得人也一知半解，最后做出来的东西就是不对的。
2. 不要吝惜笔墨。犯这个毛病我感觉有个主要原因，就是环境问题。需求分析者每天都在用户的环境中，有些东西对于他成为默认的事情了，他会把这些默认的东西给省略，以为别人也应该知道这些。但是，开发人员没有这个被省略的重要信息，结果造成需求的误解。所以需求要有主谓宾，什么东西在什么时机要做什么，得到的结果是什么，对结果有什么具体要求，什么方式出现，出现的样子是什么样的，有什么要求(就是不断沟通，把所有细节问个清楚的过程，不说清楚，要等到说清楚为止)，条理清晰的表达出来。不要说“做个查询”，这是很差劲的需求。开发人员应该拒绝这样的需求。“有哪些条件，是否联动，那些做成选择项，选择项的默认值是什么，这些条件的前后顺序怎么安排…..”，对于一个查询需求，起码要确定这些问题才能动手去做。
3. 关联关系。当这个需求和脑子中的另一个需求有关系的时候，请说清楚，这个需求和另一个需求有相关联的关系。因为需求分析者要从整体把握需求，提醒开发者注意其中的一些关联关系。
4.需求的语言尽量用短句，不要用长句。并且要注意行文方式，该打引号的地方要打引号，不要写成一堆，要1，2，3这样一条条的去写。写完自己得读一遍，看看有没有歧义句，掌握这些信息是否能够做出你想象中的功能，如果某个地方不提醒，是否会遗漏等。
需求的确认
当你的朋友让你做出一些承诺，你会随口说说，因为说说话总不会有什么大的责任。但是当他把这些承诺整理成文，让你签字画押时，你会重新考虑一下你说的这些话，开始认真起来。同理，对于需求，不要认为用户说了，写成需求，自信满满的觉得写得没有问题发回去修改，一定要签字确认，这其实就是上述的心理过程。这么做，用户会开始重视我们的需求，很多时候还能提出一些意见和错误，这就成为了一个比较有公信力的需求。
其实，做需求分析是个很难的工作，没有什么灵丹妙药能够很好的解决需求分析，这取决于需求分析者的经验，悟性，学习能力，沟通能力，分析能力，思考能力，甚至做人的方式和方法，上面只是一些个人经验的总结，而且只是需求分析中很简单的部分。
需求的跟踪
整个项目的主体过程，其实就是在产生需求，实现需求，验证需求，结束需求的过程。我们需要跟踪这个过程，跟踪不是代表不相信，而是让需求和进度能把很好的把握。
在这个项目中，我们做到了每个变化都有需求变更文档的要求，这为我们修改操作说明书，详细设计修改，数据库的修改都提供了一个坚实的基础。所以，无论需求变更多么的小，多么的简单，请坚持把它记录下来，一定不要相信自己的记忆力。
当把需求下发下去后，开发组会进行实现，实现的过程中就会涉及程序的改动，文件的改动等。这些改动需要被详细记录下来，在这个项目中，我们专门建立了这么一个文件，用来记录每个星期需求所带来的文件变化，并把这些文件和需求变更放到一起，如果有一天我们发现某个需求带来了意想不到的影响，我们总可以很快速的知道当时我们修改了什么，这样的形式有诸多的好处，最主要的好处大大的提高工作效率。我希望以后的项目能够延续这样的做法。
需求实现完，要通知用户，告诉那个需求已经实现完，而不是只管实现上传，这是需求分析人员的责任和义务，应该这么去做。需求的跟踪会涉及到一些沟通问题，关于沟通我们将作为一个专题去进行讲述。
我们的团队需要提高我们的需求分析能力，因为需求的质量在很大的程度上决定了项目的质量。我们应该学习更加先进的表达需求的方式，树立正确的需求观念。
最后，用一句话来表达我的看法“用户的需求是不变的，变的只是我们对需求的理解”。
作者：阿斯木
2008年3月17
你可以使用这个链接引用该篇文章 http://publishblog.blogchina.com/blog/tb.b?diaryID=6668120