用戶需求說明書的編寫指引

用戶需求說明書

編寫指南

用戶需求說明書編寫指南文檔修訂記錄版本編號或者更改記錄編號變化狀態(tài)簡要說明（變更內(nèi)容和變更范圍）日期變更人批準(zhǔn)日期批準(zhǔn)人V1.0C初次創(chuàng)建2010-11-05張海彥V1.1A對文檔內(nèi)容進行重新維護，形成V1.1版本2015-04-24趙景越*變化狀態(tài)：C——創(chuàng)建，A——增加，M——修改，D——刪除用戶需求說明書編寫指南目錄TOC\o"1-5"\h\z\o"CurrentDocument".確定系統(tǒng)邊界 1目的 1\o"CurrentDocument"確定執(zhí)行者 1\o"CurrentDocument"確定用例 1\o"CurrentDocument"描述執(zhí)行者和用例 2\o"CurrentDocument"處理時間 2\o"CurrentDocument"潛在的邊界問題 3確定項目范圍 3\o"CurrentDocument"邊界和范圍的圖形化 3\o"CurrentDocument".編寫基本用例 4\o"CurrentDocument"基本用例 4進入與退出標(biāo)準(zhǔn) 5事件流 5\o"CurrentDocument"基本用例的評審 5\o"CurrentDocument"表示形式 6\o"CurrentDocument"其他需求 7\o"CurrentDocument"基本路徑 7\o"CurrentDocument"可選路徑 7\o"CurrentDocument"文檔化可選項 8\o"CurrentDocument"場景 12\o"CurrentDocument"關(guān)聯(lián)用例和執(zhí)行者 12\o"CurrentDocument". 高級用例 12\o"CurrentDocument"包含 12擴展 14\o"CurrentDocument"繼承 14\o"CurrentDocument"接口 15\o"CurrentDocument".圖形化用例 15\o"CurrentDocument"活動圖 16\o"CurrentDocument"時序圖 17\o"CurrentDocument".圖解用戶界面 18\o"CurrentDocument".常見錯誤 18用戶需求說明書編寫指南1,確定系統(tǒng)邊界目的將項目的參與者定位到一個共同的和明確的方向上。確定系統(tǒng)中有什么（必須為創(chuàng)建他們投入大量精力），系統(tǒng)外有什么（不需要創(chuàng)建，但是必須考慮與它們的接口）。估計項目規(guī)模，定義要創(chuàng)建系統(tǒng)的哪些部分（在一定時間段和一定預(yù)算的基礎(chǔ)上。確定執(zhí)行者我們將采用用例分析技術(shù)，通過確定執(zhí)行者和用例來確定系統(tǒng)邊界。在一些參考資料中，我們會經(jīng)?？吹健巴獠繉嶓w”這個術(shù)語，我們認(rèn)為外部實體和執(zhí)行者具有同樣的含義。執(zhí)行者是同系統(tǒng)交互的事物，包括人、其它軟件、硬件設(shè)備、數(shù)據(jù)存儲或者網(wǎng)絡(luò)。每個執(zhí)行者定義一種特定的角色，每個系統(tǒng)之外的實體可以用一個或多個執(zhí)行者來代表。執(zhí)行者總是在系統(tǒng)之外，不是系統(tǒng)的一部分。提出下列問題會幫助分析員確定執(zhí)行者：>誰使用這個系統(tǒng)？>誰安裝這個系統(tǒng)？誰啟動系統(tǒng)？誰維護系統(tǒng)？誰關(guān)閉系統(tǒng)？哪些其它的系統(tǒng)使用這個系統(tǒng)？誰從這個系統(tǒng)獲取信息？誰為這個系統(tǒng)提供信息？是否有事情自動在預(yù)計的時間發(fā)生？1.3確定用例用例是系統(tǒng)的一種行為，它為執(zhí)行者產(chǎn)生一種可以估量的價值結(jié)果，它描述執(zhí)行者想要系統(tǒng)完成的事情。從執(zhí)行者的角度看，用例應(yīng)該是一個完整的任務(wù)，一個用例行為經(jīng)常是在一個相對較短的時間段內(nèi)完成。如果用例的各部分被分在不同的時間段，尤其是被不同的執(zhí)行者執(zhí)行時，最好還是將各部分作為單獨的用例對待。用例通常由執(zhí)行者啟動，所以我們可以從執(zhí)行者角度出發(fā)，判斷有哪些用例?？紤]以下問題：執(zhí)行者希望系統(tǒng)提供什么樣的功能？系統(tǒng)存儲信息嗎？執(zhí)行者將要創(chuàng)建、讀取、更新或刪除什么信息？系統(tǒng)是否需要把自身內(nèi)部狀態(tài)的變化通知給執(zhí)行者？系統(tǒng)必須知道哪些外部的事件？執(zhí)行者將怎樣通知系統(tǒng)這些事件？用戶需求說明書編寫指南>怎樣修復(fù)系統(tǒng)？是否需要把系統(tǒng)關(guān)閉或者在系統(tǒng)運行的情況下進行系統(tǒng)維護？描述執(zhí)行者和用例用一個名字和簡單的話描述每個執(zhí)行者和用例。建議采用“執(zhí)行者列表”和“用例表”分別描述執(zhí)行者和用例。表1 執(zhí)行者列表執(zhí)行者名稱執(zhí)行者描述客戶代表ABC公司處理客戶請求的雇員客戶從ABC公司訂購商品的人表2用例表用例觸發(fā)器來源動作響應(yīng)目的地客戶發(fā)送訂單新訂單客戶生成新訂單實時連接信用卡部門訂單確認(rèn)客戶訂單細(xì)節(jié)發(fā)貨部門交易處理銀行用例：引起系統(tǒng)去執(zhí)行某種操作的事情；觸發(fā)器：系統(tǒng)如何知道這個用例發(fā)生了？或者是進入系統(tǒng)的數(shù)據(jù)，或者是定義好的時間點。來源：執(zhí)行者；動作：當(dāng)用例發(fā)生時，系統(tǒng)做了什么操作？響應(yīng)：系統(tǒng)產(chǎn)生了什么樣的輸出結(jié)果（如果有的話）？目的地：哪個執(zhí)行者獲得了產(chǎn)生的輸出結(jié)果？首先，對每個用例來說，系統(tǒng)怎么知道某一事件發(fā)生了呢？用來通知系統(tǒng)某一事件發(fā)生了的事物稱為觸發(fā)器。對于一個外部事件，觸發(fā)器就是系統(tǒng)必須處理的數(shù)據(jù)到達了。對于臨時事件，觸發(fā)器是某一個時間點。其次，當(dāng)用例發(fā)生時，系統(tǒng)該做些什么呢？系統(tǒng)對用例的響應(yīng)稱為動作。最后，動作導(dǎo)致系統(tǒng)產(chǎn)生什么響應(yīng)呢？響應(yīng)是系統(tǒng)的輸出結(jié)果。一個動作通常會有多個響應(yīng)。目的地就是系統(tǒng)發(fā)送響應(yīng)的地方，也就是執(zhí)行者。注意，有些時候不需要系統(tǒng)響應(yīng)。處理時間在用例中主要用兩種方法來處理時間。一個方法是把時間當(dāng)作一個執(zhí)行者，然后由時間執(zhí)行者啟動用例。第二種方法是把它當(dāng)作系統(tǒng)的一部分，用例在某個時間自己啟動。2

