需求分析與系統(tǒng)設(shè)計(jì)

1、需求分析與系統(tǒng)設(shè)計(jì) 第3章 需求確定 需求確定是一種關(guān)于社會(huì)、溝通和管理的技能。它是系統(tǒng)開(kāi)發(fā)中最不需要技術(shù)的一個(gè)階段，但是，如果沒(méi)有完全地進(jìn)行，其結(jié)果將會(huì)比其他階段更糟。由于沒(méi)有捕獲、忽略或錯(cuò)誤地理解客戶需求，為此而付出的代價(jià)在軟件過(guò)程的以后階段將是不可承受的。 需求確定 本章介紹需求確定中的一系列范圍廣泛的問(wèn)題。本章前半部分涉及需求抽取、協(xié)商和驗(yàn)證以及需求管理的問(wèn)題，后面還包括可追蹤性和變化管理的問(wèn)題，這個(gè)問(wèn)題我們將在第10章中詳細(xì)討論。 本章后半部分介紹用于描述與組織和目標(biāo)應(yīng)用領(lǐng)域相關(guān)的業(yè)務(wù)模型的基本圖形建模技術(shù)。還討論了需求文檔的結(jié)構(gòu)。 第3章 需求確定 3.1需求確定的原則 3.2需求

2、抽取 3.3需求協(xié)商和驗(yàn)證 3.4需求管理 3.5需求業(yè)務(wù)模型 3.6需求文檔 3.1需求確定的原則 需求確定是系統(tǒng)開(kāi)發(fā)生命周期的第一個(gè)階段。要開(kāi)發(fā)的系統(tǒng)由系統(tǒng)規(guī)劃活動(dòng)確定(1.2節(jié)），需求確定的目的包括提供功能和其他需求的敘述性定義，這些需求是投入者希望在實(shí)現(xiàn)的或部署的系統(tǒng)中所具有的。 需求定義了系統(tǒng)被期望的服務(wù)（服務(wù)陳述）和系統(tǒng)要服從的約束（約束陳述）。服務(wù)陳述可以分為幾個(gè)部分，它們是系統(tǒng)的范圍、必要的業(yè)務(wù)功能（功能需求）和要求的數(shù)據(jù)結(jié)構(gòu)（數(shù)據(jù)需求）。約束陳述可以按照系統(tǒng)不同限制的類(lèi)型來(lái)劃分，比如所要求的系統(tǒng)的“外觀和感覺(jué)”、性能、安全性等。 3.1需求確定的原則 需求需要從客戶（用戶和系

3、統(tǒng)所有者）那里獲得。這就是由業(yè)務(wù)（或系統(tǒng)）分析員引導(dǎo)的需求抽取活動(dòng)，從傳統(tǒng)的客戶會(huì)談到（如果必要）構(gòu)建軟件原型以通過(guò)它來(lái)發(fā)現(xiàn)更多的需求，有許多技術(shù)可以利用。 3.1需求確定的原則 收集到的需求必須進(jìn)行仔細(xì)的分析以消除多重性和矛盾，這個(gè)過(guò)程總會(huì)導(dǎo)致需求評(píng)審和與客戶的再一次協(xié)商。 一旦被客戶所接受，需求就要在需求文檔中進(jìn)行定義、分類(lèi)、編號(hào)并賦予不同的優(yōu)先級(jí)。需求文檔按組織選定的用于書(shū)寫(xiě)需求的文檔模板進(jìn)行組織。 3.1需求確定的原則 雖然需求文檔大部分都是敘述性的，它也可能包含一些高層圖形化的業(yè)務(wù)模型，這個(gè)業(yè)務(wù)模型一般由系統(tǒng)范圍模型、業(yè)務(wù)用例模型和業(yè)務(wù)類(lèi)模型組成。 客戶需求是一個(gè)移動(dòng)的目標(biāo)。為了處理

4、多變的需求，我們需要能夠管理變化。需求管理包含諸如估計(jì)變化對(duì)需求和系統(tǒng)的其他部分的影響等活動(dòng)。 3.2需求抽取 業(yè)務(wù)分析員通過(guò)咨詢發(fā)現(xiàn)系統(tǒng)的需求。這個(gè)咨詢過(guò)程涉及客戶和問(wèn)題領(lǐng)域的專家。在一些情況下，業(yè)務(wù)分析員擁有足夠的領(lǐng)域經(jīng)驗(yàn)，領(lǐng)域?qū)＜铱赡芫筒恍枰恕＿@時(shí)，就像圖3-l中用泛化關(guān)系構(gòu)建的模型那樣，一個(gè)業(yè)務(wù)分析員就是一種領(lǐng)域?qū)＜?。（記住，圖3-1不是用例模型，這里采用用例模型表示法只是為了方便而已。） 3.2需求抽取 從領(lǐng)域?qū)＜姨幊槿〉男枨笥深I(lǐng)域知識(shí)組成，它們捕獲了被廣泛承認(rèn)的與時(shí)間無(wú)關(guān)的業(yè)務(wù)規(guī)則，可適用于大多數(shù)的組織和系統(tǒng)。從客戶處抽取的需求以用例實(shí)例表示。它們超出了基本的領(lǐng)域知識(shí)，捕獲了組織

5、的獨(dú)特性質(zhì)，即當(dāng)前組織做業(yè)務(wù)的或業(yè)務(wù)應(yīng)該怎樣做的方式。 3.2需求抽取 業(yè)務(wù)分析員的任務(wù)就是要組合這兩部分需求以形成業(yè)務(wù)模型。如圖3-l所示，業(yè)務(wù)模型包含業(yè)務(wù)類(lèi)模型和業(yè)務(wù)用例模型。業(yè)務(wù)類(lèi)模型是一個(gè)高層類(lèi)圖，標(biāo)識(shí)并關(guān)聯(lián)業(yè)務(wù)對(duì)象。業(yè)務(wù)用例模型是一個(gè)高層用例圖，標(biāo)識(shí)系統(tǒng)中的主要功能構(gòu)建塊。3.2需求抽取 一般來(lái)說(shuō)，領(lǐng)域類(lèi)（業(yè)務(wù)對(duì)象）不必由用例導(dǎo)出（。實(shí)際上，業(yè)務(wù)類(lèi)模型應(yīng)該由業(yè)務(wù)用例模型來(lái)驗(yàn)證，這個(gè)驗(yàn)證過(guò)程可能導(dǎo)致業(yè)務(wù)類(lèi)模型的調(diào)整和擴(kuò)展。 我們區(qū)分傳統(tǒng)的和現(xiàn)代的事實(shí)發(fā)現(xiàn)和信息聚集方法。3.2需求抽取3.2.l傳統(tǒng)的需求抽取方法3.2.2現(xiàn)代需求抽取方法 3.2.l傳統(tǒng)的需求抽取方法 傳統(tǒng)的需求抽取方法

6、包括面談?dòng)泦?wèn)卷法、觀察法和業(yè)務(wù)文檔研究法。這些都是簡(jiǎn)單和合算的方法。 但這些傳統(tǒng)方法的效果與項(xiàng)目的風(fēng)險(xiǎn)是成反比的。高風(fēng)險(xiǎn)意味著系統(tǒng)難以實(shí)現(xiàn)，甚至高層的需求也非常不清楚。在這種項(xiàng)目中，這些傳統(tǒng)的方法就不可能勝任。 3.2.l傳統(tǒng)的需求抽取方法3.2.1.1與客戶和領(lǐng)域?qū)＜颐嬲?3.2.1.2問(wèn)卷法 3.2.1.3觀察 3.2.l.4文檔和軟件系統(tǒng)的研究 3.2.1.1與客戶和領(lǐng)域?qū)＜颐嬲?面談法是事實(shí)發(fā)現(xiàn)和信息聚集的基本技術(shù)。大多數(shù)的面談過(guò)程都是與客戶一起進(jìn)行的。與客戶面談大多用來(lái)抽取“用例”需求（圖3-1）。如果業(yè)務(wù)分析員沒(méi)有足夠的領(lǐng)域知識(shí)的話，可以把領(lǐng)域?qū)＜艺襾?lái)面談。 3.2.1.1與客戶和

