軟件開發過程中的需求分析探討

摘要：軟件需求分析是軟件工程過程中計劃階段的一個決定性步驟，在這一步將把含糊的軟件概念轉變成具體的規格說明，從而奠定了軟件開發的基礎。本文通過對需求的定義、需求的類型、需求分析的任務、需求分析的方法、需求的變更以及應用實例等幾個方面的介紹，對于在軟件開發中做好需求分析有一定的借鑒作用。

關鍵詞：軟件；開發；需求；分析

中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2008)32-1125-04

The Study on Requirement Analysis in Software's Development

WU Zheng

(Anhui Family Planning School， Chizhou 247000， China)

Abstract: software requirement analysis is a decisive step of planning stage in software engineering， it changes unclear software concept into specific explainations in this step， thus，it establishes foundation of software development.This paper intoduces the requirement definition，types of the requirement， the mission of the requirement analysis， the method of the requirement analysis，the change of the requirement，and applied example etc. These intoductions will be helpful in requirement analysis of software’s development.

Key words: software; development; requirement; analysis

1 引言

軟件項目的開發主要分為五個階段：需求分析階段、設計階段、編碼階段、測試階段和維護階段，需求調研和分析是軟件開發的第一個階段。完善的軟件需求說明是軟件開發項目得以成功的基礎。不管設計如何精心或者編碼如何巧妙，如果對軟件需求不加以明確規定，將使用戶感到失望，并給軟件開發者帶來嚴重后果。據權威部門統計，目前軟件的成功率約為25%，75%的軟件是失敗的。在這75%的失敗中，約有50%以上的軟件是由于需求的原因造成的。另有資料表明，軟件開發項目中返工開銷幾乎占開發總費用的一半，而導致返工的主要原因是需求分析錯誤或不明確，從而引發項目開發中的一系列更改。成功的軟件需求分析不僅能提高軟件的成功率，而且能節省大量的資源，因此需求分析是軟件開發的關鍵階段。[1]

2 需求的定義和類型

2.1 需求的定義

軟件產業存在的一個普遍問題就是缺乏統一定義的名詞術語來描述我們的工作。客戶所定義的“需求”對開發者似乎是一個較高層次的產品概念，而開發人員所說的“需求”對用戶來說又像是詳細設計了。實際上，軟件需求包含著多個層次，不同層次的需求從不同角度與不同程度反映著細節問題。

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

1) 用戶解決問題或達到目標所需的條件或能力。

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

3) 一種反映上面1)或2)所描述的條件或能力的文檔說明。

IEEE的定義包括從用戶角度（系統的外部行為），以及從開發者角度（一些內部特性）來闡述需求，其關鍵的問題是一定要編寫需求文檔。

另外，還有其他幾種關于“需求”的定義：

需求是用戶所需要的并能觸發一個程序或系統開發工作的說明；

需求是從系統外部能發現系統所具有的滿足于用戶的特點、功能及屬性等；

需求是指明必須實現什么的規格說明。它描述了系統的行為、特性或屬性，是在開發過程中對系統的約束。

從以上的定義中，我們依然無法得到有關“需求”的清晰概念，真正的“需求”實際上存在人們的腦海中，任何文檔形式的需求（例如：需求規格說明）僅是一個模型或一種敘述，但是編寫出高質量的需求規格說明書在需求分析階段還是關鍵。

需求分析奠定了軟件工程和項目管理的基礎。我們在建造軟件系統這座大廈的時候，如果需求分析的基礎不夠堅實和牢固，那么往往會導致軟件系統問題百出，甚至被馬上丟棄。在建造軟件系統的過程中，如果我們經常習慣地沿用一些不規范的方法，其后果便是產生一條鴻溝──開發者開發的與用戶所想得到的軟件存在著巨大的“期望差異”。 因此“需求”這個名詞的定義不僅僅是從用戶角度對系統外部行為的描述，以及從開發人員角度對系統內部特性的描述，其關鍵的一點是“需求”必須文檔化。

2.2 需求的類型

軟件需求包括三個不同的層次──業務需求、用戶需求和功能需求。

除此之外，每個系統還有各種非功能需求。

業務需求（BusinessRequirement）表示組織或客戶高層次的目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什么要開發一個系統，即組織希望達到的目標。使用前景和范圍（vision and scope）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔。

用戶需求（UserRequirement）描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統來做些什么。

