導(dǎo)致區(qū)別的七個(gè)原則

級(jí)別: 高級(jí)

Thomas Behrens, 首席技術(shù)官, Alpheus解決方案

2005 年 2 月 15 日

來自Rational Edge：這篇文章基于Simpay，一個(gè)通過移動(dòng)電話操作的支付系統(tǒng)，的業(yè)務(wù)需求工程項(xiàng)目的經(jīng)驗(yàn)，大致描繪了關(guān)于捕獲業(yè)務(wù)需求的七個(gè)實(shí)用原則。

假定你已經(jīng)有需求工程規(guī)范的一些經(jīng)驗(yàn)，而且你突然面對(duì)一個(gè)包括多個(gè)公司，并跨越不同商業(yè)領(lǐng)域的重大業(yè)務(wù)需求方案。開始在你的心里出現(xiàn)問題：用例是否會(huì)在這個(gè)項(xiàng)目中使用？我應(yīng)如何決定用例粒度的正確層次？我應(yīng)如何構(gòu)建用例模型？我必須裁剪標(biāo)準(zhǔn)的 IBM? Rational Unified Process 或 RUP以達(dá)到交付標(biāo)準(zhǔn)嗎？這篇文章提供Alpheus，一位國(guó)際性的IT顧問，如何在Simpay（一個(gè)可共同操作的手持電話支付系統(tǒng)）組織需求工程項(xiàng)目 ¹ 中應(yīng)對(duì)這些問題。它提取我們?cè)陧?xiàng)目中所學(xué)到的，成為七個(gè)實(shí)用的原則，它將舉例說明你怎樣在你自己的業(yè)務(wù)需求計(jì)劃中取得成功。

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

Simpay 是關(guān)于開發(fā)聯(lián)合現(xiàn)在分段的手持電話支付市場(chǎng)的、能共同操作支付的全新架構(gòu)的第一步 ² 。圖 1 顯示業(yè)務(wù)上下文的概觀。Simpay 占領(lǐng)這上下文的中心位置，使用開放的接口，來整合手持電話商業(yè)要求者（代表多個(gè)零售商及[或] 內(nèi)容供應(yīng)者）和手持電話操作者（代表并認(rèn)證最終客戶），成為在線金融交易。Simpay 為支付認(rèn)證，結(jié)算并解決手持電話操作者與手持電話商業(yè)要求者之間的資金流，提供服務(wù)。 ³

圖 1: Simpay 商業(yè)上下文概觀

業(yè)務(wù)需求過程被嵌入到一個(gè)把支付解決方案（如Simpay 產(chǎn)品）轉(zhuǎn)變進(jìn)入市場(chǎng)的大型過程中。產(chǎn)品展現(xiàn)了一個(gè)使用手動(dòng)或自動(dòng)過程的、從頭建造的、新業(yè)務(wù)。由于預(yù)算必須控制得恰到好處，因此決定延期實(shí)現(xiàn)確切的自動(dòng)化過程，直到業(yè)務(wù)已經(jīng)被建模。

整體項(xiàng)目及商業(yè)特性可以摘要為：

• 多公司（Orange，Telef a M es，T-Mobile和Vodafone）
• 重視規(guī)模方面（支持約二億八千萬客戶）
• 擁有虛擬團(tuán)隊(duì)的多國(guó)公司
• 持有名譽(yù)方面的潛在影響
• 覆蓋多重專家領(lǐng)域（舉例來說，無線通通訊，財(cái)政服務(wù)）
• 規(guī)則加強(qiáng)器，擁有多種不同的法律約束

這些特性表達(dá)了許多關(guān)于建立所有企業(yè)涉眾、共同的、一致的業(yè)務(wù)需求集合的重要性和可見性。

我們介紹一個(gè)與RUP ⁴ 結(jié)合的過程，跨越Simpay從商業(yè)想法到產(chǎn)品部署的項(xiàng)目生命周期。我們把活動(dòng)和交付產(chǎn)物映射到 RUP的四個(gè)階段（初始，精化，構(gòu)建和產(chǎn)品化）及它們各自的里程碑。RUP 活動(dòng)和交付產(chǎn)物最初剪裁為軟件開發(fā)過程，然而項(xiàng)目已經(jīng)有一個(gè)非常寬泛的范圍（舉例來說，一個(gè)交付產(chǎn)物是新公司的建立，如Simpay Ltd.）。然而，活動(dòng)和交付產(chǎn)物有時(shí)大幅度地偏離 RUP 。而且，這個(gè)與 RUP最佳實(shí)踐相反的進(jìn)程，并不是可重復(fù)的。 ⁵ 然而，許多個(gè)別交付產(chǎn)物在重復(fù)的/增量的基礎(chǔ)上產(chǎn)生，提供早期的評(píng)審，驗(yàn)證和質(zhì)量保證，以及偶爾依靠早期的活動(dòng)啟動(dòng)。

