需求分析導引

摘要：各種需求分析方法各具特點，如果僅使用某種方法在項目實踐中往往會困難重重，怎樣結合各種需求分析方法之長為項目實踐建立一種需求分析參考標準成為一個迫切需要解決的問題。通過對面向問題域、面向對象、模型驅動等分析方法的研究，并結合在項目實踐中應用，以面向問題域分析為核心規定需求分析的根本目的與基本活動，結合面向對象的分析與模型驅動分析說明有效建模的技術要點，初步形成一個適合于實際項目活動的需求分析標準的框架。

關鍵詞：需求分析；面向問題域的需求分析；面向對象分析；領域模型驅動；需求分析標準

中圖分類號：TP302文獻標識碼：A文章編號：1009-3044(2008)35-2156-03

An Introduction to Requirements Analysis

FU Hong-lei1， ZHANG Yong-feng2

(1.CMDP Service Department of Nova Network Software Development Center， Beijing 100062， China; 2.Shanxi Normal Univercity， Linfen 041004， China)

Abstract: Each kind of demand analysis method each characteristic， but if will only use some method to be often beset with difficulties in the project practice， how to unify each demand analysis method long to establish one kind of demand analysis reference standard for the project practice to become the question which urgent needs to solve. Through the opposite to the question territory's analysis method， the object-oriented analysis method， the model actuation analysis method's research， and unifies in the project practice applies， take faces the question territory analysis as the core stipulation demand analysis primary purpose and the basic activity， unifies the object-oriented analysis and the model actuation analysis explanation effective modelling importance and the technical point， forms one to suit initially in the actual project activity demand analysis standard frame.

Key words: requirements anlysis; problem domain oriented analysis; analysis strategy; domain model driven; requirements analysis standard

1 引言

開發軟件就是通過描述來構建一部軟件機器去實現某一目的，因此在動手之前，我們需要詳細地弄清這個特定目的是什么，這就是需求分析需要完成的任務。

需求分析過程處于軟件工程的開始階段，它提供了軟件項目其余部分得以構建的根基，如果錯誤出現在需求分析階段，而且并未立即予以糾正，那么所有后續階段的工作將都在錯誤的基礎上進行，修正錯誤的代價將飛速增加。對于一個大型的軟件項目，一旦忽略或低估需求分析過程必將承擔風險。

2 需求分析的目的與活動

軟件項目的目的一般是解決一個信息化的問題，而需求分析的目的就是要定義所需解決的問題。一般情況下，對于項目組來說，總是要面對問題定義不足，需求不清的困境。因此，可以這樣初步理解需求分析的目的——需求分析過程就是要把一個定義不足的問題轉換為一個定義良好認并且清晰的問題并且找出解決方案。

要確定軟件項目的目的，那么首先要做的是識別問題，然后再去研究解決方案。

要識別問題，那么首先要去了解問題域。

問題域，應用領域或客戶領域，就是需要解決問題的現實世界的一個領域，而項目的最終成果，即解系統或新系統，將運行其上，產生某種效果而最終解決問題。

問題域并不等同新系統運作的環境，因為新的解系統將不可避免地對問題域進行改變，否則它就不可能解決問題，因此問題域與新系統運作環境事實上存在差別。

問題域也不等同于舊的應用系統，這個舊的應用系統可能是原有的計算機軟件系統或是非軟件的解決方案，因為舊的應用系統本身只是問題域的解決方案，即問題域的一個不成功的解系統，新的解系統也許會繼承其運作方式或者產生全新的運作方式，因此對舊的應用系統的研究不能替代對問題域的研究，雖然它可以提供一些知識，但它始終是問題域的一種包裝。舊的應用系統不僅僅指原有的計算機信息系統，也涉及客戶當前的工作流程和工作方式。

整個需求分析過程需要關注兩個系統——問題域與解系統，它們的相互關系如圖1。

這個相互關系也定義了三個主要開發活動的區域，如圖2所示。

對于這三個主要開發活動可以區別如下：

分析：關注問題域本身，清晰定義需要解決的問題。

規格說明：關注解系統與問題域的交互，規定解系統的運行方式以解決問題