7、領(lǐng)域?qū)＜颐嬲?與領(lǐng)域?qū)＜业拿嬲劷?jīng)常是一個(gè)知識(shí)轉(zhuǎn)換的過(guò)程，即對(duì)業(yè)務(wù)分析員來(lái)說(shuō)是一個(gè)學(xué)習(xí)過(guò)程。與客戶的面談就比較復(fù)雜了。 客戶可能對(duì)他們的需求只有一個(gè)模糊的認(rèn)識(shí)，他們也可能不愿意合作或不能夠表達(dá)他們的需求，他們還可能提出超出項(xiàng)目預(yù)算或不可實(shí)現(xiàn)的需求。最后，來(lái)自不同客戶的需求還可能發(fā)生沖突。 3.2.1.1與客戶和領(lǐng)域?qū)＜颐嬲?面談法有兩種基本形式：結(jié)構(gòu)化的（形式化的）和非結(jié)構(gòu)化的（非形式化的）。結(jié)構(gòu)化面談法需要提前準(zhǔn)備，有一個(gè)明確的日程，并且許多問(wèn)題都是預(yù)先確定的。有一些問(wèn)題可以是無(wú)確定答案的（對(duì)這些問(wèn)題，其答案無(wú)法預(yù)計(jì)），其他問(wèn)題可以是有確定答案的（回答從提供的答案中選?。?。 3.2.1.1與客

8、戶和領(lǐng)域?qū)＜颐嬲?結(jié)構(gòu)化面談法需要非結(jié)構(gòu)化面談法進(jìn)行補(bǔ)充。非結(jié)構(gòu)化面談法更像非正式的會(huì)議，沒(méi)有預(yù)定的問(wèn)題或預(yù)計(jì)的目的。非結(jié)構(gòu)化面談法的目的是鼓勵(lì)客戶講出他/她的想法，并且在這個(gè)過(guò)程中導(dǎo)出業(yè)務(wù)分析員沒(méi)有想到的和因而沒(méi)能提出的相關(guān)問(wèn)題的需求。 結(jié)構(gòu)化和非結(jié)構(gòu)化面談法都必須有某個(gè)出發(fā)點(diǎn)和討論的語(yǔ)境，這可以是一篇短的書(shū)面文檔，或在解釋面談?wù)吣康幕蛱岢鰡?wèn)題的會(huì)議之前發(fā)送給面談對(duì)象的email。3.2.1.1與客戶和領(lǐng)域?qū)＜颐嬲?一般來(lái)說(shuō)，有三種問(wèn)題應(yīng)該避免：固執(zhí)己見(jiàn)的問(wèn)題。在這種問(wèn)題中，面談?wù)撸ㄖ苯拥鼗蜷g接地）表達(dá)了你她自己關(guān)于這個(gè)問(wèn)題的觀點(diǎn)（“我們必須按我們做這件事的方式來(lái)做它嗎？”）。帶偏見(jiàn)的問(wèn)題。

9、它類(lèi)似于固執(zhí)己見(jiàn)的問(wèn)題，但面談?wù)叩挠^點(diǎn)明顯是有偏見(jiàn)的（“我們不做這件事，對(duì)嗎？”）。強(qiáng)加的問(wèn)題。它假設(shè)了問(wèn)題的答案（“你用這種方式做這件事，對(duì)嗎？”）。3.2.1.1與客戶和領(lǐng)域?qū)＜颐嬲?成功的面談存在許多因素，但也許最重要的是面談?wù)叩臏贤ê腿穗H交流技能。與面談?wù)咛岢鰡?wèn)題和控制面談過(guò)程的同時(shí)，認(rèn)真傾聽(tīng)和保持耐心從而使得面談對(duì)象不感到拘束也是同等重要的。為了維持好的人際關(guān)系并得到好的反饋，簡(jiǎn)單綜述面談的備忘錄應(yīng)該在一兩天內(nèi)發(fā)給面談對(duì)象。 3.2.1.2問(wèn)卷法 問(wèn)卷法是從多個(gè)客戶中收集信息的有效方法。它一般用來(lái)作為面談法的補(bǔ)充形式，而不是要替代它。但有一個(gè)例外，就是非常了解的低風(fēng)險(xiǎn)項(xiàng)目。對(duì)這種項(xiàng)目

10、，具有被動(dòng)特征和不是很深入的問(wèn)卷法就已經(jīng)足夠了。 3.2.1.2問(wèn)卷法 一般而言，問(wèn)卷法沒(méi)有面談法有效，因?yàn)闊o(wú)法澄清問(wèn)題和可能得到的響應(yīng)。問(wèn)卷法是被動(dòng)的，就它本身來(lái)說(shuō)既有優(yōu)點(diǎn)也有缺點(diǎn)。優(yōu)點(diǎn)在于回答者有時(shí)間去考慮如何回答，并且口答可以是匿名的。缺點(diǎn)在于回答者不容易弄清楚這些問(wèn)題的含義。 3.2.1.2問(wèn)卷法 問(wèn)卷應(yīng)該設(shè)計(jì)成便于問(wèn)題的回答。特別地，應(yīng)該避免開(kāi)放式問(wèn)題大多數(shù)問(wèn)題都應(yīng)該是封閉式的。封閉式問(wèn)題可以采用如下三種形式：評(píng)分問(wèn)題，回答者在這里需要表達(dá)他她對(duì)一段陳述的觀點(diǎn)，可能的分值可以是強(qiáng)烈同意、同意、中立、不同意、強(qiáng)烈不同意和不知道。多項(xiàng)選擇問(wèn)題，回答者在這里必須從提供的答案集中選取一個(gè)或多

11、個(gè)答案?？梢栽试S回答者附加注釋。排序問(wèn)題，這里所提供的答案應(yīng)該用序數(shù)、百分比或相似的排序方式給出。 3.2.1.2問(wèn)卷法 一個(gè)設(shè)計(jì)良好，易于回答的問(wèn)卷將鼓勵(lì)回答者及時(shí)返回完成的文檔。但是，在評(píng)估問(wèn)卷結(jié)果時(shí)，業(yè)務(wù)分析員應(yīng)該考慮到由于有些人沒(méi)有回答以至于可能提供不同的答案的這個(gè)事實(shí)所帶來(lái)的偏差。 3.2.1.3觀察 存在這樣的情景，其中業(yè)務(wù)分析員發(fā)現(xiàn)通過(guò)交談法和問(wèn)卷法都很難獲得完整的信息?？蛻艨赡懿荒軌蛴行У乇磉_(dá)信息，或者只有一個(gè)完整的業(yè)務(wù)過(guò)程中的片段知識(shí)。在這種情況下，觀察可能是有效的事實(shí)發(fā)現(xiàn)技術(shù)。學(xué)習(xí)如何系領(lǐng)帶的最好方法就是觀察這個(gè)過(guò)程。 3.2.1.3觀察 觀察可以有兩種形式：被動(dòng)觀察，業(yè)務(wù)

12、分析員在這里不受干擾或直接干預(yù)的情況下觀察業(yè)務(wù)活動(dòng)。在有些情況下，攝像機(jī)可以用來(lái)進(jìn)行更少干擾的觀察。主動(dòng)觀察，業(yè)務(wù)分析員在這里參與到活動(dòng)中，并且有效地成為其中的部分。3.2.1.3觀察 要使觀察具有代表性，觀察應(yīng)該持續(xù)進(jìn)行一個(gè)較長(zhǎng)的時(shí)間段，在不同的時(shí)間段上進(jìn)行，并且在不同的工作負(fù)荷下（挑選時(shí)間）進(jìn)行。觀察法的主要困難在于，人們?cè)诒挥^察的情況下總想表現(xiàn)出不同的行為。特別地，他們總想按照形式化的規(guī)則和過(guò)程去做。這會(huì)由于隱藏了正面或負(fù)面的工作方法而歪曲了現(xiàn)實(shí)情況。我們應(yīng)該記住“按規(guī)則進(jìn)行工作”在工業(yè)行為中是有效的形式。 3.2.l.4文檔和軟件系統(tǒng)的研究 文檔和軟件系統(tǒng)的研究是發(fā)現(xiàn)用例需求和領(lǐng)域知識(shí)

13、需求的不可限量的技術(shù)，雖然它可能只針對(duì)系統(tǒng)中所選擇的方面。 用例需求通過(guò)研究存在的組織文檔和系統(tǒng)表格報(bào)表（如果存在當(dāng)前系統(tǒng)的計(jì)算機(jī)化方案，因?yàn)橐话闶窃诖笮徒M織中）。對(duì)用例需求最有價(jià)值的了解之一是缺陷（如果存在的話）的記錄和對(duì)存在系統(tǒng)的變化要求。 3.2.l.4文檔和軟件系統(tǒng)的研究 要研究的組織文檔包括：業(yè)務(wù)表格（填好的，如果可能）、工作過(guò)程、職位描述、政策手冊(cè)、業(yè)務(wù)計(jì)劃、組織圖、辦公室之間的通信、會(huì)議紀(jì)要、財(cái)務(wù)報(bào)表、外部通信、客戶投訴等。 要研究的系統(tǒng)表格和報(bào)表包括：計(jì)算機(jī)屏幕和報(bào)表，并帶有所關(guān)聯(lián)的文檔：系統(tǒng)操作手冊(cè)、用戶文檔、技術(shù)文檔、系統(tǒng)分析和設(shè)計(jì)模型等。3.2.l.4文檔和軟件系統(tǒng)的研究

