项目管理之需求分析.ppt

项目管理之需求分析.ppt

《项目管理之需求分析.ppt》由会员分享，可在线阅读，更多相关《项目管理之需求分析.ppt（37页珍藏版）》请在冰豆网上搜索。

项目管理ProjectManagement_需求管理需求管理InternalTrainingMaterialsCONFIDENTIALINFORMATION:

DonotdiscloseI.Content什么是需求II.III.IV.V.VI.如何寻找需求分析需求的难点需求分析20条准则需求确认案例讨论No.2从一个典型的失败项目说起需求和功能设计|现实一个小项目，感觉需求也简单，再加上时间紧，如果从需求开始一步步来，时间肯定来不及，在这种情况下，项目就匆匆的开始了。

为了节省时间，需求分析,架构设计等等都不去考虑了，想到哪写到哪，完全瀑布式开发。

直接结果是，完工时间一拖再拖，最后不得不决定下一版本整个推倒重来。

No.3从一个典型的失败项目说起需求和功能设计以上示例失败的原因需求分析不到位、架构设计不合理Do需求分析做的好架构设计合理灵活的适应变化的需求Dont需求分析做的好,架构设计不合理,项目也可以实现，只是以后的维护会有困难架构好了，需求没有做好，随着需求的进一步完善，项目也会完成如果都没有做好，象这个项目一样，就只能有两种选择：

尽早重来;下一个版本重新开始好的需求，会加快项目的进度，也可以给开发人员的设计提供帮助。

项目开始前一定要做好需求和设计，至少要有明确的思路，匆忙开始的项目很可能会失败，至少也会走弯路，而走弯路花的时间很可能会超过在需求和设计上省下来的时间，更不用说失败的项目所造成的后果。

No.4需求内容业务需求反映了组织机构或客户对网站、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

例如：

电子商务网站中,关于客户在线业务流程实现,在线产品展示,订单与支付等，整个过程都要符合客户企业自身的业务运作流程，为客户服务。

用户需求描述了用户使用网站必须要完成的任务，这在使用实例或方案中予以说明。

例如：

描述招聘系统功能，用户可分部门浏览职位招聘情况，可在线填写简历，用户填写的简历字段可定制，后台可分类检索简历。

No.5需求内容功能需求定义了开发人员必须实现的系统功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

例如：

系统需要具有网站统计分析功能，需要统计出每日，每月，每年的点击量，PV值，用户来源。

非功能性的需求描述了系统展现给用户的行为和执行的操作等，它包括系统必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。

例如：

系统是按照W3C标准进行开发制作；首页BANNER区以FLASH形式展现；首页新闻区域采用JAVASCRIPT效果以标签形式展现。

需求分析报告报告所说明的功能需求充分描述了系统所应具有的外部行为。

需求分析报告在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。

No.6什么是好需求需求要从客户的角度去寻找需求是客户要求的抽象，而不是具体的表现，这样做的需求才能对以后的设计产生积极的影响。

而一些具体的要求可能都是易变的，这些可能是商业政策，而不是真正的需求。

需求总是易变的这就要求架构要有灵活性，灵活性不是靠提前设计实现你认为将来会有的需求，而是靠抽象，这样可以在需求变化时，架构做最少的修改。

从开发者角度说，需求是架构必须要实现的要求要把抽象的需求再扩展到具体。

这样需求就经历了从具体（客户的描绘）到抽象（架构，好的需求）再到具体（实现）的一个过程都是自己的理解。

No.7I.Content什么是需求II.III.IV.V.VI.如何寻找需求分析需求的难点需求分析20条准则需求确认案例讨论No.8如何寻找客户的需求如果你赞成客户的参与是发布一个优秀软件的关键因素，在项目的开始阶段就会努力致力于为你的项目征求各个客户的意见。

为了征求客户的意见，必须采取以下几步：

明确项目用户需求的来源访问并与有潜力的用户探讨把对目前的或竞争产品的描述写成文档系统需求规格说明对当前系统的问题报告和增强要求指导用户和提供技术支持的工作人员是最有价值的需求来源市场调查和用户问卷调查用户任务的内容分析明确使用该产品的不同类型的用户与产品不同用户类的代表进行沟通遵从项目的最终决策者的意见No.9I.Content什么是需求II.III.IV.V.VI.如何寻找需求分析需求的难点需求分析20条准则需求确认案例讨论No.10项目需求分析难在哪里有几种原因使需求分析变得困难：

客户说不清楚需求有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。

例如全国各地的很多政府机构在搞网络建设，这些单位的领导和办公人员大多不清楚计算机网络有什么用，反而要系统分析人员替他们设想需求。