功能需求（Functional Requirement）規定開發人員必須在產品中實現的軟件功能，用戶利用這些功能來完成任務，滿足業務需求。功能需求有時也被稱作行為需求（behavioral requirement），因為習慣上總是用“應該”對其進行描述：“系統應該發送電子郵件來通知用戶已接受其預定”。功能需求描述是開發人員需要實現什么。

非功能需求（Non-functional Requirement） 定義了軟件產品為滿足用戶業務需求而必須具有的除功能需求以外的特性。包括系統的完整性（聯機幫助、 數據管理、用戶管理、軟件發布管理、在線升級等）、性能、可靠性、可維護性、可擴充性、對技術和業務的適應性等。

3 需求分析的任務

3.1 解決的問題

1) 齊全、準確地找出目標系統全部的功能、性能、限制；

2) 找出全部的輸入流、輸出流；

3) 找出所有的加工；

4) 產生完整的分層的DFD、數據字典、加工的描述；

5) 補充的意見。

3.2 綜合要求

確定對系統的綜合要求，系統功能要求，系統性能要求，運行要求，將來可能提出的要求。

3.3 任務

圖1為需求分析任務圖，需求分析階段要完成的具體明確的最終任務就是形成一份經開發方和用戶認可或達成共識的軟件需求分析文檔（需求規格說明書、修改后的項目開發計劃、初步的用戶手冊、確認測試計劃、數據要求說明書）。這個文檔能清晰準確地說明系統將要開發什么，能夠規定出詳細的技術需求，包括所有面向用戶、面向機器和其它軟件系統的接口。可以說需求文檔在開發過程中一直起指導作用。

為了更好地完成軟件開發第一階段的需求分析任務，提高質量，需求管理是必不可少的。

需求管理的目的是在客戶與開發方之間建立對需求的共同理解，維護需求與其他工作成果的一致性，并控制需求的變更，主要體現在跟蹤和控制需求變更管理。需求管理是開發工作有效進行的保證，是一種很高層次的系統行為，涉及整個開發過程和產品本身。

4 需求分析的方法

需求分析方法由對軟件問題的信息域和功能域的系統分析過程及其表示方法組成，大多數的需求分析方法是由信息驅動的。信息域具有三種屬性： 信息流、信息內容和信息結構。

常用的需求分析方法有：面向數據流的結構化分析方法（SA），面向數據結構的Jackson方法（JSD），面向數據結構的結構化數據系統開發方法（DSSD），面向對象的分析方法（OOA）等。選擇那種方法要根據哪些資源在什么時間對開發人員有效，不能盲目套用。這里著重闡述面向數據流的結構化分析方法（SA）。[2]

4.1 面向數據流的結構化分析方法

面向數據流的結構化分析方法（Structured Analysis，簡稱SA），是面向數據流進行需求分析的方法，是需求分析使用最多的方法之一。 SA也是一種建模活動，該方法使用簡單易讀符號，根據軟件內部數據傳遞、變換的關系，自頂向下逐層分解，描繪出滿足功能要求的軟件模型。適用于數據處理類型軟件的需求分析，這一方法除了簡單，容易掌握之外，還能和設計階段的結構化設計（SD）銜接，從而取得良好的設計結果。

4.2 自頂向下逐層分解的分析策略

SA方法的基本手段：“分解”和“抽象”。這是系統開發技術中控制復雜性的兩種手段。它先將系統“抽象”成一個模型，此模型是有輸入和輸出并有系統名稱的盒子，然后打開這個盒子，對它進行逐層分解，直到能被理解，可以實現為止。因此分析的策略是自頂向下，逐層加細，由抽象到具體的過程。如圖2。

4.3 結構化分析方法使用工具

SA方法利用圖形等半形式化的描述方式表達需求，簡明易懂，用它們形成需求規格說明書中的主要部分。描述工具是：

1) 數據流圖：描述系統由哪幾部分組成，各部分之間有什么聯系等等。

2) 數據字典：定義了數據流圖中每一個圖形元素。

3) 描述加工邏輯的結構化語言、判定表、判定樹：詳細描述數據流圖中不能被再分解的每一個加工。

由于分析中的主要依據是數據傳遞及數據變換所形成的數據流，所以結構化分析一般采用的方法是使用數據流圖的分析方法，最終結果是產生需求規格說明書，該文檔包括一套數據流圖，對數據流圖中的成分進行定義的一本數據字典及對加工邏輯的描述。

4.4 結構化分析步驟

用結構化分析方法進行系統需求分析的具體步驟是：