設計：不屬于需求分析范疇，關注于解系統的內部實現。

因此，需求分析階段包含兩個主要活動，需求分析與規格說明。這兩個主要活動可簡述為：從問題域的研究入手，對問題域進行描述，獲取問題域的定義和客戶對新的解系統能夠產生的效果（需求）的陳述，以此確定新的解系統所應具有的功能，以便達到客戶所需要的效果。

顯而易見，需求分析階段必然包括兩個主要文檔，一個應當包含問題域特性的細致描述與需求的陳述，稱之為《用戶需求說明書》；另一個包含經過精心設計的解系統的功能的描述，這個精心設計的行為可以滿足客戶的需求，稱之為《軟件需求規格說明書》。

3 需求獲取

3.1 “獲取”與“采集”

“需求采集”隱含表示已有了“成熟”的需求，只需要去“采集”，而實際上很少會有這種情況，客戶“原始”的需求往往是以很零散、很不完整的形式呈現出來。“獲取”隱含著一個知識傳遞的過程，“需求獲取”是要將隱藏在問題域之中的信息明確化、具體化、系統化，并與客戶形成共識。

3.2 需求獲取的信息

對于大型的軟件系統，由需求分析階段的整體要求決定，應當包括：1)問題域的描述；2)要求解決的問題列表，即需求列表；3)用戶對解系統想要施加的任何約束；

3.3 信息來源

問題域中信息的主要來源，即需求獲取人員應當關注的對象，包括：1）實際的客戶和潛在的客戶；2）客戶的“要求說明”；3）任何原有解系統及其文檔；4）原有系統的用戶和新的解系統的可能用戶；5）開發者相似產品；6）競爭對手產品；7）行業專家；8）定義任何操作規范或數據規范的文檔；9）相關的技術標準與法規。

3.4 需求獲取的技術

獲取需求的技術與信息的可能來源密切相關，大致包括：閱讀背景材料；面談；調查表；檢查文檔；任務觀察；人種論；用例與場景；討論分析；聯合應用設計；需求剝離等方法，這里不再詳述。

3.5 需求獲取策略

3.5.1 一般策略

1）從一般到具體，通過概述幫助確定每次需求獲取的目標，適當時候再詳細調查；2）要敢于陳述好像是顯而易見的事實；3）從信息的源頭探究，而不是道聽途說；4）信息來源多多益善；5）主管與高層應適時介入；6）注意消除分歧。

3.5.2.管理者與一般用戶

1）管理者：一般對原始數據不感興趣，只對增加新的業務知識的信息感興趣；關注的是整體，通常對細節不感興趣；對業務功能的整體視圖感興趣；從系統支持的功能和改進的預期方面理解系統；可以幫助確定需要收集和存儲數據的相關業務實體；可以幫助理解描述業務實體是如何交互的簡單業務關系和規則；需要持續跟蹤這些業務實體和規則，以產生有用的信息；會談時可使用業務事件列表及對那些事件的響應方式記錄業務功能（包括時間）；可能會了解新系統需要為哪些企業部門、員工、客戶和外部企業提供接口；這些接口位于什么地方；是否需要同其他的信息系統或自動化系統接口。

2）一般用戶：以目前數據如何存儲或他們認為數據應如何存儲的方式來看待數據；說明被存儲的確切數據屬性以及用于維護這些數據的精確業務規則；應當正確地確定和驗證用戶的業務數據需求；業務過程——為了提供對業務事件的恰當響應必須執行的“工作”；以過程需求的方式說明新系統的業務過程，過程需求通常以策略和規程的形式定義；關心輸入與輸出；輸入輸出的構成細節，圖型用戶界面的原型形式，形似于PC工具（WORD，EXCEL）。

3.5.3 需求演化

問題域本身遠不及需求更易于變化，用戶可能要求產生新的報表或采用不同的方式對某一部分產生控制，但底層的問題域數據或相關元素的內在行為的變化卻很少。首先應當將問題域特性描述與需求分離；可維護文檔是另一個關鍵因素；時間越長，變化的可能越大，鼓勵盡快完成系統開發。

4 需求分析

4.1 目的

