Shao Fan

If the problem was exploring requirements to lead them toward stability, the solution was seen to be prototyping. ... Prototyping and JAD continue to be used to this day, especially when requirements are poorly understood.

Meanwhile, management had to figure out how to deal with reuiqrements instability and the "moving target" problem. ... But eventually management came to realize that, although they could not freeze the requirements, they could insist that changing requirements lead to changing project terms and conditions. "You want new or revised features? Then let's talk about how much time and money that will cost over and above our original estimate." Unfortunately, that led us into the swampland of changing estimates while the project was in progress...

There is an interesting new twist evolving on the requirements instability problem. The extream Programming lightweight methodology calls for a representative of the user community to reside with the software project team during development. ... The questions remain, however, how many user organizations (a) will be willing to give up a first-rate person to such a full-time task, and (b) have one person who can represent all the potentially varying viewpoints of the customers and users?

為了更好得捕獲需求，使它們有更好的穩(wěn)定性，人們開始使用＂原型＂．＂原型＂和JAD（聯合應用開發(fā)）在如今仍在被使用著，尤其當需求無法被準確理解的時候．

同時，管理者必需面對和解決需求不穩(wěn)定，及＂移動靶＂的問題．最終他們認識到，雖然他們無法凍結需求，但是他們可以堅持＂需求變化導致合同條款變更＂的想法．＂如果你想修改項目的功能，那就需要考慮這些修改所需要的時間和資金成本．＂不幸的是，這致使項目陷入需要重新進行估計的泥沼之中（在項目進行之中進行重新估計會造成哪些問題？）．

此時極限編程浮出水面．它要求一個客戶代表與開發(fā)人員一起，參與軟件開發(fā)的過程．這可以解決一些問題，然而問題仍然存在，有多少組織(a)愿意放棄一個一線員工，讓他全職參與軟件開發(fā)，(b)能找到一個可以代表所有潛在的，持不同觀點的客戶和用戶的人？（關于這點，個人認為光有客戶代表可能還不夠，還是要在需求捕獲的過程中采用多種有效的手段，起碼客戶代表要與其他參與需求的客戶和用戶有一定的一致意見，否則，怎么起到＂代表＂的作用？）