內容簡介
作為經典的軟件需求工程暢銷書，經由需求社區兩大知名領袖結對全面修訂和更新，覆蓋新的主題、實例和指南，全方位討論軟件項目所涉及的所有需求開發和管理活動，介紹當下的所有實踐。書中描述實用性強的、高效的、經過實際檢驗的端到端需求工程管理技術，通過豐富的實例來演示如何利用最佳實踐來減少訂單變更，提高客戶滿意度，減少開發成本。書中的用例、業務規則和商業工具全面修訂以體現現狀和未來的趨勢。
本書尤其適合具備一定軟件開發過程經驗的業務分析師、需求分析師、項目經理和其他軟件項目涉眾。
推薦序：軟件需求的百科全書
鄭人杰
當前，軟件承載著人類的專業知識和實踐經驗，進入了社會生活的各個領域，它已經深入到人們的工作和日常生活，呈現出無處不在的景象。而軟件產業己成為社會經濟發展的先導性和戰略性產業，成為信息產業和國民經濟新的增長點和重要支柱。與此同時，人們對軟件開發的產品也相應地提出了更高的要求，包括高質量、低成本和易用性，等等。
經過多年的實踐，我們開始認識到，確定軟件需求是軟件產品生命周期中最關鍵的一個環節。對于軟件這一不可見的邏輯實體來說，它的研發和傳統產業的產品相比有著很大差別。軟件需求決定著產品開發的目標，同時，軟件需求也是開發項目策劃的依據。然而，做好軟件需求工作并不容易。如果項目開始時需求工作做得不到位，開發項目的大廈就將建立在不牢固的基礎上。自從上世紀七十年代開始，本人在軟件工程領域的教學、科研和開發實踐中深深地理解到軟件需求工作的重要意義，也曾親身經歷過一些軟件開發項目由于在初期階段對需求工作不夠重視，就匆忙開展后續工作，致使項目最終受到嚴重后果的懲罰。例如，用戶對交付的產品不滿意，由于不適用不得不返工，延期再交付。然而，返工導致的額外成本投入不僅會使開發組織的高管人員失望，開發人員也因要付出更多的勞動而怨聲載道，最終導致開發組織的聲譽受到影響。實際上，這種人們不愿看到的事件不斷發生，也有著它的客觀原因。比如，軟件人員對項目提出的業務領域知識和相關技術并不熟悉，并且軟件人員通常并不只是面對一個應用領域，而是常常在開發一個產品，初歩熟悉一個領域之后，下一個開發任務又會面臨另一個全新的領域。此外，當今各應用領域的技術和市場情況大多處于迅速發展和演變之中。另一方面，主觀上經常出現的情況則是，軟件開發人員未能在項目的需求階段很好地和用戶配合，充分吸收和聽取用戶的意見，或是接受應用領域知識和技術的培訓，等等。
據本人了解，多年以來，市面上也有不少有關軟件需求領域的專業書籍。但本書第3版在我讀后，確實令我感到它的與眾不同，令我贊嘆。沒有想到，這本書竟然對軟件需求工作提供了如此全面、系統、詳盡和具體的闡述。過去很長時間以來，人們對軟件需求工作的理解是片面的，常常稱其為“需求分析”，以為需求工作只是對需求進行分析。其實，需求分析固然重要，但還有更為重要的。那就是需求獲取、需求說明、需求驗證和需求管理等。許多軟件項目的教訓表明，問題出現的根源恰恰在于需求獲取和需求驗證方面存在缺陷。
本書的另一特點是不僅講原則、方法，而且還對軟件項目的工作提供了具體的指導。比如，不同項目類型的需求（第Ⅲ部分）、需求工程的實施（第Ⅴ部分）以及在附錄部分給出的“需求實踐自評”、“問題問診指南”和“范例需求文檔”都具有很強的指導性、可操作性和可遵循性。無疑，在這些實踐性指導的部分中滲透著作者多年的工作經驗，甚至是親歷的教訓，非常值得廣大讀者認真地學習和吸取。
本人以為，在軟件需求方面本書如此全面詳盡，又是具有相當深度的指導性讀物，稱之為“軟件需求手冊”并不為過，甚至可以堪稱“軟件需求的百科全書”。
高校信息技術類專業的研究生完全可以用本書作為學習參考書。對于高校教師和科研機構的研究人員以及軟件開發機構的開發人員和管理人員都會將其作為必備的參考。
正是基于對本書的上述評價，本人愿意積極向廣大讀者推薦，并且充分相信本書必將在一定程度上促進他們的專業工作，最終成為他們的良師益友。
譯序：試問需求從何而來
譯者團隊代表李淳
這是一個全民創業、萬眾創新的時代。無論初創企業還是大型企業，無論互聯網巨頭還是傳統行業公司，都在思考這樣的問題：“我們的風口在哪里？”
隨著大數據、O2O、移動互聯、物聯網、開放平臺、云計算等技術術語越來越快速地進入公眾的視野，為商業創新帶來了巨大的機遇，更為新時代的軟件開發提出了機會和挑戰。我們看到，微博、微信、手機打車等一批新興商業模式如雨后春筍般滲入到人們的生活，為人們帶來極大的便利。然而，我們還看到，在這些成功的商業模式身后，流淌著無數“失敗者”的血淚。大量新企業、新項目勞神費力，投入大把時間，大把燒錢，上線后卻發現提供的產品和服務無人問津。
為什么？因為我們需要的并不是“等風來”，閉門坐在辦公室里等需求是行不通的。
以往，一切都源自老板的一個想法。然后大家便會在辦公室里討論，各種頭腦風暴，然后選擇其中認為不錯的方案來寫需求文檔，進行技術評估……（中間省略一千步）……直至最后交付。然后，就有了大家都知道的然后，簡直讓人痛心疾首！
在我看來，閉門造出來的需求通常都有這樣的共同特性。
1. 希望在上線的一剎那一舉形成可行的商業模式
通常，當一個成功的商業模式被大眾所接受時，人們看到的便是一個具有百萬千萬級規模的市場群體在進行消費。然而，人們看不到的是這些商業模式成功之前所遭受的屢屢失敗。無疑，這些成功的商業模式在給人們設立了標桿之后，也給人們帶來了不切實際的幻想：“一定要交付能夠一舉成功的產品或服務。”
2. 假設最初的想法是正確的
不切實際的預期伴隨著一種扭曲的力場，讓人誤將想法假設為事實。于是，幾乎沒有人認真思考最初的想法是否真的正確？
信息洪泛使得未來是愈發不可精確預知，試問每個想法能有多大的可能性是正確的呢？
3. 認為專家就在辦公室里
頭腦風暴，討論，最終民主集中為辦公室里的權威人士，可能是老板、上級甚至在辦公室里工作年頭最長的那個人。他們的決策依據往往是經驗。然而，當你滿懷希望想要創新的時候，就已經意味著沒有人會有經驗，所有意見決策都往往是靠猜的。
4. 上線之前，知道這個想法的客戶數量為0
為了確保我們“一舉成名”，讓那個不切實際的幻想變成現實，我們會對外嚴格保密，一出辦公室便絕口不提。因為我們害怕這個想法被別人搶走，更害怕客戶否定尚未達到我們心中“完美標準”的產品。然而，飛得越高摔得越痛，當上線時才開始尋找客戶，我們的幻想將宣告災難性的破滅。
幸運的是，近十年間，人們開始意識到這一問題，發現正確的需求變得愈發重要，各種新的創新方法不約而同地向人們傳達出下面這四大新的理念。
1. 成功的商業模式需要依靠對正確需求的持續積累
商業模式的成功需要一個從0到1的過程，而非一蹴而就。在這個過程中，失敗的可能性遠遠超過成功，所以為了更快地成功，就要快速而頻繁地失敗，更快速從失敗中學習，更快地積累點滴成功。拋棄不切實際的幻想，不要再苛求“完美”，主動擁抱失敗，讓商業模式自然生長出來！
2. 要獲得正確的需求，需要專家不斷否定你的猜想
擁抱失敗不等于魯莽地冒險，漫無目的地四處挖井，而是要使需求不再失敗。因此，最好辦法就是讓專家頻繁地對你的猜想證偽，用反饋和數據來指導接下來的行動，直到需求無限趨近于恰到好處。
3. 真正的專家是會購買你的產品或服務的客戶
需求之所以有存在的意義，歸根結底是因為有客戶愿意為此買單。因此，要想做到擁抱失敗，持續證偽，你要做的便是不斷與客戶溝通，找出這兩個問題的答案：1）為什么你的產品無法吸引他們的注意力？2）為什么他們不會為你所假設的需求買單？
真正的專家不是辦公室中的權威，客戶才是！主動和他們溝通，積極向他們提問，收集他們的數據，聆聽他們的心聲，讓他們告訴你什么是錯，什么是對。
4. 走出辦公室
既然客戶不在你的辦公室，世界那么大，何不出去看看呢？走出辦公室，找到客戶，發現真正的需求！
在此，我想對本書的作者Karl Wiegers和Joy Beatty致敬，他們一直在告訴我們一個道理：“正確的需求高于正確地需求。”我還要衷心感謝一同翻譯此書的譯者、編輯、設計等，感謝清華大學出版社為我們帶來如此經典而權威的著作。
再次，愿所有讀者能與我們一起共勉：“不要等風來，走出辦公室，去找風！”
前 言
幾十年過去了，許多軟件組織仍然難以了解、記錄和管理自己的產品需求。之所以如此多的信息技術項目無法完全成功，主要原因在于用戶輸入匱乏、需求不完整、需求變化以及對業務目標的誤解。一些軟件團隊疏于從客戶和其他來源收集需求。客戶往往沒有時間或耐心參與需求工作。在許多情況下，項目參與人員甚至無法就“需求的確切含義”達成共識。正如有作者所指出的：“工程師寧愿破譯Kingsmen 1963年的經典派對歌曲Louie Louie，也不愿意破譯客戶需求。”（PerterSon 2002）
十多年前，《軟件需求（第2版）》出版發行。十年對技術界而言真的是一段漫長的時間。許多事情在這期間已經發生了變化，但仍然有一些沒有變。過去十年中，軟件需求主要呈現出以下幾個趨勢。
* 業務分析被認為是一門專業的學科，專業認證和組織已經興起，比如“國際業務分析師協會”和“國際需求工程協會”。
* 基于數據庫的需求管理工具和需求開發輔助工具（如原型、建模和仿真）日趨成熟。
* 敏捷開發方法的使用越來越廣泛，處理敏捷項目需求的技術也在不斷演進。
* 可視化模型越來越廣泛地應用于闡述需求知識。
那么，哪些不曾發生變化呢？這一話題重要而且意義深遠，原因有兩個。其一，許多軟件工程和計算機科學的本科教材依然不夠重視需求工程（包括需求開發和需求管理）的重要性。其次，我們這些軟件領域從業人員骨子里一直癡迷于通過技術和過程方案來應對挑戰。其實有時并未意識到需求收集以及許多軟件和系統項目工作中，普遍面臨的最大挑戰是人與人如何互動。盡管許多工具都可以用于幫助地理分散的人們展開有效的協作，但沒有哪一種神奇的新技術能夠將此自動化。
我們相信，第2版中提到的實踐依然廣泛有效并適用于軟件項目的需求開發和管理。為了滿足具體情況的需要，業務分析師、產品經理或產品負責人需要發揮自己的創造力，對這些實踐進行精心調整和測量。在第3版中，新增一章介紹敏捷項目中的需求把控，其他幾章中也增加有新的內容，介紹如何在敏捷開發環境中使用和調整需求實踐。
在軟件開發中，溝通總是重于計算機操作，但在教學課程和項目工作中，卻往往注重計算機操作而忽視人際溝通。本書提供數十種工具用于加強溝通和幫助軟件從業人員、管理人員、市場營銷人員以及客戶使用更有效的需求工程方法。這里提及的技術是一套工具包，其中包含主流的“優秀實踐”，而非奇炫的新技術或某種聲稱能解決所有需求問題的復雜方法論。本書講了無數趣聞軼事和八卦故事，都是真人真事，講述著典型的需求相關經歷，你可能也曾有過相關的經歷。可以找到“真實故事”圖標，了解精選自各種項目經歷的真人真事。
自從本書1999年第1版問世以來，我們歷經項目無數，并且已授課好幾百場，為來自不同規模和類型的企業和政府機構的學員傳授軟件需求知識。我們發現，無論是本地團隊還是分布式團隊，無論使用傳統開發方法還是敏捷開發方法，這些實踐對任何項目幾乎都有幫助。這些技術不只適用于軟件項目，還適用于硬件和系統工程項目。與其他任何技術性實踐一樣，需要憑借良好的判斷力和經驗了解如何才能最有效地使用這些方法。要將這些實踐想象成工具，借助于這些工具，可以確保在項目中與合適的人進行有效的溝通。
本書的價值
在所有可以采取的軟件過程改進中，讓人們收獲最多的就是改進需求實踐。我們介紹的技術都是實踐證明有效的，能夠從以下幾個方面提供幫助。
* 從項目開始，寫高質量的需求，盡可能減少返工，盡可能提升生產率。
* 交付高質量的信息系統和商業產品，實現業務目標。
* 管理范圍蠕變和需求變更，既緊盯目標，又確保可控。
* 獲得更高客戶滿意度。
* 降低維護、改進和支持成本。
我們的目標是幫助改進所使用的需求流程，更好地收集和分析需求、編寫和確認需求規范以及在整個軟件開發周期中管理需求。我們所介紹的技術全部都是務實求真的。我們兩人已經多次使用這些技術，而且每次這樣做，總是能夠得到很好的結果。
本書的讀者
包括軟件在內的任何系統，只要需要定義或了解其需求，任何人都能從這本書中找到有用的信息。本書主要面向開發項目中擔任業務分析師或需求工程師的個人或群體，既包括全職專家，也包括臨時填補分析師角色的其他團隊成員。第二個讀者群體包括架構師、設計師、開發人員、測試人員以及必須了解與滿足用戶預期并參與創建和評審有效需求的其他技術團隊成員。負責制定（使產品獲得商業成功的）功能和屬性規范的市場人員和產品經理會發現這些實踐非常有用。項目經理能從本書中學到如何對項目需求工作進行規劃和跟蹤，如何處理需求變更。此外，干系人也屬于本書讀者群體，為了滿足業務、功能和質量需要，他們也會參與產品定義工作中。對于最終用戶、需要購買或承建軟件產品的客戶以及許多其他干系人，本書能夠幫助他們了解需求流程的重要性及其所扮演的角色。
內容概覽
本書共五個部分。第I部分從相關定義切入。如果是企業內部的技術人員，請與關鍵客戶分享第2章中的“客戶開發伙伴”小節。第3章概述幾十種需求開發和管理的優秀實踐以及一個需求開發流程整體框架。業務分析師的角色是第4章的主題，這一角色還有很多其他的名稱。
第II部分首先講項目的業務需求定義技術。接著專門介紹如何找到正確的客戶代表，如何從他們那里收集需求，如何記錄用戶需求、業務規則、功能性需求、數據需求以及非功能性需求。第12章介紹許多可視化模型，從不同角度闡述需求并對自然語言文本加以補充。第15章講述使用原型降低風險。隨后介紹需求排優先級、需求確認、需求重用的方法。最后介紹需求如何影響項目工作的其他方面。
第III部分屬于新增內容，各章為各種具體類型的項目推薦最有效的需求方法，具體類型包括：開發任何類型產品的敏捷項目、改進型和替換型項目、引入軟件包方案的項目、外包項目、業務過程自動化項目、業務分析項目以及嵌入式和其他實時系統。
需求管理的原則和實踐是第IV部分的主題，重點講述用于處理需求頻繁變更所需的技術。第29章介紹如何進行需求跟蹤，如何將獨立的需求與原始需求連接起來，如何將需求與下游的開發交付物連接起來。第V部分最后介紹用戶改進團隊需求開發和需求管理行為的商業工具。
本書的最后一部分是第V部分，這一部分幫助你從概念走向實踐。第31章幫助你向團隊開發流程中導入新的需求技術。第32章介紹項目中一些需求相關的常見風險。附錄A的自我評估能夠幫助你選擇改進時機成熟的領域。其他兩個附錄包括一個疑難解答和一些需求文檔樣例，以便你能夠看到全景。
案例學習
為了說明本書所介紹的方法，我們提供若干事例，這些事例來自我們做過的真實項目，尤其是化學品追蹤系統這個中型信息系統。別擔心，了解這個項目不需要懂化學。案例過程中的討論貫穿全書始終。無論組織要構建什么軟件，這些對話都能與你產生共鳴。
從原則到實踐
鼓起勇氣，克服障礙進行變革，并將新知識付諸于行動，是很困難的事情。為幫助進行需求改進，大多數章都在最后給出行動練習，幫助你立即開始學以致用。許多章都提供建議模板，包括各種需求文檔、評審檢查清單、需求排優先級電子表格、變更控制流程以及許多其他的流程資源。這些內容可以在本書配套內容網站下載，網址為http://aka.ms/SoftwareReq3E/files，可以通過它們馬上上手。從小的改進開始，從現在開始，宜早不宜遲。
有些人不愿意嘗試新的需求技術。使用本書來教一教自己的同行、客戶以及經理。提醒他們以往項目中所遇到的需求相關問題，并和他們討論嘗試使用新方法能帶來哪些潛在的收益。
要想使用更好的需求開發實踐，無需啟動一個新的開發項目。第21章討論了各種技術在改進型和替換型項目中的用法。增量實施需求實踐是一種低風險的過程改進方法，可以為你的下一個重要項目做足準備。
需求開發的目標是積累一系列足夠好的需求，使團隊能夠以可接受的風險水平設計和構建產品的下一個部分。需要對需求工作投入足夠的重視，才能降低返工、產品驗收不通過以及計劃“爆炸”所帶來的風險。本書提供的工具能夠讓正確的人落實到行動上，為正確的產品開發正確的需求。
勘誤&本書支持
我們已經力求確保本書及其輔助內容的準確性。在本書出版發行之后，書中的任何錯誤都將列在以下網址：http://aka.ms/SoftwareReq3E/errata。
如果發現未列出的錯誤，同樣可以在這里進行報告。
如果需要其他支持，請發送電子郵件至微軟出版社圖書支持郵箱：mspinput@microsoft.com。
請注意，上述地址不提供對微軟軟件產品的支持。
讓我們聆聽你的心聲
在微軟出版社，讀者的滿意是我們的頭等大事，讀者反饋是我們最有價值的資源。請告訴我們你對本書的想法：http://aka.ms/tellpress。
調查很短，我們會閱讀您的每一個評論和想法。先感謝您的貢獻！
保持聯系
讓我們保持順利的溝通！我們的推特地址是http://twitter.com/MicrosoftPress。
致 謝
寫這樣一本書離不開整個團隊的努力，遠遠不只是我們兩位作者的貢獻。很多人花時間對書稿進行評審，提出無數改進建議，我們對此深表感謝。我們特別感謝Jim Brosseau、Joan Davis、Gary K. Evans、Joyce Grapes、Tina Heidenreich、Kelly Morrison Smith以及Joyce Statz博士為我們提出寶貴意見。其他評審人員還包括Kevin Brennan、Steven Davis、Anne Hartley、Emily Iem、Matt Leach、Jeannine McConnell、Yaaqub Mohamed以及John Parker。我們還要感謝Tanya Charbury、Mike Cohn、Alex Dean博士、Ellen Gottesdiener、Shane Hastie、James Hulgan、Phil Koopman博士、Mark Kulak、Shirley Sartin、Rob Siciliano以及Betsy Stockdale，他們從各自的專業角度對具體章節提供了非常詳盡的意見。我們特別感謝Roxanne Miller和Stephen Withall，感謝他們深刻的見解和無私的參與。
我們與許多人就書中的主題進行了探討，從他們的個人經驗和他們發給我們的資源材料中，我們學到很多東西。我們對Jim Brosseau、Nanette Brown、Nigel Budd、Katherine Busey、Tanya Charbury、Jennifer Doyle、Gary Evans、Scott Francis、Sarah Gates、David Gelperin博士、Mark Kerin、Norm Kerth、Scott Meyers博士、John Parker、Kathy Reynolds、Bill Trosky、Ricardo Valerdi博士以及Ian Watson博士的貢獻表示贊賞。我們還要感謝讓我們在“真實故事”中分享其趣聞軼事的人。
Seilevel公司的許多工作人員也為本書提供了大力支持。他們對具體章節進行評審、參與快速意見和體驗調查、分享他們寫的博客、編輯定稿、繪圖并幫助我們解答各類業務問題。在此我們要感謝Ajay Badri、Jason Benfield、Anthony Chen、Kell Condon、Amber Davis、Jeremy Gorr、Joyce Grapes、John Jertson、Melanie Norrell、David Reinhardt、Betsy Stockdale以及Christine Wollmuth。他們的工作為我們減輕了壓力。我們特別贊賞Candase Hokanson對編輯工作的投入。
還要感謝微軟出版社的許多工作人員，包括組稿編輯Devon Musgrave和項目編輯Carol Dillingham，S4Carlisle Publishing Services的項目編輯Christian Holdener、編審人員Kathy Krasuse。感謝校對人員Nicole Schlutt、索引制作人員Maureen Johnson、排版人員Sambasivam Sangaran以及產品制作人員Balaganesan M.、Srinivasan R.與Ganeshbabu G.。作者Karl對Devon Musgrave和Ben Ryan長期以來建立的合作和友誼給予高度評價。在我們這么多年的需求培訓班中，有上千名學員提供反饋和問題，激勵著我們深入思考需求問題，我們從中得到了莫大的幫助。我們的咨詢經歷和讀者提出的引人深思的問題，使我們不斷了解到從業人員在日常工作中遇到的困難并幫助我們思考。請與我們分享你的經歷，發送電子郵件到 karl@processimpact.com 或者 joy.beatty@seilevel.com。
一如既往，Karl要感謝他的妻子Chris Zambito。一如既往，整個過程中她都很有耐心而且脾氣極好。Karl還要感謝Joy鼓勵他參與這個項目中以及Joy對這個項目聽做的了不起的貢獻。與Joy一起工作真的很開心，她還使這本書增添了很多價值。很高興能夠和她一起不斷討論、一起艱難決定并在交稿前一起對書稿進行精雕細琢。
Joy特別感謝他的丈夫Tony Hamilton這么快就再次支持她的寫作夢想；還有她的女兒Skye，讓她每天輕松保持工作與生活的平衡；還有Sean和Estelle，讓家庭時光充滿歡樂。Joy還想專門感謝Seilevel的全體員工，感謝他們齊心協力推動軟件需求領域向前發展。她特別感謝兩位同事兼朋友：Anthony Chen對她寫這本書提供了至關重要的支持；Rob Sparks不斷鼓勵Joy為此付出努力。最后，Joy重點感謝Karl允許她和他一起合著，每天都教她一些新知識，百分之百的愉快合作！
目 錄第Ⅰ部分 軟件需求的3W（什么、為什么和誰）第1章 軟件需求的本質 3軟件需求的定義 5關于“需求”的一些解釋 5字典中的“需求” 6需求的層次和種類 6處理三種層次的需求 11產品需求與項目需求 13需求開發和管理 14需求開發 15需求管理 16每個項目都有需求 17人對了，得出的需求卻很糟糕 18用戶參與度不夠 18規劃不當 19用戶需求蔓延 19需求模棱兩可 19鍍金 20忽視干系人 20高質量需求過程帶來的好處 20第2章 從客戶角度審視需求 22期望落差 23誰是客戶 24客戶-開發的合作關系 26軟件客戶的需求權利法案 28軟件客戶的需求責任法案 30建立尊重需求的企業文化 32識別決策者 33對需求達成一致 34需求基線 35達不成共識怎么辦 36對敏捷項目的需求達成共識 36第3章 需求工程優秀實踐 38需求開發過程框架 40優秀實踐：需求獲取活動 42優秀實踐：需求分析 44優秀實踐：需求規范說明 45優秀實踐：需求驗證 46優秀實踐：需求管理 47優秀實踐：知識 49優秀實踐：項目管理 50開始新的實踐 51第4章 業務分析師 53業務分析師的角色 54業務分析師的職責 55基本的分析技巧 56基本的分析知識 59業務分析師的培養 60前用戶 60前開發人員或測試人員 61前（或兼職）項目經理 61主題專家 62菜鳥 62敏捷項目中的分析師角色 63打造一個協作型的團隊 64第Ⅱ部分 需 求 開 發第5章 建立業務需求 67定義業務需求 67確定預期業務收益 68產品愿景和項目范圍 68業務需求沖突 69愿景和范圍文檔 711. 業務需求 722. 范圍和限制 773. 業務背景 79范圍表示技巧 80關聯圖 81生態系統圖 82特性樹 83事件列表 84聚焦于范圍 85使用業務目標來做范圍決策 85評估范圍變更的影響 86敏捷項目的愿景與范圍 86使用業務目標來確定完成 87第6章 傾聽用戶的心聲 89用戶類別 90用戶分類 90識別用戶類別 92用戶畫像 94與用戶代表取得聯系 95產品代言人 96外部產品代言人 97產品代言人的期望 98多個產品代言人 99推廣產品代言人理念 100產品代言人要避免的陷阱 101敏捷項目的用戶表達方式 102處理需求沖突 103第7章 需求獲取 105需求獲取技巧 106訪談 107工作坊 108焦點小組 110觀察 111問卷調查 112系統接口分析 113用戶界面分析 113文檔分析 114制定項目需求獲取計劃 114準備需求獲取 116執行獲取活動 117需求獲取后的跟進 119整理和分享會議筆記 119記錄提出的問題 120對客戶的輸入進行分類 120如何知道已經完成 123需求獲取的注意事項 123假設的需求和隱晦的需求 124找出遺漏的需求 125第8章 理解用戶需求 127用例和用戶故事 128用例方法 131用例和使用場景 133識別用例 139探索用例 141驗證用例 142用例和功能需求 143用例要避免的陷阱 145“以使用為中心”的需求有何好處 145第9章 照章辦事 147業務規則分類法 148事實 149約束 150觸發規則 151推理 152運算 152原子業務規則 153記錄業務規則 154發現業務規則 156業務規則與需求 157把一切串起來 158第10章 記錄需求 160軟件需求規范說明 162標識需求 164處理不完整性 166用戶界面和SRS 167軟件需求規范說明模板 1681. 引言 1692. 整體描述 1704. 數據需求 1725. 外部接口需求 1736. 質量屬性 1747. 國際化和本地化需求 1758. ?[?其他需求?] 175附錄A：詞匯表 175附錄B：分析模型 176敏捷項目的需求規范說明 176第11章 寫出優秀的需求 178優秀需求的特點 178需求陳述的特點 179需求集合的特點 180需求編寫指南 181系統或用戶的角度 182寫作風格 183細化程度 185表述技巧 187避免歧義 188避免不完整性 191改進前后的需求示例 192第12章 一圖勝千言 196需求建模 197從客戶需求到分析模型 198選擇正確的表達方式 199數據流圖 201泳道圖 204狀態轉換圖和狀態表 206對話圖 209判定表和判定樹 212事件-響應表 213小議UML圖 216敏捷項目中的需求建模 216最后提示 217第13章 具體指定數據需求 218對數據關系進行建模 218數據字典 221數據分析 224報表的規范說明 225獲取報表需求 226對報表需求規范的幾點思考 227報表規范說明模板 228儀表盤報表 230第14章 功能需求以外 233軟件質量屬性 234探究質量屬性 235定義質量需求 239外部質量屬性 239內部質量屬性 251用Planguage指定質量需求 256質量屬性的平衡 258質量屬性需求的實現 259約束條件 260如何處理敏捷項目的質量屬性 261第15章 通過原型來減少風險 264原型的定義及其動機 265實物模型和概念證明 266拋棄型原型和演化性原型 267紙上原型和電子原型 270原型的使用 271原型的評估 274原型風險 275原型發布的壓力 275受細節所累 276不現實的性能預期 277對原型投入過多 277原型成功的因素 277第16章 要事優先：設定需求優先級 279為什么要排優先級 280優先級排序實踐 281人與優先級之間的博弈 282確定優先級的技術 283入選與落選 283兩兩比較并排序 284三層分級法 284MoSCoW 286100美元 287根據價值、成本和風險排優先級 288第17章 確認需求 293確認與驗證 295需求評審 295審查流程 297缺陷檢查清單 301需求評審提示 302需求評審面臨的挑戰 303需求原型 304需求測試 305使用驗收條件確認需求 309驗收條件 309驗收測試 310第18章 需求的重用 312為什么要重用需求 313需求重用的維度 313重用范圍 314修改范圍 314重用手段 315哪些需求信息類型可以重用 316常見重用場景 317軟件產品線 317再設計與替換系統 318其他可能的重用機會 318需求模式 319促進重用的工具 319使需求可重用 320需求重用的障礙與成功要素 322重用的障礙 322重用的成功要素 323第19章 需求開發之外 325估算需求工作量 326從需求到項目計劃 329根據需求估算項目規模和工作量 329需求和排期 331從需求到設計和代碼 332架構與分配 332軟件設計 333用戶界面設計 334從需求到測試 336從需求到成功 337第Ⅲ部分 具體項目類別的需求第20章 敏捷項目 341瀑布的局限性 341敏捷開發方法 343敏捷方法中需求的基本面 343客戶參與 343文檔的細節 344Backlog和排優先級 344確定時機 344史詩、用戶故事和特性 345期待變更 346根據敏捷項目調整需求實踐 347敏捷轉型，怎么辦 347第21章 改進型和替換型項目 349預期的挑戰 350基于現有系統的需求技術 350按業務目標來排優先級 351當心差異 352維持性能水平 353找不到原有需求怎么辦 353應當指定哪些需求 354如何發現現有系統的需求 355鼓勵使用新系統 356是否可以迭代 357第22章 軟件包方案項目 359進行軟件包方案選型的需求 360開發用戶需求 360考慮業務規則 361識別數據需要 361定義質量要求 361評估方案 362實施軟件包方案的需求 364配置需求 364集成需求 364擴展需求 365數據需求 365業務過程變更 365軟件包方案的常見挑戰 366第23章 外包項目 367需求的詳細程度恰當 368需求方-供應方的互動 369變更管理 371驗收條件 371第24章 業務過程自動化項目 372業務過程建模 372基于當前過程推導出需求 373首先設計未來的過程 375業務績效指標建模 375業務過程自動化項目的良好實踐 376第25章 業務分析項目 378業務分析項目概述 378業務分析項目的需求開發 380對決策的使用排優先級 381定義如何使用信息 381指定數據需求 383定義轉換數據的分析 385分析的演進本質 386第26章 嵌入式和其他實時系統項目 388系統需求、架構和分配 388實時系統建模 390環境圖 390狀態轉換圖 390事件響應表 391架構圖 392原型 394接口 394有時限的需求 395嵌入式系統的質量屬性 396嵌入式系統的挑戰 400第Ⅳ部分 需 求 管 理第27章 需求管理實踐 403需求管理流程 403需求基線 405需求版本控制 405需求屬性 407跟蹤需求狀態 408解決需求問題 410度量需求投入 411敏捷項目的需求管理 412為什么要管理需求 414第28章 需求變更 415為什么要管理變更 415管理范圍蔓延 416變更控制政策 417變更控制流程的基本概念 418變更控制流程說明 4181. 目的和范圍 4192. 角色和職責 4193. 變更請求狀態 4204. 準入標準 4205. 任務 4216. 退出標準 4217. 變更控制狀態報告 421附錄：為每個請求保存的屬性 422變更控制委員會 422CCB的組成 423CCB章程 423重新協商承諾 424變更控制工具 424度量變更活動 425變更影響分析 426影響分析過程 426影響分析模板 429敏捷項目的變更管理 430第29章 需求鏈中的鏈接 432需求跟蹤 432需求跟蹤的動機 434需求跟蹤矩陣 435需求跟蹤工具 438需求跟蹤過程 439需求跟蹤可行嗎？有沒有必要 440第30章 需求工程工具 442需求開發工具 443獲取工具 444原型工具 444建模工具 444需求管理工具 445使用RM工具的好處 445RM工具的能力 446挑選和實現需求工具 448選擇工具 448建立工具和流程 449引導用戶采用 450第Ⅴ部分 需求工程的實施第31章 改進需求過程 455需求如何關聯到其他項目過程 456需求與不同的干系人群體 457獲得對變革的承諾 458軟件過程改進基礎 460根因分析法 461過程改進循環 463評估當前實踐 463規劃改進行動 463過程的創建、試點和推行 465評估結果 465需求工程的過程資產
