【正文】 去觀察和記錄他們現在是怎么工作的 ? 從專家那里了解用戶業(yè)務的原理和規(guī)則 ? 你是去了解要做什么而不是怎么做 15 首先，您需要把系統(tǒng)看成黑盒 ? 一開始就深入細節(jié)的產品經理，忙亂而又沒有績效 – 往往陷入細節(jié)的泥坑，甚至是技術細節(jié)，甚至 UI細節(jié) – 被層出不窮的需求點和例外處理困擾 – 控制不住滿腦袋亂冒的 ideas ? 請相信?。。。。。。。。。。。。。。。。。。?！ – 系統(tǒng)內部無論多么復雜 – 他總是可以被“使用說明書”說清楚 16 Actor 17 需求分析的第一個問題 誰是這個產品的用戶？ 或者， 誰是這個產品系統(tǒng)中的 角色 ？ 18 什么是角色 (Actor) ? 與系統(tǒng)發(fā)生交互作用的、系統(tǒng)之外的任何東西都是角色 – 可以是人 – 也可以是機器 ? 角色不等同于使用者 ? 角色存在于 系統(tǒng)外部 ? 角色不是活動的準確描述 ? 使用者是行駛某個角色職責的系統(tǒng)的使用人員 – 如小王是個采購員 我是角色 Actor！ 19 角色（續(xù)） ? 每個 Actor都通過不同的方式使用系統(tǒng)，除非他們是相同的 Actor ? Actor使用系統(tǒng)的每一種方式就是一個 Use Case 群普通用戶 群管理員 群股東 群創(chuàng)建者 群股東 20 角色分類 ? 主動角色： Use Case的動作序列是由他先發(fā)起的，通常系統(tǒng)返回最后結果 – 主叫方，采購人員，票據錄入員等 ? 被動角色：系統(tǒng)通過調用角色來完成 Use Case的動作序列（或其中的某一個動作） – 不是初始動作的發(fā)起者 – 當系統(tǒng)需要它們幫助的時候 – 最終是為了滿足主動角色的需要 – 通常是機器或其他系統(tǒng) Actor Use Case1 Use Case2 Actor Actor 21 Script 22 腳本 Script ? 腳本是一個角色與系統(tǒng)之間的一組交互作用 ? 通常具有詳細的真實數據及實際的期望輸出值 ? 一個應用系統(tǒng)可能具有成千上萬個腳本 ? 即使同一件事，所得到的腳本可能也會有細微的區(qū)別 ? 腳本是描繪 Use Case的重要的背景信息 23 腳本示例 1：小王輸入他的賬號 413597 2：小王輸入他的密碼 119823 3：小王查詢 4：系統(tǒng)顯示余額 1：小張輸入他的賬號 413343 2：小張輸入他的密碼 646788 3：小張查詢 4：系統(tǒng)顯示余額 1：小李輸入她的賬號 346780 2：小李輸入她的密碼 435645 3：小李查詢 4：系統(tǒng)顯示余額 24 腳本與 Use Case ? 一個 Use Case代表一組潛在的腳本 ? 通過研究一組相似的腳本，可以得到它們內在的邏輯 ? 相似的腳本通常遵循相似的模式工作，并提供相似類型的結果 ? 一個 Use Case通常關注某一個目標 ? 例如：查詢存折余額 腳本功能夾Use Case 25 Use Case 26 轉讓群 通過 Use Case描述系統(tǒng)功能需求 ? 一個系統(tǒng)具有無限個潛在的腳本 ? 但一個系統(tǒng)可以被有限的 Use Case完整說明 ? 系統(tǒng)的每一個 Use Case都必須列舉，否則系統(tǒng)將會遺漏功能 創(chuàng)建群 解散群 加入群 贊助群 邀請加入群 群內發(fā)言 授權群管理 27 Use Case ? 描述系統(tǒng)提供的交互功能 – 一個 Use Case可以被其他的 Use Case調用 – Use Case可以組合完成某一項更大的功能 ? Use Case說明系統(tǒng)需要提供什么而不是怎么提供 – 用戶并不關心你如何給他們提供所需要的功能 ? Use Case一般是用“動賓”短語命名 創(chuàng)建群 解散群 加入群 贊助群 邀請加入群 群內發(fā)言 授權群管理 28 Use Case ? Use Case不是分析設計文檔 – 雖然它們支持后續(xù)的分析設計工作 ? Use Case不是操作腳本 – 它不是用戶使用系統(tǒng)時實際操作的具體步驟的記錄 – 雖然它可能是通過操作腳本得來的 29 Use Case是很好的測試單元 ? Use Case清晰地描述了系統(tǒng)的功能界面 ? 測試人員可以在開發(fā)初期制定測試計劃 ? 每一個 Use Case都嚴格地說明了系統(tǒng)的某一項功能 – 它的輸入 – 它的輸出 – 期間的交互作用 ? Use Case是黑盒測試的基準 30 Use Case的闡述 ? 應該包含 Use Case的所有重要細節(jié) ? 應該包括角色與系統(tǒng)交互的關鍵步驟，可以使用順序圖（ Sequence Diagram） ? 要表述有關角色的信息 ? 要分清哪些是角色所具有的職能、哪些是系統(tǒng)所應提供的 ? 要列清使用這些功能是所應滿足的前提條件 ? 如果某些功能具有質量上的要求（如性能），也要列出來 創(chuàng)建群 Dddddddddddd Dddddxxafsdfads Dddddddddddd Ddddfcadsfasd ddddccdasdwe 31 Use Case：標記方法簡單 Actor名稱 Use Case名稱 32 Use Case：主動角色 經紀人 下單 投資人 報價審查 貨幣存取 經紀管理系統(tǒng) 33 Use Case：被動角色 經紀人 下單 投資人 報價審查 貨幣存取 經紀管理系統(tǒng) 銀證轉賬系統(tǒng) 34 畫 Use Case圖規(guī)則 ? 主動角色畫在圖的左邊 ? 被動角色畫在圖的右邊 ? 每個 Use Case必須為用戶提供確切的功能 ? Use Case名稱必須寫在橢圓里面 ? 保持圖面整潔 ? 每一張圖里不能有太多的 Use Case ? 為每一個 Use Case編號便于檢索 ? 為 Use Case建立目錄（編號和名稱）便于管理 35 Use Case 高級概念 36 Use Case高級概念 ? 通過分析 Use Case圖，分析人員可以找出不同的業(yè)務過程之間的共性 – 擴展、包含、派生、使用等關系 ? 通過這些關系可以降低系統(tǒng)的復雜度 ? 為重用提供了條件 ? 將共性提出來，可以幫助我們發(fā)現重復的過程 – 二次開發(fā)應該關注的地方 37 Actor 的繼承 ? 類似于 Use Case的擴展，角色之間可以繼承 ? 其他銀行不僅具有儲戶的所有功能，還有其他的功能 查詢余額存錢儲戶銀行取錢費用結算其他銀行38 Actor 繼承的好處 ? 在不丟失信息的前提下，簡化了 Use Case圖 ? 繼承說明了角色間的層次關系 ? 派生者繼承了父角色的所有能力 ? 父角色不知道派生者 39 擴展關系： extend ? 擴展關系通常用來表示某一