需求经理必修课全文解说需求分析.docx
《需求经理必修课全文解说需求分析.docx》由会员分享，可在线阅读，更多相关《需求经理必修课全文解说需求分析.docx（62页珍藏版）》请在冰点文库上搜索。
需求经理必修课全文解说需求分析
我们应当怎样做需求分析
又到新年了，日历又要从2011年翻到2012年了，这使我有太多的感慨，进而勾起了对太多往事的回忆。
过去的10年，毫无疑问是中国软件业发展最快的10年。
当我们刚刚毕业的时候，还在使用VB、PB开发一些简单的数据库应用，而现在却几乎看不到它们的踪影，换来的是诸如J2EE和.NET这样的大型web应用。
而这期间，RUP、XP、敏捷开发、持续集成••••••一个接一个的新概念层出不穷，令人眼花缭乱。
现在想来，恍如隔世。
但更令我印象深刻而难以忘怀的，是我亲自经历的、亲眼目睹的、道听途说的一个又一个的软件项目，它们有的获得了成功，但更多的是令人沮丧的失败。
套用一下大文豪托尔斯泰体：
幸福的家庭都是一样的，不幸的家庭却各有各的不幸；幸福的软件项目都是一样的，不幸的软件项目却各有各的不幸；或者说，成功的软件项目都是一样的，失败的项目却各有各的问题。
我常常在想，我们的项目开发到底怎么了，进而把它们一个一个的剥开来深入分析，竟然触目惊心。
它们有的是需求的问题，有的是客户关系的问题，还有设计的问题、技术的问题、时间管理的问题、人员培养的问题••••••但归根到底更多的还是需求的问题。
需求分析既是一份体力活儿，更是一份技术活儿，它既是人际交往的艺术，又是逻辑分析与严密思考的产物。
正是我们在需求分析过程存在的巨大隐患，最终导致了那么多项目的失败。
也许你认为我在危言耸听，好吧，我来举几个典型事例分析分析吧。
我的第一个故事来自大名鼎鼎的东软。
我在2005年接一个项目的时候，听说这个项目之前是东软做的。
当时东软在做这个项目的时候，整个过程经历了10多次结构性的大变更，局部性的调整更是不计其数。
据说某天早上，客户对某个功能不满意，他们不得不对几百处程序进行修改。
之后客户对修改的内容还是不满意，又不得不将几百处修改重新改回来。
最后这个项目导致的结果是，整个这个项目组的所有成员都离开了东软，并似乎从此不愿涉足软件开发领域。
多么惨痛的教训啊！
我常常听到网友抱怨客户总是对需求改来改去，但客户对需求改来改去的真正原因是什么呢？
当我们对客户的需求没有真正理解清楚时，我们做出来的东西客户必然不满意。
客户只知道他不满意，但怎样才能使他满意呢？
他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。
如果我们明白了这一点，深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。
记住，当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。
我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。
当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。
第二个故事来自我自己的项目，一个早期的项目。
在这个项目中，客户扔给了我们很多他们目前正在使用的统计报表，要我们按照报表的格式做出来。
这些报表都是手工报表，许多格式既不规范，又很难于被计算机实现。
这些报表令我耗费了不少脑细胞，直到最终项目失败都没法完成。
这件事留给我的深刻教训是，不能客户怎么说软件就怎么做。
客户提出的原始需求往往是不考虑技术实现，基于非计算机管理的操作模式提出来的。
他们提出的很多需求常常比较理想而不切实际，毕竟人家是非技术的。
但我们作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑。
那种“有条件要上，没有条件创造条件也要上”的鲁莽行事，结果必然是悲惨的。
所以我们必须要基于技术实现去引导客户的需求。
同时，计算机信息化管理就是一次改革，对以往手工管理模式的改革。
如果我们上了信息化管理系统，采用的管理模式却依然是过去的手工模式，新系统的优势从何而来呢？
因此，我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理。
2007年，我参与了一个集团信息化建设的项目。
这个项目中的客户是一个庞大的群体，他们分别扮演着各种角色。
从机构层次划分，有集团领导、二级机构人员、三级机构人员；从职能角色划分，有高层领导、财务人员、生产管理员、采购人员、销售人员，等等。
在这样一个复杂场景中，不同人员对这个项目的需求是各自不同的。
非常遗憾的是，我们在进行需求分析的时候没有认真分析清楚所有类型人员的需求。
在进行需求调研的时候，总是集团领导带领我们到基层单位，然后基层单位将各方面的人员叫来开大会。
这样的大会，各类型的人员七嘴八舌各说各自的需求，还有很多基层人员在大会上因为羞涩根本就没有提出自己的需求。
这样经过数次开会，需求调研就草草收场。
我们拿着一个不充分的需求分析结果就开始项目开发，最终的结果可想而知。
直到项目上线以后，我们才发现许多更加细节的业务需求都没能分析到，系统根本没法运行，不得不宣告失败。
一个软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。
需求调研的初期需要召开项目动员大会，这是十分必要的。
但真正要完成需求分析，应该是一个一个的小会，1~3个业务专家，只讨论某个领域的业务需求，并且很多问题都不是能一蹴而就完成的，我们必须与专家建立联系，反复沟通后完成。
需求分析必须遵从的是一定的科学方法，而不是盲目的大上快上。
我的最后一个故事可能典型到几乎每个人都曾经遇到过。
我们的项目从需求分析到设计、开发、测试都十分顺利。
但到了项目进行的后期，快到达最后期限时，我们将我们的开发成果提交给客户看，客户却对开发结果不满意，提出了一大堆修改，而且这些修改工作量还不小。
怎么办呢？
加班、赶工，测试时间被最大限度压缩。
最后项目倒是如期上线了，但大家疲惫不堪，并且上线以后才发现许多的BUG。
需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。
以上这个事例，如果我们提早将开发成果给客户看，提早解决问题，后面的情况就将不再发生。
这就是敏捷开发倡导的需求反馈。
敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。
只有这样才能及时纠正需求理解的偏差，保证项目的成功。
以上的故事各有各自的不幸，各自都在不同的开发环节出现了问题。
但经过深入的分析，各自的问题最终都归结为需求分析出现了问题。
为了使我们今后的软件项目不会重蹈覆辙，似乎真的有必要讨论一下我们应该怎样做需求分析。
我们应当怎样做需求调研：
初识
很多需求分析的工作是从需求调研开始的，我们就从这里说起吧。
需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，更是一份技术活儿。
它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。
在一个阳光明媚的下午，项目经理带领着项目组成员，参加了客户组织的见面会，一个新的软件研发项目就这样开始了。
双方在一种友好的气氛中进行，相互寒暄，介绍与会人员，拉拉家常。
逐渐地，会议开始进入了正题。
初次接触客户，对于项目团队意义重大。
对方对你印象的好坏，今后如何与你交往，都在这个阶段被确定下来。
然而，在客户至上的今天，与客户保持适当的谦卑是有必要的，但过于的谦卑却常常给项目日后的进程带来风险。
为什么这么说呢？
过于的谦卑，处处都是诺诺诺，客户说什么就是什么，就会使客户变得非常强势。
这样的结果就是，客户提出了许多变态的、不太现实的、不合理的需求，而我们呢却是一味地服从，客户说什么就是什么。
最后我们做得很累，结果却不能让客户满意。
正确的做法是，我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。
如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。
这毫无疑问会形成一个良性循环，但要做到这一点并不容易，毫无疑问，在与客户接触初期的表现起到了极其关键的作用。
人与人交往，往往在接触的初期就决定了相互的行为方式，与客户交往也是一样。
起初的唯唯诺诺，客户说啥就是啥，必然造成客户不再关注你的意见，对你发号施令就可以了。
相反，起初展现出一位技术专家的姿态，能大方而得体地提出自己的意见，会使客户重视你的意见，甚至主动征求你的意见。
这一方面要求我们对自己要有足够的自信，另一方面也要有循循善诱的表达能力。
如果我们做到了这些，就会客户心目中形成一种威信，使项目向着一种良性的方向前进。
同时，这样的会议又是一个项目启动会议。
客户方领导要在会议上传达给与会代表一个清晰的信号，那就是与会代表今后要积极配合我们完成今后的工作。
这时候，我们要弄清，客户方有哪些角色，谁是这些角色的需求提出者与决策者。
这是什么意思呢？
在软件项目中，特别是管理型软件项目中，客户都代表的是一个群体，而不是个人。
他们代表的可能是一个单位、一个集团，甚至是一系列组织机构。
在这样一个群体中，他们按照职能被划分成了不同的角色。
拿一个单位来说，横向可能划分成不同的部门，财务部、销售部、采购部、生产部••••••不同的部门，由于业务的不同，对软件的需求自然是不同的，因此我们在进行需求调研的时候，什么部门的需求就应当跟什么部门谈。
同时，纵向又可以划分为多个层次，如高层领导、中层领导与基层人员，理解这些方面格外重要：
1.高层领导
高层领导关心的是宏观的目标，因此软件研发目标、宏观统计报表、决策支持功能，都应当与高层领导谈。
他们关系的都是宏观的问题，因此不要与他们谈那些细枝末节；
2.中层领导
中层领导关心的是具体的效益，即软件给各个部门信息化管理方面带来的效益，因此，中层领导是各项业务流程、功能模块的需求决策者。
他们关心功能的定义、业务流转的衔接、查询报表的设计，但不太关心一些具体的操作，以及一些具体业务流程的细节；
3.基层人员
基层人员是每一项业务流程的操作者，也是软件今后真正的使用者。
他们是真正了解你所要开发的软件的业务需求的领域专家，是你进行需求调研的重点对象。
但是，基层人员往往受到自身视野的局限，可能只清楚自己工作涉及的十分狭小的一个范围，因此我们需要努力寻找那些业务涉及面广，经验丰富，又有一定大局观的真正的专家。
另外，他们就是软件今后真正的使用者，让他们参加，会让他们成为今后软件推行的忠实支持者，对其他操作人员的指导者，益处多多。
而他们关心的则是每项操作的细节。
划分清楚角色，弄清楚每个角色的需求提出者与决策者，就是为了在今后的需求调研中找对正确的人，使今后的调研工作事半功倍。
另外，如果客户方是一个集团、一个多组织机构的政府机关、事业单位，需求的多元化问题必须引起我们的足够重视。
什么是多元化问题呢？
比如同样一个业务操作，在同一级别的A单位是这样操作的，而在B单位却是那样操作的。
需求的多元化往往会给今后的软件开发带来巨大挑战。
因此，我们要在需求调研阶段降低软件的多元化需求。
要解决这样的问题，首先应当从高层领导着手，提出规范化管理的口号。
同时，在进行需求调研时，尽可能地召集各个单位的代表在一起开会讨论。
同时，应当有高层领导，或者指定一个负责人，在出现分歧的时候最终拍板决策。
这些都需要在项目启动的时候事先规划好。
最后，与客户方领导制订出软件目标，是相当重要但常常被我们忽视的一个步骤。
软件信息化管理不是包治百病的神药。
很多项目的失败都归因与项目目标不明确造成的项目范围的失控。
因此，这时讨论项目目标，既重要又适时。
也许在此之前我们已经做足了功课，对业务需求进行了一番详细的整理，有了一大堆疑问急需解答。
但是，在这时，不是解答具体问题的地方，这是我们常常会犯的一个毛病。
在这样一个会议上，我们应当询问客户方领导对这个项目的期望，渴望达到的项目预期，而我们应当描述的，是对达到这些预期的整体解决方案，凡此等等。
俗话说：
万事开头难。
如果你在项目开始的时候总感觉千头万绪不知如何着手，在这里我给大家的三点建议：
1）树立良好的职业威信；2）进行详细角色分析，将与会各方代表对号入座；3）从宏观上制订目标与方案。
随后的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。
我们应当怎样做需求调研：
拜访
项目组经过一番努力，获得了一些初步的成果。
首先是给客户留下了一个良好的印象，这是一个开端，但要在他们心目中树立自己的职业威信还要看你今后的表现。
同时，我们与客户一起为项目制订了短期与长期目标。
不要小看了这些目标，它们就是我们的尚方宝剑。
正是因为有了它，今后项目中的有关各方就应当协助实现这个目标。
我们应当清晰地向客户表达这样一个意思，要完成这样的目标，不是某一方的努力，而是双方共同努力的结果。
这也是客户方召开这样一个项目启动会议的重要意义。
最后一个成果，也是最重要的成果，就是与各种角色、各个类型的客户建立了联系。
下面，我们将一个一个去拜访他们，展开我们的需求调研。
与西方人不同，中国人做事往往比较重视感情，这是与中国数千年的文化分不开的。
让我们来听听一位金牌销售员是怎么做生意的：
“我跟客户头几次见面，绝对不提生意的事，玩，就是玩。
吃饭啦，唱卡拉OK啦，打球啦••••••先建立关系，关系好了再慢慢提生意的事儿。
”这说得比较夸张，毕竟他是在做销售，但至少传达出一个概念，那就是做事先培养感情，感情培养起来才好慢慢做事，需求调研也是一样。
需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工作（假如项目还有后期维护）。
在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求。
不仅如此，技术这东西总有不如意甚至实现不了的地方，我们需要客户的理解与包容，这都需要有良好的客户关系。
按照现在的软件运作理念，软件项目已经不是一锤子的买卖，而是长期的、持续不断的提供服务。
按照这样的理念，软件供应商与客户建立的是长期共赢的战略协作关系，这更需要我们与客户建立长期友好的关系。
尽管如此，我们也不能总是期望客户中的所有人都能与我们合作，很多项目都不可避免地存在阻碍项目开展的人。
如很多ERP项目会损害采购和销售人员的利益，因为信息化的管理断了他们的财路；很多企业管理软件会遭到来自基层操作人员的抵制，因为它会给基层操作人员带来更多的工作量负担。
有一次，我们给一个集团开发一套软件，当我们下到基层单位时，才发现，一些基层单位已经有了相应的管理软件。
我们的软件成功上线，必然就意味着这些基层单位的管理软件寿终正寝，这必然影响到基层信息化管理专员的利益和政绩。
分析一个客户人群的关系，就是在分析这个人群中，谁有意愿支持我们，而谁却在自觉不自觉地阻碍我们。
那些通过这个项目可以提高政绩，提高自身价值的人，都是我们可以争取的盟友。
他们是我们最可以依赖的人，我们一定要与他们站在一起，荣辱与共，建立战略合作伙伴关系。
另一种人，即使软件获得了成功，也与他没有太多关系，但你与他相处得好，却可以给予你巨大的帮助，这种人是我们需要拼命争取的人。
所谓领域专家，他可以给你多讲点儿，但随便打发你，对他也没太大影响。
报着谦虚谨慎、相互尊重的态度，大方地与他们交往。
当他们帮助我们以后，真诚地予以感谢。
这是我总结出来的，与他们交往的准则。
最后，就是那些对我们怀有敌意的人。
尽管有敌意，但我们能够坦荡的，敞开心扉的与他们交往。
虽然不能奢望太多，但拿出诚意去争取他们，也还是有机会化干戈为玉帛、化敌为友。
如果能够那样，那是再好不过了。
经过一番交往，我们将逐渐在客户中结识一批可以帮助我们的人。
今后一段日子里，我们将依靠他们去学习和认识业务知识，收集业务需求，为日后的软件研发提供素材。
我们应当怎样做需求调研：
研讨会
经过一番努力，我们终于在客户中找到了一批人，可以解答困扰我们多时的业务问题了，真是不容易呀。
但是，如何以合适的时间、合适的地点、通过合适的形式与客户研讨业务需求，是摆在项目经理面前的一道难题。
在我所经历的项目中，业务研讨会没有一个是相同的。
我曾经做过一个政府机关的项目，在这个项目中，从总局到省、地市、区县，形成了一个多组织机构的管理系统。
虽然全国管理流程大体相同，但各地因各地实际情况的不同、领导管理思路和政策理解的不同，管理模式在许多细节上存在着差异，也就是说，这个项目存在着需求个性化的问题。
在项目进行之初，客户方领导提前意识到这方面的问题，因此在组织需求研讨时，分别从各个省市抽调业务人员，集中在一起进行研讨。
同时，在研讨时，根据与会人员的业务特点，将他们分成若干个业务组，分别对某个相对独立的业务模块的需求进行研讨。
采用这样的组织形式，各地的业务差异在会上都会被提出来。
一些地区不合理的管理模式，一经提出，就会得到其它地区业务人员的纠正，进而避免了不合理需求的提出。
当然业务人员之间也会出现意见分歧。
在会议启动之时，高层领导就明确提出了必须形成全国统一版本。
因此，一旦出现分歧时，业务人员就会通过激烈辩论、各抒己见，进而形成统一意见。
如果分歧双方谁都说服不了谁，业务组指定的组长则拍板采用哪个方案。
如果他不能做出决定，就立即反映到总局领导那里当场做出决定。
采用这种集中式的研讨，可以使问题的处理变得高效而及时。
当然，也会因地区化差异而出现多个方案，每个方案都是合理的，我们必须在软件中分别对其进行处理的情况。
出现这种情况时，至少我们很容易理清楚有几种情况，有没有可以合并的地方，使得差异最小化，最终在软件维护中体现出来，让客户自己去选择自己的管理模式。
另外，将业务人员划分为多个业务组也是一项比较成功的经验。
由于业务人员自身的局限，不可能对所有业务领域的细节全面掌握，往往总是有自己熟悉的部分，也有自己不熟悉的部分。
划分业务组，可以让业务人员分别在自己最熟悉的业务范围内参与讨论，可以有效提高业务讨论的质量。
同时，一个管理系统涉及的业务是复杂而系统的，如果划分成多个模块并行地进行业务讨论，也可以大大提高业务研讨的工作效率。
这个项目采用这种方式，使这个项目在运行数年后依然能保持统一的版本，而不至于形成一个一个的地方版本。
统一的版本使得软件的升级维护成本大大降低，使项目进入良性的进化、完善的循环中。
以上讲的是一种集中式的业务研讨形式。
采用这是形式固然好处多多，但并非所有软件项目都能够采用这种模式。
我参与过的另一个项目就没有如此幸运了。
在这个项目中，虽然也是多组织机构管理系统，但总公司对各分子公司的管理是松散的，所以很难组织各地的业务代表集中在一起讨论，甚至不能要求各分子公司采用统一的管理模式。
企业信息化的目的就是要建立统一的、规范化的管理形式，它本身就是一场企业管理的变革。
我们的软件，如果不能规范各分支机构的管理，抑制个性化差异，而是照猫画虎地一家一家为分子公司做软件，不仅我们的成本是巨大的，客户的信息化管理效果也不能发挥出来，而且为日后的运行维护带来巨大的隐患。
毫无疑问，它是我们做管理软件的一个雷区，我们必须小心应对。
起先，总公司领导带着我们一家一家地去分子公司开需求研讨会。
每个需求研讨会，我们都要着力注意各个单位管理模式的差异。
当业务代表在描述自己业务流程的时候，我们常常提示业务代表，×××公司是这样管理的。
这时候，业务代表会思考，采用×××公司的管理模式是否会更好，或者采用×××公司的管理模式行不行。
如果他提出×××公司的管理模式可能会出现什么什么问题时，我们也会着力记录下来，下次再和×××公司讨论，他们是不是会出现这些问题。
采用这种分散式的业务研讨形式，让我们作为外人来规范客户的管理模式，常常会有这样那样的不便，但这也是我们可能面对得最多的需求研讨形式。
在这样的形式中，寻找一个典型范例也许可以算是一种最佳实践。
当我们面对管理松散的多组织机构时，寻找一个管理规范、对我们的支持度高的分支机构，首先将他们的信息化系统建立起来，产生预期的效益，这就树立了一个范例。
它的成功就会为其它分支机构带来一种精神动力和成功案例，照着做肯定不会错。
这样就可以更容易地说服其它分支机构，摒弃现有的管理模式而朝着规范化管理迈进。
业务研讨形式比较容易出现的另一个问题，就是将各个方面的业务代表拉过来开大会。
在大会上，你说你的，我说我的，杂乱无章，一些重要的需求被不经意地漏掉。
遇上这样的情形，项目经理应当有清醒的认识，我们需要再下来开小会。
销售部门的需求跟销售部门谈，采购部门的需求跟采购部门谈••••••既然是小会，每次谈的时候人不在多，在精，参会的业务人员对自己的业务了解精细而全面。
这样的会议，通常有一至三个业务人员，和一个负责人（负责拍板）参加。
会议之后，我们最好询问与会人员的联系方式，便于日后建立长期的联系，毕竟业务需求不是一蹴而就的事情。
同时，如果我们今后采用的是迭代式开发，他们也就成为了我们业务验证的客户代表。
业务研讨会是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能称之为会议。
项目经理需要根据实际情况，合理地与客户组织研讨会。
但不论怎样组织，必须注意两点：
有效抑制个性化差异、分模块组织专项研讨会。
我们应当怎样做需求调研：
需求研讨
前面我们探讨了业务研讨会应当怎样组织，下面我们再具体讨论一下我们应当怎样与客户讨论业务需求。
如果说组织业务研讨会是项目经理的功底，那么讨论业务需求就是需求分析人员的功底。
以往我们常常认为，需求分析是一件最简单的事情。
客户说他们需要做一个什么软件，有些什么功能，我们照着做就可以了，所谓的需求分析员就是需求的记录员。
我要说，这是一个极大的错误，许多失败的软件项目，或者说软件项目中的需求问题，大多都源于此。
经过人们多年的研究发现，在需求分析过程中，客户存在的最大问题就是提不出正确的需求，这表现为几种形式：
1.由于对软件不了解，客户提不出需求，不知道软件最终会做成什么样子。
这类客户在需求讨论过程中，往往只能描述目前自己手工管理的方式是怎样的，不知道计算机会怎样管理。
2.能提出一些业务需求，但当软件做出来摆在自己面前时，需求就变了。
这类客户，他们能熟练使用电脑，对信息化管理是清楚的。
他们提出的业务需求从整体上应当是八九不离十的。
但是，由于没有实物，在软件中的一些具体操作并没有完全想清楚。
因此，当软件真正做出来摆在自己面前时，甚至经过一系列流程操作以后，会对一些操作提出变更需求。
他们正如那句经典的话说的：
“Ihavechangedwhenitsawit.”
3.能非常详细地提出业务需求，甚至有时候该怎么做的提出来了。
这类客户，参与过很多软件信息化建设，甚至有些还是软件开发的半专业人士。
但是他们提出的业务需求过于具体，甚至怎样实现都说出来了，但这些有时候不是最佳设计方案、可能在技术上难于实现，甚至有些就是过于理想化而不可实现。
因此，我在进行需求研讨的时候，首先跟客户探讨的不是软件功能，而是客户现有的业务知识，用专业的话叫“业务领域分析”。
客户现有的业务流程是什么样的，都有些什么操作？
客户在业务中都有些什么事物，什么专用名词，都是怎样定义的，相互之间的关系是什么？
客户在每一项操作中的目的是什么，为什么要这样做，他们制作的手工报表都说明了什么问题？
后面我会更加详细地描述怎么进行业务领域分析。
在认识了客户的业务领域之后，我们才能去分析他们提出的所有原始需求。
他们为什么要提出这项需求，提这项需求的目的是什么？
只有经过这样的分析，我们才能深刻地理解需求，进而运用我们的专业知识，提出更加合理的技术方案。
但非常遗憾，我们在需求分析中常常不是这样做的，甚至当软件都开发出来了，需求分析人员都说不出客户为什么要提出这个需求，更谈不上了解业务操作流程。
一句经典的话是：
“客户让我们这样做的。
”
总之，我们做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。
当然，另一个极端就是为了开发软件，无限地扩大学习领域知识的范围。
为了开发财务软件去考会计师，为了开发税务软件去学习税法等等。
开发软件不是让我们成为这个领域的专家。
我们学习领域知识是为了更好地理解和开发软件，是学习与这个软件有关的领域知识，而不是成为一个专家。
在客户提出的所有原始需求中那些与业务实现有关的需求都是无效的需求，它
升级会员 