當(dāng)我們想要在業(yè)務(wù)層次上捕獲需求，而不指定特定交付產(chǎn)物是手動(dòng)的或自動(dòng)的，我們使用 RUP 業(yè)務(wù)建模規(guī)范作為我們的參考規(guī)范，并用需求工程的一些元素進(jìn)行強(qiáng)化。對(duì)于我們定制的交付產(chǎn)物結(jié)構(gòu)，參見文章的補(bǔ)充內(nèi)容。

實(shí)踐原則

下面，我們將討論由我們的經(jīng)驗(yàn)總結(jié)的實(shí)踐原則。他們將會(huì)幫助你：

• 為你的業(yè)務(wù)需求尋找正確的邊界（原則 1：得到正確范圍）
• 適當(dāng)結(jié)構(gòu)化你的用例模型（原則 2：向你的用例目標(biāo)和原則挑戰(zhàn)； 原則3：使用需求屬性決定最好的用例模型）
• 進(jìn)一步詳細(xì)說明你的業(yè)務(wù)需求（原則 4：分而治之：通過業(yè)務(wù)參與者分解）
• 適當(dāng)描述你的業(yè)務(wù)用例（原則 5：用例描述：闡明“ 是什么”，而不是“如何做”）
• 連接你的業(yè)務(wù)用例,避免冗余，并確認(rèn)你的需求（原則 6：提出域模型和原則7：使用實(shí)體的生命周期）

原則 1：確定正確范圍

需求管理的目的是為了確定正確范圍。邊界在哪里呢？誰在里面而誰在外面呢？這是更高層次的抽象，更為重要的。在范圍方面很小的變化，就可能會(huì)帶來與企業(yè)所有者相關(guān)，將要開展的工作，及項(xiàng)目運(yùn)行的最后期限的重大影響。

讓我們回顧圖 1，這次把它當(dāng)作一個(gè)市場(chǎng)視圖。 ⁶ 這個(gè)視圖顯示購(gòu)買（購(gòu)物相互作用）和付款相互作用；它也顯示Simpay作為支付中介?，F(xiàn)在，比較圖1與圖2。除了使用不同的記號(hào)（UML）之外，圖 2 顯示兩個(gè)不同的語境。上面一個(gè)是具有銷售功能的商人的語境，它在購(gòu)買商品用例中表現(xiàn)。下面的一個(gè)是 Simpay 擁有的支付功能，用請(qǐng)求支付用例表現(xiàn)。 ⁷

如果你認(rèn)真地看，你將會(huì)看到這個(gè)特征把Simpay從市場(chǎng)視圖分為兩個(gè)部分：Simpay 產(chǎn)品和和 Simpay 有限公司。當(dāng)我們發(fā)現(xiàn) Simpay 產(chǎn)品不僅僅Simpay有限公司（也就是，中心實(shí)體）需要，也被移動(dòng)操作者、及移動(dòng)商家要求者實(shí)體需要時(shí)，這種區(qū)別是必要的。同時(shí)，這些實(shí)體識(shí)別到產(chǎn)品的功能；因此，所有的三方都在項(xiàng)目范圍內(nèi)。

這是在斤斤計(jì)較嗎？不！它幫助我們清晰地建立項(xiàng)目邊界。這意謂著我們可以從早期開始，就能避免不必要的討論。在事后，這些區(qū)別可以看得很清楚，除了新的業(yè)務(wù)活動(dòng)，為涉及到需求活動(dòng)的當(dāng)事者確定邊界。然而，這是值得研究的工作。

圖 2: 商業(yè)語境和 Simpay 語境

原則 2: 挑戰(zhàn)你的用例目標(biāo)

