需求工程的16字方针
需求工程是软件工程中一项十分重要的工作，这也是历来为软件工程专家们所重视，关于
这方面的著作可以说是汗牛充栋。而我不自量力想用16个字来概括需求工程中的best practi
-ce，是为16字方针：“发掘需求、限制需求、引导需求、控制需求”，仅供园子里的朋友讨论。
一、发掘需求
需求工程的目的是为了完整地把握用户的需求，所以怎样尽可能的了解到客户的需求是十分
重要的，软件工程专家们早就为我们开好了药方，提供了很多的step by step的方法供我们使用
，然而我常常觉得真正要了解用户的需求是一件不太容易的事情，这里面存在沟通的问题、方法
的问题甚至态度的问题。
（1）克服企业背景对需求工程的影响。
在做需求调查的时候，一般情况下会召集一帮子人来开需求会议，然而如果以前不是很熟悉，
或者对客户公司或者工厂的背景及其企业文化不太了解，我们就需要力图正确了解客户的表达方
式或者措辞。通常的情况下，企业的词汇与我们系统中的词汇往往并不存在一一对应的关系，即
使存在同一个词汇，那么在客户的脑海里和在我们的脑海也可能是两个完全不一样的。常常是你
说东他以为说西，你说西他以为说东。那么在这样的情况下，我们所要做的就是从概念上与用户
取得一致，而且今后的表述也应该尽量使用用户可以接受的表述，而不是总是抱着我们自己的概
念不放。毕竟我们总是在软件的象牙塔里，而用户总是脚踏实地的在地上。一方面我们的软件应
该有自己的文化，当同时我们的软件也应该能适应用户的文化，如果需求工程结束能够提供一个
比较详细的企业和软件的词汇对照表是一个理想的做法，在这个词汇对照表里为双方的理解提供
详尽的参照。
（2）克服方法不当对需求工程的影响。
在没有UML之前，描述软件需求的基本都是文字，软件工程里也提到可以使用原型法来表达用
户的需求。有了UML之后，我们大多数系统分析师可能都会选择使用用例图来文档化需求。不管是
哪种方法，我认为并不一定就能够很好的捕捉用户的需求。就拿原型法为例，我们用最短的时间做
出了一个系统原型，并与客户面对面讨论，可能在讨论的时候大家彼此都很愉快，客户也承认这个
原型系统能够满足自己的要求，在日常工作中也是这么做的，您以为万事大吉了，需求算是完成了
，但是且慢，说不定过了两三天你再和客户讨论的时候他又变卦了，这个时候我们的系统分析师可
能就会不高兴了，上次不是说得好好的吗？怎么又变卦了？在我实施项目的时候一位企业的项目负
责人说的话我觉得很有道理。第一、如果被调查者事先没有什么准备，突然让他谈论需求，他很有
可能是一下不可能说的很完整清楚，因为他本来就没有什么准备，即使他有所准备，但是由于受角
色和能力的限制，他也许就真的不能够谈得很清楚，他可能会有遗漏。第二、软件使用者往往都只
关系自己的使用部分，而对其它部分都会漠视。他只关心他能写什么数据，然后能看到什么数据，
而对其它的东西都会漠视。比如上次实施一个项目的时候，本来界面上和功能上都已经和软件使用
者做了交流，也得到他的认可，但是后来他突然提到界面所有显示的数据是允许修改的。原型也许
能告诉用户他可以做什么的，但是可能并不能告诉他怎么做的。
对于UML用例图，我一直也是心存疑虑的。我想既然用户不懂编程，那么他就能够看得懂UML用
例图吗？可视化的确是交流的一种好的方式，但是我觉得缺少文字的准确性和深度。如果您只使用
图来与用户做交流，我想最后失败是一种必然。UML图加上详细的文字说明，我想才是正确之道。
如果可能，我认为UML图+用例文字说明+原型或许更能准确捕捉到系统的需求。
至于在实际的需求工程中，具体可以采用什么样的方法，可能每一个人都有自己的特长，希望
读到这篇文章的朋友也能提出自己的看法来交流。
（3）克服受访谈者对需求工程的影响。
从某种意义上来说，对受访谈者的选择决定了需求工程的成败，因为受访谈者的计算机水平、
业务水平、责任心、学习能力都对需求调查会产生很大的影响。计算机水平比较好的用户，他往往
能明白计算机可以做什么不可以做什么，对新的软件系统接受能力也较强，业务水平强的用户因为
对业务天生的熟悉因此也往往能提出具体的需求，他们提出的需求也往往是最准确的。责任心强的
用户也许会站在实际使用和提供管理水平的高度来考究企业的需求，学习能力强的用户对新概念的
接受能力也强无疑会增加沟通的效率。当然在实际的工作中，具备这些条件的用户往往不可能很多
，有那么一个也许就够系统分析师们念阿弥陀佛的了。退而取其次，受访者一定是要业务水平较高
而且有一定权威的用户。关于这个条件，可以在做需求工程之前就对企业提出要求。不过在我的实
际工作中却遇到一些业务很好，但是对软件本身就很有抵触的人，一方面年纪较大，另一方面电脑
基础不是很好，再次害怕上了软件以后影响自己的地位或者饭碗，在这时候我们就需要小心的应付
这些利益上的小九九给需求工程带来的损害。
（4）克服就项目论项目对需求工程的影响。
做需求工程的时候，我们切不可以只是调查当前确定的项目的内容，我认为在最开始与客户交
流的时候就不要太限定谈论的内容。首先要从广度上对企业的需求进行调查。从广度上调查，我们
就可以发现企业潜在的需求。这也为我们下一步的实施打下基础。通常情况是如果您在一个企业实
施了某一个项目，而如果你把握到了企业的潜在的需求，正好自己的公司有一个产品符合企业的那
一方面的需求，那么这又是一个潜在的项目。系统分析师有责任为公司带来更多的订单，大家认为
呢？不光是系统分析师，我认为每一个实施人员都有这个义务。也许这也算是我们爱公司的表现。
总而言之，发掘需求就是要发掘出用户表面的和潜在的需求，既要有广度也需要有深度。
二、限制需求
（1）给客户当头一盆冷水
有些公司信息化基础比较好，有些公司的老总对信息化比较狂热，可能在您与他们交谈的时候
他会大谈他要一个什么样什么样的系统，这个系统功能强大无比甚至是无所不能，他跟你算帐，上
了这个系统之后会给企业带来什么样的效益，效率可以提高多少，成本可以节省多少。如果系统分
析师与他一道狂热，头脑发晕，我想后果会是很严重的。也许我们最终得到的需求是一个假大空的
需求，一个不切实际的需求，而要完成这样的一个系统在项目规定的时间内是根本不可能完成的。
这个时候，需要系统分析师给他当头泼一盆冷水，给他谈论一个比较现实的方案，一个可以分步骤
有重点的方案。
（2）认清真正的需求
在需求讨论会上，可能每一个人都会谈到自己的需求，这个人是这样的需求，那个人是那样的
需求。实际上也许可能就是一个要求，而不是需求。需求与要求是有着本质的区别的。这个时候就
要求系统分析师具有火眼金睛，能够透过用户的字里行间和片言只语中把握用户真正想要表达的东
西从中归纳出真正的需求。需求也就是要求的归纳。实际上，我们开始时是不懂用户的，而用户也
不懂我们的系统的，我们都陷入的是一个想象的空间中。即使我们面对用户，对于用户的需求也是
一种想象，即使用户面对我们，他对我们的系统也是一种想象中。
能从众说纷纭中剔出有价值的信息并提炼出真的需求才是系统分析师的真本事。
（3）定义需求的边界
需求定义出来了，那么是否是所有的需求都要满足呢？我想肯定不是这样的。我们还要对可以
实现的需求做出一定的限制。这里面蕴含的一个道理是需求是有层次的。有的需求很紧急的，必须
要完成的，这部分需求我们当然要满足。有些需求则不是很紧急的，我们可以在下期实施中满足（
如果有下期）。有些需求是可有可无的，那么这些需求我们可以不满足。而有些需求则可能是无理
的，那么这样的需求我们当然要拒绝。这么做的理由是一方面可能有技术的限制，一方面是项目经
费的限制，一方面则是项目时间的限制。如果不对需求的边界做出定义，那么这样的需求工程显然
就是失败的，有却像无。用户可以永远不停的改变需求。当然我们允许用户修改自己的需求，但是
这样的变更也要控制在一定的合理的范围之内。
三、引导需求
在做需求工程的时候，用户可能有这样那样的需求，如果我们一味沿着用户的思路，那么可能
最终导致我们原来的系统需要彻底的修改，或者说根本不能够使用，那么这个时候我们需要针对客
户的需求做出必要的引导，将用户的思路引导到我们软件系统已经很好的解决的方案上来。我们可
以告诉用户我们是怎么做的，可以怎样满足他的需求的，我们这样做已经在很多企业得到应用而且
得到他们的认可和实践的检验。这时候用户不得不考虑风险的问题，因为如果出了什么问题，他们
是要承担责任的，而责任不是每个人都喜欢承担的承担得了的。这里我不得不提到软件的灵魂了，
尽管有人不喜欢。引导的目的我想就是要将我们认为我们的软件中有价值的东西推销给用户。如果
一个软件没有灵魂，我想价值可能也要打点折扣，推销的可能性也不会很大。
四、控制需求
控制需求一方面是针对用户的，就是要严格控制需求的变更，不允许随便的变更，这样的变更
起码需要经过评价。另一方面是针对开发者的，在我们的开发中必须保证做的软件是符合客户的需
求的。可能大家觉得这不是问题，但是实际上这往往就是个问题。需求既然有挖掘，那么同样在开
发团队内部就有消化的问题。不是每一个程序员都能够正确理解用户需求的。也许有人说这个问题
在做概要设计或者详细设计的时候就应该做好的，因为设计是根据需求来的，是的，您是对的，但
是每个人都会有走偏路的时候，并不是总是走直线，设计与编程之间同样存在着沟壑，但这不是本
篇的重点，一个好的做法是如果您有UML用力图，那么做详细设计的时候要标明那个模块或者那些模
块是实现那个需求或者那些需求的。那么在做代码走查的时候可以比较方便的检查。