需求文檔是每個產品經理都必備的一大技能之一，本著實用性的原則，作者總結了一版可以應用于B端的產品需求文檔模板，并經過了實踐的檢驗，分享給大家，希望對你有所幫助。

對于產品經理而言，書寫需求文檔是最為常見的工作?；ヂ摼W上有著各種各樣的需求文檔模板，每個公司的也都有著自己的需求文檔規范。

在剛做產品經理的時候，總是覺得所用的需求文檔模板不是太簡單，就是太過復雜。本著實用性的原則，我總結了一版可以應用于B端的產品需求文檔模板。

這個模板我用了好多年，也曾作為文檔規范在所在的團隊中使用，可以說是經過了實踐的檢驗。

在這里總結分享給大家，希望能夠對大家有所幫助，也歡迎大神們能夠多提寶貴建議。

一、版本記錄

新增和變更需求時，須添加一條版本記錄。

版本號：新增新的迭代的需求時需要在版本號整數位累加版本號，有需求變更時則在原版本的小數位累加版本號。通常在研發評審后，新增或修改評審過的版本的需求時，都需要走需求變更的流程。

內容提要：新增需求版本時，建議在“內容提要”中，以“XX版本：”開頭；需求變更時，則建議以“需求變更：”開頭。內容簡短說明重點即可。

二、業務介紹

1. 業務場景

此項為必需項，需要描述實際業務場景及此需求產生的用戶價值。

通常在此項會預設“業務活動者”和“業務場景及用戶價值”兩個二級標題。

有的模板會要求“業務場景”和“用戶價值”分開描述，但我的經驗是這兩者在一起描述更加順暢。在描述業務場景的過程中，用戶價值也就自然而然的一起說明了。

2. 專業詞匯

列出需要進行說明的業務專業詞匯及其含義。此項可略。

e.g. 臨床路徑變異：指患者在進入臨床路徑接受診療服務的過程中，出現偏離臨床路徑程序或診療計劃的情況。

變異率=變異人數/入徑人數。

3. 業務流程

描述需求所對應的業務流程，推薦使用泳道圖或業務流程圖。

對于十分簡單業務，此項可略。

需要上下游產品協同或研發認為需要說明，則必須進行業務流程描述。

4. 評級標準

新產品設計時，此項內容為必需。對于B端產品，能夠達到所處行業相關的評級標準，往往是客戶決定付費購買的前提條件。

拿醫療信息行業舉例，一些產品既要對標醫療信息相關的《電子病歷系統應用水平分級評價標準》、《醫院信息互聯互通標準化成熟度 》等評級標準，又要滿足等級醫院評審標準、公立醫院績效考核等醫療機構評價標準的要求。

三、需求說明

1. 功能概述

必需，簡要描述相關功能之間的使用邏輯，復雜功能可用Xmind說明。

e.g. 藥品常用方法維護：門診及住院藥品開立選擇藥品之后，自動帶入維護的常用方法。同時有多個方法時，需要用戶進行選擇?？梢栽O定全院、科室、個人級別的常用。

2. 功能詳情

必需，在此項詳細的描述產品的功能需求。以下規范性要求可供參考，可根據團隊的實際需要進行增減。

（1）需寫明是否需要提示框、二次確認框

如果需要，需寫明判斷觸發條件和提示語內容，提示語需要注明阻塞條件。

e.g.【XXXX藥品】超過一次量上限，請調整！

（2）涉及特殊的狀態變更的操作，需寫明狀態變更邏輯及不同狀態對應可執行的操作

e.g. 保存：保存完之后為草稿狀態。

發布：點擊發布之后，即變為“發布”狀態。

各狀態下操作：草稿：可以編輯、發布、刪除；發布：可以編輯、停用。

（3）原型的數據是真實內容，便于交互和研發同學理解。

（4）每個頁面需寫明是否分頁。

（5）列表功能需寫明默認排序規則。

（6）需確認是否需要導出功能。

（7）新版本需求添加至上一版本內容下方，以分割線區分，開頭注明版本號。如：

3. 界面及交互說明

必需。一般在交互評審之后，在此粘貼交互稿的鏈接即可。

4. 可用性需求

從業務視角提出的各項可用性需求。

4.1 性能需求

如對性能要特殊需求，請詳細描述，如：響應時間、最大并發數等。

4.2 監控需求

如需要特殊的監控和統計埋點需求，請詳細描述。

四、相關文檔

產品其他相關的文檔，可直接上傳至文檔中。如：業務手冊、需求調研報告、競品分析文檔等。

五、產品評審紀要

產品評審后，詳細記錄評審過程中提出的問題（包含提出人）及問題回復。

六、研發評審紀要

研發評審后，詳細記錄評審過程中提出的問題（包含提出人）及問題回復。

第五、第六點是我最近才加進來的?，F在大多數公司都采用了統一的在線文檔工具，可以比較方便存儲和共享文檔。所以也就將產品評審和研發評審的紀要，特別是關鍵問題和回復內容直接添加到了需求文檔中。方便日后回溯相關評審會的決議內容。