使用用例捕獲業務需求（業務需求的7個實踐原則）

blueski推薦 [2005-7-30]
出處：Rational Edge
作者：Thomas Behrens
 

 

導致區別的七個原則

Thomas Behrens 首席技術官, Alpheus解決方案
本文來源：
http://www-128.ibm.com/developerworks/cn/rational/rationaledge/content/feb05/behrens/

來自Rational Edge：這篇文章基於Simpay，一個通過行動電話操作的支付系統，的業務需求工程項目的經驗，大致描繪了關於捕獲業務需求的七個實用原則

假定你已經有需求工程規範的一些經驗，而且你突然面對一個包括多個公司，並跨越不同商業領域的重大業務需求方案。開始在你的心裡出現問題：用例是否會在這個項目中使用？我應如何決定用例粒度的正確層次？我應如何構建用例模型？我必須裁剪標準的 IBM Rational Unified Process 或 RUP以達到交付標準嗎？這篇文章提供Alpheus，一位國際性的IT顧問，如何在Simpay（一個可共同操作的手持電話支付系統）組織需求工程項目 1 中應對這些問題。它提取我們在項目中所學到的，成為七個實用的原則，它將舉例說明你怎樣在你自己的業務需求計劃中取得成功。

該論述假定讀者對需求工程，使用用例及對RUP的基本協議，有很好的理解。

 

Simpay 是關於開發聯合現在分段的手持電話支付市場的、能共同操作支付的全新架構的第一步 2 。圖 1 顯示業務內容相關的概觀。Simpay 佔領這內容相關的中心位置，使用開放的介面，來整合手持電話商業要求者（代表多個零售商及[或] 內容供應者）和手持電話操作者（代表並認證最終客戶），成為線上金融交易。Simpay 為支付認證，結算並解決手持電話操作者與手持電話商業要求者之間的資金流，提供服務。 3

圖 1: Simpay 商業上下文概觀

業務需求過程被嵌入到一個把支付解決方案（如Simpay 產品）轉變進入市場的大型過程中。產品展現了一個使用手動或自動過程的、從頭建造的、新業務。由於預算必須控製得恰到好處，因此決定延期實現確切的自動化過程，直到業務已經被建模。

整體項目及商業特性可以摘要為：

• 多公司（Orange，Telef a M es，T-Mobile和Vodafone）
• 重視規模方面（支援約二億八千萬客戶）
• 擁有虛擬團隊的多國公司
• 持有名譽方面的潛在影響
• 覆蓋多重專家領域（舉例來說，無線通通訊，財政服務）
• 規則加強器，擁有多種不同的法律約束

這些特性表達了許多關於建立所有企業涉眾、共同的、一致的業務需求集合的重要性和可見度。

我們介紹一個與RUP 結合的過程，跨越Simpay從商業想法到產品部署的專案生命週期。我們把活動和交付產物映射到 RUP的四個階段（初始，精化，構建和產品化）及它們各自的裡程碑。RUP 活動和交付產物最初剪裁為軟體開發過程，然而項目已經有一個非常寬泛的範圍（舉例來說，一個交付產物是新公司的建立，如Simpay Ltd.）。然而，活動和交付產物有時大幅度地偏離 RUP 。而且，這個與 RUP最佳實務相反的進程，並不是可重複的。然而，許多個別交付產物在重複的/增量的基礎上產生，提供早期的評審，驗證和品質保證，以及偶爾依靠早期的活動啟動。

當我們想要在業務層次上捕獲需求，而不指定特定交付產物是手動的或自動的，我們使用 RUP 業務建模規範作為我們的參考規範，並用需求工程的一些元素進行強化。對於我們定製的交付產物結構，參見文章的補充內容。

實踐原則
下面，我們將討論由我們的經驗總結的實踐原則。他們將會協助你：

• 為你的業務需求尋找正確的邊界（原則 1：得到正確範圍）
• 適當結構化你的用例模型（原則 2：向你的用例目標和原則挑戰； 原則3：使用需求屬性決定最好的用例模型）
• 進一步詳細說明你的業務需求（原則 4：分而治之：通過商務參與者分解）
• 適當描述你的業務用例（原則 5：用例描述：闡明“ 是什麼”，而不是“如何做”）
• 串連你的業務用例,避免冗餘，並確認你的需求（原則 6：提出領域模型和原則7：使用實體的生命週期）

原則 1：確定正確範圍
需求管理的目的是為了確定正確範圍。邊界在哪裡呢？誰在裡面而誰在外面呢？這是更高層次的抽象，更為重要的。在範圍方面很小的變化，就可能會帶來與企業所有者相關，將要開展的工作，及項目啟動並執行期限的重大影響。

