SCEA第二階段---如何開始
還記得拿到第二階段的考題後，便迫不及待的把他印出來，並且很認真的畫線、註解。
然後很快的看完了一遍，當時覺得應該不難，但反覆看過幾次後，卻還是不知如何開始…
在考SCEA之前，我也負責過幾個J2EE的案子，在客戶面前也都能自傲的吹噓我們的OOAD技術，UML的各種圖也都畫了出來，在"結案"前也準時的交付，但仔細想想…那些文件的用途是什麼?
老實說，是為了結案。
如果客戶需要顧用一位新員工來維護該系統，新員工能在沒有我出面說明的情形下，只憑文件就了解系統嗎? 系統中的各項設計訣擇，是在什麼情形下產生的?
一個個問題在我回想中一一浮現…是的，我的確沒有認真想過，以致只能看著試題發呆…
當你拿到一份需求時，首先要做的是徹底了解，接著思考可行的架構，一個好的架構必然是符合需求且具全面性考量的，以下我要來介紹一些名詞，都是在設計時必須好好思考的名詞：
1. Assumption:
我在SI公司待了很久，就是那種專門接案件開發的單位，東奔西跑下來，看過的需求還真不少，使用者提出需求一定有他的想法需要你幫他滿足，但可惜的是他們永遠說不清楚，他們需要一位有經驗的IT從業人員來導引出真正清楚可行的需求。
不論是那裡來的需求書，看完後必然有一堆問號(如果你有認真看的話)，把這些問號都寫下來，去找實際的使用者，一一問清楚，然後做成正式的會議記錄，要求大家簽名同意，並更新文件，這個階段的每個遺漏，都是你這開發者將來會吃悶虧的地方。
SCEA第二部份的考題也是一份需求書，同樣的也是不清不楚，但這次沒有使用者可以幫你犛清所有問號，但沒關係，想像你自己是使用者，自問自答，把答案寫下來成為一條一條的Assumption。
2. Design Decision:
去年12月，我帶著身懷六甲的老婆出遊，行程是這樣設計的：
第一天：
08:00 出發，從茹冬交流道上北二高，往南至南投草屯接新中橫，目的地是合歡山
12:00 清境附近找一間不錯的民宿用餐
14:00 合歡山莊 Check in
15:00 武嶺賞雲海
16:00 合歡主峰登山步道
17:30 合歡主峰頂看日落
…
…
行程的設計訣擇:
1. 08:00出發-->因為當天是非假日，所以預期不會塞車，這時間出發到清境剛好約午餐時間。
2. 從茹冬交流道上北二高，往南至南投草屯-->因為從新竹經北二高到南投路徑短，車流速度快。
3. 12:00 清境附近找一間不錯的民宿用餐-->清境附近的用餐選擇很多，不致於找不到餐館，所以決定到時再找。
4. 從新中橫上山會先經過合歡主峰、武嶺再到合歡山莊，但我們決定先到合歡山莊Check in再回頭觀光 --> 因為合歡主峰日落景致很美，為了配合黃昏的時間，所以決定先Check in再繞回頭路。
…
…
我並不想寫一篇遊記，但思考一下行程與其設計訣擇之間的關係，其實是很有趣的。
如果只有行程表，而十年後的我看到這行程表時，能夠了解行程為何要這樣安排嗎？
如果只有行程表，而十年後的我想再安排一次合歡山之旅時，這行程有用嗎？（也許到時的交通環境和景點設施都已改變）
生活中的許多事物都存在著「Design＜－－＞Design Decision」之間的關係，例如大樓的設計圖、食譜、引擎……數不盡。
軟體設計也一樣，好的設計文件，應該要將「重要的」「Design Decision」，以簡單明暸的方式寫下來，這會使你的文件更具可讀性及參考價值。
3. Good Diagram:
簡單的文字搭配良好的圖解，可以讓你的文件可讀性事半功倍，這裡的Diagram並不限定要符合UML規格，只要是可以幫助說明的，都可以放在文件中，記住一點：沒有人員輔助說明就看不懂的文件，不能叫好。