用戶需求說明書編寫指南用戶需求說明書編寫指南潛在的邊界問題如果某些需求需要一個執(zhí)行者來處理，但是這個執(zhí)行者又超出了已經(jīng)確定的執(zhí)行者的范圍，怎么辦？需要確定這個執(zhí)行者是否真的是系統(tǒng)的一部分。如果不是，那么需求也就不能成為系統(tǒng)的一部分；如果是，那么看一看對它的描述，可能需要重新定義執(zhí)行者或者它的角色以使系統(tǒng)邊界清晰。如果執(zhí)行者變成系統(tǒng)的一部分，可能需要重新定義用例。當(dāng)你發(fā)現(xiàn)新的需求時，應(yīng)該考慮的一些問題如下：這些需求是否對系統(tǒng)是必須的？這些需求是系統(tǒng)在邏輯上可以完成的嗎？新的需求將如何影響我們目前的風(fēng)險分析？這些需求是否可以被系統(tǒng)目前的執(zhí)行者處理？這些需求是客戶希望系統(tǒng)去做的嗎？這些需求會使產(chǎn)品在市場上變得與眾不同嗎？1.7確定項目范1.7確定項目范確定了系統(tǒng)的邊界之后，需要為系統(tǒng)確定一個范圍。一個項目有特定的開始和結(jié)束的時間，用于完成項目目標(biāo)的資金也有一定的限制。所以，一定要清晰地定義系統(tǒng)將要包括和不包括的成分。使用需求優(yōu)先級的方法確定系統(tǒng)必須包含的事情，并確定沒有必要的事情確實被放在了一邊。建立了用例表以后，系統(tǒng)分析員可以和用戶進一步溝通協(xié)商，也可以召開聯(lián)系會議，確定列表中的用例哪些是在項目范圍以內(nèi)的，哪些是項目范圍以外的?？紤]下列問題有助于確定下面的范圍：是否能夠應(yīng)付得了把這些需求添加到計劃和預(yù)算上去？是否應(yīng)該再有一個后期的版本？如果我們不得不現(xiàn)在考慮這些，是否可以把其它需求移到后期版本？1.8邊界和范圍的圖形化1.8邊界和范圍的圖形化使用用例圖，描述項目的邊界和范圍?？梢杂肰isio畫用例圖。下面是用例圖用到的圖形符號圖1 用例的圖形符號主角1系統(tǒng)邊界接口1執(zhí)行者用例接口擴展包含

