使用案例寫作實務中譯本 — Writing Effective Use Cases ———————————– 作者／Alistair Cockburn/著 譯者／趙光正/譯 出版社／碁峰出版 ISBN／9867727681

內容簡介
完整討論使用案例的關鍵部分，包括參與者、關係人、設計範圍、情節等等。提供完整的使用案例寫作指導，包括寫作步驟與推薦格式。提供一大堆省時有效的使用案例寫作技巧。提供有用的使用案例範例，並且說明範例適用的時機。

這本書的好處就是實例超多，一般的書中對使用案例的介紹都很簡單，或者範例不足，讀一些原則如果沒有範例配合，有時候還真的像在隔靴搔癢。

這本書提出兩個概念：1.把使用案例依照設計範圍(design scope)或者系統範圍(the extent of the system )分為三個層次(第三章)1.Enterprise (business use case) 2.System(system use case) 3.Subsystem(component use case) 2.依照使用案例所達成的目的(goal )分為三層(第五章)1.Summary goal 2.User Goals 3. Subfunctionas 當你在畫使用案例時，思緒先粗再細，就我自己的經驗，高層次的使用案例，數量不會太多，容易控制，也比較能夠用巨觀看事情。管理大量的使用案例時，除了使用高層次的使用案例外，通常也會用到很多使用案例間的關係(第九章,第十章)，或者把使用案例組織一下成套件(package)管理(第十三章)。 還有，就是一般人會問使用案例是否等於需求？不過本書對這部分著墨稍嫌少了一點(第十六章)，還好，它補了一章說明使用案例與整個開發流程的關係(第十七章)，裡面提到使用案例 v.s. 系統特性(System Feature)，作者蒐集了很多的使用案例格式(第十一章)，作者把寫使用案例當成寫作文，所以整本書是在教導你如果寫出一篇篇的短文(使用案例)，當然而會有類似教作文的起承轉合(第六章,第七章,第八章)。

前言

使用案例 (Use Case) 是由 Jacobson 在易利信公司做電信系統時，所發明的一種描述系統行為的工具，並隨著 UML 規格的制訂，而成為普遍被用來作為需求捕捉最關鍵的技術。我是認為，使用案例可以說是這十來年來軟體界最了不起的創見！ 因為它簡單，使用案例圖，利用棒型人偶 (參與者)表達使用系統的使用者與系統需要外部系統的支援服務，而橢圓形的使用案例即是表達一個個系統所提供的功能服務；然後再以純文字的寫作方式，來描述每一個使用案例的需求陳述，也可以說是參與者與系統之間的互動對話，卻又不致牽涉到系統的實做面 (把系統當黑箱)。簡單的圖形，加上文字敘述，就可以建構出從使用者角度來看系統功能觀點的使用案例模型。

不過很奇怪，使用案例易學難精，沒有把握基本精要與原則，很難把圖給畫好 (不容易界定出系統範圍)，更何況是用純文字來寫出需求陳述。耶？ 純文字的寫作這麼困難嗎？ 是的，它真的不容易，我還常建議需求分析人員，多勤讀「古文觀止」，來充實散文的寫作能力。

我大概看了有五本寫使用案例的書籍了 (均為原文著作)，發現到每位作者對使用案例的闡述，歧異還蠻大的，可以說是“各自表述”，而且多少都已經有加入作者本身的觀點，擴展 Jacobson 的使用案例理論。老實說，我對使用案例的技術相當著迷，但學習該技術的前兩年完全不知所云，一點都無法體會出它的本質精髓 (只學會一些使用的功法而已)，直到吸收了兩本好書：“Use Case Requirements in Context”，以及本次書評的主角，才慢慢打開心眼。尤以本書，我起碼看了半年以上，讓我對所謂的層次、目標等級、寫作原則與風格等，可說是奠定了相當清晰的基礎功夫了。

腦力激盪的最佳工具—記錄需求、發掘需求

本書不算薄，22 個章節，外加四個附錄，內容分為三大部分—使用案例的主體、相關議題的討論、寫作提示等。一開始閱讀會有些吃力，尤其第一部份，其實內容有些零散。我是建議要隨時翻閱目錄，瞭解自己在閱讀時的主題與焦點所在，若當下無法體會，其實跳過去也無妨。

第一部份最重要的是當然要瞭解使用案例的本質，以及寫使用案例的格式，Cockburn 提供多種寫作的格式供參考，如單欄/兩欄/RUP，甚至利用 Occam 程式語言、圖形呈現的另類寫作風格，相當有意思！ 另外最有價值的部分，也是 Cockburn 自創的三個目標等級—白雲、海平面、海平面下，來說明使用案例的精確程度，以及適合的目標層級對象。第二部分算是 FAQ 性質的一些主題性的討論。例如最常見的 CRUD (Create, Read, Update, Delete) 與 可參數化 的使用案例該如何描述比較恰當；開發流程中，使用案例所扮演的角色與其它製程產出的關連性；常見的寫使用案例所發生的錯誤 …等，對於實務已經在應用使用案例開發的人員來說，相當具有參考價值。第三部份是我覺得本書最實用的部分了，尤其第 20 章，單一寫使用案例的相關寫作提示，就足以讓需求分析人員受用無窮了，因為以我所看過太多位 SA 所寫的使用案例，幾乎所犯的錯誤，在本章都有提到。所以只要依循本章所列出的十一個寫作提示，要寫出中規中矩的案例敘述，也就不會是什麼難事了。

有意思的是，即使你寫的是中等程度的使用案例，都還來得比其它種類的需求文件還有用，事實上，只要能具可讀性，對整個專案就會有相當的貢獻；再則，使用案例不僅僅只是記錄需求的工具而已，它更可以成為專案成員的腦力激盪工具，來發掘出新的或潛在性的需求，這更是價值斐然！

順應國內短線專案型態—Use Case First

一般而言，使用案例會成為「物件導向」式專案開發的最佳前導工具，雖然它與物件導向一點都沒有關係。本書在國外的評價相當高，但在國內卻不賣座，這多少與本書完全沒有提到如何將使用案例與系統的結構設計至實做的橋接有關，純粹就是在談使用案例的寫作而已。而事實上，國內 95% 以上的專案都是偏以功能導向的開發為主，至於系統內部的結構分析設計，因為時程的壓縮與抽象基礎的素養不足，往往無法做好。功能會直接影響到專案能否被“做出來”；結構則是影響系統的彈性與穩定度。所以個人是主張“務實一點”，先順應國內短線的專案生態，利用使用案例，快速的給直接 mapping 到實做面。

我在實際輔導的經驗中，效果與接受度相當高；雖然是“Quick”，但可不“Dirty”，兩個配套措施是一定要做的：測試案例到測試程式碼，隨時驗證功能的正確性；分析類別的規劃，以符合 3-tier 的 MVC (Model-View-Control) 框架。系統做的出來，開發能力也有比較提升，老闆也比較願意投入更多資源的情況下，再施以結構重整，慢慢粹取出系統最穩定、共用的那一部份。有了使用案例後，我好像就再也沒擔心過能不能“做”得出來，那根本已經不是問題了。

五顆星級的好書，價值多少？

在 Amazon 評價四顆半星的好書，你猜猜看台灣賣多少錢？ NT$ 99，沒錯！ 你沒有看錯，國內販售軟體書籍指標的「天瓏書局」竟然將本書折扣到一折半，不到一百元可以買到寫使用案例叢書中最棒的書籍，但，卻仍舊乏人問津，我真的很難以想像，需求分析人員，省一到兩次的便當錢，總該可以吧？ 好歹，本書真的可以在工作上幫助你太多太多了。