最新需求分析論文

1、需求分析對(duì)軟件項(xiàng)目開(kāi)發(fā)成敗影響探討摘要：需求分析是軟件工程過(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ā)；需求；分析1 引言軟件項(xiàng)目的開(kāi)發(fā)主要分為五個(gè)階段：需求分析階段、設(shè)計(jì)階段、編碼階段、測(cè)試階段和維護(hù)階段，需求分析是軟件開(kāi)發(fā)的第一個(gè)階段。完善的軟件需求說(shuō)明是軟件開(kāi)發(fā)項(xiàng)目得以成功的基礎(chǔ)。不管設(shè)計(jì)如何精心或者編碼如何巧妙，如果對(duì)軟件需求不加以明確規(guī)定，將使用戶(hù)感到失望

2、，并給軟件開(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)鍵階段。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ō)又像

3、是詳細(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ě)需求文檔。另外，還有其他幾種最新“需求”的定義：需求是用戶(hù)所需要的并能觸發(fā)一個(gè)程序或系統(tǒng)開(kāi)發(fā)工作的說(shuō)明；需求是從系統(tǒng)外部能發(fā)現(xiàn)系統(tǒng)所具有的滿(mǎn)足于用

4、戶(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ù)所想得到

5、的軟件存在著巨大的“期望差異”。 因此“需求”這個(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í)也

6、被稱(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ù)

7、定”。功能需求描述是開(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)行要

8、求，將來(lái)可能提出的要求。3.3 任務(wù) 需求分析任務(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)的接口?？梢哉f(shuō)需求文檔在開(kāi)發(fā)過(guò)程中一直起指導(dǎo)作用。為了更好地完成軟件開(kāi)發(fā)第一階段的需求分析任務(wù)，提高質(zhì)量，需求管理是必不可少的。需求管理的目的是在客戶(hù)與開(kāi)發(fā)方之間建立對(duì)需求的共同理解，維護(hù)需求與其他工作成果的一致性，并控制需求的變更，主要體現(xiàn)在跟蹤和控制

9、需求變更管理。需求管理是開(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ù)流的

10、結(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)的盒

11、子，然后打開(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)生需

12、求規(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)“做什么”的功能。

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)化。為了對(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á)了

14、他們的要求后，系統(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ù)，使許多

15、大型數(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ǔ)言作

16、補(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í)間的推

17、移，用戶(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)的可能

18、性。如圖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è)

19、新的版本來(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ě)法。 例如：使用學(xué)校員工IC卡功能模塊。4

20、 在此把軟件功能劃分成三個(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ì)情

21、況。 觸發(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)