第4章需求开发与需求管理.doc

《第4章需求开发与需求管理.doc》由会员分享，可在线阅读，更多相关《第4章需求开发与需求管理.doc（40页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、如有侵权，请联系网站删除，仅供学习与交流第4章需求开发与需求管理【精品文档】第 40 页目 录 第4章 需求开发与需求管理我们把所有与需求直接相关的活动通称为需求工程。需求工程是国内大学软件工程教育最薄弱的环节之一，这种教育模式下诞生的软件工程师会有这样的习惯：他们在开发产品时并不清楚究竟该做什么，但却在一直忙碌不停地开发。这不是个别的荒唐现象，这差不多成了国内软件业的痼疾。把责任推给学校显然无济于事。不论你是学生还是职业软件工程师，如果你不懂需求工程，你就不可能把产品做好。为了你的前途，你应该认真学习需求工程。令人遗憾的是大多数软件工程教科书喜欢以学术的形式论述需求，大讲结构化分析或面向对象

2、分析，并给出一堆模型和符号。然而大部分开发人员首先要学习的是如何调查需求、如何写需求文档等基本技能。需求工程是经典软件工程的核心内容，按理说早就研究得相当透彻了，奇怪的是人们就是学不好、用不好。可见需求工程的研究者似乎并不清楚实践者的真正需求，真让人哭笑不得。有个射击教练教出了不少神枪手，那些神枪手的枪法虽然很准，但老是打错人，有的甚至拿枪来自杀。你能说射击教练教和神枪手们合格吗？基于我自己学习以及培训别人的心得体会，我准备以说理的方式论述需求工程，期望能减轻软件开发人员心头长久的痛。4.1 什么是需求4.1.1 基本概念宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完

3、整的文档，该文档详细地说明了产品“必须或应当”做什么。所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。人们常问：“需求、设计、编程、测试四者究竟哪个重要？”这个问题不好回答。四者都是软件开发过程中必不可少的环节，光做好其中一个环节并不能产生好的系统，但是做坏了其中任何一个环节，必定对系统产生坏影响。若站在风险管理角度讲，我认为需求开发与管理是最重要的环节。因为需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。Frederick Brooks在他1987年的经典文章“No Silver Bullet”中阐述

4、了需求的重要性：开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。没有软件工程书籍不强调需求的重要性，也几乎没有软件开发人员不知道需求的重要性。但是读过书并不表示就能够熟练掌握，需求工作说起来容易做起来难啊。根据我的观察和切身体会，大部分软件开发人员并不知道如何把需求工作做好。在我为本公司软件开发人员写需求工程培训教材时，恰好遇到公司里一群高智商的开发人员集体犯需求观念错误的事情。我就把它写成案例，现炒现卖。4.1.2 需求案例本公司是国内一家

5、大型的电信设备供应商，本案例涉及6个机构A,B,C,D,E和F，它们之间的关系如图4-1所示。故事是这样的：A和B都是公司的研发机构，B做核心平台的研发，A做增值业务的研发（我在A工作）。C是公司的项目管理机构，负责立项、结项和研发经费管理。D是公司的一个销售机构。一年前，B研制了一种数据接入服务器的原型。B对A讲：“我们的接入服务器前途很好，请你们帮助开发网管软件（属于增值业务范畴），大家合作把产品做好，一起发财。”D对B和A讲：“你们把接入服务器和网管软件做好，我们负责卖，挣了钱大家一起分。”A想了想觉得机会难得，于是向C申请立项。立项后，A把该项目外包给一家专业做网管软件的公司E，期望半

6、年内完成。由于接入服务器是B的，于是A和E就派开发人员到B处搞需求分析。B的接入服务器并不成熟，老在变，三方折腾了好久，最终E用了一年时间把接入服务器的网管软件做出来了。E把网管软件交付给A，A付清了E的开发费用，再把网管软件交付给D，D再卖给客户F（某地电信局）。F对D讲：“你们的网管软件不是我们想要的东西，等你们把软件改好后我们再付钱。”D赶紧对A讲：“兄弟阿，货已经出手了，但是不对路，请赶紧把它改好，不然大家都没钱赚。”A很愤怒，怨天不公：“我们辛苦了一年，又花了很多钱，可是产品做完了却没人要，岂有此理！”祸不单行的是，C来找A的麻烦：“你们的项目延期半年多了，经费也用光了，请尽快结束项

