專案啟動
啟動會議的主要目的是為接下來需求發現工作奠定基礎，並確保專案成功需要的所有東西都已經到位
確定業務問題的範圍---》確定利益相關者----》確定專案的目標---》成本初步評估（早一些理解風險與成本）---》小組成員是否值得進行和是否可行達成一致意見
網羅需求
啟動會議結束後，需求分析師開始在工作中網羅，學習和理解它的功能性，即「這部分業務是做什麼的」。為了獲得方便性和一致性，他們將工作上下圖劃分為一些業務用例。
每個業務用例都是一部分功能，這是工作正確響應乙個業務事件所必需的。每個業務事件都指派一名需求分析師，分析師採用一些技巧，如做學徒、場景分析或用例研討會等來發現工作的真正本質。
在理解了工作實質後，分析師和關鍵利益相關者一起工作，決定改進工作的最佳產品。也就是說，確定多少工作需要自動化或改變，以及這些決定會對工作產生什麼影響。當分析師知道了產品的範圍，就為它編寫需求。
總結：啟動會議確定了待改進的工作範圍。業務用例可以通過這個範圍匯出。每個業務用例都由需求分析師和相關利益相關者進行研究，以發現期望的工作方式。在理解了這些之後，就可以以確定適合的產品（puc場景），並寫下需求或使用者故事。
快而不完美的建模
白板上隨手畫出的原型，對可能實現的需求提供 了快速的視覺解釋，並澄清一些誤解或遺漏的需求
編寫需求
系統開發的乙個主要問題就是需求被誤解。為了避免誤解，分析師必須以一種無二義的，可測試的方式寫下需求，同時確保提出需求的利益相關者理解並同意寫下需求，然後再傳遞給開發者。
需求規格說明模板/需求項框架
想編寫需求，主要不是為了得到書面的需求（雖然這常常是需求的），而是去「寫」需求。寫需求這個活動，以及與之相關的理由和驗收標準，澄清了編寫者對需求的看法，用無二義的，可驗證的方式確定下來。換句話說，如果分析師不能正確地編寫需求，他就沒有理解需求。
質量關在每項需求傳遞給開發者之前，質量關測試每項需求的完整性、正確性、可度量性、無二義性和其他的一些屬性，確保它是嚴格的。
復用需求
複查需求
複查工作確保規格說明書是完整的，恰當的，這樣可以轉向下乙個階段。
複查也為重新評估產品的費用和風險提供了乙個機會。既然擁有了乙個完整的需求集，對產品的了解就比啟動會議要更多。
迭代和增量過程
需求反思
我們做對了什麼？
我們做錯了什麼？
如果我們必須重新做一次，在哪些地方會做得不同？
需求演進
需求隨著產品開發過程而演進。它們開始是相當模糊的想法，分析師和利益相關者會探索工作領域。隨著時間的推移，關於產品的想法出現了，需求就變得精確、可測試。它們一直是與技術無關的，直到設計者加入進來，增加了一些技術需求，使產品能夠在它的技術環境中工作。
模板專案驅動
專案的目標
客戶、顧客和其他的利益相關者
產品的使用者
專案限制條件
需求限制條件
命名標準和定義
相關事實和假定
功能需求
工作的範圍
產品的範圍
功能與資料需求
非功能需求
觀感需求
易用性和人性化需求
執行需求
操作和環境需求
可維護性和支援需求
安全性需求
文化與政策需求
法律需求
專案問題
開放式問題
立即可用的解決方案
新問題任務
遷移到新產品
風險費用
使用者文件
後續版本需求
解決方案的想法
白雪卡需求項框架或白雪卡，有需求的各種屬性，用於最初的需求收集工作。每個屬性都對需求的理解和可測試性有一定貢獻。
第二章 需求分析
1 了解需求分析概念及需求獲取方法 2 了解需求建模方面 3 結構化分析案例 購銷系統 1.1 需求分析的概念和意義 需求是至使用者對軟體的功能和效能的要求 就是使用者希望軟體能做是麼事情，完成什麼樣的功能，達到什麼效能。需求分析是在計算機系統的軟體功能分配和軟體設計之間重要的橋梁作用的一項軟體工程...
第二章 使用者需求分析
第二章 使用者需求分析 1.需求分析基本方法 1 怎樣獲取使用者需求？a 網路工程面向的是特定行業或特定使用者 如金融行業 使用者提交業務需求書是重要的資訊 b 如果系統整合商與使用者建立長期的合作關係，則在合作過程中可以培養使用者提出需求和表達需求的能力，或者聯合成立需求小組，共同開發需求 c 網...
掌握過程需求
今日閱讀了 掌握需求過程 這本書，書中從基本事實 需求過程 確定業務問題的範圍 業務用例 工作調研 場景 理解真正的問題 開始解決方案 今日業務分析策略，功能需求 非功能需求 驗收標準和理由 質量關 需求與迭代開發 復用需求 溝通需求 需求完整性十七個方面對於需求過程進行詳細講解。目前讀到第四章，先...