14、 領(lǐng)域知識(shí)需求通過(guò)研究領(lǐng)域刊物和參考手冊(cè)獲得。對(duì)專用軟件包（如ERP）的研究也提供領(lǐng)域知識(shí)源。因此，訪問(wèn)圖書(shū)館和軟件供應(yīng)商是需求抽取過(guò)程的一部分（當(dāng)然，因特網(wǎng)使得這種訪問(wèn)不離開(kāi)辦公室就能完成）。 3.2.2現(xiàn)代需求抽取方法 現(xiàn)代需求抽取方法包括軟件原型的使用、JAD（聯(lián)合應(yīng)用開(kāi)發(fā)）以及RAD（快速應(yīng)用開(kāi)發(fā)）。它們提供了對(duì)需求更深的理解，但需要較高的開(kāi)銷(xiāo)和較大的努力。當(dāng)然，長(zhǎng)期的付出可能是非常值得的。 當(dāng)項(xiàng)目風(fēng)險(xiǎn)高的時(shí)候總采用現(xiàn)代方法。項(xiàng)目風(fēng)險(xiǎn)高的因素有很多，包括不明確的目標(biāo)、未成文的過(guò)程、不穩(wěn)定的需求、不完善的用戶知識(shí)、沒(méi)有經(jīng)驗(yàn)的開(kāi)發(fā)人員、沒(méi)有足夠的用戶承諾等等。 3.2.2現(xiàn)代需求抽取方法3

15、.2.2.1原型法 3.2.2.2聯(lián)合應(yīng)用開(kāi)發(fā) 3.2.2.3快速應(yīng)用開(kāi)發(fā) 3.2.2.1原型法 原型法在現(xiàn)代需求獲取方法中是最常用的方法。構(gòu)造軟件原型為了使系統(tǒng)或者是系統(tǒng)的一部分對(duì)客戶可視化以獲得他們的反饋。 原型是一個(gè)演示系統(tǒng)，它是解決方案的一件“快速而粗糙的”工作模型，它呈現(xiàn)出 GUI（圖形用戶界面），并且對(duì)各種用戶事件模擬系統(tǒng)的行為。GUI屏幕上的信息內(nèi)容在原型程序中是硬編碼的，而不是從數(shù)據(jù)庫(kù)中動(dòng)態(tài)取得的。 3.2.2.1原型法 現(xiàn)代GUI的復(fù)雜性（和增長(zhǎng)的客戶期望）使原型法成為軟件開(kāi)發(fā)中必不可少的因素，系統(tǒng)的柔性和可用性可以通過(guò)原型在開(kāi)始真正的實(shí)現(xiàn)之前就估計(jì)出來(lái)。 通常，系統(tǒng)原型是抽

16、取從客戶那里用其他方式難以抽取的需求的一種非常有效的方式。對(duì)增加新的業(yè)務(wù)功能的系統(tǒng)常常是這種情況，對(duì)沖突的需求或者在客戶和開(kāi)發(fā)人員之間有溝通問(wèn)題時(shí)也是如此。 3.2.2.1原型法 原型有兩種：“丟棄”式原型。它是當(dāng)需求抽取完成時(shí)要被丟棄的?！皝G棄”式原型針對(duì)生命周期的需求確定階段，它集中在理解得最少的需求上。進(jìn)化式原型。它是在需求抽取之后仍保留并被用來(lái)產(chǎn)生最終產(chǎn)品。進(jìn)化式原型目標(biāo)在于產(chǎn)品發(fā)布的速度，它集中在理解得最好的需求上，使得產(chǎn)品的第1版能夠很快發(fā)布（雖然只具備不完整的功能）。3.2.2.1原型法 支持“丟棄”式原型的另一個(gè)論斷是，它避免了在最終產(chǎn)品中保留“快速而粗糙”或者不夠有效的方案。

17、然而，當(dāng)代軟件生產(chǎn)工具的能力和靈活性淡化了這個(gè)論斷。在一個(gè)管理得很好的項(xiàng)目中也不能根除無(wú)效原型是沒(méi)有道理的。 3.2.2.2聯(lián)合應(yīng)用開(kāi)發(fā) JAD在一個(gè)或多個(gè)工作會(huì)議中的一次聯(lián)合應(yīng)用開(kāi)發(fā)將所有的投入者（客戶和開(kāi)發(fā)人員）帶到了一起。雖然我們?cè)谶@里將JAD歸為現(xiàn)代需求抽取方法，但這種技術(shù)還是（由IBM）在20世紀(jì)70年代后期引入的。 有許多JAD的品牌，也有許多專門(mén)提供組織和執(zhí)行JAD活動(dòng)的服務(wù)的咨詢公司。一次JAD會(huì)議可能要幾個(gè)小時(shí)、幾天或者甚至一兩個(gè)星期，參加者的人數(shù)不應(yīng)超過(guò)25到30人。 3.2.2.2聯(lián)合應(yīng)用開(kāi)發(fā) 會(huì)議的參加者有：領(lǐng)導(dǎo)：組織和召集這次會(huì)議的人。這個(gè)人具有很強(qiáng)的交流能力，他不是

18、項(xiàng)目的投入者（除了作為JAD領(lǐng)導(dǎo)之外），但應(yīng)具有很好的業(yè)務(wù)領(lǐng)域的知識(shí)（但不需要很好的軟件開(kāi)發(fā)知識(shí)）。文書(shū)：在計(jì)算機(jī)上記錄JAD活動(dòng)的人。這個(gè)人應(yīng)該有快速錄入的技能，應(yīng)該具備很強(qiáng)的軟件開(kāi)發(fā)知識(shí)。他能夠使用 CASE工具為活動(dòng)生成文檔，并開(kāi)發(fā)最初的解決方案模型?？蛻簦ㄓ脩艉徒?jīng)理）：他們是交流、討論需求、作出決策、批準(zhǔn)項(xiàng)目目標(biāo)等工作的主要的參與者。開(kāi)發(fā)人員：開(kāi)發(fā)隊(duì)伍中的業(yè)務(wù)分析員和其他人員，他們聽(tīng)得多說(shuō)得少他們?cè)谶@個(gè)會(huì)議上是發(fā)現(xiàn)事實(shí)并收集信息，而不是支配這個(gè)過(guò)程。3.2.2.2聯(lián)合應(yīng)用開(kāi)發(fā) JAD利用了群體動(dòng)力學(xué)原理。“組協(xié)同”很可能得到問(wèn)題更好的解決方案。組提高生產(chǎn)力。學(xué)得更快、制定更多理智的判斷

19、、消除更多的錯(cuò)誤、采取更具風(fēng)險(xiǎn)的決定（雖然這一點(diǎn)可能起負(fù)作用）、使參與者的注意力更集中在那些最重要的問(wèn)題上、集成了人員等等。當(dāng)按照規(guī)則引導(dǎo)時(shí)，JAD活動(dòng)傾向于輸出令人驚奇的好結(jié)果。但也有人警告說(shuō)，“福特汽車(chē)公司在20世紀(jì)50年代因?yàn)镋dsel（由一個(gè)委員會(huì)設(shè)計(jì)的汽車(chē)）而經(jīng)歷了一場(chǎng)市場(chǎng)的災(zāi)難?！?3.2.2.3快速應(yīng)用開(kāi)發(fā) RAD（快速應(yīng)用開(kāi)發(fā)）不僅僅是一種需求抽取方法，它還是視軟件開(kāi)發(fā)為一體的方法。RAD目的是快速發(fā)布系統(tǒng)方案，而技術(shù)上的優(yōu)美對(duì)發(fā)布速度來(lái)說(shuō)則是次要的。 3.2.2.3快速應(yīng)用開(kāi)發(fā) RAD組合了五個(gè)方面的技術(shù)：進(jìn)化原型。帶有代碼生成以及在設(shè)計(jì)模型和代碼之間的循環(huán)工程的CASE工具

