前言：
需求收集後，需要經過漫長的需求分析和所需要評估過程，才能正式在某個軟體版本中實作需求。
在軟體開發人員通過程式設計實作需求前，中間經過了多種角色的辛苦勞動，最終才會生成需要規格說明書，需求規格說明書是逐漸由粗到細的分解過程 。一個需求，要進入項目計劃中，除了範圍管理的需要，進行技術分析和細化，還需要時間管理和人力資源管理，即需要多少人，多長時間才能實作這些需求，是以，還需要進行人力資源“人月”的評估。
除了軟體故障的解決，幾乎所有的軟體開發和代碼改動活動，都是基于“需求”進行的。
第1章 需求分析全過程
1.1 需求收集
在前文我們已經探讨了需求收集的過程和防範。
1.2 需要分析與評估
（1）潛在商業價值報告FS0 -- 産品經理或需求經理
該階段的目的是：識别、請求、建議需要清單，并在投入更多精力之前，篩選掉業務潛力低的功能。
（2）技術可行性報告FS1
FS1階段，有三個主要的任務：
- 技術的可行性
技術可行性分析階段一個重要的任務就是判斷技術的可行性。并非所有的需求都需要進行可行性分析，對于簡單的使用者需要，很容易判斷技術方案是否可行，可以不需要進行技術可行性分析。
是否需要進行FS1，是由FS0階段決定的。
- 對系統中元件/子產品的影響面
技術可行性分析階段，另一個重要的任務，就是确定該客戶的需要影響面有多大，影響多少個系統的子產品。
如果是一個單一的功能需要，影響面很明顯，也可以不用進行可行性分析。
- 所需人力資源的初步評估， 即
（3）所需人力資源的初步評估E1： FS1
（4）系統需求範圍的明确
（5）系統需求規範（業務場景+功能性需求+非功能性需求+限制條件）
（6）所需人力資源的進一步評估E2
（7）初始需求清單（産品經理建議的需求類别）
（8）最終需求清單（開發團隊根據人力資源的現狀，承諾實作的需求清單）
（9）項目計劃基線（範圍基線+時間基線+人力資源基線。。。。。）
1.3 需求實作
（1）元件的軟體設計
（2）元件的編碼
（3）元件的單元測試
1.4 需求驗證
（1）元件的內建測試
（2）系統測試
第2章 需要分析與需求規範
2.1 需要分析與狀态
2.2 需要規範撰寫的階段劃分
（1）CP1：确定需要範圍和需求的切分， XXX-A, XXX-B, XXX-C.............
（2）CP2：對每個切分的子需求XXX-Y，明确功能
- 業務場景
- 功能性需求
- 非功能性需求
- 限制條件
- 與其他需求的依賴關系
- 與其他需求的互動關系
- OAM參數：配置參數、告警、計數、狀态等
（3）CP3：技術元件/子產品/領域間需要
- 元件與元件的接口
- 元件與元件之間的業務場景
- 元件的功性能需要
- 元件的非功能性需要
- 元件的限制條件
- ..................