7、目。”A的那位项目经理为此每天愁眉苦脸，他的上司请来几位参谋商量对策（包括我在内），设法把事情搞定。大家挖空心思只想出一个馊主意：既然套子是B下的，那么就把套子还给B。要设法把“那么好”的网管产品转让给B，只要B能给我们成本费，以后就跟B拜拜。C：项目管理机构F客户D销售机构E：网管软件承包商B：核心平台研发机构A：增值业务研发机构图4-1 本案例6个机构的关系图读者听了这个故事肯定既迷糊又惊诧：“哇，大公司是这样开发产品的啊？”。我也是在人家请我商量对策的时候，才知道有这样的事情。问题的根源在于没有搞清楚网管软件的需求，这都是B,A,E闭门造车惹的祸。三方开发团队里可是有不少的博士、硕士呐，

8、可是他们集体犯了如此低级的错误。最可悲的是，相关责任人关心的是如何把事情“搞定”，而不是深刻反思。估计类似的事情还会继续发生，每发生一次就损失成百上千万元。大公司再有钱也会给浪费光的。讲了这个故事，我不免有所感叹：需求问题有时如同爱情问题，真是“当局者迷，旁观者清”啊。我自己也是这么过来的，但愿以后不再犯类似的错误。4.2 了解用户“用户”（user）是一种泛称，它可细分为“客户”（customer）、“最终用户”（the end user）和“间接用户”（或称为关系人）。掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。如果软件是面向企

9、业用户的，那么客户与最终用户通常不是同一个人。如果软件是面向个人用户的，那么客户与最终用户通常是同一个人。由于客户是掏钱买软件的人，所以他是“上帝”。“现代营销学之父”菲利普科特勒所著的市场营销导论是这样描述客户的：客户永远是本公司的座上客。客户并不依赖我们，而我们却依赖客户。客户不是我们工作的障碍，而是我们工作的目标。我们并不因为服务于他而对他有恩，他却因为给予我们服务于他的机会而有恩于我们。客户不是我们要与之争辩和斗智的人。从未有人曾在与客户的争辩中获胜。客户是把他的欲望带给我们的人，因此我们的工作就是满足这些欲望，从而使客户和我们共同获益。科特勒2001, p25某饭店经理在解释“先有鸡

10、还是先有蛋”这个哲学问题时，精辟地阐述了客户的地位：如果顾客先点鸡，那么就先有鸡；如果顾客先点蛋，那么就先有蛋。软件开发方与客户打交道的主要目的是：一是获取需求，二是签合同。客户所说的需求一般比较宏观，更详细的需求应该从最终用户那里获取。对于大宗买卖，软件开发方会把“上帝”侍侯得舒舒服服，想方设法拿到合同。利益往往诱使人们搞不正之风，洽谈业务时少不了吃喝玩乐。我有位在国内大型电信企业搞销售的朋友，几乎每周都出差，带一帮客户老爷们游山玩水。这种做法差不多成了电信行业的“事实标准”。羊毛出在羊身上，奢侈花费最终将摊到老百姓的头上。为了避免被客户怀疑是在挖墙角，国内电信厂商一般不会招聘从电信局辞职的

11、人，足见厂商对客户的“敬重”。有不少客户精通业务，技术水平相当不错。跟这些客户打交道，开发方千万别派出只会吹牛皮的“酒囊饭袋”之辈。我曾听说有些项目负责人在竞标时，在技术方面竟然被客户反驳得哑口无言，着实丢脸。如果项目规模比较大，那么开发方与最终用户的来往就比较多。如从最终用户那里获取详细的需求，请最终用户试验软件，对最终用户进行培训等等。即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。有一次我们公司新员工上产品培训课，有位小领导匆匆赶来作指示：“隔壁班正在给电信局的员工们进行培训，他们都是上帝派来的，大家要注意形象。由于休息室空间有限，请大家自觉让位。午休时他们可以躺着睡，我们

12、只能坐在位置上打个盹儿.。”除了客户和最终用户之外，软件开发方不能疏忽另一类用户“间接用户”，千万别“大意失荆州”啊。间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响。例如，财务软件开发商在把“财务软件”卖给客户之前，这个“财务软件”必须得到国家财政部的批准。否则即使该软件的功能是完美的，但却被政府认为是非法的。所以国家财政部就是所有财务软件的间接用户，它不仅不付钱给财务软件开发商，反而要收取鉴定费、手续费等。同理，市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则软件开发商被逮住后戴上“非法经营”的帽子就惨了。4.3 需求工程4.3.1 基本概念

