寫給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次扣款不成功，銀行將自動停止繼續扣款投資。
|
沒有留言:
張貼留言