【正文】 確定行為者 ? 確定用例 確定行為者 ? 行為者： ? 與系統(tǒng)交互的人或其他系統(tǒng) ? 交互：發(fā)送、接收、交換信息 ? 行為者執(zhí)行用例 ? 行為者是一個(gè)角色，而不是具體個(gè)人 ? 尋找行為者 ? 誰使用系統(tǒng)的功能 ? 誰需要系統(tǒng)提供信息 ? 誰維護(hù)、管理、控制系統(tǒng) ? 系統(tǒng)完成功能還需要得到其他系統(tǒng)的支持 ? 還有哪些人對(duì)系統(tǒng)的結(jié)果感興趣 業(yè)務(wù)用例 – 銀行 確定用例 ?一個(gè)用例是被行為者感受到的一個(gè)完整的功能 UML的定義：用例是給一個(gè)特定行為者的一個(gè)可觀察的結(jié)果值的系統(tǒng)所完成的一系列動(dòng)作 這個(gè)動(dòng)作除計(jì)算機(jī)內(nèi)部完成的計(jì)算外，還包括與行為者的信息交互 用例通過關(guān)聯(lián)與行為者進(jìn)行交互 用例總是被行為者所啟動(dòng)，并回答一個(gè)可識(shí)別的結(jié)果 類似于對(duì)象是類的實(shí)例，用例的實(shí)例是場(chǎng)景（ scenario）。 ? 用例 描述了系統(tǒng)的行為 ， 包括行為者和系統(tǒng)之間的交互以及系統(tǒng)與系統(tǒng)之間的交互 。演示了人們?nèi)绾问褂孟到y(tǒng)。這個(gè)過程稱為 Use Case分析 , 是整個(gè)系統(tǒng)開發(fā)中非常關(guān)鍵的過程。 用戶普遍稱為 “ 活動(dòng)者 ” ，它可以是 人 或 另一個(gè)系統(tǒng) 。 Use Case 活動(dòng)者 活動(dòng)者 可以是 人 或 另一個(gè)系統(tǒng) ， 它與當(dāng)前的系統(tǒng)交互 ，向系統(tǒng)提供 輸入 或從系統(tǒng)中獲得 輸出 。命名這些角色的時(shí)候，要按作用來命名，而不是按照位置命名。例如航空訂票系統(tǒng)可能需要與外部應(yīng)用程序接口，驗(yàn)證信用卡以便購買。例如商業(yè)促銷項(xiàng)目推出免費(fèi)獎(jiǎng)，每天下午三點(diǎn)，系統(tǒng)自動(dòng)選擇向隨機(jī)客戶提供免費(fèi)獎(jiǎng)品。 Buy Soda Restock Soda Collect Money Customer Supplier Collector 每一 種活 動(dòng)者 具有 自己 的 use case 飲料販賣機(jī)中的 活動(dòng)者 供應(yīng)商 向 自動(dòng)販賣機(jī)添加飲料。 理解用例 ? 用例 獨(dú)立于實(shí)現(xiàn)。 ? 用例 是系統(tǒng)的高級(jí)視圖。 ? 最后， 用例 關(guān)注系統(tǒng)外的用戶。 用例 應(yīng)按業(yè)務(wù)術(shù)語命名，而不是按技術(shù)術(shù)語命名，應(yīng)讓客戶一目了然。 ? 用例 分析有助于 : ?捕捉需求 ?計(jì)劃開發(fā)過程的循環(huán)往復(fù)。 ? 需求分析 從 用例 分析開始，它驅(qū)動(dòng)整個(gè)開發(fā)過程。 標(biāo)記 用例 ? 活動(dòng)者希望這個(gè)系統(tǒng) 執(zhí)行 什么任務(wù)。 ? 是否考慮了每個(gè)操作者 如何使用系統(tǒng)。 ? 每個(gè)操作員從系統(tǒng) 接收了什么信息。是否標(biāo)示了系統(tǒng)要交互的所有外部系統(tǒng)。 Buy Soda Restock Soda Collect Money Customer Supplier Collector Soda Machine 系統(tǒng) 邊界 用例的范圍 從業(yè)務(wù)模型到系統(tǒng)模型 例：建立用例的系統(tǒng)模型 ?ATM取款機(jī)作為一個(gè)業(yè)務(wù)系統(tǒng) ?來取款的客戶是一個(gè)角色 ?用例是業(yè)務(wù)模型中業(yè)務(wù)的活動(dòng) ?系統(tǒng)模型描述了業(yè)務(wù)中系統(tǒng)的工作 （ 內(nèi)部活動(dòng) ） ?角色是外部 ， 用例是內(nèi)部 。 ?用例模型開始定義角色之間的關(guān)系 （ 關(guān)聯(lián)關(guān)系 、 包括關(guān)系 、 擴(kuò)展關(guān)系 、 一般化關(guān)系等 ） 。 ?這樣 ， 我們就建立了一張描述 “ 活動(dòng) ” 的 Use Case圖 ， 通過這張圖 ，我們就能夠比較具體地描述 “ 活動(dòng) ” ， 即讓用戶看到： ?誰與系統(tǒng)交互 ， 有助于發(fā)現(xiàn)缺少的參與者 ?知道系統(tǒng)的范圍 ， 有助于發(fā)現(xiàn)缺少的功能 業(yè)務(wù)用例描述：柜臺(tái)取款 業(yè)務(wù)用例活動(dòng)圖 ： 柜臺(tái)取款 注意： 這里只有角色（客戶）和用例（系統(tǒng)） 對(duì)于系統(tǒng)內(nèi)部的實(shí)現(xiàn)，我們還沒有更多的涉及 從業(yè)務(wù)模型到系統(tǒng)模型 ATM 系統(tǒng)用例 – ATM 系統(tǒng)用例 ATM取款 用例時(shí)序圖 ATM取款 系統(tǒng)開始區(qū)分 ATM系統(tǒng)和銀行主機(jī)系統(tǒng) 用例的層次 ? 概要目標(biāo)用例： 需要多個(gè)用戶目標(biāo)會(huì)話來完成（日、周、月、年） ? 用戶目標(biāo)用例 ： 滿足特定、迫切、有價(jià)值的用例目標(biāo)（分鐘、小時(shí)） ? 子功能用例： 為了完成用戶的真實(shí)目標(biāo)而提供的功能 用戶目標(biāo)層 ? ―Can the actor go away happy after having done this?‖ ? 通常 1個(gè)人， 1次性完成， 220分鐘 概要目標(biāo)層 ? 使用 ATM用例：銀行自動(dòng)柜員機(jī) ? 含有多個(gè)用戶目標(biāo)，可包含：存取款、查詢、修改密碼、打印憑單、提供跨地域、跨銀行服務(wù) ? 作用 ?說明用戶目標(biāo)執(zhí)行的背景 ?說明相關(guān)目標(biāo)的范圍 ?提供了下層用例的目錄 用戶目標(biāo)層次 用例分析流程 1. 定義系統(tǒng)范圍和邊界 2. 列出角色及其作用 3. 提取概要用例并調(diào)整得當(dāng) 4. 著重對(duì)系統(tǒng)的用戶目標(biāo)層用例進(jìn)行細(xì)化 5. 填寫干系人責(zé)權(quán)利、前置后置條件 6. 編寫基本流 7. 列出所有擴(kuò)展條件，編寫擴(kuò)展處理步驟 8. 用活動(dòng)圖、狀態(tài)圖、交互圖等描述重點(diǎn)用例 9. 分解、合并用例，調(diào)整用例關(guān)系模型（用例圖） 需求獲取 ——關(guān)鍵是獲得用戶的確認(rèn) 建立業(yè)務(wù)模型的工作主要包括： ?分析領(lǐng)域中的業(yè)務(wù)角色 ?分析角色間的業(yè)務(wù)功能等關(guān)系 ?分析業(yè)務(wù)組織架構(gòu) ?分析業(yè)務(wù)規(guī)則 ?分析業(yè)務(wù)實(shí)體 ?分析業(yè)務(wù)事件 ?分析以業(yè)務(wù)角色為主角的業(yè)務(wù)用例等； 以業(yè)務(wù)用例為實(shí)例，與用戶進(jìn)行溝通： ?需求是否被清楚地陳述？ ?存在錯(cuò)誤的理解嗎？ ?需求的來源（人員、規(guī)章制度、文件）是否正確？ ?需求的最終陳述是否得到用戶最終責(zé)任人確認(rèn)？ 問題 用戶不知道他們需求什么或不知道如何表達(dá) 直到開發(fā)人員把用戶所描述的東西給他們，用戶才認(rèn)為知道自己要什么 分析人員認(rèn)為自己比用戶更了解用戶的需求 解決方案 將用戶當(dāng)作領(lǐng)域?qū)＜襾碚J(rèn)識(shí)和感激， 嘗試一下其他溝通和啟發(fā)技術(shù) 盡早提供相互選擇的啟發(fā)技術(shù)：情節(jié) 串聯(lián)板、原型、角色換位等 把分析人員放在用戶的位置，試著換位一小時(shí)或一天 解決用戶和開發(fā)人員綜合癥 用戶講故事 介紹游戲規(guī)則 輸出結(jié)果 幻燈片放映 動(dòng)畫制作 仿真演示 交互演示 現(xiàn)場(chǎng)演示 被動(dòng)式介紹 主動(dòng)式介紹 交互式介紹 需求誘導(dǎo)的方法（情節(jié)串聯(lián)板） 原型開發(fā) 復(fù)雜程度與成本 需求獲取過程需求管理的關(guān)注點(diǎn) 步驟： 發(fā)現(xiàn)和分析問題 理解用戶的需求 定義系統(tǒng) （ 用例模型 ） 管理范圍 （ 項(xiàng)目管理 ） 方法： 采用業(yè)務(wù)建模和系統(tǒng)建模的方法進(jìn)行問題分析 對(duì)與系統(tǒng)架構(gòu)和系統(tǒng)行為有關(guān)的用例進(jìn)行描述和定義 目標(biāo)： ?在問題定義上與用戶達(dá)成共識(shí) ?理解問題背后的根本原因 ?確定用戶和項(xiàng)目干系人 ?定義問題解空間的邊界 ?確定問題解決方案的約束和假設(shè) 最終階段完成標(biāo)志：用戶對(duì)系統(tǒng)目標(biāo)的認(rèn)可 —— 簽字 需求獲取過程產(chǎn)品基線管理的關(guān)注點(diǎn) 產(chǎn)品前景文件 技術(shù)創(chuàng)新和突破 產(chǎn)品特點(diǎn) 客戶：涉眾和用例 分析人員和專家的意見 與公司其他產(chǎn)品的配套和一致性 與對(duì)手的競(jìng)爭性產(chǎn)品差異和優(yōu)勢(shì) 開發(fā)團(tuán)隊(duì)的狀況與產(chǎn)品的可持續(xù)性 系統(tǒng)平臺(tái)與兼容性 公司目標(biāo)與市場(chǎng)需求 一個(gè)真正偉大的產(chǎn)品 需求獲取過程產(chǎn)品路線管理的關(guān)注點(diǎn) 新系統(tǒng) 版本特性 基本功能 安保接口 客戶定義 遠(yuǎn)程維護(hù) 多平臺(tái)支持 中央控制單元 戶主客戶 控制開關(guān) 05/01 05/07 05/09 06/01 06/03 圖例： 正在發(fā)行 發(fā)布代碼行 代碼行修改 需求提取的最佳實(shí)踐 1. 明確構(gòu)想和范圍 2. 確立需求開發(fā)過程 3. 用戶群分類 4. 選定產(chǎn)品代表 5. 建立用戶核心隊(duì)伍 6. 建立用例模型 7. 舉辦用例演示會(huì) 8. 分析業(yè)務(wù)流程 9. 明確質(zhì)量屬性 10. 檢查問題報(bào)告 11. 重用需求 …… 用例常見錯(cuò)誤 1. 無系統(tǒng)目標(biāo)或邊界 2. 無角色定位 3. 用戶界面細(xì)節(jié)過多 4. 目標(biāo)層次太低 5. 目的與內(nèi)容不一致 6. 含有設(shè)計(jì)內(nèi)容 7. 過多的數(shù)據(jù)細(xì)節(jié) “ 用例分析 是當(dāng)今消除需求不明確、不一致、不完整 的重要手段和關(guān)鍵技術(shù) ” 用例在 需求獲取 階段的好處： ?與傳統(tǒng)的需求分析方法相比，用例書寫簡單、易于理解 ?用例迫使開發(fā)人員從系統(tǒng)設(shè)計(jì)時(shí)，就從用戶的角度考慮問題 ?用例使用戶參與需求過程，幫助他們理解所建設(shè)的系統(tǒng)，并提供了一種交流和記錄的工具 ?用例給出了需求的情景，從而使人們理解需求的原因以及系統(tǒng)是如何實(shí)現(xiàn)它的目標(biāo) ?大多數(shù)情況下，用例是開發(fā)人員寫的，因此，他是理解這個(gè)需求，也知道最終要對(duì)實(shí)現(xiàn)這個(gè)需求負(fù)責(zé)的 用例在系統(tǒng)開發(fā)的其他階段的好處： ?用例在分析階段，也是一個(gè)關(guān)鍵的工具，它幫助我們理解系統(tǒng)需求做什么以及系統(tǒng)可能如何去做 ?用例在設(shè)計(jì)和實(shí)現(xiàn)過程中，也是一個(gè)關(guān)鍵的工具，它降低了因需求表達(dá)不確切和不一致，導(dǎo)致系統(tǒng)開發(fā)錯(cuò)誤的風(fēng)險(xiǎn) ?用例可以直接延伸到測(cè)試過程，這有利于確保系統(tǒng)真正做了它應(yīng)該做的事情 ?用例也是用戶文檔的輸入，可以從用例開始，很方便地組織用戶文檔的編寫 用例在組織軟件開發(fā)中的核心作用 用例驅(qū)動(dòng)模型 到目前為止，我們完成了需求獲取階段的任務(wù) 通過采用用例的方法，建立了業(yè)務(wù)模型，使用戶理解并確認(rèn)系統(tǒng)要做什么和不做什么 從業(yè)務(wù)用例到測(cè)試用例 V模型中的過程從左到右 ， 描述了基本的開發(fā)過程和測(cè)試行為 。 測(cè)試與開發(fā)階段的對(duì)應(yīng) ——V模式 驗(yàn)收測(cè)試 ? 在行業(yè)應(yīng)用軟件環(huán)境中 ， 驗(yàn)收測(cè)試是項(xiàng)目過程非常重要的一環(huán) ， 也是項(xiàng)目經(jīng)理非常關(guān)注的一項(xiàng)工作 。 ? 驗(yàn)收測(cè)試通常由項(xiàng)目組先提出測(cè)試大綱 ， 定義測(cè)試目的 、范圍 、 方法 、 測(cè)試用例 、 預(yù)期結(jié)果 、 驗(yàn)收標(biāo)準(zhǔn)等 。 ? 用戶在完成按測(cè)試用例的測(cè)試后 ， 在測(cè)試記錄上逐條確認(rèn) 、 簽字 ， 最后 ， 在測(cè)試報(bào)告上簽字 ， 完成驗(yàn)收測(cè)試 。 系統(tǒng)驗(yàn)收與用例的關(guān)系 驗(yàn)收測(cè)試的用例 ， 在需求獲取完成后產(chǎn)生 測(cè)試用例的依據(jù)是需求獲取的業(yè)務(wù)用例 。 從用例到測(cè)試用例 測(cè)試用例名稱 工號(hào)權(quán)限 被測(cè)子系統(tǒng)名 卡 /號(hào)資源管理 測(cè)試用例來源 ? 公司測(cè)試組 □ 內(nèi)部測(cè)試抽查參考文檔 序號(hào) 測(cè)試用例描述 XWYY001 測(cè)試目的 能否正確識(shí)別合法的操作員進(jìn)入應(yīng)用系統(tǒng) 測(cè)試步驟 “ 卡 /號(hào)資源管理 ” 應(yīng)用程序 。 系統(tǒng)中存在的工號(hào) nj001和正確的密碼 ， 檢查能否進(jìn)入系統(tǒng) 。 輸入數(shù)據(jù)描述 工號(hào) 1000根本不是系統(tǒng)合法的工號(hào) 。 工號(hào)yd002是卡號(hào)資源管理系統(tǒng)的工號(hào) 。 ?用例 —— 業(yè)務(wù)模型和系統(tǒng)模型的最典型表示形式 ?軟件產(chǎn)品本身可能還存在與業(yè)務(wù)無直接關(guān)系的另類需求（一般與硬件、軟件環(huán)境相關(guān)），比如支持多種操作系統(tǒng)、對(duì)軟件運(yùn)行的遠(yuǎn)端監(jiān)控要求、異常處理（如通訊連接中斷等非業(yè)務(wù)異常）等等。 需求分析 —— 細(xì)化系統(tǒng)定義 在需求分析階段，我們不可避免地要涉及到進(jìn)行設(shè)計(jì)決策 設(shè)計(jì)決策： ?硬件環(huán)境（運(yùn)行在 PC服務(wù)器上？還是小型機(jī)？） ?平臺(tái)的選擇（只支持 Windows平臺(tái)，是否也支持 UNIX平臺(tái)？） ?工具的限制（采用 VB實(shí)現(xiàn)？） ?方法的約束（用 XYZ類庫實(shí)現(xiàn)數(shù)據(jù)庫訪問？） 當(dāng)前需求使我們考慮采用某種設(shè)計(jì)選項(xiàng) 被選擇的設(shè)計(jì)選項(xiàng)可能影響需求 需求分析是在需求獲取、需求分析和設(shè)計(jì)決策之間反復(fù)迭代循環(huán)的過程 需求分析 —— 細(xì)化系統(tǒng)定義 軟件需求是具體的： ?面向系統(tǒng)設(shè)計(jì)、編碼 ?面向測(cè)試 因此，在需求獲取的基礎(chǔ)上，進(jìn)一步細(xì)化系統(tǒng)需求、明確和細(xì)化系統(tǒng)定義，這就是需求分析階段的任務(wù) 在傳統(tǒng)軟件過程方法中，這二個(gè)階段不是非常清晰和明確 系統(tǒng)需求 功能性需求 非功能性需求 設(shè)計(jì)約束 需求分析 ——細(xì)化用例 在需求獲取過程中 ， 我們建立了業(yè)務(wù)模型和系統(tǒng)模型 ， 引入了角色和用例的概念 角色與用例的區(qū)別： ?系統(tǒng)的角色是業(yè)務(wù)之外與業(yè)務(wù)交互的人或事 ?例如： ATM取款機(jī)作為一個(gè)業(yè)務(wù)系統(tǒng) ， 來取款的客戶就是一個(gè)角色 ?用例是業(yè)務(wù)模型中 ， 業(yè)務(wù)的活動(dòng) ?在系統(tǒng)模型中 ， 描述了業(yè)務(wù)中系統(tǒng)的工作