第1章需求问题.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,*,*,软件需求,1,需求,:,导致项目失败的罪魁祸首,根据,Standish Group,对,23000,个项目进行的研究结果表明，,28%,的项目彻底失败，,46%,的项目超出经费预算或者超出工期，只有约,26%,的项目获得成功。,而在于这些高达,74%,的不成功项目中，有约,60%,的失败是源于需求问题。,也就是说，有近,45%,的项目最终因为需求的问题最终导致失败。,对不知道航行目的地的人来说，没有顺风！,2,我们在哪里重重摔了一跤,在,Standish Group,的报告中总结了导致项目失败的最重要的,8,大原因中，有,5,个与需求相关：,不完整的需求,(13.1%),；,缺乏用户的介入,(12.4%),；,不实际的客户期望,(9.9%),；,需求和规范的变更,(8.7%),；,提供了不再需要的,(7.5%),缺乏资源,(10.6%),没有执行层支持,(9.3%),缺少规划,(8.1%),3,项目成功的因素,用户的参与：,15.9%,管理层支持：,13.9%,清晰的需求描述,(13.0%),；,合适的规划,(9.6%),；,现实的客户期望,(8.2%),；,较小的里程碑,(7.7%),；,有才能的员工,(7.2%),4,第,1,章 需求问题,了解软件需求开发中使用的一些关键名词。,警惕在软件项目中可能出现的与需求相关的一些问题。,知道优秀的需求规格说明应该具有的特点。,明白需求开发与需求管理之间的区别。,5,需求问题,需求,是软件项目成败的,关键所在,。,越,早发现,需求错误，越早改正它，其代价越小,需求是系统必须,具有的能力,。,好需求的特征：,无歧义、完整、一致、可检验、确定、可跟踪的，正确的，可行的和必要的。,6,需求问题的症状,1,症状：在软件项目中，变更频繁，而且集中出现在项目的中后阶段。,分析要点：,变更是对原需求的背离，还是补遗,(,需求不完整,)?,背离发生在什么方面,(,流程间,/,流程内,/,数据使用,),？,这些变更是需求阶段是否可能预见的,?,是否存在无效的变更响应,(,管理有问题,)?,改进方向：,变更的可预测性,需求阶段标识,(,需求捕获,/,分析,),变更渠道单一化、统一化,(,需求管理,),7,需求问题的症状,2,症状：软件项目上线运行时遇到很多阻力。,分析要点：,是否为组织因素,?,阻力源于操作层还是管理层,?,改进方向：,清晰的业务需求导向,(,需求定义,),面向不同层面的需求分析,正确识别组织因素,(,需求捕获,),8,需求问题的症状,3,症状：软件项目上线运行后效果很差。,分析要点：,为什么不使用,(,用户界面,/,功能,/,手工系统,)?,使用者的成本,/,效益分析,?,改进方向：,抓准业务需求,(,需求定义,),不同层面用户的分析,(,需求捕获,/,分析,),9,需求问题的症状,4,症状：产品二次开发量大。,分析要点：,二次开发量最要集中于什么方面,(,业务规则,/,用户界面,/,流程顺序,/,流程细节,/,报表格式,)?,改进方向：,工作流模型,顺序,/,细节,弹性设计,业务规则,/UI,报表格式理解数据模型,10,需求问题的症状,5,症状：产品,/,项目完全不可用或崩溃。,分析要点：,忽略了哪方面非功能需求,?,改进方向：,性能与能力,操作环境,可靠性,11,中国有句谚语：,“好的开始就等于成功的一半,12,软件开发的目标,软件开发的目标，简单而言，就是满足用户的需要。,13,项目失败与成功的原因,三种最经常使项目“遇到困难”的因素是：,缺乏用户介入：占所有项目的,13%,不完整的需求和规格说明：占所有项目的,12%,不断改变的需求和规格说明：占所有项目的,12%,三种项目最主要的“成功因素”是：,用户介入：占所有成功项目的,16%,高层管理的支持：占所有成功项目的,14%,需求陈述清晰：占所有成功项目的,12%,14,2-8,原则,80%,的工程活动是由,20%,的需求消耗的,80%,的软件成本是由,20%,的构件消耗的,15,需求在项目中的作用,在项目开发中，所有的,涉众（,Stakeholder,）,都对需求分析阶段备感兴趣。,未真正明白这些问题就开始编码，结果没有人对产品满意。,16,需求缺陷造成的成本增加,重新进行需求规格说明,重新设计,重新编码,重新测试,改变订单,告诉用户将以一个修正后的版本来替代有缺陷的版本。,纠正活动,消除由于不准确的特定系统的错误造成的危害，可能涉及到赔偿客户损失。,报废,包括对于已经完成的代码、设计和测试，当发现它们是根据不正确的需求进行的时候，这些工作成果不得不被丢弃。,收回有缺陷的软件产品以及相关的用户手册。,产品赔偿或保修的成本。,重新安装新版本的成本。,重新建档的成本。,17,“喂，是,王经理,吗？我是人力资源部的,小李,，我们在使用你编写的职员系统时遇到一个问题，一个职员想把她的名字改成,高李丽娜,，而系统不允许，你能帮帮忙吗？”,“她嫁给了一个姓高 的人吗？”王经理问道。,“不，她没有结婚，而仅仅是要更改她的名字，”小李回答。,“就是这问题，好像我们只能在婚姻状况改变时才能更改姓名。”,“当然是这样，我从没想过谁会莫名其妙地更改自己的姓名。我不记得你曾告诉我系统需要处理这样的事情，这就是为什么你们只能在改变婚姻状况对话框中才能进入更改姓名的对话框。”王经理 说。,小李说：“我想你当然知道每个人只要愿意都可以随时合法更改他（她）们的姓名。但不管怎样，我们希望在下周五之前解决这个问题，否则，李丽娜将不能支付她的账单。你能在此前修改好这个错误吗？”,“这并不是我的错！我从来不知道你需要处理这种情况。我现在正忙着做一个新的性能检测系统，并且还要处理职员系统的一些需求变更请求”“我还有别的事。我只可能在月底前修改好，一周内不行，很抱歉。下次若有类似情况，请早一些告诉我并把它们写下来。”,“那我怎么跟李丽娜说呢？”小李追问道，“如果她不能支付账单，那她只能挂帐了。”“小李，你要明白，这不是我的过错。”王经理坚持道，“如果你一开始就告诉我，你要能随时改变某个人的名字，那这些都不会发生。因此你不能因我未猜出你的想法（需求）就责备我。”小李不得不愤怒地屈从：“好吧，好吧，这种烦人的事使我恨死计算机系统了。等你修改好了，马上打电话告诉我，行吧？”,18,在软件开发中遇到的许多问题，都是由于,收集、编写、协商、修改产品需求过程中的手续和作法（方法）失误,带来的。,例如上面的王经理和小李，出现的问题涉及到：,非正式信息的收集,未确定的或不明确的功能,未发现或未经交流的假设,不完善的需求文档,以及突发的需求变更过程。,19,在软件工程中，所有的风险承担者（,s t a k e h o l d e r,）都感兴趣的就是需求分析阶段。,需求分析,奠定了软件工程和项目管理的基础,20,软件需求的定义,软件产业存在的一个问题就是缺乏统一定义的名词术语来描述我们的工作。客户所定义的“需求”对开发者似乎是一个较高层次的产品概念。而开发人员所说的“需求”对用户来说又像是详细设计了。实际上，软件需求包含着多个层次，不同层次的需求从不同角度与不同程度反映着细节问题。,I E E E,软件工程标准词汇表（,1 9 9 7,年）中定义需求为：,（,1,）用户解决问题或达到目标所需的条件或权能（,C a p a b i l i t y,）。,（,2,）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。,（,3,）一种反映上面（,1,）或（,2,）所描述的条件或权能的文档说明。,21,一些关于“需求”的解释,包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求。关键的问题是一定要编写需求文档。,另外一种定义认为需求是“,用户所需要的并能触发一个程序或系统开发工作的说明,”,需求是指明必须实现什么的规格说明。它描述了,系统的行为、特性或属性，是在开发过程中对系统的约束,。,22,需求的层次,软件需求包括三个不同的层次,业务需求（,business requirement,）,用户需求,(user requirement),功能需求,(functional requirement),软件需求规格说明（,software requirements specification,，,S R S,）中说明的,功能需求,充分描述了软件系统所应具有的外部行为。,软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。,非功能需求。它,描述了系统展现给用户的行为和执行的操作,等。,它包括产品必须遵从的标准、规范和合约；,外部界面的具体细节；,性能要求；,设计或实现的约束条件及质量属性。,约束是指对开发人员在软件产品设计和构造上的限制,23,软件需求各组成部分之间的关系,24,业务需求,业务需求是指,反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求,。,背景描述：,XX,保险公司希望充分利用日益完善的移动通信技术，在原有的办公系统的基础上进行扩展，使得在外的业务人员能够及时地获得客户、业务相关的动态信息，与此同时，实现企业内部的即时通信。,业务需求,/,目标：通过该系统的实施，将人工保费续缴、投保手续办理两项业务运转周期缩短,10,以上，使企业内部沟通效率大幅改善，以帮助企业运转效率得以提高。,25,业务需求就是系统目标,现状：功能分解盛行的今天，常常会犯“盲人摸象”的错误，这使得需求太过脆弱，难以经受考验。,目标！目标！还是目标！,-,系统开发应,目标驱动,！目标是团队唯一的行动纲领。,目标的定义不能够流于形式，应该具有以下特征：,业务导向、可度量、合理、可行,。要注意目标太夸大会浪费资源，目标太缩小会影响士气。,（教堂与小屋）,目标通常就是,业务需求,！,26,用户需求,用户需求是指,描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求,。,用户有不同类型：,管理型、事务型,信息系统、人,决策层、使用层,常用者、偶用者,组织方法：用例、用户故事、特性,例子：对快到期的客户，系统将通过短信将续保信息发给该客户的代理人。,27,软件需求,从系统实现的角度描述的需求。,开发人员（设计及分析人员）在业务需求、用户需求的基础上生成的。,有时还需要考虑相关联的硬件、环境方面的需求,28,功能需求,功能需求是,需求的主体，是需求的本质。,功能需求定义了：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作。,零散（需求项）,整理（特性、用例）,29,质量属性,产品必须具备的属性或品质：,可靠性：成熟性、容错性、易恢复性,易使用性：易理解性、易学习性、易操作性,效率：时间特性、资源特性,可维护性：易分析性、易更改性、稳定性、易测试性,可移植性：适应性、易安装性、一致性、易替换性,McCALL,体系：运行,(,正确性、可靠性、效率、完整性、使用性,),、修正,(,维护性、测试性、灵活性,),、转移,(,移植性、复用性、共运行性,),30,设计约束,也称为,限制条件、补充规约,，这通常是对解决方案的一些约束说明。,例如：必须采用国有自主知识版权的数据库系统,再如：必须运行在,UNIX,操作系统之下,三如：用户将在户外完成作业,31,以一个字处理程序为例来说明需求的不同种类,业务需求可能是：,“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。,用户需求可能是,:,“,找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。,功能需求可能是,:“,如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换”,。,32,需求过程在软件项目中扮演重要角色,开发软件系统最为困难的部分就是,准确说明开发什么。,最为困难的概念性工作便是,编写出详细技术需求,，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。,33,不适当的需求过程所引起的一些风险,用户不多导致产品无法被接受。,用户需求的增加带来过度的耗费和降低产品的质量。,模棱两可的需求说明可能导致时间的浪费和返工。,用户增加一些不必要的特性和开发人员画蛇添足。,过分简略的需求说明以致遗漏某些关键需求。,忽略某类用户的需求将导致众多客户的不满。,不完善的需求说明使得项目计划和跟踪无法准确进行。,34,导致需求过程中软件成本估计极不准确的原因主要有以下五点：,频繁的需求变更,遗漏的需求,与用户交流不够,质量低下的需求规格说明,不完善的需求分析,35,高质量的需求过程带来的好处,实行有效的需求工程管理的组织能获得多方面的好处。最大的好处是在开发后期和整个维护阶段的,重做的工作大大减少了,。,36,需求工程域的层次分解示意图,37,38,需求说明的特征,完整性,正确性,可行性,必要性,划分优先级,无二义性,可验证性,39,软件或系统项目涉众,(stake holder,，产品或项目相关人员,),的利益之间的相互作用在需求过程中表现得最为强烈。项目涉众包括：,客户,:,为达到其公司的业务目标而投资项目或购买产品。,用户：直接或间接与产品打交道，是客户的一部分。,需求分析员：负责编写需求并传达给开发团队。,开发人员：设计、实现和维护产品。,测试人员：确定产品的行为是否与预计的相一致。,文档编制人员：负责编写用户手册、培训资料和系统帮助。,项目经理：制定项目计划并带领开发人员获得成功。,法律人员：确保产品符合所有相关法规。,生产人员：制造包含该软件的产品。,市场营销,:,技术支持及其他与产品和客户打交道的人员。,40,用户的权利法则,用户总是对的。如果系统使用有问题，那么系统就是问题所在，而不是用户。,用户有权进行简易安装和卸载软件和硬件系统，而不会产生任何负面的影响。,用户有权要求系统达到承诺的性能。,用户有权获得易于使用的指导（用户指南、在线或上下文帮助、出错信息），从而理解和使用系统，达到既定目标，并能从系统发生的问题中有效地恢复。,用户有权控制系统，并且能使系统响应其要求。,用户有权要求系统提供有关正在进行的任务及进展的清晰、准确而可理解的信息。,用户有权要求所有有关正确使用软件或硬件的系统信息。,用户有权知道系统的能力限制。,用户有权与技术提供商联系，并得到合理而有用的帮助。,用户应该是软件和硬件的主人，而不是相反。产品应该简单而直观，易于使用。,41,需求金字塔,42,特征（,feature,）,特征（,feature,）是系统为了完成涉众的一个或多个需要而提供的服务。,应用领域,特征范例,电梯控制系统,在发生火警时人工控制通道,存货管理系统,及时提供所有存货的最新状况,缺陷跟踪系统,提供缺陷走势数据评估产品质量,工资管理系统,到目前为止的金额分类扣除报告,家用自动照明系统,长时间外出的设置,43,特征属性,44,风险躲在需求的迷雾之后,经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部,-,门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”经理觉得奇怪：“我不是刚告诉你我的需求了吗？”分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”,45,优秀的团队遇到糟糕 的需求,需求问题导致的主要后果是返工,重复做您认为早已做好的事情。,返工的成本占了总开发成本的,30%,50,，而对于返工的情况，,70%,80%,是因需求错误引起的。,从图可以看出，在项目末期才发现缺陷，对其进行改正的成本要比在缺陷刚产生不久时修改的成本高得多。,46,镀金问题,开发人员为产品添加了一项需求说明中没有提到的功能，他认为“,用户肯定会喜欢的,”。这就是所谓的“镀金问题,(gold plating)”,。,开发人员和需求分析员不应擅自添加特性，应该把创意和备选方案提交给客户，让他们做决定。,要避免镀金问题，就应该追溯每项功能的来源，弄清楚为什么添加该功能。,47,过于抽象的需求,营销人员或经理经常喜欢只给出一个粗略的说明，他们希望开发人员在开发过程中充实它。,这种方式对研究性项目或需求特别灵活的项目或许管用，但是需要紧密合作的团队，而且仅限于开发小型系统。,大多数情况下，这种做法的结果是使开发人员受挫，让客户失望。,48,忽略了某类用户,用户所使用的产品特性、产品的使用频率以及用户自身的经验水平不尽相同。,多数产品都拥有不同的用户群。如果一开始没能找出产品的所有重要用户群，就会有某些用户需求得不到满足。确定所有用户群后，还要保证获得各类用户的需求。,49,