一旦你確定了你的范圍，你可以開始確定用例和參與者。一個(gè)通常的問題是用例模型爆炸式快速增長(zhǎng)，特別當(dāng)你正在業(yè)務(wù)需求的抽象層工作的時(shí)候。很快的，你將會(huì)發(fā)現(xiàn)你需要表達(dá)很多內(nèi)容。從字面上，停留在你的用例模型的頂層以避免“700 用例并發(fā)癥”。如果你的用例模型正在爆炸式增長(zhǎng)，你應(yīng)該挑戰(zhàn)你的用例粒度。對(duì)于 Simpay來說，在最高抽象層，我們以大約二十種主要用例作為結(jié)束。記住，一個(gè)用例傳遞值的一些東西給參與者；它為參與者實(shí)現(xiàn)一個(gè)目標(biāo)。確保所有用例目標(biāo)都在相同的層次上，并且對(duì)于業(yè)務(wù)建模來說所有目標(biāo)都在抽象層上。

有一個(gè)來自 Simpay 語境的具體實(shí)例。支付可以立刻實(shí)現(xiàn)——支付授權(quán) ⁸ 和支付捕獲 ⁹ 同時(shí)發(fā)生，或延期實(shí)現(xiàn)——授權(quán)在捕獲之前發(fā)生。圖 3 顯示了一個(gè)可能的用例圖。然而，請(qǐng)注意用例所表現(xiàn)的目標(biāo)并不在同一層次。商家的目標(biāo)是接受支付。他必須服從管理規(guī)則，并把支付事務(wù)，分離為捕獲之后的獨(dú)立授權(quán)，這可能不是他樂意的。同時(shí)，你被迫表達(dá)在請(qǐng)求支付授權(quán)和請(qǐng)求支付捕獲之間的一些關(guān)系。一個(gè)簡(jiǎn)單的解決方案是把這兩個(gè)用例，結(jié)合為一個(gè)稱為Request Deferred Payment的用例。 ¹⁰ 你以更少的用例完成，并進(jìn)一步得到易于理解的用例建模。

如果在授權(quán)和捕獲之間有一個(gè)長(zhǎng)的時(shí)間間隙，那是什么呢？這你無須關(guān)心！時(shí)間間隙并不是你分隔用例的指示器；尤其是業(yè)務(wù)用例可以是長(zhǎng)期運(yùn)轉(zhuǎn)的。決定是否分隔用例的本質(zhì)標(biāo)準(zhǔn)是他們的目標(biāo)是否不同。

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

同時(shí), 當(dāng)你確定支持目標(biāo)，如維護(hù)重要的業(yè)務(wù)實(shí)體，把它們排除在外，使之獨(dú)立并使用自己的圖支持用例包。

圖 3：不同的目標(biāo)層次

原則 3：使用需求屬性決定最好的用例模型

需求屬性包含需求信息。優(yōu)先級(jí)：顯示一個(gè)需求 對(duì)于 商業(yè)用戶有多重要。迭代：表明需求分配到哪個(gè)迭代。穩(wěn)定度：指出哪些需求可能遭受變更。還有更多的屬性，但是，讓我們把目光集中到上述三個(gè)屬性上。請(qǐng)確定你在堅(jiān)持不懈地為你的用例捕獲這些屬性。為什么呢？因?yàn)樗麄兛梢允鼓愕倪^程變成更輕松。特別地，你將時(shí)常會(huì)有關(guān)于如何構(gòu)建用例模型 ¹¹ 的多種選擇；當(dāng)你這樣做時(shí)，用上述的屬性定位你的用例模型。這將產(chǎn)生最少的重構(gòu)工作，并聚焦于你的工作。

實(shí)際上，考慮下列的指導(dǎo)方針以決定你的選擇：

1. 如果任何的這些指導(dǎo)方針違背原則2，并導(dǎo)致用例增加，不要應(yīng)用指導(dǎo)方針！
2. 如果兩個(gè)用例有不同的優(yōu)先級(jí)，避免合并它們。
3. 如果兩個(gè)用例被分配到不同的迭代中，避免合并它們。
4. 如果兩個(gè)用例具有不同的穩(wěn)定性等級(jí)，避免合并它們。
5. 不要為取得不穩(wěn)定用例的模型花太多時(shí)間；這個(gè)功能可能根本上不需要改變?，F(xiàn)在，把焦點(diǎn)集中在穩(wěn)定用例上，以得到正確的模型。

記?。耗闳绾沃貥?gòu)用例模型將會(huì)影響其它的工作。業(yè)務(wù)用戶將不得不找到適合新模型的方法，對(duì)于不同的可交付變量的追蹤也將需要被更新。從一開始就正確地構(gòu)建模型，也將節(jié)省其他人的時(shí)間。

