需求分析與系統(tǒng)設計

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

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

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

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

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

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

7、領域專家面談 與領域專家的面談經(jīng)常是一個知識轉換的過程，即對業(yè)務分析員來說是一個學習過程。與客戶的面談就比較復雜了。 客戶可能對他們的需求只有一個模糊的認識，他們也可能不愿意合作或不能夠表達他們的需求，他們還可能提出超出項目預算或不可實現(xiàn)的需求。最后，來自不同客戶的需求還可能發(fā)生沖突。 3.2.1.1與客戶和領域專家面談 面談法有兩種基本形式：結構化的（形式化的）和非結構化的（非形式化的）。結構化面談法需要提前準備，有一個明確的日程，并且許多問題都是預先確定的。有一些問題可以是無確定答案的（對這些問題，其答案無法預計），其他問題可以是有確定答案的（回答從提供的答案中選取）。 3.2.1.1與客

8、戶和領域專家面談 結構化面談法需要非結構化面談法進行補充。非結構化面談法更像非正式的會議，沒有預定的問題或預計的目的。非結構化面談法的目的是鼓勵客戶講出他/她的想法，并且在這個過程中導出業(yè)務分析員沒有想到的和因而沒能提出的相關問題的需求。 結構化和非結構化面談法都必須有某個出發(fā)點和討論的語境，這可以是一篇短的書面文檔，或在解釋面談者目的或提出問題的會議之前發(fā)送給面談對象的email。3.2.1.1與客戶和領域專家面談 一般來說，有三種問題應該避免：固執(zhí)己見的問題。在這種問題中，面談者（直接地或間接地）表達了你她自己關于這個問題的觀點（“我們必須按我們做這件事的方式來做它嗎？”）。帶偏見的問題。

9、它類似于固執(zhí)己見的問題，但面談者的觀點明顯是有偏見的（“我們不做這件事，對嗎？”）。強加的問題。它假設了問題的答案（“你用這種方式做這件事，對嗎？”）。3.2.1.1與客戶和領域專家面談 成功的面談存在許多因素，但也許最重要的是面談者的溝通和人際交流技能。與面談者提出問題和控制面談過程的同時，認真傾聽和保持耐心從而使得面談對象不感到拘束也是同等重要的。為了維持好的人際關系并得到好的反饋，簡單綜述面談的備忘錄應該在一兩天內(nèi)發(fā)給面談對象。 3.2.1.2問卷法 問卷法是從多個客戶中收集信息的有效方法。它一般用來作為面談法的補充形式，而不是要替代它。但有一個例外，就是非常了解的低風險項目。對這種項目

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

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

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

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

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

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

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

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

18、項目的投入者（除了作為JAD領導之外），但應具有很好的業(yè)務領域的知識（但不需要很好的軟件開發(fā)知識）。文書：在計算機上記錄JAD活動的人。這個人應該有快速錄入的技能，應該具備很強的軟件開發(fā)知識。他能夠使用 CASE工具為活動生成文檔，并開發(fā)最初的解決方案模型。客戶（用戶和經(jīng)理）：他們是交流、討論需求、作出決策、批準項目目標等工作的主要的參與者。開發(fā)人員：開發(fā)隊伍中的業(yè)務分析員和其他人員，他們聽得多說得少他們在這個會議上是發(fā)現(xiàn)事實并收集信息，而不是支配這個過程。3.2.2.2聯(lián)合應用開發(fā) JAD利用了群體動力學原理?！敖M協(xié)同”很可能得到問題更好的解決方案。組提高生產(chǎn)力。學得更快、制定更多理智的判斷

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

49、務 3.6.4系統(tǒng)約束 3.6.5項目的其他問題 3.6.6附錄 3.6.l文檔模板 需求文檔的模板廣泛來自教科書、標準化組織（IEEE，ANSI等）、咨詢公司的Web頁面、軟件工程工具的供應商等。在適當?shù)臅r候，每個組織應該開發(fā)自己的適合自身組織實踐、文化所期望的讀者、系統(tǒng)的類型等的標準。 需求文檔模板定義了文檔的結構，并給出了關于文檔中每一節(jié)的內(nèi)容的詳細指南。這個指南可以包含內(nèi)容材料、動機、例子和其他方面的考慮。 需求文檔典型的內(nèi)容表 1項目準備2.系統(tǒng)服務3系統(tǒng)約束4項目的其他問題附錄1項目準備1.1產(chǎn)品的目的和范圍1.2業(yè)務語境1.3投入者1.4多種解決方案1.5文檔綜述2.系統(tǒng)服務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項目的其他問題4.1開放問題4.2初步安排4.3初步預算附錄術語表業(yè)務文檔和表格參考文獻 3.6.2項目準備 文檔的項目準備部分主要針對管理者和決策制定者，這些人不可能仔細研究整個文檔。項目的目的和范圍需要在文檔一開始緊跟著業(yè)務語境就清楚地解釋。 需求文檔必須為系統(tǒng)做一個業(yè)務用例。特別地，必須涉及所有確立對系統(tǒng)的需要的系統(tǒng)規(guī)劃階段所作的努力。需求文檔應該解釋所提出的系統(tǒng)將對組織的業(yè)務目的和目標作出什么貢獻。 3.6.2項目準備 系統(tǒng)的投入者必須被標

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

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