軟體需求最佳實踐：SERU過程框架原理與套用

本書的主線索是筆者在RUP（Rational統一過程）、信息工程理論、結構化分析方法、面向對象分析方法的基礎上，結合長期需求分析工作的實際經驗，剪裁出來的一個針對軟體需求工程階段的SERU過程框架。SERU過程框架覆蓋了需求定義、需求捕獲、需求分析與建模、需求描述四大活動，明確地定義了工作任務、介紹了工作方法、指出了工作產物、說明了產物之間的連線方法，可以幫助軟體開發團隊快速套用到工作中，有效提高需求工程的質量

基本介紹

• 書名：軟體需求最佳實踐
• 又名：軟體需求最佳實踐：SERU過程框架原理與套用
• 作者：徐鋒
• 原版名稱：軟體需求最佳實踐
• ISBN：9787121073953
• 類別： 圖書 >> 計算機/編程 >> 軟體工程
• 頁數：400頁
• 定價：￥59.80元
• 出版社：電子工業出版社
• 出版時間：2008-10-1
• 裝幀：精裝
• 開本：16開

宣傳語

·經驗密集，直擊需求實踐中各種問題。

·貫穿全書的SERU過程框架，詳盡地覆蓋了需求工作中各個環節的任務、要點及產物，可操作性極強。

內 容 簡 介

本書首先從軟體需求實踐中出現的主要問題和困難入手，指出了改進的主要方向；然後逐一說明了需求定義、需求捕獲、需求分析與建模、編寫規約、需求驗證等需求開發活動的任務、要點和具體手段；並提出了一個可操作性強、易於上手的SERU過程框架，能夠幫助讀者清晰地了解整個過程，理解各階段的關鍵產物和產物之間的關係。

本書還對包括需求基線、變更管理、需求跟蹤在內的需求管理活動的操作要點進行了闡述，給出了具有很強實踐性的具體建議。綜觀全書，語言淺顯、文字生動，蘊含了許多人文、心理、交流方面的知識，即使非技術背景的讀者也能夠輕鬆讀懂大部分內容，從中受益。

本書可作為計算機軟體專業本科生、研究生和軟體工程碩士的軟體需求分析教材，也可以作為軟體工程、軟體開發管理培訓的教材，更是一線項目經理、需求分析人員、資深開發人員、信息系統運行管理人員、研發企業管理人員的必備參考書。

作者簡介

徐鋒，中國系統分析員顧問團（CSAI）軟體工程首席顧問，中國軟體技術大會傑出貢獻專家，資深諮詢顧問、培訓講師。主要研究領域為需求工程、系統分析與設計、軟體估算，致力於推動軟體工程方法論的落地套用。作者具有豐富的軟體開發、信息系統運行與管理、市場規劃、企業管理等領域的從業經驗，善於從業務、技術兩個視角審視軟體開發工作。