20、。擁有先進(jìn)工具的專門(mén)人員（SWAT）：RAD開(kāi)發(fā)小組。最好的分析員、設(shè)計(jì)師和程序員是這個(gè)組織能得到的。這個(gè)開(kāi)發(fā)組在嚴(yán)格的時(shí)間安排下工作，并與用戶在一起。交互式JAD：一個(gè) JAD活動(dòng)，在此期間文書(shū)由具有 CASE工具的 SWAT小組代替。時(shí)間表：SWAT小組完成項(xiàng)目具有固定時(shí)間期限（時(shí)間表）的項(xiàng)目管理方法，這個(gè)方法禁止“范圍擴(kuò)張”；如果項(xiàng)目進(jìn)展慢就削減方案涉及的范圍以使項(xiàng)目能按時(shí)完成。 3.2.2.3快速應(yīng)用開(kāi)發(fā) RAD方法對(duì)許多項(xiàng)目來(lái)說(shuō)是有吸引力的，特別是針對(duì)不是組織核心業(yè)務(wù)范圍，并且因此不給其他開(kāi)發(fā)項(xiàng)目制訂日程表的小項(xiàng)目而言?？焖偾蠼夂芸赡懿皇亲顑?yōu)的或者不是核心業(yè)務(wù)范圍內(nèi)能承受的。與RAD

21、相關(guān)的問(wèn)題包括：1.不一致的GUI設(shè)計(jì)。2.支持軟件復(fù)用的專門(mén)的解決方案，而不是通用的解決方案。3.不足的文檔。4.難以維護(hù)和擴(kuò)展的軟件等。3.3需求協(xié)商和驗(yàn)證 從客戶處抽取的需求可能是重疊和矛盾的，有些需求可能是二義的或不現(xiàn)實(shí)的，而其他需求又可能還沒(méi)發(fā)現(xiàn)。由于這些原因，需求在被編進(jìn)文檔之前需要進(jìn)行協(xié)商和驗(yàn)證。 實(shí)際上，需求協(xié)商和驗(yàn)證是與需求抽取同步進(jìn)行的。在需求抽取的同時(shí)，它們也經(jīng)受某種程度的審查。在包括所謂組協(xié)同方法在內(nèi)的所有現(xiàn)代需求抽取技術(shù)原本就是如此，而且，一旦所有抽取到的需求放到一起，它們還要經(jīng)歷仔細(xì)的協(xié)商和驗(yàn)證。3.3需求協(xié)商和驗(yàn)證 需求協(xié)商和驗(yàn)證不能不與書(shū)寫(xiě)需求文檔的過(guò)程關(guān)聯(lián)在一

22、起。需求協(xié)商通常是以文檔的草稿為基礎(chǔ)的，如果需要，列在文檔草稿中的需求就要被協(xié)商修改。錯(cuò)誤的需求被移走，新發(fā)現(xiàn)的需求被加入。 需求驗(yàn)證要求有更完整的需求文檔的版本，其中所有的需求都要被清楚地標(biāo)識(shí)和分類(lèi)。投入者閱讀文檔并且召集正式的審查會(huì)，審查常常結(jié)構(gòu)化為所謂的走查或檢查。審查也是測(cè)試的一種形式。3.3需求協(xié)商和驗(yàn)證 3.3.l超出范圍的需求 3.3.2需求依賴矩陣 3.3.3需求風(fēng)險(xiǎn)和優(yōu)先順序 3.3.l超出范圍的需求 IT項(xiàng)目的選擇和因此要實(shí)現(xiàn)的系統(tǒng)（以及它們的廣泛范圍）都是在系統(tǒng)規(guī)劃活動(dòng)中確定的。然而，系統(tǒng)之間詳細(xì)的相互依賴關(guān)系只有在需求分析階段被發(fā)現(xiàn)。確定系統(tǒng)邊界（系統(tǒng)范圍）是需求分析的

23、任務(wù)，使得“范圍擴(kuò)張”問(wèn)題在這個(gè)過(guò)程中可以早點(diǎn)解決。 3.3.l超出范圍的需求 決定任何特定需求是在系統(tǒng)范圍之內(nèi)還是之外，需要一個(gè)參考模型來(lái)對(duì)照才能作出決定。歷史上，這樣一個(gè)參考模型由語(yǔ)境圖來(lái)提供流行的結(jié)構(gòu)化建模技術(shù)的頂級(jí)圖稱為DFD（數(shù)據(jù)流圖）。雖然DFD在UML中已經(jīng)被用例圖所代替，語(yǔ)境圖仍然是建立系統(tǒng)邊界很好的方法。 3.3.l超出范圍的需求 然而，為什么需求落在范圍之外還有其他的原因。例如，一個(gè)需求可能在計(jì)算機(jī)化的系統(tǒng)中難以實(shí)現(xiàn)，它留在人類(lèi)完成的過(guò)程中?；蛘咝枨罂赡芫哂械偷膬?yōu)先級(jí)并被排除在系統(tǒng)的第1個(gè)版本之外。需求可能己經(jīng)在硬件或外部設(shè)備中實(shí)現(xiàn)了，并且超出了軟件系統(tǒng)的控制范圍。 3.3

24、.2需求依賴矩陣 假設(shè)所有的需求都被清楚地標(biāo)識(shí)和編號(hào)，還可以構(gòu)造需求依賴矩陣（或交互矩陣。這個(gè)矩陣按一個(gè)分類(lèi)順序分別在行和列的表頭上列出需求標(biāo)識(shí)符，如表3- 1所示。 表3-1需求依賴矩陣需求R1R2R3R4R1XXXXR2沖突XXXR3XXR4重疊重疊X3.3.2需求依賴矩陣 矩陣的右上部分（對(duì)角線的上面并包含對(duì)角線）沒(méi)有用上，其余單元格指出任意兩個(gè)需求是否重疊、是否矛盾或者是否獨(dú)立（空單元格）。矛盾的需求應(yīng)與客戶進(jìn)行討論，并且可能的話重新構(gòu)形這個(gè)需求以避免矛盾（并且矛盾的記錄應(yīng)該保留，對(duì)后續(xù)的開(kāi)發(fā)可見(jiàn)）。重疊的需求也要重新陳述以消除重疊。 3.3.2需求依賴矩陣 當(dāng)需求的條數(shù)相對(duì)較小的時(shí)候

25、，需求依賴矩陣是發(fā)現(xiàn)矛盾和重疊的一個(gè)簡(jiǎn)單而有效的技術(shù)。若不是這種情況，如果需求能組合成不同的類(lèi)，并且能獨(dú)立地在每個(gè)類(lèi)中進(jìn)行比較時(shí)，這種技術(shù)也是有用的。 3.3.3需求風(fēng)險(xiǎn)和優(yōu)先順序 一旦解決了需求中的沖突和重疊，并且產(chǎn)生了一個(gè)修改后需求的集合，這個(gè)需求集合還需要進(jìn)行風(fēng)險(xiǎn)分析和優(yōu)先排序。風(fēng)險(xiǎn)分析標(biāo)識(shí)那些可能引起開(kāi)發(fā)困難的需求。需要優(yōu)先排序是為了允許當(dāng)遇到延遲時(shí)能夠容易地重新界定范圍。 3.3.3需求風(fēng)險(xiǎn)和優(yōu)先順序 需求可能由于各種因素而“具有風(fēng)險(xiǎn)”，典型的風(fēng)險(xiǎn)種類(lèi)是：技術(shù)風(fēng)險(xiǎn)，當(dāng)需求在技術(shù)上是難以實(shí)現(xiàn)的。性能風(fēng)險(xiǎn)，當(dāng)需求在實(shí)現(xiàn)后，反而會(huì)影響系統(tǒng)的響應(yīng)時(shí)間。安全風(fēng)險(xiǎn)，當(dāng)需求在實(shí)現(xiàn)后，會(huì)把系統(tǒng)暴露到

26、安全缺口。數(shù)據(jù)庫(kù)完整性風(fēng)險(xiǎn)，當(dāng)需求不能被容易地驗(yàn)證并可能引起數(shù)據(jù)不一致性。開(kāi)發(fā)過(guò)程風(fēng)險(xiǎn)，當(dāng)系統(tǒng)要求使用開(kāi)發(fā)人員不熟悉的非常規(guī)開(kāi)發(fā)方法（如形式化規(guī)格說(shuō)明方法）。政治風(fēng)險(xiǎn)，當(dāng)需求由于內(nèi)部的政治原因被證明是難以滿足的。法律風(fēng)險(xiǎn)，當(dāng)需求可能招致當(dāng)前法律上的困難，或者預(yù)先假定了法律的變化。易變性風(fēng)險(xiǎn)，當(dāng)需求很可能在開(kāi)發(fā)過(guò)程中不斷變化或進(jìn)化。 3.3.3需求風(fēng)險(xiǎn)和優(yōu)先順序 理想地，需求優(yōu)先級(jí)首先在需求抽取過(guò)程中從個(gè)體客戶處獲得，然后在會(huì)議中協(xié)商并當(dāng)風(fēng)險(xiǎn)因素附加在它們上面時(shí)進(jìn)行再一次修改。 為了消除二義性并支持優(yōu)先級(jí)的賦值，優(yōu)先級(jí)分類(lèi)的數(shù)目應(yīng)該小一些，通常設(shè)35個(gè)不同的優(yōu)先級(jí)，它們可以被命名為“高”、“中”

