################################################
需求文件是收集需求過程的產出：
收集需求過程詳解鏈接：https://www.cnblogs.com/hemukg/p/12566131.html
################################################
一、需求文件背景
1. 需求文件相關負責人
相關方、高層級
2. 需求文件定義
需求文件描述各種單一需求將如何滿足與項目相關的業務需求。
發起人、客戶和其他相關方的已量化且書面記錄的需要和期望。
3. 需求文件作用
（1）需求文件識別了應納入范圍的需求。並且需求文件用於證明符合項目范圍。
（2）將需求與實際結果比較，以決定是否有必要進行變更、采取糾正措施或預防措施。
（3）需求文件用於發現任何對商定的項目或產品范圍的偏離。
4. 需求文件完成步驟/執行時間
定期更新
（1）一開始可能只有高層級的需求，然后隨着有關需求信息的增加而逐步細化。
（2）在指導與管理項目工作過程中可以識別新的需求，也可以適時更新需求的實現情況。
（3）在創建WBS過程提出並已被批准的變更的需求
5. 需求文件分類
需求文件的格式多種多樣
（1）既可以是一份按相關方和優先級分類列出全部需求的簡單文件
（2）也可以是一份包括內容提要、細節描述和附件等的詳細文件。
前者是相關方的需要，后者是指如何實現這些需要。
把需求分成不同的類別，有利於對需求進行進一步完善和細化
6. 需求與基准
只有明確的（可測量和可測試的）、可跟蹤的、完整的、相互協調的，且主要相關方願意認可的需求，才能作為基准
二、需求文件內容
1. 高層級需求/業務需求
高層級需求見《項目章程》（《項目章程》鏈接：https://www.cnblogs.com/hemukg/p/12392846.html）
整個組織的高層級需要：
（1）解決業務問題或抓住業務機會
（2）實施項目的原因
2. 相關方需求
相關方或相關方群體的需要。
根據《相關方登記冊》，登記不同相關方的期望和需求。
（《相關方登記冊》鏈接：https://www.cnblogs.com/hemukg/p/12401751.html）
3. 解決方案需求
為滿足業務需求和相關方需求，產品、服務或成果必須具備的特性、功能和特征。
解決方案需求又進一步分為功能需求和非功能需求：
（1）功能需求
功能需求描述產品應具備的功能，例如，產品應該執行的
<1> 行動
<2> 流程
<3> 數據
<4> 交互
（2）非功能需求
非功能需求是對功能需求的補充，是產品正常運行所需的環境條件或質量要。
例如，
<1> 可靠性
<2> 保密性
<3> 性能
<4> 安全性
<5> 服務水平
<6> 可支持性
<7> 保留或清除
（3）業務解決方案
相關方的需要。
（4）技術解決方案
指如何實現相關方需要。
5. 過渡和就緒需求
這些需求描述了從“當前狀態”過渡到“將來狀態”所需的臨時能力，如
（1）數據轉換
（2）培訓需求
6. 項目需求
項目需要滿足的行動、過程或其他條件，例如
（1）里程碑日期
（2）合同責任
（3）制約因素
7. 質量需求
用於確認項目可交付成果的成功完成或其他項目需求的實現的任何條件或標准，例如
（1）測試
（2）認證
（3）確認
8. 溝通需求
需求文件可能包含項目相關方對溝通的需求。
9. 資源需求
嚴格說，資源需求不算在需求文件之內，因為需求文件時在項目規划開始就需要的文件。
還沒有提及具體資源，在完成活動資源估算后才會形成。
我們在之后，單獨描述資源需求的內容。到時更新鏈接。
（1）資源類型
（2）資源數量
三、應用過程
需求文件**（4.1.1、4.3.3.6、4.7.1.3、見5.2.3.1、5.3.1.3、5.3.3.2、5.3.3、5.4.1.2、5.4.3.2、5.5.1、5.5.3、5.6.1.2、8.1.1、9.1.1、10.1.1.3 、11.2.1.2、12.1.1.4、12.1.3.9、12.2.1.2、12.2.3.4 、12.2.3.5、12.3.1.2、13.1.1.4）
1. 規划資源管理
需求文件指出了項目所需的資源的類型和數量，並可能影響管理資源的方式。
2. 規划溝通管理
需求文件可能包含項目相關方對溝通的需求。
3. 識別風險
需求文件列明了項目需求，使團隊能夠確定哪些需求存在風險。
4. 規划采購管理/實施采購/控制采購
需求文件可能包括：
（1）賣方需要滿足的技術要求
（2）具有合同和法律意義的需求
非技術要求如：
<1> 健康
<2> 安全
<3> 安保
<4> 績效
<5> 環境
<6> 保險
<7> 知識產權
<8> 同等就業機會
<9> 執照
<10> 許可證
5. 確認范圍
將需求與實際結果比較，以決定
（1）是否有必要進行變更
（2） 采取糾正措施或預防措施
6. 控制范圍
需求文件用於發現任何對商定的項目或產品范圍的偏離。
7. 結束項目和階段
需求文件用於證明符合項目范圍。
四、更新需求文件過程
1. 指導和管理項目工作
在指導和管理項目工作過程中可以識別新的需求，也可以適時更新需求的實現情況。
2. 實施采購
需求文件可能更新：
（1）賣方需要滿足的技術要求
（2）具有合同和法律意義的需求
非技術要求如：
<1> 健康
<2> 安全
<3> 安保
<4> 績效
<5> 環境
<6> 保險
<7> 知識產權
<8> 同等就業機會
<9> 執照
<10> 許可證
3. 確認范圍
記錄實際的驗收結果，更新需求文件。
需要特別注意實際結果比原定需求更好的情況，或者原定需求已經被放棄的情況。
4. 控制范圍
如果項目范圍偏離，可以通過增加或修改需求而更新需求文件。
#################################################
需求文件時項目初期就需要確定，並且需要再項目進行的過程組定期更新的。
再項目初期，我們只有項目章程中的高層級需求，需要進一步完善項目文件中所列的子項。
這里我們只提供一個《需求文件》的框架，后期項目中又完善的《需求文件》，我會更新並添加鏈接。
願各位在進步中安心
2020-03-25 禾木
#################################################
需求文件**（4.1.1、4.3.3.6、4.7.1.3、見5.2.3.1、5.3.1.3、5.3.3.2、5.3.3、5.4.1.2、5.4.3.2、5.5.1、5.5.3、5.6.1.2、8.1.1、9.1.1、10.1.1.3 、11.2.1.2、12.1.1.4、12.1.3.9、12.2.1.2、12.2.3.4 、12.2.3.5、12.3.1.2、13.1.1.4）