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

摘要：

　　本文是在管理信息系統需求調研實踐和學習中的一些經驗總結，有些是自己的體會，有些來自專家的書本或文章，希望與大家分享，并起到一個拋磚引玉的作用，如有不妥之處歡迎指正。

關鍵字：需求、調研

　　一、軟件需求的定義

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

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

　?。?） 系統或系統部件要滿足合同、標準、規范或其他正式規定文檔所需具有的條件或能力；

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

　　二、需求分析的幾個方面

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

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



　　三、需求文檔規范

　　A、三種編寫方法

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

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

　　3、 編寫形式化規格說明，這可以通過使用數學上精確的形式化邏輯語言來定義需求。

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

　　B、應有成果

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

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

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

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

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

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

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

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

　　C、文檔工具推薦

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

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

　　　3、 業務流程圖用VISIO中的FLOWCHART模板繪制；

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

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

　　　6、 數據物理模型用POWERDESINER繪制；

　　D、需求文檔編寫原則

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

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

　　　3、 需求陳述應該有一致的樣式，例如“系統必須..”或者“用戶必須..”，并緊跟一個行為動作和可觀察的結果。；

　　　4、 避免使用模糊、主觀的術語，減少不確定性，如“界面友好、操作方便”；

　　　5、 避免使用比較性詞語，如“提高”，應定量說明提高程度。


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

　　需求分析的任務是借助于當前系統的物理模型（待開發系統的系統元素）導出目標系統的邏輯模型（只描述系統要完成的功能和要處理的數據），解決目標系統“做什么”的問題，所要做的工作是深入描述軟件的功能和性能，確定軟件設計的限制和軟件同其他系統元素的接口細節，定義軟件的其他有效性需求，通過逐步細化對軟件的要求描述軟件要處理的數據，并給軟件開發提供一種可以轉化為數據設計、結構設計和過程設計的數據與功能表示。必須全面理解用戶的各項要求，但不能全盤接受，只能接受合理的要求；對其中模糊的要求要進一步澄清，然后決定是否采納；對于無法實現的要求要向用戶作充分的解釋。最后將軟件的需求準確地表達出來，形成軟件需求說明書SRS。其實現步驟如圖：



　　(1) 獲得當前系統的物理模型：首先分析、理解當前系統是如何運行的，了解當前系統的組織機構、輸入輸出、資源利用情況和日常數據處理過程，并用一個具體的模型來反映自己對當前系統的理解。此步驟也可以稱為“業務建?！?，其主要任務是對用戶的組織機構或企業進行評估理解他們的需要及未來系統要解決的問題，然后建立一個業務USECASE模型和業務對象模型。當然如果系統相對簡單，也沒必要大動干戈區進行業務建模，只要做一些簡單的業務分析即可。

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

　　(3) 建立目標系統的邏輯模型：明確目標系統要“做什么”

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

　　需求分析各過程如下：

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

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

　?。?） 編制需求分析文檔

　?。?） 需求評審

　　五、需求分析的要求

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

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

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

　　六、需求調研方法

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

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

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

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

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

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

　　七、調研基本策略

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

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

　　3、 以業務為主線，搞清每個業務的每個環節的流程關系、涉及部門、輸入輸出項；

　　4、 以數據為主線，搞清數據采集方式、數據流向、數據之間的內在聯系；

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

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

　　八、結構化方法分析步驟

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

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

　　3、 描述數據流細節，大型軟件可以使用數據字典描述所有數據元素；

　　4、 定義處理邏輯（加工邏輯：每個加工處理做什么）；

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

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

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

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

　　9、 確定軟硬件接口和環境需求。

　　九、UML方法分析步驟

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

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

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

　　?。?） 確定系統范圍和系統邊界；

　　?。?） 確定系統的約束（環境和條件）；

　　?。?） 定義活動者；

　　?。?） 確定系統的綜合要求（功能、性能、運行）；

　　?。?） 確定系統的數據要求（名稱、范圍、類型、數量、特點）；

　　?。?） 建立USE CASE模型、繪制USE CASE圖；

　　?。?） 繪制主要交互圖；

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

　　4、 建立動態行為模型（順序圖、協同圖、狀態圖、活動圖）；

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

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

　　企業級信息系統即著眼于整個企業的信息系統，是一個覆蓋企業所有業務領域、適應企業不斷發展的綜合信息系統，它是一個統一的整體數據具有一致性，提高了系統的綜合利用效率。

　　A、規劃階段

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

　?。?） 調查組織結構、建立組織關系層次圖；

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

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

　?。?） 給出每個目標完成的度量標準；

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

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

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

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

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

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

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

　　B、業務領域分析階段

　　1、 確定業務范圍、建立組織、制訂計劃；

　　2、 進行數據分析、建立詳細的數據模型（詳細實體關系圖）；

　　3、 業務活動分析（分析業務過程細節、分解業務過程、分析過程間的依賴關系、分析業務交互作用、建立業務活動模型）；

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

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

　　十一、調研說明與基本問題

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

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

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

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

　　每個環節的輸入和輸出之間的變化或關系是什么？

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

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

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

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

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

　　每個環節的輸入的數據項目有無檢驗規則？（如不能為空）
　　
　　從一個環節到下一個環節的條件是什么？

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

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

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



　　十二、需求管理

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

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

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

　?。?） 以一種可控的方式將需求變更融入到項目中；

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

　?。?） 分析變更所產生的影響并在此基礎上協商出新的約定；

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

　?。?） 在整個項目過程中跟蹤需求狀態及其變更情況。


　　

原文轉自：http://www.anti-gravitydesign.com