軟件測試之如何進行軟件需求分析[1]

關鍵字：軟件 需求分析

　　1.概念

　　需求的定義包括從用戶角度(系統的外部行為)，以及從開發者角度(一些內部特性)來闡述需求。

　　關鍵的問題是一定要編寫需求文檔。我曾經目睹過一個項目中途更換了所有的開發者，客戶被迫與新的需求分析者坐到一起。系統的分析人員說：“我們想與你談談你的需求?！笨蛻舻牡谝环磻闶牵骸拔乙呀泴⑽业囊蠖几嬖V你們前任了，現在我要的就是給我編一個系統”。而實際上，需求并未編寫成文檔，因此新的分析人員不得不從頭做起。所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話，你就確信你已明白用戶的需求，那完全是自欺欺人。

　　需求的另外一種定義認為需求是“用戶所需要的并能觸發一個程序或系統開發工作的說明”。有些需求分析專家拓展了這個概念：“從系統外部能發現系統所具有的滿足于用戶的特點、功能及屬性等”。這些定義強調的是產品是什么樣的，而并非產品是怎樣設計、構造的。而下面的定義則從用戶需要進一步轉移到了系統特性：

　　需求是指明必須實現什么的規格說明。它描述了系統的行為、特性或屬性，是在開發過程中對系統的約束。

　　從上面這些不同形式的定義不難發現：并沒有一個清晰、毫無二義性的“需求”術語存在，真正的“需求”實際上在人們的腦海中，這個人們主要是指客戶，但一般情況下，用戶并不能描述自己的需要，只就需要系統分析人員根據用戶的自己語言的描述整理出相關的需要再進一步和客戶核對。系統分析員和客戶需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務必達成共識。

　　任何文檔形式的需求(例如如下將要描述的需求規格說明書)僅是一個模型，一種描述。

　　2.需求分析的任務

　　開發軟件系統最為困難的部分就是準確說明開發什么。最為困難的概念性工作便是編寫出詳細技術需求，這包括所有面向用戶、面向機器和其它軟件系統的接口。同時這也是一旦做錯，將最終會給系統帶來極大損害的部分，并且以后再對它進行修改也極為困難。

　　目前，國內產品的龐雜，一家企業可能有幾個系統并立運行，它們之間接口是系統開發人員最頭痛的問題。

　　對于商業最終用戶應用程序，企業信息系統和軟件作為一個大系統的一部分的產品是顯而易見的。但是對于我們開發人員來說，并沒有編寫出客戶認可的需求文檔，我們如何知道項目于何時結束?而如果我們不知道什么對客戶來說是重要的，那我們又如何能使客戶感到滿意呢?

　　然而，即便并非出于商業目的的軟件需求也是必須的。例如庫、組件和工具這些供開發小組內部使用的軟件。當然你可能偶爾勿需文檔說明就能與其他人意見較為一致，但更常見的是出現重復返工這種不可避免的后果，而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價，這些血的教訓正在國內的軟件開發者身上發生。

原文轉自：http://www.anti-gravitydesign.com