需求分析的根本目的：通過對問題領域的研究，獲得對該領域特性及存在于其中需要解決的問題特性的透徹理解并用文檔說明。

需求分析的輸出結果是《用戶需求說明書》，該文檔應當能夠提供關于問題域各個相關方面的全面描述和有關客戶需求的完整的列表。

4.2 需求分析策略

4.2.1 關注問題域

需求分析強調的揭示問題域的結構與屬性，而不是將來解系統將要實現的功能。

4.2.2 建模與描述

分析的總目標可以被認為是以某種易于理解的形式提供所有必需的信息。這就需要對收集得來的信息應當精心加以提煉，獲取精華從而保證所有相關的細節能以一種清晰、符合邏輯且簡潔的方式得以呈現——建立合適的問題領域的模型。

許多系統真正復雜之處不在于技術，而在于問題領域本身。如果在需求分析時沒有獲得對問題領域的深刻理解，沒有通過模型將復雜的領域邏輯以模型概念和模型元素的形式清晰地表達出來，那么無論我們使用多么先進的平臺或架構，都難以保證項目的真正成功。

成功項目的特征是：在迭代中不斷地完善領域模型，通過領域模型越過問題域的表象揭示其底層的結構；將這個領域模型作為項目骨干結構的一部分；模型是知識的一種有選擇的簡化和有意識的組織形式，一個合適的模型能夠表達信息的含義并聚焦于問題本身；模型并不是某種特殊的圖，而是圖所要表達的思想，可能是圖也可以是認真編寫的代碼或形式化語言，模型松散地表現具有特定目的的現實不要試圖用UML表示出整個模型或設計。很多對象模型過于完整，又遺漏了很多東西：總是想要把的有將要編碼的對象都放進去，所有的東西過于細化；屬性與關系只占到一個對象模型的一半內容，那些對象的行為及約束則不容易用圖例表達出來。因此，應當采用圖與描述相結合的方式：約束與斷言可用括號包含的文本在對象關系圖中表達；對象與模型所代表的概念意義（定義）和對象所要完成的工作應當以文本加以描述。與其使用一個帶有文本注釋的圖，不如編寫一個文本文檔，里面用經過挑選的簡化圖做示例。

4.2.3 有效模型因素

1）模型與編碼實現相互綁定；2）基于模型產生一種通用語言，既可以用來與領域專家進行溝通，又可以做為需求、設計、編碼的溝通語言；

3）開發一個包含豐富知識的模型；4）精煉模型；5）采用頭腦風暴與實驗來驗證模型。

4.2.4 模型分析過程

1）從需求獲取中得到領域模型的元素，建立初步的領域模型；2）在討論中細化，在詢問中解釋，隨著對領域的理解和領域專家對模型如何在問題解決中發揮作用的理解，模型一步步地發展；3）編寫一個簡單的原型，該原型是能夠精確地反映領域模型的部分軟件系統，開發人員結合領域專家通過各種場景一步一步地使用模型對象來非正式地走查模型，當原型不能完成一個重要的場景時，對模型進行修改；4）原型并不僅僅是界面，重要的是清晰地表達業務邏輯和行為。

4.2.5 面向對象的分析

1）需求分析的基本技術手段是面向對象的分析。

2）類模型作用的延續性：

需求分析階段——問題域概念化，建立問題域類模型；

規格說明階段——規格說明，建立接口類；

編碼實現階段——業務模型實現，建內部設計的業務類。

3）用例的作用應該是有限的，使用用例避開了對問題域及相關問題做全面考慮，并直接對解系統的行為進行定義。

4）面向對象分析的補充：

在面向對象分析的過程中可建立DD（數據字典）來定義和解釋術語與數據項；

分析初期可采用傳統意義的流程圖幫助理解問題域，但最終要避免讓業務流程成為模型中的突出方面，對象意味著將業務流程封裝起來，對于復雜的處理流程可以用服務來進行封裝，對于多種分支流程，可以將算法本身作為一個獨立的對象，選擇不同的流程也就選擇不同的對象，每個對象代表一個不同的策略。

可以單獨列出問題域事件與輸入列表及這些事件可能的發生序列；