讓我們回顧圖 1，這次把它當作一個市場視圖。 6 這個視圖顯示購買（購物相互作用）和付款相互作用；它也顯示Simpay作為支付中介。現在，比較圖1與圖2。除了使用不同的記號（UML）之外，圖 2 顯示兩個不同的語境。上面一個是具有銷售功能的商人的語境，它在購買商品用例中表現。下面的一個是 Simpay 擁有的支付功能，用請求支付用例表現。 7

如果你認真地看，你將會看到這個特徵把Simpay從市場視圖分為兩個部分：Simpay 產品和和 Simpay 有限公司。當我們發現 Simpay 產品不僅僅Simpay有限公司（也就是，中心實體）需要，也被移動操作者、及移動商家要求者實體需要時，這種區別是必要的。同時，這些實體識別到產品的功能；因此，所有的三方都在專案範圍內。

這是在斤斤計較嗎？不！它協助我們清晰地建立項目邊界。這意謂著我們可以從早期開始，就能避免不必要的討論。在事後，這些區別可以看得很清楚，除了新的商務活動，為涉及到需求活動的當事者確定邊界。然而，這是值得研究的工作。

圖 2: 商業語境和 Simpay 語境

原則 2: 挑戰你的用例目標
一旦你確定了你的範圍，你可以開始確定用例和參與者。一個通常的問題是用例模型爆炸式快速增長，特別當你正在業務需求的抽象層工作的時候。很快的，你將會發現你需要表達很多內容。從字面上，停留在你的用例模型的頂層以避免“700 用例併發症”。如果你的用例模型正在爆炸式增長，你應該挑戰你的用例粒度。對於 Simpay來說，在最高抽象層，我們以大約二十種主要用例作為結束。記住，一個用例傳遞值的一些東西給參與者；它為參與者實現一個目標。確保所有用例目標都在相同的層次上，並且對於業務建模來說所有目標都在抽象層上。

有一個來自 Simpay 語境的具體執行個體。支付可以立刻實現——支付授權 8 和支付捕獲 9 同時發生，或延期實現——授權在捕獲之前發生。圖 3 顯示了一個可能的使用案例圖。然而，請注意用例所表現的目標並不在同一層次。商家的目標是接受支付。他必須服從管理規則，並把支付事務，分離為捕獲之後的獨立授權，這可能不是他樂意的。同時，你被迫表達在請求支付授權和請求支付捕獲之間的一些關係。一個簡單的解決方案是把這兩個用例，結合為一個稱為Request Deferred Payment的用例。 10 你以更少的用例完成，並進一步得到易於理解的用例建模。

如果在授權和捕獲之間有一個長的時間間隙，那是什麼呢？這你無須關心！時間間隙並不是你分隔用例的指標；尤其是業務用例可以是長期運轉的。決定是否分隔用例的本質標準是他們的目標是否不同。

導致用例膨脹的另外一個危險是我稱之為“睡蓮併發症狀”。當你為一個用例找到一種變化的時候，它就開始了；在 Simpay 例子中，它可能是支付發生的通道（例如，SMS，WAP）。你可能馬上被我們例子中的多用途用例所誘惑（要求使用WAP，SMS等方式立即支付）。也可能存在更多的維數。很快地，你就可以像睡蓮覆蓋池塘一樣，覆蓋你的使用案例圖。相反地，向目標挑戰。如果你做些分析，你將會發現目標對於所有這些用例都是相同的。把焦點集中在本質的用例上，稍後你會知道表現這些變更的更好的方法（舉例來說，在用例描述的特別需求部分）

同時, 當你確定支援目標，如維護重要的業務實體，把它們排除在外，使之獨立並使用自己的圖支援用例包。

圖 3：不同的目標層次

原則 3：使用需求屬性決定最好的用例模型
需求屬性包含需求資訊。優先順序：顯示一個需求 對於 商業使用者有多重要。迭代：表明需求分配到哪個迭代。穩定度：指出哪些需求可能遭受變更。還有更多的屬性，但是，讓我們把目光集中到上述三個屬性上。請確定你在堅持不懈地為你的用例捕獲這些屬性。為什麼呢？因為他們可以使你的過程變成更輕鬆。特別地，你將時常會有關於如何構建用例模型 11 的多種選擇；當你這樣做時，用上述的屬性定位你的用例模型。這將產生最少的重構工作，並聚焦於你的工作。

實際上，考慮下列的指導方針以決定你的選擇：

