具體描述
産品特色
編輯推薦
聚焦於軟件需求中的目標、人、係統和數據；重點介紹四大類需求可視化模型的實踐運用
內容簡介
需求文檔的模糊性和歧義性是導緻很多軟件項目最終無法滿足用戶需求的主要原因。針對這一現狀，本書主要側重於以視覺化方式來錶達軟件需求，介紹瞭4大類22個可視化需求模型，旨在指導讀者通過軟件需求的視覺化模型來進一步明確需求，促進開發人員對需求的理解，從而進一步推動軟件項目的成功。
本書取自需求領域兩位專傢十多年的實踐經驗，具有重要的指導和參考意義，可以幫助讀者準確理解需求，開發齣滿足用戶需求和可以幫助用戶達成任務目標的軟件産品。
作者簡介
Anthony Chen（安東尼·陳），Seilevel聯閤創始人兼總裁。在過去十幾年間，Anthony與財富500強許多公司有廣泛的閤作。他是Seilevel的戰略負責人和軟件需求創新技術的開發負責人。他針對軟件需求技術、用戶體驗和需求分析思路寫過很多文章。
他擁有伊利諾大學電子工程和微生物學雙學士學位，德州農工大學微生物和免疫學碩士學位。
Joy Beatty（喬伊·貝迪），軟件需求社區的領袖，Seilevel公司副總裁，認證以業務分析師（CBAP）。經過15年的專業經驗積纍，Joy找到瞭如何運用*佳實踐來改進需求收集和建模。她協助財富500強很多企業建立瞭卓越業務分析中心。她培訓過的業務分析師數以韆計。
Joy畢業於普渡大學，擁有計算機科學與數學雙學士學位。工作之餘，Joy還熱愛劃船、遊泳、外齣野炊。
方敏，微軟公司前資深軟件架構師，早期微軟美國華人協會聯閤創始人。他具有豐富的技術和管理經驗和廣泛的人生閱曆，他高度重視用戶對軟件的需求，非常熟悉敏捷軟件開發和經典軟件管理，注重團隊的優勢和創新。他已與清華大學齣版社翻譯齣版瞭幾本價值極高的軟件工程書籍。
赴美之前，他在中國航天部計算中心從事過微機開發工作。他擁有清華大學電子工程學士和碩士學位，美國新墨西哥州礦業技術學院計算機科學碩士學位。
方敏領導和參與和很多優秀書籍的翻譯，包括《敏捷文化》、《Windows 程序設計》、《探索性軟件測試》和《遊戲創造世界：矽榖創新遊戲練習》等。
硃嶸，在英國航空電子係統公司擔任質量工程師期間，主要負責空客A320、空客A340、波音737、波音747等飛機機型的關鍵質量分析和故障維修，具有豐富的專業經驗。
赴美之前，她在中國航天部二院擔任工程師，負責紅七地對空導彈通信係統的研發。她擁有哈爾濱工業大學無綫電工程學士學位。
內頁插圖
目錄
第Ⅰ部分 需求模型介紹
第1章 需求建模語言入門 3
第2章 模型分類 12
第Ⅱ部分 對象模型
第3章 業務目標模型 23
第4章 目標鏈 40
第5章 關鍵績效指標模型 57
第6章 特性樹 67
第7章 需求映射矩陣 78
第Ⅲ部分 人員模型
第8章 組織結構圖 95
第9章 處理流程 109
第10章 用例 125
第11章 角色權限矩陣 143
第Ⅳ部分 係統模型
第12章 生態係統圖 159
第13章 係統流程 171
第14章 用戶界麵流程 182
第15章 顯示-動作-響應 195
第16章 決策錶 210
第17章 決策樹 221
第18章 係統界麵錶 233
第Ⅴ部分 數據模型
第19章 業務數據圖 243
第20章 數據流圖 258
第21章 數據字典 268
第22章 狀態錶 283
第23章 狀態圖 293
第24章 報告錶 303
第Ⅵ部分 大局圖中的模型
第25章 項目模型的選擇 317
第26章 模型的綜閤應用 336
第Ⅲ部分 附錄
附錄A 快速查找模型錶格 355
附錄B 一般性模型指南 357
附錄C 練習答案 359
精彩書摘
第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模型在業務分析師看來通常屬於設計領域。例如，顯示-操作-響應模型使用綫框或屏幕截圖來描述用戶如何與屏幕元素交互，用戶界麵流模型展示用戶如何瀏覽各種用戶界麵。
有一句關於需求的諺語：“需求關注的是要建什麼，設計關注的則是它如何起作用。”需求和設計之間的區彆很重要，因為很多人強調任何設計都不應該和需求混在一起，設計文檔不應該由業務分析師來寫。遺憾的是，這種嚴格的定義存在一個問題：“一個層麵的需求是對另一個層麵的設計。”
一個層麵的需求是對另一個層麵的設計
在自上而下的解決方案中有不同的概念層麵，如果考慮一個層麵是有關“什麼”的，那麼它的下一層麵將是有關“如何作用”於它的。因此，基於這種“什麼”與“如何作用”的定義，如果一個層麵是需求，那麼下麵的層麵就應該是對需求的設計。
例如，項目乾係人可能需要降低網站的購物車放棄率。在下麵的細節層麵，産品經理可能會提齣幾個不同的解決方案力求降低購物車放棄率。例如，該團隊可以減少結賬過程中的步驟，可以提供保留購物車內容的功能方便顧客下次購買，或者可以提供免費送貨服務。提齣的每一個解決方案都是有關“如何作用”(即“設計”)的，滿足的是“什麼”需求(即降低購物車放棄率)。此外，最初的“什麼”(即改進係統降低購物車放棄率)可能同樣也是“如何作用”(即試圖改進整個網站轉化率)。
不要用“什麼”與“如何作用”的關係來區彆“需求”和“設計”。這種方式不好。
確定業務的實際需要
另一個常見的定義是，任何有關實際解決方案的都屬於設計而不是需求，例如算法的使用、外觀和感覺、用戶界麵元素等。但是，在有些情況下，特定的請求有時可能是需求，而有時可能是設計。例如，在某些行業中，一個産品為瞭競爭的需要必須使用專門的加密算法，因此它是一種需求。對於另一個應用程序，它完全不關心使用專門的加密算法，唯一重要的是應用程序必須使用某種算法來加密信用卡號碼。
用戶要求是不是需求，關鍵要看業務項目乾係人是否真正需要它。我們都知道，項目乾係人實際上並不需要他們宣稱自己想要所有的特徵，所以要對請求作齣判斷，它是否真正是需求，用戶是否真的需要。
定義需求
需求是企業需要在解決方案中實現的。因此需求可以包括功能性需求、非功能性需求、業務規則，甚至包括許多人傳統上所稱的設計。可以使用模型方法幫助項目乾係人真正明白需要什麼，而不是告訴他們允許他們選擇什麼類型的需求。
本節定義一些用於全書的需求術語。功能性需求是一個解決方案所提供的行為或功能而不加任何限定詞。業務規則錶示在修改功能性需求時必須滿足的條件語句，包括但不限於什麼時候該功能可以用以及允許誰執行該功能。業務規則包含諸如“如果”“何時”和“然後”等詞匯。非功能性需求是任何不屬於功能性的需求(包括業務規則)。特性是一個功能區域的簡短描述，解決方案將最終實現該特性以達到業務目標。特性是需求的集閤，用來清楚描述和組織需求。錶1-1給齣瞭幾個例子。
錶1-1 需求的例子
需求 類彆
係統應該能夠自動批準或駁迴信用申請 功能性需求
當信用指標高於750，係統應該自動批準信用申請 業務規則
對於信用指標低於750，當自動決定是否批準信用申請時，係統應該使用下列算法：[算法將加在這裏] 業務規則
審批過程應該在30秒內返迴給用戶 非功能性需求
假設是做決策時所依據的真實陳述。假設包括對未來的任何預測或預報。假設對於需求非常關鍵，因為這些假設會不斷被引用，但很少有人理解或能夠有人講清楚。事實上，如果讓業務分析師寫下自己的假設，他們通常寫下一些瑣碎的小事，既不具有影響力又缺乏重要性。如果這些例子中的假設被證明是不正確的，可能會導緻業務目標無法實現。
很多人都願意在網上搜索以解決他們的技術問題。
當遇到技術問題時，50%的人願意等待以後再試。
90%的業務客戶都在上網進行。
待解決的問題中有些問題可以由客戶自行解決。
需求模型不等於遊戲的結束
需求模型的使用並沒有完全取消寫需求。雖然模型提供上下文又創建瞭有關需求的完整圖形，但是模型還不是係統開發人員和測試人員最終使用的形式，必須采取額外的步驟從模型中提煉齣需求。就像按照貨架走道來組織購物清單一樣，要為開發項目的團隊産生需求清單。模型的價值在於以某種方式幫助組織所有的需求，以便很容易看齣需求有缺失、無關或不正確的情況。
創建的所有模型都應該納入項目的全部需求中。文字需求和可視化需求共同描繪齣待建的解決方案的全景(Wiegers, Karl E. 2003)。
在項目中使用RML
可以把這本書中介紹的RML模型想象成軟件項目的模型模闆工具箱。通常情況下，建議綜閤使用多個模型，有些常用的方法定義瞭在整個開發周期中何時使用特定的模型。把需求模型應用到項目時，可以和許多開發方法一起使用，例如敏捷方法、迭代方法和瀑布方法(參見第25章)。
其他資源
“業務分析師的RML快速參考指南”，兩頁篇幅的模型相關摘要：http://www.seilevel.com/wp-content/uploads/RML-Language-for-Modeling-Software-Requirements.pdf
《軟件需求》(第2版)第11章係統介紹瞭模型的價值(Wiegers, Karl E. 2003)
參考文獻
Chen, Anthony. 2010. “What vs. How – BRD vs. User Requirements vs. Functional Requirements”: http://requirements.seilevel.com/blog/2010/04/ what-vs-how-brd-vs-user-requirements-vs-functional-requirements.html.
Cowan, Nelson. 2001. “The Magical Number 4 in Short-Term Memory: A Reconsideration of Mental Storage Capacity.” Behavioral and Brain Sciences 24, 87-114.
Ellis, Keith. 2008. “Business Analysis Benchmark Report.“ IAG Consulting. http://www.iag.biz/images/resources/iag%20business% 20analysis%20benchmark%20-%20executive%20summary.pdf.
Gottesdiener, Ellen. 2002. Requirements by Collaboration: Workshops for Defining Needs. Boston, MA: Addison-Wesley Professional.
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.
Object Management Group. 2007. “OMG Unified Modeling Language Specification.” http://www.uml.org/#UML2.0.
The Standish Group. 2009. “CHAOS Summary 2009.” West Yarmouth, MA: The Standish Group International, Inc.
Wiegers, Karl E. 2003. Software Requirements, Second Edition. Redmond, WA: Microsoft Press.
……
前言/序言
可視化需求模型是確認軟件需求最有效的方法之一。這些模型幫助市場分析師確認，所有的項目利益相關者能夠理解提齣的解決方案，這些人士包括領域專傢、商業利益相關者、高層管理人員和技術團隊。可視化方式讓項目利益相關者對項目更感興趣，更樂於參與，其目的是找齣需求方麵是否存在差異。更重要的是，可視化創造瞭圖形化的解決方案，幫助項目利益相關者理解解決方案交付什麼結果和不包括什麼。雖然可視化有這些優點，許多市場分析師和産品經理還是使用非可視化的電子錶格或文本列齣數韆行條款。這些大量的文檔讓人吃不消，審查起來很枯燥，極不容易發現缺失的需求。這種實際狀況反映當前需求專業培訓有哪些問題癥狀，培訓往往注重如何寫齣每條好的需求，而不注重如何分析整個解決方案。
這本書將幫助市場分析師、産品經理以及部門其他成員使用可視化模型捕獲需求、建立模型和理解需求。本書描述瞭一種簡潔而完整的語言RML(Requirements Modeling Language，需求建模語言)，它用於建立軟件需求的可視化模型，收集和規範瞭工業界中普遍使用的最佳實踐模型。
誰應該讀這本書
雖然這本書主要針對市場分析師和産品經理，但是我們認為項目經理、開發人員、架構師和測試人員也可以從這本書中獲得巨大的價值，因為它可以幫助他們學習必要的信息標準，使他們的工作更容易。這本書通常把實際做工作的人稱為“市場分析師”，在不同的部門裏這個角色有著許多不同的職稱。當提到“你”，我們也是指“市場分析師”。
事先告訴大傢，我們的經驗主要基於在現有基礎架構上建設軟件的項目，例如麵嚮內部的信息技術係統(IT)、麵嚮消費者的作為軟件即服務(SaaS)的大型軟件係統以及雲係統。雖然我們已經在獨立的軟件包和嵌入式係統中使用瞭RML，但是這些類型的項目都不是我們的主打領域。根據我們對這些係統的有限經驗，認為做這些係統工作的讀者也會發現RML提供瞭令人難以置信的價值，我們期待著收到他們提齣的改進意見。
本書的假設
本書假設你已具有編寫軟件需求的基礎知識，因此不提供需求工作的基本信息。本書希望你對軟件開發過程有些基本瞭解，例如，迭代方法、瀑布方法、和敏捷方法，知道它們是如何處理軟件需求的。
誰不必讀這本書
如果你剛剛開始做市場分析師，我們建議你在讀這本書之前先閱讀卡爾·魏格斯所寫的《軟件需求》一書，瞭解需求領域的全麵概況。如果你正在開發獨立包裝齣售的軟件，書裏的一些概念還是有意義的，不過你可能會發現商業定位不同。如果你是一個産品經理，側重於軟件産品的戰略和營銷而不是開發軟件，這本書可能對你不閤適，因為它重點集中於如何設計軟件功能使其受到高端用戶的認可。
本書的結構
我們組織這本書的目的是將它作為參考指南。
第Ⅰ部分先介紹一般模型的情況，然後討論RML語言和四類模型：目標模型、人員模型、係統模型和數據模型(OPSD)。
第Ⅱ部分到第Ⅴ部分的各章討論全部RML模型，各章有相同的結構，其中包括：
有關模型的真實故事
模型的定義
模型的模闆
建議創建模型的工具
虛構的例子
解釋如何創建和使用模型
學習使用模型的練習
所有這些章的練習都圍繞著一個樣品項目而設計。
第Ⅵ部分解釋如何選擇模型以及如何使用模型來産生軟件需求。
附錄A包含兩個快速模型查找錶作為模型選擇指導，附錄B建議創建模型的一般準則，包括所有的模型元數據和模闆提示，附錄C給齣書中所有練習的答案。還有一個詞匯錶定義本書用過的術語。
閱讀本書的最佳切入點
可以直接閱讀全書，但對有些人來說，在深入每個模型的細節之前，從第Ⅵ部分開始閱讀會更好地理解上下文。下錶提供瞭更多的指導。
讀者對象 建議步驟
總體上不熟悉需求建模或可視化建模 可以從前到後地閱讀本書，看看需求模型的介紹，
瞭解每個模型的內容，最後把它們聯係起來使用
熟悉可視化需求建模或者 建議瀏覽所有的章節，瞭解RML在可視化建模上與
是使用過類似模型的市場分析師 其他建模語言有什麼不同。但是可能從第Ⅵ部分
開始瞭解更高級的內容更有幫助，如何選擇模型
以及如何在項目中把多個模型一起使用。當項目
需要時，可以參考相關模型的章節
建模快速入門
這本書包含學習需求建模的大量信息。前景是美好的，為此我們開發瞭一種方法，使用盡可能少的模型但能為項目創造明顯的價值。這種快速啓動的方法適用於大多數IT項目。下麵的流程圖總結瞭這種方法。
如圖所示，首先創建業務流程。接下來，根據流程步驟創建需求映射矩陣(RMM)。然後為流程步驟的截屏創建對應的顯示-操作-響應(DAR)模型，將它們映射到業務流程步驟上。最後創建數據字典確保所有字段都包括，確認字段的驗證規則。
雖然這張圖沒有提到很多其他有價值的模型，但給齣瞭一係列讀者容易理解的主要步驟。最後結果是，項目的需求將按照流程步驟來組織，截屏也將映射到流程步驟，以確保用戶界麵滿足關鍵流程的需要。
本書約定和功能
本書使用專門的約定確保信息易於理解，易於遵循。
每章開始處用斜體字嚮讀者講述一個非軟件的故事作為引子。
整本書中所有RML模型名稱都大寫。用非RML的其他建模語言建的模型名稱不大寫。
RML模型的模塊稱為元素，這些模型元素名稱沒有大寫，以免與模型名稱混淆。
這本書結尾處的詞匯錶列齣我們認為重要的RML術語。這些術語以斜體字貫穿全書。
每個模型的模闆提供工具提示的讀者幫助，建議使用何種工具創建該模型。
配套內容
如果項目需要創建本書的模型時，歡迎你下載使用RML模型模闆。RML模型的全套模闆下載網址
壓縮文件中的使用說明介紹瞭如何使用模闆。簡單步驟如下：下載壓縮文件，還原文件內容放到方便的地方。每個模型有一個模闆，Visio文件格式的模型包括一個模闆和一個模闆文件，模闆正常工作需要這兩個部分。其餘模闆均為Excel格式或Word格式。快速模型查找錶也在壓縮文件中。
緻謝
從我們Seilevel公司的團隊到在世界各地做需求工作的同事，再到多年來一直支持和幫助我們改進RML的客戶，沒有你們的閤作，這本書是不可能齣版的。
非常感謝Seilevel公司的員工幫助研究、審閱、寫作、編輯和起草模型，提齣很難迴答的好問題，他們是喬伊斯·格雷普斯、詹姆·哈爾根、貝琪斯·托剋代爾、邁剋爾·劉、坎達絲·霍卡鬆、傑裏·高爾、巴拉吉·維賈揚、馬剋·塔爾博特、馬特·奧佛斯、阿賈伊·巴德裏、傑森·菲爾德、傑拉爾丁·濛戈爾德、凱爾·康登、剋林特·格雷厄姆、大衛·萊因哈特、韋斯·埃德森、阿蔔杜勒·馬瑟、剋裏斯·蒂森索、羅布·斯巴剋斯和洛瑞·威策爾。
我們誠摯地感謝許多審閱人員，他們花時間閱讀書稿，給齣他們的想法和批評，幫助改進本書。他們是喬伊·斯塔茲、肯特·麥當勞、莎拉·格雷戈裏、列爾卡·彆烏斯-杜奇、瑪麗·戈若斯、卡爾·魏格斯、埃倫·戈特斯蒂訥、斯科特·賽爾豪斯特、埃維·鬍剋斯和安妮·哈特利。特彆感謝卡爾·魏格斯和伊恩·亞曆山大，他們兩人提供寫作指導並和我們切磋關於模型的想法。
我們衷心感謝勤奮工作和富有情趣的編輯團隊，他們把這本書變成瞭現實。同時感謝組稿和策劃編輯德文郡·馬斯格雷夫和項目編輯卡羅爾·迪靈漢，他們兩人都在微軟齣版社工作。我們還要感謝項目經理和文稿編輯凱西·剋勞斯，排版人員吉恩·特雷納裏、校對海梅·奧德爾、美編珍妮·剋雷沃和索引人員揚·巴德納茲剋。
最後，要感謝我們的傢人一起忍受漫長的寫作過程。喬伊感謝她的丈夫托尼·漢密爾頓，在整個過程中幫助她保持幽默感；感謝她的女兒斯凱，她齣生在這本書的寫作期間，當我們完成寫作時她已經學會瞭一覺睡到天明。事實證明，寫一本書就像有一個孩子：許多月的孕育、準備、和喂養。安東尼感謝他的妻子格洛麗亞對他的支持，還有他的女兒梅森，她可以自己愉快地玩耍讓爸爸工作，但在電話會議時她變得非常安靜。最後，安東尼想感謝喬伊，如果沒有她全力以赴地推動這本書的寫作，此書永遠不會齣版。
勘誤和支持
我們已經盡瞭一切努力來確保本書和配套內容的準確性。這本書齣版之後所報告的任何錯誤都會列在我們的微軟齣版社網站
如果發現沒有列齣的錯誤，可以通過這個網址嚮我們報告。
如果需要額外的支持，發電子郵件到微軟齣版社的書籍支持。
請注意，微軟的軟件産品支持不是通過上麵地址提供的。
我們期待著你的意見
在微軟齣版社，你的滿意是我們的首要任務，你的反饋是我們最寶貴的財富。請通過下麵的網址告訴我們你對這本書的看法：
這項調查很簡短。我們會閱讀每一條意見和建議，提前謝謝你的輸入。
用戶評價
這次活動價格相當實惠，買到瞭想要的，很滿意
評分老公買的書不錯不錯，就是這本！
評分包裝完好，應當是正品
評分非常滿意的購物體驗，100分！
評分書的質量沒問題，是正版。內容還沒有看，對於項目的需求分析之前做過，但是沒有係統的理論支撐，看看這部作品充電用
評分買瞭需求分析，還差一本可視化建模，需求分析好書
評分包裝很好，送貨也很快，下雪天，辛苦快遞小哥！
評分非常好的一本書 可以讓項目經理更好的與客戶溝通開發需求
評分很不錯的書，對需求可視化闡述的很清晰。需要好好學習
相關圖書
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 book.tinynews.org All Rights Reserved. 静思书屋 版权所有