13、我们把所有与需求直接相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求工程的结构如图4-2所示，需求开发与需求管理的流程如图4-3所示。需求确认需求管理需求分析需求定义需求调查需求开发需求工程需求变更控制需求跟踪图4-2 需求工程结构图需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求开发过程域有3个主要活动： 需求调查。需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生用户需求说明书。 需求分析。需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。 需

14、求定义。需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生产品需求规格说明书。系统设计人员将依据产品需求规格说明书开展系统设计工作。需求开发过程域可分为两个阶段：“用户需求调查阶段”和“产品需求定义阶段”。两者在逻辑上存在先后关系，实际工作中二者通常是迭代进行的。我们把从事需求开发工作的人员称为需求分析员（也叫系统分析员），避免与其它开发人员混淆。“需求分析”活动贯穿于“用户需求调查”和“产品需求定义”两个阶段。需求开发过程域产生的主要文档有： 用户需求说明书 产品需求规格说明书（对于软件产品而言就是软件需求规格说明书）需求管理的目的是在客户与开发方之间建立对需求

15、的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求管理过程域有3个主要活动： 需求确认。需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。 需求跟踪。需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。 需求变更控制。需求变更控制是指依据“变更申请审批更改重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。需求管理过程域产生的主要文档有： 需求评审报告 需求跟踪报告 需求变更控制报告需求分析需求变更控制需求跟踪需求确认需求管理过程域输出

16、输出用户需求说明书产品需求定义用户需求调查产品需求规格说明书需求开发过程域图4-3 需求开发与需求管理流程图4.3.2 一些感悟本章通篇都在讲解需求工程的方法与技术，但是我担心读者辛苦地学习了，却可能在实践时用歪了。因此我要先谈谈自己对需求工程的一些感悟。需求工程感悟之一：不论是合同项目还是自主研发的产品，都必须开展需求开发和需求管理活动。对于合同项目，由于客户是已知的，需求开发和需求管理的各项活动可以有的放矢地开展。但是对于自主研发的产品而言，在产品没有卖出之前，并不存在真正的用户。由于用户是未知的，这就产生了令人困惑的问题：究竟该向谁调查需求？由谁来确认需求？很多开发人员不知不觉落入陷阱：

17、既然产品是自主研发的，反正目前没有用户，那么就让我们自己设想需求、自己确认需求吧！此念一起，祸根埋下。如此开发的产品十有八九会落得前述案例的下场。相似惨痛的教训实在太多，人们一定要清醒啊。即便待开发的产品尚未有真正的用户，但必定有潜在的用户（如果连潜在的用户都没有，那么就不要开发这样的产品，否则开发出来卖给谁？）。开发人员可以向潜在的用户们调查需求，请他们来确认需求。如果因条件限制，实在请不到潜在的用户，那么开发者可以把自己一分为二，既当用户又当分析员。注意在扮演用户这个角色时，应当忘记自己是开发者，一定要真正地站在用户的立场思考问题。一旦混淆角色，就会犯错误。需求工程感悟之二： 开发者对待需

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

19、的需求，导致用户跟着新产品跑而不是新产品围着用户转，这叫引导消费。需求工程做到这个份上，才能使产品立于不败之地，长盛不衰。4.4 需求开发的主要困难与对策4.4.1 知识技能问题绝大多数软件开发人员在学生时期的学习重点是计算机技术，他们毕业后到企业工作，主要任务依然是技术开发。由于专业和职业的原因，多数软件开发人员不擅长与用户交流。有些人技术很出色，但与用户在一起时显得很木讷，有劲使不出。所以企业不能期望他们能够无师自通地把需求开发工作做好。最好最快的解决办法是培训。如果你是项目的领导，既然你要把那么重要的工作（需求开发）交给他们去做，你就要舍得花钱对他们进行需求开发培训，帮助他们把需求开发工

20、作做好。即使需求分析员对需求调查、需求分析、需求定义已经有了丰富的经验，但他们的知识仍然可能不够用。应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。一个企业要谋求发展，不能总在做老的业务。人一生中会有许多充满挫折的“第一次”，不可以逃避。当需求分析员缺乏应用域知识时，他该怎么办？首先他要有勇气做事，否则连实践的机会都没有。其次他应当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙。如果需求分析员完全不了解应

