軟件開(kāi)發(fā)過(guò)程中的需求分析探討

摘要：軟件需求分析是軟件工程過(guò)程中計(jì)劃階段的一個(gè)決定性步驟，在這一步將把含糊的軟件概念轉(zhuǎn)變成具體的規(guī)格說(shuō)明，從而奠定了軟件開(kāi)發(fā)的基礎(chǔ)。本文通過(guò)對(duì)需求的定義、需求的類(lèi)型、需求分析的任務(wù)、需求分析的方法、需求的變更以及應(yīng)用實(shí)例等幾個(gè)方面的介紹，對(duì)于在軟件開(kāi)發(fā)中做好需求分析有一定的借鑒作用。

關(guān)鍵詞：軟件；開(kāi)發(fā)；需求；分析

中圖分類(lèi)號(hào)：TP311文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：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 引言

軟件項(xiàng)目的開(kāi)發(fā)主要分為五個(gè)階段：需求分析階段、設(shè)計(jì)階段、編碼階段、測(cè)試階段和維護(hù)階段，需求調(diào)研和分析是軟件開(kāi)發(fā)的第一個(gè)階段。完善的軟件需求說(shuō)明是軟件開(kāi)發(fā)項(xiàng)目得以成功的基礎(chǔ)。不管設(shè)計(jì)如何精心或者編碼如何巧妙，如果對(duì)軟件需求不加以明確規(guī)定，將使用戶(hù)感到失望，并給軟件開(kāi)發(fā)者帶來(lái)嚴(yán)重后果。據(jù)權(quán)威部門(mén)統(tǒng)計(jì)，目前軟件的成功率約為25%，75%的軟件是失敗的。在這75%的失敗中，約有50%以上的軟件是由于需求的原因造成的。另有資料表明，軟件開(kāi)發(fā)項(xiàng)目中返工開(kāi)銷(xiāo)幾乎占開(kāi)發(fā)總費(fèi)用的一半，而導(dǎo)致返工的主要原因是需求分析錯(cuò)誤或不明確，從而引發(fā)項(xiàng)目開(kāi)發(fā)中的一系列更改。成功的軟件需求分析不僅能提高軟件的成功率，而且能節(jié)省大量的資源，因此需求分析是軟件開(kāi)發(fā)的關(guān)鍵階段。[1]

2 需求的定義和類(lèi)型

2.1 需求的定義

軟件產(chǎn)業(yè)存在的一個(gè)普遍問(wèn)題就是缺乏統(tǒng)一定義的名詞術(shù)語(yǔ)來(lái)描述我們的工作。客戶(hù)所定義的“需求”對(duì)開(kāi)發(fā)者似乎是一個(gè)較高層次的產(chǎn)品概念，而開(kāi)發(fā)人員所說(shuō)的“需求”對(duì)用戶(hù)來(lái)說(shuō)又像是詳細(xì)設(shè)計(jì)了。實(shí)際上，軟件需求包含著多個(gè)層次，不同層次的需求從不同角度與不同程度反映著細(xì)節(jié)問(wèn)題。

IEEE軟件工程標(biāo)準(zhǔn)詞匯表（1997年）將需求定義為：

1) 用戶(hù)解決問(wèn)題或達(dá)到目標(biāo)所需的條件或能力。

2) 系統(tǒng)或系統(tǒng)部件要滿(mǎn)足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力。

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

IEEE的定義包括從用戶(hù)角度（系統(tǒng)的外部行為），以及從開(kāi)發(fā)者角度（一些內(nèi)部特性）來(lái)闡述需求，其關(guān)鍵的問(wèn)題是一定要編寫(xiě)需求文檔。

另外，還有其他幾種關(guān)于“需求”的定義：

需求是用戶(hù)所需要的并能觸發(fā)一個(gè)程序或系統(tǒng)開(kāi)發(fā)工作的說(shuō)明；

需求是從系統(tǒng)外部能發(fā)現(xiàn)系統(tǒng)所具有的滿(mǎn)足于用戶(hù)的特點(diǎn)、功能及屬性等；

