①概念化”階段進入到“圖紙化”

我們之前在市場需求文檔（MRD）中闡述到的功能，都是表達的一個意向，不考慮實現方法和細節(jié)。而PRD則是將概念圖紙化，需要闡述詳細的細節(jié)和實現模型。產品人員可以通過撰寫PRD，梳理清楚方案實現過程中的各種問題和影響。

②向項目成員傳達需求的意義和明細

PRD的主要面向對象是項目經理、開發(fā)、設計和測試。如何向這些不同的角色表達清楚需求明細，就需要一份規(guī)范的PRD文檔來描述。項目經理通過文檔可以迅速了解任務的規(guī)模和相關接口，而開發(fā)設計人員通過文檔可以了解頁面元素和用例規(guī)則，測試人員可以提前根據文檔撰寫測試用例。PRD文檔在形式上是項目啟動的必要元素之一。

③ 管理歸檔需求

大都數的新需求都需要迭代幾個版本后才能走向成熟穩(wěn)定的階段，如果沒有PRD文檔，在大型項目中，需求的迭代變更將變的無據可循。PRD的文檔修訂編號和命名也是項目規(guī)范化管理的主要方法之一。

PRD的表現形式

一般企業(yè)內部的PRD文檔選擇wiki系統(tǒng)或word文檔。wiki在協同和保密方面會有優(yōu)勢，而且能夠記錄修改文檔的每一次變更。而word在閱讀修改方面比較有優(yōu)勢，一般使用Word加SVN的方式來管理更新文檔。這個可根據每個企業(yè)的管理規(guī)范來選擇那種方法更合適。

PRD的主要構成

一份基礎的PRD文檔主要由三部分組成

①引言

引言部分主要包括：需求背景、需求目的、需求概要、涉及范圍、全局規(guī)則和名詞說明，交互原型地址等。引言部分的寫作目的是讓閱讀者快速理解需求背景和概要。如果是公司內部文檔，引言部分可以從簡寫作。

②業(yè)務建模

建模的目的是為了幫助閱讀對象更好的理解需要開發(fā)的需求，常用的模型種類包括：用例圖、實體圖、狀態(tài)圖、流程圖等。常用的建模語言如UML。UML具體的建模方法請戳這里。

③ 業(yè)務模塊

業(yè)務模塊包含具體頁面的元素、用例規(guī)則，以及相關的原型，流程圖。業(yè)務模塊的描述是整個文檔最核心的部分，下面博主用案例來描述一下業(yè)務模塊的編寫方法。

案例介紹：旅行箱–目的地攻略（應用商店搜索“旅行箱”）

需求的目標是在APP中展示相關國家/城市的旅游資訊內容，如下圖所示：

那么我們在第一部分的引言中可以寫下簡單的需求描述：

1. 目的地攻略以城市/國家為單位，展示八個欄目下的文章列表。
2. 初期運營指標為編輯所有涉及城市的歸屬國家攻略內容，相關城市暫不編輯；APP前臺默認顯示國家內容卡片，城市內容卡片無數據時隱藏。
3. 運營系統(tǒng)提供內容生成對應的觸屏網頁，App讀取和下載對應網頁內容；

為了幫開發(fā)者迅速了解需求結構，我們需要建一個簡單的流程圖幫助開發(fā)理解功能：

引言和建模部分是為了幫助開發(fā)和測試人員快速理解需求，具體的頁面和用例規(guī)則還需要通過第三部分的業(yè)務模塊來描述，這里我們節(jié)選案例中的文章列表頁來描述：

文章列表頁共包含一個頁面，四個用例

那我們的描述結構就為：
文章卡片頁面元素
收藏文章用例
分享文章用例
查看文章列表
查看文章（太簡單可不描述）

文章卡片的頁面元素描述：

（收藏）用例的描述為

業(yè)務模塊的描述一般是原型圖+數據元素+用例描述，這樣可以在原型圖的基礎上加上對應元素屬性的描述，并通過動作描寫的方式表達用例規(guī)則和各種流程。這樣的寫作方式不僅可以向不同對象傳達產品經理的意圖，而且可以幫助產品經理自己梳理需求的邏輯和各種異常流程。

本文所用例子app為“旅行箱”

本文為小猛投稿發(fā)布，轉載請注明出處并附帶本文鏈接