在上面的例子中，我們堅(jiān)決反對(duì)把延期和即付功能，歸并到一個(gè)單一用例中（如，請(qǐng)求支付），因?yàn)椤俺跏糞impay開發(fā)，可以而且也會(huì)包括延遲的或直接的支付”可能很快會(huì)被產(chǎn)生；無論選擇哪種支付機(jī)制，其它的將是以后版本的范圍。這種用例反復(fù)屬性的變化，導(dǎo)致分裂為即付請(qǐng)求和遲延支付請(qǐng)求。

原則 4：分解和規(guī)則 – 通過業(yè)務(wù)參與者分解

現(xiàn)在你有一個(gè)結(jié)構(gòu)良好并可以理解的業(yè)務(wù)用例模型。接下來你要往哪里去呢？一件重要的事情是 不要 把功能分解到你的用例模型中；即，不要把你的用例打破成較小的部分。這樣的部分將會(huì)變成孤立的，違反用例步驟的最重要的優(yōu)點(diǎn)之一：在參與者的目標(biāo)語境中呈現(xiàn)需求。相反地，答案是遞歸地在當(dāng)前語境中，基于用例步驟重新應(yīng)用。

讓我們回過頭看看圖 3。底部的 Simpay 產(chǎn)品語境顯示由Simpay 有限公司，移動(dòng)操作者和移動(dòng)商業(yè)要求者實(shí)現(xiàn)的Simpay 產(chǎn)品。這些實(shí)體的 RUP 術(shù)語是 業(yè)務(wù)參與者 。這些業(yè)務(wù)參與者合作完成 Simpay 產(chǎn)品功能。一個(gè)，二個(gè)，或所有的業(yè)務(wù)參與者都參與每個(gè) Simpay 產(chǎn)品用例。通過這一信息，你可以為每個(gè)業(yè)務(wù)參與者（由Simpay產(chǎn)品語境分配的）產(chǎn)生一個(gè)語境。每個(gè)語境由下面二者建立：(1)通過業(yè)務(wù)參與者劃分用例，和(2)從現(xiàn)有的業(yè)務(wù)參與者派生出新的參與者。這個(gè)過程在圖 4 中舉例說明，它為移動(dòng)操作者顯示了一個(gè)實(shí)例結(jié)果。帶有兩段用例和一個(gè)新參與者（Simpay 有限公司）的新的移動(dòng)操作者語境已經(jīng)由更高抽象層派生出來。現(xiàn)在你能分開控制（相互調(diào)用）新的語境。 ¹²

這與功能分解有什么不同嗎？是的！取替在Simpay 產(chǎn)品語境（不是由參與者目標(biāo)激發(fā)的）創(chuàng)建孤立的部分的是，你已經(jīng)用新參與者表現(xiàn)的精確目標(biāo)，創(chuàng)建了更小的域?？纯匆苿?dòng)操作者語境的結(jié)果。明顯地，Simpay 有限公司代表移動(dòng)業(yè)務(wù)需求方（依次代表貿(mào)易商）做這些事情。然而，移動(dòng)操作者的領(lǐng)域是自我包含的；它不需要了解Simpay 有限公司參與者做什么。相反地，功能分解方式將把用例分解成許多部分：獲得商業(yè)細(xì)節(jié)；進(jìn)行外匯交易；授權(quán)支付；捕獲支付。哪種方式更適合管理方案范圍呢？

圖 4: 業(yè)務(wù)參與者劃分。 點(diǎn)擊這里放大。

原則 5: 用例描述：陳述“是什么”，而非“如何做”

很幸運(yùn)；我們擁有感興趣的業(yè)務(wù)代表，他們很快地就適應(yīng)了用例方式，和有能力的技術(shù)隊(duì)伍，他們的目標(biāo)是把需求自動(dòng)翻譯成科技規(guī)范。然而，如同它被生成一樣，業(yè)務(wù)代表盡可能地由狀態(tài)激發(fā)，而且科技隊(duì)伍對(duì)于強(qiáng)加于他們之上的不必要的限制因素感到不安。用例通過描述產(chǎn)品做什么來展現(xiàn)需求，以達(dá)到參與者的目標(biāo)?！?做什么 ”和“ 如何做 ”間的產(chǎn)品活動(dòng)是人們特別是全球性的分布化團(tuán)隊(duì)不太清楚的一些事情，誤解是正常的。這里有四種類型的指導(dǎo)方針可以幫助我們避免這些錯(cuò)誤：

