商業需求文檔
Business Requirement Document
BRD和MRD，PRD一起被認爲是從市場到產品需要建立的文檔規範。
是產品生命週期中最早的文檔，再早就應該是腦中的構思了，其內容涉及市場分析，銷售策略，盈利預測等，通常是供決策層們討論的演示文檔，一般比較短小精煉，沒有產品細節。是基於商業目標或價值所描述的產品需求內容文檔（報告），其核心的用途就是用於產品在投入研發之前，由企業高層作爲決策評估的重要依據。
BRD與PRD的差異
BRD不同於常見的MRD和PRD，既然是用於產品實施之前的決策評估依據，必然對其文檔（報告）的內容和格式要求夠直觀、精煉，要點突出。作爲報告的撰寫者，你必須讓高層明白，你的報告中將展現出怎樣的商業價值，如何用有力的論據來說服企業對你這個項目的認可，併爲之慷慨的投入研發資源及市場費用。如果說PRD的好壞，直接決定了項目的質量水平，那麼BRD的作用，就是決定了你的項目的商業價值。優秀的BRD文檔，可以讓決策層充分被你的報告觀點所吸引，或許財務主管會因爲報告呈現的低投入高產出的經濟效益預測而蠢蠢欲動；或許技術主管會因爲項目的牽涉面廣泛而頭疼不已；又或許公司的VP之流因之報告而看到了未來一年業績的飛速發展的廣闊前景……
說白了，BRD需要產品經理（產品設計師）像對待PRD一樣，充分應用市場調查、用戶研究、需求分析等各種設計手段來充分闡述報告的內容。基於這樣的狀況，顯然不是給大家一份完整的BRD標準格式規範，就能夠搞定一切的！哈，也許有人會說這有點危言聳聽，不過我一向贊成，面對一切“產品”，都應該用設計的眼光看待它。
首先，你應該把決策層當作你的產品——BRD的受衆羣體，一切從這裏開始……
市場需求文檔
Market Requirement Document
該文檔在產品項目過程中屬於“過程性”文檔。
1文檔作用
該文檔是產品項目由“準備”階段進入到“實施”階段的第一文檔，其作用就是“對年度產品中規劃的某個產品進行市場層面的說明”，這個文檔的質量好壞直接影響到產品項目的開展，並直接影響到公司產品戰略意圖的實現。
2文檔意義
該文檔在產品項目中是一個“承上啓下”的作用，“向上”是對不斷積累的市場數據的一種整合和記錄，“向下”是對後續工作的方向說明和工作指導。
3文檔撰寫
撰寫MRD，大致下幾個方面（按先後順序）着手：
1、項目背景；
2、名詞解釋；
3、可行性分析（前期調研信息和數據+項目預期目標）；
4、綜合描述（功能概述+對其他產品的影響）；
5、功能詳述（功能需求+功能點）；
6、其他問題描述。
4文檔核心
該文檔中，側重的是對產品所在市場、客戶（client）、購買者（buyer）、用戶（user）以及市場需求進行定義，並通過原型的形式加以形象化
5錯誤認識
1）根本沒有MRD的思想，許多企業把產品經理歸爲技術端，因此，在現實中，許多產品經理的產品文檔只是側重於功能描述，而對基礎性的市場缺乏足夠認識和記錄；
2）把MRD和PRD混爲一談，MRD是PRD的基礎，PRD是MRD在產品功能上的具體化。
3）照搬國外的MRD模板，來源於何處，不知道，將去向何處，也不知道，無頭無尾，一個被割裂的文檔。
產品需求文檔
產品需求文檔(Product Requirement Document，PRD)的英文簡稱。
是將商業需求文檔（BRD）和市場需求文檔（MRD）用更加專業的語言進行描述。
文檔意義
該文檔在產品項目中是一個“承上啓下”的作用，“向上”是對MRD內容的繼承和發展，“向下”是要把MRD中的內容技術化，向研發部門說明產品的功能和性能指標。
文檔撰寫
在該文檔中，基點依然是MRD中的內容，只是把重心放在了“產品需求”上，而產品需求本身是在MRD中有所體現的，區別就是在於，PRD要把MRD中的“產品需求”的內容獨立出來加以詳細的說明。
這部分是PRD寫得最多的內容，也就是傳統意義上的需求分析，我們這裏主要指UC（use case）文檔。主要內容有，功能使用的具體描述（每個UC一般有用例簡述、行爲者、前置條件、後置條件、UI描述、流程/子流程/分支流程等幾大塊），Visio做的功能點業務流程，界面的說明，demo等。Demo方面，可能用dreamweaver、ps甚至畫圖板簡單畫一下，有時候也會有UI/UE支持，出高保真的demo，開發將來可以直接用的那種。
文檔核心：
該文檔中，側重的是對產品產品功能和性能（即“產品需求”）的說明，相對於MRD中的同樣內容，要更加詳細，並進行量化。
在一些國外的公司，是允許把MRD和PRD合併成一個文檔的，通常叫做“Marketing & Product Requirements Document”。
該文檔一般可以包括以下內容：
該產品的遠景目標（vision）
目標市場和客戶（target market and customers）的描述
競爭對手分析（competitive summary）
對產品主要feature的比較詳細的描述
這些feature的優先級
初步擬定的實現進度安排。
用例（use cases），這可以是較粗略的大致描述，未必一定要UML Use Case圖。
產品的軟硬件需求
產品的性能要求
銷售方式上的思路、需求（直銷還是渠道？直銷怎麼做？渠道怎麼做？）
技術支持方式上的思路、需求（提供什麼樣的技術服務？）
開發工具推薦 ：
Rational Rose★★★★－－熟悉項目發生的相關業務行爲。
visio 2007★★★★－－將業務，從產品層面肢解開來，做到抽絲剝繭部分與整體統一
mind manager★★★－－把項目條目化，條理化，目錄結構具體規定好。
Axure★★★－－前臺結構佈局，合理規範的將系統脫去朦朧的華紗。
Word★★★★★--穿針織網，把需求綜合起來，整理成最終的產品需求文檔。
錯誤認識
1）PRD無原始數據（MRD爲體現載體）支持，只是個人經驗、部門要求或者領導指示進行撰寫。
2）在PRD中，只重視“產品功能”的描述，而缺乏對產品其它指標項的說明。在一個完整的PRD中，一共需要對產品的10個產品需求項指標進行說明，分別是“功能要求、開發要求、兼容性要求、性能要求、擴展要求、產品文檔要求、產品外觀要求、產品發佈要求、產品支持和培訓要求、產品其它要求”。
3）照搬國外的PRD模板，來源於何處，不知道，將去向何處，也不知道，無頭無尾，一個被割裂的文檔。
---------------------