1、產品需求規格說明書副標題：版本 0.1修訂歷史版本號作者內容提要發布日期目錄一、業務目標？業務背景？3二、術語表3三、業務流程圖3四、系統用例模型5五、系統用例詳細描述61.用例172.11一、 業務目標？業務背景？業務的價值是什么？它的責任范圍是什么？哪些不屬于它的責任范圍？（可選）二、 術語表所有本文中可能需要用到的業務術語，都需要在這里定義，以保證業務的相關人員對這些專有名詞的理解是一致的，并且，保證所有需要用到這些專有名詞的地方，都統一地使用這些專有名詞三、 業務流程圖說明：業務流程圖可以采用流程圖的形式，也可以是序列圖的形式，業務流程圖需要先以組織結構為單位建立組織結構之間的工作流程

2、，再按照人力資源關系細化這些組織內部的工作流程，組織結構本身又有層次之分。例如，阿里巴巴集團和外部集團或者公司之間的協作關系，屬于集團級別的流程圖，阿里巴巴內部各個公司之間的協作，屬于公司級別的流程，支付寶公司內部部門之間的協作，屬于部門級別的協作，最后，才是人力資源之間的協作關系，到了人力資源層次，每個人的個人活動才可能需要一次上機操作（也可以不需要上機操作），當需要上機操作的時候，這個操作任務就被映射到一個系統用例。因此， 業務流程圖建立的是各個活動之間的關系，而這些活動又按照粒度自上而下，逐步展開的方式進行描述，見范例： 四、 系統用例模型觀察上面流程圖中各個活動結點的粒度劃分，這些粒度

3、正好是每個角色的最原子的“業務目標”即，具有不可分割性，如果繼續分割，活動就將成為一個一個操作，而操作本身不具有完整的業務意義，因為系統用例必須按照“業務目標”進行組織，因此，按照“業務目標”組織活動結點的好處是，每個活動如果需要上機操作，它實際上就可以被當作一個系統用例，所以，流程圖到系統用例的轉化就具有了可追溯性，系統用例模型描述了系統參與者和系統的職責邊界，如下圖范例所示五、 系統用例詳細描述對系統用例模型中的各個系統用例展開描述思考思路如下所述：1. 用例1<<層次>> <<名稱>> 層次的概念：系統用例之間存在相互依賴關系，例如，我們需

4、要先進入管理保單這個高層用例，才可能進一步進入修改保單、統計結果等子用例，因此，管理保單就成為這些子用例的高層用例，實際上是一個描寫用例名稱的規范。版本號：該UC的版本號UC變更歷史：該UC歷史上的變更情況負責人：該UC的負責人摘要：l 用例描述：簡單描寫該用戶的業務目標l 權限項：如果是支付寶后臺的UC，需要在這里描述該UC所屬的權限項（由業務部門確認），所屬菜單，以及角色分配情況，和角色分配的用戶情況用戶界面設計：頁面白板Demo用例場景：l 主要參與者及其目標：任務的執行者是誰？它做這件事情的目的是什么？這個角色可以是任何事物，可以是人、外部系統、定時器、溫度感受器等等，主要參與者必須是

5、和系統直接交互的人或事物l 輔助參與者及其作用：任務執行過程中需要什么角色來輔助任務的完成？例如：銀行職員的操作過程需要用戶輸入密碼，才能進入下一步工作，輔助參與者必須是和系統直接交互的人或事物l 涉眾利益：（用例評審者，利益相關者）除了直接交互的參與者，還有哪些角色會關心這個用例的執行過程和結果？它們關心的理由是什么？l 前置條件：這個用例需要滿足什么條件才能進行？這個條件必須是系統能夠感知的，否則，不能作為前置條件，只能寫背景概述中，另外，要求這個條件必須是當前操作需要進行判斷的，有的用例在當前并不判斷如“用戶是否登錄”這樣的狀態，因為這些狀態在進入這個用例之前的用例已經做了l 主流程：如

6、果一切順利，通過那些交互過程來達成目標幾點約束：采用：用戶。系統。用戶。系統。這樣的格式進行描述，要求使用簡明扼要的動賓結構，統一的格式便于閱讀；、通過使用者視角，并采用業務語匯進行描述；、不包含交互的具體數據描述以及系統背后的操作；甚至不包含業務規則；此處僅僅關注的交互即用戶如何使用系統，其他的內容分離到相應的部分詳細展開描述，此處可以說明“業務規則見規則。（后文業務規則中的規則編號）”、每個操作必須具有業務意義上的“意圖”，例如：輸入用戶名、輸入密碼這兩個操作背后的意圖是“輸入并提交用戶驗證信息”，因此，不能將這兩個操作分別作為用例的步驟，只能寫“用戶輸入并提交驗證信息”，也就是說，每個用

7、例步驟都根本地表達出一個完整的 “意圖”，并且有助于朝目標邁進一步。、如果一個步驟是一個需要展開描述的復雜交互，可以作為一個“功能級”用例分離到一個單獨的用例中描述，此處的只要寫這個用例的名稱，并且帶下劃線，表示是一個需要展開子用例。因此，正常的用例很少超過步，如果多于這個數字，需要警惕。、某些部分需要循環，直接在用例文本的重復步驟后面說明“重復步驟n到m直到。（推出條件）l 后置條件：如果目標達成了，系統和開始以前相比，發生了哪些變化？這種變化包括操作者可見和不可見兩個部分，例如：銀行柜員機除了告訴操作者其銀行賬戶減少了多少金額，還同時在背后按照業務規則給另一個賬戶增加了等量的金額l 擴展流

8、程：主流程中各個步驟都可能出現的各種其他可能情況，這些擴展點的寫法是：對于需要擴展的步驟，使用這個步驟的編號加英文字母表示，英文a表示第一種可能的情況，b表示第二種可能的情況，對于在任何步驟都可能出現的情況，標號使用“”號表示。l 輸入項詳列：詳細羅列可能的輸入項，說明字段長度、必填還是選填等具體要求，對于可選項的可選范圍，在輸入輸出限制中描述l 輸出項詳列：詳細羅列可能的輸出項l 輸入輸出限制：例如：是使用刷卡器來讀卡還是手工輸入卡號？還有例如：某些輸入項的可選范圍限制是什么，在對某個可選項進行選擇以后，對其他輸入項的可選范圍產生什么影響？等等，避免使用“下拉列表”、“選擇框”之類關乎界面設計的表述，只能用“單選項”或者“復選項”這種表達方式。l 領域的業務規則：例如：法律的、政府的、行業的l 用戶操作流程：用圖形的模式展現用戶流程，簡單說就是流程圖。l 未決的問題：補充規約：思考范圍：安全性要求：例如：加密算法、安全架構. 可用性要求：例如：新手無需幫助的情況下的平均上手時間可靠性要求:例如：平均故障率，故障的平均恢復時間. 性能要求：例如：在一定并發數下的響應時間可支持性要求：例如：支持新的接口擴展、支持國際化擴展. 軟硬件環境約束：例如：操作系統、網絡、設備.的限制必須符合的標準：例如：網絡協議、行業標準對文檔和幫助的要求：例如：需