1、姓名：李浩 學(xué)號：需求分析對軟件項目開發(fā)成敗影響探討摘要：需求分析是軟件工程過程中計劃階段的一個決定性步驟，在這一步將把含糊的軟件概念轉(zhuǎn)變成具體的規(guī)格說明，從而奠定了軟件開發(fā)的基礎(chǔ)。本文通過對需求的定義、需求的類型、需求分析的任務(wù)、需求分析的方法、需求的變更以及應(yīng)用實例等幾個方面的介紹，對于在軟件開發(fā)中做好需求分析有一定的借鑒作用。關(guān)鍵詞：軟件；開發(fā)；需求；分析1 引言軟件項目的開發(fā)主要分為五個階段：需求分析階段、設(shè)計階段、編碼階段、測試階段和維護(hù)階段，需求分析是軟件開發(fā)的第一個階段。完善的軟件需求說明是軟件開發(fā)項目得以成功的基礎(chǔ)。不管設(shè)計如何精心或者編碼如何巧妙，如果對軟件需求不加以明確規(guī)定

2、，將使用戶感到失望，并給軟件開發(fā)者帶來嚴(yán)重后果。據(jù)權(quán)威部門統(tǒng)計，目前軟件的成功率約為25%，75%的軟件是失敗的。在這75%的失敗中，約有50%以上的軟件是由于需求的原因造成的。另有資料表明，軟件開發(fā)項目中返工開銷幾乎占開發(fā)總費用的一半，而導(dǎo)致返工的主要原因是需求分析錯誤或不明確，從而引發(fā)項目開發(fā)中的一系列更改。成功的軟件需求分析不僅能提高軟件的成功率，而且能節(jié)省大量的資源，因此需求分析是軟件開發(fā)的關(guān)鍵階段。2 需求的定義和類型 2.1 需求的定義軟件產(chǎn)業(yè)存在的一個普遍問題就是缺乏統(tǒng)一定義的名詞術(shù)語來描述我們的工作?？蛻羲x的“需求”對開發(fā)者似乎是一個較高層次的產(chǎn)品概念，而開發(fā)人員所說的“需

3、求”對用戶來說又像是詳細(xì)設(shè)計了。實際上，軟件需求包含著多個層次，不同層次的需求從不同角度與不同程度反映著細(xì)節(jié)問題。IEEE軟件工程標(biāo)準(zhǔn)詞匯表（1997年）將需求定義為：1) 用戶解決問題或達(dá)到目標(biāo)所需的條件或能力。2) 系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力。 3) 一種反映上面1)或2)所描述的條件或能力的文檔說明。IEEE的定義包括從用戶角度（系統(tǒng)的外部行為），以及從開發(fā)者角度（一些內(nèi)部特性）來闡述需求，其關(guān)鍵的問題是一定要編寫需求文檔。另外，還有其他幾種關(guān)于“需求”的定義：需求是用戶所需要的并能觸發(fā)一個程序或系統(tǒng)開發(fā)工作的說明；需求是從系統(tǒng)外部能發(fā)現(xiàn)系

4、統(tǒng)所具有的滿足于用戶的特點、功能及屬性等；需求是指明必須實現(xiàn)什么的規(guī)格說明。它描述了系統(tǒng)的行為、特性或?qū)傩?，是在開發(fā)過程中對系統(tǒng)的約束。從以上的定義中，我們依然無法得到有關(guān)“需求”的清晰概念，真正的“需求”實際上存在人們的腦海中，任何文檔形式的需求（例如：需求規(guī)格說明）僅是一個模型或一種敘述，但是編寫出高質(zhì)量的需求規(guī)格說明書在需求分析階段還是關(guān)鍵。需求分析奠定了軟件工程和項目管理的基礎(chǔ)。我們在建造軟件系統(tǒng)這座大廈的時候，如果需求分析的基礎(chǔ)不夠堅實和牢固，那么往往會導(dǎo)致軟件系統(tǒng)問題百出，甚至被馬上丟棄。在建造軟件系統(tǒng)的過程中，如果我們經(jīng)常習(xí)慣地沿用一些不規(guī)范的方法，其后果便是產(chǎn)生一條鴻溝開發(fā)者開

