日本免费精品视频,男人的天堂在线免费视频,成人久久久精品乱码一区二区三区,高清成人爽a毛片免费网站

第1章 需求建模語言入門

離節(jié)假日旺季還有九個月，一家著名的網(wǎng)上零售商確定要在其網(wǎng)站上添加一組重要的新功能，這將大大增強(qiáng)消費體驗，直接增加銷售額，同時減少好幾個國家的客戶電話服務(wù)量。據(jù)估計，這些新功能會為公司每年增加1400萬美元的收入，而實現(xiàn)這些功能的費用卻不到200萬美元。產(chǎn)品經(jīng)理確定這些功能的要求和業(yè)務(wù)規(guī)則，開發(fā)團(tuán)隊和項目管理團(tuán)隊預(yù)估可以在節(jié)假日旺季節(jié)到來時輕松地完成項目。為了能按期交付產(chǎn)品，開發(fā)團(tuán)隊努力趕工，晚上和周末經(jīng)常加班加點。

八個月之后，該團(tuán)隊進(jìn)入的測試階段，感覺良好。他們完成了一長串功能增強(qiáng)以求獲得高額的回報。然而，一位測試人員發(fā)現(xiàn)稅收的計算是不正確的。不幸的是，這些計算錯誤只是冰山一角，因為團(tuán)隊忽略了和稅收團(tuán)隊交流。實際上，他們當(dāng)時沒有意識到必須這樣做。如果與稅收團(tuán)隊交流，他們會發(fā)現(xiàn)在有些國家營業(yè)時要遵守的稅務(wù)規(guī)則極為復(fù)雜，必須與管理稅收規(guī)則的第三方軟件進(jìn)行集成。項目被推遲，那個旺季1400萬美元的回報也成泡影。項目經(jīng)理被解雇，產(chǎn)品經(jīng)理被調(diào)往其他小項目。

項目經(jīng)常因為需求的缺失、不完整或者不明確而受到困擾(The Standish Group 2009)。錯誤的需求實踐普遍存在，所以大部分項目注定會失敗(Ellis, Keith. 2008)。需求沒做好是許多項目失敗的根源，令人失望的是在過去20年中軟件需求水平并沒有顯著提高。盡管學(xué)術(shù)界一直在穩(wěn)步改善需求技術(shù)和工程方法，但是業(yè)務(wù)實踐行為在很大程度上并沒有什么變化。軟件編程技術(shù)已經(jīng)相當(dāng)成熟，創(chuàng)造出各種新的技術(shù)，開發(fā)出豐富的工具，但是在寫需求時，人們還是常常使用一長串的“應(yīng)該”語句，把語句存在電子表格中。使用敏捷方法的項目也沒有多少改進(jìn)，還是經(jīng)常把產(chǎn)品工作清單和用戶故事作為一長串列表存在電子表格或其他工具中。

定義RML

RML(需求建模語言)是為建立需求視覺模型而專門設(shè)計的語言，它便于企業(yè)管理、業(yè)務(wù)和技術(shù)等項目干系人使用。RML不是一種學(xué)術(shù)上的建模語言。在開發(fā)RML期間，我們改進(jìn)了現(xiàn)有模型的易用性，創(chuàng)建新的模型來彌補(bǔ)功能上的缺失。結(jié)果就有了一套完整的模型，是專門為軟件需求建模而設(shè)計的，對于那些常常搞不懂復(fù)雜模型的項目干系人來說，更容易接受。我們已經(jīng)在許多大型軟件開發(fā)項目上成功使用了這些需求模型。

傳統(tǒng)軟件需求實踐的挑戰(zhàn)