27、、“低”、“不確定”。另外可選的優(yōu)先級(jí)可以是“本質(zhì)的”、“有用的”、“幾乎不可能的事情”、“待確定的”。 3.4需求管理 需求必須被管理。需求管理實(shí)際上是項(xiàng)目管理的一個(gè)部分，它涉及三個(gè)主要問(wèn)題：1.識(shí)別、分類(lèi)、組織需求，并為需求建立文檔。2.需求變化（即帶有建立對(duì)需求不可避免的變化是如何提出、如何協(xié)商、如何驗(yàn)證以及如何形成文檔的過(guò)程）。3.需求可跟蹤性（即帶有維護(hù)需求之間以及與系統(tǒng)的其他制品之間依賴關(guān)系的過(guò)程。 3.4需求管理 3.4.l需求識(shí)別與分類(lèi)3.4.2需求層次 3.4.3變化管理 3.4.4需求可跟蹤性 3.4.l需求識(shí)別與分類(lèi) 需求是用自然語(yǔ)言陳述的，如：“根據(jù)電話銷(xiāo)售人員的請(qǐng)求，

28、系統(tǒng)將安排下一次給客戶打電話。”“系統(tǒng)將自動(dòng)撥通安排好的電話號(hào)碼，并同時(shí)在電話銷(xiāo)售人員的屏幕上顯示客戶信息，包括電話號(hào)碼、客戶號(hào)、客戶名宇?！薄霸诔晒油〞r(shí)，系統(tǒng)應(yīng)將顯示一段介紹性文本，電話銷(xiāo)售人員將與客戶開(kāi)始進(jìn)行一次對(duì)話?！?通常系統(tǒng)由幾百或幾千條像上面那樣的需求陳述組成。要適當(dāng)?shù)毓芾砗眠@樣大量的需求，這些需求必須用某種識(shí)別方案進(jìn)行編號(hào)，這個(gè)方案可以包含將需求分成更便于管理的組的一個(gè)分類(lèi)。 3.4.l需求識(shí)別與分類(lèi) 有幾種對(duì)需求進(jìn)行識(shí)別和分類(lèi)的技術(shù)：惟一標(biāo)識(shí)符：通常是一個(gè)連續(xù)的編號(hào)，由手工方式或由 CASE工具的數(shù)據(jù)庫(kù)生成（即CASE工具存儲(chǔ)分析和設(shè)計(jì)制品的數(shù)據(jù)庫(kù)（或資源庫(kù)）并賦值。在文檔層

29、次之內(nèi)連續(xù)編號(hào)：考慮需求在需求文檔中位置的賦值。在需求的種類(lèi)之內(nèi)連續(xù)編號(hào)：加上一些幫助記憶的標(biāo)識(shí)需求的種類(lèi)的名字的賦值（這里，需求的種類(lèi)可以是功能需求、數(shù)據(jù)需求、性能需求、安全需求等等）。3.4.l需求識(shí)別與分類(lèi) 每種標(biāo)識(shí)方法都有正反兩個(gè)方面的理由。最靈活和不容易出錯(cuò)的方法是數(shù)據(jù)庫(kù)生成惟一標(biāo)識(shí)符的方法，數(shù)據(jù)庫(kù)具有對(duì)每一個(gè)數(shù)據(jù)記錄在多用戶同時(shí)存取數(shù)據(jù)的情況下生成惟一標(biāo)識(shí)符的固有能力。 一些數(shù)據(jù)庫(kù)還有對(duì)相同記錄的多個(gè)版本維護(hù)的支持（通過(guò)用版本值來(lái)擴(kuò)展惟一標(biāo)識(shí)符的值的方法）。最后，數(shù)據(jù)庫(kù)能夠維護(hù)包括需求在內(nèi)的建模構(gòu)件之間的索引完整性鏈，因而能對(duì)需求變化管理和可跟蹤性提供必要的支持。 3.4.2需求層

30、次 需求可以按父子關(guān)系建立層次化結(jié)構(gòu)。父子關(guān)系與組合關(guān)系相似，父級(jí)需求由各種子級(jí)需求組成，子級(jí)需求是父級(jí)需求有效的子需求。 層次關(guān)系將另一種層次引入了需求分類(lèi)。這個(gè)層次可以直接反映，也可以不直接反映在標(biāo)識(shí)編號(hào)中（用點(diǎn)表示）。因此，編號(hào)為4.9的需求應(yīng)該是指由編號(hào)為4來(lái)標(biāo)識(shí)的父級(jí)需求的第9個(gè)子級(jí)需求。3.4.2需求層次 下面是一組層次的需求：1.“對(duì)應(yīng)電話銷(xiāo)售人員的請(qǐng)求，系統(tǒng)將安排下一次給客戶打電話?！?.l“系統(tǒng)將對(duì)應(yīng)每次Telemarketinq Control表格的輸入，或前一次電話被中斷時(shí)都激活Next Call的按鈕?！?.2“系統(tǒng)將從打電話隊(duì)列的頂端刪除這次電話，井使得這次電話成為當(dāng)

31、前的電話?！?.3等等。3.4.2需求層次 需求的層次允許定義在不同抽象層次上的需求，這與在向低抽象層次發(fā)展時(shí)應(yīng)系統(tǒng)地細(xì)化模型全面的建模原則是一致的。結(jié)果是，高級(jí)模型可以構(gòu)造成父級(jí)需求，而低級(jí)模型可以作為子級(jí)需求鏈接上去。 3.4.3變化管理 需求是變化的。在開(kāi)發(fā)生命周期的任何階段，需求都可以被改變、可以被刪除或者可以增加新的需求。變化井不是災(zāi)難，但沒(méi)有管理的變化卻是。 開(kāi)發(fā)越往前走，變化的開(kāi)銷(xiāo)越大。事實(shí)上，由于變化而將項(xiàng)目沿著開(kāi)發(fā)軌跡向回拖的向下開(kāi)銷(xiāo)總是增長(zhǎng)的，巳總是指數(shù)式增長(zhǎng)的。改變一個(gè)剛創(chuàng)建的還沒(méi)有與其他需求鏈接的需求僅僅是直接編輯的工作，而當(dāng)同一個(gè)需求已經(jīng)在軟件中實(shí)現(xiàn)時(shí)再去改變它就可能

32、會(huì)出現(xiàn)不可承擔(dān)的開(kāi)銷(xiāo)了。3.4.3變化管理 一個(gè)變化可能與人為錯(cuò)誤有關(guān)，但常常是由于內(nèi)部政策的變化或外部因素而引起的，如競(jìng)爭(zhēng)力、全球市場(chǎng)或技術(shù)進(jìn)步。無(wú)論什么原因，需要強(qiáng)有力的管理政策來(lái)建立變化需求的文檔，使得能夠估計(jì)變化的影響并實(shí)現(xiàn)變化。 由于需求的變化是開(kāi)銷(xiāo)很大的，因而對(duì)每一個(gè)變化請(qǐng)求必須建立正式的業(yè)務(wù)用例。一個(gè)有效的變化（以前沒(méi)有處理的）必須從技術(shù)可行性、對(duì)項(xiàng)目其他部分的影響以及開(kāi)銷(xiāo)上進(jìn)行估計(jì)。一旦批準(zhǔn)，變化就被結(jié)合進(jìn)相關(guān)的模型，并在軟件中實(shí)現(xiàn)。 3.4.3變化管理 變化管理涉及跟蹤大量的跨越較長(zhǎng)時(shí)間段的相互聯(lián)系的信息，沒(méi)有工具的支持，變化管理注定是要失敗的。理想的情況下，需求的變化應(yīng)該由

