管理信息系統需求調研分析指南

摘要：本文是在管理信息系統需求調研實踐和學習中的一些經驗總結，有些是本身的體會，有些來自專家的書本或文章，但願與你們分享，並起到一個拋磚引玉的做用，若有不妥之處歡迎指正。

1、軟件需求的定義

IEEE軟件工程標準詞彙表（1997年）中定義的需求爲：

（1） 用戶解決問題或達到目標所需的條件或能力；

（2） 系統或系統部件要知足合同、標準、規範或其餘正式規定文檔所需具備的條件或能力；

（3） 一種反映上述條件和能力的文檔說明。

2、需求分析的幾個方面

需求分析可分爲問題識別、分析與綜合、編制需求分析文檔、需求評審等四個階段，包括如下幾個方面：肯定軟件所指望的用戶類；獲取每一個用戶的需求；瞭解實際用戶任務和目標以及這些任務所支持的業務需求；分析員與用戶的信息以區別用戶任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息；將系統級的需求分爲幾個子系統，並將需求中的一部分分配給軟件組件；瞭解相關質量屬性的重要性；討論得出實施優先級；將所收集的用戶需求編寫成需求規格說明和模型；評審需求規格說明，確保與用戶達成共識。

軟件需求的各組成部分以下圖所示：

3、需求文檔規範

A、三種編寫方法

一、 用好的結構化和天然語言編寫文本型文檔；

二、 創建圖形化模型，這些模型能夠描繪轉換過程、系統狀態、和它們之間的變化、數據關係、邏輯流或對象類和他們的關係；

三、 編寫形式化規格說明，這能夠經過使用數學上精確的形式化邏輯語言來定義需求。

多種編寫方法可在同一個文檔使用，根據須要選擇，或互爲補充，以可以把需求說明白爲目的。

B、應有成果

一、 各業務手工辦理流程文字說明；

二、 各業務手工辦理流程圖；

三、 各業務手工辦理各環節輸入輸出表單、數據來源；

四、 目標軟件系統功能劃分（示意圖及文字說明）；

五、 目標軟件系統中各業務辦理流程文字說明；

六、 目標軟件系統中各業務辦理流程圖（模型）；

七、 目標軟件系統中各業務辦理各環節數據、數據採集方式、數據間的內在聯繫分析。

八、 目標軟件系統用戶界面圖、各式系統邏輯模型圖及說明

C、文檔工具推薦

一、 調研結果《需求分析說明書》格式參照開發文檔模板；

二、 單位組織結構圖、功能模塊分解圖用VISIO繪製，或直接用WORD中的畫圖工具；

三、 業務流程圖用VISIO中的FLOWCHART模板繪製；

四、 系統邏輯模型使用ROSE繪製活用VISIO中的UML模板繪製；

五、 軟件用戶界面用VISIO中的WIN95 USER INTERFACE模板繪製；

六、 數據物理模型用POWERDESINER繪製；

D、需求文檔編寫原則

一、 句子簡短完整，具備正確的語法、拼寫和標點；

二、 使用的術語與詞彙表中所定義的一致；

三、 需求陳述應該有一致的樣式，例如「系統必須..」或者「用戶必須..」，並緊跟一個行爲動做和可觀察的結果；

四、 避免使用模糊、主觀的術語，減小不肯定性，如「界面友好、操做方便」；

五、 避免使用比較性詞語，如「提升」，應定量說明提升程度。

4、需求分析的任務與過程

需求分析的任務是藉助於當前系統的物理模型（待開發系統的系統元素）導出目標系統的邏輯模型（只描述系統要完成的功能和要處理的數據），解決目標系統「作什麼」的問題，所要作的工做是深刻描述軟件的功能和性能，肯定軟件設計的限制和軟件同其餘系統元素的接口細節，定義軟件的其餘有效性需求，經過逐步細化對軟件的要求描述軟件要處理的數據，並給軟件開發提供一種能夠轉化爲數據設計、結構設計和過程設計的數據與功能表示。必須全面理解用戶的各項要求，但不能全盤接受，只能接受合理的要求；對其中模糊的要求要進一步澄清，而後決定是否採納；對於沒法實現的要求要向用戶做充分的解釋。最後將軟件的需求準確地表達出來，造成軟件需求說明書SRS。其實現步驟如圖：

(1) 得到當前系統的物理模型：首先分析、理解當前系統是如何運行的，瞭解當前系統的組織機構、輸入輸出、資源利用狀況和平常數據處理過程，並用一個具體的模型來反映本身對當前系統的理解。此步驟也能夠稱爲「業務建模」，其主要任務是對用戶的組織機構或企業進行評估理解他們的須要及將來系統要解決的問題，而後創建一個業務USECASE模型和業務對象模型。固然若是系統相對簡單，也不必大動干戈區進行業務建模，只要作一些簡單的業務分析便可。

(2) 抽象出當前系統的邏輯模型：在理解當前系統「怎樣作」的基礎上，取出非本質因素，抽取出「作什麼」的本質。

(3) 創建目標系統的邏輯模型：明確目標系統要「作什麼」

