軟件項目所面臨的最大挑戰之一，便是決定由確定需求轉為系統設計的過程應該在什么時候開始，且該如何進行。類似以下的問題將不斷地冒出來：我什么時候才可以完成使用個案？我需要先將所有的使用個案詳細闡明后，再跳到系統設計嗎？在設計時，我應該先處理哪些需求？
大多數的人似乎都能理解做對了決定所帶來的好處，和做錯了決定而帶來的麻煩一樣地多。起步得太早，項目將面臨草率制定需求便進行系統設計的風險；起步得太晚，您所要負擔的風險更大，因為項目的生命周期勢必將因高風險的架構決策而延宕。此外，在準備由需求轉向設計的工作產出時，您還得留心別失去了原始的精神（例如誰負責做決定？在某些需求里有沒有特定的關系存在？）
這篇文章將告訴您如何由需求制定順利地轉變至系統設計的階段，重點會放在一些尤其容易出狀況的項目上。首先，我們先來看看項目小組在開始設計之前，應如何利用使用個案。接下來，再檢測所謂在架構上定義明確的需求。最后，我將解釋如何運用使用個案體現（use-case realizations）作為重要的工作產出，并成為由需求制定轉為系統設計的橋梁。
揭露風險是美事一樁
根據過去的經驗看來，我們都知道傳統的瀑布法（waterfall approach）軟件開發方式，并沒有辦法減低在項目生命周期早期的巨大風險。這是由于一些高風險性的決策，如項目的架構方向等，在開始撰寫程序代碼之前都沒有被好好測試過。它可能導致嚴重的后果；許多瀑布式項目因此而在相當的投資及關注之后，才又被削減或整個取消掉。
Rational Unified Process (RUP) 因為具有以下兩種關鍵特性，而和上述的方式形成對比：一， RUP具備風險基礎（risk-based）；二，RUP具備架構精神。RUP會促使項目團隊在早期便確立需求，除了面對可能發生的巨大風險之外，也讓他們及早做好計劃以便降低這些風險。這些所謂的架構明確（architecturally significant）的需求，基本上在RUP的初始階段（Inception phase）是顯而易見的，它們也將成為規劃階段（Elaboration phase）的第一個開發周期（iteration）中做進一步分析與設計的標的。
面對風險對項目開發來說，其實是美事一樁，因為它會要求項目團隊盡快地發展出解決之道。在不斷向前邁進的過程中所面臨的挑戰，是必須設法回答這些重要的問題：項目團隊在開始著手進行設計之前，應該如何利用使用個案呢？
在于廣而不在深（A Mile Wide and Five Inches Deep）
項目在架構上能明確定義使用個案（見附文）之前，它必須設法充實需求內容，以便針對風險所在做出明智的決策。至于該充實到什么樣的程度呢？把握住“在于廣而不在深”的關鍵就對了。
在項目的初始階段，我對項目團隊的標準作業程序是讓他們達成以下任務：
1. 經過討論后，確認項目關系人以及主要的系統產品特性（RUP的愿景產出，Vision artifact）。
2. 經由腦力激蕩過程，列出事件清單，先確認行為者（人員、其它系統、硬件裝置、以及定時器）有哪些，以及它們將與系統互動出哪些事件。
3. 再次腦力激蕩，看看哪些使用個案可以滿足這些事件。
4. 針對每一個使用個案，完成一使用個案樣版，至少確認出關鍵路線（key pathways）。這些關鍵路線可以區分為幾種類別：最常見的或是快樂路徑（happy path）、快樂路徑的其它選擇，以及例外路線（exception paths）等等。
5. 時間允許的情況下，把每個使用個案的快樂路徑步驟詳細列出，或至少列出該項目的中樞使用個案的快樂路徑。
6. 確認代表最大風險所在的需求是哪些。
這些任務可以在一個開發周期里完成，如果需要的話，在較大的項目里，還可以在相關的使用個案里循環運用。
就這樣的項目觀點來看，項目團隊其實對整個項目的廣度都有所涉獵，但卻涉入不深。以該角度說來，我們不能斷言所有的功能需求都已被了解。然而，對于那些可能面臨最大的架構風險的需求，我們確實有了足夠的認知。
行為者和使用個案在做些什么？
多年來專家們始終在努力要構筑出最好的方式來引發，記錄，并追蹤功能性需求。這些方式從迷你規格書（mini-specifications）－一種以段落的型式將需求訴諸文字－到利用圖形展現每個需求的控制流程，包羅萬象。
Rational的Ivar Jacobson在Ericsson從事復雜的電子通訊項目時，就成了應用使用個案概念的先軀。這種使用個案的方式首先著重在確立應用軟件的行為者（Actors）或使用者為何。行為者基本上以四種型式存在：人員，其它系統，硬件裝置，或定時器。系統必須能夠滿足他們的需求，這個目標乃藉由使用個案來完成。
使用個案代表著主要的功能類別，由應用系統的使用者所定義出來；最終提供可計量化的數據給行為者的，就是使用個案。使用個案圖（use-case diagrams）是由每個使用個案的使用個案樣版所完成的。圖１表示了使用個案和行為者之間的關系。
＜圖１＞下訂單的使用個案圖
如果想知道更多的行為者與使用個案相關信息，請參考以下資源：
參考網站：
http://www.rational.com/uml/index.jsp
http://www.Usecases.org/
http://www.therationaledge.com/admin/archives.jsp (search for Use Cases)
參考書籍:
Alistair Cockburn所著, Writing Effective Use Cases。 由Addison-Wesley出版社于 2002。9年出版。
架構明確的需求
與項目團隊一起工作時，我通常把重點放在一些架構明確的涵蓋領域（coverage areas，也就是具有高風險的部份，見表１）。表１ 架構明確的涵蓋領域
| 涵蓋領域 | 風險因子 |
| 1. 組織內還沒有在其它專案中應用國的新技術或工作 | 確認組織對于使用新技術是不是還不太在行。 |
| 2.客戶因為新技術而產生的全新或修訂國的企業流程。 | 面臨的風險在于，客戶在新技術上的工作流程可能未經過測試。舉例來說。如果銀行分行把它的帳戶資料輸入與獲取的流程轉換到較輕薄的Client端，以Web_Base應用系統處理，那么該應用系統可能不會象以前那種集中的方式那樣，在工作流程及使用者界面上皆較具有彈性。 |
| 3.有時效性的流程（Time based processing） | 在幫助有時效性的時間流程上，想找到又耐用、又現成不修改的產品，可以說是少之又少。許多應用軟件若不是需要量身定做，要不就是得籍由先前采購的元件加上程式碼加以修正。 |
| 4.批次作業流程（Batch processing） | 別以為新一代的技術興起后，批次導向的作業就不見了。這知識個常見的誤會，批次流程可以是架構中一個很精巧的部分。如何在批次與即時作業之間取得平衡是企業邏輯里很微妙的一環。 |
| 5.多重面版式互動（Multi-panel interactions） | 需要整個流程的正式管理法則（工作流程管理）這主要是針對Web_Base的解決方案來的，因為Web的本質就在于它的“非正式性”。軟件產商對多頁式互動產品的正式管理方式，視其復雜程度與影響曾層面而有所不同。 |
| 6. 安全性、追蹤、與記錄需求（Security, logging, and archiving demands） | 大多數的客戶都渴望他們先前所采購的解決方案，可以具有單一登入(single sign-on, SSO)的功能，并且整合安全性與獲取方面的能力。要將之整合進全面性的解決方案之中著實得花不少的工夫。 |
| 7. 正確對應管理（Persistence management） | 如果解決方案是以物件導向技術為基礎，那么就必須特別注意在物件對應到關聯式存放（relational stores）時不可發生錯配的情形。 |
| 8.品質控管（Quality of service） | 效能永遠是我們考慮的重點。雖然在規劃階段初期也許不適合進行量化測試（volume testing），但模擬工具仍然可以提供我們一些估測未來產出的有意義的數據。 |
涵蓋領域 風險因子 1. 組織內還沒有在其它專案中應用國的新技術或工作 確認組織對于使用新技術是不是還不太在行。 2.客戶因為新技術而產生的全新或修訂國的企業流程。 面臨的風險在于，客戶在新技術上的工作流程可能未經過測試。舉例來說。如果銀行分行把它的帳戶資料輸入與獲取的流程轉換到較輕薄的Client端，以Web_Base應用系統處理，那么該應用系統可能不會象以前那種集中的方式那樣，在工作流程及使用者界面上皆較具有彈性。 3.有時效性的流程（Time based processing） 在幫助有時效性的時間流程上，想找到又耐用、又現成不修改的產品，可以說是少之又少。許多應用軟件若不是需要量身定做，要不就是得籍由先前采購的元件加上程式碼加以修正。 4.批次作業流程（Batch processing） 別以為新一代的技術興起后，批次導向的作業就不見了。這知識個常見的誤會，批次流程可以是架構中一個很精巧的部分。如何在批次與即時作業之間取得平衡是企業邏輯里很微妙的一環。 5.多重面版式互動（Multi-panel interactions） 需要整個流程的正式管理法則（工作流程管理）這主要是針對Web_Base的解決方案來的，因為Web的本質就在于它的“非正式性”。軟件產商對多頁式互動產品的正式管理方式，視其復雜程度與影響曾層面而有所不同。 6. 安全性、追蹤、與記錄需求（Security, logging, and archiving demands） 大多數的客戶都渴望他們先前所采購的解決方案，可以具有單一登入(single sign-on, SSO)的功能，并且整合安全性與獲取方面的能力。要將之整合進全面性的解決方案之中著實得花不少的工夫。 7. 正確對應管理（Persistence management） 如果解決方案是以物件導向技術為基礎，那么就必須特別注意在物件對應到關聯式存放（relational stores）時不可發生錯配的情形。 8.品質控管（Quality of service） 效能永遠是我們考慮的重點。雖然在規劃階段初期也許不適合進行量化測試（volume test ing），但模擬工具仍然可以提供我們一些估測未來產出的有意義的數據。
在評估使用個案的能力時，請記得它至少要能夠涵括表１所列出的一種或一種以上的涵蓋領域。在項目初期最容易發生的第一個錯誤步驟，便是確認了一些很容易被建置起來的需求，但它們對減輕架構上的風險卻沒有什么幫助。
對整個使用個案而言，使用個案的路線（use-case pathways）應該是搜尋架構明確的需求的重心。它們應該由所有的使用個案中描繪出來。在規劃階段的第一個開發周期當中，我試著避免過多的CRUD路線（Creat／Read／Update／Delete，新增／讀�。薷模瘎h除）。雖然它們對涵蓋領域可能有所助益，但是卻容易導致其它更多重要的部份被忽略掉。
最重要的一個開發周期
無庸置疑地，在規劃階段的第一個開發周期，的確是整個項目進行中最重要的一環（參見圖１及RUP附文）。在這個開發周期里的輸入項，稱之為架構原型（Architectural Prototype），便是在初始階段（Inception phase）結束時所選擇出來的架構明確的需求。
項目團隊將架構明確的使用個案路線向下延展，也是在規劃階段的第一個開發周期里完成。所有的企業規則與附屬品，都在此時完整地填充進來。這時加進項目里來的，不只是更多的功能知識而已，還有進一步的為了健全架構的測試。當規劃階段完成后，就絕對不要再做任何困難的架構決策了。其余的使用個案路線，則應該繼續在規劃（Elaboration）、建置（Construction）、甚至轉變（Transition）等階段的后續開發周期里做更詳細的陳述。
The Rational Unified Process (RUP)
如圖２所示，RUP包含了四個階段和九個工作流程。所謂的開發周期（iteration），指的是在九個工作流程中，垂直地將項目區分開來的部份，它是由每個工作流程里的活動（activities）所描繪出來的。每個開發周期通常都包含了由九個工作流程而來的要件（elements）。其所導致之任務集合，便構成了我們所知的周期計劃（iteration plan）。一個階段里可能有多個開發周期，至于其數量的多寡，通常便成為一個項目的技術復雜度與規模大小的直接因素。在RUP產品里則對這四個階段都各提供了一個周期計劃的樣本。
在每個階段結束時，都會有一個里程碑的標示。RUP四階段的里程碑分別是：Lifecycle Objective（生命周期目標）, Lifecycle Architecture（生命周期架構）, Initial Operational Capability（初始操作能力）, 與Product Release（產品交付）。
RUP的開發周期模型和傳統瀑布式的模型不同，它認可在范圍寬廣的工作流程（例如需求制定與系統設計等）當中所訂定的活動，是可以實際上在項目的生命周期當中同時發生的。
如果想知道更多關于RUP的信息，請參考下列信息來源：
參考網站：
http://www。rational。com/products/rup/index。jsp
http://www。therationaledge。com/admin/archives。jsp (搜尋RUP)
參考書籍：
Philippe Kruchten著，The Rational Unified Process: An Introduction,第二版，由Addison-Wesley出版社于2002年所出版。
Use-Case Realizations：需求制定與系統設計之間的橋梁
由需求制定順利轉變到系統設計的關鍵核心，在于一個能將這兩個工作流程直接綁在一起的工作產出（artifact）。項目團隊運用使用個案體現（use-case realization）作為他們的轉變產出（transitional artifact）。這個系統設計的活動，是在規劃階段的第一個開發周期里發生的。
所謂的使用個案體現，指的是使用個案的設計觀點（Design View）。一開始的時候，使用個案只定義了使用者要的是“什么”。而使用個案體現則是明確指出使用個案要“如何”建置起來的轉變組件。然而，使用個案體現事實上是個復合式的工作產出，它還包括了其它的設計模型以表示實際上的體現（realization）。一般在體現里最常使用的模型是UML循序圖（sequence diagram）及／或合作圖（collaboration diagram）。
項目可以利用Rational Rose (見圖３)，以圖型化的方式來表示使用個案體現。在Use-Case View里的使用個案與Logical View里建立的使用個案之間，會建立起一典型的依賴關系（dependency）。
＜圖３＞在Rational Rose里的Use-Case Realization
這樣的關系在實際的使用個案中，并不只是好看而已。還記得在Use-Case View里的使用個案包含了數條路線嗎？這些路線是由無數條企業規則結合出一連串的步驟，形成路線的架構，完全根據使用者定義出來。我們現在就是依循這些步驟，在Design里塑模對象訊息之間的集合，以達成行為者的目標。這種訊息傳遞的過程可以用以下兩種圖之一來塑模：循序圖（Sequence）或合作圖（Collaboration）。（注：我發現在實務上進行項目時，比較傾向單一使用循序圖或合作圖兩者之一，而不�；煊脙烧�。）
＜圖４＞在Use-Case Realizations里的循序圖（樹狀展示）
在圖４里的樹狀觀點，展現了在每個使用個案體現里的循序圖如何進行擴展。在使用個案中，每一條關鍵路線里都會建立一份互動圖。一開始在規劃階段的第一個開發周期中，這代表著只有這些路線是被選擇來充實高風險項目的內容的。
Use-Case Realization：當一個不夠用時
在我最近參與的一項項目計劃中，出現了在Use-Case View里的每個使用個案需要不只一個使用個案體現的情形。通常這意指該使用個案所需要的是一個多重技術的解決方案。舉個例子來說，在下訂單的這個使用個案里，你可能會有一個額外的非功能上的需求，希望下訂的方式除了在web在線下訂之外，也可以經由PDA的無線接口或類似的方式處理。在這種情形下，最好便能有兩個使用個案體現，一個處理Web的交易，另一個則處理無線方式的交易（參見圖５）。
＜圖５＞同一個使用個案的兩個體現
技術上而言，需要兩個體現的原因，在于它們的解決方案差異很大。在Web這一案上，假設我們使用的是Java，一定會有Servlet classes，和一些其它的support classes，是絕對不會拿來用在無線方式里的。然而，在這兩種不同的技術方案中，我們卻可以省下一些共通訊息重復傳遞的工夫。這么說好了，當一切就緒時，由entity classes（例如訂單，客戶）實際到系統里取得訂單的這段企業流程，在這兩種方案里其實是完全相同的。
因此在這個例子里，由網絡下訂單的體現互動圖，與無線方式下訂單的體現互動圖，兩者都會指向同一個處理entity classes訊息傳遞的互動圖。
這就是由需求制定轉向系統設計的過程當中的使用個案體現。在我舉辦的座談上，曾經有個參與者問道，像這樣讓體現直接指向需求架構，會不會有些危險呢？我的回答是，其實它再自然也不過了。就如同對象導向的觀念讓我們了解，現實世界中的實體代表著架構與行為兩種概念一般，使用個案體現也同樣可以代表從自然世界到使用個案中的Design View之間的轉變。
物以類聚
在過去的生命周期解決方案里，對于需求搜集到系統設計的活動轉變過程，總是充滿了一股不可解的神秘氣氛。需求制定的過程通常都訴諸文字型式，以段落方式來描述，而可視化的設計文件對這些需求卻完全無法進行追蹤。這種記錄靜態需求再將之轉成設計產出的過程，在內容上常有所漏失，也常�；煜耸褂谜咴葘ο到y的期望。
相反地，類似RUP的開發過程，可讓您在任何軟件開發項目中，了解風險所在而對癥制定需求。使用個案體現為那些在初始階段粗略捕捉到的需求，提供了類似現實世界環境的Design View。而在規劃階段的第一個開發周期里便鎖定使用個案路線，了解項目的最大風險所在，更大大地增進了項目團隊在未來開發周期里成功的機會。
千萬別勉強接受那些無法在各個項目階段中轉移的工作產出。每一個工作產出都應該是可以追蹤的，不管是在項目生命中往前或往后追溯。從確認需求到系統設計之間的轉變過程，并不是什么神秘事件，沒什么大不了的。它應該是個自然的過程，很容易解釋，也很容易讓所有的項目團隊成員都了解才是。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