需求是指明必須實(shí)現(xiàn)什么的規(guī)格說(shuō)明。它描述了系統(tǒng)的行為、特性或?qū)傩裕窃陂_(kāi)發(fā)過(guò)程中對(duì)系統(tǒng)的約束。

從以上的定義中，我們依然無(wú)法得到有關(guān)“需求”的清晰概念，真正的“需求”實(shí)際上存在人們的腦海中，任何文檔形式的需求（例如：需求規(guī)格說(shuō)明）僅是一個(gè)模型或一種敘述，但是編寫(xiě)出高質(zhì)量的需求規(guī)格說(shuō)明書(shū)在需求分析階段還是關(guān)鍵。

需求分析奠定了軟件工程和項(xiàng)目管理的基礎(chǔ)。我們?cè)诮ㄔ燔浖到y(tǒng)這座大廈的時(shí)候，如果需求分析的基礎(chǔ)不夠堅(jiān)實(shí)和牢固，那么往往會(huì)導(dǎo)致軟件系統(tǒng)問(wèn)題百出，甚至被馬上丟棄。在建造軟件系統(tǒng)的過(guò)程中，如果我們經(jīng)常習(xí)慣地沿用一些不規(guī)范的方法，其后果便是產(chǎn)生一條鴻溝──開(kāi)發(fā)者開(kāi)發(fā)的與用戶(hù)所想得到的軟件存在著巨大的“期望差異”。 因此“需求”這個(gè)名詞的定義不僅僅是從用戶(hù)角度對(duì)系統(tǒng)外部行為的描述，以及從開(kāi)發(fā)人員角度對(duì)系統(tǒng)內(nèi)部特性的描述，其關(guān)鍵的一點(diǎn)是“需求”必須文檔化。

2.2 需求的類(lèi)型

軟件需求包括三個(gè)不同的層次──業(yè)務(wù)需求、用戶(hù)需求和功能需求。

除此之外，每個(gè)系統(tǒng)還有各種非功能需求。

業(yè)務(wù)需求（BusinessRequirement）表示組織或客戶(hù)高層次的目標(biāo)。業(yè)務(wù)需求通常來(lái)自項(xiàng)目投資人、購(gòu)買(mǎi)產(chǎn)品的客戶(hù)、實(shí)際用戶(hù)的管理者、市場(chǎng)營(yíng)銷(xiāo)部門(mén)或產(chǎn)品策劃部門(mén)。業(yè)務(wù)需求描述了組織為什么要開(kāi)發(fā)一個(gè)系統(tǒng)，即組織希望達(dá)到的目標(biāo)。使用前景和范圍（vision and scope）文檔來(lái)記錄業(yè)務(wù)需求，這份文檔有時(shí)也被稱(chēng)作項(xiàng)目輪廓圖或市場(chǎng)需求（project charter 或 market requirement）文檔。

用戶(hù)需求（UserRequirement）描述的是用戶(hù)的目標(biāo)，或用戶(hù)要求系統(tǒng)必須能完成的任務(wù)。用例、場(chǎng)景描述和事件響應(yīng)表都是表達(dá)用戶(hù)需求的有效途徑。也就是說(shuō)用戶(hù)需求描述了用戶(hù)能使用系統(tǒng)來(lái)做些什么。

功能需求（Functional Requirement）規(guī)定開(kāi)發(fā)人員必須在產(chǎn)品中實(shí)現(xiàn)的軟件功能，用戶(hù)利用這些功能來(lái)完成任務(wù)，滿(mǎn)足業(yè)務(wù)需求。功能需求有時(shí)也被稱(chēng)作行為需求（behavioral requirement），因?yàn)榱?xí)慣上總是用“應(yīng)該”對(duì)其進(jìn)行描述：“系統(tǒng)應(yīng)該發(fā)送電子郵件來(lái)通知用戶(hù)已接受其預(yù)定”。功能需求描述是開(kāi)發(fā)人員需要實(shí)現(xiàn)什么。

非功能需求（Non-functional Requirement） 定義了軟件產(chǎn)品為滿(mǎn)足用戶(hù)業(yè)務(wù)需求而必須具有的除功能需求以外的特性。包括系統(tǒng)的完整性（聯(lián)機(jī)幫助、 數(shù)據(jù)管理、用戶(hù)管理、軟件發(fā)布管理、在線(xiàn)升級(jí)等）、性能、可靠性、可維護(hù)性、可擴(kuò)充性、對(duì)技術(shù)和業(yè)務(wù)的適應(yīng)性等。

