從開始寫程式也快四年了，在寫過一些系統後開始重視規劃的部份，先前規劃真的會提早知道很多資料限制與可能問題，一些平常到開發中期才會浮現的問題，很有可能在規劃時就會讓人注意到，相對來說，不論是要避開或是提醒業主都是非常方便的。
由於通常收到的專案的需求常常不夠穩定，什麼較不夠穩定，以下我提供三次開會出來的需求紀錄，這次是想做一個學生用的論證網站，環境限定PC，選擇語言是node.js (對方要求)，討論需求時間分別是20171123、20171201、20171213：
20171123：
(1)兩人一房分間討論
(2)每房配給一項題目
(3)題目從題目庫中隨機抽出
(4)每個參與人員將有獨特的流水號
(5)房內使用者行為依序紀錄
20171201：
(1) 學生活動前通過問券調查立場,利用立場分為同意反對兩派。
(2) 老師會事先新增自己的學生，相同的學生若分屬不同老師時，視為不同人。
(3) 老師查閱自己班級內的學生問答情況，並且在同一頁可以直接指派學生進入房間。
(4) 每間房間的學生數量不一定。
(5) 老師事先設定本次活動主題題目、房間數量。
(6) 學生輸入學生編號與活動編號登入，直接進入論證室。
(7) 活動中房內學生執行特定行為時，記錄下學生代號、時間、動作，不同活動的行為分開紀錄。
(8) 特定行為種類會事先儲存在資料庫中，目前以四項為主，未來有可能會依照系統擴展而增加。
(9) 可能會有多個老師使用系統，不同老師間的學生、房間資訊資料不可流通。
(10) 每位老師可能會辦多次活動。
(11) 每個活動都會有自己獨特的問卷。
20171213：
使用者的註冊:
● 使用者可以透過註冊後成為一般使用者。
● 任何使用者都可以使用以下功能。活動設置:
● (主辦人)從使用者清單中選出參與活動者(稱為受測人)。
● 每位使用者都可以舉辦多次活動。
● 每個活動都會有一個問卷連結。
● 使用者可以新增活動主題題目，可以看到自己與其他使用者所新增的題目。
● 舉辦活動之使用者(稱為主辦人)事先設定本次活動主題題目、聊天室數量。
● 每間聊天室的(受測者)數量不一定。活動期間動作:
● (受測學生)活動前通過問券調查立場組別，利用立場分為不同的組別。
● (主辦人)查閱(受測人)問答情況，並且在同一頁可以直接指派(受測者)歸屬聊天室。
● (受測者)輸入使用者代號與活動編號登入，直接進入論證室。
● (受測者)執行特定行為時，記錄下使用者代號、時間、動作、活動代號。預設資料:
● 系統管理者將特定行為種類事先儲存在資料庫中，目前以四項為主，未來有可能會依照系統擴展而增加。(兩天後增加為十六項)
這邊只是最剛開始的三次需求訪談，我想由上就可以看出需求是詭變多端的。
那在討論完需求後，個人就先依需求完成的ERD( Entity-relationship model )。
這邊算是總結文，詳細的圖像介紹我會再另開連結
利用這張ERD建構資料庫。
在完成SQL後，我再來規劃User Case Diagram。
然後這邊每個case都可以轉換成activity diagram，由於數量太多我這邊只放幾個示意。
基本上規畫到這邊我就會開始進行雛形試作，讓系統能夠有個基礎的運作，然後邊試做的同時，也要同時保留測試的檢核點，良好的文件會讓之後進行系統重鑄時更加穩定，以下提供一個API測試文件的部分。
當然除了以上說明的以外還需要考量很多東西，像是框架、環境、架構風格與API架構等等，甚至到往後的UI/UX、行動端等等，對我來說網站是永遠都沒有完成作品的，唯有不斷改變才得以朝向完美。
1 thought on “【ERD&UML】System Design 經驗分享”