細談軟體需求分析過程

軟體的需求分析必須要有對原業務的一個深入瞭解、提取、抽象、升華的過程，管理軟體需求分析尤其如此。

軟體的需求分析是從使用者的業務中提取出軟體系統能夠協助使用者解決的業務問題，通過對使用者業務問題的分析，規划出我們的軟體產品。這個步驟是對使用者業務需求的一個升華，是一個把使用者業務管理流程最佳化，轉化為軟體產品，從而提升管理而實現的質的飛躍，這一步是否成功，直接關係到開發出來的軟體產品能否得到使用者認可，順利交付給客戶，客戶能否真正運用我們的產品協助他解決業務或管理問題。

按照軟體工程對軟體開發過程的描述，需求階段我們可以細分為需求調研和需求分析兩個小階段，需求調研需要充分細緻的瞭解客戶目標，使用者業務內容、流程等，這是一個對需求的採集過程，是進行需求分析的基礎準備。當我們已經瞭解、理解了使用者的業務，於是可以開始分析需求了。軟體系統的需求分析可以由產品工程師或系統分析員或兩者分階段合作完成全部的需求分析工作。

一、 提取出核心、主要、急迫的業務，明晰商務程序

通過需求調研，我們會發現使用者各方面的業務很多，從大處著眼，包括使用者的各種商務專案、商務程序，再明細到業務過程的每一個單據，每一條記錄，如生產過程中每一個環節的記錄，辦公中的每一個通知，甚至包括檔案報刊的收發，計劃生育指標統計等等。如此繁雜的各類業務，我們從何下手？這時需要我們回頭去查看軟體的項目規格說明書，再次溫故客戶對軟體項目或產品的最初提出的需求目標和範圍，我們的軟體主要是為使用者解決什麼樣的問題。從眾多的業務中提取出使用者核心的、主要的、急需的業務，這些是我們軟體需求主要關心所在。寫一篇文章需要重點突出，主次分明，我以為規劃一個軟體產品也是同理。

從使用者繁雜的業務中進行業務、商務程序的提取，把那些分布在各個部門的同一種業務提取出來。比如物資的管理，涉及到生產部門的需用計劃，匯總到物資部門的採購計劃，計劃的審批，採購合約，物資採購，物資部門的收發存業務，生產部門的物資領用消耗等等，我門需要分析使用者的這個商務程序中哪些是系統能協助管理的，哪些是要在系統外處理的，充分分析了使用者現有的業務和商務程序，我們進入下一步驟。

二、 運用管理思想，最佳化商務程序

我們提供的是管理軟體產品，要協助使用者解決的是管理問題，那麼使用者是這樣的商務程序，就需要我們分析這樣的流程合理嗎，還有缺陷嗎，怎樣做能提高效率、解決問題，可以運用更先進的管理思想嗎……。一般情況下，我們需要從兩個方面考慮商務程序的最佳化。一是我們採用了網路電腦這些新的技術手段，較之原先手工、電話等方式在資訊的傳遞、資訊的共用、資料的處理等方面將會帶來新的方式，必將改變原有的商務程序。另一方面就是我們根據對使用者業務的理解，考慮是否可以運用先進的管理思想，比如MRPII、ERP、SCM、CRM、JIT、EIA、E-Business等等管理模型，進行現有商務程序的重組或最佳化。當然一旦牽涉到商務程序的修改一定要與客戶的中高層管理者進行充分的溝通，只有客戶認同方可確定，因為這一定會在軟體實施時需要相應的管理制度配套執行。

三、 進行業務分類，規劃系統藍圖

以上都明確了以後，我們可以描繪系統藍圖了。系統有幾個子系統，每個子系統有哪些模組，各個模組處理哪些業務，很重要的一點還有各子系統模組之間的資料介面關係，基礎資料從哪裡進入，通過哪些處理產生哪些結果等等。這個過程需要整理、抽象使用者業務，規劃軟體實現，規劃軟體系統模組間的邏輯關係。因為系統的頁面實現是按照系統模組的規劃，所以應盡量採用使用者易理解、熟悉的方式、詞語進行模組的描述。

例如ERP系統中的物資管理子系統，首先明確這個子系統是ERP系統中進行物資相關的業務處理系統，同時它為主生產系統、成本管理子系統提供生產物資供應、領用消耗核算等的資料支援。因此在規划子系統模組時，按照業務過程模型，應包含物資需用計劃、物資採購計劃、出入庫管理、庫存管理等主要業務模組，再考慮軟體運行必須的初始資料設定，增加一個基礎資訊維護模組(包括物資大類、物資編碼等資訊維護)，還有考慮到不同使用者對此系統的不同需求，如更多的生產人員、管理員的需求，再單獨增加一個綜合查詢和分析模組。另外還有與物資採購相關的業務如採購合約，可以放到合約管理子系統統一考慮，這裡只做查詢。這樣規划出了軟體系統對物資管理業務的處理，檢查一下是否包含了物資管理中所有核心、主要的業務，這時我們發現還有比如物資採購、驗收、盤庫等業務還是需要物資管理業務人員來完成，系統可以做到的就是記錄結果。軟體系統是管理的輔助系統，不能完全代替人的所有工作。管理軟體再加上管理制度、業務人員的操作才構成一套完整的管理體系。

四、 詳細描述軟體功能點

規划出了軟體的功能模組，只是軟體的功能架構結構，下一步就需要明確描述每個模組的具體內容了。包含什麼內容、能做什麼操作，每一個功能點的說明、優先順序、商務規則、詳細功能描述等等。這些也是軟體需求規格必須描述的內容。

需求分析的表現方式，我們現在採用需求規格文檔，UML語言描述的使用案例圖、類圖、活動圖表，還有實體關聯圖、介面原型等等，從不同角度、不同需求描述規划出的軟體全貌。

五、 需求分析的品質控制

軟體需求分析直接關係到軟體產品的方向，所以需求分析的品質至關重要。對於這個關鍵點的品質控制，則可以通過內部評審和同行評審的方式，然後是客戶方的評審。項目組內部評審或同行評審主要是根據公司規範和評審人員本身的經驗對需求分析中不明確、不合理、不符合邏輯、不符合規範的地方予以指正。而客戶的評審主要是對描述的軟體實現是否真正符合他們的需求，能否協助他們解決問題等方面作出評定。

軟體的需求分析必須要有對原業務的一個深入瞭解、提取、抽象、升華的過程，管理軟體需求分析尤其如此。