【文章摘要】我們之前在市場需求文檔(MRD)中闡述到的功能，都是表達的一個意向，不考慮實現方法和細節。而PRD則是將概念圖紙化，需要闡述詳細的細節和實現模型。產品人員可以通過撰寫PRD，梳理清楚方案實現過程中的各種問題和影響。
產品經理主要有兩項職責：①評估產品機會 ② 定義要開發的產品;前者我們在上篇的如何獲得產品立項文章中已經大致介紹過;而定義開發的產品則需要通過產品需求文檔(PRD)來描述產品的特征和功能。本篇主要分享下博主平常工作中是如何撰寫移動應用的PRD文檔的。
1.PRD(開發需求文檔)的作用
在學習如何撰寫PRD之前，我們先要明白寫PRD的目的是什么：
①概念化”階段進入到“圖紙化”
我們之前在市場需求文檔(MRD)中闡述到的功能，都是表達的一個意向，不考慮實現方法和細節。而PRD則是將概念圖紙化，需要闡述詳細的細節和實現模型。產品人員可以通過撰寫PRD，梳理清楚方案實現過程中的各種問題和影響。
②向項目成員傳達需求的意義和明細
PRD的主要面向對象是項目經理、開發、設計和測試。如何向這些不同的角色表達清楚需求明細，就需要一份規范的PRD文檔來描述。項目經理通過文檔可以迅速了解任務的規模和相關接口，而開發設計人員通過文檔可以了解頁面元素和用例規則，測試人員可以提前根據文檔撰寫測試用例。PRD文檔在形式上是項目啟動的必要元素之一。
③ 管理歸檔需求
大都數的新需求都需要迭代幾個版本后才能走向成熟穩定的階段，如果沒有PRD文檔，在大型項目中，需求的迭代變更將變的無據可循。PRD的文檔修訂編號和命名也是項目規范化管理的主要方法之一。
2.PRD的表現形式
一般企業內部的PRD文檔選擇wiki系統或word文檔。wiki在協同和保密方面會有優勢，而且能夠記錄修改文檔的每一次變更。而word在閱讀修改方面比較有優勢，一般使用Word加SVN的方式來管理更新文檔。這個可根據每個企業的管理規范來選擇那種方法更合適。
3.PRD的主要構成
一份基礎的PRD文檔主要由三部分組成
①引言
引言部分主要包括：需求背景、需求目的、需求概要、涉及范圍、全局規則和名詞說明，交互原型地址等。引言部分的寫作目的是讓閱讀者快速理解需求背景和概要。如果是公司內部文檔，引言部分可以從簡寫作。
②業務建模
建模的目的是為了幫助閱讀對象更好的理解需要開發的需求，常用的模型種類包括：用例圖、實體圖、狀態圖、流程圖等。常用的建模語言如UML。UML具體的建模方法請戳這里。
③ 業務模塊
業務模塊包含具體頁面的元素、用例規則，以及相關的原型，流程圖。業務模塊的描述是整個文檔最核心的部分，下面博主用案例來描述一下業務模塊的編寫方法。
4.案例介紹：旅行箱–目的地攻略(應用商店搜索“旅行箱”)
需求的目標是在APP中展示相關國家/城市的旅游資訊內容，如下圖所示：
那么我們在第一部分的引言中可以寫下簡單的需求描述：
目的地攻略以城市/國家為單位，展示八個欄目下的文章列表。
初期運營指標為編輯所有涉及城市的歸屬國家攻略內容，相關城市暫不編輯;APP前臺默認顯示國家內容卡片，城市內容卡片無數據時隱藏。
運營系統提供內容生成對應的觸屏網頁，App讀取和下載對應網頁內容;
為了幫開發者迅速了解需求結構，我們需要建一個簡單的流程圖幫助開發理解功能：
相對復雜的運營系統，我們可以補充相關用例圖和實體關系圖：
引言和建模部分是為了幫助開發和測試人員快速理解需求，具體的頁面和用例規則還需要通過第三部分的業務模塊來描述，這里我們節選案例中的文章列表頁來描述：
文章列表頁共包含一個頁面，四個用例
那我們的描述結構就為：
文章卡片頁面元素
收藏文章用例
分享文章用例
查看文章列表
查看文章(太簡單可不描述)
文章卡片的頁面元素描述：
(收藏)用例的描述為
業務模塊的描述一般是原型圖+數據元素+用例描述，這樣可以在原型圖的基礎上加上對應元素屬性的描述，并通過動作描寫的方式表達用例規則和各種流程。這樣的寫作方式不僅可以向不同對象傳達產品經理的意圖，而且可以幫助產品經理自己梳理需求的邏輯和各種異常流程。
——非原創、收集整理。
