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

第1章 需求建模語言入門

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

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

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

定義RML

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

傳統軟件需求實踐的挑戰

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

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

人腦的限制

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

7 /-2

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

需求文件

REQ001系統應該有姓、中間名首字母和名等字段。

REQ002系統應該顯示名字如果存儲的個人資料中已有一個。

REQ003系統應該要求姓名是完整的。

REQ004系統應該有職位或頭銜字段。

REQ005系統應該要求頭銜是完整的。

REQ006系統應該顯示職位或頭銜如果存儲的個人資料中已有一個。

REQ007系統應該有電子郵件地址字段。

REQ008系統應該有備用的電子郵件地址字段。

REQ009系統應該顯示電子郵件地址如果存儲的個人資料中已有一個。

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

REQ011系統應該要求電子郵件地址是完整的。

REQ012系統應該要求備用的電子郵件地址是完整的。

REQ013系統應該具有白天電話號碼的字段。

REQ014系統應該顯示電話號碼如果存儲的個人資料已有一個。

REQ015系統應該要求電話號碼是完整的。

REQ016系統應該在驗證電話號碼字段中所有字符是數字當用戶退出該字段時。

REQ017系統應該顯示錯誤消息如果在電話號碼字段不是所有字符都是數字。

REQ018系統應該有傳真號碼的字段。

REQ019系統應該要求傳真號碼是完整的。

REQ020系統應該顯示傳真號碼如果存儲的個人資料已有一個。

REQ021系統應該驗證在傳真號碼字段中的所有字符是數字當用戶退出該字段時。

REQ022系統應該顯示錯誤信息如果在傳真號碼字段里不是所有字符都是數字。

REQ023系統應該有街道地址的兩個字段。

REQ024系統應該要求街道地址字段是完整的。

REQ025系統應該顯示地址如果存儲的個人資料已有一個。

REQ026系統應該有城市的字段。

REQ027系統應該要求城市字段是完整的。

REQ028系統應該顯示城市如果存儲的個人資料已有一個。

REQ029系統應該有狀態的字段。

REQ030系統應該顯示狀態如果存儲的個人資料已有一個。

REQ031系統應該要求狀態字段是完整的。

REQ032系統應該有郵政編碼的字段。

REQ033系統應該顯示郵政編碼如果存儲的個人資料已有一個。

REQ034系統應該要求郵政編碼字段是完整的。

圖1-1 冗長的需求列表

圖比文字更容易理解

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

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

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

圖1-2 一張穿過賭場的地圖，對應于女服務員所說的路線

需求模型

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

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

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

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

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

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

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

為什么不用UML

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

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

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

需求與設計

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

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

一個層面的需求是對另一個層面的設計

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

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

不要用“什么”與“如何作用”的關系來區別“需求”和“設計”。這種方式不好。

確定業務的實際需要

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

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

定義需求

需求是企業需要在解決方案中實現的。因此需求可以包括功能性需求、非功能性需求、業務規則，甚至包括許多人傳統上所稱的設計?？梢允褂媚Ｐ头椒◣椭椖扛上等苏嬲靼仔枰裁矗皇歉嬖V他們允許他們選擇什么類型的需求。

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

表1-1 需求的例子

需求 類別

系統應該能夠自動批準或駁回信用申請 功能性需求

當信用指標高于750，系統應該自動批準信用申請 業務規則

對于信用指標低于750，當自動決定是否批準信用申請時，系統應該使用下列算法：[算法將加在這里] 業務規則

審批過程應該在30秒內返回給用戶 非功能性需求

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

很多人都愿意在網上搜索以解決他們的技術問題。

當遇到技術問題時，50%的人愿意等待以后再試。

90%的業務客戶都在上網進行。

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

需求模型不等于游戲的結束

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

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

在項目中使用RML

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

其他資源

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

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

參考文獻

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.