業(yè)務(wù)需求交付產(chǎn)物的結(jié)構(gòu) Simpay 產(chǎn)品（ 如這里所示）業(yè)務(wù)需求的可交付文檔，采用了UML類圖結(jié)構(gòu)。過程框架和功能架構(gòu)是高層次的業(yè)務(wù)需求文檔，相當(dāng)于針對(duì) Simpay 產(chǎn)品的RUP業(yè)務(wù)視圖和業(yè)務(wù)用例模型。在產(chǎn)品定義中捕獲詳細(xì)說明的業(yè)務(wù)需求，產(chǎn)品定義是接近于三個(gè)業(yè)務(wù)參與者（在Simpay中作為實(shí)體引用）：Simpay有限公司，移動(dòng)操作者和移動(dòng)業(yè)務(wù)需求方）的業(yè)務(wù)用例模型的文檔集。對(duì)于 Simpay 有限公司，產(chǎn)品定義捕獲了在RUP中引用、作為業(yè)務(wù)分析模型的東西。標(biāo)準(zhǔn)的 RUP 交付產(chǎn)物內(nèi)容已經(jīng)被修改，因?yàn)椋?/p> 業(yè)務(wù)需求存在于兩個(gè)抽象層面上（例如，Simpay 產(chǎn)品和移動(dòng)電話操作者或Simpay 有限公司或移動(dòng)業(yè)務(wù)需求方） 在第二個(gè)抽象層上要求兩個(gè)不同層的細(xì)節(jié)： a）一個(gè)層次是為 Simpay 有限公司確切描述，如何建立業(yè)務(wù)需求，或者通過技術(shù)解決方案自動(dòng)實(shí)現(xiàn)，或者由操作者手動(dòng)編寫。 b）另一個(gè)層次主要是為移動(dòng)操作者和移動(dòng)業(yè)務(wù)需求方，描述設(shè)計(jì)準(zhǔn)則（不包括個(gè)別實(shí)體）。

1. 特定的自然語言表達(dá)有技術(shù)內(nèi)涵。（舉例來說，回路）。如果你使用這些表達(dá)，確定他們?cè)谧鳛榧夹g(shù)設(shè)計(jì)建議時(shí)不會(huì)被誤解。
2. 業(yè)務(wù)用例描述商業(yè)流；它們決定誰是信息的來源，以及誰是目標(biāo)。它們沒有暗示流的技術(shù)實(shí)現(xiàn)。沒有明確定義信息是否要推或拉，信息交換是批量的或在線的，是否要使用緩存。這樣的技術(shù)性的決斷主要關(guān)聯(lián)到非功能需求。確定人們理解業(yè)務(wù)用例中的詞，例如聯(lián)系、請(qǐng)求，不要為基本的技術(shù)交流基礎(chǔ)設(shè)施暗示技術(shù)約束。
3. 爭(zhēng)取涉及參與者及產(chǎn)品間的簡(jiǎn)單交流模式。嘗試遵照同步請(qǐng)求/響應(yīng) ¹³ 溝通模型。這暗示一個(gè)請(qǐng)求的響應(yīng)在用例描述持續(xù)情況下，或者被接收，或者不被接收（舉例來說，在超時(shí)的情況下）。當(dāng)用例已經(jīng)在它的描述中繼續(xù)前進(jìn)時(shí)，它不可能接受響應(yīng)。請(qǐng)求的表達(dá)是充分的，并且它簡(jiǎn)化了描述。應(yīng)強(qiáng)調(diào)的是，它并不暗示同一模型的技術(shù)性實(shí)現(xiàn)。
4. 當(dāng)你為用例步驟編號(hào)時(shí)，人們通常認(rèn)為你正在下令應(yīng)該如何完成功能。 ¹⁴ 然而，用例步驟的順序通常僅僅關(guān)系到參與者的下一個(gè)交互。當(dāng)在這樣一組步驟的特定順序被托管時(shí)，請(qǐng)習(xí)慣于跟隨明確的狀態(tài)。

交流這些指導(dǎo)方針是重要的。對(duì)于 Simpay 來說，我們?cè)诋a(chǎn)品概述文檔（見頁面邊欄）捕獲它們。在RUP中最適合做這件事的地方是用例模型，指導(dǎo)方針文檔。更為重要的是，如果你正工作于定制的過程之中，要有一個(gè)試驗(yàn)。選取一個(gè)用例，并努力與整個(gè)隊(duì)伍前進(jìn)一致，這樣每個(gè)人都會(huì)對(duì)你將如何生成事務(wù)及管理期望，感到滿意。

