第4章 需求开发与需求管理.docx
《第4章 需求开发与需求管理.docx》由会员分享，可在线阅读，更多相关《第4章 需求开发与需求管理.docx（49页珍藏版）》请在冰豆网上搜索。
第4章需求开发与需求管理
目录
第4章需求开发与需求管理3
4.1什么是需求4
4.1.1基本概念4
4.1.2需求案例4
4.2了解用户6
4.3需求工程7
4.3.1基本概念7
4.3.2一些感悟8
4.4需求开发的主要困难与对策9
4.4.1知识技能问题9
4.4.2态度问题10
4.4.3合作关系10
4.4.4用户说不清楚需求12
4.4.5双方误解需求12
4.4.6开发人员写不好需求文档13
4.4.7用户经常变更需求13
4.5如何开展需求调查13
4.5.1需求调查规程13
4.5.2准备调查14
4.5.3调查与记录14
4.5.4撰写用户需求说明书15
4.6如何进行需求分析17
4.6.1问答分析法17
4.6.2建模分析法17
4.6.2.1结构化分析法18
4.6.2.2面向对象分析法18
4.6.2.3恰当地使用图形符号19
4.6.3作出决策19
4.7什么是好的产品需求规格说明书20
4.7.1正确20
4.7.2清楚20
4.7.3无二义性20
4.7.4一致21
4.7.5必要21
4.7.6完备21
4.7.7可实现22
4.7.8可验证22
4.7.9确定优先级22
4.7.10阐述“做什么”而不是“怎么做”23
4.8如何定义产品需求23
4.8.1规程23
4.8.2软件需求规格说明书的模板24
4.9需求确认26
4.9.1规程26
4.9.2需求评审26
4.9.3需求承诺28
4.10需求跟踪29
4.11需求变更控制30
4.12CMMI对应规范32
4.12.1需求开发过程域的目标与实践32
4.12.2需求管理过程域的目标与实践33
4.13需求建模工具33
4.14需求管理工具34
4.15应用示例34
4.15.1成功的示例34
4.15.2失败的示例34
4.16小结34
第4章需求开发与需求管理
我们把所有与需求直接相关的活动通称为需求工程。
需求工程是国内大学软件工程教育最薄弱的环节之一，这种教育模式下诞生的软件工程师会有这样的习惯：
他们在开发产品时并不清楚究竟该做什么，但却在一直忙碌不停地开发。
这不是个别的荒唐现象，这差不多成了国内软件业的痼疾。
把责任推给学校显然无济于事。
不论你是学生还是职业软件工程师，如果你不懂需求工程，你就不可能把产品做好。
为了你的前途，你应该认真学习需求工程。
令人遗憾的是大多数软件工程教科书喜欢以学术的形式论述需求，大讲结构化分析或面向对象分析，并给出一堆模型和符号。
然而大部分开发人员首先要学习的是如何调查需求、如何写需求文档等基本技能。
需求工程是经典软件工程的核心内容，按理说早就研究得相当透彻了，奇怪的是人们就是学不好、用不好。
可见需求工程的研究者似乎并不清楚实践者的真正需求，真让人哭笑不得。
有个射击教练教出了不少神枪手，那些神枪手的枪法虽然很准，但老是打错人，有的甚至拿枪来自杀。
你能说射击教练教和神枪手们合格吗？
基于我自己学习以及培训别人的心得体会，我准备以说理的方式论述需求工程，期望能减轻软件开发人员心头长久的痛。
4.1什么是需求
4.1.1基本概念
宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。
所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。
人们常问：
“需求、设计、编程、测试四者究竟哪个重要？
”
这个问题不好回答。
四者都是软件开发过程中必不可少的环节，光做好其中一个环节并不能产生好的系统，但是做坏了其中任何一个环节，必定对系统产生坏影响。
若站在风险管理角度讲，我认为需求开发与管理是最重要的环节。
因为需求是产品的根源，需求工作的优劣对产品影响最大。
就像一条河流，如果源头被污染了，那么整条河流也就被污染了。
FrederickBrooks在他1987年的经典文章“NoSilverBullet”中阐述了需求的重要性：
开发软件系统最困难的部分就是准确说明开发什么。
最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。
此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。
没有软件工程书籍不强调需求的重要性，也几乎没有软件开发人员不知道需求的重要性。
但是读过书并不表示就能够熟练掌握，需求工作说起来容易做起来难啊。
根据我的观察和切身体会，大部分软件开发人员并不知道如何把需求工作做好。
在我为本公司软件开发人员写需求工程培训教材时，恰好遇到公司里一群高智商的开发人员集体犯需求观念错误的事情。
我就把它写成案例，现炒现卖。
4.1.2需求案例
本公司是国内一家大型的电信设备供应商，本案例涉及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，期望半年内完成。
由于接入服务器是B的，于是A和E就派开发人员到B处搞需求分析。
B的接入服务器并不成熟，老在变，三方折腾了好久，最终E用了一年时间把接入服务器的网管软件做出来了。
E把网管软件交付给A，A付清了E的开发费用，再把网管软件交付给D，D再卖给客户F（某地电信局）。
F对D讲：
“你们的网管软件不是我们想要的东西，等你们把软件改好后我们再付钱。
”
D赶紧对A讲：
“兄弟阿，货已经出手了，但是不对路，请赶紧把它改好，不然大家都没钱赚。
”
A很愤怒，怨天不公：
“我们辛苦了一年，又花了很多钱，可是产品做完了却没人要，岂有此理！
”
祸不单行的是，C来找A的麻烦：
“你们的项目延期半年多了，经费也用光了，请尽快结束项目。
”
A的那位项目经理为此每天愁眉苦脸，他的上司请来几位参谋商量对策（包括我在内），设法把事情搞定。
大家挖空心思只想出一个馊主意：
既然套子是B下的，那么就把套子还给B。
要设法把“那么好”的网管产品转让给B，只要B能给我们成本费，以后就跟B拜拜。
C：
项目管理机构
F
客户
D销售机构
E：
网管软件承包商
B：
核心平台研发机构
A：
增值业务研发机构
图4-1本案例6个机构的关系图
读者听了这个故事肯定既迷糊又惊诧：
“哇，大公司是这样开发产品的啊？
”。
我也是在人家请我商量对策的时候，才知道有这样的事情。
问题的根源在于没有搞清楚网管软件的需求，这都是B,A,E闭门造车惹的祸。
三方开发团队里可是有不少的博士、硕士呐，可是他们集体犯了如此低级的错误。
最可悲的是，相关责任人关心的是如何把事情“搞定”，而不是深刻反思。
估计类似的事情还会继续发生，每发生一次就损失成百上千万元。
大公司再有钱也会给浪费光的。
讲了这个故事，我不免有所感叹：
需求问题有时如同爱情问题，真是“当局者迷，旁观者清”啊。
我自己也是这么过来的，但愿以后不再犯类似的错误。
4.2了解用户
“用户”（user）是一种泛称，它可细分为“客户”（customer）、“最终用户”（theenduser）和“间接用户”（或称为关系人）。
掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。
客户与最终用户可能是同一个人也可能不是同一个人。
如果软件是面向企业用户的，那么客户与最终用户通常不是同一个人。
如果软件是面向个人用户的，那么客户与最终用户通常是同一个人。
由于客户是掏钱买软件的人，所以他是“上帝”。
“现代营销学之父”菲利普•科特勒所著的《市场营销导论》是这样描述客户的：
客户永远是本公司的座上客。
客户并不依赖我们，而我们却依赖客户。
客户不是我们工作的障碍，而是我们工作的目标。
我们并不因为服务于他而对他有恩，他却因为给予我们服务于他的机会而有恩于我们。
客户不是我们要与之争辩和斗智的人。
从未有人曾在与客户的争辩中获胜。
客户是把他的欲望带给我们的人，因此我们的工作就是满足这些欲望，从而使客户和我们共同获益。
[科特勒2001,p25]
某饭店经理在解释“先有鸡还是先有蛋”这个哲学问题时，精辟地阐述了客户的地位：
如果顾客先点鸡，那么就先有鸡；如果顾客先点蛋，那么就先有蛋。
软件开发方与客户打交道的主要目的是：
一是获取需求，二是签合同。
客户所说的需求一般比较宏观，更详细的需求应该从最终用户那里获取。
对于大宗买卖，软件开发方会把“上帝”侍侯得舒舒服服，想方设法拿到合同。
利益往往诱使人们搞不正之风，洽谈业务时少不了吃喝玩乐。
我有位在国内大型电信企业搞销售的朋友，几乎每周都出差，带一帮客户老爷们游山玩水。
这种做法差不多成了电信行业的“事实标准”。
羊毛出在羊身上，奢侈花费最终将摊到老百姓的头上。
为了避免被客户怀疑是在挖墙角，国内电信厂商一般不会招聘从电信局辞职的人，足见厂商对客户的“敬重”。
有不少客户精通业务，技术水平相当不错。
跟这些客户打交道，开发方千万别派出只会吹牛皮的“酒囊饭袋”之辈。
我曾听说有些项目负责人在竞标时，在技术方面竟然被客户反驳得哑口无言，着实丢脸。
如果项目规模比较大，那么开发方与最终用户的来往就比较多。
如从最终用户那里获取详细的需求，请最终用户试验软件，对最终用户进行培训等等。
即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。
有一次我们公司新员工上产品培训课，有位小领导匆匆赶来作指示：
“隔壁班正在给电信局的员工们进行培训，他们都是上帝派来的，大家要注意形象。
由于休息室空间有限，请大家自觉让位。
午休时他们可以躺着睡，我们只能坐在位置上打个盹儿…….。
”
除了客户和最终用户之外，软件开发方不能疏忽另一类用户——“间接用户”，千万别“大意失荆州”啊。
间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响。
例如，财务软件开发商在把“财务软件”卖给客户之前，这个“财务软件”必须得到国家财政部的批准。
否则即使该软件的功能是完美的，但却被政府认为是非法的。
所以国家财政部就是所有财务软件的间接用户，它不仅不付钱给财务软件开发商，反而要收取鉴定费、手续费等。
同理，市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则软件开发商被逮住后戴上“非法经营”的帽子就惨了。
4.3需求工程
4.3.1基本概念
我们把所有与需求直接相关的活动通称为需求工程。
需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。
需求工程的结构如图4-2所示，需求开发与需求管理的流程如图4-3所示。
需求确认
需求管理
需求分析
需求定义
需求调查
需求开发
需求工程
需求变更控制
需求跟踪
图4-2需求工程结构图
需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。
需求开发过程域有3个主要活动：
✧需求调查。
需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。
✧需求分析。
需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。
常见的需求分析方法有“问答分析法”和“建模分析法”两类。
✧需求定义。
需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。
系统设计人员将依据《产品需求规格说明书》开展系统设计工作。
需求开发过程域可分为两个阶段：
“用户需求调查阶段”和“产品需求定义阶段”。
两者在逻辑上存在先后关系，实际工作中二者通常是迭代进行的。
我们把从事需求开发工作的人员称为需求分析员（也叫系统分析员），避免与其它开发人员混淆。
“需求分析”活动贯穿于“用户需求调查”和“产品需求定义”两个阶段。
需求开发过程域产生的主要文档有：
✧《用户需求说明书》
✧《产品需求规格说明书》（对于软件产品而言就是《软件需求规格说明书》）
需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。
需求管理过程域有3个主要活动：
✧需求确认。
需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。
✧需求跟踪。
需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。
✧需求变更控制。
需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。
需求管理过程域产生的主要文档有：
✧《需求评审报告》
✧《需求跟踪报告》
✧《需求变更控制报告》
需求
变更
控制
需求跟踪
需求确认
需求
管理
过程域
输出
输出
产品需求定义
用户需求调查
需求
开发
过程域
图4-3需求开发与需求管理流程图
4.3.2一些感悟
本章通篇都在讲解需求工程的方法与技术，但是我担心读者辛苦地学习了，却可能在实践时用歪了。
因此我要先谈谈自己对需求工程的一些感悟。
需求工程感悟之一：
不论是合同项目还是自主研发的产品，都必须开展需求开发和需求管理活动。
对于合同项目，由于客户是已知的，需求开发和需求管理的各项活动可以有的放矢地开展。
但是对于自主研发的产品而言，在产品没有卖出之前，并不存在真正的用户。
由于用户是未知的，这就产生了令人困惑的问题：
究竟该向谁调查需求？
由谁来确认需求？
很多开发人员不知不觉落入陷阱：
既然产品是自主研发的，反正目前没有用户，那么就让我们自己设想需求、自己确认需求吧！
此念一起，祸根埋下。
如此开发的产品十有八九会落得前述案例的下场。
相似惨痛的教训实在太多，人们一定要清醒啊。
即便待开发的产品尚未有真正的用户，但必定有潜在的用户（如果连潜在的用户都没有，那么就不要开发这样的产品，否则开发出来卖给谁？
）。
开发人员可以向潜在的用户们调查需求，请他们来确认需求。
如果因条件限制，实在请不到潜在的用户，那么开发者可以把自己一分为二，既当用户又当分析员。
注意在扮演用户这个角色时，应当忘记自己是开发者，一定要真正地站在用户的立场思考问题。
一旦混淆角色，就会犯错误。
需求工程感悟之二：
开发者对待需求工程的态度可分“被动型”、“主动型”和“领先型”三种，只有后两种才有可能开发出成功的产品。
“被动型”是指开发者被动地对待需求工程中的各项活动，能少干则少干，能偷懒则偷懒。
他们认为需求是用户的事情而不是自己的事情。
开发过程中经常发生需求变更，导致产品迷失方向，不是半途而废就是陷入半死不活的状态。
“主动型”是指开发者积极地开展需求工程中的各项活动。
他们把获取准确的需求当作自己的职责，会想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。
俗话说“良好的开端是成功的一半”，“主动型”需求工程是开发成功产品的必备条件。
“领先型”是需求工程的最高境界。
开发者发掘了连用户自己都没有意识到的需求，导致用户跟着新产品跑而不是新产品围着用户转，这叫引导消费。
需求工程做到这个份上，才能使产品立于不败之地，长盛不衰。
4.4需求开发的主要困难与对策
4.4.1知识技能问题
绝大多数软件开发人员在学生时期的学习重点是计算机技术，他们毕业后到企业工作，主要任务依然是技术开发。
由于专业和职业的原因，多数软件开发人员不擅长与用户交流。
有些人技术很出色，但与用户在一起时显得很木讷，有劲使不出。
所以企业不能期望他们能够无师自通地把需求开发工作做好。
最好最快的解决办法是培训。
如果你是项目的领导，既然你要把那么重要的工作（需求开发）交给他们去做，你就要舍得花钱对他们进行需求开发培训，帮助他们把需求开发工作做好。
即使需求分析员对需求调查、需求分析、需求定义已经有了丰富的经验，但他们的知识仍然可能不够用。
应用域的知识是无边无际的，任何人都不可能是“万事通”。
俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。
一个企业要谋求发展，不能总在做老的业务。
人一生中会有许多充满挫折的“第一次”，不可以逃避。
当需求分析员缺乏应用域知识时，他该怎么办？
首先他要有勇气做事，否则连实践的机会都没有。
其次他应当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。
如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙。
如果需求分析员完全不了解应用域，而用户几乎是个计算机盲，并且双方都不愿意主动了解对方领域的事情，这种状况下的需求开发很难成功。
这世上没有人能够在知识面前耍花招，“不懂装懂，永远饭桶”。
4.4.2态度问题
相当多的开发人员习惯于被动地对待需求开发。
每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。
这是普遍现象，并不是开发人员懒惰所造成的，而是不正确的观念误导了他们！
很多开发人员错误地以为：
需求是用户的事情，不是我们的事情。
我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？
如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。
用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。
可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。
软件企业的领导应当给具有错误观念的开发人员们洗脑：
需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。
4.4.3合作关系
如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲惫。
倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。
因为用户有他自己的想法：
我回答了你们的问题，讲了该讲的。
我们付钱给你们，难道还要我伺候你们不成？
我还要干自己的事情，别打扰我了。
你们自己想办法把活干好吧 ……。
对于一些竞标项目，在合同未签订之前的需求开发工作尤为困难。
用户未必会买你的产品，他不会投入很多精力来协助你搞需求开发。
我是个软件开发人员，有时我又成为别的软件公司的用户，需求开发过程中的两类角色我都经历过，很有感受。
举一例谈谈。
公司曾有一个关于企业管理的项目要外包，项目金额不小，有数家软件公司来竞标。
他们在做方案时，我是被访问的主要“用户”之一。
我虽然是个用户，但真的不清楚这个项目的需求，说不出长篇大论，只能人家问什么我回答什么。
由于我有重要的研发、管理工作要做（每个人都会觉得自己的工作很重要），不愿意老被别人的访问打扰，有时想回避。
然而将心比心（或者说同病相怜吧），我也是开发人员，知道吃这碗饭不容易，我理应帮他们一把。
我想了一个办法：
请我的几位小组成员轮流代我参加需求调查会议。
我提醒组员：
“我们要热情地为调查者解答疑问，同时要观察、体会他们的调查方法，学习好的、屏弃差的。
因为我们以后也要向别人调查需求。
”
需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼络住用户就能成功。
出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力，否则会把事情搞砸的。
在上例中，有些调查人员和我谈方案时，结果我发现他们的水平还不及我们小组的高，真不知道是谁给谁做方案。
把他们一送出大门，我就打了“小报告”，他们的机会变得很渺茫。
有些调查人员为了讨好我，不停地说好话、套近乎。
说好话当然让我高兴，但是听多了，让我感觉此人很圆滑，反而印象不好，于是应付了事。
有些调查人员倒是很务实，一上来就问问题、填写调查报告，一点好话都不会说，让我提不起兴趣，我也不想多谈。
有些感受挺有趣，每当我认真思考这些事情时，不禁心事重重。
有太多的开发人员不懂得“如何做好”需求开发，这并不有趣，组建优秀的开发团队谈何容易啊！
开发方与用户的合作关系对需求开发而言是至关重要的。
对于重大的、复杂的项目，我们不能完全期望双方能够自发地建立起良好地合作关系，这样风险太大。
文献[Wiegers2000,p12-p16]给出了一种好方法：
开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确定合作关系。
“好话”和“丑话”都说在前头，这样能减少今后的摩擦。
如果条件允许的话，开发方最好为用户举办关于需求工程的培训，这样的培训将使用户明白需求的重要性以及忽视需求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。
表4-1列举了用户在需求工程中的“权利与义务”，读者可以根据实际情况适当地修改。
用户的权利
1.有权要求开发方派遣资质合格的需求分析员和相关人员。
2.有权要求开发方采用用户熟悉的语言来描述需求，即开发方必须提供用户看得懂得需求文档。
3.有权审查需求文档，并对有争议的需求作出决策。
如果认为需求文档不能准确地反映用户真实的意愿，可以拒绝在需求文档上签字。
4.如果用户想要变更需求，有权要求开发方对该变更将产生的影响作出真实可信的评估，以便用户决定是否变更需求。
用户的义务
1.以积极友善的态度与开发方人员交流、协作，尽可能地为开发方人员提供工作和生活上的便利。
2.乐意接受需求分析员的采访，在不泄漏机密的前提下，尽可能地回答需求分析员的问题。
3.在不泄漏机密的前提下，尽可能地向需求分析员提供与需求相关的材料。
4.与需求分析员共同评审需求文档，确保需求文档准确地反映用户真实的意愿。
5.不轻易变更需求。
如果需要变更需求的话，按照“需求变更控制规程”执行，而非强迫开发方接受。
表4-1用户在需求工程中的“权利与义务”
4.4.4用户说不清楚需求
用户说不清楚需求是普遍现象，这是让开发人员头痛的大问题。
有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求。
开发人员可能觉得奇怪：
用户自己都不知道要什么，为什么还要我们开发软件？
这种现象有些时候是正常的，例如开发方的营销人员水平比较高，他能够在用户不清楚自己要什么的情况下引导用户“消费”。
也有不正常的现象，例如前些年全国各地的很多政府机构大搞网络建设。
这些机构的领导和办公人员大多数不清楚网络干什么用，就让开发人员替他们设想需求吧，反正是花公家的钱。
有些用户虽然心里明白想要什么，但却说不清楚需求。
读者可能很不以为然，用户不致于笨到这个地步吧？
这不是聪明或笨的问题，是表达能力问题。
举个日常生活的事例，比如说买鞋子。
我们非常了解自已的脚，但很难用语言说清楚脚的大小和形状。
通常拿鞋子去试，试穿时感觉到舒服才会买鞋（居然也有神通广大的售货员，看一眼用户的手，就知道应该穿什么样的鞋）。
真所谓“道可道，非常道。
明可明，非常明。
”
需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连累整个开发团队的。
无论是什么原因导致用户说不清楚需求，需求分析员必须设法搞清楚用户真正的需求，这是需求分析员的职责，也是职业的挑战。
4.4.5双方误解需求
人们在交流的时候，经常会发生“问非所求，答非所问”的事情。
升级会员 