| 導致區別的七個(gè)原則  |
級別: 高級 Thomas Behrens, 首席技術(shù)官, Alpheus解決方案 2005 年 2 月 15 日 來(lái)自Rational Edge：這篇文章基于Simpay，一個(gè)通過(guò)移動(dòng)電話(huà)操作的支付系統，的業(yè)務(wù)需求工程項目的經(jīng)驗，大致描繪了關(guān)于捕獲業(yè)務(wù)需求的七個(gè)實(shí)用原則。  該論述假定讀者對需求工程，使用用例及對RUP的基本協(xié)議，有很好的理解。 Simpay 是關(guān)于開(kāi)發(fā)聯(lián)合現在分段的手持電話(huà)支付市場(chǎng)的、能共同操作支付的全新架構的第一步 2 。圖 1 顯示業(yè)務(wù)上下文的概觀(guān)。Simpay 占領(lǐng)這上下文的中心位置，使用開(kāi)放的接口，來(lái)整合手持電話(huà)商業(yè)要求者（代表多個(gè)零售商及[或] 內容供應者）和手持電話(huà)操作者（代表并認證最終客戶(hù)），成為在線(xiàn)金融交易。Simpay 為支付認證，結算并解決手持電話(huà)操作者與手持電話(huà)商業(yè)要求者之間的資金流，提供服務(wù)。 3  圖 1: Simpay 商業(yè)上下文概觀(guān) 業(yè)務(wù)需求過(guò)程被嵌入到一個(gè)把支付解決方案（如Simpay 產(chǎn)品）轉變進(jìn)入市場(chǎng)的大型過(guò)程中。產(chǎn)品展現了一個(gè)使用手動(dòng)或自動(dòng)過(guò)程的、從頭建造的、新業(yè)務(wù)。由于預算必須控制得恰到好處，因此決定延期實(shí)現確切的自動(dòng)化過(guò)程，直到業(yè)務(wù)已經(jīng)被建模。 整體項目及商業(yè)特性可以摘要為：
這些特性表達了許多關(guān)于建立所有企業(yè)涉眾、共同的、一致的業(yè)務(wù)需求集合的重要性和可見(jiàn)性。 我們介紹一個(gè)與RUP 4 結合的過(guò)程，跨越Simpay從商業(yè)想法到產(chǎn)品部署的項目生命周期。我們把活動(dòng)和交付產(chǎn)物映射到 RUP的四個(gè)階段（初始，精化，構建和產(chǎn)品化）及它們各自的里程碑。RUP 活動(dòng)和交付產(chǎn)物最初剪裁為軟件開(kāi)發(fā)過(guò)程，然而項目已經(jīng)有一個(gè)非常寬泛的范圍（舉例來(lái)說(shuō)，一個(gè)交付產(chǎn)物是新公司的建立，如Simpay Ltd.）。然而，活動(dòng)和交付產(chǎn)物有時(shí)大幅度地偏離 RUP 。而且，這個(gè)與 RUP最佳實(shí)踐相反的進(jìn)程，并不是可重復的。 5 然而，許多個(gè)別交付產(chǎn)物在重復的/增量的基礎上產(chǎn)生，提供早期的評審，驗證和質(zhì)量保證，以及偶爾依靠早期的活動(dòng)啟動(dòng)。 當我們想要在業(yè)務(wù)層次上捕獲需求，而不指定特定交付產(chǎn)物是手動(dòng)的或自動(dòng)的，我們使用 RUP 業(yè)務(wù)建模規范作為我們的參考規范，并用需求工程的一些元素進(jìn)行強化。對于我們定制的交付產(chǎn)物結構，參見(jiàn)文章的補充內容。 下面，我們將討論由我們的經(jīng)驗總結的實(shí)踐原則。他們將會(huì )幫助你：
需求管理的目的是為了確定正確范圍。邊界在哪里呢？誰(shuí)在里面而誰(shuí)在外面呢？這是更高層次的抽象，更為重要的。在范圍方面很小的變化，就可能會(huì )帶來(lái)與企業(yè)所有者相關(guān)，將要開(kāi)展的工作，及項目運行的最后期限的重大影響。 讓我們回顧圖 1，這次把它當作一個(gè)市場(chǎng)視圖。 6 這個(gè)視圖顯示購買(mǎi)（購物相互作用）和付款相互作用；它也顯示Simpay作為支付中介?，F在，比較圖1與圖2。除了使用不同的記號（UML）之外，圖 2 顯示兩個(gè)不同的語(yǔ)境。上面一個(gè)是具有銷(xiāo)售功能的商人的語(yǔ)境，它在購買(mǎi)商品用例中表現。下面的一個(gè)是 Simpay 擁有的支付功能，用請求支付用例表現。 7 如果你認真地看，你將會(huì )看到這個(gè)特征把Simpay從市場(chǎng)視圖分為兩個(gè)部分：Simpay 產(chǎn)品和和 Simpay 有限公司。當我們發(fā)現 Simpay 產(chǎn)品不僅僅Simpay有限公司（也就是，中心實(shí)體）需要，也被移動(dòng)操作者、及移動(dòng)商家要求者實(shí)體需要時(shí)，這種區別是必要的。同時(shí)，這些實(shí)體識別到產(chǎn)品的功能；因此，所有的三方都在項目范圍內。 這是在斤斤計較嗎？不！它幫助我們清晰地建立項目邊界。這意謂著(zhù)我們可以從早期開(kāi)始，就能避免不必要的討論。在事后，這些區別可以看得很清楚，除了新的業(yè)務(wù)活動(dòng)，為涉及到需求活動(dòng)的當事者確定邊界。然而，這是值得研究的工作。  圖 2: 商業(yè)語(yǔ)境和 Simpay 語(yǔ)境 一旦你確定了你的范圍，你可以開(kāi)始確定用例和參與者。一個(gè)通常的問(wèn)題是用例模型爆炸式快速增長(cháng)，特別當你正在業(yè)務(wù)需求的抽象層工作的時(shí)候。很快的，你將會(huì )發(fā)現你需要表達很多內容。從字面上，停留在你的用例模型的頂層以避免“700 用例并發(fā)癥”。如果你的用例模型正在爆炸式增長(cháng)，你應該挑戰你的用例粒度。對于 Simpay來(lái)說(shuō)，在最高抽象層，我們以大約二十種主要用例作為結束。記住，一個(gè)用例傳遞值的一些東西給參與者；它為參與者實(shí)現一個(gè)目標。確保所有用例目標都在相同的層次上，并且對于業(yè)務(wù)建模來(lái)說(shuō)所有目標都在抽象層上。 有一個(gè)來(lái)自 Simpay 語(yǔ)境的具體實(shí)例。支付可以立刻實(shí)現——支付授權 8 和支付捕獲 9 同時(shí)發(fā)生，或延期實(shí)現——授權在捕獲之前發(fā)生。圖 3 顯示了一個(gè)可能的用例圖。然而，請注意用例所表現的目標并不在同一層次。商家的目標是接受支付。他必須服從管理規則，并把支付事務(wù)，分離為捕獲之后的獨立授權，這可能不是他樂(lè )意的。同時(shí)，你被迫表達在請求支付授權和請求支付捕獲之間的一些關(guān)系。一個(gè)簡(jiǎn)單的解決方案是把這兩個(gè)用例，結合為一個(gè)稱(chēng)為Request Deferred Payment的用例。 10 你以更少的用例完成，并進(jìn)一步得到易于理解的用例建模。 如果在授權和捕獲之間有一個(gè)長(cháng)的時(shí)間間隙，那是什么呢？這你無(wú)須關(guān)心！時(shí)間間隙并不是你分隔用例的指示器；尤其是業(yè)務(wù)用例可以是長(cháng)期運轉的。決定是否分隔用例的本質(zhì)標準是他們的目標是否不同。 導致用例膨脹的另外一個(gè)危險是我稱(chēng)之為“睡蓮并發(fā)癥狀”。當你為一個(gè)用例找到一種變化的時(shí)候，它就開(kāi)始了；在 Simpay 例子中，它可能是支付發(fā)生的通道（例如，SMS，WAP）。你可能馬上被我們例子中的多用途用例所誘惑（要求使用WAP，SMS等方式立即支付）。也可能存在更多的維數。很快地，你就可以像睡蓮覆蓋池塘一樣，覆蓋你的用例圖。相反地，向目標挑戰。如果你做些分析，你將會(huì )發(fā)現目標對于所有這些用例都是相同的。把焦點(diǎn)集中在本質(zhì)的用例上，稍后你會(huì )知道表現這些變更的更好的方法（舉例來(lái)說(shuō)，在用例描述的特別需求部分） 同時(shí), 當你確定支持目標，如維護重要的業(yè)務(wù)實(shí)體，把它們排除在外，使之獨立并使用自己的圖支持用例包。  圖 3：不同的目標層次 需求屬性包含需求信息。優(yōu)先級：顯示一個(gè)需求 對于 商業(yè)用戶(hù)有多重要。迭代：表明需求分配到哪個(gè)迭代。穩定度：指出哪些需求可能遭受變更。還有更多的屬性，但是，讓我們把目光集中到上述三個(gè)屬性上。請確定你在堅持不懈地為你的用例捕獲這些屬性。為什么呢？因為他們可以使你的過(guò)程變成更輕松。特別地，你將時(shí)常會(huì )有關(guān)于如何構建用例模型 11 的多種選擇；當你這樣做時(shí)，用上述的屬性定位你的用例模型。這將產(chǎn)生最少的重構工作，并聚焦于你的工作。 實(shí)際上，考慮下列的指導方針以決定你的選擇：
記?。耗闳绾沃貥嬘美Ｐ蛯?huì )影響其它的工作。業(yè)務(wù)用戶(hù)將不得不找到適合新模型的方法，對于不同的可交付變量的追蹤也將需要被更新。從一開(kāi)始就正確地構建模型，也將節省其他人的時(shí)間。 在上面的例子中，我們堅決反對把延期和即付功能，歸并到一個(gè)單一用例中（如，請求支付），因為“初始Simpay開(kāi)發(fā)，可以而且也會(huì )包括延遲的或直接的支付”可能很快會(huì )被產(chǎn)生；無(wú)論選擇哪種支付機制，其它的將是以后版本的范圍。這種用例反復屬性的變化，導致分裂為即付請求和遲延支付請求。 原則 4：分解和規則 – 通過(guò)業(yè)務(wù)參與者分解 現在你有一個(gè)結構良好并可以理解的業(yè)務(wù)用例模型。接下來(lái)你要往哪里去呢？一件重要的事情是 不要 把功能分解到你的用例模型中；即，不要把你的用例打破成較小的部分。這樣的部分將會(huì )變成孤立的，違反用例步驟的最重要的優(yōu)點(diǎn)之一：在參與者的目標語(yǔ)境中呈現需求。相反地，答案是遞歸地在當前語(yǔ)境中，基于用例步驟重新應用。 讓我們回過(guò)頭看看圖 3。底部的 Simpay 產(chǎn)品語(yǔ)境顯示由Simpay 有限公司，移動(dòng)操作者和移動(dòng)商業(yè)要求者實(shí)現的Simpay 產(chǎn)品。這些實(shí)體的 RUP 術(shù)語(yǔ)是 業(yè)務(wù)參與者 。這些業(yè)務(wù)參與者合作完成 Simpay 產(chǎn)品功能。一個(gè)，二個(gè)，或所有的業(yè)務(wù)參與者都參與每個(gè) Simpay 產(chǎn)品用例。通過(guò)這一信息，你可以為每個(gè)業(yè)務(wù)參與者（由Simpay產(chǎn)品語(yǔ)境分配的）產(chǎn)生一個(gè)語(yǔ)境。每個(gè)語(yǔ)境由下面二者建立：(1)通過(guò)業(yè)務(wù)參與者劃分用例，和(2)從現有的業(yè)務(wù)參與者派生出新的參與者。這個(gè)過(guò)程在圖 4 中舉例說(shuō)明，它為移動(dòng)操作者顯示了一個(gè)實(shí)例結果。帶有兩段用例和一個(gè)新參與者（Simpay 有限公司）的新的移動(dòng)操作者語(yǔ)境已經(jīng)由更高抽象層派生出來(lái)?，F在你能分開(kāi)控制（相互調用）新的語(yǔ)境。 12 這與功能分解有什么不同嗎？是的！取替在Simpay 產(chǎn)品語(yǔ)境（不是由參與者目標激發(fā)的）創(chuàng )建孤立的部分的是，你已經(jīng)用新參與者表現的精確目標，創(chuàng )建了更小的域?？纯匆苿?dòng)操作者語(yǔ)境的結果。明顯地，Simpay 有限公司代表移動(dòng)業(yè)務(wù)需求方（依次代表貿易商）做這些事情。然而，移動(dòng)操作者的領(lǐng)域是自我包含的；它不需要了解Simpay 有限公司參與者做什么。相反地，功能分解方式將把用例分解成許多部分：獲得商業(yè)細節；進(jìn)行外匯交易；授權支付；捕獲支付。哪種方式更適合管理方案范圍呢？  圖 4: 業(yè)務(wù)參與者劃分。 點(diǎn)擊這里放大。 很幸運；我們擁有感興趣的業(yè)務(wù)代表，他們很快地就適應了用例方式，和有能力的技術(shù)隊伍，他們的目標是把需求自動(dòng)翻譯成科技規范。然而，如同它被生成一樣，業(yè)務(wù)代表盡可能地由狀態(tài)激發(fā)，而且科技隊伍對于強加于他們之上的不必要的限制因素感到不安。用例通過(guò)描述產(chǎn)品做什么來(lái)展現需求，以達到參與者的目標?！?做什么 ”和“ 如何做 ”間的產(chǎn)品活動(dòng)是人們特別是全球性的分布化團隊不太清楚的一些事情，誤解是正常的。這里有四種類(lèi)型的指導方針可以幫助我們避免這些錯誤：
交流這些指導方針是重要的。對于 Simpay 來(lái)說(shuō)，我們在產(chǎn)品概述文檔（見(jiàn)頁(yè)面邊欄）捕獲它們。在RUP中最適合做這件事的地方是用例模型，指導方針文檔。更為重要的是，如果你正工作于定制的過(guò)程之中，要有一個(gè)試驗。選取一個(gè)用例，并努力與整個(gè)隊伍前進(jìn)一致，這樣每個(gè)人都會(huì )對你將如何生成事務(wù)及管理期望，感到滿(mǎn)意。 在 RUP 中一個(gè)域模型（見(jiàn)圖 5）被定義為：在域的語(yǔ)境中捕獲最重要類(lèi)型的對象。域模型是業(yè)務(wù)分析模型的一個(gè)子集，業(yè)務(wù)分析模型包含描述業(yè)務(wù)參與者（見(jiàn)原則4）和業(yè)務(wù)實(shí)體如何獲得用例功能的業(yè)務(wù)用例實(shí)現。域模型很有用，即使你不提出業(yè)務(wù)用例實(shí)現。它通過(guò)為你的用例描述提供具有精確含義的通用詞匯術(shù)語(yǔ)，來(lái)連接你的各個(gè)用例。域模型確保相同的術(shù)語(yǔ)指向相同的業(yè)務(wù)實(shí)體。正好也捕獲如下類(lèi)型的需求：
結構化你的域模型文檔，為這一信息（見(jiàn)到圖 5）加入占位符。在我的經(jīng)驗中，業(yè)務(wù)用戶(hù)對這些細微改進(jìn)的形式感到相當滿(mǎn)意，而且它為你提高穩定性和完全性檢驗：
當創(chuàng )造域模型的時(shí)候，除了根據常識和你的讀者偏好之外，你能使用下列的指導方針：
一個(gè)域模型如何與一個(gè)術(shù)語(yǔ)表相關(guān)聯(lián)？一個(gè)術(shù)語(yǔ)表定義了項目中使用的重要術(shù)語(yǔ)。以這個(gè)定義為基礎，一個(gè)域模型是術(shù)語(yǔ)表中術(shù)語(yǔ)的一個(gè)子集。但要避免冗余：在術(shù)語(yǔ)表或域模型中定義一個(gè)條目，但是不要在兩者里面都下定義。通常，當你知道更多關(guān)于你的商業(yè)域時(shí)，術(shù)語(yǔ)從術(shù)語(yǔ)表轉移到域模型。然而，你的術(shù)語(yǔ)表對于那些不存在于業(yè)務(wù)實(shí)體中的術(shù)語(yǔ)，仍然是有用的交付產(chǎn)物內容。 圖 5：域模型圖和相關(guān)文本。 點(diǎn)擊這里放大。 實(shí)體生命周期在商業(yè)規范中未得到充分利用，但是，一個(gè)好的解決方案是可用的：UML狀態(tài)圖。 你為什么要使用這些，以及它們如何關(guān)聯(lián)到用例？業(yè)務(wù)實(shí)體（舉例來(lái)說(shuō)，一個(gè)移動(dòng)使用者）通常有跨用例的生命周期。一個(gè)在狀態(tài)之間的用例過(guò)渡（通常是不同的，狀態(tài)圖給一個(gè)統一視圖，它關(guān)于你的重要業(yè)務(wù)實(shí)體在哪里，如何被操縱。圖 6 顯示一個(gè)關(guān)于移動(dòng)使用者業(yè)務(wù)實(shí)體的例子。轉變表現了維護移動(dòng)用戶(hù)的用例 15 ，并在不同狀態(tài)間轉化它。 作為一個(gè)分析師，你也可以使用狀態(tài)圖保持你的需求集的一致性和完整性。我的業(yè)務(wù)實(shí)體是如何成為實(shí)物的呢？我是否已經(jīng)錯過(guò)了一個(gè)重要的狀態(tài)？我是否已經(jīng)描述我的用例中支持的所有轉變的所有狀態(tài)？我是否錯過(guò)了影響轉變的特別條件？ 限定最重要的業(yè)務(wù)對象的生命周期，而在你的文檔中描寫(xiě)所有狀態(tài)。你的用例將以正確定義的域模型術(shù)語(yǔ)，描述涉及的這些狀態(tài)，在保持可讀性的情況下，把歧義從你的規范中排除。一個(gè)用例描述（涉及到圖 6 所示的實(shí)例）會(huì )如下被看到： 4. 移動(dòng)操作者確認移動(dòng)用戶(hù)并未被禁止。 這種禁止狀態(tài) 指明了移動(dòng)用戶(hù)所處的狀態(tài)，并為狀態(tài)展現了一個(gè)非常精確的定義。依賴(lài)參數選擇，你可以使用格式來(lái)強調文本中的狀態(tài)。 生命周期最好作為由業(yè)務(wù)實(shí)體定義（如圖5所示）耦合的附錄，置于域模型中。你能夠使用IBM Rational Rose來(lái)維護狀態(tài)圖并文檔化狀態(tài)，而且你也可以使用IBM Rational SoDa 產(chǎn)生易于操縱的文檔。 采用這種方式，當你把實(shí)體生命周期置于業(yè)務(wù)用戶(hù)之前時(shí)，你可以就像技師 16 一樣，在沒(méi)有做出需求時(shí)，平衡使用它們的好處。 一個(gè)對于未來(lái)的調查：通過(guò)模型驅動(dòng)架構， 17 你將會(huì )獨立于一個(gè)特定的平臺，受益于預先指定的精確性態(tài)。除此之外，可運行的 UML 將會(huì )使你可以在你開(kāi)始著(zhù)手不惜代價(jià)的細分你的需求之前，確認你前面的模型。 圖 6：狀態(tài)圖：手機用戶(hù) -- 生命周期
用例是捕獲業(yè)務(wù)需求的一個(gè)優(yōu)秀的方法。只要你定義適當的抽象層，以支持可理解及可追蹤的全部細節，他們就可以通過(guò)大的項目很好地伸縮。僅僅增加用例的數目并不起作用。確認你的需求的業(yè)務(wù)用戶(hù)，會(huì )對基于用例的方法感到非常舒服。關(guān)于這種方法，精心描述你的自動(dòng)化業(yè)務(wù)用例，讓技術(shù)需求的技術(shù)團隊通常更容易被接受。 因此，如果你被分配了一個(gè)復雜的業(yè)務(wù)需求項目，不要絕望。通過(guò)應用用例方法于需求工程，一個(gè)由可靠的開(kāi)發(fā)過(guò)程及本文中呈現的原則，細化支持的方法，你就能克服許多挑戰，并使方案成功。正如我所做的，你甚至可能已經(jīng)發(fā)現，它是一個(gè)令人滿(mǎn)意的實(shí)踐。
我很感謝在 Simpay 中的人們，因為他們在本文中描述的方法中所承擔的工作。特別是Tim Jones，Simon Richards，Martin Rugfelt 和 Jim Wadsworth。特別感謝我的同事Martin Elliffe提供了有幫助的說(shuō)明及建議。
1在這該文章中，我使用需求工程，作為業(yè)務(wù)需求工程一個(gè)簡(jiǎn)稱(chēng)。 2本文所用的例子來(lái)源于寬泛的Simpay語(yǔ)境。一些已經(jīng)被簡(jiǎn)化了，僅僅用來(lái)論證要點(diǎn)和要求的觀(guān)察保密性。因此，請讀者不要把這些例子，理解為真實(shí)的Simpay活動(dòng)。 3更多關(guān)于 Simpay 商業(yè)模型的細節，見(jiàn) www.simpay.com。 4更多關(guān)于 RUP 的細節，見(jiàn) Philippe Kruchten的《The Rational Unified Process. 》，Addison-Wesley，2000及 http://www-306.ibm.com/software/awdtools/rup/index.html。 5非迭代交付的主要障礙是，IT解決方案和它的操作者是由第三方轉包，并通過(guò)一組法律合同集成到整個(gè)過(guò)程的事實(shí)。一個(gè)迭代過(guò)程會(huì )在這些法律合同中增加重要的復雜性。 6盡管不是與RUP關(guān)聯(lián)的標準4+1 視圖的一部分，但這一視圖是基本的。在最后，你不得不出售你的產(chǎn)品。 7兩個(gè)語(yǔ)境有很明顯的關(guān)系。作為在商業(yè)語(yǔ)境中購買(mǎi)產(chǎn)品用例的一部分，商業(yè)觸發(fā)器支付請求使用 Simpay 語(yǔ)境中的例子。 8商人確定手機使用者能支付和為他儲備的貨幣。 9商人請求應支付給他的金額。 10實(shí)際上，你甚至可以更進(jìn)一步考慮，并有一個(gè)獨立的支付請求用例：我們的確決定反對它。理由是范圍管理, 但是繼續向下看。 11我不在這里討論擴大并包括聯(lián)系。以我的經(jīng)驗，最好在你的業(yè)務(wù)用例模型中避免這些聯(lián)系。 12在《 The Object Advantage》（Addison-Wesley，1995，第173頁(yè)），E.A. Jacobsen 介紹了一個(gè)算法，用于映射一個(gè)業(yè)務(wù)用例模型到一個(gè)系統用例模型。這里使用一個(gè)類(lèi)似的算法，把一個(gè)業(yè)務(wù)用例模型映射到不同語(yǔ)境中的另一個(gè)業(yè)務(wù)用例模型。 13在確定的環(huán)境中，你可能有一個(gè)不存在響應的請求。如果響應沒(méi)有業(yè)務(wù)含義，這與被提議及將被使用的模型完全一致。 14相反地，我強烈建議你使用一個(gè)有細密紋理的編號樣式，作為用例描述。它允許你改良一致性、完整性檢查及參照。 15如果一個(gè)用例在多種狀態(tài)間轉換為業(yè)務(wù)實(shí)體。你可以轉換為備選流或一組步驟（舉例來(lái)說(shuō)，使用標簽或你用例描述的數字記號）。 16讓我強調一下，它們可能看起來(lái)象技師，但是它們不是技師，因為它們僅僅書(shū)寫(xiě)商業(yè)決策的文檔。 17更多關(guān)于模式驅動(dòng)架構的細節，參見(jiàn) http://www.omg.org/mda 和 Behrens，Richards的《 StateLator in Advanced Information Systems Engineering》，Springer，2000。
| ||||||||||||||||||||||||||||||||
聯(lián)系客服