原則 6：提出域模型

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

• 業(yè)務(wù)實(shí)體和它們的多樣性之間的聯(lián)系（舉例來說，一個(gè)移動(dòng)用戶使用一個(gè)或多個(gè)移動(dòng)電話）
• 限制因素（舉例來說，一個(gè)支付不能夠超過一個(gè)特定的數(shù)值）和推導(dǎo)規(guī)則（舉例來說，利息計(jì)算），尤其當(dāng)這些不僅僅與一個(gè)用例相關(guān)時(shí)

結(jié)構(gòu)化你的域模型文檔，為這一信息（見到圖 5）加入占位符。在我的經(jīng)驗(yàn)中，業(yè)務(wù)用戶對(duì)這些細(xì)微改進(jìn)的形式感到相當(dāng)滿意，而且它為你提高穩(wěn)定性和完全性檢驗(yàn)：

• 所有的業(yè)務(wù)實(shí)體及它們的屬性是否都已經(jīng)定義？
• 你是否已經(jīng)捕獲了所有的聯(lián)系？
• 所有涉及的業(yè)務(wù)實(shí)體是否至少在一個(gè)用例中？
• 所有涉及的業(yè)務(wù)實(shí)體是否都存在于域模型的用例中？

當(dāng)創(chuàng)造域模型的時(shí)候，除了根據(jù)常識(shí)和你的讀者偏好之外，你能使用下列的指導(dǎo)方針：

1. 使用圖幫助描述，尤其是顯示業(yè)務(wù)實(shí)體間的彼此聯(lián)系。
2. 寧愿冗余的泛化；否則，你可以從你的業(yè)務(wù)用戶那里要求。
3. 對(duì)于簡(jiǎn)單的關(guān)系類型使用屬性；否則，你將會(huì)使你的圖混亂。
4. 當(dāng)屬性的類型會(huì)明顯避免制造困惑時(shí)，忽略它們。
5. 如果識(shí)別符（比如用戶ID）與商業(yè)無關(guān)，忽略它們。
6. 只有當(dāng)參與者名字有助于澄清語境的時(shí)候，才使用它們。否則，意味著把業(yè)務(wù)實(shí)體作為參與者命名，以避免弄亂你的圖。
7. 產(chǎn)生相關(guān)條目的簡(jiǎn)單導(dǎo)航技巧。域模型將會(huì)時(shí)常被用于查找信息。對(duì)于 Simpay來說，我們使用IBM Rational Rose為域模型捕獲信息，使用IBM Rational SoDa來產(chǎn)生簡(jiǎn)單的導(dǎo)航文檔。

一個(gè)域模型如何與一個(gè)術(shù)語表相關(guān)聯(lián)？一個(gè)術(shù)語表定義了項(xiàng)目中使用的重要術(shù)語。以這個(gè)定義為基礎(chǔ)，一個(gè)域模型是術(shù)語表中術(shù)語的一個(gè)子集。但要避免冗余：在術(shù)語表或域模型中定義一個(gè)條目，但是不要在兩者里面都下定義。通常，當(dāng)你知道更多關(guān)于你的商業(yè)域時(shí)，術(shù)語從術(shù)語表轉(zhuǎn)移到域模型。然而，你的術(shù)語表對(duì)于那些不存在于業(yè)務(wù)實(shí)體中的術(shù)語，仍然是有用的交付產(chǎn)物內(nèi)容。

圖 5：域模型圖和相關(guān)文本。 點(diǎn)擊這里放大。

原則 7: 使用實(shí)體生命周期

實(shí)體生命周期在商業(yè)規(guī)范中未得到充分利用，但是，一個(gè)好的解決方案是可用的：UML狀態(tài)圖。 你為什么要使用這些，以及它們?nèi)绾侮P(guān)聯(lián)到用例？業(yè)務(wù)實(shí)體（舉例來說，一個(gè)移動(dòng)使用者）通常有跨用例的生命周期。一個(gè)在狀態(tài)之間的用例過渡（通常是不同的，狀態(tài)圖給一個(gè)統(tǒng)一視圖，它關(guān)于你的重要業(yè)務(wù)實(shí)體在哪里，如何被操縱。圖 6 顯示一個(gè)關(guān)于移動(dòng)使用者業(yè)務(wù)實(shí)體的例子。轉(zhuǎn)變表現(xiàn)了維護(hù)移動(dòng)用戶的用例 ¹⁵ ，并在不同狀態(tài)間轉(zhuǎn)化它。