傳統(tǒng)的做法不得不使用幾千行“系統(tǒng)應(yīng)該”這樣的需求描述句，其繁復(fù)程度如圖1-1所示。這些需求通常是通過與企業(yè)項目干系人面談或者舉行工作會議之后產(chǎn)生的。因為一般人都受米勒魔數(shù)的制約(參見下一節(jié)“人腦的限制”)，下面的事情幾乎是不可能發(fā)生的：人們在閱讀了數(shù)以千計的需求條款后，突然確信項目的需求是的。此外，另一個較大的問題是需求規(guī)模會逐漸變化。等你有了上千個需求，如果沒有某種方法把這些需求與價值聯(lián)系起來，力求在解決方案層面上進(jìn)行比較，將很難決定應(yīng)該砍掉哪些需求。團(tuán)隊經(jīng)常把需求進(jìn)行邏輯分組，但這些分組通常還是過大，無法得到有效的處理。

敏捷方法，如Scrum，有產(chǎn)品工作清單、用戶故事和驗收標(biāo)準(zhǔn)。許多Scrum布道者說，產(chǎn)品工作清單應(yīng)該是非嵌套的故事列表，這種做法比傳統(tǒng)的需求列表好不了多少。驗收標(biāo)準(zhǔn)也要求列出來，有時就列在便條卡的某一面上。做過大型系統(tǒng)的人都知道，在可能會有幾百個項目干系人參加的項目上，這種缺乏信息組織結(jié)構(gòu)的做法是行不通的。

人腦的限制

使用傳統(tǒng)實踐來創(chuàng)建軟件需求的業(yè)務(wù)分析師在分析、組織和使用需求上會遇到同樣的問題。傳統(tǒng)的做法使用冗長列表來列出需求的文字描述，其形式是“應(yīng)該”語句、用例、最近又增加的用戶故事和產(chǎn)品工作清單。受限于人類的基本認(rèn)知能力，冗長的清單列表使用起來都很困難。在20世紀(jì)50年代，認(rèn)知心理學(xué)家喬治•米勒發(fā)現(xiàn)，人類只能記住和處理7加或減2項內(nèi)容(Miller, George A. 1956)，這通常稱為“米勒魔數(shù)”。

7 /-2

后來的證據(jù)表明基數(shù)甚至可能少到3或4(Cowan, Nelson. 2001)。這個數(shù)字代表大腦“暫存器”解決問題時所能保存的信息容量。無論實際數(shù)目是多少，如果要求普通人同時考慮大約15件事情，實際上最多只能記住和處理其中9件(可能更少)。如果要求處理的事情更多，一次只有幾件可以同時處理，其他的會被快速切入或切出暫存器。想想去雜貨店購買15件東西，如果沒有一份寫好的購物清單，你很可能漏掉東西或者買回的東西數(shù)量不正確。同樣的道理，如果需求列表或產(chǎn)品工作清單中的事項成百上千，那么你的大腦根本沒有辦法處理這種復(fù)雜性，除非把它分解成更小的結(jié)構(gòu)化分組。

需求文件

REQ001系統(tǒng)應(yīng)該有姓、中間名首字母和名等字段。

REQ002系統(tǒng)應(yīng)該顯示名字如果存儲的個人資料中已有一個。

REQ003系統(tǒng)應(yīng)該要求姓名是完整的。

REQ004系統(tǒng)應(yīng)該有職位或頭銜字段。

REQ005系統(tǒng)應(yīng)該要求頭銜是完整的。

REQ006系統(tǒng)應(yīng)該顯示職位或頭銜如果存儲的個人資料中已有一個。

REQ007系統(tǒng)應(yīng)該有電子郵件地址字段。

REQ008系統(tǒng)應(yīng)該有備用的電子郵件地址字段。

REQ009系統(tǒng)應(yīng)該顯示電子郵件地址如果存儲的個人資料中已有一個。

REQ010系統(tǒng)應(yīng)該顯示備用電子郵件地址如果存儲的個人資料中已有一個。

REQ011系統(tǒng)應(yīng)該要求電子郵件地址是完整的。

REQ012系統(tǒng)應(yīng)該要求備用的電子郵件地址是完整的。

REQ013系統(tǒng)應(yīng)該具有白天電話號碼的字段。

REQ014系統(tǒng)應(yīng)該顯示電話號碼如果存儲的個人資料已有一個。

REQ015系統(tǒng)應(yīng)該要求電話號碼是完整的。

