需求定義應該是項目啟動時要解決的事情(應該是PMP裏項目章程的壹部分內容，應該在項目啟動會前準備好)。
但在實際項目中很難達到要求，因為在項目立項階段，開發團隊包括需求分析人員可能還沒有成立。在這種情況下，需求分析人員更應該審視和補救需求定義階段的產物。
清晰的項目目標和範圍定義，能夠引導需求工作順利進行。
4.1.2.1 破解混沌不清的項目目標
對於項目目標經常會做的比較空洞，例如“全面提高企業的信息化應用水平”，這些空洞的目標難以落實。
對混沌不清的目標，可以通過內部尋根或外部溯源來破解。
》內部尋根
當妳看到壹個比較空洞的目標時，首先可以嘗試尋找企業內部真正的項目發起人，跟他們深入溝通。
》外部溯源
項目有時並不是內部發起的，而是受到壹些外部條件的影響，這時就要從外部尋找信息。
4.1.2.2 需求定義的理念
需求定義就是四個字：問題/機會。
具體步驟：GPOA模型。在需求定義或項目提案時，經常會采用目標Goal-問題Problem-可選方案Options-建議方案Answer的過程。
》目標Goal：通過內部尋根或外部溯源方法，將整個項目要解決的問題或機會羅列出來。
》問題Problem：找出該目標的問題/機會根源，然後全部羅列出來。
》可選方案Options：針對每個問題/機會，羅列出盡可能多的解決方案。
》建議方案Answer：從可選方案中挑出最可靠的方案。
對於需求定義活動，RUP給出五步法，但在實際項目中會發現可操作性並不強，但它提供了壹個很好的理論框架，我們先學習五步法，後續將介紹更適合落地的方法。
將問題分為五個步驟：第壹步：在問題定義上達成***識。第二步：問題的根本原因分析。第三步：確定相關人員和用戶。第四步：定義解決方案的界限；第五步：確定加在解決方案上的約束。
要讓大家達成***識，采用統壹的格式描述問題就是壹個有效的手段。
4.2.1.1 問題定義的技巧
對問題進行了正確的定義，意味著成功了壹半，而在問題定義時應該善於運用轉換和本源兩個技巧。
》轉換
需求定義階段要善於將未知問題轉換成已知問題
例如在實際項目過程中，在和客戶溝通時就應該註意如何將客戶的需求轉換成自己的已有產品，而不是簡單的重新開發。
》本源
問題經常會被表象所掩蓋《妳的燈亮著嗎--發現問題的真正所在》中收錄了壹些案例。
在確定某問題的解決方案時，壹定要思考是否會引發新的問題。
用壹個成本很大的解決方案去彌補壹個錯誤，是很常見的問題。
直接修改錯誤，不要用其他方案來彌補錯誤。
4.2.1.2 影響人群分析的技巧
根本原因分析有兩個實用工具：魚骨圖，帕累托圖。
4.2.2.1 魚骨圖
是壹種找出根本原因的方法，主要用於定性分析。魚骨圖通常要結合頭腦風暴，具體來說就是壹個團隊壹起繪制魚骨圖。步驟如下：
1 選擇問題。首選必須選擇壹個具體的問題或結果。
2 頭腦風暴。頭腦風暴的目的是尋找原因，不能將原因和解決方案混為壹談。
3 確定原因類型。對頭腦風暴的結果匯總，壹般來說類型不會超過六種：人，機，料，法，環。
4 分配原因。將頭腦風暴得出的原因，歸於相應的原因類型下，放在魚骨圖中。
5 分析根本原因。
6 小結。
4.2.2.2 帕累托圖
帕累托圖主要進行定量分析。主要用來識別最重要的事項，即關鍵原因。帕累托分析常常揭示出壹個現象：少數失誤應該為大量的質量成本負責，也就是大名鼎鼎的28法則。步驟如下：
1 確定問題和相關原因。這個工作實際上可以由魚骨圖來完成。
2 收集數據。針對魚骨圖的結果，隨機抽取樣品，收集分析每個原因的頻率。
3 繪制直方圖。將原因放在x軸上，比例或頻率放在y軸上。
4 小結。
魚骨圖為解決問題找到了靶子，帕累托圖則標上了環數。
以上兩種方法都是站在問題的角度進行分析，需求人員應該判斷哪些原因是可以通過信息系統解決的，從而使系統的確立更加科學。
當問題明確後，系統的目標也就明確了。接下來就是明確項目幹系人了。
4.2.3.1 Stakeholder分析(PMP裏的幹系人分析)
項目幹系人，涉眾，利益人等項目管理書籍中常提到的詞語，都源自Stakeholder，它的原意是籌碼持有人。
4.2.3.2 用戶分析
用戶實際上也是Stakeholder的壹類，他們是直接使用系統的人。
4.2.4.1 範圍 vs 邊界
範圍是涉及的事，物。邊界是人與系統的職責邊界。
4.2.4.2 確定邊界
4.2.4.3 邊界談判
用戶永遠會希望花同樣的錢，獲得盡可能多的功能。
這不能完全歸於是客戶的原因，因為交易雙方處於信息不對稱的時候，就壹定會出現這種情況。
很多時候，妳不能直接回復客戶說妳要的功能太多了，這些投資是不夠的，而是應該找到更有力的理由。
4.2.4.3 創新邊界
4.2.5 確定加載解決方案上的約束
主要包括技術約束和項目實施約束。
4.2.6 RUP問題分析五步法小結
五步法更多是從策略，思考方式的焦點入手，在實際操作上並沒有給出清晰的指導，在接下來兩章中，將重點分析需求分析人員在需求定義中應該完成哪些任務，具體應該做些什麽。
根據項目類型不同，產物可以分為POS(Project Overview Sprcify，項目綜述) 和 Vision(願景) 兩大類。
4.3.1.1 POS類
對於項目型的軟件開發工作，通常會在立項結束時完成立項報告，最典型的就是項目章程，可行性分析報告等。主要內容如下：
4.3.1.2 Vision類
對於生命周期相對較長，應用面相對較廣的項目或產品而言，會在POS的基礎上添加壹些內容，主要是市場分析，規劃方面，最典型的是RUP推薦的Vision文檔。
從內容可以看出，Vision更重視市場機會分析，有時甚至會加入SWOT分析等市場分析內容。
4.3.2.1 目標
目標對於壹個項目而言，其重要性不言而喻。壹個好的目標應該滿足SMART原則：
》具體(Sprcific)
》可以度量的(Measureable)
》可以達到的(Attainable)
》與其他目標具有相關性(Relevant)
》有明確的截至期限(Time-based)
而在具體寫作過程中，從目標，業務優勢，度量指標，合理性，可行性和可達成性方面進行編寫，是壹個不錯的選擇。
4.3.2.2 範圍
很多書籍都推薦通過上下文關系圖來描述範圍，在這裏將介紹壹種“兩圖壹綱”的方法，將在4.4節中詳細介紹。
4.3.2.3 相關人員與用戶
需求階段描述的是用戶的能力特點，以便提高系統可用性。
在進行需求定義時，對於用戶而言，需要收集和分析的信息包括：與系統主題相關的經驗，技術上的經驗，智力能力，對工作的態度，對技術的態度，受教育程度，語言技能，年齡，性別等信息。
對於用戶之外的幹系人，則需要了解他們對於軟件系統的關註點，想通過系統獲得什麽利益。
4.3.2.4 相關事實與假定
需求方為很多時候都用程序分解結構(系統-子系統-模塊-子模塊)來表示，在前面已經描述這種結構的弊端。在這裏將介紹兩圖壹綱的方法，即構件圖，上下文關系圖和需求大綱。
當我們面對壹個新系統時，可以將整個待開發的系統看做壹個黑盒子；首先要判斷是否需要劃分成不同的主題域。如果需要，就通過壹張構件圖將主題域和他們之間的服務接口標識出來。
4.4.2.1 什麽是主題域
主題域劃分跟傳統的子系統劃分是有很大區別的。首先看看傳統的子系統劃分：
傳統劃分方法經常是“業務名詞+管理”的方式命名，本質上是以物為線索。雖然體現了系統的分解結構，但忽略了每個系統/模塊之間的關系。
主題域劃分則是以事為線索，通過構件圖來展現系統。
主題域劃分的思考過程
》以組織結構為線索
》以分管領導為突破
》借鑒典型業務區塊
在最終決定主題域之前，還需要結合目標來考慮這些主題域，如果主題域跟目標無關，就可以將它移除。
目標決定範圍。
4.4.2.2 使用構件圖
》構件圖可以體現服務接口的重要性
》構件圖解析
× 構件
× 服務接口
× 構件與接口之間的關系：提供，使用
上下文關系圖是繪制系統範圍很重要的壹種工具。在劃分完主題域之後，針對每個主題域來繪制上下文關系圖，以確定每個主題域的範圍。
4.4.3.1 上下文關系圖繪制要點
在繪制上下文關系圖時應采用以下步驟：
1 首先用壹個矩形表示系統
2 找到該系統的所有Customer，考慮每個Customer會發起什麽事件，這些事件會引發Worker什麽工作，將這些序列逐壹表示出來。
3 最後看看每個Worker還有沒有主動發起的事件。
在繪制上下文關系圖時，先考慮Customer再考慮Worker是關鍵。
上下文關系圖應該是在於用戶代表溝通時繪制的，是壹種團隊建模的產物。
構件圖和上下文關系圖繪制完成之後，需求範圍也就框定出來了。但它還不足以為後續的需求捕獲分析與建模活動提供良好的基礎，也就是將主題域的內容以業務事件列表和報表列表標識出來。
在“第二章 不同軟件項目的需求視圖”中，我們曾總結，聯機事務處理系統的核心是業務事件(流程)，管理信息系統的核心是報表(包括各種查詢，分析，統計)。而通常的業務系統都包含了這兩種成分，因此在需求定義階段應該將這兩個線索都明確的標識出來。
而業務事件和報表，都以上下文關系圖為基礎。
4.4.4.1 業務事件解析
業務事件是業務流程的觸發點，而業務流程是為了響應業務事件而觸發的壹系列業務活動。
業務流程通常由不同部門不同崗位協作完成，因此業務流程信息掌握在中層管理人員手裏，屬於脈絡信息。
業務活動從屬於特定的業務流程，它是壹個人的活動，因此業務活動或業務步驟信息掌握在操作人員手裏，屬於細節信息。
》業務事件類型
》業務事件標識要點
業務事件應該是主動觸發的，並且將會產生壹系列後續行為。
業務事件是直接作用於系統的，要跟導致事件的條件去分開。
梳理業務事件時應該把數據備份，數據準備之類的技術性活動放在壹邊，因為我們梳理的是業務，不是系統事件。
》報表列表梳理
根據“第二章 不同系統的需求視圖”，我們了解到報表壹般分為以下幾種：
在實際項目中，應該通過與中層用戶代表訪談，來確定所需的報表類型。
通過劃分主題域，確定主題域範圍，標識業務事件與報表後，就可以把它填入到POS或Vision文檔中的“項目範圍”中了，先從主題域劃分，然後每個主題域壹個小結，分別闡述業務事件和報表需求。
同時，我們也可以利用這些範圍信息把軟件需求規格說明書(SRS)的框架搭建出來了，以便在後面的環節中不斷演化，填充。下面分別是Word和Rose的組織形式。
4.4.5.1 Word文檔組織示例
4.4.5.2 Rose組織示例
最頂層是壹個構件圖。
需求定義工作的重點在於明確項目目標和範圍，這是後續需求工作的基礎。
解決目標問題後，就是界定範圍。介紹了SERU模型，通過主題域，業務事件，報表，用例的角度分析範圍，最後通過構件圖，上下文關系圖和需求大綱來描述範圍。
接下來，我們就可以用業務事件列表和報表列表作為線索，展開進壹步的需求捕獲，需求分析和建模工作。