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

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

不用自宮，也能成功。

功能需求

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

概要功能需求

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

業(yè)務(wù)需求

幫助理解產(chǎn)品的業(yè)務(wù)需求和內(nèi)容

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

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

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

• 需求編號常見于大型后臺系統(tǒng)，便于查找。
• 需求分析可以描述該需求內(nèi)因，外因，kano等級，緊急程度等，便于快速了解。
• 優(yōu)先級指導(dǎo)先后順序，可用與火車頭發(fā)布模式。

我見過很多需求文檔中，優(yōu)先級設(shè)定沒有規(guī)則。我個人優(yōu)先級順序原則是:

1. 產(chǎn)品可用性的需求
2. 產(chǎn)品用戶體驗性需求
3. 產(chǎn)品擴展性需求
4. 產(chǎn)品生態(tài)需求

產(chǎn)品結(jié)構(gòu)圖

幫助了解產(chǎn)品功能和總體形態(tài)的概貌。

全局功能結(jié)構(gòu)：表達這個產(chǎn)品整體的功能層次和邏輯關(guān)系，通常用腦圖來表達。

頁面結(jié)構(gòu)圖：以頁面為基準，描述產(chǎn)品各頁面的層次結(jié)構(gòu)，常用于移動端產(chǎn)品，可用結(jié)構(gòu)圖表達。

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

業(yè)務(wù)流程

幫助理解產(chǎn)品的業(yè)務(wù)關(guān)系和流程。

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

示例來源于網(wǎng)絡(luò)

整體流程圖：用于描述某個整體任務(wù)時，各模塊之間的配合關(guān)系，常見于后臺系統(tǒng)。

示例來源于網(wǎng)絡(luò)

全局數(shù)據(jù)流：用于描述紀錄或表單等信息的流轉(zhuǎn)關(guān)系或?qū)哟谓Y(jié)構(gòu)，常用于后臺系統(tǒng)。

示例來源于網(wǎng)絡(luò)

根據(jù)產(chǎn)品類型，選擇需要的表達模型去構(gòu)建PRD。

詳細功能需求

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

對于詳細功能，我把它分為兩種類型，一種是業(yè)務(wù)功能，一種是報表功能。根據(jù)不同的類型，結(jié)構(gòu)有所不同。

業(yè)務(wù)功能

功能名稱

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

概述：

包含功能的一般性描述，包含以下幾點內(nèi)容

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

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

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

業(yè)務(wù)流程

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

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

• 擴展事件流：備選，可選事件流。如：1、可通過點擊｛導(dǎo)出｝，進入導(dǎo)出流程。
• 異常事件流：異常情況下事件流。如：空狀態(tài)下，服務(wù)異常時的事件流。
• 后置條件：在結(jié)束后，系統(tǒng)可檢測的有意義的條件。如：1、保存后，界面數(shù)據(jù)更新。

相關(guān)功能

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

界面原型

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

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

業(yè)務(wù)規(guī)則

針對此功能或某個數(shù)據(jù)相的業(yè)務(wù)規(guī)則描述，如果在業(yè)務(wù)流程中描述過，不需要重復(fù)描述。

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

設(shè)計約束

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

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

驗收標準

描述產(chǎn)品驗收時要滿足的內(nèi)容，是測試人員重點關(guān)注事項。

原則上優(yōu)先保證正常流下的業(yè)務(wù)結(jié)果正確，異常邊界不報錯，提示明確即可。

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

報表功能

功能名稱

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

概述

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

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

報表內(nèi)容

詳細描述報表各項數(shù)據(jù)的來源和計算規(guī)則。

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

界面原型

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

報表框架

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

設(shè)計約束、驗收標準

與業(yè)務(wù)功能相同，這里不再重復(fù)說明。

數(shù)據(jù)字典

列出有關(guān)功能的數(shù)據(jù)元素，或信息結(jié)構(gòu)。若原型部分已經(jīng)描述過，可以省略。

【未完待續(xù)】

相關(guān)閱讀

PRD修煉真經(jīng)?卷一：一份標準化產(chǎn)品需求文檔的邏輯思路

PRD修煉真經(jīng)?卷二：一份標準化產(chǎn)品需求文檔的邏輯思路

PRD修煉真經(jīng)?卷三：一份標準化產(chǎn)品需求文檔的邏輯思路

作者：小星星，8年互聯(lián)網(wǎng)工作經(jīng)驗，5年技術(shù)，3年產(chǎn)品。

本文由 @小星星 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于 CC0 協(xié)議