3 需求分析的任務(wù)

3.1 解決的問(wèn)題

1) 齊全、準(zhǔn)確地找出目標(biāo)系統(tǒng)全部的功能、性能、限制；

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

3) 找出所有的加工；

4) 產(chǎn)生完整的分層的DFD、數(shù)據(jù)字典、加工的描述；

5) 補(bǔ)充的意見(jiàn)。

3.2 綜合要求

確定對(duì)系統(tǒng)的綜合要求，系統(tǒng)功能要求，系統(tǒng)性能要求，運(yùn)行要求，將來(lái)可能提出的要求。

3.3 任務(wù)

圖1為需求分析任務(wù)圖，需求分析階段要完成的具體明確的最終任務(wù)就是形成一份經(jīng)開(kāi)發(fā)方和用戶(hù)認(rèn)可或達(dá)成共識(shí)的軟件需求分析文檔（需求規(guī)格說(shuō)明書(shū)、修改后的項(xiàng)目開(kāi)發(fā)計(jì)劃、初步的用戶(hù)手冊(cè)、確認(rèn)測(cè)試計(jì)劃、數(shù)據(jù)要求說(shuō)明書(shū)）。這個(gè)文檔能清晰準(zhǔn)確地說(shuō)明系統(tǒng)將要開(kāi)發(fā)什么，能夠規(guī)定出詳細(xì)的技術(shù)需求，包括所有面向用戶(hù)、面向機(jī)器和其它軟件系統(tǒng)的接口。可以說(shuō)需求文檔在開(kāi)發(fā)過(guò)程中一直起指導(dǎo)作用。

為了更好地完成軟件開(kāi)發(fā)第一階段的需求分析任務(wù)，提高質(zhì)量，需求管理是必不可少的。

需求管理的目的是在客戶(hù)與開(kāi)發(fā)方之間建立對(duì)需求的共同理解，維護(hù)需求與其他工作成果的一致性，并控制需求的變更，主要體現(xiàn)在跟蹤和控制需求變更管理。需求管理是開(kāi)發(fā)工作有效進(jìn)行的保證，是一種很高層次的系統(tǒng)行為，涉及整個(gè)開(kāi)發(fā)過(guò)程和產(chǎn)品本身。

4 需求分析的方法

需求分析方法由對(duì)軟件問(wèn)題的信息域和功能域的系統(tǒng)分析過(guò)程及其表示方法組成，大多數(shù)的需求分析方法是由信息驅(qū)動(dòng)的。信息域具有三種屬性： 信息流、信息內(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)開(kāi)發(fā)方法（DSSD），面向?qū)ο蟮姆治龇椒ǎ∣OA）等。選擇那種方法要根據(jù)哪些資源在什么時(shí)間對(duì)開(kāi)發(fā)人員有效，不能盲目套用。這里著重闡述面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（SA）。[2]

4.1 面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法

面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（Structured Analysis，簡(jiǎn)稱(chēng)SA），是面向數(shù)據(jù)流進(jìn)行需求分析的方法，是需求分析使用最多的方法之一。 SA也是一種建模活動(dòng)，該方法使用簡(jiǎn)單易讀符號(hào)，根據(jù)軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系，自頂向下逐層分解，描繪出滿(mǎn)足功能要求的軟件模型。適用于數(shù)據(jù)處理類(lèi)型軟件的需求分析，這一方法除了簡(jiǎn)單，容易掌握之外，還能和設(shè)計(jì)階段的結(jié)構(gòu)化設(shè)計(jì)（SD）銜接，從而取得良好的設(shè)計(jì)結(jié)果。

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