21、用域，而用户几乎是个计算机盲，并且双方都不愿意主动了解对方领域的事情，这种状况下的需求开发很难成功。这世上没有人能够在知识面前耍花招，“不懂装懂，永远饭桶”。4.4.2 态度问题相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。这是普遍现象，并不是开发人员懒惰所造成的，而是不正确的观念误导了他们！很多开发人员错误地以为：需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不

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

23、项目，在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品，他不会投入很多精力来协助你搞需求开发。我是个软件开发人员，有时我又成为别的软件公司的用户，需求开发过程中的两类角色我都经历过，很有感受。举一例谈谈。公司曾有一个关于企业管理的项目要外包，项目金额不小，有数家软件公司来竞标。他们在做方案时，我是被访问的主要“用户”之一。我虽然是个用户，但真的不清楚这个项目的需求，说不出长篇大论，只能人家问什么我回答什么。由于我有重要的研发、管理工作要做（每个人都会觉得自己的工作很重要），不愿意老被别人的访问打扰，有时想回避。然而将心比心（或者说同病相怜吧），我也是开发人员，知道吃这碗饭不容易，我

24、理应帮他们一把。我想了一个办法：请我的几位小组成员轮流代我参加需求调查会议。我提醒组员：“我们要热情地为调查者解答疑问，同时要观察、体会他们的调查方法，学习好的、屏弃差的。因为我们以后也要向别人调查需求。”需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼络住用户就能成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力，否则会把事情搞砸的。在上例中，有些调查人员和我谈方案时，结果我发现他们的水平还不及我们小组的高，真不知道是谁给谁做方案。把他们一送出大门，我就打了“小报告”，他们的机会变得很渺茫。有些调查人员为了讨好我，不停地说好话、套近乎。说好话当然让我高兴

25、，但是听多了，让我感觉此人很圆滑，反而印象不好，于是应付了事。有些调查人员倒是很务实，一上来就问问题、填写调查报告，一点好话都不会说，让我提不起兴趣，我也不想多谈。有些感受挺有趣，每当我认真思考这些事情时，不禁心事重重。有太多的开发人员不懂得“如何做好”需求开发，这并不有趣，组建优秀的开发团队谈何容易啊！开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目，我们不能完全期望双方能够自发地建立起良好地合作关系，这样风险太大。文献 Wiegers2000, p12-p16 给出了一种好方法：开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协

26、议的方式确定合作关系。“好话”和“丑话”都说在前头，这样能减少今后的摩擦。如果条件允许的话，开发方最好为用户举办关于需求工程的培训，这样的培训将使用户明白需求的重要性以及忽视需求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。表4-1列举了用户在需求工程中的“权利与义务”，读者可以根据实际情况适当地修改。用户的权利1. 有权要求开发方派遣资质合格的需求分析员和相关人员。2. 有权要求开发方采用用户熟悉的语言来描述需求，即开发方必须提供用户看得懂得需求文档。3. 有权审查需求文档，并对有争议的需求作出决策。如果认为需求文档不能准确地反映用户真实的意愿，可以拒绝在需求文档上签字。4. 如

27、果用户想要变更需求，有权要求开发方对该变更将产生的影响作出真实可信的评估，以便用户决定是否变更需求。用户的义务1. 以积极友善的态度与开发方人员交流、协作，尽可能地为开发方人员提供工作和生活上的便利。2. 乐意接受需求分析员的采访，在不泄漏机密的前提下，尽可能地回答需求分析员的问题。3. 在不泄漏机密的前提下，尽可能地向需求分析员提供与需求相关的材料。4. 与需求分析员共同评审需求文档，确保需求文档准确地反映用户真实的意愿。5. 不轻易变更需求。如果需要变更需求的话，按照“需求变更控制规程”执行，而非强迫开发方接受。表4-1用户在需求工程中的“权利与义务”4.4.4 用户说不清楚需求用户说不清

