《第4章需求开发与需求管理》由会员分享，可在线阅读，更多相关《第4章需求开发与需求管理（41页珍藏版）》请在金锄头文库上搜索。
1、如果您需要使用本文档，请点击下载按钮下载!目 录 第4章 需求开发与需求管理34.1 什么是需求44.1.1 基本概念44.1.2 需求案例44.2 了解用户64.3 需求工程74.3.1 基本概念74.3.2 一些感悟84.4 需求开发的主要困难与对策94.4.1 知识技能问题94.4.2 态度问题104.4.3 合作关系104.4.4 用户说不清楚需求124.4.5 双方误解需求124.4.6 开发人员写不好需求文档134.4.7 用户经常变更需求134.5 如何开展需求调查134.5.1 需求调查规程134.5.2 准备调查144.5.3 调查与记录144.5.4 撰写用户需求说明书15
2、4.6 如何进行需求分析174.6.1 问答分析法174.6.2 建模分析法174.6.2.1 结构化分析法184.6.2.2 面向对象分析法184.6.2.3 恰当地使用图形符号194.6.3 作出决策194.7 什么是好的产品需求规格说明书204.7.1 正确204.7.2 清楚204.7.3 无二义性204.7.4 一致211 / 41Page 1 of 41如果您需要使用本文档，请点击下载按钮下载!4.7.5 必要214.7.6 完备214.7.7 可实现224.7.8 可验证224.7.9 确定优先级224.7.10 阐述“做什么”而不是“怎么做”234.8 如何定义产品需求234.
3、8.1 规程234.8.2 软件需求规格说明书的模板244.9 需求确认264.9.1 规程264.9.2 需求评审264.9.3 需求承诺284.10 需求跟踪294.11 需求变更控制304.12 CMMI对应规范324.12.1 需求开发过程域的目标与实践324.12.2 需求管理过程域的目标与实践334.13 需求建模工具334.14 需求管理工具344.15 应用示例344.15.1 成功的示例344.15.2 失败的示例344.16 小结342 / 41Page 2 of 41如果您需要使用本文档，请点击下载按钮下载!第4章 需求开发与需求管理我们把所有与需求直接相关的活动通称为需
4、求工程。需求工程是国内大学软件工程教育最薄弱的环节之一，这种教育模式下诞生的软件工程师会有这样的习惯：他们在开发产品时并不清楚究竟该做什么，但却在一直忙碌不停地开发。这不是个别的荒唐现象，这差不多成了国内软件业的痼疾。把责任推给学校显然无济于事。不论你是学生还是职业软件工程师，如果你不懂需求工程，你就不可能把产品做好。为了你的前途，你应该认真学习需求工程。令人遗憾的是大多数软件工程教科书喜欢以学术的形式论述需求，大讲结构化分析或面向对象分析，并给出一堆模型和符号。然而大部分开发人员首先要学习的是如何调查需求、如何写需求文档等基本技能。需求工程是经典软件工程的核心内容，按理说早就研究得相当透彻了
5、，奇怪的是人们就是学不好、用不好。可见需求工程的研究者似乎并不清楚实践者的真正需求，真让人哭笑不得。有个射击教练教出了不少神枪手，那些神枪手的枪法虽然很准，但老是打错人，有的甚至拿枪来自杀。你能说射击教练教和神枪手们合格吗？基于我自己学习以及培训别人的心得体会，我准备以说理的方式论述需求工程，期望能减轻软件开发人员心头长久的痛。3 / 41Page 3 of 41如果您需要使用本文档，请点击下载按钮下载!4.1 什么是需求4.1.1 基本概念宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。所以如果只有一些零碎的对话、
6、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。人们常问：“需求、设计、编程、测试四者究竟哪个重要？”这个问题不好回答。四者都是软件开发过程中必不可少的环节，光做好其中一个环节并不能产生好的系统，但是做坏了其中任何一个环节，必定对系统产生坏影响。若站在风险管理角度讲，我认为需求开发与管理是最重要的环节。因为需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。Frederick Brooks在他1987年的经典文章“No Silver Bullet”中阐述了需求的重要性：开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是
7、编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。没有软件工程书籍不强调需求的重要性，也几乎没有软件开发人员不知道需求的重要性。但是读过书并不表示就能够熟练掌握，需求工作说起来容易做起来难啊。根据我的观察和切身体会，大部分软件开发人员并不知道如何把需求工作做好。在我为本公司软件开发人员写需求工程培训教材时，恰好遇到公司里一群高智商的开发人员集体犯需求观念错误的事情。我就把它写成案例，现炒现卖。4.1.2 需求案例本公司是国内一家大型的电信设备供应商，本案例涉及6个机构A,B,C,D,E和F，它们之间的关系如图
8、4-1所示。故事是这样的：A和B都是公司的研发机构，B做核心平台的研发，A做增值业务的研发（我在A工作）。C是公司的项目管理机构，负责立项、结项和研发经费管理。D是公司的一个销售机构。一年前，B研制了一种数据接入服务器的原型。B对A讲：“我们的接入服务器前途很好，请你们帮助开发网管软件（属于增值业务范畴），大家合作把产品做好，一起发财。”D对B和A讲：“你们把接入服务器和网管软件做好，我们负责卖，挣了钱大家一起分。”4 / 41Page 4 of 41如果您需要使用本文档，请点击下载按钮下载!A想了想觉得机会难得，于是向C申请立项。立项后，A把该项目外包给一家专业做网管软件的公司E，期望半年内
9、完成。由于接入服务器是B的，于是A和E就派开发人员到B处搞需求分析。B的接入服务器并不成熟，老在变，三方折腾了好久，最终E用了一年时间把接入服务器的网管软件做出来了。E把网管软件交付给A，A付清了E的开发费用，再把网管软件交付给D，D再卖给客户F（某地电信局）。F对D讲：“你们的网管软件不是我们想要的东西，等你们把软件改好后我们再付钱。”D赶紧对A讲：“兄弟阿，货已经出手了，但是不对路，请赶紧把它改好，不然大家都没钱赚。”A很愤怒，怨天不公：“我们辛苦了一年，又花了很多钱，可是产品做完了却没人要，岂有此理！”祸不单行的是，C来找A的麻烦：“你们的项目延期半年多了，经费也用光了，请尽快结束项目。
10、”A的那位项目经理为此每天愁眉苦脸，他的上司请来几位参谋商量对策（包括我在内），设法把事情搞定。大家挖空心思只想出一个馊主意：既然套子是B下的，那么就把套子还给B。要设法把“那么好”的网管产品转让给B，只要B能给我们成本费，以后就跟B拜拜。C：项目管理机构F客户D销售机构E：网管软件承包商B：核心平台研发机构A：增值业务研发机构图4-1 本案例6个机构的关系图读者听了这个故事肯定既迷糊又惊诧：“哇，大公司是这样开发产品的啊？”。我也是在人家请我商量对策的时候，才知道有这样的事情。问题的根源在于没有搞清楚网管软件的需求，这都是B,A,E闭门造车惹的祸。三方开发团队里可是有不少的博士、硕士呐，可是
11、他们集体犯了如此低级的错误。最可悲的是，相关责任人关心的是如何把事情“搞定”，而不是深刻反思。估计类似的事情还会继续发生，每发生一次就损失成百上千万元。大公司再有钱也会给浪费光的。讲了这个故事，我不免有所感叹：需求问题有时如同爱情问题，真是“当局者迷，旁观者清”啊。我自己也是这么过来的，但愿以后不再犯类似的错误。5 / 41Page 5 of 41如果您需要使用本文档，请点击下载按钮下载!4.2 了解用户“用户”（user）是一种泛称，它可细分为“客户”（customer）、“最终用户”（the end user）和“间接用户”（或称为关系人）。掏钱买软件的用户称为客户，而真正操作软件的用户叫
12、最终用户。客户与最终用户可能是同一个人也可能不是同一个人。如果软件是面向企业用户的，那么客户与最终用户通常不是同一个人。如果软件是面向个人用户的，那么客户与最终用户通常是同一个人。由于客户是掏钱买软件的人，所以他是“上帝”。“现代营销学之父”菲利普科特勒所著的市场营销导论是这样描述客户的：客户永远是本公司的座上客。客户并不依赖我们，而我们却依赖客户。客户不是我们工作的障碍，而是我们工作的目标。我们并不因为服务于他而对他有恩，他却因为给予我们服务于他的机会而有恩于我们。客户不是我们要与之争辩和斗智的人。从未有人曾在与客户的争辩中获胜。客户是把他的欲望带给我们的人，因此我们的工作就是满足这些欲望，
13、从而使客户和我们共同获益。科特勒2001, p25某饭店经理在解释“先有鸡还是先有蛋”这个哲学问题时，精辟地阐述了客户的地位：如果顾客先点鸡，那么就先有鸡；如果顾客先点蛋，那么就先有蛋。软件开发方与客户打交道的主要目的是：一是获取需求，二是签合同。客户所说的需求一般比较宏观，更详细的需求应该从最终用户那里获取。对于大宗买卖，软件开发方会把“上帝”侍侯得舒舒服服，想方设法拿到合同。利益往往诱使人们搞不正之风，洽谈业务时少不了吃喝玩乐。我有位在国内大型电信企业搞销售的朋友，几乎每周都出差，带一帮客户老爷们游山玩水。这种做法差不多成了电信行业的“事实标准”。羊毛出在羊身上，奢侈花费最终将摊到老百姓的
14、头上。为了避免被客户怀疑是在挖墙角，国内电信厂商一般不会招聘从电信局辞职的人，足见厂商对客户的“敬重”。有不少客户精通业务，技术水平相当不错。跟这些客户打交道，开发方千万别派出只会吹牛皮的“酒囊饭袋”之辈。我曾听说有些项目负责人在竞标时，在技术方面竟然被客户反驳得哑口无言，着实丢脸。如果项目规模比较大，那么开发方与最终用户的来往就比较多。如从最终用户那里获取详细的需求，请最终用户试验软件，对最终用户进行培训等等。即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。有一次我们公司新员工上产品培训课，有位小领导匆匆赶来作指示：“隔壁班正在给电信局的员工们进行培训，他们都是上帝派来的，大家
15、要注意形象。由于休息室空间有限，请大家自觉让位。午休时他们可以躺着睡，我们只能坐在位置上打个盹儿.。”除了客户和最终用户之外，软件开发方不能疏忽另一类用户“间接用户”，千万别“大意失荆州”啊。间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响。例如，财务软件开发商在把“财务软件”卖给客户之前，这个“财务软件”必须得到国家财政部的批准。否则即使该软件的功能是完美的，但却被政府认为是非法的。所以国家财政部就是所有财务软件的间接用户，它不仅不付钱给财务软件开发商，反而要收取鉴定费、手续费等。同理，市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则软件开发商被逮住后戴上7 / 41Page 7 of 41如果您需要使用本文档，请点击下载按钮下载!“非法经营”的帽子就惨了。4.3 需求工程4.3.1 基本概念我们把所有与需求直接相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求工
