3. 模棱兩可的需求
模棱兩可是需求規(guī)格說明中最為可怕的問題(Lawrence 1996)。它的一層含義是指諸多讀者對需求說明產生了不同的理解;另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。
模棱兩可的需求會使不同的風險承擔者產生不同的期望,它會使開發(fā)人員為錯誤問題而浪費時間,并且使測試者與開發(fā)者所期望的不一致。一位系統(tǒng)測試人員曾告訴我,她所在的測試組經常對需求理解有誤,以致不得不重寫許多測試用例并重做許多測試。
模棱兩可的需求帶來不可避免的后果便是返工—重做一些你認為已做好的事情。返工會耗費開發(fā)總費用的40%,而70%~85%的重做是由于需求方面的錯誤所導致的(leffingwell 1997)。想像一下如果你能減少一半的返工會是怎樣的情況?你能更快地開發(fā)出產品,在同樣的時間內開發(fā)更多、更好的產品,甚至能偶爾回家休息休息。
處理模棱兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍。僅僅簡單瀏覽一下需求文檔是不能解決模棱兩可問題的。如果不同的評審者從不同的角度對需求說明給予解釋,但每個評審人員都真正了解需求文檔,這樣二義性就不會直到項目后期才被發(fā)現,那時再發(fā)現的話會使得更正代價很大。
4. 不必要的特性
“畫蛇添足”是指開發(fā)人員力圖增加一些“用戶欣賞”但需求規(guī)格說明中并未涉及的新功能。經常發(fā)生的情況是用戶并不認為這些功能性很有用,以致在其上耗費的努力“白搭”了。
開發(fā)人員應當為客戶構思方案并為他們提供一些具有創(chuàng)新意識的思路,具體提供哪些功能要在客戶所需與開發(fā)人員在允許時限內的技術可行性之間求得平衡,開發(fā)人員應努力使功能簡單易用,而不要未經客戶同意,擅自脫離客戶要求,自作主張。
同樣,客戶有時也可能要求一些看上去很“酷”,但缺乏實用價值的功能,而實現這些功能只能徒耗時間和成本。為了將“畫蛇添足”的危害盡量減小,應確信:你明白為什么要包括這些功能,以及這些功能的“來龍去脈”,這樣使得需求分析過程始終是注重那些能使用戶完成他們業(yè)務任務的核心功能。
時刻記?。很浖晒Φ臉藴适鞘欠窠鉀Q用戶的問題,而不是它有多Cool的功能。
5. 過于精簡的規(guī)格說明
有時,客戶并不明白需求分析有如此重要,于是只作一份簡略之至的規(guī)格說明,僅涉及了產品概念上的內容,然后讓開發(fā)人員在項目進展中去完善,結果很可能出現的是開發(fā)人員先建立產品的結構之后再完成需求說明。這種方法可能適合于尖端研究性的產品或需求本身就十分靈活的情況(McConnell 1996),不過商業(yè)應用大多都不是這種情況。在大多數情況下,這會給開發(fā)人員帶來挫折(使他們在不正確的假設前提和極其有限的指導下工作),也會給客戶帶來煩惱(他們無法得到他們所設想的產品)。
6. 忽略了用戶分類
大多數產品是由不同的人使用其不同的特性,使用頻繁程度也有所差異,使用者受教育程度和經驗水平也不盡相同。如果你不能在項目早期就針對所有這些主要用戶進行分類的話,必然導致有的用戶對產品感到失望。例如,菜單驅動操作對高級用戶太低效了,但含義不清的命令和快捷鍵又會使不熟練的用戶感到困難。
7. 不準確的計劃
“上述是我對新產品的看法,好,現在你能告訴我你什么時候能完成嗎?”許多開發(fā)人員都遇到這種難題。對需求分析缺乏理解會導致過分樂觀的估計,而當不可避免的超支發(fā)生時,會帶來頗多麻煩。據報道,導致需求過程中軟件成本估計極不準確的原因主要有以下五點:頻繁的需求變更、遺漏的需求、與用戶交流不夠、質量低下的需求規(guī)格說明和不完善的需求分析(Davis 1995)。
對不準確的要求所提問題的正確響應是“等我真正明白你的需求