33、軟件配置管理工具存儲(chǔ)和跟蹤，這個(gè)工具由開(kāi)發(fā)者使用來(lái)處理在整個(gè)開(kāi)發(fā)周期中模型和程序的版本。好的 CASE工具應(yīng)該要么具有自身的配置管理能力，要么鏈接到一個(gè)獨(dú)立存在的配置管理工具上。 3.4.4需求可跟蹤性 需求可跟蹤性雖然絕對(duì)重要但卻僅僅是變化管理的一部分。需求可跟蹤性模塊對(duì)從需求出發(fā)貫穿整個(gè)開(kāi)發(fā)生命周期的變化維護(hù)一個(gè)可跟蹤的關(guān)系。 3.4.4需求可跟蹤性 考慮需求：“對(duì)應(yīng)電話銷(xiāo)售人員的請(qǐng)求，系統(tǒng)將安排下一次給客戶打電話”。這個(gè)需求可以用一個(gè)序列圖來(lái)建模，通過(guò)GUI用標(biāo)記為“NeXt Call”的行為按鈕來(lái)激活，并用一個(gè)數(shù)據(jù)庫(kù)觸發(fā)器來(lái)編程。如果這些元素之間的可跟蹤性關(guān)系存在，其中任何元素的變化都

34、會(huì)使得這個(gè)關(guān)系提交進(jìn)行再討論，這個(gè)軌跡成是可疑的（用一個(gè)工具術(shù)語(yǔ)來(lái)說(shuō)）。 3.4.4需求可跟蹤性 可跟蹤性關(guān)系可以在連續(xù)的生命周期階段穿越許多模型。只有相鄰的可跟蹤性鏈接可以被直接修改。例如，如果元素A被跟蹤到元素B，B又到C，則在這個(gè)關(guān)系每個(gè)端點(diǎn)的變化都要經(jīng)過(guò)兩步才能完成：修改AB鏈接和BC鏈接。 3.5需求業(yè)務(wù)模型 需求確定階段捕獲需求并（主要）用自然語(yǔ)言定義需求，采用UML進(jìn)行形式化的需求建模是在以后的需求規(guī)格說(shuō)明階段進(jìn)行的。然而，采集到的需求的一個(gè)高級(jí)可視化表示，稱為需求業(yè)務(wù)模型，卻一般在需求確定階段完成。 作為最低要求，這個(gè)高級(jí)可視化表示需要確定系統(tǒng)范圍、識(shí)別基本的用例并建立最本質(zhì)的

35、業(yè)務(wù)類(lèi)。圖3-2展示了需求確定階段這三個(gè)模型和生命周期其余階段的模型之間的相關(guān)性。 3.5需求業(yè)務(wù)模型 用例圖在生命周期中的主導(dǎo)作用如圖3-2所示。因?yàn)槌姓J(rèn)測(cè)試模型，用戶文檔和項(xiàng)目規(guī)劃都是由它導(dǎo)出的。除此之外，用例圖和類(lèi)模型在連續(xù)的開(kāi)發(fā)送代中還同時(shí)應(yīng)用并相互導(dǎo)出。設(shè)計(jì)和實(shí)現(xiàn)也是交織在一起的，并能夠反饋到需求規(guī)格說(shuō)明模型。 3.5需求業(yè)務(wù)模型 3.5.l系統(tǒng)范圍模型 3.5.2業(yè)務(wù)用例模型 3.5.3業(yè)務(wù)類(lèi)模型 3.5.l系統(tǒng)范圍模型 也許系統(tǒng)開(kāi)發(fā)的主要考慮是由于變化的需求引起的范圍擴(kuò)張，當(dāng)需求的變化不可避免時(shí)，我們不得不要求變化不要超出項(xiàng)目已接受的范圍。 問(wèn)題是：“我們?cè)鯓佣x系統(tǒng)的范圍？”這

36、個(gè)問(wèn)題不是能直接回答的，因?yàn)槿魏蜗到y(tǒng)都是一個(gè)更大的環(huán)境的一個(gè)部分，一起組成這個(gè)環(huán)境的系統(tǒng)的一部分。這些系統(tǒng)通過(guò)交換信息和相互調(diào)用服務(wù)來(lái)進(jìn)行合作。因此，上述問(wèn)題可以解釋為：“我們必須實(shí)現(xiàn)這個(gè)需求嗎？”或者“所要求的功能是其他系統(tǒng)的職責(zé)嗎？” 3.5.l系統(tǒng)范圍模型 為了能夠回答這個(gè)問(wèn)題，我們需要知道我們的系統(tǒng)在其中運(yùn)作的語(yǔ)境。我們需要知道外部實(shí)體，其他的系統(tǒng)、組織、人員、機(jī)器等，這些期望從我們這里得到服務(wù)或?yàn)槲覀兲峁┓?wù)的實(shí)體。在業(yè)務(wù)系統(tǒng)，這些服務(wù)翻譯成信息，即數(shù)據(jù)流。 3.5.l系統(tǒng)范圍模型 因此，系統(tǒng)范圍可以通過(guò)外部實(shí)體以及外部實(shí)體和我們系統(tǒng)之間的輸入輸出流來(lái)確定，我們的系統(tǒng)獲得輸入信息，并

37、做一些必要的處理而產(chǎn)生輸出信息。任何不能由系統(tǒng)內(nèi)部處理所支持的需求都在系統(tǒng)的范圍之外。 UML沒(méi)有提供好的可視化模型來(lái)定義系統(tǒng)的范圍，因此，老式的DFD語(yǔ)境圖常常被應(yīng)用于此。圖3-3展示了電話銷(xiāo)售應(yīng)用的語(yǔ)境圖。 系統(tǒng)范圍建模示例例3.1電話銷(xiāo)售） 考慮關(guān)于電話銷(xiāo)售的問(wèn)題陳述，并為它構(gòu)造語(yǔ)境圖。除此之外，還考慮如下需求：1.活動(dòng)按照社會(huì)信托人出于有價(jià)值和合時(shí)宜的原因提出的建議來(lái)規(guī)劃。活動(dòng)必須經(jīng)當(dāng)?shù)卣鷾?zhǔn)，活動(dòng)的設(shè)計(jì)和規(guī)劃由一個(gè)獨(dú)立的 Campaign Database應(yīng)用系統(tǒng)來(lái)支持。2.還有一個(gè)獨(dú)立的 Supporter Database來(lái)存儲(chǔ)和維護(hù)所有支持者的信息過(guò)去的和未來(lái)的。這個(gè)數(shù)據(jù)庫(kù)用

38、于在特定的活動(dòng)中選擇要聯(lián)系的支持者，選擇出來(lái)的部分支持者交給該活動(dòng)中的電話銷(xiāo)售行為。3.來(lái)自支持者的彩票定單在活動(dòng)過(guò)程都要記錄下來(lái)，由Order Processing系統(tǒng)處理。一個(gè)定單處理系統(tǒng)維護(hù)支持者數(shù)據(jù)庫(kù)中的定單狀態(tài)。 圖3-3顯示了你可能提出的作為這個(gè)例子的解決方案的語(yǔ)境圖。圖中間的“圓泡”表示我們的系統(tǒng)，圍繞它的長(zhǎng)方形框指定為外部實(shí)體，箭頭描繪了數(shù)據(jù)流，數(shù)據(jù)流更細(xì)的信息內(nèi)容在圖上是不可見(jiàn)的，數(shù)據(jù)流的內(nèi)容獨(dú)立定義和存儲(chǔ)在 CASE工具的資源庫(kù)中。 系統(tǒng)范圍建模示例例3.1電話銷(xiāo)售） Telemarketing系統(tǒng)從外部實(shí)體Campaign Database那里獲取當(dāng)前活動(dòng)的信息。該信息包

39、括票的數(shù)目和價(jià)格、彩票中獎(jiǎng)值、活動(dòng)期限等等。 同樣， Telemarketing從Supporter Database那里獲取支持者的細(xì)節(jié)。在電話銷(xiāo)售活動(dòng)打電話的過(guò)程中，關(guān)于支持者的新的信息可能出現(xiàn)（例如支持者想要改變他們的電話號(hào)碼）。Supporter Database需要依此更新，因而數(shù)據(jù)流Support Details是雙向的。系統(tǒng)范圍建模示例例3.1電話銷(xiāo)售） 主要的活動(dòng)是在Telemarketing和Supporter之間，數(shù)據(jù)流Conversation包含電話通話期間被交換的信息。一個(gè)支持者對(duì)電話銷(xiāo)售人員對(duì)供應(yīng)的購(gòu)買(mǎi)彩票的回復(fù)沿?cái)?shù)據(jù)流 e傳送，而另一個(gè)獨(dú)立的數(shù)據(jù)流Ticket Pl