5、發(fā)的與用戶所想得到的軟件存在著巨大的“期望差異”。 因此“需求”這個名詞的定義不僅僅是從用戶角度對系統(tǒng)外部行為的描述，以及從開發(fā)人員角度對系統(tǒng)內(nèi)部特性的描述，其關(guān)鍵的一點是“需求”必須文檔化。2.2 需求的類型軟件需求包括三個不同的層次業(yè)務(wù)需求、用戶需求和功能需求。除此之外，每個系統(tǒng)還有各種非功能需求。業(yè)務(wù)需求（BusinessRequirement）表示組織或客戶高層次的目標(biāo)。業(yè)務(wù)需求通常來自項目投資人、購買產(chǎn)品的客戶、實際用戶的管理者、市場營銷部門或產(chǎn)品策劃部門。業(yè)務(wù)需求描述了組織為什么要開發(fā)一個系統(tǒng)，即組織希望達(dá)到的目標(biāo)。使用前景和范圍（vision and scope）文檔來記錄業(yè)務(wù)需

6、求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔。用戶需求（UserRequirement）描述的是用戶的目標(biāo)，或用戶要求系統(tǒng)必須能完成的任務(wù)。用例、場景描述和事件響應(yīng)表都是表達(dá)用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統(tǒng)來做些什么。功能需求（Functional Requirement）規(guī)定開發(fā)人員必須在產(chǎn)品中實現(xiàn)的軟件功能，用戶利用這些功能來完成任務(wù)，滿足業(yè)務(wù)需求。功能需求有時也被稱作行為需求（behavioral requirement），因為習(xí)慣上總是用“應(yīng)該”對其進(jìn)行描述：“系統(tǒng)應(yīng)該發(fā)送電子郵件來

7、通知用戶已接受其預(yù)定”。功能需求描述是開發(fā)人員需要實現(xiàn)什么。非功能需求（Non-functional Requirement） 定義了軟件產(chǎn)品為滿足用戶業(yè)務(wù)需求而必須具有的除功能需求以外的特性。包括系統(tǒng)的完整性（聯(lián)機(jī)幫助、 數(shù)據(jù)管理、用戶管理、軟件發(fā)布管理、在線升級等）、性能、可靠性、可維護(hù)性、可擴(kuò)充性、對技術(shù)和業(yè)務(wù)的適應(yīng)性等。3 需求分析的任務(wù) 3.1 解決的問題1) 齊全、準(zhǔn)確地找出目標(biāo)系統(tǒng)全部的功能、性能、限制；2) 找出全部的輸入流、輸出流；3) 找出所有的加工；4) 產(chǎn)生完整的分層的DFD、數(shù)據(jù)字典、加工的描述；5) 補(bǔ)充的意見。3.2 綜合要求確定對系統(tǒng)的綜合要求，系統(tǒng)功能要求，系

8、統(tǒng)性能要求，運行要求，將來可能提出的要求。3.3 任務(wù) 需求分析任務(wù)圖，需求分析階段要完成的具體明確的最終任務(wù)就是形成一份經(jīng)開發(fā)方和用戶認(rèn)可或達(dá)成共識的軟件需求分析文檔（需求規(guī)格說明書、修改后的項目開發(fā)計劃、初步的用戶手冊、確認(rèn)測試計劃、數(shù)據(jù)要求說明書）。這個文檔能清晰準(zhǔn)確地說明系統(tǒng)將要開發(fā)什么，能夠規(guī)定出詳細(xì)的技術(shù)需求，包括所有面向用戶、面向機(jī)器和其它軟件系統(tǒng)的接口?？梢哉f需求文檔在開發(fā)過程中一直起指導(dǎo)作用。為了更好地完成軟件開發(fā)第一階段的需求分析任務(wù)，提高質(zhì)量，需求管理是必不可少的。需求管理的目的是在客戶與開發(fā)方之間建立對需求的共同理解，維護(hù)需求與其他工作成果的一致性，并控制需求的變更，主