REQ016系統(tǒng)應(yīng)該在驗證電話號碼字段中所有字符是數(shù)字當(dāng)用戶退出該字段時。

REQ017系統(tǒng)應(yīng)該顯示錯誤消息如果在電話號碼字段不是所有字符都是數(shù)字。

REQ018系統(tǒng)應(yīng)該有傳真號碼的字段。

REQ019系統(tǒng)應(yīng)該要求傳真號碼是完整的。

REQ020系統(tǒng)應(yīng)該顯示傳真號碼如果存儲的個人資料已有一個。

REQ021系統(tǒng)應(yīng)該驗證在傳真號碼字段中的所有字符是數(shù)字當(dāng)用戶退出該字段時。

REQ022系統(tǒng)應(yīng)該顯示錯誤信息如果在傳真號碼字段里不是所有字符都是數(shù)字。

REQ023系統(tǒng)應(yīng)該有街道地址的兩個字段。

REQ024系統(tǒng)應(yīng)該要求街道地址字段是完整的。

REQ025系統(tǒng)應(yīng)該顯示地址如果存儲的個人資料已有一個。

REQ026系統(tǒng)應(yīng)該有城市的字段。

REQ027系統(tǒng)應(yīng)該要求城市字段是完整的。

REQ028系統(tǒng)應(yīng)該顯示城市如果存儲的個人資料已有一個。

REQ029系統(tǒng)應(yīng)該有狀態(tài)的字段。

REQ030系統(tǒng)應(yīng)該顯示狀態(tài)如果存儲的個人資料已有一個。

REQ031系統(tǒng)應(yīng)該要求狀態(tài)字段是完整的。

REQ032系統(tǒng)應(yīng)該有郵政編碼的字段。

REQ033系統(tǒng)應(yīng)該顯示郵政編碼如果存儲的個人資料已有一個。

REQ034系統(tǒng)應(yīng)該要求郵政編碼字段是完整的。

圖1-1 冗長的需求列表

圖比文字更容易理解

如何解決原始哺乳動物大腦的基本限制呢？有句話說得好：“一圖勝千言。”模型是信息的視覺表現(xiàn)方式(圖形)，它描述了流程、數(shù)據(jù)和解決方案內(nèi)部和環(huán)境的互動。你可能每天都在使用視覺模型但可能沒有意識到這一點。

最近我出差，參加一個在賭場酒店舉辦的會議，我在前臺登記后領(lǐng)到了房間的鑰匙，前臺女服務(wù)員給我指路，告訴我怎么去我的房間。她說了類似這樣的話：“你從這里沿著右邊走出去，然后沿著路向左行，穿過一個酒吧，路過幾臺老虎機(jī)，在噴泉附近向右轉(zhuǎn)，走過一家餐廳，再走過一家餐廳，然后你會走到一個大廳，在那里向左轉(zhuǎn)走過一條商業(yè)街，在路的盡頭你會發(fā)現(xiàn)游泳池入口處有一個電梯。”

我茫然地盯著她。那一刻我能想起的就只有我剛剛從出租車走到前臺時所看到的很多老虎機(jī)和賭桌。我假設(shè)在去房間的路上會走過更多的老虎機(jī)和賭臺，女服務(wù)員剛才講的已經(jīng)記不清楚，反而把我搞得更糊涂。后來她給了我一點兒希望：“這張圖畫了怎么去那里。”她畫出從前臺到電梯的路線圖，如圖1-2所示。我松了一口氣，因為我只記住了她所說的前幾步，其他記不住，但現(xiàn)在我有了一個模型，我糊涂的時候可以參考。一張圖！總而言之，當(dāng)人類解釋信息時，圖比文字更容易理解。

圖1-2 一張穿過賭場的地圖，對應(yīng)于女服務(wù)員所說的路線

需求模型