(4) 對邏輯模型的補充，如用戶界面、啓動和結束、出錯處理、系統輸入輸出、系統性能、其餘限制等等。

需求分析各過程以下：

（1） 問題識別：解決目標系統作什麼，作到什麼程度。需求包括：功能、性能、環境、可靠性、安全性、保密性、用戶界面、資源使用、成本、進度。同時創建需求調查分析所需的通訊途徑。

（2） 分析與綜合：從數據流和數據結構出發，逐步細化全部的軟件功能，找出各元素之間的聯繫、接口特性和設計上的限制，分析它們是否知足功能要求並剔除不合理部分，綜合成系統解決方案，給出目標系統的詳細邏輯模型。經常使用的分析方法有面向數據流的結構化分析方法SA（數據流圖DFD、數據詞典DD、加工邏輯說明）、描繪系統數據關係的實體關係圖ERD、面向數據結構的Jackson方法JSD、面向對象分析方法OOA（主要用UML）、對於有動態時序問題的軟件能夠用形式化技術，包括有窮狀態機FSM的狀態遷移（轉換）圖STD、時序圖、Petri網或Z。每一種分析建模方法都有其優點和侷限性，能夠兼而有之以不一樣角度分析，應該避免陷入在軟件需求方法和模型中發生教條的思惟模式和派系鬥爭，通常來講結構化方法用於中小規模軟件、面向對象方法用於大型軟件。

（3） 編制需求分析文檔

（4） 需求評審

5、需求分析的要求

一、 必須可以表達和理解問題的數據域和功能域：系統的目的都是爲了解決數據處理問題，就是將一種形式的數據轉換（輸入、處理、輸出）爲另外一種形式的數據。數據域應包括數據流、數據內容和數據結構。數據流式數據經過系統時的變化方式。對數據進行轉換就是程序的功能或子功能，兩個轉換之間的數據傳遞肯定了功能間的接口。數據內容就是數據項，如人的數據項包括姓名、性別、出生日期等等。數據結構即各類數據項的邏輯組織，如是表格結構仍是樹形結構、數據項間的相互關係

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

三、 給出系統的邏輯模型和物理模型：邏輯模型給出軟件要達到的功能和要處理的數據之間的關係；物理模型給出處理功能和數據結構的實際表示形式

6、需求調研方法

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

二、 調查表：通過仔細考慮的書面回答可能比會談中的回答更加準確；

三、 收集分析客戶使用的各類表格、有關工做責任、工做流程、工做規範、相關數據標準、業務標準的各類文字資料；

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

五、 情景分析：利用情景分析誘導用戶可以把它們的需求告知分析員（能夠描述當前一項業務怎麼作、也能夠描述設想的系統中此項業務怎麼作）；

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

7、調研基本策略

一、 首先肯定用戶的軟件開發目標，肯定系統基本範圍，而後圍繞這一目標，肯定要訪問的部門和人員，要了解的業務，在基本範圍內展開調研；

二、 以部門職責爲基礎搞清各類現有業務、要填寫的表簿冊文檔報表等，其數據來源及去向；

三、 以業務爲主線，搞清每一個業務的每一個環節的流程關係、涉及部門、輸入輸出項；

四、 以數據爲主線，搞清數據採集方式、數據流向、數據之間的內在聯繫；

五、 搞清哪些業務或數據是已建系統的，它們和新系統的關係是銜接仍是替換；

六、 應思考是否有新技術能夠改進現有工做，用戶提出的需求用現有技術可否實現。

8、結構化方法分析步驟

一、 畫出數據流圖。設計數據流圖必須逐步求精；

二、 決定哪些部分須要計算機化和怎樣計算機化（取決於用戶投資限制和自身技術限制）；

三、 描述數據流細節，大型軟件可使用數據字典描述全部數據元素；

四、 定義處理邏輯（加工邏輯：每一個加工處理作什麼）；

五、 定義數據存儲，即定義每一個存儲的確切內容及其表示法（格式）；

六、 定義物理資源：如是文件需指定：文件名、組織結構（排序、索引等）、存儲介質和記錄；如是數據庫需指定每一個表的相關信息；

七、 肯定輸入輸出規格說明，如輸入內容、輸入屏幕、打印輸出格式、輸出長度等等；

八、 肯定硬件所需有關數值，如輸入量、打印頻率、CPU、記錄大小、數據量大小、文件大小等等；

九、 肯定軟硬件接口和環境需求。

9、UML方法分析步驟

通常的應用系統又是各組成部分：問題論域、人機界面、數據管理、任務管理，在OOA階段重點對問題論域進行分析，對人機界面、數據管理、任務管理等問題，OOA通常較少或沒有分析，而是留待OOD階段解決。

一、 調研、識別系統需求；

二、 分析問題領域：主要任務是充分理解領域問題和項目投資者及用戶的需求，對需求進行抽象，提出高層次的解決方案）；

（1） 肯定系統範圍和系統邊界；

（2） 肯定系統的約束（環境和條件）；

（3） 定義活動者；

（4） 肯定系統的綜合要求（功能、性能、運行）；

（5） 肯定系統的數據要求（名稱、範圍、類型、數量、特色）；

（6） 創建USE CASE模型、繪製USE CASE圖；