9、要體現(xiàn)在跟蹤和控制需求變更管理。需求管理是開發(fā)工作有效進(jìn)行的保證，是一種很高層次的系統(tǒng)行為，涉及整個開發(fā)過程和產(chǎn)品本身。4 需求分析的方法需求分析方法由對軟件問題的信息域和功能域的系統(tǒng)分析過程及其表示方法組成，大多數(shù)的需求分析方法是由信息驅(qū)動的。信息域具有三種屬性： 信息流、信息內(nèi)容和信息結(jié)構(gòu)。常用的需求分析方法有：面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（SA），面向數(shù)據(jù)結(jié)構(gòu)的Jackson方法（JSD），面向數(shù)據(jù)結(jié)構(gòu)的結(jié)構(gòu)化數(shù)據(jù)系統(tǒng)開發(fā)方法（DSSD），面向?qū)ο蟮姆治龇椒ǎ∣OA）等。選擇那種方法要根據(jù)哪些資源在什么時間對開發(fā)人員有效，不能盲目套用。這里著重闡述面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（SA）。2 4

10、.1 面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法 面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（Structured Analysis，簡稱SA），是面向數(shù)據(jù)流進(jìn)行需求分析的方法，是需求分析使用最多的方法之一。 SA也是一種建模活動，該方法使用簡單易讀符號，根據(jù)軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系，自頂向下逐層分解，描繪出滿足功能要求的軟件模型。適用于數(shù)據(jù)處理類型軟件的需求分析，這一方法除了簡單，容易掌握之外，還能和設(shè)計階段的結(jié)構(gòu)化設(shè)計（SD）銜接，從而取得良好的設(shè)計結(jié)果。4.2 自頂向下逐層分解的分析策略 SA方法的基本手段：“分解”和“抽象”。這是系統(tǒng)開發(fā)技術(shù)中控制復(fù)雜性的兩種手段。它先將系統(tǒng)“抽象”成一個模型，此模型是有輸入和輸

11、出并有系統(tǒng)名稱的盒子，然后打開這個盒子，對它進(jìn)行逐層分解，直到能被理解，可以實現(xiàn)為止。因此分析的策略是自頂向下，逐層加細(xì)，由抽象到具體的過程。如圖2。4.3 結(jié)構(gòu)化分析方法使用工具 SA方法利用圖形等半形式化的描述方式表達(dá)需求，簡明易懂，用它們形成需求規(guī)格說明書中的主要部分。描述工具是1) 數(shù)據(jù)流圖：描述系統(tǒng)由哪幾部分組成，各部分之間有什么聯(lián)系等等。2) 數(shù)據(jù)字典：定義了數(shù)據(jù)流圖中每一個圖形元素。3) 描述加工邏輯的結(jié)構(gòu)化語言、判定表、判定樹：詳細(xì)描述數(shù)據(jù)流圖中不能被再分解的每一個加工。由于分析中的主要依據(jù)是數(shù)據(jù)傳遞及數(shù)據(jù)變換所形成的數(shù)據(jù)流，所以結(jié)構(gòu)化分析一般采用的方法是使用數(shù)據(jù)流圖的分析方法

12、，最終結(jié)果是產(chǎn)生需求規(guī)格說明書，該文檔包括一套數(shù)據(jù)流圖，對數(shù)據(jù)流圖中的成分進(jìn)行定義的一本數(shù)據(jù)字典及對加工邏輯的描述。4.4 結(jié)構(gòu)化分析步驟 用結(jié)構(gòu)化分析方法進(jìn)行系統(tǒng)需求分析的具體步驟是： 1) 了解當(dāng)前系統(tǒng)的工作流程，獲得當(dāng)前系統(tǒng)的物理模型。通過對當(dāng)前系統(tǒng)的詳細(xì)調(diào)查，了解當(dāng)前系統(tǒng)的工作過程，同時收集資料、文件、數(shù)據(jù)、報表等，將看到的、聽到的、收集到的信息和情況用圖形描述出來。也就是用一個模型來反映自己對當(dāng)前系統(tǒng)的理解，如畫系統(tǒng)流程圖。 2) 抽象出當(dāng)前系統(tǒng)的邏輯模型。物理模型反映了系統(tǒng)“怎么做”的具體實現(xiàn)，去掉物理模型中非本質(zhì)的因素，抽取出本質(zhì)的因素，構(gòu)造出當(dāng)前系統(tǒng)的邏輯模型，反映了當(dāng)前系統(tǒng)“