需求模型組織和展示了大量信息，幫助你發(fā)現(xiàn)缺失的信息，并給出上下文細(xì)節(jié)(Gottesdiener, Ellen. 2002)。最重要的是模型可以從視覺上進(jìn)行分組，使你能夠通過短期記憶能力快速分析大量截然不同的信息。在有幾千條“系統(tǒng)應(yīng)該”句式的需求文檔中，閱讀、解釋并找出差異是很困難的，而視覺模型能夠提供幫助。

想象在你面前零亂擺放的字母(如圖1-3所示)，要你找出字母表中哪些字母沒有出現(xiàn)。

圖1-3 零亂擺放的字母中，缺了哪個字母

如果你只是盯著混亂的字母或甚至把字母無序地排成一行，是很難發(fā)現(xiàn)缺了哪個字母的(事實上，你可能剛剛試著把它們按順序排列起來)。如果按字母順序排列(如圖1-4所示)，瞬間就會發(fā)現(xiàn)缺失的字母。

要找到缺失的需求，關(guān)鍵是利用一個事實，每一個需求與其他需求都有著某種聯(lián)系。當(dāng)你得到一長串“系統(tǒng)應(yīng)該”的需求條款時，要想保障其完整性是極其困難的，但如果重新組織需求就可以利用這種聯(lián)系，每次只在較小的分組里分析信息從而大大簡化任務(wù)。

需求模型用于項目的整個生命周期。這些模型可用于多種場合，有助于分析需求，有助于向項目干系人提出需求和驗證需求，有助于與開發(fā)人員和測試人員溝通需求。

圖1-4 排列已有字母，找出缺失的字母

為什么不用UML

一個直接的問題出現(xiàn)了：“為什么不使用統(tǒng)一建模語言(UML)？”|UML是一種專門用于以可視化方式設(shè)計軟件系統(tǒng)的語言(請參閱文獻(xiàn)Object Management Group. 2007)。UML為需求建模奠定了合理基礎(chǔ)，但它不滿足需求建模的全部要求，因為它缺少有關(guān)需求與業(yè)務(wù)價值的模型，缺少從最終用戶的角度展示系統(tǒng)結(jié)構(gòu)的模型。此外，它在技術(shù)上過于復(fù)雜使得業(yè)務(wù)項目干系人難以掌握，因為它的模型側(cè)重于軟件系統(tǒng)的架構(gòu)建模。，UML用于描述系統(tǒng)的技術(shù)設(shè)計和結(jié)構(gòu)，頂多在建模方面對UML進(jìn)行翻新改造以支持業(yè)務(wù)收益、用戶操作和業(yè)務(wù)規(guī)則。

當(dāng)一個模型只聚集于解決問題的一個或兩個方面時，它是最有用的。如果一個模型具有許多類型的信息或者模型的語法規(guī)則過于復(fù)雜和難于理解，項目干系人不會用。事實上，我們的經(jīng)驗說明，模型的復(fù)雜性是造成大型企業(yè)不用一些現(xiàn)有建模語言的主要原因之一。

RML模型是用最簡單的語法設(shè)計出來的，還可以傳達(dá)必要的信息。RML的目的是提供一致的語法和語義結(jié)構(gòu)供業(yè)務(wù)干系人分析和理解項目模型。設(shè)計該語言的目的是讓整個團(tuán)隊容易學(xué)習(xí)和使用，包括但又不局限于業(yè)務(wù)項目干系人、開發(fā)人員和測試人員。模型簡化到只有最基本的符號和格式，但還能保障在需求方面取得預(yù)期的結(jié)果。RML不只針對軟件開發(fā)方法，也可以容易適應(yīng)于與任何開發(fā)方法或工具套件結(jié)合使用。

需求與設(shè)計

許多RML模型在業(yè)務(wù)分析師看來通常屬于設(shè)計領(lǐng)域。例如，顯示-操作-響應(yīng)模型使用線框或屏幕截圖來描述用戶如何與屏幕元素交互，用戶界面流模型展示用戶如何瀏覽各種用戶界面。

