簡介
Product Requirement Document 產品需求文檔。
將商業需求文檔（BRD）和市場需求文檔（MRD）用更加專業的語言進行描述。
作用
如何攆寫prd該文檔在產品項目中是一個“承上啟下”的作用，“向上”是對MRD內容的繼承和發展，“向下”是要把MRD中的內容技術化，向研發部門說明產品的功能和性能指標。
撰寫
在該文檔中，基點依然是MRD中的內容，只是把重心放在了“產品需求”上，而產品需求本身實在MRD中有所體現的，區別就是在於，PRD要把MRD中的“產品需求”的內容獨立出來加以詳細的說明。
這部分是PD寫得最多的內容，也就是傳統意義上的需求分析，我們這裡主要指UC（usecase）文檔。主要內容有，功能使用的具體描述（每個UC一般有用例簡述、行為者、前置條件、後置條件、UI描述、流程/子流程/分支流程，等幾大塊），Visio做的功能點業務流程，界面的說明，demo等。Demo方面，可能用dreamweaver、ps甚至畫圖板簡單畫一下，有時候也會有UI/UE支持，出高保真的demo，開發將來可以直接用的那種。
文檔核心該文檔中，側重的是對產品產品功能和性能（即“產品需求”）的說明，相對於MRD中的同樣內容，要更加詳細，並進行量化。
在一些國外的公司，是允許把MRD和PRD合併成一個文檔的，通常叫做“Marketing&ProductRequirementsDocument”。
該文檔一般可以包括以下內容
prd製作目標市場和客戶（targetmarketandcustomers）的描述
競爭對手分析（competitivesummary）
對產品主要feature的比較詳細的描述
這些feature的優先權
初步擬定的實現進度安排
用例（usecases），這可以是較粗略的大致描述，未必一定要UMLUseCase圖。
產品的性能要求
銷售方式上的思路、需求（直銷還是渠道？直銷怎么做？渠道怎么做？）
技術支持方式上的思路、需求（提供什麼樣的技術服務？）
開發工具推薦：
RationalRose－－熟悉項目發生的相關業務行為。
visio2007－－將業務，從產品層面肢解開來，做到抽絲剝繭部分與整體統一
Mockplus——輕便好用的原型圖工具，可以和書寫PRD文檔同時進行，把需求表達得更加清楚明了。
mindmanager－－把項目條目化，條理化，目錄結構具體規定好。
axure－－前台結構布局，合理規範的將系統脫去朦朧的華紗。
Word--穿針織網，把需求綜合起來，整理成最終的產品需求文檔
錯誤認識1）PRD無原始數據（MRD為體現載體）支持，只是個人經驗、部門要求或者領導指示進行撰寫。
2）在PRD中，只重視“產品功能”的描述，而缺乏對產品其它指標項的說明。在一個完整的PRD中，一共需要對產品的10個產品需求項指標進行說明，分別是“功能要求、開發要求、兼容性要求、性能要求、擴展要求、產品文檔要求、產品外觀要求、產品發布要求、產品支持和培訓要求、產品其它要求”。
3）照搬國外的PRD模板，來源於何處，不知道，將去向何處，也不知道，無頭無尾，一個被割裂的文檔。
其他解釋
1）PesticidesRegulationDivision：（美國）農藥管理局
2）pro-ratadistribution：按比例分配
3).prd檔案擴展名
4)PearlRiverDelta:珠江三角洲
差異
prd文檔形式說白了，BRD需要產品經理（產品設計師）像對待PRD一樣，充分套用市場調查、用戶研究、需求分析等各種設計手段來充分闡述報告的內容。基於這樣的狀況，顯然不是給大家一份完整的BRD標準格式規範，就能夠搞定一切的！哈，也許有人會說這有點危言聳聽，不過我一向贊成，面對一切“產品”，都應該用設計的眼光看待它。
首先，你應該把決策層當作你的產品——BRD的客群群體，一切從這裡開始