曾在（程式設計師>等媒體發表了《實戰OO》、《項目管理三部曲》、《大話Design>等多個專欄文章，著有（LJM[．面向對象建模基礎>等多本書籍，翻譯了《JML2．O實戰》、《AOSD中文版》、《Cloud to Code中文版》等多本技術書籍。

前 言

寫一本書不容易，寫一本讓自己滿意的書更不容易，而寫一本讓讀者喜歡的書則是難上加難。或許這一“冠冕堂皇”的理由可以作為筆者一再錯過向關注本書的讀者所承諾的上市時間的藉口。但是沒有任何理由可以讓筆者鬆懈下來，畢竟自己一直在標榜要解決“我們並不缺乏需求的理論，缺少的是真正落地的方法”的問題，為所有讀者提供一種切實可行的實踐手段，是筆者寫作本書的核心目標。

在翻讀本書時，或許你會從本書的字裡行間讀到幾分輕鬆，這是因為書中有不少的文字是筆者在風景秀麗的員當湖畔的咖啡廳里寫就的，希望筆者這種輕鬆的心情能夠透過這些文字傳遞給每位工作在“沉重”的需求分析過程中的所有讀者。

在細究本書時，或許你會從本書的文字裡頭看到幾處零亂，這是因為文中有很多的段落是筆者在吚哎學語的一歲小兒的惡作劇邊碼成的，希望筆者這些零碎的想法能夠藉助書的脈絡傳達給每位工作在“繁雜”的需求分析原則下的所有讀者。

在將書稿交付編輯之時，我深刻地感到：本書雖然沒有Martin七年磨一劍的鋒芒，卻也有三年憋一本的艱辛。在整個寫作過程中，多次經歷了自我否定、推倒重來的痛苦，也享受了許多自我升華的樂趣；當然筆者衷心地希望本書能夠向大家傳遞樂趣。

本書特點

本書是一本直擊需求實踐中各種問題的書籍，在這裡沒有大量的理論和教條，有的只是翔實、生動的案例與場景；在這裡沒有高談闊論般的“道法自然”，有的只是源於生活瑣碎細節的“欣然頓悟”；在這裡沒有鷹擊長空般的豪情，有的只是“撒一把土、夯實它，再撒一把土……”的務實。

在全書的組織形式上，採用了簡單明了的語法，段落簡潔（就像寫需求那樣），讓你能夠輕鬆地閱讀；同時貫穿了許多源於生活、源於項目實踐的場景與案例，讓需求藝術“源於生活、高於生活”，為全書添色增彩；穿插了許多能夠令人沉思、輕鬆一笑的隱喻，為全書增加了一些漣漪；還埋伏了一些小提示，為全書增加了一些外延和聯想；而且還羅織了大量的誡語，使全書更多一些骨架與韻味。

相信所有需求實踐者都能夠從書中看到你工作的影子，尋找到一些“開箱即用” 的技巧和手段，同時也會有整理了一下思緒的妙味。

本書講了什麼

本書的主線索是筆者在RUP（Rational統一過程）、信息工程理論、結構化分析方法、面向對象分析方法的基礎上，結合長期需求分析工作的實際經驗，剪裁出來的一個針對軟體需求工程階段的SERU過程框架。

SERU過程框架覆蓋了需求定義、需求捕獲、需求分析與建模、需求描述四大活動，明確地定義了工作任務、介紹了工作方法、指出了工作產物、說明了產物之間的連線方法，可以幫助軟體開發團隊快速套用到工作中，有效提高需求工程的質量。

本書一共由4個部分，12個章節組成：

部 分 名 章 名 主要內容 頁碼

第一部分

原理、模型與誤區 第1章

需求實踐現狀分析 歸納實踐中遇到的問題，分析問題背後的原因，提出解決問題的方法，強調“業務驅動的需求過程”的重要性

第2章

不同軟體項目的需求視圖 指出各類軟體的需求視圖與線索，幫助需求人員明確工作方向

第3章

軟體需求與需求工程 從需求層面的角度理解需求工作的階段，並掌握不同需求類型的組織方法；指出實現優秀需求的核心手段，實例講解如何保障；對需求開發和需求管理工作的任務進行概述，說明需求分析人員工作的技能要求

第二部分

需求開發 第4章

需求定義最佳實踐 指出需求定義的任務，介紹需求定義的操作思路，介紹常用的人文方法；介紹需求定義階段確定系統範圍的具體方法；並說明需求定義階段的產物，核心內容為兩圖一綱（構件圖、上下文關係圖和需求大綱）

第5章

需求捕獲最佳實踐 從溝通的角度說明需求捕獲的障礙，並結合心理學知識提升捕獲能力；介紹各種需求捕獲方法的使用時機、要點；能在正確的時機正確地使用

第6章

需求分析與建模最佳實踐 幫助讀者理解為什麼要建模、什麼時候要建模、如何選擇模型等；學會正確理清流程分析、業務實體分析和用例分析，掌握正確的建模方法以及產物之間的關係；掌握填充用例和領域類的方法；學會有效地組織非功能需求、設計約束的方法

續表

第7章

需求描述最佳實踐 介紹需求描述的主要格式、寫作要點，以及一些提高需求規格說明書質量的手段與技巧

第8章

需求驗證最佳實踐 介紹需求驗證的主要手段、常見誤區，以及相應的解決方案

第三部分

需求管理 第9章

需求基線操作實務 說明基線和疊代開發的關係，通過實例說明基線管理中估算和優先權劃分兩大工作任務的具體執行方法。

第10章

變更管理操作實務 說明變更管理的目標與策略，並且進一步解釋統一渠道、統一平台兩大要點

第11章

需求跟蹤操作實務 說明需求跟蹤的作用、啟動時機及操作要點

第四部分

總結 第12章

SERU過程框架總結 對SERU過程框架進行概述，指出在實際項目中導入該過程框架的具體步驟和方法，強調了需求分析過程中的一些重要的原則與方法

如何進一步互動

為了更好地與讀者互動，提供相關信息及後續的更新，本書還將創建一個專門的網站來推廣SERU過程框架，如果你發現本書中的問題，或者在實際的工作中遇到問題，也可以通過電子郵件和我取得聯繫。

致謝

望著這本傾注了巨大激情的書籍，不禁想起被它吞噬的日日夜夜，不由得萌生出對家人的深深歉意，沒有你們的支持本書是不可能完成的；在此由衷地感謝我深愛的妻子許高芳以及敬愛的母親楊美琴，感謝你們多年來的鼓勵與支持。

望著這本匯聚了大量觀點的書籍，不禁想起為它貢獻的芸芸眾生，不由得萌生出對朋友的深深謝意，沒有你們的幫助本書是不可能精彩的；在此由衷地感謝我親愛的朋友們以及予以支持的學員，感謝你們一直來的關愛與幫助。

望著這本集結了眾多文字的書籍，不禁想起為它糾錯的雙雙眼睛，不由得萌生出對編輯的深深敬意，沒有你們的協助本書是不可能高質的；在此由衷地感謝本書的責任編輯以及所有工作人員，感謝你們盡職盡責地把好最後一關。

最後，我還要向CSAI創始人張友生博士，主要貢獻者馬映冰、田俊國、溫昱、張華表示感謝，你們的觀點讓我如沐春風；向博文視點的郭立、李冰表示感謝，你們的幫助讓本書最終付諸實現；向中國平安、中國工商銀行、中國建設銀行、中興通訊、東軟集團、用友政務、新大陸、福諾等企業中聽過我的課程，以及參加各期公開課的朋友們表示感謝，你們的意見、觀點、建議使本書更加精彩，在我向大家分享經驗的同時也收穫了許多寶貴的財富。

譚 文

2008年4月2日

目 錄

第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 透過表象，分析本質 12

1.2.1 需求變更頻繁 12

1.2.2 上線阻力大 13

1.2.3 運行效果差 14

1.2.4 完全崩潰 15

1.3 方法論與需求工作 16

1.3.1 計算模式 16

1.3.2 軟體工程方法論 17

1.3.3 開發思想 18

1.4 小結 19

第2章 不同軟體項目的需求視圖 20

隨著信息化套用的逐漸深入，軟體項目在企業、政府等各類組織中所擔負的角色也越來越多，套用層面也在逐漸地深入，同時也意味著不同的軟體項目具有不同的特點，這也就對需求工作產生了諸多影響。 在本章中，我們就將針對信息系統、嵌入式系統、軟體產品等不同角度來說明如何進行相應的需求工作，為需求分析師提供一個切實有效的視圖。

2.1 信息系統的需求視圖 20

2.1.1 信息系統的本質與分類 20

2.1.2 在線上事務處理系統——流程電子化 22

2.1.3 管理信息系統——數據信息化 25

2.1.4 其他信息系統 29

2.1.5 信息系統的多維視圖 31

2.2 嵌入式系統的需求視圖 33

2.2.1 面向直接用戶的嵌入式系統 34

2.2.2 面向特定設備的嵌入式系統 35

2.3 軟體產品的需求視圖 36

2.4 小結 40

第3章 軟體需求與需求工程 41

筆者在做需求分析師的培訓時，經常會問學員這樣的一個問題：什麼是軟體需求？這個看似簡單的問題卻並不好回答，也許很多人會簡單地認為軟體需求就是用戶需要實現的功能加上一些非功能方面的要求。但這樣的理解卻並不完整，如果對用戶所處的業務場景沒有建立正確認識，經常會給工作帶來麻煩。因此本章將對一些與需求、需求工程相關的關鍵概念進行闡釋。

3.1 什麼是軟體需求 41

3.1.1 需求的三個層次 41

3.1.2 需求的三種類型 43

3.1.3 優秀需求的標準 46

3.2 需求工程解析 50

3.2.1 需求工程的範疇 50

3.2.2 需求開發工作要點 51

3.2.3 需求管理工作要點 56

3.2.4 需求分析人員的技能組成 58

3.2.5 SERU模型概述 59

3.3 小結 61

第2部分 需求開發

第4章 需求定義最佳實踐 64

需求定義活動準確來說是不屬於需求工程範疇的，它實際上是立項管理需要做的工作。但需求定義階段的產物對於需求捕獲、分析與建模活動都有著直接的影響，如果這個階段的工作做得不理想，就會出現“上樑不正下樑歪”的結果。因此本書還是將這個活動納入進來，並將給大家提供一個能夠與後續活動結合緊密的方法。

4.1 需求定義任務概述 64

4.1.1 需求定義的時機 64

4.1.2 需求定義的理念與策略 65

4.2 問題分析的五步法 66

4.2.1 在問題定義上達成共識 67

4.2.2 分析問題背後的問題 73

4.2.3 確定相關人員和用戶 77

4.2.4 定義解決方案的界限 78

4.2.5 確定加在解決方案上的約束 80

4.2.6 小結 81

4.3 需求定義的產物與要素 81

4.3.1 需求定義的產物 81

4.3.2 需求定義的要素 82

4.4 定義需求範圍 87

4.4.1 案例說明 87

4.4.2 劃分主題域 88

4.4.3 確定主題域範圍 97

4.4.4 標識業務事件與報表 101

4.4.5 生成需求大綱 104

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 需求捕獲的主要方法 125

5.2.1 用戶訪談 125

5.2.2 用戶調查 137

5.2.3 文檔考古 142

5.2.4 情節串聯板 144

5.2.5 現場觀摩 145

5.2.6 聯合開發 147

5.3 需求捕獲的記錄工具 150

5.3.1 工具的選擇與定義 150

5.3.2 任務卡片 151

5.3.3 場景說明 152

5.3.4 其他工具 153

5.4 小結 154

第6章 需求分析與建模最佳實踐 156

需求分析是需求工程中最為核心的工作，而需求建模則是需求分析的主要手段。但由於分析這個詞比較抽象，很多時候讓人感到無從入手，甚至導致被輕易地滑過了，直接將需求捕獲的結果整理到軟體需求規格說明書中。而需求建模也有很多工具，到底怎么有效地套用到需求分析過程中也是令人感到難以掌握的東西。因此本章的目標就是為讀者勾勒出需求分析的階段與任務，指出如何選擇適合的建模工具，以及在什麼時機、如何套用這些建模工具。

6.1 需求分析與建模的要點與誤區分析 156

6.1.1 需求分析到底做什麼 156

6.1.2 建模的目標與要點 159

6.1.3 選擇建模工具的要點 160

6.2 周期一：理清框架與脈絡 164

6.2.1 業務流程分析 165

6.2.2 業務實體分析 191

6.2.3 角色與使用場景分析 216

6.2.4 周期一的產物 232

6.3 周期二：確定需求細節 249

6.3.1 確定行為需求的細節 250

6.3.2 確定結構需求的細節 270

6.3.3 周期二的產物 279

6.4 其他需求分析 292

6.4.1 接口需求 292

6.4.2 非功能需求的追蹤 294

6.4.3 設計約束 297

6.5 小結 301

第7章 需求描述最佳實踐 302

需求描述就是將需求捕獲、分析的結果進行文檔化的過程。在軟體開發時，將分析的結果文檔化是不可或缺的任務，也稱為編寫規約活動；而在某個項目中，可能還會由用戶代表或需求捕獲人員對捕獲的內容進行整理，形成用戶需求說明書。具體要乾什麼，想必大家並不陌生，而且在前一章中也看到了一些實例的片段。因此本章將重點從需求描述的風格與格式、寫作策略與技巧兩個方面做些強調和補充。

7.1 需求描述的風格與格式 302

7.1.1 常見的描述風格與選用標準 302

7.1.2 典型軟體需求規格說明書模板解析 303

7.1.3 定義模板的技巧 318

7.1.4 用戶需求說明與軟體需求規格說明 326

7.2 寫作策略與技巧 328

7.2.1 文字表達的先天不足 328

7.2.2 需求描述的兩大原則 330

7.2.3 不要忽視陳述需求理由的重要性 332

7.2.4 注意措辭 334

7.3 小結 335

第8章 需求驗證最佳實踐 336

需求驗證是需求開發的最後一個環節，它是一個質量關。也就是說，其目標是發現儘可能多的錯誤，減少因為需求的錯誤而帶來的工作量浪費。而需求驗證的主要手段就是Review（複查，也常譯為評審）。但是許多需求團隊都覺得需求驗證比較容易變得“務虛”，收效很少，本章的目標就是幫助大家緩解這個問題。

8.1 需求驗證的主要手段 336

8.1.1 不同正式化程度的評審 336

8.1.2 審查過程概述 338

8.2 需求驗證的主要誤區與解決方案 340

8.2.1 需求驗證的5大要點 341

8.2.2 需求驗證常見的5大問題 344

8.3 小結 346

第3部分 需求管理

第9章 需求基線操作實務 348

需求基線是需求管理活動中最為基礎的一個，通常也是在項目中首先應該引入的管理活動。但許多相關書籍中對需求基線的介紹相對比較理論化，很少給出具體的操作方法，往往使得許多軟體開發團隊無從入手。為了幫助大家更好地引入需求基線，本章的重點將是結合具體的實例來說明需求基線的劃分方法。

9.1 需求基線的理念與策略 348

9.1.1 基線思想的起源 348

9.1.2 基線的策略 350

9.2 基線劃定的基礎：優先權評價 351

9.2.1 組織需求項 351

9.2.2 業務優先權評價 352

9.2.3 根據技術依賴性和項目風險調整優先權 356

9.3 基線劃定的要素：工作量估算 356

9.3.1 估算的意義與要點 356

9.3.2 定義階段的估算示例 358

9.3.3 分析一階段的估算示例 361

9.4 基線劃定與管理 362

9.4.1 劃定基線 362

9.4.2 管理基線 363

9.5 小結 364

第10章 變更管理操作實務 365

需求變更頻繁恐怕是困擾無數軟體開發團隊的惡魔之首，而且在美國權威的第三方機構Standish Group的CHAOS報告中，也將其列為困擾軟體開發團隊、導致項目失敗的5大原因之一，其中原因實際上也充分暴露了整個產業的不成熟。需求變更在CHAOS報告中是排名第四的問題，而在中國軟體開發團隊中卻是排名第一的問題，這裡面就意味著存在距離，本章的目的就是希望幫助大家找到其中的差距。

10.1 變更管理的理念 365

10.2 變更管理要點一：統一渠道 366

10.2.1 CCB背後的道理 366

10.2.2 變更處理過程 368

10.3 變更管理要點二：統一平台 373

10.3.1 變更管理平台的選擇 373

10.3.2 變更管理平台的套用要點 374

10.4 小結 375

第11章 需求跟蹤操作實務 376

需求跟蹤是一個高階的管理活動，它的目標是為了更好地管理需求的狀態、更好地分析需求變更產生的影響。雖然執行需求跟蹤會帶來不錯的效益，但其所需付出的工作量也是巨大的。本章我們就對跟蹤的一些要點做一簡要的說明。

11.1 需求跟蹤的基本概念 376

11.1.1 用戶需求到軟體需求的跟蹤 377

11.1.2 軟體需求到軟體需求的跟蹤 377

11.1.3 軟體需求到下游工作產品的跟蹤 377

11.2 需求跟蹤的操作方法 378

11.2.1 表格法 378

11.2.2 鍊表法 379

11.3 小結 381

第4部分 總結

第12章 SERU過程框架總結 384

筆者經常說一個觀點：“我們並不缺乏軟體工程、需求工程的理論、技術，缺乏的是將這些理論與技術有效地套用到實踐中去的具體方法”。而貫穿全書的SERU過程框架（也稱為SERU模型）正是筆者基於多年不同領域、不同規模的軟體項目實踐的基礎上，通過對許多重型方法的剪裁而得到的一個清晰、實用的軟體需求過程框架。

12.1 SERU過程框架要點概述 384

12.1.1 SERU過程框架的理論基礎 384

12.1.2 SERU過程框架全景圖 385

12.1.3 SERU過程框架導入建議 388

12.2 需求實作要點概述 388

12.3 結語 391

參考文獻 392

SERU誡語目錄

第1章 需求實踐現狀分析 2

SERU誡語1-1：需求規格說明書應該採用業務導向的樹型層次結構來組織。 6

SERU誡語1-2：對於需求分析員而言，真正的專業主義是基於業務利益

SERU誡語1-2：（解決問題、創造機會、提高管控力等）的溝通。 6

SERU誡語1-3：緩解溝通失真最有效的方法是及時複述。 9

SERU誡語1-4：需求分析的本質在於業務分析，而非技術分析。 11

SERU誡語1-5：業務場景是需求之魂。 12

SERU誡語1-6：需求分析人員對於技術方法論的評價重在適用性。 16

SERU誡語1-7：對預設計的需求是評判敏捷方法論是否適用的關鍵。 18

第2章 不同軟體項目的需求視圖 20

SERU誡語2-1：流程分析（業務事件）是OLTP系統的關鍵線索和主要視圖。 23

SERU誡語2-2：報表分析是MIS系統的關鍵線索和主要視圖。 26

SERU誡語2-3：決策場景是DSS系統的關鍵線索和主要視圖。 29

SERU誡語2-4：工作場景是專家系統的關鍵線索和主要視圖。 30

SERU誡語2-5：並行工作流是OA系統的關鍵線索和主要視圖。 30

SERU誡語2-6：高層管理人員的關注點往往在問題和機會。 33

SERU誡語2-7：對於面向用戶的嵌入式系統，行為分析是要點。 35

SERU誡語2-8：面向特定設備的嵌入式系統，外部接口和事件分析是要點。 36

SERU誡語2-9：信息系統類軟體產品的需求重點在於針對不同目標客戶群體的

SERU誡語2-9：不同商業模式分離變化點；經常需要減出通用性，再通過插接

SERU誡語2-9：解決擴展性。 39

SERU誡語2-10：基於使用場景的困難點分析是工具軟體的需求要點。 40

第3章 軟體需求與需求工程 41

SERU誡語3-1：業務需求是需求定義的產物，用戶需求是需求捕獲的產物，

SERU誡語2-9：軟體需求是需求分析與建模的產物。 43

SERU誡語3-2：功能需求的要點在於如何組織。 44

SERU誡語3-3：非功能需求的要點在於保證信息的有效傳遞和注意其局部性。 44

SERU誡語3-4：設計約束包括非技術因素的技術選型、預期的軟硬體環境和預期的

SERU誡語2-9：使用環境三大類型。 45

SERU誡語3-5：業務導向的層次結構是保障完整性的關鍵。 46

SERU誡語3-6：需求有時會戴上“高優先權”的面具，實際上就是擔心

SERU誡語2-9：你不去實現它。 48

SERU誡語3-7：滿意/不滿意度模型是需求必要性評價的有效手段。 49

SERU誡語3-8：在需求捕獲活動中，化被動為主動是關鍵。 52

SERU誡語3-9：需求分析就是向下分解+向上提煉，外加一些規格化。 53

SERU誡語3-10：需求分析是目標，需求建模是手段。 54

SERU誡語3-11：在編寫需求規格說明書時，應確保一類信息只在一處描述。 55

SERU誡語3-12：劃分出大小合適、粒度均勻的需求項是需求管理的前提。 57

SERU誡語3-13：需求優先權與工作量估算是基線管理的關鍵。 57

SERU誡語3-14：SERU模型是需求分析的工作指南。 60

第4章 需求定義最佳實踐 64

SERU誡語4-1：清晰的項目目標和範圍定義，能夠引導需求工作順利進行。 65

SERU誡語4-2：對混沌不清的目標，可以通過內部尋根或外部溯源來破解。 65

SERU誡語4-3：對問題進行了正確的定義，意味著成功解決了一半。

SERU誡語2-9：而在問題定義時應該善於使用轉換和本源兩個技巧。 68

SERU誡語4-4：需求定義階段要善於將未知解問題轉換成已知解問題。 68

SERU誡語4-5：在確定某問題的解決方案時，一定要思考是否會引發新問題。 70

SERU誡語4-6：直接修改錯誤，不要用其他方案來彌補錯誤。 71

SERU誡語4-7：魚骨圖為解決問題找到了靶子，帕累托圖則標上了環數。 76

SERU誡語4-8：範圍是涉及的事、物，邊界是人與系統的職責邊界。 79

SERU誡語4-9：用戶永遠會希望花同樣的錢，獲得儘可能多的功能。 79

SERU誡語4-10：需求階段描述的是用戶的能力特點，旨在提高可用性。 86

SERU誡語4-11：你可以不做一件事，但一定不能不知道為什麼需要做這件事。 86

SERU誡語4-12：在分解系統時，應該按業務的脈絡來劃分成不同的主題域。 89

SERU誡語4-13：各個主題域之間的服務接口是需求變更的防火牆。 91

SERU誡語4-14：確保能做的事和知道的事相匹配是職責驅動設計的要點。 93

SERU誡語4-15：目標決定範圍。 96

SERU誡語4-16：繪製上下文關係圖，先考慮Customer再考慮Worker是要點。 98

SERU誡語4-17：業務事件應該是主動觸發的，並且將會產生一系列後續行為。 103

SERU誡語4-18：業務事件是直接作用於系統的，也就是將觸發系統行為。 103

第5章 需求捕獲最佳實踐 109

SERU誡語5-1：需求捕獲是撒網打魚，不是休閒釣魚。 109

SERU誡語5-2：善於聚焦訪談話題是需求捕獲人員成功的關鍵。 111

SERU誡語5-3：嘗試理解業務場景是合格需求分析人員的良好習慣。 112

SERU誡語5-4：善於利用技術為用戶創造全新體驗是優秀需求人員的特質。 113

SERU誡語5-5：通過比較用戶代表的表述來識別言過其實，利用差異展現、

SERU誡語2-9：瓶頸分析法來緩解影響。 114

SERU誡語5-6：針對越俎代庖心理現象最有效的方法是識別正確的被訪談者。 114

SERU誡語5-7：離開辦公室、對訪談進行計畫是避免非正事現象的主要手段。 115

SERU誡語5-8：化敵為友是緩解抗拒心態的主要方向。 116

SERU誡語5-9：傾聽對方的抱怨是化敵為友的有效手段之一。 116

SERU誡語5-10：突破推卸責任心理的簡單手段是讓被訪談者介紹工作場景。 117

SERU誡語5-11：需求捕獲時不要忽視對變更可能的了解。 117

SERU誡語5-12：在需求捕獲時要善於使用“？”之箭，找到真正的需求。 120

SERU誡語5-13：“撥開立場，尋找利益訴求”是需求協商的要點。 122

SERU誡語5-14：不要孤立地看待需求項，應該將所有需求視為一個整體。 123

SERU誡語5-15：“環境”將改變結果，切換不同的視角會得到不同的認識。 124

SERU誡語5-16：善於打比方是提高跨專業溝通效果的好方法。 125

SERU誡語5-17：占用時間長和信息的片面性是用戶訪談的兩大敵人。 126

SERU誡語5-18：訪談的線索是因“人”（用戶類型）而異的。 126

SERU誡語5-19：儘量將訪談問題事先發給被訪談者，讓他打一場有準備之戰。 128

SERU誡語5-20：在需求捕獲時別忘了“一圖抵千言”這句經典提示。 132

SERU誡語5-21：用戶訪談是一個有計畫的、科學的過程。 135

SERU誡語5-22：用戶調查能夠有效克服用戶訪談中存在的片面性。 137

SERU誡語5-23：在需求捕獲過程中，先訪談再調查是更合理的方式。 137

SERU誡語5-24：大樣本用戶、跨地域用戶的存在就是使用用戶調查的時機。 138

SERU誡語5-25：分析文檔資料時應該思考新流程對其的影響。 143

SERU誡語5-26：收集文檔時，應該儘可能讓用戶提供帶有真實數據的樣本。 143

SERU誡語5-27：需求捕獲人員要善於根據流程分析的結果主動收集相關文檔。 144

SERU誡語5-28：情節串聯板是消除用戶盲區的有效技術。 144

SERU誡語5-29：情節串聯板應該以業務場景作為展示的主線索。 145

SERU誡語5-30：互動才是情節串聯板的本質，不要只關注於界面的靜態效果。 145

SERU誡語5-31：現場觀摩技術是消除開發團隊認識盲區的有效手段。 146

SERU誡語5-32：現場觀摩技術能夠使開發團隊實現對業務場景“感同身受”。 146

SERU誡語5-33：聯合開發是突破雙方需求盲區的有效手段。 147

SERU誡語5-34：出現“上面開大會，下面開小會”現象，一半責任在組織者。 148

SERU誡語5-35：溝通決定內容，內容決定格式。 150

第6章 需求分析與建模最佳實踐 156

SERU誡語6-1：需求分析就是先分解，再提煉，在這個過程中消除矛盾。 156

SERU誡語6-2：需求建模的過程遠比建模的結果更重要。 159

SERU誡語6-3：模型是用來溝通的，因此僅當需要時才構建它。 160

SERU誡語6-4：建模的要點是根據要完成的任務選擇合適的建模工具。 161

SERU誡語6-5：UML本身不是方法論。 163

SERU誡語6-6：業務流程是對信息系統進行“庖丁解牛”的核心線索。 165

SERU誡語6-7：流程有組織級、部門級、崗位級三個層次，其中部門級是

SERU誡語2-9：需求分析的主線索，崗位級是需求細節填充時的工作內容，

SERU誡語2-9：組織級是對部門級流程的抽象概括。 170

SERU誡語6-8：應該根據項目的特點和團隊的技能情況選擇合適的模型。 172

SERU誡語6-9：模型最有效的方式是在交流中演化出來的。 176

SERU誡語6-10：流程圖繪製完成之後，花些時間進行瓶頸和利益分析會有意

SERU誡語6-10：想不到的收穫。 185

SERU誡語6-11：在需求建模時，應該大膽地用中文命名類和類的屬性。 194

SERU誡語6-12：需求階段的類建模應該儘可能保持簡單，引入過多的輔助建模

SERU誡語6-10：元素反而會降低圖的可讀性。 199

SERU誡語6-13：領域模型是自底向上合併出來的。 205

SERU誡語6-14：領域模型的要點是拒絕實現、保持簡單、忠於問題域。 207

SERU誡語6-15：領域建模時應遵循“拒絕實現細節、大類不分拆、子類不合併、

SERU誡語6-10：同類不抽象”的原則。 207

SERU誡語6-16：團隊的分工不明確往往是導致視圖交疊的原因，了解不同視圖的

SERU誡語6-10：關注點，是理解不同模型的關鍵。 214

SERU誡語6-17：僅在需求規格中出現用例圖並不意味著套用了用例技術。 216

SERU誡語6-18：千萬不要為了使用擴展、包含關係而使用它們。擴展用例

SERU誡語6-18：建模的通常是優先權較低的擴展事件流，包含關係建模的

SERU誡語6-18：通常是多個用例所包含的公共子事件流。 222

SERU誡語6-19：在訪談現場，就流程圖討論出用例圖是高效的建模方法。 226

SERU誡語6-20：如果說用例有粒度，那么它取決於業務流程和任務分工。 230

SERU誡語6-21：系統動作（諸如新增、刪除之類）和業務名詞在用例名稱中

SERU誡語6-18：相遇時，就是一個十分危險的信號。 230

SERU誡語6-22：對不影響泳道間協作的判斷、活動均屬於細節信息。 234

SERU誡語6-23：對於報表而言，並不一定非得按用例模板來組織需求描述。 238

SERU誡語6-24：諸如Rose之類的建模工具，對模型抽象的支撐是最重要的。 249

SERU誡語6-25：前、後置條件出現的頻度並不高，不要畫蛇添足。 254

SERU誡語6-26：避免在用例事件流描述中出現實現細節、分支結構、

SERU誡語6-18：循環結構；特別是不應該出現多路分支結構，如果出現

SERU誡語6-18：要反思用例抽象是否正確。 261

SERU誡語6-27：界面原型部分是約束、是建議，目的是支持有效的UI設計。 266

SERU誡語6-28：建議使用不同的字型風格約定，以表達出數據的結構特點。 276

SERU誡語6-29：歷史記錄的標準也是數據需求的一部分。 276

SERU誡語6-30：哪裡有分解，哪裡就有接口。 292

第7章 需求描述最佳實踐 302

SERU誡語7-1：需求規格的格式取決於開發團隊的特點及所選的開發方法論。 324

SERU誡語7-2：用戶需求說明書是為生成軟體需求規格說明書服務的。 328

SERU誡語7-3：文字的歧義可能與其長度成正比。 330

SERU誡語7-4：要使需求描述更加清晰，就應該轉用“結構化文本”式描述。 332

SERU誡語7-5：在你被逼在需求描述中增加How的信息之前，先確認自己已經

SERU誡語7-5：嘗試過為需求添加了Why。 334

SERU誡語7-6：對於非功能需求而言，應該拋棄定性，改用場景化描述；

SERU誡語7-5：並通過選取指標、積累經驗值的方法過渡到定量描述。 335

第8章 需求驗證最佳實踐 336

SERU誡語8-1：需求驗證的目標是儘可能暴露問題，而不是證明無錯。 341

SERU誡語8-2：在企業中推行即時評審、同級桌查等正式化程度不高的評審手段，

SERU誡語7-5：是創建企業評審文化的有效手段。 342

SERU誡語8-3：在評審會中，不要用“評價者”的口氣談論你的觀點。 343

SERU誡語8-4：參加需求評審的人不是越多越好，一定要保證同級、適合。 343

SERU誡語8-5：評審時要確保評審內容、缺陷檢查表的規模適合，內容應該按每

SERU誡語7-5：小時30～40頁的速度來準備，缺陷檢查表儘量在9條之內。 344

第9章 需求基線操作實務 348

SERU誡語9-1：優先權是相對的，要在同一級中進行比較。 355

SERU誡語9-2：評價具體功能點的優先權時，應將其放到業務場景甚至是業務

SERU誡語7-5：流程環境中考慮。 356

SERU誡語9-3：軟體估算是隨著工作任務的細化不斷提高精確度的。 357

SERU誡語9-4：不同階段進行軟體估算時，應該採用不同的計數單元。 357

SERU誡語9-5：悲觀估計、樂觀估計應和“風險”理由對應起來。 362

第10章 變更管理操作實務 365

SERU誡語10-1：需求變更管理的目標是控制變更，而非避免變更。 365

SERU誡語10-2：控制變更的目標是減少變更對開發工作的影響。 365

SERU誡語10-3：需求團隊的貢獻在於“儘早標識變更”，設計團隊的貢獻在於

SERU誡語10-3：“儘可能以彈性的設計來減少變更的影響”。 366

SERU誡語10-4：建立統一的渠道讓客戶意識到變更的成本，減少“來路不正”

SERU誡語10-3：的變更，記錄“變更的工作”。 366

SERU誡語10-5：CCB的核心人員只有兩個，分別代表用戶團隊和開發團隊，

SERU誡語10-3：其他組成人員都是協作者和決策者。 367

SERU誡語10-6：基於業務驅動的需求項（樹型）列表，是對變更進行業務

SERU誡語10-3：影響分析的有效方法。 372

SERU誡語10-7：對變更進行分類、再分類，是管理變更的重中之重。 375

第11章 需求跟蹤操作實務 376

SERU誡語11-1：需求跟蹤是高階管理活動，所需的工作量很大，特別是軟體需求

SERU誡語10-3：到設計元素的跟蹤，因此一定要考慮投入與產出是否成正比。 377