主角1系統(tǒng)邊界接口1執(zhí)行者用例接口擴展包含用戶需求說明書編寫指南下面是一個“訂單處理系統(tǒng)”的邊界和范圍圖，本文后續(xù)的部分，都將以“訂單處理系統(tǒng)”為例子。需要注意的是，千萬不要認(rèn)為有了用例圖，就可以不寫文檔了。事實上，圖形僅僅是更直觀地表現(xiàn)用戶需求的一種方式，文字描述還是必不可少的。我們建議采用的文字描述方式還是上文提到的“用例列表”。2,編寫基本用例2.1基本用例每個用例必須包含一些細(xì)節(jié)，這些細(xì)節(jié)告訴我們需要完成哪些步驟才能實現(xiàn)這個用例的功能。我們需要考慮基本功能、所有可選方案、異常情況，進入用例之前以及退出用例時必須正確的因素。用例可以包含條件、分支和循環(huán)?，F(xiàn)在讓我們看一個可能的用例例子：訂單處理系統(tǒng)。表3 訂單處理系統(tǒng)的用例

用戶需求說明書編寫指南進入標(biāo)準(zhǔn)：一個合法的用戶已經(jīng)登錄到這個系統(tǒng)；事件流：.當(dāng)客戶選擇訂購貨物時，用例開始；.客戶輸入他的姓名和地址；.如果客戶只輸入郵編，系統(tǒng)將給出城市名；.客戶輸入想購買產(chǎn)品的代碼；.系統(tǒng)為每一項給出產(chǎn)品描述和價格；.系統(tǒng)保存連續(xù)的已經(jīng)訂購的產(chǎn)品清單；.客戶輸入信用卡支付信息；.客戶選擇submit；.系統(tǒng)檢驗輸入的信息，把該訂單作為未完成的交易保存，同時向記賬系統(tǒng)轉(zhuǎn)發(fā)支付信息。如果客戶提交的信息不正確，系統(tǒng)將提示客戶修改；.當(dāng)支付確認(rèn)后，訂單就被標(biāo)記上已經(jīng)確認(rèn)，同時返回給用戶一個訂單ID，用例結(jié)束。如果支付沒有被確認(rèn)，系統(tǒng)將提示客戶改正支付信息或者取消。如果客戶選擇修改信息，就回到第7步；如果選擇取消，用例結(jié)束。退出標(biāo)準(zhǔn)：如果訂單沒有被取消，它將被保存在系統(tǒng)里，并做上標(biāo)記。2.1.1進入與退出標(biāo)準(zhǔn)2.1.1進入與退出標(biāo)準(zhǔn)進入與退出標(biāo)準(zhǔn)表示用例開始和結(jié)束時會發(fā)生什么，即在用例開始時系統(tǒng)必須處在什么狀態(tài)，用例結(jié)束時系統(tǒng)必須處在什么狀態(tài)。不管緊隨用例之后是哪個分支或選擇，退出標(biāo)準(zhǔn)都必須為真。2.1.2事件流從執(zhí)行者的角度看，事件流是一系列陳述句，它列出了用例的各個步驟：告訴我們它如何開始，使用一個像“當(dāng)……時用例開始”的描述。用例是為軟件做的，軟件如何知道什么時候用例開始？同樣地，用例如何結(jié)束？可以使用如“用例結(jié)束”的短語清晰地陳述它。使用分支可以表示選擇。為了表示分支，我們可以使用一個if語句。當(dāng)需要重復(fù)一個或一系列步驟時，可以使用循環(huán)。要清晰地指出循環(huán)在哪兒開始以及在哪兒結(jié)束，還要清楚地指出如何結(jié)束。我們可以使用for語句或者while語句來表示循環(huán)?；居美脑u審用例的編寫過程中需要進行多次評審，基本用例結(jié)束之后，是最佳的評審時間。我們給出首次評審用例的基本原則。用戶需求說明書編寫指南用例的每一步都應(yīng)該是一個簡單的陳述句，缺省時這些步驟按時間順序執(zhí)行。如果這些步驟可以按任何順序發(fā)生，需要清晰地描述。避免試圖做得太細(xì)，我們將隨著時間的推進添加更多的細(xì)節(jié)，但是這一階段，我們是在收集需求，而不是詳細(xì)分析或設(shè)計。另一方面，用例還要完整，開始和結(jié)束時都必須非常清楚，確保這一系列的步驟大體上包含了完成用例功能所需要的一切。>用例是一個傳達工具，只有它們向讀者傳達關(guān)于系統(tǒng)如何工作的信息時才有效。因此考慮誰會閱讀用例是很重要的，是最終用戶、市場專家、開發(fā)人員還是管理人員？不管是誰，他們必須能夠理解用例。如果他們不能理解用例，這個用例就需要改寫了。不要擔(dān)心如何才能使用例完美，這個過程的特征就是不斷反復(fù)。要持續(xù)查看已經(jīng)完成的工作，并且精簡它，以反映了解到的情況。用例質(zhì)量會隨著分析員對系統(tǒng)了解的深入而提高。必須在用例中包含足夠的信息，以判斷是不是用了特定的用例處理了特定的功能。表示形式可以非常正式地或者較自由地表示用例，但要清楚用例的讀者，從而選擇一個易于被讀者接受的形式。我們推薦了兩種形式，項目經(jīng)理可以從中選擇。一種是用編號序列來表示用例（表4），另一種是用表格形式表示（表5）。表4取消訂單用例的編號序列表示.當(dāng)客戶收到取消訂單的請求時，用例開始；.客戶代表輸入一個訂單ID；.客戶代表按下“查找”；.系統(tǒng)顯示這個訂單的內(nèi)容；.客戶代表選擇取消；.系統(tǒng)將該訂單做上取消標(biāo)志；.記賬系統(tǒng)收到向客戶賬號中加錢的通知，用例結(jié)束。表5取消訂單用例的表格形式客戶代表系統(tǒng)記賬系統(tǒng).接收到一個取消訂單的請求.輸入一個訂單ID；.按下“查找”用戶需求說明書編寫指南5.選擇取消4.顯示訂單內(nèi)容6.給該訂單打上取消標(biāo)志7.向客戶賬號中加錢其他需求分析員編寫用例的時候，可能會發(fā)現(xiàn)一些需求對執(zhí)行者并不可見，或者有一些特殊的需求很難在用例中表示。這些需求需要和用例一起記錄下來，它們同樣是系統(tǒng)的一個組成部分。當(dāng)構(gòu)建和測試系統(tǒng)時，必須將它們考慮進去。你可以將它們歸到其他的需求文檔，這些文檔和用例文檔編排在一起。有時這些需求是非功能性的需求，如可用性、安全性、穩(wěn)定性、可維護性等方面的內(nèi)容。如果需求是針對一個特殊的用例，可以在用例描述中添加一個專門的需求部分：“特殊需求”。其他文檔常常是伴隨用例開發(fā)出來的，這些文檔包含一個術(shù)語表、一個數(shù)據(jù)定義文檔以及用戶接口的指導(dǎo)原則。還需要一個文檔，它列出了需要解決的重要問題。到目前為止，我們已經(jīng)確定了用例的基本路徑。但是一個完整的用例描述可能相當(dāng)復(fù)雜，并不像最開始時所寫的那樣，它會隨著時間的推移不斷發(fā)展?；韭窂接美幕臼录鞔_定了以后，還要考慮所有可能的出錯條件。一個完整的用例描述可能相當(dāng)復(fù)雜，它是隨著時間的推移不斷發(fā)展的。事件流分為兩個部分：基本路徑和可選路徑。當(dāng)一切運轉(zhuǎn)正常時我們就得到了基本路徑。沒有故障、沒有錯誤，是一個完美的境界。每個用例都必須有一個基本路徑。可選路徑基本路徑確定了之后，就要擴充可選路徑。一個可選路徑指的是不同于基本路徑而允許不同的事件序列的路徑?？蛻艨梢詮挠美娜舾墒虑橹刑暨x一件事情來做，最可能的選擇歸入基本路徑。對于明顯有可能隨時發(fā)生的事情來說，可選路徑非常有效。找出可選路徑的方法就是沿著基本路徑一條一條地找，并且考慮：在這個點上，還可以執(zhí)行別的活動嗎？在這個點上，有沒有什么可以出錯的？有什么隨時可能發(fā)生的行為嗎？用戶需求說明書編寫指南另一種方法就是用以下典型問題去發(fā)現(xiàn)可選路徑：＞執(zhí)行者退出應(yīng)用程序；＞執(zhí)行者取消指定操作；＞執(zhí)行者請求幫助；＞執(zhí)行者提供了不正確的數(shù)據(jù)；＞執(zhí)行者提供了不完整的數(shù)據(jù)；＞執(zhí)行者提供了一個執(zhí)行用例的可選方法；＞系統(tǒng)崩潰；＞系統(tǒng)不可用。每個可選路徑需要一個名字或一個簡單的描述，如表6所示。表6 通過分類訂購貨物附加的可選項不完整的數(shù)據(jù)沒有付費；訂單不完整；運送地址不完整不正確的數(shù)據(jù)密碼錯誤、用戶名錯誤、產(chǎn)品代碼錯誤、無效支付?？蛇x行為客戶通過支票付款、客戶通過發(fā)郵件或電話訂購。取消操作客戶取消這次訂購系統(tǒng)崩潰系統(tǒng)在訂購過程中崩潰系統(tǒng)不可用系統(tǒng)沒有響應(yīng)、客戶不能登錄、訂單丟失對于每個基本路徑，簡單地列出所有你能夠想到的可選路徑和異常情況。識別出可選路徑和異常后，用新的假設(shè)更新假設(shè)列表。這張列表將在評審時提交給由用戶、客戶、市場人員組成的評委。文檔化可選項重要而復(fù)雜的可選路徑還需要一系列步驟去細(xì)化它們的行為，可以用寫基本路徑的方法去寫可選路徑。我們將用訂購貨物用例基本路徑，使用不同的方法調(diào)整它，從多方面說明此類技術(shù)，并且討論每種技術(shù)的優(yōu)缺點。表7 原來的訂購貨物用例事件流：基本路徑：.當(dāng)客戶選擇訂購貨物時用例開始；.客戶輸入他的姓名和地址；.當(dāng)客戶輸入產(chǎn)品代碼a）系統(tǒng)顯示產(chǎn)品描述和價格；用戶需求說明書編寫指南b）系統(tǒng)在該客戶的訂單中添加這個物品的價格.客戶輸入信用卡支付信息；.客戶選擇submit；.系統(tǒng)檢驗輸入的信息，把該訂單作為未完成的交易保存，同時向記賬系統(tǒng)提供支付信息;.當(dāng)支付被確認(rèn)后，訂單也被標(biāo)記上已經(jīng)確認(rèn)，同時返回給客戶一個訂單ID，用例結(jié)束。第一個技術(shù)是直接往用例文本中添加可選項，適當(dāng)?shù)靥砑有碌臉?biāo)號步驟。這個技術(shù)的優(yōu)點是可以非常容易地看到用例中可能的行為，缺點是它會導(dǎo)致用例難以理解和閱讀。添加的內(nèi)容以藍色字體表示。（表7）。表7 添加可選項的訂購貨物用例事件流：基本路徑：.當(dāng)客戶選擇訂購貨物時用例開始；.客戶輸入他的姓名和地址；.如果客戶只輸入郵編，系統(tǒng)給出城市。.客戶輸入將要訂購產(chǎn)品的代碼.對每個輸入的代碼a）如果系統(tǒng)中有該產(chǎn)品代碼，系統(tǒng)提供該產(chǎn)品的介紹和價格，并在該客戶的訂單中添加這個物品的價格。b）如果系統(tǒng)中沒有這個產(chǎn)品代碼則打印出錯信息，提示客戶輸入新的產(chǎn)品代碼。.客戶輸入信用卡支付信息；.客戶選擇submit；.系統(tǒng)核查支付信息.如果所有的信息都正確，用例就從第13步繼續(xù)執(zhí)行.如果客戶沒有輸入支付信息，系統(tǒng)提示客戶輸入支付信息或取消.如果客戶選擇取消，用例結(jié)束.如果客戶輸入新的支付信息并選擇submit，用例從第8步開始重復(fù).系統(tǒng)把該訂單作為未完成的交易保存，同時向記賬系統(tǒng)提供支付信息；.如果記賬系統(tǒng)確認(rèn)支付信息正確，訂單被標(biāo)上已經(jīng)確認(rèn)，一個訂單ID就返回給客戶，用例結(jié)束。.如果記賬系統(tǒng)返回錯誤，系統(tǒng)就打印出錯信息，提示客戶輸入新的支付信息或者取消；.如果客戶選擇取消，用例結(jié)束；.如果客戶選擇輸入新的支付信息，用例從第6步開始重復(fù)。用戶需求說明書編寫指南第二個技術(shù)是在原來的基礎(chǔ)上，在段落中增加可選項。這比前面的例子更易于閱讀，而以前的步驟成為這個用例的基本理解的標(biāo)題，可選項細(xì)節(jié)和錯誤處理成為編號步驟的下級段落。這種方式不改變原來的步驟編號。（表8）。表8 在段落中添加可選項的訂購貨物用例事件流：基本路徑：.當(dāng)客戶選擇訂購貨物時用例開始；.客戶輸入他的姓名和地址；如果客戶只輸入郵編，系統(tǒng)提供城市。.客戶輸入產(chǎn)品代碼.對每個輸入的產(chǎn)品代碼a）系統(tǒng)給出該產(chǎn)品的介紹和價格。如果系統(tǒng)中沒有這個產(chǎn)品代碼則顯示出錯信息，提示客戶輸入新的產(chǎn)品代碼。b）系統(tǒng)在該客戶的訂單中添加這個物品的價格若物品未找到，訂單保持不變；循環(huán)結(jié)束。.客戶輸入信用卡支付信息；.客戶選擇submit；.系統(tǒng)檢驗輸入的信息，把該訂單作為未完成的交易保存，同時向記賬系統(tǒng)提供支付信息；如果客戶沒有輸入支付信息，系統(tǒng)將提示客戶輸入支付信息或取消；如果客戶選擇取消，用例結(jié)束。入客戶輸入新的支付信息，客戶選擇submit，用例從第7步重復(fù)。.當(dāng)支付被確認(rèn)后，訂單也被標(biāo)記上已經(jīng)確認(rèn)，同時返回給客戶一個訂單ID，用例結(jié)束。如果記賬系統(tǒng)返回錯誤，系統(tǒng)打印出錯信息，提示客戶輸入新的支付信息或者取消。如果客戶選擇取消，用例結(jié)束。如果客戶選擇輸入新的支付信息，用例從第5步重復(fù)。第三個技術(shù)是把可選項放在用例文檔的其他部分，這個部分稱為可選路徑部分，它緊接著基本路徑（表9）。這個方法的優(yōu)點是基本路徑很容易理解，同時又有足夠的空間來展示可選項的細(xì)節(jié)。但是缺點是查找關(guān)于每一可選項的所有信息時，必須瀏覽好幾頁文檔。表9 使用可選路徑部分的訂購貨物用例事件流：基本路徑：.當(dāng)客戶選擇訂購貨物時用例開始；.客戶輸入他的姓名和地址；.客戶輸入產(chǎn)品代碼.對每個輸入的產(chǎn)品代碼10用戶需求說明書編寫指南c）系統(tǒng)顯示產(chǎn)品描述和價格；d）系統(tǒng)在該客戶的訂單中添加這個物品的價格.客戶輸入信用卡支付信息；.客戶選擇submit；.系統(tǒng)檢驗輸入的信息，把該訂單作為未完成的交易保存，同時向記賬系統(tǒng)提供支付信息;.當(dāng)支付被確認(rèn)后，訂單也被標(biāo)記上已經(jīng)確認(rèn)，同時返回給客戶一個訂單ID，用例結(jié)束?？蛇x路徑：在第7步，如果有任何不正確的信息，系統(tǒng)提示客戶修改這些信息；在選擇submit之前的任何時候，客戶可以取消這次訂購，用例結(jié)束；在第8步，如果支付沒有確認(rèn)，系統(tǒng)將提示客戶去修正支付信息或取消。如果客戶選擇修正信息，就回到基本路徑的第5步，否則用例結(jié)束。表9中的可選項部分可以用與基本路徑相同的方式書寫，見表10。事件流：基本路徑：.當(dāng)客戶選擇訂購貨物時用例開始；.如果客戶只輸入郵編，系統(tǒng)提供城市。.客戶輸入他的姓名和地址；.客戶輸入產(chǎn)品代碼.對每個輸入的產(chǎn)品代碼e）系統(tǒng)顯示產(chǎn)品描述和價格；f）系統(tǒng)在該客戶的訂單中添加這個物品的價格循環(huán)結(jié)束。.客戶輸入信用卡支付信息；.客戶選擇submit；.系統(tǒng)檢驗輸入的信息，把該訂單作為未完成的交易保存，同時向記賬系統(tǒng)提供支付信息;.當(dāng)支付被確認(rèn)后，訂單也被標(biāo)記上已經(jīng)確認(rèn)，同時返回給客戶一個訂單ID，用例結(jié)束?？蛇x路徑：可選項1：不正確的數(shù)據(jù).如果有任何不正確的信息，可選項就從基本路徑的第8步開始；.系統(tǒng)提示客戶修正錯誤的信息；.基本路徑從第8不開始繼續(xù)執(zhí)行?？蛇x項2：取消.在訂購貨物用例的任何時候，客戶都可能選擇取消；.系統(tǒng)提示客戶驗證是否取消；11