SA方法的基本手段：“分解”和“抽象”。這是系統(tǒng)開(kāi)發(fā)技術(shù)中控制復(fù)雜性的兩種手段。它先將系統(tǒng)“抽象”成一個(gè)模型，此模型是有輸入和輸出并有系統(tǒng)名稱(chēng)的盒子，然后打開(kāi)這個(gè)盒子，對(duì)它進(jìn)行逐層分解，直到能被理解，可以實(shí)現(xiàn)為止。因此分析的策略是自頂向下，逐層加細(xì)，由抽象到具體的過(guò)程。如圖2。

4.3 結(jié)構(gòu)化分析方法使用工具

SA方法利用圖形等半形式化的描述方式表達(dá)需求，簡(jiǎn)明易懂，用它們形成需求規(guī)格說(shuō)明書(shū)中的主要部分。描述工具是：

1) 數(shù)據(jù)流圖：描述系統(tǒng)由哪幾部分組成，各部分之間有什么聯(lián)系等等。

2) 數(shù)據(jù)字典：定義了數(shù)據(jù)流圖中每一個(gè)圖形元素。

3) 描述加工邏輯的結(jié)構(gòu)化語(yǔ)言、判定表、判定樹(shù)：詳細(xì)描述數(shù)據(jù)流圖中不能被再分解的每一個(gè)加工。

由于分析中的主要依據(jù)是數(shù)據(jù)傳遞及數(shù)據(jù)變換所形成的數(shù)據(jù)流，所以結(jié)構(gòu)化分析一般采用的方法是使用數(shù)據(jù)流圖的分析方法，最終結(jié)果是產(chǎn)生需求規(guī)格說(shuō)明書(shū)，該文檔包括一套數(shù)據(jù)流圖，對(duì)數(shù)據(jù)流圖中的成分進(jìn)行定義的一本數(shù)據(jù)字典及對(duì)加工邏輯的描述。

4.4 結(jié)構(gòu)化分析步驟

用結(jié)構(gòu)化分析方法進(jìn)行系統(tǒng)需求分析的具體步驟是：

1) 了解當(dāng)前系統(tǒng)的工作流程，獲得當(dāng)前系統(tǒng)的物理模型。通過(guò)對(duì)當(dāng)前系統(tǒng)的詳細(xì)調(diào)查，了解當(dāng)前系統(tǒng)的工作過(guò)程，同時(shí)收集資料、文件、數(shù)據(jù)、報(bào)表等，將看到的、聽(tīng)到的、收集到的信息和情況用圖形描述出來(lái)。也就是用一個(gè)模型來(lái)反映自己對(duì)當(dāng)前系統(tǒng)的理解，如畫(huà)系統(tǒng)流程圖。

2) 抽象出當(dāng)前系統(tǒng)的邏輯模型。物理模型反映了系統(tǒng)“怎么做”的具體實(shí)現(xiàn)，去掉物理模型中非本質(zhì)的因素，抽取出本質(zhì)的因素，構(gòu)造出當(dāng)前系統(tǒng)的邏輯模型，反映了當(dāng)前系統(tǒng)“做什么”的功能。

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)化。為了對(duì)目標(biāo)系統(tǒng)做完整的描述，還需要對(duì)得到的邏輯模型做一些補(bǔ)充。

說(shuō)明目標(biāo)系統(tǒng)的人機(jī)界面。

說(shuō)明至今尚未詳細(xì)考慮的細(xì)節(jié)（包括出錯(cuò)處理、系統(tǒng)的啟動(dòng)與結(jié)束、系統(tǒng)的輸入/輸出和系統(tǒng)性能方面的需求等）。

其他（系統(tǒng)特有的其他必須滿(mǎn)足的性能和限制，也需要用適當(dāng)?shù)男问阶龀鰰?shū)面記錄。

分析階段結(jié)束時(shí)，系統(tǒng)分析員必須和用戶(hù)再次認(rèn)真地審查系統(tǒng)文件，爭(zhēng)取在系統(tǒng)開(kāi)始設(shè)計(jì)之前，盡可能地發(fā)現(xiàn)其中存在的一些錯(cuò)誤并及時(shí)糾正，直至用戶(hù)確認(rèn)這個(gè)模型表達(dá)了他們的要求后，系統(tǒng)文件（軟件需求規(guī)格說(shuō)明書(shū)等）才作為用戶(hù)和軟件開(kāi)發(fā)人員之間的“合同”而最后得到確定。

