第1部分 原理、模型與誤區
第1章 需求實踐現狀分析 2
在信息化高速發展的今天，構建與時俱進的信息化係統已成為所有政府、企事業單位的重點課題之一。然而在軟件項目實施過程中，進度超期、經費超預算、變更頻繁的現象層齣不窮，甚至有許多項目根本無法達到預期的目標，更談不上為業主創造真正的效益。歸根結底，軟件需求實踐這一共同的軟肋是問題的根源。
1.1 軟件項目失敗的根源 2
1.1.1 CHAOS Report 1994 2
1.1.2 CHAOS Report後續版本 3
1.1.3 需求相關敗因簡要分析 4
1.1.4 一幅漫畫帶來的思考 8
1.2 透過錶象，分析本質 13
1.2.1 需求變更頻繁 13
1.2.2 上綫阻力大 14
1.2.3 運行效果差 15
1.2.4 完全崩潰 16
1.3 方法論與需求工作 17
1.3.1 計算模式 17
1.3.2 軟件工程方法論 18
1.3.3 開發思想 19
1.4 小結 20
第2章 不同軟件項目的需求視圖 21
隨著信息化應用的逐漸深入，軟件項目在企業、政府等各類組織中所擔負的角色也越來越多，應用層麵也在逐漸地深入，同時也意味著不同的軟件項目具有不同的特點，這也就對需求工作産生瞭諸多影響。 在本章中，我們就將針對信息係統、嵌入式係統、軟件産品等不同角度來說明如何進行相應的需求工作，為需求分析師提供一個切實有效的視圖。
2.1 信息係統的需求視圖 21
2.1.1 信息係統的本質與分類 21
2.1.2 聯機事務處理係統——流程電子化 23
2.1.3 管理信息係統——數據信息化 26
2.1.4 其他信息係統 30
2.1.5 信息係統的多維視圖 32
2.2 嵌入式係統的需求視圖 34
2.2.1 麵嚮直接用戶的嵌入式係統 35
2.2.2 麵嚮特定設備的嵌入式係統 36
2.3 軟件産品的需求視圖 37
2.4 小結 41
第3章 軟件需求與需求工程 42
筆者在做需求分析師的培訓時，經常會問學員這樣的一個問題：什麼是軟件需求？這個看似簡單的問題卻並不好迴答，也許很多人會簡單地認為軟件需求就是用戶需要實現的功能加上一些非功能方麵的要求。但這樣的理解卻並不完整，如果對用戶所處的業務場景沒有建立正確認識，經常會給工作帶來麻煩。因此本章將對一些與需求、需求工程相關的關鍵概念進行闡釋。
3.1 什麼是軟件需求 42
3.1.1 需求的三個層次 42
3.1.2 需求的三種類型 44
3.1.3 優秀需求的標準 47
3.2 需求工程解析 51
3.2.1 需求工程的範疇 52
3.2.2 需求開發工作要點 52
3.2.3 需求管理工作要點 57
3.2.4 需求分析人員的技能組成 60
3.2.5 SERU模型概述 61
3.3 小結 62
第2部分 需求開發
第4章 需求定義最佳實踐 64
需求定義活動準確來說是不屬於需求工程範疇的，它實際上是立項管理需要做的工作。但需求定義階段的産物對於需求捕獲、分析與建模活動都有著直接的影響，如果這個階段的工作做得不理想，就會齣現“上梁不正下梁歪”的結果。因此本書還是將這個活動納入進來，並將給大傢提供一個能夠與後續活動結閤緊密的方法。
4.1 需求定義任務概述 64
4.1.1 需求定義的時機 64
4.1.2 需求定義的理念與策略 65
4.2 問題分析的五步法 67
4.2.1 在問題定義上達成共識 67
4.2.2 分析問題背後的問題 73
4.2.3 確定相關人員和用戶 77
4.2.4 定義解決方案的界限 78
4.2.5 確定加在解決方案上的約束 81
4.2.6 小結 81
4.3 需求定義的産物與要素 82
4.3.1 需求定義的産物 82
4.3.2 需求定義的要素 83
4.4 定義需求範圍 88
4.4.1 案例說明 88
4.4.2 劃分主題域 89
4.4.3 確定主題域範圍 98
4.4.4 標識業務事件與報錶 102
4.4.5 生成需求大綱 105
4.5 小結 108
第5章 需求捕獲最佳實踐 109
需求捕獲是需求開發中的第一個活動，可以說任何一個需求團隊對它都不陌生，但如何提高需求捕獲的有效性卻一直以來是睏擾大傢的問題。需求捕獲的要點在於計劃性和科學性，計劃性體現在對捕獲對象、問題、時間的計劃，科學性則錶現在如何有效地選擇閤適的捕獲方法。本章的目的就在於幫助大傢更好地達到這兩個目標，從而提高需求捕獲活動的質量。
5.1 需求捕獲的策略 109
5.1.1 需求捕獲應該是主動的 109
5.1.2 需求捕獲應該是聚焦的 110
5.1.3 破解需求的冰山模型 111
5.1.4 破解阻礙需求捕獲的心理現象 113
5.1.5 不要忽視對變更可能的捕獲 117
5.1.6 需求協商 118
5.2 需求捕獲的主要方法 126
5.2.1 用戶訪談 126
5.2.2 用戶調查 138
5.2.3 文檔考古 143
5.2.4 情節串聯闆 145
5.2.5 現場觀摩 147
5.2.6 聯閤開發 149
5.3 需求捕獲的記錄工具 152
5.3.1 工具的選擇與定義 152
5.3.2 任務卡片 152
5.3.3 場景說明 154
5.3.4 其他工具 155
5.4 小結 156
第6章 需求分析與建模最佳實踐 157
需求分析是需求工程中最為核心的工作，而需求建模則是需求分析的主要手段。但由於分析這個詞比較抽象，很多時候讓人感到無從入手，甚至導緻被輕易地滑過瞭，直接將需求捕獲的結果整理到軟件需求規格說明書中。而需求建模也有很多工具，到底怎麼有效地應用到需求分析過程中也是令人感到難以掌握的東西。因此本章的目標就是為讀者勾勒齣需求分析的階段與任務，指齣如何選擇適閤的建模工具，以及在什麼時機、如何應用這些建模工具。
6.1 需求分析與建模的要點與誤區分析 157
6.1.1 需求分析到底做什麼 157
6.1.2 建模的目標與要點 160
6.1.3 選擇建模工具的要點 162
6.2 周期一：理清框架與脈絡 165
6.2.1 業務流程分析 166
6.2.2 業務實體分析 192
6.2.3 角色與使用場景分析 218
6.2.4 周期一的産物 236
6.3 周期二：確定需求細節 252
6.3.1 確定行為需求的細節 253
6.3.2 確定結構需求的細節 274
6.3.3 周期二的産物 283
6.4 其他需求分析 296
6.4.1 接口需求 296
6.4.2 非功能需求的追蹤 299
6.4.3 設計約束 302
6.5 小結 306
第7章 需求描述最佳實踐 307
需求描述就是將需求捕獲、分析的結果進行文檔化的過程。在軟件開發時，將分析的結果文檔化是不可或缺的任務，也稱為編寫規約活動；而在某個項目中，可能還會由用戶代錶或需求捕獲人員對捕獲的內容進行整理，形成用戶需求說明書。具體要乾什麼，想必大傢並不陌生，而且在前一章中也看到瞭一些實例的片段。因此本章將重點從需求描述的風格與格式、寫作策略與技巧兩個方麵做些強調和補充。
7.1 需求描述的風格與格式 307
7.1.1 常見的描述風格與選用標準 307
7.1.2 典型軟件需求規格說明書模闆解析 308
7.1.3 定義模闆的技巧 323
7.1.4 用戶需求說明與軟件需求規格說明 331
7.2 寫作策略與技巧 333
7.2.1 文字錶達的先天不足 333
7.2.2 需求描述的兩大原則 335
7.2.3 不要忽視陳述需求理由的重要性 338
7.2.4 注意措辭 339
7.3 小結 340
第8章 需求驗證最佳實踐 342
需求驗證是需求開發的最後一個環節，它是一個質量關。也就是說，其目標是發現盡可能多的錯誤，減少因為需求的錯誤而帶來的工作量浪費。而需求驗證的主要手段就是Review（復查，也常譯為評審）。但是許多需求團隊都覺得需求驗證比較容易變得“務虛”，收效很少，本章的目標就是幫助大傢緩解這個問題。
8.1 需求驗證的主要手段 342
8.1.1 不同正式化程度的評審 342
8.1.2 審查過程概述 344
8.2 需求驗證的主要誤區與解決方案 346
8.2.1 需求驗證的5大要點 347
8.2.2 需求驗證常見的5大問題 350
8.3 小結 353
第3部分 需求管理
第9章 需求基綫操作實務 356
需求基綫是需求管理活動中最為基礎的一個，通常也是在項目中首先應該引入的管理活動。但許多相關書籍中對需求基綫的介紹相對比較理論化，很少給齣具體的操作方法，往往使得許多軟件開發團隊無從入手。為瞭幫助大傢更好地引入需求基綫，本章的重點將是結閤具體的實例來說明需求基綫的劃分方法。
9.1 需求基綫的理念與策略 356
9.1.1 基綫思想的起源 356
9.1.2 基綫的策略 358
9.2 基綫劃定的基礎：優先級評價 359
9.2.1 組織需求項 359
9.2.2 業務優先級評價 360
9.2.3 根據技術依賴性和項目風險調整優先級 364
9.3 基綫劃定的要素：工作量估算 364
9.3.1 估算的意義與要點 364
9.3.2 定義階段的估算示例 366
9.3.3 分析一階段的估算示例 369
9.4 基綫劃定與管理 370
9.4.1 劃定基綫 370
9.4.2 管理基綫 371
9.5 小結 372
第10章 變更管理操作實務 373
需求變更頻繁恐怕是睏擾無數軟件開發團隊的惡魔之首，而且在美國權威的第三方機構Standish Group的CHAOS報告中，也將其列為睏擾軟件開發團隊、導緻項目失敗的5大原因之一，其中原因實際上也充分暴露瞭整個産業的不成熟。需求變更在CHAOS報告中是排名第四的問題，而在中國軟件開發團隊中卻是排名第一的問題，這裏麵就意味著存在距離，本章的目的就是希望幫助大傢找到其中的差距。
10.1 變更管理的理念 373
10.2 變更管理要點一：統一渠道 374
10.2.1 CCB背後的道理 374
10.2.2 變更處理過程 377
10.3 變更管理要點二：統一平颱 381
10.3.1 變更管理平颱的選擇 381
10.3.2 變更管理平颱的應用要點 382
10.4 小結 383
第11章 需求跟蹤操作實務 384
需求跟蹤是一個高階的管理活動，它的目標是為瞭更好地管理需求的狀態、更好地分析需求變更産生的影響。雖然執行需求跟蹤會帶來不錯的效益，但其所需付齣的工作量也是巨大的。本章我們就對跟蹤的一些要點做一簡要的說明。
11.1 需求跟蹤的基本概念 384
11.1.1 用戶需求到軟件需求的跟蹤 385
11.1.2 軟件需求到軟件需求的跟蹤 385
11.1.3 軟件需求到下遊工作産品的跟蹤 385
11.2 需求跟蹤的操作方法 386
11.2.1 錶格法 386
11.2.2 鏈錶法 387
11.3 小結 389
第4部分 總結
第12章 SERU過程框架總結 392
經常說一個觀點：“我們並不缺乏軟件工程、需求工程的理論、技術，缺乏的是將這些理論與技術有效地應用到實踐中去的具體方法”。而貫穿全書的SERU過程框架（也稱為SERU模型）正是筆者基於多年不同領域、不同規模的軟件項目實踐的基礎上，通過對許多重型方法的剪裁而得到的一個清晰、實用的軟件需求過程框架。
12.1 SERU過程框架要點概述 392
12.1.1 SERU過程框架的理論基礎 392
12.1.2 SERU過程框架全景圖 393
12.1.3 SERU過程框架導入建議 396
12.2 需求實作要點概述 397
12.3 結語 399
參考文獻 400
SERU誡語目錄
第1章 需求實踐現狀分析 2
SERU誡語1-1：需求規格說明書應該采用業務導嚮的樹型層次結構來組織。 6
SERU誡語1-2：對於需求分析員而言，真正的專業主義是基於業務利益（解決問題、創造機會、提高管控力等）的溝通。 6
SERU誡語1-3：緩解溝通失真最有效的方法是及時復述。 10
SERU誡語1-4：需求分析的本質在於業務分析，而非技術分析。 12
SERU誡語1-5：業務場景是需求之魂。 12
SERU誡語1-6：需求分析人員對於技術方法論的評價重在適用性。 17
SERU誡語1-7：對預設計的需求是評判敏捷方法論是否適用的關鍵。 18
第2章 不同軟件項目的需求視圖 21
SERU誡語2-1：流程分析（業務事件）是OLTP係統的關鍵綫索和主要視圖。 24
SERU誡語2-2：報錶分析是MIS係統的關鍵綫索和主要視圖。 27
SERU誡語2-3：決策場景是DSS係統的關鍵綫索和主要視圖。 31
SERU誡語2-4：工作場景是專傢係統的關鍵綫索和主要視圖。 31
SERU誡語2-5：並行工作流是OA係統的關鍵綫索和主要視圖。 32
SERU誡語2-6：高層管理人員的關注點往往在問題和機會。 34
SERU誡語2-7：對於麵嚮用戶的嵌入式係統，行為分析是要點。 36
SERU誡語2-8：麵嚮特定設備的嵌入式係統，外部接口和事件分析是要點。 37
SERU誡語2-9：信息係統類軟件産品的需求重點在於針對不同目標客戶群體的不同商業模式分離變化點；經常需要減齣通用性，再通過插接解決擴展性。 40
SERU誡語2-10：基於使用場景的睏難點分析是工具軟件的需求要點。 41
第3章 軟件需求與需求工程 42
SERU誡語3-1：業務需求是需求定義的産物，用戶需求是需求捕獲的産物，軟件需求是需求分析與建模的産物。 44
SERU誡語3-2：功能需求的要點在於如何組織。 45
SERU誡語3-3：非功能需求的要點在於保證信息的有效傳遞和注意其局部性。 45
SERU誡語3-4：設計約束包括非技術因素的技術選型、預期的軟硬件環境和預期的使用環境三大類型。 47
SERU誡語3-5：業務導嚮的層次結構是保障完整性的關鍵。 47
SERU誡語3-6：需求有時會戴上“高優先級”的麵具，實際上就是擔心你不去實現它。49
SERU誡語3-7：滿意/不滿意度模型是需求必要性評價的有效手段。 50
SERU誡語3-8：在需求捕獲活動中，化被動為主動是關鍵。 53
SERU誡語3-9：需求分析就是嚮下分解+嚮上提煉，外加一些規格化。 54
SERU誡語3-10：需求分析是目標，需求建模是手段。 55
SERU誡語3-11：在編寫需求規格說明書時，應確保一類信息隻在一處描述。 57
SERU誡語3-12：劃分齣大小閤適、粒度均勻的需求項是需求管理的前提。 58
SERU誡語3-13：需求優先級與工作量估算是基綫管理的關鍵。 59
SERU誡語3-14：SERU模型是需求分析的工作指南。 61
第4章 需求定義最佳實踐 64
SERU誡語4-1：清晰的項目目標和範圍定義，能夠引導需求工作順利進行。 65
SERU誡語4-2：對混沌不清的目標，可以通過內部尋根或外部溯源來破解。 65
SERU誡語4-3：對問題進行瞭正確的定義，意味著成功解決瞭一半。而在問題定義時應該善於使用轉換和本源兩個技巧。 68
SERU誡語4-4：需求定義階段要善於將未知解問題轉換成已知解問題。 69
SERU誡語4-5：在確定某問題的解決方案時，一定要思考是否會引發新問題。 70
SERU誡語4-6：直接修改錯誤，不要用其他方案來彌補錯誤。 71
SERU誡語4-7：魚骨圖為解決問題找到瞭靶子，帕纍托圖則標上瞭環數。 77
SERU誡語4-8：範圍是涉及的事、物，邊界是人與係統的職責邊界。 80
SERU誡語4-9：用戶永遠會希望花同樣的錢，獲得盡可能多的功能。 80
SERU誡語4-10：需求階段描述的是用戶的能力特點，旨在提高可用性。 86
SERU誡語4-11：你可以不做一件事，但一定不能不知道為什麼需要做這件事。 86
SERU誡語4-12：在分解係統時，應該按業務的脈絡來劃分成不同的主題域。 90
SERU誡語4-13：各個主題域之間的服務接口是需求變更的防火牆。 91
SERU誡語4-14：確保能做的事和知道的事相匹配是職責驅動設計的要點。 94
SERU誡語4-15：目標決定範圍。 97
SERU誡語4-16：繪製上下文關係圖，先考慮Customer再考慮Worker是要點。 99
SERU誡語4-17：業務事件應該是主動觸發的，並且將會産生一係列後續行為。 103
SERU誡語4-18：業務事件是直接作用於係統的，也就是將觸發係統行為。 104
第5章 需求捕獲最佳實踐 109
SERU誡語5-1：需求捕獲是撒網打魚，不是休閑釣魚。 109
SERU誡語5-2：善於聚焦訪談話題是需求捕獲人員成功的關鍵。 111
SERU誡語5-3：嘗試理解業務場景是閤格需求分析人員的良好習慣。 112
SERU誡語5-4：善於利用技術為用戶創造全新體驗是優秀需求人員的特質。 113
SERU誡語5-5：通過比較用戶代錶的錶述來識彆言過其實，利用差異展現、瓶頸分析法來緩解影響。 114
SERU誡語5-6：針對越俎代庖心理現象最有效的方法是識彆正確的被訪談者。 114
SERU誡語5-7：離開辦公室、對訪談進行計劃是避免非正事現象的主要手段。 116
SERU誡語5-8：化敵為友是緩解抗拒心態的主要方嚮。 116
SERU誡語5-9：傾聽對方的抱怨是化敵為友的有效手段之一。 116
SERU誡語5-10：突破推卸責任心理的簡單手段是讓被訪談者介紹工作場景。 117
SERU誡語5-11：需求捕獲時不要忽視對變更可能的瞭解。 118
SERU誡語5-12：在需求捕獲時要善於使用“？”之箭，找到真正的需求。 121
SERU誡語5-13：“撥開立場，尋找利益訴求”是需求協商的要點。 123
SERU誡語5-14：不要孤立地看待需求項，應該將所有需求視為一個整體。 123
SERU誡語5-15：“環境”將改變結果，切換不同的視角會得到不同的認識。 125
SERU誡語5-16：善於打比方是提高跨專業溝通效果的好方法。 126
SERU誡語5-17：占用時間長和信息的片麵性是用戶訪談的兩大敵人。 127
SERU誡語5-18：訪談的綫索是因“人”（用戶類型）而異的。 127
SERU誡語5-19：盡量將訪談問題事先發給被訪談者，讓他打一場有準備之戰。 129
SERU誡語5-20：在需求捕獲時彆忘瞭“一圖抵韆言”這句經典提示。 133
SERU誡語5-21：用戶訪談是一個有計劃的、科學的過程。 136
SERU誡語5-22：用戶調查能夠有效剋服用戶訪談中存在的片麵性。 138
SERU誡語5-23：在需求捕獲過程中，先訪談再調查是更閤理的方式。 138
SERU誡語5-24：大樣本用戶、跨地域用戶的存在就是使用用戶調查的時機。 139
SERU誡語5-25：分析文檔資料時應該思考新流程對其的影響。 144
SERU誡語5-26：收集文檔時，應該盡可能讓用戶提供帶有真實數據的樣本。 145
SERU誡語5-27：需求捕獲人員要善於根據流程分析的結果主動收集相關文檔。 145
SERU誡語5-28：情節串聯闆是消除用戶盲區的有效技術。 146
SERU誡語5-29：情節串聯闆應該以業務場景作為展示的主綫索。 147
SERU誡語5-30：交互纔是情節串聯闆的本質，不要隻關注於界麵的靜態效果。 147
SERU誡語5-31：現場觀摩技術是消除開發團隊認識盲區的有效手段。 147
SERU誡語5-32：現場觀摩技術能夠使開發團隊實現對業務場景“感同身受”。 147
SERU誡語5-33：聯閤開發是突破雙方需求盲區的有效手段。 149
SERU誡語5-34：齣現“上麵開大會，下麵開小會”現象，一半責任在組織者。 150
SERU誡語5-35：溝通決定內容，內容決定格式。 152
第6章 需求分析與建模最佳實踐 157
SERU誡語6-1：需求分析就是先分解，再提煉，在這個過程中消除矛盾。 157
SERU誡語6-2：需求建模的過程遠比建模的結果更重要。 160
SERU誡語6-3：模型是用來溝通的，因此僅當需要時纔構建它。 161
SERU誡語6-4：建模的要點是根據要完成的任務選擇閤適的建模工具。 162
SERU誡語6-5：UML本身不是方法論。 164
SERU誡語6-6：業務流程是對信息係統進行“庖丁解牛”的核心綫索。 166
SERU誡語6-7：流程有組織級、部門級、崗位級三個層次，其中部門級是需求分析的主綫索，崗位級是需求細節填充時的工作內容，組織級是對部門級流程的抽象概括。 171
SERU誡語6-8：應該根據項目的特點和團隊的技能情況選擇閤適的模型。 173
SERU誡語6-9：模型最有效的方式是在交流中演化齣來的。 177
SERU誡語6-10：流程圖繪製完成之後，花些時間進行瓶頸和利益分析會有意想不到的收獲。 186
SERU誡語6-11：在需求建模時，應該大膽地用中文命名類和類的屬性。 195
SERU誡語6-12：需求階段的類建模應該盡可能保持簡單，引入過多的輔助建模元素反而會降低圖的可讀性。 200
SERU誡語6-13：領域模型是自底嚮上閤並齣來的。 206
SERU誡語6-14：領域模型的要點是拒絕實現、保持簡單、忠於問題域。 209
SERU誡語6-15：領域建模時應遵循“拒絕實現細節、大類不分拆、子類不閤並、同類不抽象”的原則。 209
SERU誡語6-16：團隊的分工不明確往往是導緻視圖交疊的原因，瞭解不同視圖的關注點，是理解不同模型的關鍵。 216
SERU誡語6-17：僅在需求規格中齣現用例圖並不意味著應用瞭用例技術。 219
SERU誡語6-18：韆萬不要為瞭使用擴展、包含關係而使用它們。擴展用例建模的通常是優先級較低的擴展事件流，包含關係建模的通常是多個用例所包含的公共子事件流。225
SERU誡語6-19：在訪談現場，就流程圖討論齣用例圖是高效的建模方法。 230
SERU誡語6-20：如果說用例有粒度，那麼它取決於業務流程和任務分工。 233
SERU誡語6-21：係統動作（諸如新增、刪除之類）和業務名詞在用例名稱中相遇時，就是一個十分危險的信號。 234
SERU誡語6-22：對不影響泳道間協作的判斷、活動均屬於細節信息。 237
SERU誡語6-23：對於報錶而言，並不一定非得按用例模闆來組織需求描述。 241
SERU誡語6-24：諸如Rose之類的建模工具，對模型抽象的支撐是最重要的。 252
SERU誡語6-25：前、後置條件齣現的頻度並不高，不要畫蛇添足。 257
SERU誡語6-26：避免在用例事件流描述中齣現實現細節、分支結構、循環結構；特彆是不應該齣現多路分支結構，如果齣現要反思用例抽象是否正確。 265
SERU誡語6-27：界麵原型部分是約束、是建議，目的是支持有效的UI設計。 269
SERU誡語6-28：建議使用不同的字體風格約定，以錶達齣數據的結構特點。 280
SERU誡語6-29：曆史記錄的標準也是數據需求的一部分。 280
SERU誡語6-30：哪裏有分解，哪裏就有接口。 297
第7章 需求描述最佳實踐 307
SERU誡語7-1：需求規格的格式取決於開發團隊的特點及所選的開發方法論。 329
SERU誡語7-2：用戶需求說明書是為生成軟件需求規格說明書服務的。 333
SERU誡語7-3：文字的歧義可能與其長度成正比。 335
SERU誡語7-4：要使需求描述更加清晰，就應該轉用“結構化文本”式描述。 338
SERU誡語7-5：在你被逼在需求描述中增加How的信息之前，先確認自己已經嘗試過為需求添加瞭Why。 339
SERU誡語7-6：對於非功能需求而言，應該拋棄定性，改用場景化描述；並通過選取指標、積纍經驗值的方法過渡到定量描述。 340
第8章 需求驗證最佳實踐 342
SERU誡語8-1：需求驗證的目標是盡可能暴露問題，而不是證明無錯。 347
SERU誡語8-2：在企業中推行即時評審、同級桌查等正式化程度不高的評審手段，是創建企業評審文化的有效手段。 348
SERU誡語8-3：在評審會中，不要用“評價者”的口氣談論你的觀點。 349
SERU誡語8-4：參加需求評審的人不是越多越好，一定要保證同級、適閤。 349
SERU誡語8-5：評審時要確保評審內容、缺陷檢查錶的規模適閤，內容應該按每小時30～40頁的速度來準備，缺陷檢查錶盡量在9條之內。 350
第9章 需求基綫操作實務 356
SERU誡語9-1：優先級是相對的，要在同一級中進行比較。 363
SERU誡語9-2：評價具體功能點的優先級時，應將其放到業務場景甚至是業務流程環境中考慮。 364
SERU誡語9-3：軟件估算是隨著工作任務的細化不斷提高精確度的。 365
SERU誡語9-4：不同階段進行軟件估算時，應該采用不同的計數單元。 365
SERU誡語9-5：悲觀估計、樂觀估計應和“風險”理由對應起來。 370
第10章 變更管理操作實務 373
SERU誡語10-1：需求變更管理的目標是控製變更，而非避免變更。 373
SERU誡語10-2：控製變更的目標是減少變更對開發工作的影響。 373
SERU誡語10-3：需求團隊的貢獻在於“盡早標識變更”，設計團隊的貢獻在於“盡可能以彈性的設計來減少變更的影響”。 374
SERU誡語10-4：建立統一的渠道讓客戶意識到變更的成本，減少“來路不正”的變更，記錄“變更的工作”。 374
SERU誡語10-5：CCB的核心人員隻有兩個，分彆代錶用戶團隊和開發團隊，其他組成人員都是協作者和決策者。 375
SERU誡語10-6：基於業務驅動的需求項（樹型）列錶，是對變更進行業務影響分析的有效方法。 380
SERU誡語10-7：對變更進行分類、再分類，是管理變更的重中之重。 383
第11章 需求跟蹤操作實務 384
SERU誡語11-1：需求跟蹤是高階管理活動，所需的工作量很大，特彆是軟件需求到設計元素的跟蹤，因此一定要考慮投入與産齣是否成正比。 385
· · · · · · (收起)