需求工程的16字方針

一、發掘需求
        需求工程的目的是為了完整地把握用戶的需求，所以怎樣盡可能的了解到客戶的需求是十分
重要的，軟件工程專家們早就為我們開好了藥方，提供了很多的step by step的方法供我們使用
，然而我常常覺得真正要了解用戶的需求是一件不太容易的事情，這里面存在溝通的問題、方法
的問題甚至態度的問題。
 （1）克服企業背景對需求工程的影響。
 在做需求調查的時候，一般情況下會召集一幫子人來開需求會議，然而如果以前不是很熟悉，
或者對客戶公司或者工廠的背景及其企業文化不太了解，我們就需要力圖正確了解客戶的表達方
式或者措辭。通常的情況下，企業的詞匯與我們系統中的詞匯往往并不存在一一對應的關系，即
使存在同一個詞匯，那么在客戶的腦海里和在我們的腦海也可能是兩個完全不一樣的。常常是你
說東他以為說西，你說西他以為說東。那么在這樣的情況下，我們所要做的就是從概念上與用戶
取得一致，而且今后的表述也應該盡量使用用戶可以接受的表述，而不是總是抱著我們自己的概
念不放。畢竟我們總是在軟件的象牙塔里，而用戶總是腳踏實地的在地上。一方面我們的軟件應
該有自己的文化，當同時我們的軟件也應該能適應用戶的文化，如果需求工程結束能夠提供一個
比較詳細的企業和軟件的詞匯對照表是一個理想的做法，在這個詞匯對照表里為雙方的理解提供
詳盡的參照。
 （2）克服方法不當對需求工程的影響。
 在沒有UML之前，描述軟件需求的基本都是文字，軟件工程里也提到可以使用原型法來表達用
戶的需求。有了UML之后，我們大多數系統分析師可能都會選擇使用用例圖來文檔化需求。不管是
哪種方法，我認為并不一定就能夠很好的捕捉用戶的需求。就拿原型法為例，我們用最短的時間做
出了一個系統原型，并與客戶面對面討論，可能在討論的時候大家彼此都很愉快，客戶也承認這個
原型系統能夠滿足自己的要求，在日常工作中也是這么做的，您以為萬事大吉了，需求算是完成了
，但是且慢，說不定過了兩三天你再和客戶討論的時候他又變卦了，這個時候我們的系統分析師可
能就會不高興了，上次不是說得好好的嗎？怎么又變卦了？在我實施項目的時候一位企業的項目負
責人說的話我覺得很有道理。第一、如果被調查者事先沒有什么準備，突然讓他談論需求，他很有
可能是一下不可能說的很完整清楚，因為他本來就沒有什么準備，即使他有所準備，但是由于受角
色和能力的限制，他也許就真的不能夠談得很清楚，他可能會有遺漏。第二、軟件使用者往往都只
關系自己的使用部分，而對其它部分都會漠視。他只關心他能寫什么數據，然后能看到什么數據，
而對其它的東西都會漠視。比如上次實施一個項目的時候，本來界面上和功能上都已經和軟件使用
者做了交流，也得到他的認可，但是后來他突然提到界面所有顯示的數據是允許修改的。原型也許
能告訴用戶他可以做什么的，但是可能并不能告訴他怎么做的。
 對于UML用例圖，我一直也是心存疑慮的。我想既然用戶不懂編程，那么他就能夠看得懂UML用
例圖嗎？可視化的確是交流的一種好的方式，但是我覺得缺少文字的準確性和深度。如果您只使用
圖來與用戶做交流，我想最后失敗是一種必然。UML圖加上詳細的文字說明，我想才是正確之道。
如果可能，我認為UML圖+用例文字說明+原型或許更能準確捕捉到系統的需求。
 至于在實際的需求工程中，具體可以采用什么樣的方法，可能每一個人都有自己的特長，希望
讀到這篇文章的朋友也能提出自己的看法來交流。
 （3）克服受訪談者對需求工程的影響。
 從某種意義上來說，對受訪談者的選擇決定了需求工程的成敗，因為受訪談者的計算機水平、
業務水平、責任心、學習能力都對需求調查會產生很大的影響。計算機水平比較好的用戶，他往往
能明白計算機可以做什么不可以做什么，對新的軟件系統接受能力也較強，業務水平強的用戶因為
對業務天生的熟悉因此也往往能提出具體的需求，他們提出的需求也往往是最準確的。責任心強的
用戶也許會站在實際使用和提供管理水平的高度來考究企業的需求，學習能力強的用戶對新概念的
接受能力也強無疑會增加溝通的效率。當然在實際的工作中，具備這些條件的用戶往往不可能很多
，有那么一個也許就夠系統分析師們念阿彌陀佛的了。退而取其次，受訪者一定是要業務水平較高
而且有一定權威的用戶。關于這個條件，可以在做需求工程之前就對企業提出要求。不過在我的實
際工作中卻遇到一些業務很好，但是對軟件本身就很有抵觸的人，一方面年紀較大，另一方面電腦
基礎不是很好，再次害怕上了軟件以后影響自己的地位或者飯碗，在這時候我們就需要小心的應付
這些利益上的小九九給需求工程帶來的損害。
 （4）克服就項目論項目對需求工程的影響。
 做需求工程的時候，我們切不可以只是調查當前確定的項目的內容，我認為在最開始與客戶交