作為一個(gè)分析師，你也可以使用狀態(tài)圖保持你的需求集的一致性和完整性。我的業(yè)務(wù)實(shí)體是如何成為實(shí)物的呢？我是否已經(jīng)錯(cuò)過了一個(gè)重要的狀態(tài)？我是否已經(jīng)描述我的用例中支持的所有轉(zhuǎn)變的所有狀態(tài)？我是否錯(cuò)過了影響轉(zhuǎn)變的特別條件？

限定最重要的業(yè)務(wù)對(duì)象的生命周期，而在你的文檔中描寫所有狀態(tài)。你的用例將以正確定義的域模型術(shù)語，描述涉及的這些狀態(tài)，在保持可讀性的情況下，把歧義從你的規(guī)范中排除。一個(gè)用例描述（涉及到圖 6 所示的實(shí)例）會(huì)如下被看到：

4. 移動(dòng)操作者確認(rèn)移動(dòng)用戶并未被禁止。

這種禁止?fàn)顟B(tài) 指明了移動(dòng)用戶所處的狀態(tài)，并為狀態(tài)展現(xiàn)了一個(gè)非常精確的定義。依賴參數(shù)選擇，你可以使用格式來強(qiáng)調(diào)文本中的狀態(tài)。

生命周期最好作為由業(yè)務(wù)實(shí)體定義（如圖5所示）耦合的附錄，置于域模型中。你能夠使用IBM Rational Rose來維護(hù)狀態(tài)圖并文檔化狀態(tài)，而且你也可以使用IBM Rational SoDa 產(chǎn)生易于操縱的文檔。

采用這種方式，當(dāng)你把實(shí)體生命周期置于業(yè)務(wù)用戶之前時(shí)，你可以就像技師 ¹⁶ 一樣，在沒有做出需求時(shí)，平衡使用它們的好處。

一個(gè)對(duì)于未來的調(diào)查：通過模型驅(qū)動(dòng)架構(gòu)， ¹⁷ 你將會(huì)獨(dú)立于一個(gè)特定的平臺(tái)，受益于預(yù)先指定的精確性態(tài)。除此之外，可運(yùn)行的 UML 將會(huì)使你可以在你開始著手不惜代價(jià)的細(xì)分你的需求之前，確認(rèn)你前面的模型。

圖 6：狀態(tài)圖：手機(jī)用戶 -- 生命周期

回頁首

總結(jié)

用例是捕獲業(yè)務(wù)需求的一個(gè)優(yōu)秀的方法。只要你定義適當(dāng)?shù)某橄髮?，以支持可理解及可追蹤的全部?xì)節(jié)，他們就可以通過大的項(xiàng)目很好地伸縮。僅僅增加用例的數(shù)目并不起作用。確認(rèn)你的需求的業(yè)務(wù)用戶，會(huì)對(duì)基于用例的方法感到非常舒服。關(guān)于這種方法，精心描述你的自動(dòng)化業(yè)務(wù)用例，讓技術(shù)需求的技術(shù)團(tuán)隊(duì)通常更容易被接受。

因此，如果你被分配了一個(gè)復(fù)雜的業(yè)務(wù)需求項(xiàng)目，不要絕望。通過應(yīng)用用例方法于需求工程，一個(gè)由可靠的開發(fā)過程及本文中呈現(xiàn)的原則，細(xì)化支持的方法，你就能克服許多挑戰(zhàn)，并使方案成功。正如我所做的，你甚至可能已經(jīng)發(fā)現(xiàn)，它是一個(gè)令人滿意的實(shí)踐。

回頁首

感謝

我很感謝在 Simpay 中的人們，因?yàn)樗麄冊(cè)诒疚闹忻枋龅姆椒ㄖ兴袚?dān)的工作。特別是Tim Jones，Simon Richards，Martin Rugfelt 和 Jim Wadsworth。特別感謝我的同事Martin Elliffe提供了有幫助的說明及建議。

回頁首

腳注

¹在這該文章中，我使用需求工程，作為業(yè)務(wù)需求工程一個(gè)簡(jiǎn)稱。

²本文所用的例子來源于寬泛的Simpay語境。一些已經(jīng)被簡(jiǎn)化了，僅僅用來論證要點(diǎn)和要求的觀察保密性。因此，請(qǐng)讀者不要把這些例子，理解為真實(shí)的Simpay活動(dòng)。