28、楚需求是普遍现象，这是让开发人员头痛的大问题。有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求。开发人员可能觉得奇怪：用户自己都不知道要什么，为什么还要我们开发软件？这种现象有些时候是正常的，例如开发方的营销人员水平比较高，他能够在用户不清楚自己要什么的情况下引导用户“消费”。也有不正常的现象，例如前些年全国各地的很多政府机构大搞网络建设。这些机构的领导和办公人员大多数不清楚网络干什么用，就让开发人员替他们设想需求吧，反正是花公家的钱。有些用户虽然心里明白想要什么，但却说不清楚需求。读者可能很不以为然，用户不致于笨到这个地步吧？这不是聪明或笨的问题，是表达能力问题。举

29、个日常生活的事例，比如说买鞋子。我们非常了解自已的脚，但很难用语言说清楚脚的大小和形状。通常拿鞋子去试，试穿时感觉到舒服才会买鞋（居然也有神通广大的售货员，看一眼用户的手，就知道应该穿什么样的鞋）。真所谓“道可道，非常道。明可明，非常明。”需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连累整个开发团队的。无论是什么原因导致用户说不清楚需求，需求分析员必须设法搞清楚用户真正的需求，这是需求分析员的职责，也是职业的挑战。4.4.5 双方误解需求人们在交流的时候，经常会发生“问非所求，答非所问”的事情。有时用户会把开发人员的建议或答复给想歪了：有一个软件开发人员滔滔不绝地向

30、用户讲解在“信息高速公路上做广告”的种种好处，用户听得津津有味。最后，心动的用户对软件开发人员说：“好得很，就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。”而用户表达的需求，不同的开发人员可能有不同的理解。如果需求分析员误解了需求，那会导致后续的不少开发人员将错就错、白干活。就像作文写跑题了，写得再好也白搭。这类错误连高智商的外星人都不能避免：有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。有趣的是，车里住着一种叫作人的寄生虫，这些寄生虫完全控制了车。”不论是复杂的项目

31、还是简单的项目，需求分析员和用户都有可能误解需求。所以需求确认工作（属于需求管理）必不可少。4.4.6 开发人员写不好需求文档开发人员写不好需求文档的主要原因如下：l 需求调查工作不充分，获取的需求信息太少或者太乱，以至于写不成需求文档。古时候，一书生在考试前补习“写文章”，成天愁眉苦脸。其夫人甚为不解，问：“相公，你写文章比我生小孩还难吗？”书生长叹一声：“娘子你哪里知道我的难处啊！你生小孩时肚子里有东西，可我写文章时肚子里没东西啊。”所以要想写出好的需求文档，前提条件是把需求调查工作做好。l 开发人员写作能力比较差，虽然在调查过程中已经获得了不少需求信息，却写不出好的需求文档来。我可以毫不

32、夸张地说，国内90以上的软件开发人员，他们的写作能力远不及开发能力。提高开发人员写作能力的根本办法就是让他们多练习写文档，熟能生巧嘛。另外，企业应当提供合适的文档模板以及比较好的示例文档，尽可能地降低写作难度。4.4.7 用户经常变更需求需求变更通常会对项目的进度、人力资源、经费产生很大的影响，这是开发商非常畏惧的问题。如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。这种损失是由于双方工作失误造成的，双方应当好好反省，认真学习需求开发和管理的方法，避免再犯相似的

33、错误。如果由于市场变化而导致产品需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘若市场静如死水，那么开发商吃了“上一顿”就没有“下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。其实需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。所以需求变更控制是需求工程的重要活动，详见本章第11节的论述。4.5 如何开展需求调查4.5.1 需求调查规程开展需求调查不能学情人之间的浪漫做法“让我摸摸你的头发，感觉它是什么颜色。”需求调查的一般规程如表4-2所示。目的获取用户（客户与最终用户）的需求信息，经过分析后产生用户需求说明书。角色与职责需求分析员调查、分析用户

34、的需求，客户与最终用户提供必要的需求信息。启动准则需求分析员已经确定输入任何与用户需求相关的材料主要步骤第一步：准备调查第二步：调查与记录第三步：分析需求信息第四步：撰写用户需求说明书第五步：需求确认输出用户需求说明书结束准则需求分析员已经撰写完成用户需求说明书，确保无拼写、排版等错误。度量需求分析员统计工作量和上述文档的规模，汇报给项目经理。表4-2 需求调查的规程4.5.2 准备调查需求调查准备工作围绕三项展开：（1）调查什么？（2）通过什么方式去调查？（3）“何人”在“何时”调查？l 首先，需求分析员应当起草需求调查问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。问题表可

