需求分析

需求分析是軟件計劃階段的重要活動，也是軟件生存週期中的一個重要環節，該階段是分析系統在功能上需要“實現什麼”，而不是考慮如何去“實現”。需求分析的目標是把用户對待開發軟件提出的“要求”或“需要”進行分析與整理，確認後形成描述完整、清晰與規範的文檔，確定軟件需要實現哪些功能，完成哪些工作。此外，軟件的一些非功能性需求(如軟件性能、可靠性、響應時間、可擴展性等)，軟件設計的約束條件，運行時與其他軟件的關係等也是軟件需求分析的目標。 ^[2] 

為了促進軟件研發工作的規範化、科學化，軟件領域提出了許多軟件開發與説明的方法，如結構化方法、原型化法、面向對象方法等。這些方法有的很相似。在實際需求分析工作中．每一種需求分析方法都有獨特的思路和表示法，基本都適用下面的需求分析的基本原則。

(1)側重表達理解問題的數據域和功能域。對新系統程序處理的數據，其數據域包括數據流、數據內容和數據結構。而功能域則反映它們關係的控制處理信息。

(2)需求問題應分解細化，建立問題層次結構。可將複雜問題按具體功能、性能等分解並逐層細化、逐一分析。

(3)建立分析模型。模型包括各種圖表，是對研究對象特徵的一種重要表達形式。通過邏輯視圖可給出目標功能和信息處理間關係，而非實現細節。由系統運行及處理環境確定物理視圖，通過它確定處理功能和數據結構的實際表現形式。 ^[1] 

需求分析的內容是針對待開發軟件提供完整、清晰、具體的要求，確定軟件必須實現哪些任務。具體分為功能性需求、非功能性需求與設計約束三個方面。

1．功能性需求

功能性需求即軟件必須完成哪些事，必須實現哪些功能，以及為了向其用户提供有用的功能所需執行的動作。功能性需求是軟件需求的主體。開發人員需要親自與用户進行交流，核實用户需求，從軟件幫助用户完成事務的角度上充分描述外部行為，形成軟件需求規格説明書。

2．非功能性需求

作為對功能性需求的補充，軟件需求分析的內容中還應該包括一些非功能需求。主要包括軟件使用時對性能方面的要求、運行環境要求。軟件設計必須遵循的相關標準、規範、用户界面設計的具體細節、未來可能的擴充方案等。

3．設計約束

一般也稱做設計限制條件，通常是對一些設計或實現方案的約束説明。例如，要求待開發軟件必須使用Oracle數據庫系統完成數據管理功能，運行時必須基於Linux環境等。

需求分析階段的工作,可以分為四個方面：問題識別、分析與綜合、制訂規格説明、評審。

問題識別：就是從系統角度來理解軟件，確定對所開發系統的綜合要求，並提出這些需求的實現條件，以及需求應該達到的標準。這些需求包括：功能需求(做什麼)、性能需求(要達到什麼指標)、環境需求(如機型、操作系統等)、可靠性需求(不發生故障的概率）、安全保密需求、用户界面需求、資源使用需求(軟件運行是所需的內存、CPU等)、軟件成本消耗與開發進度需求、預先估計以後系統可能達到的目標。

分析與綜合： 逐步細化所有的軟件功能，找出系統各元素間的聯繫，接口特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。最後綜合成系統的解決方案，給出要開發的系統的詳細邏輯模型(做什麼的模型)。

制訂規格説明書： 即編制文檔，描述需求的文檔稱為軟件需求規格説明書。請注意，需求分析階段的成果是需求規格説明書，向下一階段提交。

評審： 對功能的正確性，完整性和清晰性，以及其它需求給予評價。評審通過才可進行下一階段的工作,否則重新進行需求分析。

目前，軟件需求的分析與設計方法較多，一些大同小異，而有的則基本思路相差很大。從開發過程及特點出發，軟件開發一般採用軟件生存週期的開發方法，有時採用開發原型以幫助瞭解用户需求。在軟件分析與設計時，自上而下由全局出發全面規劃分析，然後逐步設計實現。

從系統分析出發，可將需求分析方法大致分為功能分解方法、結構化分析方法、信息建模法和麪向對象的分析方法。

將新系統作為多功能模塊的組合。各功能義可分解為若干子功能及接口，子功能再繼續分解。便可得到系統的雛形，即功能分解——功能、子功能、功能接口。

結構化分析方法是一種從問題空間到某種表示的映射方法，是結構化方法中重要且被普遍接受的表示系統，由數據流圖和數據詞典構成並表示。此分析法又稱為數據流法。其基本策略是跟蹤數據流，即研究問題域中數據流動方式及在各個環節上所進行的處理，從而發現數據流和加工。結構化分析可定義為數據流、數據處理或加工、數據存儲、端點、處理説明和數據字典。

它從數據角度對現實世界建立模型。大型軟件較複雜；很難直接對其分析和設計，常藉助模型。模型是開發中常用工具，系統包括數據處理、事務管理和決策支持。實質上，也可看成由一系列有序模型構成，其有序模型通常為功能模型、信息模型、數據模型、控制模型和決策模型。有序是指這些模型是分別在系統的不同開發階段及開發層次一同建立的。建立系統常用的基本工具是E—R圖。經過改進後稱為信息建模法，後來又發展為語義數據建模方法，並引入了許多面向對象的特點。

信息建模可定義為實體或對象、屬性、關係、父類型/子類型和關聯對象。此方法的核心概念是實體和關係，基本工具是E-R圖，其基本要素由實體、屬性和聯繫構成。該方法的基本策略是從現實中找出實體，然後再用屬性進行描述。

面向對象的分析方法的關鍵是識別問題域內的對象，分析它們之間的關係，並建立三類模型，即對象模型、動態模型和功能模型。面向對象主要考慮類或對象、結構與連接、繼承和封裝、消息通信，只表示面向對象的分析中幾項最重要特徵。類的對象是對問題域中事物的完整映射，包括事物的數據特徵(即屬性)和行為特徵(即服務)。 ^[1] 

需求分析的特點及難點，主要體現在以下幾個方面。

(1)確定問題難。主要原因：一是應用領域的複雜性及業務變化，難以具體確定；二是用户需求所涉及的多因素引起的，比如運行環境和系統功能、性能、可靠性和接口等。

(2)需求時常變化。軟件的需求在整個軟件生存週期，常會隨着時間和業務而有所變化。有的用户需求經常變化，一些企業可能正處在體制改革與企業重組的變動期和成長期，其企業需求不成熟、不穩定和不規範，致使需求具有動態性。

(3)交流難以達到共識。需求分析涉及的人事物及相關因素多，與用户、業務專家、需求工程師和項目管理員等進行交流時，不同的背景知識、角色和角度等，使交流共識較難。

(4)獲取的需求難以達到完備與一致。由於不同人員對系統的要求認識不盡相同，所以對問題的表述不夠準確，各方面的需求還可能存在着矛盾。難以消除矛盾，形成完備和一致的定義。

(5)需求難以進行深入的分析與完善。需求理解對不全面準確的分析，客户環境和業務流程的改變。市場趨勢的變化等。也會隨着分析、設計和實現而不斷深入完善，可能在最後重新修訂軟件需求。分析人員應認識到需求變化的必然性，並採取措施減少需求變更對軟件的影響。對必要的變更需求要經過認真評審、跟蹤和比較分析後才能實施。 ^[1]