用戶需求說明書編寫指南.客戶選擇“OK”鍵，用例結(jié)束。可選路徑細(xì)化到什么程度？很多情況下，不必寫下整個的步驟序列，只需要用簡潔的話描述可選路徑引起的變動。.8場景任意一條貫穿用例的特定路徑，我們稱為場景。上述訂購貨物的用例中，包括的場景有一個正確付款的完整的賬單到達；缺少支付的訂單到達；缺少送貨地址的訂單到達。.9關(guān)聯(lián)用例和執(zhí)行者我們已經(jīng)把用例的細(xì)節(jié)寫出來了，知道誰開始用例一一執(zhí)行者，但是我們還沒有考慮如何以圖示的形式表示執(zhí)行者和用例之間的關(guān)系。它們之間的關(guān)系是通過通信關(guān)聯(lián)表示的，啟動方向是通過在通信關(guān)聯(lián)中添加箭頭實現(xiàn)的。我們用例子來說明，見圖3和圖4。由系統(tǒng)啟動的獲得訂單狀態(tài)用例由客戶啟動訂購貨物用例客戶由系統(tǒng)啟動的獲得訂單狀態(tài)用例由客戶啟動訂購貨物用例客戶3.高級用例開發(fā)了基本用例之后，系統(tǒng)分析員可能會發(fā)現(xiàn)有必要對基本用例進行優(yōu)化。用于優(yōu)化的技術(shù)有包含、擴展、繼承和接口。然而，我們的目的是制作一個清楚易懂的文檔。因此，對于最終用戶，唯一的優(yōu)化技術(shù)是包含（Include）。其它技術(shù)擴展（Extend）、接口（1成0f2?6）和繼承（Inheritance）只是開發(fā)人員感興趣的，不是最終用戶關(guān)心的。包含如果你發(fā)現(xiàn)自己經(jīng)常裁剪或粘貼同一部分內(nèi)容，就意味著你已經(jīng)有了可以重用的通用部分了，你可以用一種包含關(guān)系來抽象這種通用行為。從定義一個你在很多地方都需要用到的12用戶需求說明書編寫指南步驟開始，把這些步驟放在一個用例里，然后給它命名。比如在訂單處理系統(tǒng)中，通過客戶ID、訂單ID和客戶名等一系列步驟來搜索一個訂單，這種搜索需要在很多的用例中用到，包括獲得訂單狀態(tài)、取消訂單、退貨等等，我們稱這個用例為搜索訂單?，F(xiàn)在從原始用例中抽出這些步驟，把它們替換成一個引用，指向新構(gòu)成的用例（表11）。表11搜索訂單用例.當(dāng)客戶鍵入訂單ID、客戶ID或者客戶名時，用例開始；.客戶點擊Find；.如果客戶鍵入訂單IDa）系統(tǒng)顯示訂單，用例結(jié)束.如果客戶鍵入客戶名或者客戶IDa）系統(tǒng)返回當(dāng)前客戶的所有訂單表b）客戶在這個列表中選擇一個訂單c）系統(tǒng)顯示這個訂單，然后用例結(jié)束。表12 有包含關(guān)系的取消訂單用例.客戶鍵入請求取消一個訂單，用例開始.包含搜索訂單；.如果這個訂單狀態(tài)被確認(rèn)a）系統(tǒng)標(biāo)志訂單取消b）系統(tǒng)通知記賬系統(tǒng)向客戶賬號中加錢，用例結(jié)束；.如果訂單狀態(tài)是已運送a）系統(tǒng)通知發(fā)貨部門，用例結(jié)束。當(dāng)取消訂單用例執(zhí)行到搜索訂單步驟的時候，就會執(zhí)行搜索訂單中的步驟，然后返回到取消訂單繼續(xù)執(zhí)行以下的步驟。用例圖的表示方法如下（圖5）：13用戶需求說明書編寫指南圖5圖5.2擴展擴展一般用于有條件地擴展已有用例的行為，這是一種在不改變原始用例的情況下增加用例行為的一種方法。因為擴展技術(shù)不是必不可少的，我們建議系統(tǒng)分析員盡量不使用。.3繼承在用例圖中，繼承可以在執(zhí)行者或者用例之間使用。繼承是一個“種屬”關(guān)系，其中一個元素是其它元素的一種。執(zhí)行者之間的繼承意味著一個執(zhí)行者可以完成另一個執(zhí)行者的同樣任務(wù)，它也補充額外的角色，它以同樣的方式與相同的用例進行交互。用例之間的繼承意味著一個用例是另一個用例的特殊的版本。這個特殊的用例從一個通用用例中繼承行為或者增加行為?？匆幌略谟唵翁幚硐到y(tǒng)中（圖2）的一個簡單例子?？蛻艉涂蛻舸碛邢嗤呐c之進行交互的用例集合。我們通過加入執(zhí)行者之間的繼承可以使得用例圖大為簡化。見圖6?？蛻舸鞸aleReport圖614

