産品特色

編輯推薦

聚焦於軟件需求中的目標、人、係統和數據；重點介紹四大類需求可視化模型的實踐運用

內容簡介

　　需求文檔的模糊性和歧義性是導緻很多軟件項目最終無法滿足用戶需求的主要原因。針對這一現狀，本書主要側重於以視覺化方式來錶達軟件需求，介紹瞭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模型想象成軟件項目的模型模闆工具箱。通常 軟件需求與可視化模型/微軟技術叢書 下載 mobi epub pdf txt 電子書

這本書各種模型的畫法不多，比較虛。可作參考書。

非常滿意的購物體驗，100分！

好好好好好好好好好好

內容不錯，一些有用的工具。體係性不錯

該書可視為《軟件需求》一書的姐妹篇，描述用可視化模型來完成需求分析，兩書配閤使用可能會更好！需求分析是一項工程，其重要性不亞於軟件開發，甚至更重要，不知道中國的絕大部分軟件公司什麼時候纔能懂這個道理！

不錯

看著呢！！！！！！！！！！！！！！！！！！！！！！！！！！

很不錯的書,會仔細看

軟件需求與可視化模型/微軟技術叢書