1. 如果任何的這些指導方針違背原則2，並導致用例增加，不要應用指導方針！
2. 如果兩個用例有不同的優先順序，避免合并它們。
3. 如果兩個用例被分配到不同的迭代中，避免合并它們。
4. 如果兩個用例具有不同的穩定性等級，避免合并它們。
5. 不要為取得不穩定用例的模型花太多時間；這個功能可能根本上不需要改變。現在，把焦點集中在穩定用例上，以得到正確的模型。

記住：你如何重構用例模型將會影響其它的工作。業務使用者將不得不找到適合新模型的方法，對於不同的可交付變數的追蹤也將需要被更新。從一開始就正確地構建模型，也將節省其他人的時間。

在上面的例子中，我們堅決反對把延期和即付功能，歸併到一個單一用例中（如，請求支付），因為“初始Simpay開發，可以而且也會包括延遲的或直接的支付”可能很快會被產生；無論選擇哪種支付機制，其它的將是以後版本的範圍。這種用例反覆屬性的變化，導致分裂為即付請求和遲延支付請求。

原則 4：分解和規則 – 通過商務參與者分解
現在你有一個結構良好並可以理解的業務用例模型。接下來你要往哪裡去呢？一件重要的事情是 不要 把功能分解到你的用例模型中；即，不要把你的用例打破成較小的部分。這樣的部分將會變成孤立的，違反用例步驟的最重要的優點之一：在參與者的目標語境中呈現需求。相反地，答案是遞迴地在當前語境中，基於用例步驟重新應用。

讓我們回過頭看看圖 3。底部的 Simpay 產品語境顯示由Simpay 有限公司，移動操作者和移動商業要求者實現的Simpay 產品。這些實體的 RUP 術語是 商務參與者 。這些商務參與者合作完成 Simpay 產品功能。一個，二個，或所有的商務參與者都參與每個 Simpay 產品用例。通過這一資訊，你可以為每個商務參與者（由Simpay產品語境分配的）產生一個語境。每個語境由下面二者建立：(1)通過商務參與者劃分用例，和(2)從現有的商務參與者派生出新的參與者。這個過程在圖 4 中舉例說明，它為移動操作者顯示了一個執行個體結果。帶有兩段用例和一個新參與者（Simpay 有限公司）的新的移動操作者語境已經由更高抽象層派生出來。現在你能分開控制（相互調用）新的語境。 12

這與功能分解有什麼不同嗎？是的！取替在Simpay 產品語境（不是由參與者目標激發的）建立孤立的部分的是，你已經用新參與者表現的精確目標，建立了更小的域。看看移動操作者語境的結果。明顯地，Simpay 有限公司代表移動業務需求方（依次代表貿易商）做這些事情。然而，移動操作者的領域是自我包含的；它不需要瞭解Simpay 有限公司參與者做什麼。相反地，功能分解方式將把用例分解成許多部分：獲得商業細節；進行外匯交易；授權支付；捕獲支付。哪種方式更適合管理方案範圍呢？

圖 4: 商務參與者劃分。

原則 5: 用例描述：陳述“是什麼”，而非“如何做”
很幸運；我們擁有感興趣的業務代表，他們很快地就適應了用例方式，和有能力的技術隊伍，他們的目標是把需求自動翻譯成科技規範。然而，如同它被產生一樣，業務代表儘可能地由狀態激發，而且科技隊伍對於強加於他們之上的不必要的限制因素感到不安。用例通過描述產品做什麼來展現需求，以達到參與者的目標。“ 做什麼 ”和“ 如何做 ”間的產品活動是人們特別是全球性的分布化團隊不太清楚的一些事情，誤解是正常的。這裡有四種類型的指導方針可以協助我們避免這些錯誤：

1. 特定的自然語言表達有技術內涵。（舉例來說，迴路）。如果你使用這些表達，確定他們在作為技術設計建議時不會被誤解。
2. 業務用例描述商業流；它們決定誰是資訊的來源，以及誰是目標。它們沒有暗示流的技術實現。沒有明確定義資訊是否要推或拉，資訊交換是批量的或線上的，是否要使用緩衝。這樣的技術性的決斷主要關聯到非功能需求。確定人們理解業務用例中的詞，例如聯絡、請求，不要為基本的技術交流基礎設施暗示技術約束。
3. 爭取涉及參與者及產品間的簡單交流模式。嘗試遵照同步請求/響應 13 溝通模型。這暗示一個請求的響應在用例描述持續情況下，或者被接收，或者不被接收（舉例來說，在逾時的情況下）。當用例已經在它的描述中繼續前進時，它不可能接受響應。請求的表達是充分的，並且它簡化了描述。應強調的是，它並不暗示同一模型的技術性實現。
4. 當你為用例步驟編號時，人們通常認為你正在下令應該如何完成功能。 14 然而，用例步驟的順序通常僅僅關係到參與者的下一個互動。當在這樣一組步驟的特定順序被託管時，請習慣於跟隨明確的狀態。