³更多關(guān)于 Simpay 商業(yè)模型的細(xì)節(jié)，見 www.。

⁴更多關(guān)于 RUP 的細(xì)節(jié)，見 Philippe Kruchten的《The Rational Unified Process. 》，Addison-Wesley，2000及 http://www-306.ibm.com/software/awdtools/rup/index.html。

⁵非迭代交付的主要障礙是，IT解決方案和它的操作者是由第三方轉(zhuǎn)包，并通過一組法律合同集成到整個(gè)過程的事實(shí)。一個(gè)迭代過程會(huì)在這些法律合同中增加重要的復(fù)雜性。

⁶盡管不是與RUP關(guān)聯(lián)的標(biāo)準(zhǔn)4+1 視圖的一部分，但這一視圖是基本的。在最后，你不得不出售你的產(chǎn)品。

⁷兩個(gè)語境有很明顯的關(guān)系。作為在商業(yè)語境中購(gòu)買產(chǎn)品用例的一部分，商業(yè)觸發(fā)器支付請(qǐng)求使用 Simpay 語境中的例子。

⁸商人確定手機(jī)使用者能支付和為他儲(chǔ)備的貨幣。

⁹商人請(qǐng)求應(yīng)支付給他的金額。

¹⁰實(shí)際上，你甚至可以更進(jìn)一步考慮，并有一個(gè)獨(dú)立的支付請(qǐng)求用例：我們的確決定反對(duì)它。理由是范圍管理, 但是繼續(xù)向下看。

¹¹我不在這里討論擴(kuò)大并包括聯(lián)系。以我的經(jīng)驗(yàn)，最好在你的業(yè)務(wù)用例模型中避免這些聯(lián)系。

¹²在《 The Object Advantage》（Addison-Wesley，1995，第173頁），E.A. Jacobsen 介紹了一個(gè)算法，用于映射一個(gè)業(yè)務(wù)用例模型到一個(gè)系統(tǒng)用例模型。這里使用一個(gè)類似的算法，把一個(gè)業(yè)務(wù)用例模型映射到不同語境中的另一個(gè)業(yè)務(wù)用例模型。

¹³在確定的環(huán)境中，你可能有一個(gè)不存在響應(yīng)的請(qǐng)求。如果響應(yīng)沒有業(yè)務(wù)含義，這與被提議及將被使用的模型完全一致。

¹⁴相反地，我強(qiáng)烈建議你使用一個(gè)有細(xì)密紋理的編號(hào)樣式，作為用例描述。它允許你改良一致性、完整性檢查及參照。

¹⁵如果一個(gè)用例在多種狀態(tài)間轉(zhuǎn)換為業(yè)務(wù)實(shí)體。你可以轉(zhuǎn)換為備選流或一組步驟（舉例來說，使用標(biāo)簽或你用例描述的數(shù)字記號(hào)）。

¹⁶讓我強(qiáng)調(diào)一下，它們可能看起來象技師，但是它們不是技師，因?yàn)樗鼈儍H僅書寫商業(yè)決策的文檔。

¹⁷更多關(guān)于模式驅(qū)動(dòng)架構(gòu)的細(xì)節(jié)，參見 http://www./mda 和 Behrens，Richards的《 StateLator in Advanced Information Systems Engineering》，Springer，2000。

回頁首

參考資料

• 您可以參閱本文在 developerWorks 全球站點(diǎn)上的 英文原文。
  

回頁首

關(guān)于作者

		Thomas Behrens 是Alpheus（www.alpheus.com）的技術(shù)總監(jiān)和需求工程市場(chǎng)方面的頭。他宣傳在建立解決方案之前，需要了解并定義它，主要在技術(shù)驅(qū)動(dòng)環(huán)境中。他在電訊和財(cái)務(wù)服務(wù)領(lǐng)域已經(jīng)領(lǐng)導(dǎo)了大量的需求項(xiàng)目。由于作為 IBM Rational Rose的首批用戶之一，他對(duì)于IBM Rational工具和這種訓(xùn)練的相關(guān)過程非常專業(yè)。他在軟件工業(yè)中作為不同的角色有14年的經(jīng)驗(yàn)。Thomas 是一個(gè)認(rèn)證 IBM 講師。他從德國(guó)慕尼黑的陸?？杖姶髮W(xué)獲得計(jì)算機(jī)科學(xué)的學(xué)位。