當我們進行業(yè)務流程分析時,只空對空而不落到紙面上是不可以的。過去,在面向過程的時代,我們繪制DFD圖、流程圖,以及編寫流程說明來描繪這一部分分析;而現(xiàn)在,在面向?qū)ο蟮臅r代,我們則是繪制行動圖、狀態(tài)圖,以及編寫用例說明來完成這部分工作。
在這部分工作中,編寫用例說明應當是最主要的工作,之后在一些關(guān)鍵部分輔之以行動圖、狀態(tài)圖。現(xiàn)在我們來看看用例說明應當怎樣編寫。
毫不疑問,做用例分析首先是要繪制出用例圖(前面已經(jīng)說過了)。圖形的最大優(yōu)勢是能夠形象生動地描述我們的分析,但它最大的缺點是會遺失許多的細節(jié)信息,因此我們必須要對它進行進一步的文字描述。
由于不同的人對用例的理解不同,格式也不盡相同,但一些基本的元素是一樣的。以上表格是我采用的用例說明格式,其中用例名稱、用例描述、參與者、前置條件、事件流、后置條件是公認的、用例說明的基本元素。
用例標識:就是用例的編號,一般采用“項目編號-子系統(tǒng)編號-模塊編號-序號”來編號。
用例名稱:沒啥可說的,就是用例圖中該用例的名稱。注意用例的命名規(guī)則:用例名稱通常是一個動詞短語或短句,而不是一個名詞短語。它可以是一個動詞(如:自動考核),一個動賓短語(如:提取存款),一個被動句(如:發(fā)票填報),或者一個主謂句(如:用戶提款,這個不推薦,因為主語就是參與者,顯得有些多余)。
用例類型:在我看來,不同類型的用例,其用例說明的格式是不一樣的。以上給出的是“業(yè)務操作”類用例的格式,它更加著重地在描述業(yè)務操作的流程。而“查詢報表”類用例則沒有什么流程,它更加著重地在描述報表格式及顯示內(nèi)容(后面再給出)。還有用例類型還包括“子用例”、“擴展用例”。
用例描述:對該用例的功能定義、要實現(xiàn)的業(yè)務需求,以及誰(參與者)應該如何使用進行描述。同時,這部分還可以整體概述實現(xiàn)業(yè)務需求的主要流程,以及與其它用例、其它外部系統(tǒng)的關(guān)系。通過用例描述,閱讀者可以對該用例有一個整體的認識。
參與者:用例圖中該用例的參與者,通常是業(yè)務操作的觸發(fā)者和施與對象(如外部系統(tǒng))。
觸發(fā)事件:誰干了什么,觸發(fā)了這個用例。
前置條件:在觸發(fā)該用例相關(guān)操作前必須達到的條件。
事件流:這是用例說明中最重要的部分,它詳細描述了該用例可能出現(xiàn)的所有流程。
1. 基本流程:另一個名稱更能表達它的意義:最佳流程(The Best Flow)。它描述的是該用例以最佳的、最正常的方式流轉(zhuǎn),沒有出現(xiàn)任何異常,并且最終成功完成操作的流程。基本流程在編寫時,應當通過數(shù)字對流程中的每一步進行編號。
2. 擴展流程:或者叫“分支流程”,它描述的是基本流程在流轉(zhuǎn)過程中可能出現(xiàn)的所有分支。擴展流程最大的特點就是,它應當是在基本流程的某一步驟發(fā)生的分支,因此它的編號規(guī)則是“基本流程號+序號”。基本流程號就是發(fā)生分支的那一個基本流程的編號。在同一個基本流程上發(fā)生多個分支時,它們的序號從1依次開始編號。
另一種情況是,某個擴展流程本身擁有多個步驟,這時應當在“基本流程號+自身序號”的基礎(chǔ)上再添加序號,如“2.1.1”。
擴展流程在描述時,應當首先描述進入這個分支的條件,即“如果××則××”、“當××時××”。
3. 異常流程:就是發(fā)生異常情況時的處理流程。注意,用例說明是站在用例角度進行的說明,因此這里并不是我們通常一樣的發(fā)生程序異常的處理流程,而是用戶在處理業(yè)務操作時發(fā)生的異常情況,如:如果顧客不能提供身份證,則??????
后置條件:又稱為“成功保證”,就是執(zhí)行基本流程獲得成功以后所達到的狀態(tài)(條件)。后置條件往往體現(xiàn)的是執(zhí)行該用例的最終目的。如:完成用戶檔案的填寫并提交。
非功能需求:簡稱為“URPS+”,即可用性(Usability)、可靠性(Reliability)、性能(Performance)、可支持性(Supportability)以及其它(+)。這一部分的需求分析相當重要而又最容易被忽略,后面我們再詳細討論。
假設與約束:就是隱藏于業(yè)務功能中的各項規(guī)則與條件,如各種邏輯條件、計算公式、環(huán)境限制等等。
優(yōu)先級:沒啥可說的,最關(guān)鍵的是怎么去評定。這里我賣一個官子,在需求評審階段,我會給大家一個比較準確而又可操作的評定方法。
除此之外,我還往往在每一個用例說明的后面與該用例相關(guān)的需求列表,便于需求跟蹤。用例分析實質(zhì)是需求人員的一份設計。既然是設計就可能出現(xiàn)偏差,最終偏離原始的需求(這種情況特別容易出現(xiàn)在日后的升級維護中)。因此,將需求列表附在用例后面,便于日后的需求評審與確認。當每次需要升級時,則添加上新的需求,或?qū)σ酝男枨筮M行更新。
我們應當怎樣做需求分析
我們應當怎樣做需求調(diào)研:初識
我們應當怎樣做需求調(diào)研:拜訪
我們應當怎樣做需求調(diào)研:研討會
我們應當怎樣做需求調(diào)研:需求研討
我們應當怎樣做需求調(diào)研:迭代
我們應當怎樣做需求調(diào)研:需求捕獲(上)
我們應當怎樣做需求調(diào)研:需求捕獲(下)
我們應當怎樣做需求分析:功能角色分析與用例圖
我們應當怎樣做需求分析:業(yè)務流程分析(上)
我們應當怎樣做需求分析:業(yè)務流程分析(下)
我們應當怎樣做需求分析:用例說明
我們應當怎樣做需求分析:查詢報表分析
我們應當怎樣做需求分析:子用例與擴展用例
我們應當怎樣做需求分析:行動圖和狀態(tài)圖
我們應當怎樣做需求分析:業(yè)務領(lǐng)域分析
我們應當怎樣做需求分析:原文分析法
我們應當怎樣做需求分析:領(lǐng)域驅(qū)動設計
我們應當怎樣做需求分析:非功能需求
我們應當怎樣做需求確認:需求列表
我們應當怎樣做需求確認:一個需求列表的實例
我們應當怎樣做需求確認:快速原型法
我們應當怎樣做需求確認:需求規(guī)格說明書
我們應當怎樣做需求確認:評審與簽字確認會
(續(xù))
在這部分工作中,編寫用例說明應當是最主要的工作,之后在一些關(guān)鍵部分輔之以行動圖、狀態(tài)圖。現(xiàn)在我們來看看用例說明應當怎樣編寫。
毫不疑問,做用例分析首先是要繪制出用例圖(前面已經(jīng)說過了)。圖形的最大優(yōu)勢是能夠形象生動地描述我們的分析,但它最大的缺點是會遺失許多的細節(jié)信息,因此我們必須要對它進行進一步的文字描述。
由于不同的人對用例的理解不同,格式也不盡相同,但一些基本的元素是一樣的。以上表格是我采用的用例說明格式,其中用例名稱、用例描述、參與者、前置條件、事件流、后置條件是公認的、用例說明的基本元素。
用例標識:就是用例的編號,一般采用“項目編號-子系統(tǒng)編號-模塊編號-序號”來編號。
用例名稱:沒啥可說的,就是用例圖中該用例的名稱。注意用例的命名規(guī)則:用例名稱通常是一個動詞短語或短句,而不是一個名詞短語。它可以是一個動詞(如:自動考核),一個動賓短語(如:提取存款),一個被動句(如:發(fā)票填報),或者一個主謂句(如:用戶提款,這個不推薦,因為主語就是參與者,顯得有些多余)。
用例類型:在我看來,不同類型的用例,其用例說明的格式是不一樣的。以上給出的是“業(yè)務操作”類用例的格式,它更加著重地在描述業(yè)務操作的流程。而“查詢報表”類用例則沒有什么流程,它更加著重地在描述報表格式及顯示內(nèi)容(后面再給出)。還有用例類型還包括“子用例”、“擴展用例”。
用例描述:對該用例的功能定義、要實現(xiàn)的業(yè)務需求,以及誰(參與者)應該如何使用進行描述。同時,這部分還可以整體概述實現(xiàn)業(yè)務需求的主要流程,以及與其它用例、其它外部系統(tǒng)的關(guān)系。通過用例描述,閱讀者可以對該用例有一個整體的認識。
參與者:用例圖中該用例的參與者,通常是業(yè)務操作的觸發(fā)者和施與對象(如外部系統(tǒng))。
觸發(fā)事件:誰干了什么,觸發(fā)了這個用例。
前置條件:在觸發(fā)該用例相關(guān)操作前必須達到的條件。
事件流:這是用例說明中最重要的部分,它詳細描述了該用例可能出現(xiàn)的所有流程。
1. 基本流程:另一個名稱更能表達它的意義:最佳流程(The Best Flow)。它描述的是該用例以最佳的、最正常的方式流轉(zhuǎn),沒有出現(xiàn)任何異常,并且最終成功完成操作的流程。基本流程在編寫時,應當通過數(shù)字對流程中的每一步進行編號。
2. 擴展流程:或者叫“分支流程”,它描述的是基本流程在流轉(zhuǎn)過程中可能出現(xiàn)的所有分支。擴展流程最大的特點就是,它應當是在基本流程的某一步驟發(fā)生的分支,因此它的編號規(guī)則是“基本流程號+序號”。基本流程號就是發(fā)生分支的那一個基本流程的編號。在同一個基本流程上發(fā)生多個分支時,它們的序號從1依次開始編號。
另一種情況是,某個擴展流程本身擁有多個步驟,這時應當在“基本流程號+自身序號”的基礎(chǔ)上再添加序號,如“2.1.1”。
擴展流程在描述時,應當首先描述進入這個分支的條件,即“如果××則××”、“當××時××”。
3. 異常流程:就是發(fā)生異常情況時的處理流程。注意,用例說明是站在用例角度進行的說明,因此這里并不是我們通常一樣的發(fā)生程序異常的處理流程,而是用戶在處理業(yè)務操作時發(fā)生的異常情況,如:如果顧客不能提供身份證,則??????
后置條件:又稱為“成功保證”,就是執(zhí)行基本流程獲得成功以后所達到的狀態(tài)(條件)。后置條件往往體現(xiàn)的是執(zhí)行該用例的最終目的。如:完成用戶檔案的填寫并提交。
非功能需求:簡稱為“URPS+”,即可用性(Usability)、可靠性(Reliability)、性能(Performance)、可支持性(Supportability)以及其它(+)。這一部分的需求分析相當重要而又最容易被忽略,后面我們再詳細討論。
假設與約束:就是隱藏于業(yè)務功能中的各項規(guī)則與條件,如各種邏輯條件、計算公式、環(huán)境限制等等。
優(yōu)先級:沒啥可說的,最關(guān)鍵的是怎么去評定。這里我賣一個官子,在需求評審階段,我會給大家一個比較準確而又可操作的評定方法。
除此之外,我還往往在每一個用例說明的后面與該用例相關(guān)的需求列表,便于需求跟蹤。用例分析實質(zhì)是需求人員的一份設計。既然是設計就可能出現(xiàn)偏差,最終偏離原始的需求(這種情況特別容易出現(xiàn)在日后的升級維護中)。因此,將需求列表附在用例后面,便于日后的需求評審與確認。當每次需要升級時,則添加上新的需求,或?qū)σ酝男枨筮M行更新。
我們應當怎樣做需求分析
我們應當怎樣做需求調(diào)研:初識
我們應當怎樣做需求調(diào)研:拜訪
我們應當怎樣做需求調(diào)研:研討會
我們應當怎樣做需求調(diào)研:需求研討
我們應當怎樣做需求調(diào)研:迭代
我們應當怎樣做需求調(diào)研:需求捕獲(上)
我們應當怎樣做需求調(diào)研:需求捕獲(下)
我們應當怎樣做需求分析:功能角色分析與用例圖
我們應當怎樣做需求分析:業(yè)務流程分析(上)
我們應當怎樣做需求分析:業(yè)務流程分析(下)
我們應當怎樣做需求分析:用例說明
我們應當怎樣做需求分析:查詢報表分析
我們應當怎樣做需求分析:子用例與擴展用例
我們應當怎樣做需求分析:行動圖和狀態(tài)圖
我們應當怎樣做需求分析:業(yè)務領(lǐng)域分析
我們應當怎樣做需求分析:原文分析法
我們應當怎樣做需求分析:領(lǐng)域驅(qū)動設計
我們應當怎樣做需求分析:非功能需求
我們應當怎樣做需求確認:需求列表
我們應當怎樣做需求確認:一個需求列表的實例
我們應當怎樣做需求確認:快速原型法
我們應當怎樣做需求確認:需求規(guī)格說明書
我們應當怎樣做需求確認:評審與簽字確認會
(續(xù))
更多文章、技術(shù)交流、商務合作、聯(lián)系博主
微信掃碼或搜索:z360901061
微信掃一掃加我為好友
QQ號聯(lián)系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元