40、acement用于記錄由支持者預(yù)定彩票的細(xì)節(jié)。 系統(tǒng)范圍建模示例例3.1電話銷(xiāo)售） 彩票預(yù)定的進(jìn)一步處理超出了我們系統(tǒng)的范圍。數(shù)據(jù)流Ticket Order轉(zhuǎn)送到外部實(shí)體order Processing。我們可以假設(shè)在預(yù)定輸入后，別的外部實(shí)體可以處理支持者的付款、票的寄出、抽獎(jiǎng)等。這些不是我們所考慮的，只要來(lái)自外部實(shí)體Campaign Database和Supporter Database的定單當(dāng)前狀態(tài)和付款等對(duì)我們來(lái)說(shuō)是存在的就可以了。 系統(tǒng)范圍建模示例例3.1電話銷(xiāo)售）3.5.2業(yè)務(wù)用例模型 業(yè)務(wù)用例模型是一個(gè)在較高的抽象級(jí)別上的用例模型。業(yè)務(wù)用例模型標(biāo)識(shí)高層業(yè)務(wù)進(jìn)程：業(yè)務(wù)用例。業(yè)務(wù)用例相

41、當(dāng)于經(jīng)常被稱為系統(tǒng)特征的東西（系統(tǒng)特征在視點(diǎn)文檔中標(biāo)識(shí)。如果一個(gè)視點(diǎn)文檔存在，則它可以用來(lái)代替業(yè)務(wù)用例模型）。 3.5.2業(yè)務(wù)用例模型 業(yè)務(wù)用例圖的焦點(diǎn)是業(yè)務(wù)進(jìn)程體系結(jié)構(gòu)。這個(gè)圖提供了所希望的系統(tǒng)行為的鳥(niǎo)瞰圖，對(duì)每個(gè)業(yè)務(wù)用例的陳述性描述是簡(jiǎn)短的和面向業(yè)務(wù)的并集中在活動(dòng)的主要流程上。業(yè)務(wù)用例模型不適于傳達(dá)給開(kāi)發(fā)人員系統(tǒng)確切地應(yīng)該做什么。 3.5.2業(yè)務(wù)用例模型 業(yè)務(wù)用例在需求規(guī)格說(shuō)明階段被轉(zhuǎn)換成用例，就是在這個(gè)階段詳細(xì)的用例才被標(biāo)識(shí)。敘述性描述被擴(kuò)展成包括子進(jìn)程和替換進(jìn)程，一些GUI界面被制作出模型，并且用例之間的關(guān)系也被建立。 3.5.2業(yè)務(wù)用例模型 業(yè)務(wù)用例圖中的參與者不同于語(yǔ)境圖中的外部實(shí)

42、體。區(qū)別在于參與者與系統(tǒng)交互，參與者是主動(dòng)的，他們具有控制的作用，他們通過(guò)發(fā)送事件來(lái)觸發(fā)用例。用例是事件驅(qū)動(dòng)的，參與者與用例之間的通信線路不是數(shù)據(jù)流，它們表示來(lái)自參與者的事件流和來(lái)自用例的響應(yīng)流。 3.5.2業(yè)務(wù)用例模型 參與者具有很有意思的兩面性。參與者對(duì)系統(tǒng)來(lái)說(shuō)可以既是外部的又是內(nèi)部的。因?yàn)樗麄儚耐獠颗c系統(tǒng)交互，所以他們是外部的。因?yàn)橄到y(tǒng)可能維護(hù)關(guān)于參與者的信息，使得系統(tǒng)能夠主動(dòng)地與“外部”參與者交互，所以他們又是內(nèi)部的。作為一個(gè)模型，系統(tǒng)規(guī)格說(shuō)明必須描述系統(tǒng)以及環(huán)境。這個(gè)環(huán)境包含參與者，系統(tǒng)本身也可以保留關(guān)于參與者的信息。因此，規(guī)格說(shuō)明保持了與參與者相關(guān)的兩個(gè)模型：一個(gè)參與者的模型以及一

43、個(gè)系統(tǒng)所記錄的關(guān)于參與者的模型。 業(yè)務(wù)用例建模示例例3.2（電話銷(xiāo)售） 考慮電話銷(xiāo)售的問(wèn)題陳述和語(yǔ)境圖，構(gòu)造其業(yè)務(wù)用例圖。 一個(gè)可能的業(yè)務(wù)用例圖如圖 3-4所示，有兩個(gè)參與者： Telemarketer和Supporter。Telemarketer要求系統(tǒng)對(duì)于支持者的電話都要安排并撥號(hào)。一旦連接成功，Supporter被涉及作為一個(gè)參與者，業(yè)務(wù)用例Schedule Phone Conversation對(duì)所有參與者來(lái)說(shuō)變成一塊外部可見(jiàn)的求值的功能。 業(yè)務(wù)用例建模示例例3.2（電話銷(xiāo)售） 在通話期間，Telemarketer可能需要存取和修改活動(dòng)和支持者的細(xì)節(jié)。這個(gè)功能在業(yè)務(wù)用例CRUD Camp

44、aign and Supporter Details中被捕獲。（CRUD是一個(gè)流行的字母首字，代表四個(gè)主要的數(shù)據(jù)操作：創(chuàng)建、讀、更新、刪除。） 業(yè)務(wù)用例建模示例例3.2（電話銷(xiāo)售） 最后，業(yè)務(wù)用例Enter Conversation e用于輸入電話銷(xiāo)售活動(dòng)的成功或不成功的結(jié)果。這個(gè)用例傳遞一個(gè)對(duì)所有參與者都可標(biāo)識(shí)的值。 業(yè)務(wù)用例建模示例例3.2（電話銷(xiāo)售） 忽略用例 CRUD Campaign and Supporter Details和 Enter Conversation e之間的關(guān)系是武斷的。通常，用例之間的所有關(guān)系都可以隱藏起來(lái)，其目的是為了避免整個(gè)圖太雜亂擁擠。用例傾向于擁有與大多數(shù)

45、其他用例之間的某種類(lèi)型的通信，因此包含所有關(guān)系比這個(gè)目的更重要。 3.5.3業(yè)務(wù)類(lèi)模型 業(yè)務(wù)類(lèi)模型是一個(gè)類(lèi)模型。業(yè)務(wù)類(lèi)模型就像業(yè)務(wù)用例模型一樣，區(qū)別僅僅在于它們的抽象層次上。業(yè)務(wù)類(lèi)模型標(biāo)識(shí)系統(tǒng)中的主要“業(yè)務(wù)對(duì)象”，支持和駕馭系統(tǒng)的業(yè)務(wù)數(shù)據(jù)結(jié)構(gòu)。 業(yè)務(wù)類(lèi)模型也在一個(gè)高的抽象層次上提出，在這個(gè)層次上，我們很少對(duì)類(lèi)的屬性感興趣類(lèi)的名字和一個(gè)簡(jiǎn)短的描述就足夠了。 經(jīng)常出現(xiàn)這樣的情況，即業(yè)務(wù)用例模型的參與者被表示為業(yè)務(wù)類(lèi)模型中的類(lèi)。這與我們的觀察，參與者對(duì)系統(tǒng)來(lái)說(shuō)常常既是外部的又是內(nèi)部的，是一致的。 業(yè)務(wù)類(lèi)模型示例 例3.3（電話銷(xiāo)售） 考慮電話銷(xiāo)售的問(wèn)題陳述，語(yǔ)境圖和業(yè)務(wù)用例圖，構(gòu)造其業(yè)務(wù)類(lèi)圖。下面的

46、提示可能具有輔助作用的。1.系統(tǒng)強(qiáng)調(diào)的是電話的安排。電話的安排本身是一個(gè)過(guò)程式計(jì)算，即它的解決方案本質(zhì)上是算法式的。而且被安排的電話隊(duì)列和電話的結(jié)果必須存儲(chǔ)在某個(gè)數(shù)據(jù)結(jié)構(gòu)中。2.像上面討論的那樣，關(guān)于參與者的信息可能需要存儲(chǔ)在類(lèi)中。 業(yè)務(wù)類(lèi)模型示例 例3.3（電話銷(xiāo)售） 業(yè)務(wù)類(lèi)模型的第1版如圖3.5所示。這個(gè)圖包含六個(gè)類(lèi)：其中的兩個(gè)類(lèi)（Supporter和Telemarketer）是從業(yè)務(wù)用例模型的參與者導(dǎo)出的。電話安排算法從類(lèi)Supporter中獲取電話號(hào)碼和其他信息，給當(dāng)前有空的Telemarketers中的一個(gè)安排一個(gè)電話。這個(gè)算法最終在系統(tǒng)數(shù)據(jù)庫(kù)中用存儲(chǔ)過(guò)程的形式實(shí)現(xiàn)。 業(yè)務(wù)類(lèi)模型示例