1) 了解當前系統的工作流程，獲得當前系統的物理模型。通過對當前系統的詳細調查，了解當前系統的工作過程，同時收集資料、文件、數據、報表等，將看到的、聽到的、收集到的信息和情況用圖形描述出來。也就是用一個模型來反映自己對當前系統的理解，如畫系統流程圖。

2) 抽象出當前系統的邏輯模型。物理模型反映了系統“怎么做”的具體實現，去掉物理模型中非本質的因素，抽取出本質的因素，構造出當前系統的邏輯模型，反映了當前系統“做什么”的功能。

3) 建立目標系統的邏輯模型。分析、比較目標系統與當前系統邏輯上的差別，明確目標系統到底要“做什么”，從而從當前系統的邏輯模型導出目標系統的邏輯模型。

4) 作進一步補充和優化。為了對目標系統做完整的描述，還需要對得到的邏輯模型做一些補充。

說明目標系統的人機界面。

說明至今尚未詳細考慮的細節（包括出錯處理、系統的啟動與結束、系統的輸入/輸出和系統性能方面的需求等）。

其他（系統特有的其他必須滿足的性能和限制，也需要用適當的形式做出書面記錄。

分析階段結束時，系統分析員必須和用戶再次認真地審查系統文件，爭取在系統開始設計之前，盡可能地發現其中存在的一些錯誤并及時糾正，直至用戶確認這個模型表達了他們的要求后，系統文件（軟件需求規格說明書等）才作為用戶和軟件開發人員之間的“合同”而最后得到確定。

4.5 結構化分析方法的優缺點

1) 優點： 結構化分析方法是軟件需求分析中公認的、有成效的、技術成熟的、使用廣泛的一種方法，它較適合于開發數據處理類型軟件的需求分析，該方法利用圖形等半形式化工具表達需求，簡明易讀，也易于使用，為后一階段的設計、測試、評價提供了有利條件。

2) 缺點：① 傳統的SA方法主要用于數據處理方面的問題，主要工具DFD體現了系統“做什么”的功能，但它僅是一個靜態模型，沒有反映處理的順序，即控制流程。因此，不適合描述實時控制系統。② 上世紀60年代末出現的數據庫技術，使許多大型數據處理系統中的數據都組織成數據庫的形式，SA方法使用DFD在分析與描述“數據要求”方面是有局限的，DFD應與數據庫技術中的實體聯系圖(ER圖)結合起來(如同IDEF0功能模型與IDEF1信息模型相結合一樣)。ER圖能增加對數據存儲的細節以及數據與數據之間，數據與處理過程之間關系的理解，還解決了在DD中所包含的數據內容表示問題，這樣才能較完整的描述用戶對系統的需求。③ 對于一些頻繁的人機交互的軟件系統，如飛機訂票、銀行管理等系統，用戶最關系的是如何使用它，輸入命令、操作方式、系統響應方式、輸出格式等都是用戶需求的重要方面，DFD不適合描述人機界面系統的需求，SA方法往往對這一部分用自然語言作補充。④ 描述軟件需求的精確性有待提高。

5 需求的變更

在開發項目過程中，用戶隨時會提出一些新的需求，要求開發方解決，這些需求的提出，有時在開發階段中有時在開發階段后。這種在需求分析的兩個相鄰子階段中，或者在迭代周期的需求分析中，后一段或周期的需求分析結果與前一次不一致，我們把這種不一致稱為需求變更。產生需求變更的原因主要有以下幾個方面：1) 在需求分析階段，開發方與用戶的溝通不夠。在需求分析階段，開發方與用戶沒有很好的交流，開發方就根據用戶提供的大概信息，自己推導出用戶的需求。通過這種需求分析得出的需求往往會和用戶的實際需求相差甚遠，導致用戶提出更改需求。2) 項目的實施周期過長。隨著時間的推移，用戶對整個系統的了解也越來越深入。他們會對模塊的界面、功能和性能方面提出更高更多的要求。3) 技術更新過快。由于技術的快速更新， 企業可能引進一些新的設備， 而這些設備可能就會與我們的目標系統有直接的關系， 由于這一變化可能發生在解決用戶原先問題之前或者之中，那么開發方不得不加入這一新的需求。[3]

