如何做好軟件開發過程式中的軟件需求分析

軟件開發工作是IT行業中的重頭戲，軟件需求分析是軟件開發的出發點，為有效的需求管理提供了必要的前提，為設計起到指導性作用，同時還有助于預測銷售和收益，所以軟件需求分析在軟件開發過程中起著非常重要的作用。

一、需求分析的要求

需求分析必須能夠表達和理解問題的數據域和功能域。數據域應包括數據流、數據內容和數據結構。數據流式數據通過系統時的變化方式，對數據進行轉換就是程序的功能或子功能，兩個轉換之間的數據傳遞確定了功能間的接口；數據內容就是數據元素，數據元素由多個數據項組成，如在學校的學生管理信息系統中，“學生”字段有多個數據項，包括學號、姓名、性別、出生日期、成績等。數據結構是帶一種或多種關系的數據元素的集合。

需求分析必須按自頂向下、逐層分解的方式對問題進行分解和不斷細化。軟件的功能域和信息域都能做進一步的分解，可以是同一層次上的橫向分解，也可以是多層次上的縱向分解。

需求分析給出系統的邏輯模型和物理模型。邏輯模型給出軟件要達到的功能和要處理的數據之間的關系；物理模型給出處理功能和數據結構的實際表示形式。

二、需求調研

在做需求時，分析人員和客戶必須達到和諧的交流，融洽的溝通。通常采用以下幾種調研方法：

1．會談、詢問：圍繞軟件目標提出具體問題；

2．發放調查表；

3．收集分析客戶使用的各種表格、有關工作責任、工作流程、工作規范、相關數據標準、業務標準的各種文字資料；

4．收集同類相關產品的宣傳資料、技術資料、演示程序或軟件程序；

5．情景分析：利用情景分析誘導用戶能夠把需求告知分析員；

6．可視化方法：結合情景分析，利用畫用戶界面圖、業務流程圖、功能結構圖、時序圖等圖形與客戶進行討論。

一般分為規劃階段和業務領域分析階段：

在規劃階段，第一步要構建高層次的企業模型，包括：調查組織結構、建立組織關系層次圖；調查企業的任務、目標、戰略重點和關鍵成功因素并予以分類；識別每個目標和關鍵成功因素所需的信息；給出每個目標完成的度量標準；分析信息技術對企業業務的潛在影響；建立高層次企業模型；與企業中高層管理人員討論，對所得信息和分析進行補充和確認。第二步對功能進行分解，具體是輸出功能層次圖、功能關系圖、功能／組織矩陣；第三步進行實體分析，主要是輸出高層實體關系圖、實體類／信息需求矩陣、業務功能／實體類矩陣。第四步評估企業當前環境。第五步識別和確定預期的數據存儲和業務系統，建立業務系統的結構圖，確定和記錄業務領域。

在業務領域分析階段，第一步確定業務范圍、建立組織、制訂計劃；第二步進行數據分析、建立詳細的數據模型，即詳細的實體關系圖；第三步業務活動分析，包括分析業務過程細節、分解業務過程、分析過程間的依賴關系、分析業務交互作用、建立業務活動模型；第四步現有系統分析，具體指操作程序分解表、數據流圖、用戶感興趣的字段集；第五步業務領域模型的確認，包括完整性、正確性、長效性。

在做需求時不僅要求分析人員要有很強的溝通能力、語言表達能力，還要有相應的調研策略。首先確定用戶的軟件開發目標，確定系統基本范圍，然后圍繞這一目標，確定要訪問的部門和人員，要了解的業務，以業務為主線，搞清每個業務的每個環節的流程關系、涉及部門、輸入輸出項；以數據為主線，搞清數據采集方式、數據流向、數據之間的內在聯系；搞清哪些業務或數據是已建系統的，它們和新系統的關系是銜接還是替換；應思考是否有新技術可以改進現有工作，用戶提出的需求用現有技術能否實現。

三、需求分析過程

取得了需求之后，要對需求進行分析，分析過程是：

第一，問題識別。

解決目標系統做什么，做到什么程度。需求包括：功能、性能、環境、可靠性、安全性、保密性、用戶界面、資源使用、成本、進度。同時建立需求調查分析所需的通信途徑。

第二，分析與綜合。

從數據流和數據結構出發，逐步細化所有的軟件功能，找出各元素之間的聯系、接口特性和設計上的限制，分析它們是否滿足功能要求并剔除不合理部分，綜合成系統解決方案，給出目標系統的詳細邏輯模型。

常用的分析方法有面向數據流的結構化分析方法SA、描繪系統數據關系的實體關系圖E-R圖、面向數據結構的Jackson方法JSD、面向對象分析的方法OOA(主要用UML)。對于有動態時序問題的軟件可以用形式化技術，包括有窮狀態機FSM的狀態遷移(轉換)圖STD、時序圖、Petfi網。

上述每—種分析建模方法都有其優勢和局限性，可以兼而有之。以不同角度分析，應該避免陷入在軟件需求方法和模型中發生教條的思維模式和派系斗爭。一般來說結構化方法用于中小規模軟件、面向對象方法用于大型軟件。

結構化方法分析步驟是：畫出數據流圖；設計數據流圖必須逐步求精；決定哪些部分需要計算機化和怎樣計算機化；描述數據流細節，大型軟件可以使用數據字典描述所有數據元素；定義處理邏輯；定義數據存儲，即定義每個存儲的確切內容及其表示法；定義物理資源；確定輸入輸出規格說明；確定硬件所需有關數值；確定軟硬件接口和環境需求。

UML方法分析步驟是：調研、識別系統需求；分析問題領域：確定系統范圍和系統邊界、確定系統的約束、定義活動者、確定系統的綜合要求、確定系統的數據要求、建立USE CASE模型并繪制、繪制主要交互圖等；建立靜態結構模型：對象類圖、數據庫模型、包圖；建立動態行為模型：順序圖、協同圖、狀態圖、活動圖；建立系統物理模型：組件圖、配置圖；

第三，編制需求分析文檔。

需求分析文檔便于用戶、分析人員和設計人員進行理解和交流。用戶通過它可在分析階段即可初步判定目標軟件能否滿足其原來的期望，設計人員將它作為設計的出發點。

第四，需求評審。

在將需求分析文檔提交給設計之前，必須進行需求評審。一般以用戶、分析人員和設計人員共同參與的會議形式進行，包括以下評審標準：正確性、無歧異性、完全性、可驗證性、一致性、可理解性、可修改性和可追蹤性。

四、需求管理

需求分析過程是一個由粗到細、漸進明晰、持續完善的過程。在指導后面系統設計和編碼階段時都應當不斷完善修改需求文檔，因此需求管理非常重要。

需求管理包括在工程進展過程中維持需求約定集成型和精確性的所有活動，它是CMM模型二級中的首要KPA(關鍵過程域)。這些活動包括：定義需求基線(需求文檔的主體)；評審提出的需求變更申請、評估每項變更可能的影響，從而決定是否實施變更；以一種可控的方式將需求變更融入到項目中；使當前的項目計劃與需求保持一致；分析變更所產生的影響并在此基礎上協商出新的約定；使每項需求都能與其對應的設計、源代碼和測試用例聯系起來以實現跟蹤；在整個項目過程中跟蹤需求狀態及其變更情況。

五、總結

只有需求分析做好了，才對下一步的設計階段工作真正起到指導性作用，只有對需求管理好了，才能增強軟件的維護性等。

(作者單位：臨沂師范學院信息學院)