需求开发与需求管理

《需求开发与需求管理》由会员分享，可在线阅读，更多相关《需求开发与需求管理（34页珍藏版）》请在金锄头文库上搜索。

1、需求开发与需求管理 消除软件开发百病之源林 锐 博士rui.linalcatel-http:/Page 2目录1. 什么是需求 2. 了解客户、最终用户、间接用户3. 需求工程基本概念4. 需求开发的主要困难与对策5. 如何开展需求调查6. 如何进行需求分析7. 什么是好的需求规格说明书8. 如何定义产品需求9. 需求管理：确认、跟踪、变更控制Page 31. 什么是需求1.1 需求的基本概念 u宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整 的文档，该文档详细地说明了产品“必须或应当”做什么。 u所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，

2、那是自 欺欺人。1.2 需求的重要性uFrederick Brooks在他1987年经典文章“No Silver Bullet”中阐述了需求的重要性 ： 开发软发软 件系统统最困难难的部分就是准确说说明开发发什么。最困难难的概念性工作是 编编写出详细详细 的需求，包括所有面向用户户、面向机器和其它软软件系统统的接口。 此工作一旦做错错，将会给给系统带统带 来极大的损损害，并且以后对对它修改也极为为困 难难。 u需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污 染了，那么整条河流也就被污染了。 u国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。 Pa

3、ge 41. 什么是需求1.3 需求开发失败的案例 u上海贝尔某事业部一群高智商的开发人员集体犯需求观念错误的案例。u故事是这样的u需求问题有时如同爱情问题，真是“当局者迷，旁观者清”啊。 Page 52. 了解客户、最终用户、间接用户2.1 基本概念u“用户”（user）是一种泛称，它可细分为“客户”（customer）、“最终用户”（the end user）和“间接用户”（或称为关系人）。u掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个 人也可能不是同一个人。2.2 客户是掏钱买软件的人，所以他是“上帝” u某饭饭店经经理在解释释“先有鸡还鸡还 是先

4、有蛋”这这个哲学问题时问题时 ，精辟地阐阐述了客户户的地 位： 如果顾顾客先点鸡鸡，那么就先有鸡鸡；如果顾顾客先点蛋，那么就先有蛋。u“现代营销学之父”菲利普科特勒所著的市场营销导论是这样描述客户的：客户户永远远是本公司的座上客。客户户并不依赖赖我们们，而我们们却依赖赖客户户。客户户 不是我们们工作的障碍，而是我们们工作的目标标。我们们并不因为为服务务于他而对对他 有恩，他却因为给为给 予我们们服务务于他的机会而有恩于我们们。客户户不是我们们要与 之争辩辩和斗智的人。从未有人曾在与客户户的争辩辩中获胜获胜 。客户户是把他的欲望 带给带给 我们们的人，因此我们们的工作就是满满足这这些欲望，从而使

5、客户户和我们们共同 获获益。u与客户打交道的主要目的是：一是获取需求，二是签合同。不要把钱钱仍到水里。Page 62. 了解客户、最终用户、间接用户2.3 即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。u如果项目规模比较大，那么开发方与最终用户的来往就比较多。如从最终用户那里获 取详细的需求，请最终用户试验软件，对最终用户进行培训等等。u公司新员工上产品培训课，有位小领导匆匆赶来作指示：“隔壁班正在给电信局的员 工们进行培训，他们都是上帝派来的，大家要注意形象。由于休息室空间有限，请大 家自觉让位。午休时他们可以躺着睡，我们只能坐在位置上打个盹儿.。” 2.4 重视“间接用户”

6、，千万别“大意失荆州” u间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的 影响。u例如，财务软件开发商在把“财务软件”卖给客户之前，这个“财务软件”必须得到 国家财政部的批准。否则即使该软件的功能是完美的，但却被政府认为是非法的。所 以国家财政部就是所有财务软件的间接用户，它不仅不付钱给财务软件开发商，反而 要收取鉴定费、手续费等。u同理，市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则软 件开发商被逮住后戴上“非法经营”的帽子就惨了。 Page 73. 需求工程基本概念3.1 什么是需求工程u把所有与需求直接相关的活动通称为需求工程。u需求工程中

7、的活动可分为两大类，一类属于需求开发，另一类属于需求管理。 u需求工程的结构图 Page 83. 需求工程基本概念3.2 需求开发过程域 u需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。 u需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生用户需求 说明书。 u需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分 析方法有“问答分析法”和“建模分析法”两类。 u需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求 ，产生产品需求规格说明书。系统设计人员将依据产品需求规格说明书开展 系统设计工作。 3.3 需求管理过程域 u

8、需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作 成果的一致性，并控制需求的变更。 u需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书 面承诺，使需求文档具有商业合同效果。 u需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求 跟踪矩阵”，确保产品依据需求文档进行开发。 u需求变更控制是指依据“变更申请审批更改重新确认”的流程处理需求的变更 ，防止需求变更失去控制而导致项目发生混乱。 Page 93. 需求工程基本概念3.4 需求工程的一些感悟 u不论是合同项目还是自主研发的产品，都必须开展需求开发和需求管理活动 。u

