寫給SA的UML/MDA實務手冊
----------
第6章-分析系統流程
6.5-模擬PIM-1:分析系統流程
在進行PIM-1訪談時,針對每一個系統UC,系統分析師可以請企業人員協助回答下列問題,或者提供相關資料:
1.
條列出企業人員現行的執行步驟。
2.
期望系統怎麼做,以改善現行作業的缺失。
3.
提供相關的紙本表單或電子表單。
4.
列出相關的企業規則和計算公式
資訊化之後,企業人員原先的執行步驟,很可能會成為系統UC的主要流程。再配合瞭解企業人員對系統的期望之後,方便系統分析師根據這些流程資料,編寫出系統UC的主要流程。
編寫UC敘述時,盡量使用單一的專有名詞涵括多項的資料欄位,這樣才不會因為資料欄位變動而須改版UC敘述。同時可以請企業人員提供相關的現行表單,以便系統分析師可以從中獲取重要的專有名詞,以及相關的資料欄位。
在基金模擬個案中,投資人上網申購基金之前,並須執行「登入」系統UC,執行期間系統將要求提供投資人資料以驗證身分。在這個例子中,系統分析師可能有兩種寫法:
1.
參與者鍵入(代號)、(密碼),供系統驗證身份。
2.
參與者鍵入(投資人)資料,供系統驗證身份。
第1種寫法非常明確清楚,缺點是資料項目經常會有變動,將導致UC敘述改版頻繁。在基金模擬個案中,基金系統上線之後,銀行可能會要求投資人登入時,需要多鍵入一項身分證字號,這是很常見的需求變更,系統也很容易配合修改。可是,只要一遇到這樣的小變動,第1種UC敘述就得改版了。
在第2種寫法中,投資人封裝了代號、密碼以及其他相關的資料項目,所以現在要求鍵入兩項資料以供驗證,或者日後改成鍵入三項資料,都沒關係,因為這些的資料項目都封裝在投資人底下。
雖然,在第2種寫法中,得配合類別圖才會知道投資人類別擁有哪些屬性項目,不如第1種寫法的細緻,不過第2種寫法封裝了變動細節,所以反而降低了改版的頻率,同時也因此預留了變動的空間和彈性。
根據「SUC001-網路申購單筆基金」系統UC,系統分析師已經先編寫了如下的UC敘述,隨後開始訪談企業人員,以便獲知更多的細節。
UC名稱
|
網路申購單筆基金
|
UC 編號
|
SUC001
|
UC簡述
|
投資人上網下單購買某檔基金。
|
UC圖
|
|
主要流程
|
系統分析師問:投資人申購單筆基金時,需要填寫什麼文件?或者需要攜帶什麼証明文件嗎?理專一般都怎麼處理的?
企業人員答:首先,投資人必須攜帶存摺和印鑑,綜存帳戶中存有足夠的申購款和手續費。理專會請投資人填寫基金申購書,然後從綜存帳戶中扣款。最後,理專會開立申購收執聯給投資人,整個手續就完成了。
系統分析師問:可以拿一份基金申購書和申購收執聯給我做參考嗎?
企業人員答:好的。你需要空白的表單,還是我填上假資料給你參考。
系統分析師答:填有假資料的表單最好。空白表單有電子檔,可以一併給我嗎?
企業人員答:有pdf檔。
根據上述訪談,系統分析師提出幾個需要釐清的問題,並且編寫了部份的敘述內容,如下:
n 如何分類基金?
n 約定扣款帳戶一個或多個?
n 帳戶餘額不足時,讓投資人重新輸入申購額,或者啟動交易失敗的例外流程?
n 扣款未成功時,是否啟動交易失敗的例外流程?
n 交易編號可有特殊的編碼方式?
n 手續費的計算公式為何?
n 「交易款項」是「申購金額」加上「手續費」嗎?
n 申購金額可有最高及最低金額限制?
n 需要提供列印申購收執聯的功能嗎?
主要流程
|
1.
系統列出可申購基金清單,以及約定之扣款帳戶。
2.
投資人從中選定一檔基金、扣款帳戶,鍵入申購金額,按下確定鍵。
3.
系統計算出手續費。
4.
系統連線綜存系統,查詢綜存帳戶餘額,確認餘額是否足夠支付交易款項。
5.
系統出現交易確認訊息,供投資人做最後確認。
6.
投資人按下最後確認鍵。
7.
系統連線綜存系統,扣交易款,交易成立。
8.
系統回傳申購收執聯,並且提供列印功能,供投資人選擇列印與否。
|
企業規則
|
1.
交易款項=申購金額+手續費
2.
手續費=?
3.
最高及最低申購金額?
4.
交易編號的編碼方式?
|
非UML文檔
|
基金申購書pdf檔、申購收執聯pdf檔。
|
其他
|
填了假資料的「基金申購書」和「申購收執聯」紙本。
|
系統分析師繼續下述訪談,以便釐清疑點,並且蒐集更多的細節,模擬對話如下:
系統分析師問:系統會列出基金清單,供投資人挑選。如果,基金個數很多的話,我們會需要對這些基金做分類,銀行有慣用的分類方式嗎?
企業人員答:我們都是用基金公司來分類基金。
系統分析師問:系統先讓投資人挑選某一家基金公司,然後系統才出現該基金公司名下的基金清單,供投資人從中挑選一檔基金。這樣可以嗎?
企業人員答:好。
系統分析師問:約定扣款的帳戶只有一個,還是可以有很多個供投資人挑選?
企業人員答:投資人可以申請多個扣款帳戶,不過每一筆交易只能指定某一個扣款帳戶。
系統分析師說:了解。如果扣款帳戶的餘額不足時,希望系統做什麼處理,是讓投資人重新輸入申購金額,還是把這個狀況當成交易失敗。
企業人員答:餘額不足時,系統出現提醒訊息,讓投資人重新輸入申購金額就可以了。扣款失敗,才算交易失敗。
系統分析師問:如果交易成功的話,通常會給交易編號,銀行有獨特的編碼方式嗎?
企業人員答:有的。公司有自己的編碼方式。
系統分析師問:所以,系統還是依照公司原有的編碼方式產出交易編號,就可以了?
企業人員答:按照公司的編碼方式。
系統分析師問:確認一下,交易款項是申購金額加手續費嗎?還是有其他的費用。
企業人員答:沒有,就這兩項費用。
系統分析師問:手續費怎麼算?
企業人員答:申購金額乘上基金公司公告的管理費,銀行有時還會給折扣。比方說,投資人申購一檔JF東協基金,申購金額100,000元,該檔基金的管理費為3%,銀行針對網路投資人給6折的折扣。所以,手續費就是1,800元=100,000×3%×0.6。
系統分析師問:每筆申購金額有最高及最低的金額限制嗎?
企業人員答:有。國內基金最低申購金額為一萬元,境外基金最低申購金額為三萬元。而且申購金額必須以萬元為單位。原本申購金額無上限,不過透過網路下單的話,因為會從扣款帳戶轉出,所以有限制每筆轉出金額最高不得超過200萬元。也就是說,申購金額加上手續費不得超過200萬元。
系統分析師問:交易完成之後,需要提供列印功能,供投資人列印申購收執聯嗎?
企業人員答:這樣最好了。
系統分析師將上述訪談內容,整理編寫出UC敘述,並於企業人員討論確認之。「SUC001-網路申購單筆基金」系統UC的敘述如下:
■UC名稱 ■UC編號 ■UC簡述 ■UC圖 □系統 □參與者
□相關UC □其他( )
|
■主要流程 ■替代流程 ■例外流程
□其他(
)
|
□啟動事件或要件 □執行前要件 □成功時要件 □失敗時狀態
■企業規則 □其他( )
|
□UC敘述的歷史版本 □UML圖 □參考畫面 ■非UML文檔
■其他(基金申購書、申購收執聯 )
|
□優先性 □循環等級 □待解議題 □基本假設 □相關人員
□特殊需求 □其他( )
|
□其他(
)
|
UC名稱
|
網路申購單筆基金
|
UC 編號
|
SUC001
|
UC簡述
|
投資人上網下單購買某檔基金。
|
UC圖
|
|
主要流程
|
1.
系統列出基金公司清單及名下之基金清單,以及約定之扣款帳戶。
2.
投資人從中選定一家基金公司及其名下的某一檔基金,並且挑選某一個約定之扣款帳戶,鍵入申購金額,按下確定鍵。
3.
系統計算出手續費。
4.
系統連線綜存系統,查詢綜存帳戶餘額,確認餘額是否足夠支付交易款項。
5.
系統出現交易確認訊息,供投資人做最後確認。
6.
投資人按下最後確認鍵。
7.
系統連線綜存系統,扣交易款,交易成立。
8.
系統回傳申購收執聯,並且提供列印功能,供投資人選擇列印與否。
|
替代流程
|
2.a [金額不符]系統出現申購額必須為萬元倍數之訊息,回到主要流程2,供投資人重新輸入申購資料。
2.b [金額過低]系統出現最低申購額之訊息,回到主要流程2,供投資人重新輸入申購資料。
2.c [金額過高]系統出現最高申購額之訊息,回到主要流程2,供投資人重新輸入申購資料。
4.a [餘額不足]系統出現餘額不足的訊息,回到主要流程2,供投資人重新輸入申購資料。
|
例外流程
|
7.a [扣款失敗]系統出現交易失敗的訊息,該系統UC執行失敗。
|
企業規則
|
1.
交易款項=申購金額+手續費
2.
手續費=申購金額×基金管理費×銀行折扣
3.
國內基金最低申購金額為一萬元,境外基金最低申購金額為三萬元。
4.
每筆交易款項(申購金額+手續費)不得超過200萬元。
5.
系統依照公司原有的編碼方式產出交易編號。
|
非UML文檔
|
基金申購書pdf檔、申購收執聯pdf檔。
|
其他
|
填了假資料的「基金申購書」和「申購收執聯」紙本。
|
「SUC002-網路申購定期定額基金」敘述,如下:
■UC名稱 ■UC編號 ■UC簡述 ■UC圖 □系統 □參與者
□相關UC □其他( )
|
■主要流程 ■替代流程 □例外流程
□其他(
)
|
□啟動事件或要件 □執行前要件 □成功時要件 □失敗時狀態
■企業規則 □其他( )
|
□UC敘述的歷史版本 □UML圖 ■參考畫面 □非UML文檔
□其他(
)
|
□優先性 □循環等級 □待解議題 □基本假設 □相關人員
□特殊需求 □其他( )
|
□其他( )
|
UC名稱
|
網路申購定期定額基金
|
UC 編號
|
SUC002
|
UC簡述
|
投資人上網申購定期定額基金。
|
UC圖
|
|
參考畫面
|
|
主要流程
|
1.
系統列出基金公司清單及名下之基金清單、約定之扣款帳戶,以及扣款日期。
2.
投資人從中選定一家基金公司及其名下的某一檔基金,並且挑選某一個約定之扣款帳戶,鍵入申購金額,選擇一扣款日期,並且按下確定鍵。
3.
系統計算出手續費。
4.
系統出現交易資料,供投資人做最後確認。
5.
投資人按下最後確認鍵。
6.
系統回傳定期定額申購約定書,並且提供列印功能,供投資人選擇列印與否。
|
替代流程
|
2.a [金額不符]系統出現申購額必須為千元倍數之訊息,回到主要流程2,供投資人重新輸入申購資料。
2.b [金額過低]系統出現最低申購額之訊息,回到主要流程2,供投資人重新輸入申購資料。
2.c [金額過高]系統出現最高申購額之訊息,回到主要流程2,供投資人重新輸入申購資料。
|
企業規則
|
1.
交易款項=申購金額+手續費
2.
手續費=申購金額×基金管理費×銀行折扣
3.
定期定額國內基金最低申購金額為三千元,定期定額境外基金最低申購金額為五千元。
4.
每筆交易款項(申購金額+手續費)不得超過200萬元。
5.
系統依照公司原有的編碼方式產出交易編號。
|
「SUC003-定期定額約定異動」敘述,如下:
■UC名稱 ■UC編號 ■UC簡述 ■UC圖 □系統 □參與者
□相關UC □其他( )
|
■主要流程 ■替代流程 □例外流程
□其他(
)
|
□啟動事件或要件 □執行前要件 □成功時要件 □失敗時狀態
■企業規則 □其他( )
|
□UC敘述的歷史版本 □UML圖 ■參考畫面 □非UML文檔
□其他(
)
|
□優先性 □循環等級 □待解議題 □基本假設 □相關人員
□特殊需求 □其他( )
|
□其他( )
|
UC名稱
|
定期定額約定異動
|
UC 編號
|
SUC003
|
UC簡述
|
投資人上網更改定期定額約定。
|
UC圖
|
|
參考畫面
|
|
主要流程
|
1.
系統列出可異動之定期定額交易清單。
2.
投資人從中選擇一筆交易,進行異動修改。
3.
系統列出異動事項,包含變更扣款金額、扣款帳戶、扣款日期、扣款情況。
4.
投資人可以同時勾選多項異動事項,並且按下確定鍵。
5.
系統出現異動之後的最新約定事項,供投資人做最後確認。
6.
投資人按下最後確認鍵。
7.
系統電郵異動成功的通知給投資人。
|
替代流程
|
4.a [金額不符]系統出現申購額必須為千元倍數之訊息,回到主要流程4,供投資人重新輸入申購資料。
4.b [金額過低]系統出現最低申購額之訊息,回到主要流程4,供投資人重新輸入申購資料。
4.c [金額過高]系統出現最高申購額之訊息,回到主要流程4,供投資人重新輸入申購資料。
|
企業規則
|
1.
扣款日期之前一個金融機構營業日(不包括星期例假日)之營業時間內(09:00~15:00)異動,當次扣款才生效,逾期則需下次扣款日期才能生效。
|
省略「SUC004-代客申購單筆基金」及「SUC005-代客申購定期定額基金」敘述。讀友們可以拿來當練習題。
「SUC006-扣款申購當期基金」敘述,如下:
■UC名稱 ■UC編號 ■UC簡述 ■UC圖 □系統 □參與者
□相關UC □其他( )
|
■主要流程 □替代流程 ■例外流程
□其他(
)
|
□啟動事件或要件 □執行前要件 □成功時要件 □失敗時狀態
■企業規則 □其他( )
|
□UC敘述的歷史版本 □UML圖 □參考畫面 □非UML文檔
□其他(
)
|
□優先性 □循環等級 □待解議題 □基本假設 □相關人員
□特殊需求 □其他( )
|
□其他( )
|
UC名稱
|
扣款申購當期基金
|
UC 編號
|
SUC006
|
UC簡述
|
系統於約定日自動扣款申購一筆基金。
|
UC圖
|
|
主要流程
|
1.
扣款約定日期一到,系統檢查定期定額申購之扣款情況為「正常扣款」。
2.
系統連線綜存系統,查詢扣款帳戶餘額,確認餘額是否足夠支付交易款項。
3.
系統連線綜存系統,扣交易款,交易成立。
4.
系統將累積扣款失敗次數歸零。
5.
系統更新基金庫存單位數。
|
例外流程
|
2.a [餘額不足]
2.a.1
系統檢查累積扣款失敗次數。
2.a.2
[失敗次數<3] 累加1次。
2.a.3
[失敗次數≧3] 更改交易情況為「停止扣款」。
2.a.4 中止執行主要流程2之後的其餘步驟。
|
企業規則
|
1.
交易款項=申購金額+手續費
2.
手續費=申購金額×基金管理費×銀行折扣
3.
最新庫存單位數=原庫存單位數+(申購金額÷申購淨值)
4.
連續3次扣款不成功,銀行將自動停止繼續扣款投資。
|
沒有留言:
張貼留言