35、以有多份，随着调查的深入，问题表将不断地被细化。根据经验，用户通常没有耐心回答复杂的“论述题”，所以问题表应当以“选择题”和“是非题”为主。制定问题表最简便的方法就是从用户需求说明书的模板中提取需求问题。l 其次，需求分析员应当确定需求调查的方式，例如： 与用户交谈，向用户提问题。 参观用户的工作流程，观察用户的操作。 向用户群体发调查问卷。 与同行、专家交谈，听取他们的意见。 分析已经存在的同类软件产品，提取需求。 从行业标准、规则中提取需求。 从Internet上搜查相关资料。l 最后，需求分析员与被调查者建立联系，确定调查的时间、地点、人员等，撰写需求调查计划。要特别留意的是不要漏掉典型

36、的用户。4.5.3 调查与记录准备工作完毕后，需求分析员按照计划执行调查。在调查过程中随时记录（或存储）需求信息，建议采用表格的形式，如表4-3所示。需求标题1调查方式调查人调查对象时间、地点需求信息记录基本要素如“是什么”、“为什么”等表4-3 需求信息表格示例需求分析员与用户面谈时应当注意以下事项： 如果与用户约好了时间，切勿迟到或早退。要注意礼节，尽可能获得用户的好感，并为下次打扰他们埋下伏笔。 需求分析员应事先了解用户的身份、背景，以便随机应变。IT人士不可貌相，有些大企业的领导其外表很土气，象农民。如果你路上碰到他，以为是个勤杂工，说：“喂，老师傅，来帮我拎东西。”也许这笔生意就泡汤

37、了。 需求调查不象侦探推理那样从蛛丝马迹着手，应该先了解宏观问题，再了解细节问题。 如果双方气氛融洽，可以采用灵活的访谈形式，轻易不要打断用户的谈话。当双方对某些问题的交流合乎逻辑地结束后，即可继续讨论问题表中的其它问题。 尽可能避免为用户添麻烦，但也不能怕给用户添麻烦而降低需求调查的力度。 避免片面地听取某些用户的需求而忽视其它用户的需求。如果有些事情现场就能分析清楚，那么不要拖延到以后做。在调查需求的同时应当进行必要的需求分析，建议采用“问答分析法”（详见4.6.1节），尽可能确定每个需求的基本要素，如“是什么”、“为什么”等。4.5.4 撰写用户需求说明书需求分析员对收集到的所有需求信息

38、进行分析（方法详见4.6节），消除错误，归纳与总结共性的用户需求。然后按照指定的文档模板（见表4-3）撰写用户需求说明书，调查过程中获取的需求信息（见表4-2）可以作为用户需求说明书的附件。用户需求说明书撰写完毕之后，需求分析员应当邀请同行专家和用户（包括客户和最终用户）一起评审用户需求说明书，尽最大努力使用户需求说明书能够正确无误地反映用户的真实意愿。之后才进一步定义产品的需求，产生产品需求规格说明书。用户需求说明书与产品需求规格说明书的主要区别与联系是：（1）前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。（2）后者是前者的细化，更多地采用计算机

39、语言和图形符号来刻画需求，产品需求是软件系统设计的直接依据。（3）两者之间可能并不存在一一影射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据产品需求规格说明书来开发当前产品。用户需求说明书的参考模板见表4-4。用户需求说明书0. 文档介绍0.1文档目的0.2文档范围0.3读者对象0.4参考文档0.5术语与缩写解释1. 产品介绍提示：（1）说明产品是什么，什么用途。（2）介绍产品的开发背景。2. 产品面向的用户群体提示：（1）描述本产品面向的用户（客户、最终用户）的特征，（2）说明本产品将给他们带来什么好处？

40、他们选择本产品的可能性有多大？3. 产品应当遵循的标准或规范提示：阐述本产品应当遵循什么标准、规范或业务规则（Business Rules），违反标准、规范或业务规则的产品通常不太可能被接受。4. 产品的功能性需求功能类别功能名称、标识符描述Feature AFunction A.1Feature BFunction B.1Feature CFunction C.15. 产品的非功能性需求需求类别需求名称、标识符描述用户界面需求软硬件需求质量需求6. 其它需求附录：用户需求调查报告表4-4 用户需求说明书的参考模板4.6 如何进行需求分析为了得到用户的金钱，企业不得不鼓吹：用户就是上帝，用户永