流的時候就不要太限定談論的內容。首先要從廣度上對企業的需求進行調查。從廣度上調查，我們
就可以發現企業潛在的需求。這也為我們下一步的實施打下基礎。通常情況是如果您在一個企業實
施了某一個項目，而如果你把握到了企業的潛在的需求，正好自己的公司有一個產品符合企業的那
一方面的需求，那么這又是一個潛在的項目。系統分析師有責任為公司帶來更多的訂單，大家認為
呢？不光是系統分析師，我認為每一個實施人員都有這個義務。也許這也算是我們愛公司的表現。
 總而言之，發掘需求就是要發掘出用戶表面的和潛在的需求，既要有廣度也需要有深度。
二、限制需求
 （1）給客戶當頭一盆冷水
 有些公司信息化基礎比較好，有些公司的老總對信息化比較狂熱，可能在您與他們交談的時候
他會大談他要一個什么樣什么樣的系統，這個系統功能強大無比甚至是無所不能，他跟你算帳，上
了這個系統之后會給企業帶來什么樣的效益，效率可以提高多少，成本可以節省多少。如果系統分
析師與他一道狂熱，頭腦發暈，我想后果會是很嚴重的。也許我們最終得到的需求是一個假大空的
需求，一個不切實際的需求，而要完成這樣的一個系統在項目規定的時間內是根本不可能完成的。
這個時候，需要系統分析師給他當頭潑一盆冷水，給他談論一個比較現實的方案，一個可以分步驟
有重點的方案。
 （2）認清真正的需求
 在需求討論會上，可能每一個人都會談到自己的需求，這個人是這樣的需求，那個人是那樣的
需求。實際上也許可能就是一個要求，而不是需求。需求與要求是有著本質的區別的。這個時候就
要求系統分析師具有火眼金睛，能夠透過用戶的字里行間和片言只語中把握用戶真正想要表達的東
西從中歸納出真正的需求。需求也就是要求的歸納。實際上，我們開始時是不懂用戶的，而用戶也
不懂我們的系統的，我們都陷入的是一個想象的空間中。即使我們面對用戶，對于用戶的需求也是
一種想象，即使用戶面對我們，他對我們的系統也是一種想象中。
 能從眾說紛紜中剔出有價值的信息并提煉出真的需求才是系統分析師的真本事。
 （3）定義需求的邊界
 需求定義出來了，那么是否是所有的需求都要滿足呢？我想肯定不是這樣的。我們還要對可以
實現的需求做出一定的限制。這里面蘊含的一個道理是需求是有層次的。有的需求很緊急的，必須
要完成的，這部分需求我們當然要滿足。有些需求則不是很緊急的，我們可以在下期實施中滿足（
如果有下期）。有些需求是可有可無的，那么這些需求我們可以不滿足。而有些需求則可能是無理
的，那么這樣的需求我們當然要拒絕。這么做的理由是一方面可能有技術的限制，一方面是項目經
費的限制，一方面則是項目時間的限制。如果不對需求的邊界做出定義，那么這樣的需求工程顯然
就是失敗的，有卻像無。用戶可以永遠不停的改變需求。當然我們允許用戶修改自己的需求，但是
這樣的變更也要控制在一定的合理的范圍之內。
三、引導需求
 在做需求工程的時候，用戶可能有這樣那樣的需求，如果我們一味沿著用戶的思路，那么可能
最終導致我們原來的系統需要徹底的修改，或者說根本不能夠使用，那么這個時候我們需要針對客
戶的需求做出必要的引導，將用戶的思路引導到我們軟件系統已經很好的解決的方案上來。我們可
以告訴用戶我們是怎么做的，可以怎樣滿足他的需求的，我們這樣做已經在很多企業得到應用而且
得到他們的認可和實踐的檢驗。這時候用戶不得不考慮風險的問題，因為如果出了什么問題，他們
是要承擔責任的，而責任不是每個人都喜歡承擔的承擔得了的。這里我不得不提到軟件的靈魂了，
盡管有人不喜歡。引導的目的我想就是要將我們認為我們的軟件中有價值的東西推銷給用戶。如果
一個軟件沒有靈魂，我想價值可能也要打點折扣，推銷的可能性也不會很大。
四、控制需求
 控制需求一方面是針對用戶的，就是要嚴格控制需求的變更，不允許隨便的變更，這樣的變更
起碼需要經過評價。另一方面是針對開發者的，在我們的開發中必須保證做的軟件是符合客戶的需
求的�？赡艽蠹矣X得這不是問題，但是實際上這往往就是個問題。需求既然有挖掘，那么同樣在開
發團隊內部就有消化的問題。不是每一個程序員都能夠正確理解用戶需求的。也許有人說這個問題
在做概要設計或者詳細設計的時候就應該做好的，因為設計是根據需求來的，是的，您是對的，但
是每個人都會有走偏路的時候，并不是總是走直線，設計與編程之間同樣存在著溝壑，但這不是本
篇的重點，一個好的做法是如果您有UML用力圖，那么做詳細設計的時候要標明那個模塊或者那些模
塊是實現那個需求或者那些需求的。那么在做代碼走查的時候可以比較方便的檢查。

文章來源于領測軟件測試網 http://www.kjueaiud.com/