有些客户心里非常清楚想要什么，但却说不明白。

如果客户本身就懂开发，能把需求说得清清楚楚，这样的需求分析将会非常轻松、愉快。

如果客户全不懂开发，但信任开发方，事情也比较简单。

分析人员可以引导客户，先阐述常规的需求，再由客户否定不需要的，最终确定客户真正的需求。

最怕的就是不懂装懂或者半懂充内行的客户，他们会提出不切实际的需求。

如果这些客户甚至觉得自己是上帝的爸爸，那么沟通和协商都会很困难。

No.11项目需求分析难在哪里有几种原因使需求分析变得困难：

需求自身经常变动网站开发的需求会变化吗？

据统计，没有一个软件的需求改动少于三次。

让我们先接受需求会变动这个事实吧，免得在需求变动时惊慌失措。

明白需求会变动这个道理后，在进行需求分析时就要留点神：

（1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。

以便在进行系统设计时，将网站的核心建筑在稳定的需求上，否则将会吃尽苦头。

（2）在合同中一定要说清楚做什么和不做什么。

如果合同含含糊糊，日后扯皮的事情就多。

要防止开始时什么都点头,事后就宣布刚才答应的事都不算数。

No.12项目需求分析难在哪里有几种原因使需求分析变得困难：

分析人员或客户理解有误有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：

主宰地球的是车。

它们喝汽油，靠四个轮子滚动前进。

嗓门极大，在夜里双眼能射出强光。

有趣的是，车里住着一种叫作人的寄生虫，这些寄生虫完全控制了车。

网站需求分析人员不可能都是全才。

客户表达的需求，不同的分析人员可能有不同的理解。

如果分析人员理解错了，可能会导致开发人员白干活，吃力不讨好。

所以分析人员写好需求说明书后，要请客户方的各个代表验证。

由于客户大多不懂网站建设，他们可能觉得网站是万能的，会提出一些无法实现的需求。

有时客户还会把需求分析人员的建议或答复给想歪了。

有一个软件人员滔滔不绝地向客户讲解在信息高速公路上做广告的种种好处，客户听得津津有味。

最后，心动的客户对软件人员说：

好得很，就让我们马上行动起来吧。

请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。

No.13I.Content什么是需求II.III.IV.V.VI.如何寻找需求分析需求的难点需求分析20条准则需求确认案例讨论No.14123项目需求分析20条法则客户与开发人员交流需要好的方法。

下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。

如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。

：

分析人员要使用符合客户语言习惯的表达需求讨论集中于业务需求和任务，因此要使用术语。

客户应将有关术语解释给分析人员，而客户不一定要懂得计算机行业的术语。

分析人员要了解客户的业务及目标为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。

如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。

分析人员必须编写软件需求报告分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。

需求分析报告，使开发人员和客户之间针对要开发的产品内容达成协议。

客户要评审此报告，以确保报告内容准确完整地表达其需求。

No.15456项目需求分析20条法则要求得到需求工作结果的解释说明分析人员可能采用了多种图表作为文字性需求分析报告的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面；客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果开发人员要尊重客户的意见如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。

共同合作能使大家兼听则明。

参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。

开发人员对需求及产品实施提出建议和解决方案通常客户所说的需求已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；分析人员应提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。

No.1678项目需求分析20条法则描述产品使用特性客户可以要求分析人员在实现功能需求的同时还注意网站的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。

例如：

客户有时要求产品要界面友好或健壮或高效率，但对于开发人员来讲，太主观了并无实用价值。

正确的做法是，分析人员通过询问和调查了解客户所要的友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。

以已有的模块进行需求示例需求通常有一定灵活性，分析人员可能发现已有的某个模块与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。

所以说，如果想在产品中使用一些已有的常用模块，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。

No.17910项目需求分析20条法则要求对变更的代价提供真实可靠的评估有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。

而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。

所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。

开发人员不能由于不想实施变更而随意夸大评估成本。

获得满足客户功能和质量要求的系统每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统做什么所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。

11给分析人员讲解业务分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的常识。

No.1814No.19项目需求分析20条法则12抽出时间清楚地说明并完善需求客户很忙，但无论如何客户有必要抽出时间参与头脑高峰会议的讨论，接受采访或其他获取需求的活动。

有些分析人员可能先明白了客户的观点，而过后发现还需要客户的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复。

13准确而详细地说明需求由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。

但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选。

客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进软件需求报告中去。

如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。

及时作出决定分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。

有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。

15项目需求分析20条法则尊重开发人员的需求可行性及成本评估所有的软件功能都有其成本。

客户所希望的某