軟體需求分析

軟體需求分析所要做的工作是深入描述軟體的功能和效能，確定軟體設計的限制和軟體同其它系統元素的介面細節，定義軟體的其它有效性需求。　　

進行需求分析時，應注意一切資訊與需求都是站在使用者的角度上。盡量避免分析員的主觀想象，並盡量將分析進度提交給使用者。在不進行直接指導的前提下，讓使用者進行檢查與評價。從而達到需求分析的準確性。　　

分析員通過需求分析，逐步細化對軟體的要求，描述軟體要處理的資料域，並給軟體開發提供一種可轉化為資料設計、結構設計和過程設計的資料和功能表示。在軟體完成後，制定的軟體規格說明還要為評價軟體質量提供依據。

需求分析的任務

開發軟體系統最為困難的部分就是準確說明開發什麼。最為困難的概念性工作便是編寫出詳細技術需求，這包括所有面向使用者、面向機器和其它軟體系統的介面。同時這也是一旦做錯，將最終會給系統帶來極大損害的部分，並且以後再對它進行修改也極為困難。目前，國內產品的龐雜，一家企業可能有幾個系統並立執行，它們之間介面是系統開發人員最頭痛的問題。對於商業終端使用者應用程式，企業資訊系統和軟體作為乙個大系統的一部分的產品是顯而易見的。但是對於我們開發人員來說，並沒有編寫出客戶認可的需求文件，我們如何知道專案於何時結束？而如果我們不知道什麼對客戶來說是重要的，那我們又如何能使客戶感到滿意呢？　　

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

近來，我遇到乙個開發小組開發包括**編輯器在內的一套內部使用的計算機輔助軟體。不幸的是，當他們開發完這個工具後，發現這個工具不能列印出源**檔案，使用者當然希望有這個功能。結果這個小組只好手工抄寫源**文件以供**檢查。這說明那怕需求明確無誤並構思準確，如果我們沒有編寫文件，軟體達不到期望目標也只能是咎由自取了。　　相反的情況，我曾見乙個要整合到「錯誤跟蹤系統」中的簡單介面寫了一頁需求說明。而作業系統系統管理員在為處理指令碼時發現簡單的一張需求清單竟是如此有用。他們依據需求對系統進行測試時，此系統不僅非常清晰地實現了所有必需功能，而且未發現任何錯誤。　　事實上，需求文件在開發過程中一直起指導作用。

需求的型別

下面這些定義是需求工程領域中常見術語的定義。　　

軟體需求包括三個不同的層次：業務需求、使用者需求和功能需求（也包括非功能需求）。　　

1．業務需求（business requirement）反映了組織機構或客戶對系統、產品高層次的目標要求，它們在專案檢視與範圍文件中予以說明。

2．使用者需求(user requirement)文件描述了使用者使用產品必須要完成的任務，這在使用例項（use case）文件或方案指令碼說明中予以說明。　　

3．功能需求(functional requirement)定義了開發人員必須實現的軟體功能，使得使用者能完成他們的任務，從而滿足了業務需求。　　

在軟體需求規格說明書（srs）中說明的功能需求充分描述了軟體系統所應具有的外部行為。軟體需求規格說明在開發、測試、質量保證、專案管理以及相關專案功能中都起了重要的作用。對乙個大型系統來說，軟體功能需求也許只是系統需求的乙個子集，因為另外一些可能屬於子系統（或軟體部件）。

作為功能需求的補充，軟體需求規格說明還應包括非功能需求，它描述了系統展現給使用者的行為和執行的操作等。它包括產品必須遵從的標準、規範和合約；外部介面的具體細節；效能要求；設計或實現的約束條件及質量屬性。所謂約束是指對開發人員在軟體產品設計和構造上的限制。質量屬性是通過多種角度對產品的特點進行描述，從而反映產品功能。多角度描述產品對使用者和開發人員都極為重要。

下面以乙個字處理程式為例來說明需求的不同種類。

業務需求可能是：「使用者能有效地糾正文件中的拼寫錯誤」，該產品的包裝盒封面上可能會標明這是個滿足業務需求的拼寫檢查器。而對應的使用者需求可能是「找出文件中的拼寫錯誤並通過乙個提供的替換項列表來供選擇替換拼錯的詞」。同時，該拼寫檢查器還有許多功能需求，如找到並高亮度提示錯詞的操作；顯示提供替換詞的對話方塊以及實現整個文件範圍的替換。　　

從以上定義可以發現，需求並未包括設計細節、實現細節、專案計畫資訊或測試資訊。需求與這些沒有關係，它關注的是充分說明你究竟想開發什麼。專案也有其它方面的需求，如開發環境需求或發布產品及移植到支撐環境的需求。

軟體需求分析

軟體需求分析

軟體需求分析

軟體需求分析

相關推薦