文档介绍：需求的十六字方针
需求工程是软件工程中一项十分重要的工作,这也是历来为软件工程专家们所重视,关于这方面的著作可以说是汗牛充栋。而我不自量力想用16个字来概括需求工程中的best practi-ce,是为16字方针:“发掘需求、限制需求、引导需求、控制需求”,仅供园子里的朋友讨论。
一、发掘需求
需求工程的目的是为了完整地把握用户的需求,所以怎样尽可能的了解到客户的需求是十分
重要的,软件工程专家们早就为我们开好了药方,提供了很多的step by step的方法供我们使用
,然而我常常觉得真正要了解用户的需求是一件不太容易的事情,这里面存在沟通的问题、方法
的问题甚至态度的问题。
 
(1)克服企业背景对需求工程的影响。
 在做需求调查的时候,一般情况下会召集一帮子人来开需求会议,然而如果以前不是很熟悉,
或者对客户公司或者工厂的背景及其企业文化不太了解,我们就需要力图正确了解客户的表达方
式或者措辞。通常的情况下,企业的词汇与我们系统中的词汇往往并不存在一一对应的关系,即
使存在同一个词汇,那么在客户的脑海里和在我们的脑海也可能是两个完全不一样的。常常是你
说东他以为说西,你说西他以为说东。那么在这样的情况下,我们所要做的就是从概念上与用户
取得一致,而且今后的表述也应该尽量使用用户可以接受的表述,而不是总是抱着我们自己的概
念不放。毕竟我们总是在软件的象牙塔里,而用户总是脚踏实地的在地上。一方面我们的软件应
该有自己的文化,当同时我们的软件也应该能适应用户的文化,如果需求工程结束能够提供一个
比较详细的企业和软件的词汇对照表是一个理想的做法,在这个词汇对照表里为双方的理解提供
详尽的参照。
 
(2)克服方法不当对需求工程的影响。
在没有UML之前,描述软件需求的基本都是文字,软件工程里也提到可以使用原型法来表达用
户的需求。有了UML之后,我们大多数系统分析师可能都会选择使用用例图来文档化需求。不管是
哪种方法,我认为并不一定就能够很好的捕捉用户的需求。就拿原型法为例,我们用最短的时间做
出了一个系统原型,并与客户面对面讨论,可能在讨论的时候大家彼此都很愉快,客户也承认这个
原型系统能够满足自己的要求,在日常工作中也是这么做的,您以为万事大吉了,需求算是完成了
,但是且慢,说不定过了两三天你再和客户讨论的时候他又变卦了,这个时候我们的系统分析师可
能就会不高兴了,上次不是说得好好的吗?怎么又变卦了?在我实施项目的时候一位企业的项目负
责人说的话我觉得很有道理。第一、如果被调查者事先没有什么准备,突然让他谈论需求,他很有
可能是一下不可能说的很完整清楚,因为他本来就没有什么准备,即使他有所准备,但是由于受角
色和能力的限制,他也许就真的不能够谈得很清楚,他可能会有遗漏。第二、软件使用者往往都只
关系自己的使用部分,而对其它部分都会漠视。他只关心他能写什么数据,然后能看到什么数据,
而对其它的东西都会漠视。比如上次实施一个项目的时候,本来界面上和功能上都已经和软件使用
者做了交流,也得到他的认可,但是后来他突然提到界面所有显示的数据是允许修改的。原型也许
能告诉用户他可以做什么的,但是可能并不能告诉他怎么做的。
对于UML用例图,我一直也是心存疑虑的。我想既然用户不懂编程,那么他就