13、做什么”的功能。 3) 建立目標(biāo)系統(tǒng)的邏輯模型。分析、比較目標(biāo)系統(tǒng)與當(dāng)前系統(tǒng)邏輯上的差別，明確目標(biāo)系統(tǒng)到底要“做什么”，從而從當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型。 4) 作進(jìn)一步補(bǔ)充和優(yōu)化。為了對目標(biāo)系統(tǒng)做完整的描述，還需要對得到的邏輯模型做一些補(bǔ)充。 說明目標(biāo)系統(tǒng)的人機(jī)界面。 說明至今尚未詳細(xì)考慮的細(xì)節(jié)（包括出錯處理、系統(tǒng)的啟動與結(jié)束、系統(tǒng)的輸入/輸出和系統(tǒng)性能方面的需求等）。 其他（系統(tǒng)特有的其他必須滿足的性能和限制，也需要用適當(dāng)?shù)男问阶龀鰰嬗涗洝?分析階段結(jié)束時，系統(tǒng)分析員必須和用戶再次認(rèn)真地審查系統(tǒng)文件，爭取在系統(tǒng)開始設(shè)計之前，盡可能地發(fā)現(xiàn)其中存在的一些錯誤并及時糾正，直至用戶

14、確認(rèn)這個模型表達(dá)了他們的要求后，系統(tǒng)文件（軟件需求規(guī)格說明書等）才作為用戶和軟件開發(fā)人員之間的“合同”而最后得到確定。 4.5 結(jié)構(gòu)化分析方法的優(yōu)缺點 1) 優(yōu)點： 結(jié)構(gòu)化分析方法是軟件需求分析中公認(rèn)的、有成效的、技術(shù)成熟的、使用廣泛的一種方法，它較適合于開發(fā)數(shù)據(jù)處理類型軟件的需求分析，該方法利用圖形等半形式化工具表達(dá)需求，簡明易讀，也易于使用，為后一階段的設(shè)計、測試、評價提供了有利條件。 2) 缺點： 傳統(tǒng)的SA方法主要用于數(shù)據(jù)處理方面的問題，主要工具DFD體現(xiàn)了系統(tǒng)“做什么”的功能，但它僅是一個靜態(tài)模型，沒有反映處理的順序，即控制流程。因此，不適合描述實時控制系統(tǒng)。 上世紀(jì)60年代末出現(xiàn)的

15、數(shù)據(jù)庫技術(shù)，使許多大型數(shù)據(jù)處理系統(tǒng)中的數(shù)據(jù)都組織成數(shù)據(jù)庫的形式，SA方法使用DFD在分析與描述“數(shù)據(jù)要求”方面是有局限的，DFD應(yīng)與數(shù)據(jù)庫技術(shù)中的實體聯(lián)系圖(ER圖)結(jié)合起來(如同IDEF0功能模型與IDEF1信息模型相結(jié)合一樣)。ER圖能增加對數(shù)據(jù)存儲的細(xì)節(jié)以及數(shù)據(jù)與數(shù)據(jù)之間，數(shù)據(jù)與處理過程之間關(guān)系的理解，還解決了在DD中所包含的數(shù)據(jù)內(nèi)容表示問題，這樣才能較完整的描述用戶對系統(tǒng)的需求。 對于一些頻繁的人機(jī)交互的軟件系統(tǒng)，如飛機(jī)訂票、銀行管理等系統(tǒng)，用戶最關(guān)系的是如何使用它，輸入命令、操作方式、系統(tǒng)響應(yīng)方式、輸出格式等都是用戶需求的重要方面，DFD不適合描述人機(jī)界面系統(tǒng)的需求，SA方法往往對這

16、一部分用自然語言作補(bǔ)充。 描述軟件需求的精確性有待提高。5 需求的變更 在開發(fā)項目過程中，用戶隨時會提出一些新的需求，要求開發(fā)方解決，這些需求的提出，有時在開發(fā)階段中有時在開發(fā)階段后。這種在需求分析的兩個相鄰子階段中，或者在迭代周期的需求分析中，后一段或周期的需求分析結(jié)果與前一次不一致，我們把這種不一致稱為需求變更。產(chǎn)生需求變更的原因主要有以下幾個方面：1) 在需求分析階段，開發(fā)方與用戶的溝通不夠。在需求分析階段，開發(fā)方與用戶沒有很好的交流，開發(fā)方就根據(jù)用戶提供的大概信息，自己推導(dǎo)出用戶的需求。通過這種需求分析得出的需求往往會和用戶的實際需求相差甚遠(yuǎn)，導(dǎo)致用戶提出更改需求。2) 項目的實施周期