41、远是正确的。谁都知道这不是真的。事实上，很多时候用户说不清楚需求、会说错需求或者提出一些无法实现的需求。需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。需求分析是需求开发过程中最费脑子的工作。分析方法大体有两类：“问答分析法”和“建模分析法”。后者技术性比较强，写出来有学术味，故大多数软件工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易用（保你一学就会），很有实用价值。根据作者的经验，“问答分析法”比较适合于用户需求调查阶段，而“建模分析法”比较适合于产品需求定义阶段。4.6.1 问答分析法问答分析方法很

42、简单：刨根究底地问，如果问题都被解答了，那么需求也就分析清楚了。一个人可以“自问自答”地分析需求，几个人分析需求则称为“研讨”。问答分析最重要的问题是：“是什么”和“为什么”。每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。其它常见的问题有： 需求存在二义性吗？ 需求文档的上下文有矛盾吗？ 需求完备吗？ 需求是必要的吗？ 需求可实现吗？ 需求可验证吗？ 需求的优先级确定了吗？4.6.2 建模分析法人们

43、都有这样地感受：有些时候用语言描述某个问题特别费劲，而采用图形则使人一目了然，所谓“一图低千言”就是这个道理。在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求。建模分析方法主要有两大类：“结构化分析法”和“面向对象分析法”。4.6.2.1 结构化分析法软件的建模分析兴起于20世纪60年代末期和70年代初期。结构化分析方法并不是由里程碑式的明确地涉及这个主题的一篇文章或者一本著作引入的，它也不是被所有使用者一致采用的单一方法。相反地，它是几乎发展了20多年的一个混合物。结构化分析方法在7

44、0年代和80年代非常流行，相关论著很多。对结构化分析方法有较大贡献的学者有DeMarco, Gane, Sarsen, Yourdon, Constantine, Ward, Mellor, Hatly, Pirbhai等人。文献Pressmen99, p206-p214对结构化分析方法作了高度概括（如图4-4所示），我们不妨称之为“一个中心三种图”： “数据字典”是中心，它包含了软件中所有数据对象的描述。 “实体关系图”是用图形符号来标识数据对象以及它们之间的关系。 “数据流图”指明了数据在系统中移动时如何被变换。 “状态变迁图”表示了系统存在的各种状态以及它们之间的变迁方式。数据字典实体关

45、系图数据流图状态变迁图图4-4 结构化分析方法示意图4.6.2.2 面向对象分析法面向对象分析设计（OOAD）方法兴起于20世纪80年代，从90年代起至今它已经在分析设计领域占据了无可争议的主流地位。我在读本科（90年至94年）时就充分地感受到了人们对“面向对象”的狂热。关于“面向对象”的课堂、学术报告常常人满为患。搞软件研发的人都“言必谈对象”，并引以为荣。面向对象分析设计领域有一些比较著名的学派，如： Coad和Yourdon学派，其代表作为Coad91。 Booch学派，其代表作为Booch94。 Jocobson学派，其代表作为Jacobson92。 Rumbaugh学派，其代表作为R

46、umbaugh91。有趣的是，这些学派的掌门人就像上帝、真主、如来佛，他们用各自的方式定义了这个世界，并留下一堆经书来解释这个世界。这种混乱的局面被学术界称为百家争鸣，每年诞生了许多论著和教授。叫苦的是软件企业和开发人员：没有统一的方法，不好干活啊！终于等到了那一天，Rational公司招纳了Booch, Jocobson, Rumbaugh，这三位“面向对象”业界的老大强强联手，制定了“统一建模语言”（UML）。1997年11月，UML被国际对象管理组织（OMG）采纳，此后UML成为OOAD建模语言的国际标准。UML吸取了各种OOAD方法的精髓，对于OOAD中的语义、图形表示法和使用规则作了完整而详细的定义。UML的建模能力超过了以往任何一种OOAD方法，当然其复杂性也随之膨胀。大多数软件开发人员没有兴趣阅读枯燥乏味的UML文档（如Rumbaugh99）。真正使UML流行的是Rational公司基于UML的建模工具Rose。Rose易学易用，它能交互式地构建类图、用例图、构件图、部署图、状态图、活动图、顺序图、协作图等等，深得开发人员的喜爱。介绍UML和Rose的书籍非常多，读者自己选择、学习，这里不再论述。4.6.2.3 恰当地使用图形符号现代建模工具如Rose有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文