為了盡可能地避免發生需求變更，以及保證需求分析的高穩定性，可以采用以下方法：1) 分工明確，系統分析員和程序員各有不同的職責。系統分析員處在用戶和程序員之間，溝通用戶和開發人員的認識和見解。系統分析員一方面要協助用戶對所開發的軟件提出需求，另一方面還要和程序員充分交換意見，探討其合理性和實現的可能性。如圖3所示，系統分析員在需求分析階段起著重要的作用。

2) 開發方與用戶進行協作和交流。在用戶提出需求變更時系統分析員應該認真聽取用戶的要求并加以整理和分析。分析需求變更的原因并提出可行的替代方案；同時向用戶說明這些需求變更會對整個項目的開發帶來的不良后果。3) 合同約束。由于需求變更可能會對整個項目產生影響，所以，開發方和用戶在簽定項目合同時，可以對需求變更增加一些相關的合同條款。4) 建立需求文檔并進行版本控制。需求分析的最終成果是一份客戶和開發方對所開發的產品達成共識的系統文檔。有了這份文檔， 即使開發方人員的角色有所變動，也不會對需求分析的前期工作有所影響。對每次的需求變更都用一個新的版本來標識。5) 需求評審和設立需求基線。為了讓開發方詳細了解用戶的需求，讓不同人員從不同的角度對需求進行驗證，作為需求的提出者（用戶方），在需求評審過程中，往往能提出許多有價值的意見，同時，也是對需求進行最后確認的機會，可以有效減少需求變更的發生。需求在通過正式評審和批準之后，應該確定需求基線，進一步的需求變更將在此基線的基礎上，依照項目定義的變更過程進行。設置需求基線可以將變更引起的麻煩減至最小。

6 應用實例

需求分析階段的主要成果體現在書寫一份高質量的軟件需求規格說明書，其中在規格說明書中書寫用例是最好的辦法。 下面舉一個例子來說明用例的寫法。 例如：使用安徽省計劃生育學校員工IC卡功能模塊。[4] 在此把軟件功能劃分成三個目標層次：概要目標層：使用 IC 卡；用戶目標層：發卡、卡充值、刷卡就餐、修改密碼、卡回收、余額轉賬、提取現金等；子功能層：刷卡就餐。

用例描述如下：

用例名稱：使用 IC 卡就餐。

使用背景：學校員工持個人 IC 卡去食堂就餐。

范圍：IC卡，系統。

層次：用戶目標。

使用者：持 IC卡的學校員工。

受益人及其利益：學校員工：買到飯菜；學校食堂：保證資金安全和系統安全。

前提條件：學校員工均有代表個人信息的IC卡。

最小保證：學校員工刷卡活動被記錄；就餐系統和數據保證完整性。

成功保證：學校員工取回IC卡，獲準領取指定的飯菜；賬戶數據被正確修改；系統記錄了刷卡詳細情況。

觸發事件：無。

基本流程：略。這是學校員工持卡來就餐的整個過程。要注意的是約束條件的體現，如輸入金額后首先判斷卡內余額是否足夠以扣款等等。

擴展流：對應基本流程的每個步驟里無法實現的時候的處理流程。

技術和數據變體：無。

擴展點：輸入就餐額。

非功能需求：食堂就餐讀卡機響應時間不超過10秒。

業務規則：單日消費不超過人民幣100元，每次消費不超過人民幣20元。

根據以上用例，很容易確定數據流和控制流，得到對應的數據流圖，進而得到程序流程圖也方便得多。很多功能及非功能的需求、業務規則等，就是實現這個系統時的約束條件，設計數據庫以及編制程序時必須考慮進去。同時，這個用例可以為測試階段測試用例的建立提供信息。測試人員只要根據此流程，編制相應的測試用例即可，能提高測試的效率，從而獲得更好的效果。

7 結束語

通過以上對軟件需求分析較為詳細的闡述，說明了需求分析在軟件開發過程中的重要性。為了使軟件開發工作能順利完成，必須重視需求分析工作，用先進的方法和科學的手段來保證此項工作的順利完成，為后續軟件開發奠定堅實的基礎。

參考文獻：

[1] 方圓.怎樣做需求分析[EB/OL].(2005-04-20).[2008-07-23].中國系統分析師，http://www.sachina.cn/index.php?type=columnarea=1p=articlesid=175.

[2] 周蘇，王文.軟件工程學教程[M].北京:科學出版社，2004:46-71.

[3] 朱寅非.淺析軟件開發項目中的需求分析[J].南京廣播電視大學學報，2006(4):84-86.

[4] 邵建偉.淺談軟件開發中的需求開發及其管理[J].計算機時代，2003(8):27-29.