47、 例3.3（電話銷(xiāo)售） 類(lèi)Callscheduled包含當(dāng)前電話的隊(duì)列，包括那些當(dāng)前正在進(jìn)行的。電話結(jié)果記錄在 e中，并被傳播給其他受影響的類(lèi)，如 Campaign Ticket或 SuPPorter。 類(lèi)Campaign包含Campaign Ticket，它能夠擁有多個(gè)Callscheduled。同樣，Supporter和Telemarketer可以有多個(gè)Callscheduled。Callscheduled和 e之間的關(guān)聯(lián)是一對(duì)一的。 3.6需求文檔 需求文檔是需求確定階段的一個(gè)實(shí)實(shí)在在的結(jié)果。大多數(shù)的組織按照預(yù)先定義好的模板產(chǎn)生需求文檔，這個(gè)模板定義了文檔的結(jié)構(gòu)（內(nèi)容表）和風(fēng)格。 需求文

48、檔的主體由需求陳述組成。需求可以被劃分為服務(wù)陳述（常常稱為功能性需求）和約束陳述。服務(wù)陳述還可以進(jìn)一步分為功能需求和數(shù)據(jù)需求。（在文獻(xiàn)中，廣義上的“功能性需求”或窄義上的“功能需求”被交替著使用。按窄義使用時(shí)，它相當(dāng)于我們所說(shuō)的功能需求。） 3.6需求文檔 除了所說(shuō)的需求外，需求文檔還要解決項(xiàng)目的問(wèn)題。通常，項(xiàng)目的問(wèn)題在文檔的開(kāi)頭以及文檔的結(jié)尾都要討論。在文檔的引言部分，項(xiàng)目業(yè)務(wù)的來(lái)龍去脈要討論，包括項(xiàng)目的目的、投入者和主要約束。而在接近于文檔結(jié)束時(shí)，所有項(xiàng)目其他方面的問(wèn)題都要提到，包括日程安排、預(yù)算、風(fēng)險(xiǎn)、提供文檔等。 3.6需求文檔 3.6.l文檔模板 3.6.2項(xiàng)目準(zhǔn)備 3.6.3系統(tǒng)服

49、務(wù) 3.6.4系統(tǒng)約束 3.6.5項(xiàng)目的其他問(wèn)題 3.6.6附錄 3.6.l文檔模板 需求文檔的模板廣泛來(lái)自教科書(shū)、標(biāo)準(zhǔn)化組織（IEEE，ANSI等）、咨詢公司的Web頁(yè)面、軟件工程工具的供應(yīng)商等。在適當(dāng)?shù)臅r(shí)候，每個(gè)組織應(yīng)該開(kāi)發(fā)自己的適合自身組織實(shí)踐、文化所期望的讀者、系統(tǒng)的類(lèi)型等的標(biāo)準(zhǔn)。 需求文檔模板定義了文檔的結(jié)構(gòu)，并給出了關(guān)于文檔中每一節(jié)的內(nèi)容的詳細(xì)指南。這個(gè)指南可以包含內(nèi)容材料、動(dòng)機(jī)、例子和其他方面的考慮。 需求文檔典型的內(nèi)容表 1項(xiàng)目準(zhǔn)備2.系統(tǒng)服務(wù)3系統(tǒng)約束4項(xiàng)目的其他問(wèn)題附錄1項(xiàng)目準(zhǔn)備1.1產(chǎn)品的目的和范圍1.2業(yè)務(wù)語(yǔ)境1.3投入者1.4多種解決方案1.5文檔綜述2.系統(tǒng)服務(wù)2.

50、1系統(tǒng)的范圍2.2功能需求2.3數(shù)據(jù)需求3系統(tǒng)約束 3.1界面需求3.2性能需求3.3安全性需求3.4操作性需求3.5政策和法律需求3.6其他約束4項(xiàng)目的其他問(wèn)題4.1開(kāi)放問(wèn)題4.2初步安排4.3初步預(yù)算附錄術(shù)語(yǔ)表業(yè)務(wù)文檔和表格參考文獻(xiàn) 3.6.2項(xiàng)目準(zhǔn)備 文檔的項(xiàng)目準(zhǔn)備部分主要針對(duì)管理者和決策制定者，這些人不可能仔細(xì)研究整個(gè)文檔。項(xiàng)目的目的和范圍需要在文檔一開(kāi)始緊跟著業(yè)務(wù)語(yǔ)境就清楚地解釋。 需求文檔必須為系統(tǒng)做一個(gè)業(yè)務(wù)用例。特別地，必須涉及所有確立對(duì)系統(tǒng)的需要的系統(tǒng)規(guī)劃階段所作的努力。需求文檔應(yīng)該解釋所提出的系統(tǒng)將對(duì)組織的業(yè)務(wù)目的和目標(biāo)作出什么貢獻(xiàn)。 3.6.2項(xiàng)目準(zhǔn)備 系統(tǒng)的投入者必須被標(biāo)

51、識(shí)，客戶不僅僅是一個(gè)非個(gè)人的部門(mén)或辦公室，這一點(diǎn)是重要的，人員的名字應(yīng)該列出。最后將有一個(gè)人決定所交付的軟件是否是可接受的。 雖然需求文檔應(yīng)該盡可能遠(yuǎn)離技術(shù)方案，但在開(kāi)發(fā)生命期的早期就想好多種解決方案還是重要的。對(duì)任何現(xiàn)成的方案都應(yīng)特別感興趣，買(mǎi)一個(gè)產(chǎn)品比從頭開(kāi)發(fā)總是在業(yè)務(wù)上有好的意義。 3.6.2項(xiàng)目準(zhǔn)備 需求文檔應(yīng)該提供一個(gè)列表，它列出現(xiàn)存的被進(jìn)一步研究后可作為可能的解決方案的軟件包和構(gòu)件。注意，采取一個(gè)現(xiàn)成方案會(huì)改變開(kāi)發(fā)過(guò)程，但它并不支配需求分析與系統(tǒng)設(shè)計(jì)。 最后，在項(xiàng)目準(zhǔn)備這部分內(nèi)容包含一段對(duì)文檔其余部分的綜述是一個(gè)好的想法。這可以促使繁忙的讀者去研究文檔的其他部分，并且它還將有助于對(duì)

52、文檔內(nèi)容的理解。這段綜述還應(yīng)該解釋被開(kāi)發(fā)者嵌在其中的分析和設(shè)計(jì)的方法學(xué)。 3.6.3系統(tǒng)服務(wù) 需求文檔的主要部分被貢獻(xiàn)給了系統(tǒng)服務(wù)的定義，這個(gè)部分很可能占有整個(gè)文檔的一半以上。這也是文檔中包含解決方案的高層模型，需求業(yè)務(wù)模型，僅有的部分。 系統(tǒng)的范圍可以用語(yǔ)境圖來(lái)建模。在解釋語(yǔ)境圖的時(shí)候，所提出的項(xiàng)目的邊界必須被清楚地定義，沒(méi)有這個(gè)定義，項(xiàng)目在范圍擴(kuò)張的要求中將無(wú)法立足。3.6.3系統(tǒng)服務(wù) 功能需求可以用業(yè)務(wù)用例圖來(lái)建模。然而，這個(gè)圖只提供了功能需求的詳細(xì)列表的一個(gè)高層的范圍。像3.4節(jié)討論的那樣，每個(gè)需求必須被標(biāo)識(shí)、分類(lèi)和定義。 數(shù)據(jù)需求可以用業(yè)務(wù)類(lèi)圖來(lái)建模。同功能模型一樣，業(yè)務(wù)類(lèi)圖不是業(yè)務(wù)數(shù)據(jù)結(jié)構(gòu)的完整定義。每個(gè)業(yè)務(wù)類(lèi)需要進(jìn)一步解釋，類(lèi)的屬性內(nèi)容應(yīng)該被描述。標(biāo)識(shí)的類(lèi)屬性必須確定。否則，不可能適于解釋關(guān)聯(lián)。3.6.4系統(tǒng)約束 系統(tǒng)服務(wù)定義系統(tǒng)必須完成什么。系統(tǒng)約束描述系統(tǒng)在完成它的服務(wù)時(shí)怎樣被約束。系統(tǒng)約束的設(shè)立是由于：界面需求。性能需求。安全性需求。