（7） 繪製主要交互圖；

三、 創建靜態結構模型（對象類圖、數據庫模型、包圖）；

四、 創建動態行爲模型（順序圖、協同圖、狀態圖、活動圖）；

五、 創建系統物理模型（組件圖、配置圖）；

10、企業級信息系統調研分析步驟

企業級信息系統即着眼於整個企業的信息系統，是一個覆蓋企業全部業務領域、適應企業不斷髮展的綜合信息系統，它是一個統一的總體數據具備一致性，提升了系統的綜合利用效率。

A、規劃階段

一、 構建高層次的企業模型

（1） 調查組織結構、創建組織關係層次圖；

（2） 調查企業的任務、目標、戰略重點和關鍵成功因素並予以分類；

（3） 識別每一個目標和關鍵成功因素所需的信息；

（4） 給出每一個目標完成的度量標準；

（5） 分析信息技術對企業業務的潛在影響；

（6） 創建高層次企業模型（描述業務處理的主題域及其關係、創建企業初始功能層次圖）；

（7） 與企業中高層管理人員討論，對所得信息和分析進行補充和確認；

二、 對功能進行分解（輸出：功能層次圖、功能關係圖、功能／組織矩陣）；

三、 進行實體分析（輸出：高層實體關係圖、實體類／信息需求矩陣、業務功能／實體類矩陣）；

四、 評估企業當前環境（現有系統和數據存儲的清單、信息結構的範圍、信息需求列表、組織、技術環境）；

五、 識別和肯定預期的數據存儲和業務系統，創建業務系統的結構圖，肯定和記錄業務領域；

B、業務領域分析階段

一、 肯定業務範圍、創建組織、制訂計劃；

二、 進行數據分析、創建詳細的數據模型（詳細實體關係圖）；

三、 業務活動分析（分析業務過程細節、分解業務過程、分析過程間的依賴關係、分析業務交互做用、創建業務活動模型）；

四、 現有系統分析（操做程序分解表、數據流圖、用戶視圖：用戶感興趣的字段集）；

五、 業務領域模型的確認（完整性、正確性、長效性）

11、調研說明與基本問題

很多行業的業務都是由一系列環節構成的業務流程組成的，有的簡單隻有一兩個環節，有的複雜有多個環節，還可能有循環或分枝，系統軟件不只要解決獨立環節的業務問題，並且要可以自動把這些環節串聯起來，但願一個環節所作的工做可以自動被下一個環節利用，這就是最基本工做流的需求。例如一個案件從接案、立案、偵查、起訴，到執行由不一樣的部門來完成。這些環節不是獨立的，後面的環節不該該比前面的發生的早，也不能延遲過多，由於存在法律時限，而且流程中存在循環，也就是說某些環節可能重複屢次，再者每一個部門的流程種類又多，每一個工做人員可能要處理多個環節上的任務。所以咱們把每一個業務的每一個環節搞清楚，主要搞清如下幾個基本問題：

每一個流程中的每一個環節是否已經不能再分解？

每一個流程中的每一個環節的主辦（責任）部門是誰？

每一個環節要求的輸入（項目、格式、方式）和輸出（項目、格式、方式）是什麼？

每一個環節的輸入和輸出之間的變化或關係是什麼？

每一個環節的輸入的數據來源是什麼？

每一個環節的輸出的數據去向是什麼？

每一個環節的數據項目有無國家標準或部頒標準或其餘標準？

每一個環節的數據項目的類型是什麼？

每一個環節的責任人對本環節中數據項目的權限是什麼？（可新建、可刪除、可修改、只讀、）

每一個環節的輸入的數據項目有無檢驗規則？（如不能爲空）

從一個環節到下一個環節的條件是什麼？

從一個環節到下一個環節有無時間限制？是多少？

收集上來的表單用在哪一個業務中的哪一個環節？

多個表單間的關係：繼承？關聯？

12、需求管理

需求調研分析過程是一個由粗到細、漸進明晰、持續完善的過程。在指導後面系統設計，編碼階段時都應當不斷完善修改需求文檔，所以需求管理很是重要。需求管理包括在工程進展過程當中維持需求約定集成型和精確性的全部活動，它是CMM模型二級中的首要KPA（關鍵過程域），這些活動包括：

（1） 定義需求基線（需求文檔的主體）；

（2） 評審提出的需求變動申請、評估每項變動可能的影響，從而決定是否實施變動；

（3） 以一種可控的方式將需求變動融入到項目中；

（4） 使當前的項目計劃與需求保持一致；

（5） 分析變動所產生的影響並在此基礎上協商出新的約定；

（6） 使每項需求都能與其對應的設計、源代碼和測試用例聯繫起來以實現跟蹤；

（7） 在整個項目過程當中跟蹤需求狀態及其變動狀況。

   參考文獻：

   《實用》第二版，鄭人傑、殷人昆、陶永雷等著

   《軟件需求》Soren Lauesen著，劉曉暉譯

   《軟件工程：實踐者的研究方法》（第5版）Roger S.Pressman著

原文：http://blog.sina.com.cn/s/blog_53c53b7f0101oxxz.html