在台湾，进行使用者需求访谈，就像在火车站把一个要赶着去搭车的人拦下来进行问卷.调查差不多。一开始，他可能还会基于礼貌，填写问卷。当他需要第四次还是第五次回.答同一张问卷的话，他会觉得你是否听不懂人类所说的语言，还是存心找他麻烦。如果.你开发一个系统，得要使用者评估个好几回的话，God bless you。
就算使用者对你十分仁慈，没有把你轰出去，采用iterative的做法会有的另外一个问题，.其实是在于你的系统是一个iteration，一个iteration慢慢调整，逐渐形成的。所以到底什.么算是在系统的范围(scope)里面，其实很难界定。所以如果使用者觉得这个iteration的.成品，与他原始需求还有距离，你大概都会被迫再多几个iteration。而这几个iteration，.是收不到钱的。这跟以前的所谓螺线型的开发方式，在台湾遇到的困难是一样的。客户.不会因为你多做了几个循环(cycle)，而多给你钱。然而，你会因为多做了几个cycle，投.入超出预期的人力与时间。
事情多做了，可是赚不到钱，这怎么划算呢?要知道，开发项目跟开发产品是不同的。.开发项目，就是要在最少的资源之下，提供给客户一个可以接受的烂货。可以花100万.就让客户愿意结案，绝对不要花101万，让客户拥有一个比较好用的系统。越好用的东.西越难做，出槌的机率也越高，为什么要这样做呢?
除非今天客户是人力外包，花钱买你的人月，去帮他开发。这个时候，当然是尽量选择.可以做得长长久久的方式来开发啰。
所以我觉得应该要以项目的特性来选择项目开发方式。大部分的项目，应该用传统的软.件生命周期开发方式来开发。- (待续)
**使用者或者是客户的信息人员，看不懂相关的文件**
开发项目到底会遇到什么样的客户?其实就像是跟网友见面差不多，还没有看到真人，你永远不知道哪个每天跟你聊天分享心事的超级美女，其实是一个中年男子。就算你运气好，以前已经跟这个使用者接触过，彼此混的很熟，还是有可能会发生变化。
如果以前的项目做得好，这个人有可能升官，所以他就不会做这个专案了;如果以前的项目做得不好，有可能这个人就被列入下次裁员的黑名单里，所以他也不会做这个项目。更不要提有些时候，你是跟一些从来都没有打过交道的人一起开始做一个新的项目。
既然我们在描述的对象是项目，大部分的项目，都是从需求分析开始。使用者便会提出他们的需求，系统分析师听到使用者的需求以后，就会开始把他所收集到的需求写成文件，接着会去跟使用者确认需求是否便是如此。
采用use case driven的OOA(object oriented analysis)，你会请使用者确认的文件，当然就是use case。
接着你会依据use case，开始进行OOD(object oriented design)。当你画好sequence diagram, class diagram，你可能会希望客户的信息人员，可以帮忙确认，这些文件所描述的系统，是否正确。
问题是，大部分的使用者，以及客户的信息人员，其实并没有足够的能力，来确认这些文件的正确性与完整性。因为你所提供的文件，他们看不懂。通常需要你的带领，才看得懂。当他们需要靠你解释才看得懂时，这时候通常会有一些问题随之产生。他们通常可以挑出专业领域上的错误，可是他们通常会忽略掉整个系统的完整性。因为他们会觉得，你所没有描述的东西，可能写在另外的文件中。所以如果你提供的文件有错，通常是你所提供的文件可能不完整，其实要到蛮后期的时候才会发现。这时候修改的成本就会变得非常高了。
为什么采用use case来描述一个系统，通常会发生遗漏呢?或许我们应该先看看use case是什么。
根据我的一知半解呢，use case就是尝试着用文字来描述系统与外界之间的交互作用。对于没有看过use case的人来说，我在此举一个例子来说明。书上最常看到的例子呢，就是一个人用提款机在领钱。虽然我没有写过类似的程序，我可以想象一下，这个use case应该包含的内容。
1.Brief Description
这个use case说明，怎么样透过提款机来领钱。
2.Flow of Events
文章来源于领测软件测试网 https://www.ltesting.net/
