CMMI3 精髓培训(中级2)

CMMI精髓培训－中级2彭国明需求的基本概念‹宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。‹所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。1.1.2需求的重要性‹FrederickBrooks在他1987年经典文章“NoSilverBullet”中阐述了需求的重要性：–开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。‹需求是产品的根源，需求工作的优劣对产品影响昀大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。‹国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。1.1什么是需求Page41.2.了解客户、昀终用户、间接用户1.2.1基本概念‹“用户”（user）是一种泛称，它可细分为“客户”（customer）、“昀终用户”（theenduser）和“间接用户”（或称为关系人）。‹掏钱买软件的用户称为客户，而真正操作软件的用户叫昀终用户。客户与昀终用户可能是同一个人也可能不是同一个人。1.2.2客户是掏钱买软件的人，所以他是“上帝”‹某饭店经理在解释“先有鸡还是先有蛋”这个哲学问题时，精辟地阐述了客户的地位：–如果顾客先点鸡，那么就先有鸡；如果顾客先点蛋，那么就先有蛋。‹“现代营销学之父”菲利普•科特勒所著的《市场营销导论》是这样描述客户的：–客户永远是本公司的座上客。客户并不依赖我们，而我们却依赖客户。客户不是我们工作的障碍，而是我们工作的目标。我们并不因为服务于他而对他有恩，他却因为给予我们服务于他的机会而有恩于我们。客户不是我们要与之争辩和斗智的人。从未有人曾在与客户的争辩中获胜。客户是把他的欲望带给我们的人，因此我们的工作就是满足这些欲望，从而使客户和我们共同获益。‹与客户打交道的主要目的是：一是获取需求，二是签合同。不要把钱仍到水里。Page51.2.了解客户、昀终用户、间接用户1.2.3即使昀终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。‹如果项目规模比较大，那么开发方与昀终用户的来往就比较多。如从昀终用户那里获取详细的需求，请昀终用户试验软件，对昀终用户进行培训等等。‹公司新员工上产品培训课，有位小领导匆匆赶来作指示：“隔壁班正在给电信局的员工们进行培训，他们都是上帝派来的，大家要注意形象。由于休息室空间有限，请大家自觉让位。午休时他们可以躺着睡，我们只能坐在位置上打个盹儿…….。”1.2.4重视“间接用户”，千万别“大意失荆州”‹间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响。‹例如，财务软件开发商在把“财务软件”卖给客户之前，这个“财务软件”必须得到国家财政部的批准。否则即使该软件的功能是完美的，但却被政府认为是非法的。所以国家财政部就是所有财务软件的间接用户，它不仅不付钱给财务软件开发商，反而要收取鉴定费、手续费等。‹同理，市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则软件开发商被逮住后戴上“非法经营”的帽子就惨了。Page6AnalyzeandValidateRequirements分析和验证需求DevelopCustomerRequirements开发客户需求CustomerRequirements客户需求ValidatedRequirements验证需求Product,Product-Component,andInterfaceRequirements产品、产品组件、接口需求DevelopProductRequirements开发产品需求1.3需求开发过程域结构图RD:RequirementsDevelopmentPage7DeveloptheCustomerRequirements转换成客户需求CustomerRequirementsDevelopCustomerRequirements开发客户需求ElicitNeeds诱导需求1.3.1开发客户需求Page8EstablishProduct&Product-ComponentRequirements确定产品和产品组件需求Product,Product-Component,andInterfaceRequirementsDevelopProductRequirements开发产品需求AllocateProduct-ComponentRequirements分配产品组件需求IdentifyInterfaceRequirements确定接口需求CustomerRequirements1.3.2开发产品需求Page9EstablishOperationalConcepts&Scenarios建立操作概念和场景EstablishaDefinitionofRequiredFunctionality评审功能需求AnalyzeRequirementstoAchieveBalance平衡需求AnalyzeRequirements分析需求Product,Product-Component,andInterfaceRequirementsValidatedRequirementsAnalyzeandValidateRequirements分析和确认需求ValidateRequirementswithComprehensiveMethods确认需求1.3.3分析和确认需求Page10RequirementsObtainanUnderstandingofRequirements获得可理解需求ObtainCommitmenttoRequirements获得对需求的承诺TraceabilityMatrixorRequirementsTrackingSystemMaintainBidirectionalTraceabilityofRequirements维护需求的双向可溯性IdentifyInconsistenciesBetweenProjectWorkandReqmts识别需求和工产品不一致性ManageRequirements管理需求ManageRequirementsChanges管理需求的变更1.3.2需求管理过程域结构图REQM:RequirementsManagementPage111.4.需求工程基本概念1.4.1什么是需求工程‹把所有与需求直接相关的活动通称为需求工程。‹需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。‹需求工程的结构图Page121.4.需求工程基本概念1.4.2需求开发过程域‹需求开发的目的是产生和分析用户需求、产品需求和产品组件需求。‹需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。‹需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。‹需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《需求规格说明书》。系统设计人员将依据《需求规格说明书》开展系统设计工作。1.4.3需求管理过程域‹需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。‹需求确认是指开发方和客户共同对需求文档进行确认，确认方法有评审、签字、原型等，使需求文档具有商业合同效果。‹需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。‹需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。Page131.4.需求工程基本概念1.4.4需求工程的一些感悟‹不论是合同项目还是自主研发的产品，都必须开展需求开发和需求管理活动。‹开发者对待需求工程的态度可分“被动型”、“主动型”和“领先型”三种，只有后两种才有可能开发出成功的产品。–“被动型”是指开发者被动地对待需求工程中的各项活动，能少干则少干，能偷懒则偷懒。他们认为需求是用户的事情而不是自己的事情。开发过程中经常发生需求变更，导致产品迷失方向，不是半途而废就是陷入半死不活的状态。–“主动型”是指开发者积极地开展需求工程中的各项活动。他们把获取准确的需求当作自己的职责，会想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。俗话说“良好的开端是成功的一半”，“主动型”需求工程是开发成功产品的必备条件。–“领先型”是需求工程的昀高境界。开发者发掘了连用户自己都没有意识到的需求，导致用户跟着新产品跑而不是新产品围着用户转，这叫引导消费。需求工程做到这个份上，才能使产品立于不败之地，长盛不衰。Page141.5.需求开发的主要困难与对策1.5.1知识技能问题‹应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。一个企业要谋求发展，不能总在做老的业务。人一生中会有许多充满挫折的“第一次”，不可以逃避。‹当需求分析员缺乏应用域知识时，他该怎么办？–首先他要有勇气做事，否则连实践的机会都没有。–其次他应当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。如果可能的话，开发方昀好请既懂软件又懂应用域知识的行家来帮忙。1.5.2态度问题‹相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为：–需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。‹用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。‹软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。Page151.5.需求开发的主要困难与对策1.5.3合作关系‹如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲惫。‹倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有他自己的想法：–我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧……。‹对于一些竞标项目，在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品，他不会投入很多精力来协助你搞需求开发。‹需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼络住用户就能成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力。‹开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目，我们不能完全期望双方能够自发地建立起良好地合作关系，这样风险太大。‹开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确定合作关系。“好话”和“丑话”都说在前头，这样能减少今后的摩擦。如果条件允许的话，开发方昀好为用户举办关于需求工程的培训，这样的培训将使用户明白需求的重要性以及忽视需求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。Page161.5.需求开发的主要困难与对策1.5.4用户说不清楚需求‹用户说不清楚需求是普遍现