交流這些指導方針是重要的。對於 Simpay 來說，我們在產品概述文檔（見頁面側邊欄）捕獲它們。在RUP中最適合做這件事的地方是用例模型，指導方針文檔。更為重要的是，如果你正工作於定製的過程之中，要有一個實驗。選取一個用例，並努力與整個隊伍前進一致，這樣每個人都會對你將如何產生事務及管理期望，感到滿意。

原則 6：提出領域模型
在 RUP 中一個領域模型（見圖 5）被定義為：在域的語境中捕獲最重要類型的對象。領域模型是業務分析模型的一個子集，業務分析模型包含描述商務參與者（見原則4）和業務實體如何獲得用例功能的業務用例實現。領域模型很有用，即使你不提出業務用例實現。它通過為你的用例描述提供具有精確含義的通用詞彙術語，來串連你的各個用例。領域模型確保相同的術語指向相同的業務實體。正好也捕獲如下類型的需求：

• 業務實體和它們的多樣性之間的聯絡（舉例來說，一個移動使用者使用一個或多個行動電話）
• 限制因素（舉例來說，一個支付不能夠超過一個特定的數值）和推導規則（舉例來說，利息計算），尤其當這些不僅僅與一個用例相關時

結構化你的領域模型文檔，為這一資訊（見到圖 5）加入預留位置。在我的經驗中，業務使用者對這些細微改進的形式感到相當滿意，而且它為你提高穩定性和完全性檢驗：

• 所有的業務實體及它們的屬性是否都已經定義？
• 你是否已經捕獲了所有的聯絡？
• 所有涉及的業務實體是否至少在一個用例中？
• 所有涉及的業務實體是否都存在於領域模型的用例中？

當創造領域模型的時候，除了根據常識和你的讀者偏好之外，你能使用下列的指導方針：

1. 使用圖協助描述，尤其是顯示業務實體間的彼此聯絡。
2. 寧願冗餘的泛化；否則，你可以從你的業務使用者那裡要求。
3. 對於簡單的關聯類型使用屬性；否則，你將會使你的圖混亂。
4. 當屬性的類型會明顯避免製造困惑時，忽略它們。
5. 如果識別符（比如使用者ID）與商業無關，忽略它們。
6. 只有當參與者名字有助于澄清語境的時候，才使用它們。否則，意味著把業務實體作為參與者命名，以避免弄亂你的圖。
7. 產生相關條目的簡單導航技巧。領域模型將會時常被用於尋找資訊。對於 Simpay來說，我們使用IBM Rational Rose為領域模型捕獲資訊，使用IBM Rational SoDa來產生簡單的導航文檔。

一個領域模型如何與一個術語表相關聯？一個術語表定義了項目中使用的重要術語。以這個定義為基礎，一個領域模型是術語表中術語的一個子集。但要避免冗餘：在術語表或領域模型中定義一個條目，但是不要在兩者裡面都下定義。通常，當你知道更多關於你的商業域時，術語從術語錶轉移到領域模型。然而，你的術語表對於那些不存在於業務實體中的術語，仍然是有用的交付產物內容。

圖 5：領域模型圖和相關文本。

原則 7: 使用實體生命週期
實體生命週期在商業規範中未得到充分利用，但是，一個好的解決方案是可用的：UML狀態圖。 你為什麼要使用這些，以及它們如何關聯到用例？業務實體（舉例來說，一個移動使用者）通常有跨用例的生命週期。一個在狀態之間的用例過渡（通常是不同的，狀態圖給一個統一視圖，它關於你的重要業務實體在哪裡，如何被操縱。圖 6 顯示一個關於移動使用者業務實體的例子。轉變表現了維護移動使用者的用例 15 ，並在不同狀態間轉化它。

作為一個分析師，你也可以使用狀態圖保持你的需求集的一致性和完整性。我的業務實體是如何成為實物的呢？我是否已經錯過了一個重要的狀態？我是否已經描述我的用例中支援的所有轉變的所有狀態？我是否錯過了影響轉變的特別條件？

限定最重要的業務對象的生命週期，而在你的文檔中描寫所有狀態。你的用例將以正確定義的領域模型術語，描述涉及的這些狀態，在保持可讀性的情況下，把歧義從你的規範中排除。一個用例描述（涉及到圖 6 所示的執行個體）會如下被看到：