9、开发者对待需求工程的态度可分“被动型”、“主动型”和“领先型”三种 ，只有后两种才有可能开发出成功的产品。 “被动型”是指开发者被动地对待需求工程中的各项活动，能少干则少干，能 偷懒则偷懒。他们认为需求是用户的事情而不是自己的事情。开发过程中经常 发生需求变更，导致产品迷失方向，不是半途而废就是陷入半死不活的状态。 “主动型”是指开发者积极地开展需求工程中的各项活动。他们把获取准确的 需求当作自己的职责，会想尽一切办法克服需求开发和需求管理过程中的困难 ，而不是找借口推卸责任。俗话说“良好的开端是成功的一半”，“主动型” 需求工程是开发成功产品的必备条件。 “领先型”是需求工程的最高境界。开发

10、者发掘了连用户自己都没有意识到的 需求，导致用户跟着新产品跑而不是新产品围着用户转，这叫引导消费。需求 工程做到这个份上，才能使产品立于不败之地，长盛不衰。 Page 104. 需求开发的主要困难与对策4.1 知识技能问题 u应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说“隔行如隔山” ，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知 ”者。一个企业要谋求发展，不能总在做老的业务。人一生中会有许多充满挫折的“ 第一次”，不可以逃避。u当需求分析员缺乏应用域知识时，他该怎么办？ 首先他要有勇气做事，否则连实践的机会都没有。 其次他应当赶紧补习应用域知识，不

11、论是通过自学还是培训的方式，否则他很 难与用户交流。如果可能的话，开发方最好请既懂软件又懂应用域知识的行家 来帮忙。 4.2 态度问题 u相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢 骚，找出一堆用户的毛病。很多开发人员错误地以为： 需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告 诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问 题是用户产生的，应当由他们自己负责。 u用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可 以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致 需求

12、问题扩散到整个软件开发过程，产生太多的后患。 u软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有 限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。 Page 114. 需求开发的主要困难与对策4.3 合作关系 u如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲 惫。 u倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有他自己的 想法：我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不 成？我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧 。 u对于一些竞标项目，在合同未签订之前的需

13、求开发工作尤为困难。用户未必会买你的 产品，他不会投入很多精力来协助你搞需求开发。u需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼络住用户就能 成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力 。u开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目， 我们不能完全期望双方能够自发地建立起良好地合作关系，这样风险太大。 u开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与 义务”，即以协议的方式确定合作关系。“好话”和“丑话”都说在前头，这样能减 少今后的摩擦。如果条件允许的话，开发方最好为用户举办关于需求工

14、程的培训，这 样的培训将使用户明白需求的重要性以及忽视需求的危害性，从而促使他们积极友善 地参加需求工程中的各项活动。 Page 124. 需求开发的主要困难与对策u用户在需求工程中的“权利” 1. 有权要求开发方派遣资质合格的需求分析员和相关人员。 2. 有权要求开发方采用用户熟悉的语言来描述需求，即开发方必须提供用户看 得懂得需求文档。 3. 有权审查需求文档，并对有争议的需求作出决策。如果认为需求文档不能准 确地反映用户真实的意愿，可以拒绝在需求文档上签字。 4. 如果用户想要变更需求，有权要求开发方对该变更将产生的影响作出真实可 信的评估，以便用户决定是否变更需求。 u用户在需求工程中

15、的“义务” 1. 以积极友善的态度与开发方人员交流、协作，尽可能地为开发方人员提供工 作和生活上的便利。 2. 乐意接受需求分析员的采访，在不泄漏机密的前提下尽可能地回答需求分析 员的问题。 3. 在不泄漏机密的前提下，尽可能地向需求分析员提供与需求相关的材料。 4. 与需求分析员共同评审需求文档，确保需求文档准确地反映用户真实的意愿 。 Page 134. 需求开发的主要困难与对策4.4 用户说不清楚需求 u用户说不清楚需求是普遍现象，这是让开发人员头痛的大问题。 u有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求 。 例如开发方的营销人员水平比较高，他能够在用户不

16、清楚自己要什么的情况下 引导用户“消费”。 例如前些年全国各地的很多政府机构大搞网络建设。这些机构的领导和办公人 员大多数不清楚网络干什么用，就让开发人员替他们设想需求吧，反正是花公 家的钱。u有些用户虽然心里明白想要什么，但却说不清楚需求。 比如说买鞋子。我们非常了解自已的脚，但很难用语言说清楚脚的大小和形状 。通常拿鞋子去试，试穿时感觉到舒服才会买鞋。u需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连 累整个开发团队的。u无论是什么原因导致用户说不清楚需求，需求分析员必须设法搞清楚用户真正的需求 ，这是需求分析员的职责，也是职业的挑战。 Page 144. 需求开发的主要困难与对策4.5 双方误解需求 u人们在交流的时候，经常会发生“问非所求，答非所问”的事情。 u有时用户会把开发人员的建议或答复给想歪了： 有一个软件开发人员滔滔不绝地向用户讲解在“信息高速公路上做广告”的种种