4.5 結(jié)構(gòu)化分析方法的優(yōu)缺點(diǎn)

1) 優(yōu)點(diǎn)： 結(jié)構(gòu)化分析方法是軟件需求分析中公認(rèn)的、有成效的、技術(shù)成熟的、使用廣泛的一種方法，它較適合于開(kāi)發(fā)數(shù)據(jù)處理類(lèi)型軟件的需求分析，該方法利用圖形等半形式化工具表達(dá)需求，簡(jiǎn)明易讀，也易于使用，為后一階段的設(shè)計(jì)、測(cè)試、評(píng)價(jià)提供了有利條件。

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

5 需求的變更

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

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

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

6 應(yīng)用實(shí)例

需求分析階段的主要成果體現(xiàn)在書(shū)寫(xiě)一份高質(zhì)量的軟件需求規(guī)格說(shuō)明書(shū)，其中在規(guī)格說(shuō)明書(shū)中書(shū)寫(xiě)用例是最好的辦法。 下面舉一個(gè)例子來(lái)說(shuō)明用例的寫(xiě)法。 例如：使用安徽省計(jì)劃生育學(xué)校員工IC卡功能模塊。[4] 在此把軟件功能劃分成三個(gè)目標(biāo)層次：概要目標(biāo)層：使用 IC 卡；用戶(hù)目標(biāo)層：發(fā)卡、卡充值、刷卡就餐、修改密碼、卡回收、余額轉(zhuǎn)賬、提取現(xiàn)金等；子功能層：刷卡就餐。

用例描述如下：

用例名稱(chēng)：使用 IC 卡就餐。

使用背景：學(xué)校員工持個(gè)人 IC 卡去食堂就餐。

范圍：IC卡，系統(tǒng)。

層次：用戶(hù)目標(biāo)。

使用者：持 IC卡的學(xué)校員工。

受益人及其利益：學(xué)校員工：買(mǎi)到飯菜；學(xué)校食堂：保證資金安全和系統(tǒng)安全。

前提條件：學(xué)校員工均有代表個(gè)人信息的IC卡。

最小保證：學(xué)校員工刷卡活動(dòng)被記錄；就餐系統(tǒng)和數(shù)據(jù)保證完整性。

成功保證：學(xué)校員工取回IC卡，獲準(zhǔn)領(lǐng)取指定的飯菜；賬戶(hù)數(shù)據(jù)被正確修改；系統(tǒng)記錄了刷卡詳細(xì)情況。

觸發(fā)事件：無(wú)。

基本流程：略。這是學(xué)校員工持卡來(lái)就餐的整個(gè)過(guò)程。要注意的是約束條件的體現(xiàn)，如輸入金額后首先判斷卡內(nèi)余額是否足夠以扣款等等。

擴(kuò)展流：對(duì)應(yīng)基本流程的每個(gè)步驟里無(wú)法實(shí)現(xiàn)的時(shí)候的處理流程。

技術(shù)和數(shù)據(jù)變體：無(wú)。

擴(kuò)展點(diǎn)：輸入就餐額。

非功能需求：食堂就餐讀卡機(jī)響應(yīng)時(shí)間不超過(guò)10秒。

業(yè)務(wù)規(guī)則：?jiǎn)稳障M(fèi)不超過(guò)人民幣100元，每次消費(fèi)不超過(guò)人民幣20元。

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

7 結(jié)束語(yǔ)

通過(guò)以上對(duì)軟件需求分析較為詳細(xì)的闡述，說(shuō)明了需求分析在軟件開(kāi)發(fā)過(guò)程中的重要性。為了使軟件開(kāi)發(fā)工作能順利完成，必須重視需求分析工作，用先進(jìn)的方法和科學(xué)的手段來(lái)保證此項(xiàng)工作的順利完成，為后續(xù)軟件開(kāi)發(fā)奠定堅(jiān)實(shí)的基礎(chǔ)。

參考文獻(xiàn)：

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

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

[3] 朱寅非.淺析軟件開(kāi)發(fā)項(xiàng)目中的需求分析[J].南京廣播電視大學(xué)學(xué)報(bào)，2006(4):84-86.

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