Y17 First Practice(2)──需求階段

專案上說還不到使用工具的時機，估計起來在十二週的時間內有八週可以開發，因此堅持需求要經過完全確認後才進行分析與設計。檔案轉換工具主要有三項功能：匯入交易的電文規格、提供使用者編輯功能、匯出XML定義檔與空的Class（當然，使用者還希望能自動產生規格書）。

需求訪談並繪製成UML用了兩週，但也足夠讓自己發現以往的經驗值有許多與理論不合之處：

●從使用者角度看Use Case
記錄使用者需求時，一開始我記錄的是系統要做出的功能：像是新增交易檔案、編輯交易說明之類的，很快地就累積了上百個Use Case。Ｅ主管review時強調Use Case是描述客戶完成一件有意義的工作，並不是對應完成工作的分解動作（雖然對系統來說是完整的工作，但應放在Activity）；重新定義之後的Use Case剩下六個。


●幫Use Case說故事
Use Case的Activity Diagram要從使用者的角度來陳述做一件事的經過，強調的是使用者做了什麼以及與系統的互動。對系統的操作只需說明（對使用者來說）要做什麼事而不用描述操作的更細節部分。用swimlane分隔使用者與系統更能清楚表達二者的互動關係。


●Activity與Domain Object無關
這個工具輸入與輸出的詳細內容已經確定，所以我很早就開始繪製Data Model並將之連接到會操作到的Activity。後來發現這是提早設計的混淆，因為在分析階段時才會運用Boundry-Control-Entity的方式定義Domain Model、接著在設計時再定義為Data Model；在需求階段應該只先收集系統詞彙作CRC分析。

●UI的Prototype
在需求階段的末期應該與使用者討論資料的呈現內容與功能的操作方式，雖然Eclipse上有Visual Editor可以快速繪製UI，但是使用與調整還是需要不少時間。同事推薦一個網頁版的UI Prototype工具，能夠在極短的時間裡儘可能地表達出畫面的模樣；雖然與實際畫面有點落差，不過使用者接受度倒是挺高的。

Balsamiq Mockups：http://www.balsamiq.com/products/mockups