應當對需求（需在問題域中求解的問題）單獨列表，包括必須支持的查詢與需要提供的報表。

4.2.6 用戶需求文檔

1）文檔核心內容：結合模型對每個問題子域的全面描述；需求列表，需求應避免指導該如何解決問題；如果出現了被初始載入系統的數據是那些原有的、以電子方式存儲的數據的情況，那么存取這類數據的方式就應該詳細闡述；數據字典。

2）特性與需求：語態的區別清楚地區分問題域的內在特性及需求；特性是對問題域的真實的反映，它們完全超出了所要構建的新的解系統所能控制與影響的范圍，其聲明采用指示語態；需求是新系統能夠控制的東西，即要求新系統產生的結果。其聲明使用祈使語態，它反映了有客戶選定的選項；只要給出問題域的內在特征，新系統應當完全有能力滿足需求。

5 規格說明

5.1 規格說明的任務

創建并定義新系統的一種行為，使之在問題域中產生所需要的效果。創建新系統可能的行為并選擇某一種行為，然后進行規格說明文檔編制，并經由客戶同意。

5.2 規格說明策略

5.2.1 外部接口

1）規格說明關注問題域與新系統之間的接口，即關注的是新系統的外部視圖；2）新系統的行為將通過其與問題域交互的接口來定義。軟件系統通過傳遞數據與外部世界發生交互，每一個接口將有一個從新系統接收或發送數據的端子，這個端子可能是操作員、其他軟件系統、電子硬件等，定義接口的首要任務是識別端子；3）在規格說明階段一般要添加新的端子，如系統管理員接口。

5.2.2 功能抽象

1）通過確定新系統輸入和輸出的語法與語義，以及這些輸入和輸出之間所需的關系（時間關系、因果關系），就可以表達新系統所需的行為；

2）規格說明需要添加大量的輸入和輸出：如用戶提示及消息、操縱接口所需的用戶命令、無效的或異常輸入的處理等；

3）可以分別在詳細與抽象級別上確定新系統的行為；

4）可采用邏輯層次分解的方式進行規格說明。

5.2.3 文檔編制

1）規格說明文檔應首先以一種很大的粒度來討論和理解新系統，可以用一組高層次的概念或規則來整個新系統建立一個模式，使人們能夠基本理解每個部分在整體中所處的位置，即使他們并不了解這個部分職責的細節內容，其次可以對一些核心元素進行專門的說明；

2）文檔與原型相結合，文檔不應該去做原型已經做得很好的工作，如所有的細節問題，精確的程序行為說明，文檔要對原型的概念進行解釋，并幫助定位到代碼中的細節；

3）在定義輸入與輸入關系時，應采用功能性的說明方式，而不要去描述過程；

4）加入性能需求，關注系統可用性。

6 需求驗證

1）正因為需求階段所犯的錯誤代價昂貴，因此，尤為重要的是設法把錯誤減到最少，并且一有可能就檢測與更正任何已出現的錯誤；

2）需求驗證機制，可采用確保一致性的簡單檢查、問題域專家評審、邏輯分析、系統Demo、測試用例設計、編制用戶手冊等方法。

7 結束語

筆者在長期的需求分析工作中，感覺到各種的系統分析理論各具特點，僅僅依靠某種分析方法的指導，很難保證項目的圓滿完成，項目組雖然有CMM規范指導按步驟完成一個個項目過程，但怎樣去完成工作產品才能提高項目的質量仍然缺乏有效的指導與規范，總結多年的學習與實踐經驗，完成此文檔，希望能對項目的需求分析過程具有參考和指導意義，能夠對提高需求分析工作產品的質量有所幫助。

參考文獻：

[1] Bray L K.REQUIREMENTS ENGINEERING:需求工程導引[M].舒忠梅.羅文村.譯.北京:人民郵電出版社，2003.

[2] Evans E:Domain-Driven Design:領域驅動設計[M].陳大峰，張澤鑫，譯.北京:清華大學出版社，2006.

[3] Jeffrey L， Whitten L D， Bentley K C.Sytems Analysis and Design Methods:系統分析與設計方法[M].肖剛，孫慧，譯.北京:機械工業出版社， 2005.