寫在前面的感想
在現今的工商社會裡，我們常需要針對客戶或長官交辦的工作進行規劃與分析。而目前這類需求分析的工作運用得最頻繁的，一定包括了『資訊軟體業』，也因此，長期來資訊業發展了多套分析與設計的規則。這些規則與作業手法，也慢慢被其他業別所接受，這可以從PMP的PMBOK或CBAP所用BABOK中一窺端倪。
而目前在描述需求時，資訊界最常用的就是UML。只是實際使用時，仍常感不足，此時在野版的UML圖如『火箭圖(Eriksson-Penker Extensions)』、『魯棒圖(Robustness Diagram)』就能適時派上用場。火箭圖我喜歡用在高層次的系統分割或高階的系統願景描述，然後再用使用者案例去描述該做的事情。而魯棒圖則可以輔助我在和使用者溝通需求時，因為只有一個圈圈的use case 很難讓使用者發揮想像力 (文字描述更沒 fu)，有了這樣的圖，我可以更明白的呈現這個案例的範圍，然後用活動圖等詮釋案例中的步驟。如此一來，使用案例圖就更貼近使用者的觀點，然後，魯棒圖又將成為系統設計時的起點。因為，用use case 和工程師溝通，其實比跟使用者聊天還困難阿。
※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
Requirements Analysis 需求分析
需求分析的目標，就是產生一份明確規範的需求定義。然後，所謂的需求包括了「功能」、「品質」和「約束」，所以並非僅有要達到的功能，其實非功能性需求，常常才是最後決定可否驗收的關鍵，該關注的項目整理於下表：
| 分類 | 常見項目 |
| 業務需求 | 競爭、舊系統整合、標準、法規、技術 |
| 用戶級需求 | 用戶特性、用戶背景、用戶語言、用戶限制 |
| 開發級需求 | 維運、安裝、管理 / 資安、團隊限制 |
通常我們會將一個大的目標(系統)分割成多個子目標(子系統)或是切割成多個層次。並從中分析出 關鍵功能、關鍵品質、業務需求與約束，作業步驟如下：
- 針對關鍵功能進行初步設計。進行發現主要工作為目的的分析。
- 綜合初步設計確定高層分割，試圖將系統分切成多個次級系統。
- 考慮非功能性需求，提出對應。
在功能需求分析上，我們可以運用Use Case，而非功能需求分析則可採用『目標—場景—決策』表，範例如下 (小編：這類的表格很多種，主要目的都是記錄並提出預計的方案)：
| 目標 | 場景 | 決策 | 評估說明 |
| 性能要求 | 問題闡述 如：用戶端重複請求頁面 |
可行策略 如：HTML靜態化 (註：可先提出多組) |
..... |
※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
Robustness Diagram 魯棒圖
我們運用使用者案例 (Use Case)僅是用來捕獲『需求』，然後如何針對需求來進行塑模 (Modeling)？ 而魯棒圖就是由Ivar Jacobson 於1991 提出，用於指出使用者案例需哪些物件。功用如下：
- 可用於進行初步設計
- 可檢查使用案例規約是否正確
雖然，未被正式納入UML規格，但透過類別圖(Class Diagram) 的Stereotype 可以指定，且大部份的工具也都支援將這樣的類別圖示，自動轉換成對應圖形，十分方便。所以成為橋接需求與系統元件間好用的溝通工具，也常出現在敏捷式分析設計中。由於需求複雜性是層次化的，雖然我們無法降低，但可透過層層的分析加以控制。
三個物件定義如下表(包含與其他相似名詞對應)：
| 項目 | 魯棒圖 | UML | MVC三層式架構 |
| 遠端調用介面 | 邊界物件 Boundary | Interface | - |
| 設備 | - | ||
| 用戶介面 | View | ||
| 應用邏輯 | 控制物件 Control | Process | Controller |
| 業務邏輯 | - | ||
| 資料存取邏輯 | - | ||
| 資料 / 檔案 | 實體物件 Entity | Domain | Model |
而各物件間可不是可以隨便畫上關係的，應符合下列四個繪圖規則：
- Actors can only talk to boundary objects. 角色僅能連到邊界物件
- Boundary objects can only talk to controllers and actors. 邊界物件僅能連到控制物件和角色
- Entity objects can only talk to controllers. 實體物件僅能連到控制物件
- Controllers can talk to boundary objects and entity objects, and to other controllers, but not to actors. 控制物件可以連到邊界物件與實體物件，但不能連到角色
另外，在使用魯棒圖時，有一些建議事項：
- 漸增式建模
- 只對 主要使用案例(UC) 畫圖
- 每張圖應有 2~5 各 控制物件
- 勿關注細節 與 UI
而在魯棒圖中的每一個物件，最終將在系統設計時，被一堆類別(Class)給取代。這些類別的組合，則要滿足在魯棒圖中繪製的物件所定下的規約。
寫在後面
我僅摘要我感興趣的部分，要知如何當架構師的方法，參考的書籍很多嚕，尤其是國外很多大師出了很多經典。不然，你也可以看本次書摘的這本嚕。
另外，本篇標籤分類仍為 “書摘”，未來 “節錄” 將僅適用於報章雜誌收集下的短文之類的。呵~ 在此說明嚕。
- 作者：溫昱
- 譯者：蔡學鏞
- 出版社：碁峰
- 出版日期：2010年05月20日
What we call the beginning is often the end.
And to make an end is to make a beginning.
The end is where we start from.
要達到什麼樣的結局，
取決於甚麼樣的開始。
結局就在開始的地方。T.S. 艾略特