17、過長。隨著時間的推移，用戶對整個系統(tǒng)的了解也越來越深入。他們會對模塊的界面、功能和性能方面提出更高更多的要求。3) 技術(shù)更新過快。由于技術(shù)的快速更新， 企業(yè)可能引進(jìn)一些新的設(shè)備， 而這些設(shè)備可能就會與我們的目標(biāo)系統(tǒng)有直接的關(guān)系， 由于這一變化可能發(fā)生在解決用戶原先問題之前或者之中，那么開發(fā)方不得不加入這一新的需求。3 為了盡可能地避免發(fā)生需求變更，以及保證需求分析的高穩(wěn)定性，可以采用以下方法：1) 分工明確，系統(tǒng)分析員和程序員各有不同的職責(zé)。系統(tǒng)分析員處在用戶和程序員之間，溝通用戶和開發(fā)人員的認(rèn)識和見解。系統(tǒng)分析員一方面要協(xié)助用戶對所開發(fā)的軟件提出需求，另一方面還要和程序員充分交換意見，探討其

18、合理性和實現(xiàn)的可能性。如圖3所示，系統(tǒng)分析員在需求分析階段起著重要的作用。 2) 開發(fā)方與用戶進(jìn)行協(xié)作和交流。在用戶提出需求變更時系統(tǒng)分析員應(yīng)該認(rèn)真聽取用戶的要求并加以整理和分析。分析需求變更的原因并提出可行的替代方案；同時向用戶說明這些需求變更會對整個項目的開發(fā)帶來的不良后果。3) 合同約束。由于需求變更可能會對整個項目產(chǎn)生影響，所以，開發(fā)方和用戶在簽定項目合同時，可以對需求變更增加一些相關(guān)的合同條款。4) 建立需求文檔并進(jìn)行版本控制。需求分析的最終成果是一份客戶和開發(fā)方對所開發(fā)的產(chǎn)品達(dá)成共識的系統(tǒng)文檔。有了這份文檔， 即使開發(fā)方人員的角色有所變動，也不會對需求分析的前期工作有所影響。對每次

19、的需求變更都用一個新的版本來標(biāo)識。5) 需求評審和設(shè)立需求基線。為了讓開發(fā)方詳細(xì)了解用戶的需求，讓不同人員從不同的角度對需求進(jìn)行驗證，作為需求的提出者（用戶方），在需求評審過程中，往往能提出許多有價值的意見，同時，也是對需求進(jìn)行最后確認(rèn)的機(jī)會，可以有效減少需求變更的發(fā)生。需求在通過正式評審和批準(zhǔn)之后，應(yīng)該確定需求基線，進(jìn)一步的需求變更將在此基線的基礎(chǔ)上，依照項目定義的變更過程進(jìn)行。設(shè)置需求基線可以將變更引起的麻煩減至最小。 6 應(yīng)用實例 需求分析階段的主要成果體現(xiàn)在書寫一份高質(zhì)量的軟件需求規(guī)格說明書，其中在規(guī)格說明書中書寫用例是最好的辦法。 下面舉一個例子來說明用例的寫法。 例如：使用學(xué)校員工

20、IC卡功能模塊。4 在此把軟件功能劃分成三個目標(biāo)層次：概要目標(biāo)層：使用 IC 卡；用戶目標(biāo)層：發(fā)卡、卡充值、刷卡就餐、修改密碼、卡回收、余額轉(zhuǎn)賬、提取現(xiàn)金等；子功能層：刷卡就餐。 用例描述如下： 用例名稱：使用 IC 卡就餐。 使用背景：學(xué)校員工持個人 IC 卡去食堂就餐。 范圍：IC卡，系統(tǒng)。 層次：用戶目標(biāo)。 使用者：持 IC卡的學(xué)校員工。 受益人及其利益：學(xué)校員工：買到飯菜；學(xué)校食堂：保證資金安全和系統(tǒng)安全。 前提條件：學(xué)校員工均有代表個人信息的IC卡。 最小保證：學(xué)校員工刷卡活動被記錄；就餐系統(tǒng)和數(shù)據(jù)保證完整性。 成功保證：學(xué)校員工取回IC卡，獲準(zhǔn)領(lǐng)取指定的飯菜；賬戶數(shù)據(jù)被正確修改；系統(tǒng)記錄了刷卡詳細(xì)情況。 觸發(fā)事件：無。基本流程：略。這是學(xué)校員工持卡來就餐的整個過程。要