有一句關(guān)于需求的諺語：“需求關(guān)注的是要建什么，設(shè)計關(guān)注的則是它如何起作用。”需求和設(shè)計之間的區(qū)別很重要，因為很多人強(qiáng)調(diào)任何設(shè)計都不應(yīng)該和需求混在一起，設(shè)計文檔不應(yīng)該由業(yè)務(wù)分析師來寫。遺憾的是，這種嚴(yán)格的定義存在一個問題：“一個層面的需求是對另一個層面的設(shè)計。”

一個層面的需求是對另一個層面的設(shè)計

在自上而下的解決方案中有不同的概念層面，如果考慮一個層面是有關(guān)“什么”的，那么它的下一層面將是有關(guān)“如何作用”于它的。因此，基于這種“什么”與“如何作用”的定義，如果一個層面是需求，那么下面的層面就應(yīng)該是對需求的設(shè)計。

例如，項目干系人可能需要降低網(wǎng)站的購物車放棄率。在下面的細(xì)節(jié)層面，產(chǎn)品經(jīng)理可能會提出幾個不同的解決方案力求降低購物車放棄率。例如，該團(tuán)隊可以減少結(jié)賬過程中的步驟，可以提供保留購物車內(nèi)容的功能方便顧客下次購買，或者可以提供免費送貨服務(wù)。提出的每一個解決方案都是有關(guān)“如何作用”(即“設(shè)計”)的，滿足的是“什么”需求(即降低購物車放棄率)。此外，最初的“什么”(即改進(jìn)系統(tǒng)降低購物車放棄率)可能同樣也是“如何作用”(即試圖改進(jìn)整個網(wǎng)站轉(zhuǎn)化率)。

不要用“什么”與“如何作用”的關(guān)系來區(qū)別“需求”和“設(shè)計”。這種方式不好。

確定業(yè)務(wù)的實際需要

另一個常見的定義是，任何有關(guān)實際解決方案的都屬于設(shè)計而不是需求，例如算法的使用、外觀和感覺、用戶界面元素等。但是，在有些情況下，特定的請求有時可能是需求，而有時可能是設(shè)計。例如，在某些行業(yè)中，一個產(chǎn)品為了競爭的需要必須使用專門的加密算法，因此它是一種需求。對于另一個應(yīng)用程序，它不關(guān)心使用專門的加密算法，重要的是應(yīng)用程序必須使用某種算法來加密信用卡號碼。

用戶要求是不是需求，關(guān)鍵要看業(yè)務(wù)項目干系人是否真正需要它。我們都知道，項目干系人實際上并不需要他們宣稱自己想要所有的特征，所以要對請求作出判斷，它是否真正是需求，用戶是否真的需要。

定義需求

需求是企業(yè)需要在解決方案中實現(xiàn)的。因此需求可以包括功能性需求、非功能性需求、業(yè)務(wù)規(guī)則，甚至包括許多人傳統(tǒng)上所稱的設(shè)計。可以使用模型方法幫助項目干系人真正明白需要什么，而不是告訴他們允許他們選擇什么類型的需求。

本節(jié)定義一些用于全書的需求術(shù)語。功能性需求是一個解決方案所提供的行為或功能而不加任何限定詞。業(yè)務(wù)規(guī)則表示在修改功能性需求時必須滿足的條件語句，包括但不限于什么時候該功能可以用以及允許誰執(zhí)行該功能。業(yè)務(wù)規(guī)則包含諸如“如果”“何時”和“然后”等詞匯。非功能性需求是任何不屬于功能性的需求(包括業(yè)務(wù)規(guī)則)。特性是一個功能區(qū)域的簡短描述，解決方案將最終實現(xiàn)該特性以達(dá)到業(yè)務(wù)目標(biāo)。特性是需求的集合，用來清楚描述和組織需求。表1-1給出了幾個例子。

表1-1 需求的例子

需求 類別

系統(tǒng)應(yīng)該能夠自動批準(zhǔn)或駁回信用申請 功能性需求

當(dāng)信用指標(biāo)高于750，系統(tǒng)應(yīng)該自動批準(zhǔn)信用申請 業(yè)務(wù)規(guī)則

