最近比較忙，水逆沒有動力更新，接上一篇《PRD修煉真經?卷一》。

特別聲明：此文目的是解構標準化PRD中各章節的邏輯，并不是PRD的模版。

不用自宮，也能成功。

功能需求

功能需求是PRD核心內容，前面說引言是幫助理解文檔本身，概述幫助理解項目和產品本身，那么功能需求部分就是幫助理解業務和功能。下面對功能需求的各部分內容進行詳細說明。

概要功能需求

概要功能需求是用于描述提供給用戶的產品特性和功能。通常使用框圖、表、文字結合的方式說明，便于快速理解。

業務需求

幫助理解產品的業務需求和內容

產品描述：總整體上解釋和描述產品定位，產品目標。如，該產品是一款專注于xxx的平臺，A業務解決用戶xxx的問題，B業務解決運營xxx的問題。

個人認為，PRD中業務需求粒度不宜過細，畢竟PRD是偏向于可量化指標，以指導設計為主。但有的時候，產品MRD、PRD會合并成同一個文檔。這種情況下，可以在產品描述中，展開MRD相關內容，如市場分析，用戶分析，競品分析，可行性結論等。

概要功能列表：列出文檔涉及的功能列表清單

• 需求編號常見于大型后臺系統，便于查找。
• 需求分析可以描述該需求內因，外因，kano等級，緊急程度等，便于快速了解。
• 優先級指導先后順序，可用與火車頭發布模式。

我見過很多需求文檔中，優先級設定沒有規則。我個人優先級順序原則是:

1. 產品可用性的需求
2. 產品用戶體驗性需求
3. 產品擴展性需求
4. 產品生態需求

產品結構圖

幫助了解產品功能和總體形態的概貌。

全局功能結構：表達這個產品整體的功能層次和邏輯關系，通常用腦圖來表達。

頁面結構圖：以頁面為基準，描述產品各頁面的層次結構，常用于移動端產品，可用結構圖表達。

利用墨刀等原型工具，可以通過創建頁面工作流快速完成。

業務流程

幫助理解產品的業務關系和流程。

產品用例圖：以不同的用戶或角色為基點，通過用例，表達用戶會使用的功能邊界，常見于后臺系統。

示例來源于網絡

整體流程圖：用于描述某個整體任務時，各模塊之間的配合關系，常見于后臺系統。

示例來源于網絡

全局數據流：用于描述紀錄或表單等信息的流轉關系或層次結構，常用于后臺系統。

示例來源于網絡

根據產品類型，選擇需要的表達模型去構建PRD。

詳細功能需求

這部分大家應該都不陌生，是PRD核心中的核心，用于描述功能的量化指標，是研發部門關注的重點。

對于詳細功能，我把它分為兩種類型，一種是業務功能，一種是報表功能。根據不同的類型，結構有所不同。

業務功能

功能名稱

一般直接使用功能名稱作為標題項，便于生成目錄和在文檔結構圖中快速定位。一個story一個小節

概述：

包含功能的一般性描述，包含以下幾點內容

需求描述：推薦一個一句話描述需求的模版給大家“xxx（角色）在xxx的情況下，通過xxx的方式，達到xxx的目的”。

業務場景：描述用戶的使用場景，可以用擬人化的語言去表達，如：“小王到達A寫字樓后，停車場管理員告知車位已滿，小王掃掃描車位二維碼，尋找附近的空閑停車場?！?/p>

參與者：表述此功能具體使用人有哪些，如某功能是管理員使用還是員工使用。

業務流程

詳細描述次業務涉及的主要事件流程，可通過流程圖輔助說明

• 前置條件：在開始前，系統可檢測的有意義的條件。如：意見反饋查詢功能中，用戶已提交意見反饋
• 觸發事件：觸發次系統功能的事件。如：用戶點擊、收到通知
• 基本事件流：常規，正常情況下的預期事件流。如：1、點擊xxx進入頁面，2、輸入xxx，3、選擇xxx，4、點擊確定保存xxx?？梢酝ㄟ^流程圖輔助說明。

• 擴展事件流：備選，可選事件流。如：1、可通過點擊｛導出｝，進入導出流程。
• 異常事件流：異常情況下事件流。如：空狀態下，服務異常時的事件流。
• 后置條件：在結束后，系統可檢測的有意義的條件。如：1、保存后，界面數據更新。

相關功能

與本功能相關，但較復雜，難以一起表達時，拆分到細分場景后所關聯的功能?？梢悦枋龀鏊鼈冎苯拥妮斎胼敵鲫P系。

界面原型

原型截圖或者鏈接至原型文檔。

另外，有必要時，需要說明界面中數據項的詳細描述

業務規則

針對此功能或某個數據相的業務規則描述，如果在業務流程中描述過，不需要重復描述。

例如：錢包余額不足時，可轉為刷銀行卡支付。

設計約束

描述需要設計、開發特別注意的事項。如：沒有說明的抽象框架設計；可兼容某些特性；不可用狀態時的顯示要求。

如果是公共性的約束，可以通過全局說明，來闡述通用約束。如：對話框樣式，加載樣式等

驗收標準

描述產品驗收時要滿足的內容，是測試人員重點關注事項。

原則上優先保證正常流下的業務結果正確，異常邊界不報錯，提示明確即可。

如：能夠注冊成功，失敗原因提示正確。

報表功能

功能名稱

一般直接使用報表名稱作為標題項，便于生成目錄和在文檔結構圖中快速定位。如：某某報表，編寫時一個報表一個小節。

概述

因報表一般情況下的用戶是管理者，因此報表類功能概述主要便于理解業務場景和管理者意圖和目的

• 目的：管理者因為什么需要查看此報表
• 使用部門／職位：用于理解使用者的職責，包括地理級別，如：xx財務經理崗位，省級/市級。
• 相關場景與評率：大概多久查一次，緯度有多大。

報表內容

詳細描述報表各項數據的來源和計算規則。

• 數據來源：該數據項的基于哪些數據生成。如：消費金額統計，來源于xx訂單紀錄
• 計算規則：該數據的統計公式。如：消費金額統計，xx訂單中“實收”的累加總額。

界面原型

報表展示原型。個人建議報表原型最好模擬一些真實數據和用戶確認最終效果。

報表框架

描述報表模塊的通用框架需求，如：打印，打印預覽，導出，總計，排序，默認緯度，篩選條件，分頁，是否支持動態報表模版等

設計約束、驗收標準

與業務功能相同，這里不再重復說明。

數據字典

列出有關功能的數據元素，或信息結構。若原型部分已經描述過，可以省略。

【未完待續】

相關閱讀

PRD修煉真經?卷一：一份標準化產品需求文檔的邏輯思路

PRD修煉真經?卷二：一份標準化產品需求文檔的邏輯思路

PRD修煉真經?卷三：一份標準化產品需求文檔的邏輯思路

作者：小星星，8年互聯網工作經驗，5年技術，3年產品。

本文由 @小星星 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議