4. 移動操作者確認移動使用者並未被禁止。

這種禁止狀態 指明了移動使用者所處的狀態，並為狀態展現了一個非常精確的定義。依賴參數選擇，你可以使用格式來強調文本中的狀態。

生命週期最好作為由業務實體定義（5所示）耦合的附錄，置於領域模型中。你能夠使用IBM Rational Rose來維護狀態圖並文檔化狀態，而且你也可以使用IBM Rational SoDa 產生易於操縱的文檔。

採用這種方式，當你把實體生命週期置於業務使用者之前時，你可以就像技師 16 一樣，在沒有做出需求時，平衡使用它們的好處。

一個對於未來的調查：通過模型驅動架構， 17 你將會獨立於一個特定的平台，受益於預先指定的精確性態。除此之外，可啟動並執行 UML 將會使你可以在你開始著手不惜代價的細分你的需求之前，確認你前面的模型。

圖 6：狀態圖：手機使用者 -- 生命週期

總結
用例是捕獲業務需求的一個優秀的方法。只要你定義適當的抽象層，以支援可理解及可追蹤的全部細節，他們就可以通過大的項目很好地伸縮。僅僅增加用例的數目並不起作用。確認你的需求的業務使用者，會對基於用例的方法感到非常舒服。關於這種方法，精心描述你的自動化業務用例，讓技術需求的技術團隊通常更容易被接受。

因此，如果你被分配了一個複雜的業務需求項目，不要絕望。通過應用用例方法於需求工程，一個由可靠的開發過程及本文中呈現的原則，細化支援的方法，你就能克服許多挑戰，並使方案成功。正如我所做的，你甚至可能已經發現，它是一個令人滿意的實踐。

感謝
我很感謝在 Simpay 中的人們，因為他們在本文中描述的方法中所承擔的工作。特別是Tim Jones，Simon Richards，Martin Rugfelt 和 Jim Wadsworth。特別感謝我的同事Martin Elliffe提供了有協助的說明及建議。

 

腳註
1在這該文章中，我使用需求工程，作為業務需求工程一個簡稱。

2本文所用的例子來源於寬泛的Simpay語境。一些已經被簡化了，僅僅用來論證要點和要求的觀察保密性。因此，請讀者不要把這些例子，理解為真實的Simpay活動。

3更多關於 Simpay 商業模型的細節，見 www.simpay.com。

4更多關於 RUP 的細節，見 Philippe Kruchten的《The Rational Unified Process. 》，Addison-Wesley，2000及http://www-306.ibm.com/software/awdtools/rup/index.html。

5非迭代交付的主要障礙是，IT解決方案和它的操作者是由第三方轉包，並通過一組法律合約整合到整個過程的事實。一個迭代過程會在這些法律合約中增加重要的複雜性。

6儘管不是與RUP關聯的標準4+1 視圖的一部分，但這一視圖是基本的。在最後，你不得不出售你的產品。

7兩個語境有很明顯的關係。作為在商業語境中購買產品用例的一部分，商業觸發器支付請求使用 Simpay 語境中的例子。

8商人確定手機使用者能支付和為他儲備的貨幣。

9商人請求應支付給他的金額。

10實際上，你甚至可以更進一步考慮，並有一個獨立的支付請求用例：我們的確決定反對它。理由是範圍管理, 但是繼續向下看。

11我不在這裡討論擴大並包括聯絡。以我的經驗，最好在你的業務用例模型中避免這些聯絡。

12在《 The Object Advantage》（Addison-Wesley，1995，第173頁），E.A. Jacobsen 介紹了一個演算法，用於映射一個業務用例模型到一個系統用例模型。這裡使用一個類似的演算法，把一個業務用例模型映射到不同語境中的另一個業務用例模型。

13在確定的環境中，你可能有一個不存在響應的請求。如果響應沒有業務含義，這與被提議及將被使用的模型完全一致。

14相反地，我強烈建議你使用一個有細密紋理的編號樣式，作為用例描述。它允許你改良一致性、完整性檢查及參照。

15如果一個用例在多種狀態間轉換為業務實體。你可以轉換為備選流或一組步驟（舉例來說，使用標籤或你用例描述的數字記號）。

16讓我強調一下，它們可能看起來象技師，但是它們不是技師，因為它們僅僅書寫商業決策的文檔。

17更多關於模式驅動架構的細節，參見 http://www.omg.org/mda 和 Behrens，Richards的《 StateLator in Advanced Information Systems Engineering》，Springer，2000。

參考資料

• 您可以參閱本文在 developerWorks 全球網站上的 英文原文。