對于信用指標(biāo)低于750，當(dāng)自動決定是否批準(zhǔn)信用申請時，系統(tǒng)應(yīng)該使用下列算法：[算法將加在這里] 業(yè)務(wù)規(guī)則

審批過程應(yīng)該在30秒內(nèi)返回給用戶 非功能性需求

假設(shè)是做決策時所依據(jù)的真實陳述。假設(shè)包括對未來的任何預(yù)測或預(yù)報。假設(shè)對于需求非常關(guān)鍵，因為這些假設(shè)會不斷被引用，但很少有人理解或能夠有人講清楚。事實上，如果讓業(yè)務(wù)分析師寫下自己的假設(shè)，他們通常寫下一些瑣碎的小事，既不具有影響力又缺乏重要性。如果這些例子中的假設(shè)被證明是不正確的，可能會導(dǎo)致業(yè)務(wù)目標(biāo)無法實現(xiàn)。

很多人都愿意在網(wǎng)上搜索以解決他們的技術(shù)問題。

當(dāng)遇到技術(shù)問題時，50%的人愿意等待以后再試。

90%的業(yè)務(wù)客戶都在上網(wǎng)進(jìn)行。

待解決的問題中有些問題可以由客戶自行解決。

需求模型不等于游戲的結(jié)束

需求模型的使用并沒有取消寫需求。雖然模型提供上下文又創(chuàng)建了有關(guān)需求的完整圖形，但是模型還不是系統(tǒng)開發(fā)人員和測試人員最終使用的形式，必須采取額外的步驟從模型中提煉出需求。就像按照貨架走道來組織購物清單一樣，要為開發(fā)項目的團(tuán)隊產(chǎn)生需求清單。模型的價值在于以某種方式幫助組織所有的需求，以便很容易看出需求有缺失、無關(guān)或不正確的情況。

創(chuàng)建的所有模型都應(yīng)該納入項目的全部需求中。文字需求和可視化需求共同描繪出待建的解決方案的全景(Wiegers, Karl E. 2003)。

在項目中使用RML

可以把這本書中介紹的RML模型想象成軟件項目的模型模板工具箱。通常情況下，建議綜合使用多個模型，有些常用的方法定義了在整個開發(fā)周期中何時使用特定的模型。把需求模型應(yīng)用到項目時，可以和許多開發(fā)方法一起使用，例如敏捷方法、迭代方法和瀑布方法(參見第25章)。

其他資源

“業(yè)務(wù)分析師的RML快速參考指南”，兩頁篇幅的模型相關(guān)摘要：www.seilevel.com/wp-content/uploads/RML-Language-for-Modeling-Software-Requirements.pdf

《軟件需求》(第2版)第11章系統(tǒng)介紹了模型的價值(Wiegers, Karl E. 2003)

參考文獻(xiàn)

l Chen, Anthony. 2010. “What vs. How – BRD vs. User Requirements vs. Functional Requirements”: requirements.seilevel.com/blog/2010/04/ what-vs-how-brd-vs-user-requirements-vs-functional-requirements.html.

l Cowan, Nelson. 2001. “The Magical Number 4 in Short-Term Memory: A Reconsideration of Mental Storage Capacity.” Behavioral and Brain Sciences 24, 87-114.

l Ellis, Keith. 2008. “Business Analysis Benchmark Report.“ IAG Consulting. www.iag.biz/images/resources/iag%20business% 20analysis%20benchmark%20-%20executive%20summary.pdf.

l Gottesdiener, Ellen. 2002. Requirements by Collaboration: Workshops for Defining Needs. Boston, MA: Addison-Wesley Professional.

l Miller, George A. 1956. “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information.” Psychological Review 63, 81-97.

l Object Management Group. 2007. “OMG Unified Modeling Language Specification.” www.uml.org/#UML2.0.

l The Standish Group. 2009. “CHAOS Summary 2009.” West Yarmouth, MA: The Standish Group International, Inc.

l Wiegers, Karl E. 2003. Software Requirements, Second Edition. Redmond, WA: Microsoft Press.