客戶代表SaleReport圖614用戶需求說明書編寫指南.4接口接口是為執(zhí)行者、用例或者兩者定義的。一個接口可以告訴我們希望實體做什么。接口不是執(zhí)行者或者用例的一部分，是對怎么樣與執(zhí)行者和用例交互的一種描述。你可以為任何執(zhí)行者和用例設(shè)置多個接口。第一步：定義接口。接口由名字和操作符號組成，一個操作符號告訴我們操作發(fā)生時傳輸何種數(shù)據(jù)以及在操作結(jié)束時將何種數(shù)據(jù)返回給我們，操作告訴我們希望實體做什么。還是考慮訂購貨物的例子，我們發(fā)現(xiàn)從庫存系統(tǒng)中得到產(chǎn)品描述和價格是必需的，我們?yōu)閹齑嫦到y(tǒng)定義接口如下：表13接口的例子PRODUCTINFO接口得到產(chǎn)品描述和價格，返回產(chǎn)品描述、價格、庫存數(shù)量第二步，把它們加到用例圖中。執(zhí)行者和接口之間直線的意思是執(zhí)行者支持接口；虛線表示使用這個接口的用例，見圖7。庫存系統(tǒng)庫存系統(tǒng)圖7如果執(zhí)行者不是人，那么這個接口將是一段程序命令，用它來與執(zhí)行者進行交互。比如，如果執(zhí)行者是一個網(wǎng)絡(luò)，接口可能是TCP/IP命令。如果執(zhí)行者是與訂單處理系統(tǒng)相交互的庫存系統(tǒng)，就需要找出什么樣的命令可以發(fā)送到庫存系統(tǒng)，這些命令將到庫存系統(tǒng)執(zhí)行者的接口。使用接口技術(shù)的最主要目的主要是兩個問題，一個是建立用例和人機界面的聯(lián)系，一個是確定用例使用到的數(shù)據(jù)。有關(guān)繼承、接口、擴展的更進一步細(xì)節(jié)可以參考相關(guān)的文獻。.圖形化用例15

用戶需求說明書編寫指南我們已經(jīng)花了很多時間為用例書寫文本，但是，大家都知道，一幅圖表示的意思勝似千言萬語，所以我們建議適當(dāng)?shù)臅r候采用圖形的方式對用例進行描述。所謂適當(dāng)?shù)臅r候，指的是以下兩種情況。一種是系統(tǒng)分析員理解用戶的需求，但是不能準(zhǔn)確地用文字描述，可以借助圖形描述；另一種情況是不完全理解用戶的需求，可以借助圖形進一步與用戶進行溝通。圖形化的方式很多，典型的有活動圖和時序圖。這兩種圖各有千秋，由項目經(jīng)理根據(jù)項目的特點進行選擇，也可以混合使用?；顒訄D活動圖類似于流程圖