什么是產品需求文檔 prd文檔是什么格式 _經驗分享

PD/MRD/PRD文檔區別
PD是BP通過后的進一步細化。產品定義文檔用來明確要做什么產品，使得公司內部所有與業務相關的部門（高層領導、研發、銷售、支持等部門）都能基本清楚我們到底要做什么產品，從而統一大家的思想和行動。PD的主要內容包括：
產品名稱
該產品的遠景目標（vision）
目標市場和客戶的描述
競爭對手分析
對產品主要功能的比較詳細的描述
這些功能的優先級
初步擬定的實現進度安排
用例，這可以是較粗略的大致描述。
產品的軟硬件需求
產品的性能要求
銷售方式上的思路、需求（直銷還是渠道？直銷怎么做？渠道怎么做？）
技術支持方式上的思路、需求（提供什么樣的技術服務？）
該文檔是產品項目由“準備”階段進入到“實施”階段的第一文檔，其作用就是“對產品進行市場層面的說明”，解決“為什么做”的問題，用來闡述產品為什么是賺錢的。大綱如下：
用戶的問題，我們的機會；
目標市場的特征和趨勢；
目標用戶的特征和購買動機；
最終使用者的特征和需求；
市場需求：功能要求、兼容性、性能、語言要求、外觀、文檔、發布、支持和培訓等要求。
PRD是針對MRD中的產品功能做進一步詳細說明，解決“怎么做”的問題。產品需求文檔一般用word+visio，或者Axure軟件來寫。文檔是寫給交互設計人員和開發人員看的，因此既需要界面流程原型，也需要詳細的功能說明、業務規則、數據要求。大綱如下：
功能名稱：
功能說明：功能清單及優先級、功能目的、詳細說明
最終用戶描述
業務流程：需要詳細的用例（use cases）
業務規則
界面原型：設計框架圖
數據要求：數據的輸入、輸出、參數范圍
其他：交互建議、性能需求、環境需求，備選方案等
產品經理文檔之PRD
PRD：產品需求文檔，全稱是Product Requirement Document，是產品文檔中最底層最細致的文檔。文檔側重對產品功能和性能的說明，主要是把產品規劃與設計中的產品流程，界面，功能等定義向研發、設計、測試等團隊做清晰的描述說明。
1、幫助團隊存檔產品信息
產品實現過程中，有很多的邏輯、算法需求，沒有文檔的記錄，容易在團隊變更、交接班的時候出現較大風險。通過產品需求文檔記錄產品的各種需求與實現方式，能有效降低團隊的風險，同時也能提高交接效率。
2、提升內部信息溝通的效率
雖然需求可以口述，但是不代表說一次全員就都能記得，會遇到開發、設計或測試記不清楚的地方，可以直接查看文檔。結構明確、表達清晰的文檔仍然有不可取代的作用。
3、產品工作有據可查
各方需求理解不一致，或延期產品工作的時候，通過產品需求文檔都可以有效的找到問題根源。
研發人員：由于研發人員本身專注于功能的實現與性能，所以他們相對于其他崗位比如運營，時長，設計等，表現相對不太關系，對于產品更多地了解來自于產品經理的產品宣講。
設計人員：設計人員本身更多的會關注產品的表現形式與原型，所以對PRD的需求是相對較弱的。
還有老板、項目經理、運營、市場、客戶、財務……
所以，PRD文檔，根據閱讀對象，可以用最平鋪直敘的話，把產品描述清楚就行。
文字模式：Word 。時間較為充裕的或崗位責任制分明，有文檔要求規范的團隊，建議選擇Word撰寫文檔。
原型圖模式：Axure 。追求時間效率靈活性的團隊，建議選擇Axure撰寫文檔，原型搭配產品說明，無需切換，只用一個文件就可，方便快捷。
無論哪種方式，都是大同小異，本質上并不影響PRD文檔的使用效果。
1、修訂記錄：版本號、修訂日期、修訂章節、修訂內容、修訂人等。
版本號說明，以1.25舉例：
版本號（ 1 .25）：重大調整升級，一般是產品結構功能等有調度。
子版本號（1. 2 5）：在原有基礎上對局部功能進行了升級或調整。
修正版本號（1.2 5 ）：局部小范圍優化與Bug修復，一般是不動功能性的東西。
版本號的命名規則：
歸零原則：前一個數字增加一位，后面的數字都歸零。
修訂記錄的作用：
對修改前后進行比較
有利于維護和管理PRD
記錄修訂人和修訂日期
方便查詢，可以只看修訂部分，快速查找變更之處
2、名詞術語：將一些產品里面不易理解，容易混淆，或者縮寫的詞匯在開篇進行統一的列表說明，有利于閱讀。
全局說明包括：權限說明、授權說明、異常情況、鍵盤說明等。
權限說明：對角色權限進行劃分，例如登錄和未登錄狀態下可訪問的功能權限。
授權說明：手機號授權、地理位置授權、相冊授權等。
異常情況：加載失敗、網絡異常等。
鍵盤說明：數字鍵盤、字母鍵盤。
......
1、產品結構：包括產品功能結構圖、信息結構圖。
【什么是產品需求文檔 prd文檔是什么格式】 2、業務流程圖：通過用戶行為串聯信息結構和產品結構，可以更好的理解產品經理設計的用戶行為。
3、功能清單：清單包括功能模塊、功能點、功能描述等。
4、功能詳情：原型設計、功能說明和用例。
功能詳情的表述順序可以按照功能的邏輯來表述，或按照產品結構來表述，具體可以看個人習慣和團隊要求。
用例：用例圖和用例說明。用例圖表述的是系統的外部參與者與系統之間的關系，是由參與者與用例組成的示意圖。
注意：
撰寫前要保證思考到位，產品結構本身短期內不會有重大改動。這樣即便是在交付后，出現調整或需要優化的地方，也不會出現重構的情況。
文檔中用詞用語一致，對于同一事物的表述應該一樣，避免混用。
非功能性需求是對產品非功能性需求的說明，包括性能需求、技術組件需求、安全性需求、可用性需求、質量需求等。
性能需求：系統滿足多用戶同時工作，保障同時在線用戶五千人，并發操作一千人的使用需求。
技術組件需求：數據存儲及計算使用星環大數據平臺等。
安全性需求：涉及外網環境的需保證數據網絡架構上保證數據的傳輸安全、具備良好的跨平臺部署能力等。
可用性需求：系統支持IE11并向下兼容，支持Chrome等主流瀏覽器。
質量需求 ......
上面的文檔結構只是PRD的基本結構，并沒有成為固定的可以供套用的東西，文章只是一種思路的分享，具體還是要根據自己公司及團隊的習慣和達到你的目的為依據來進行調整，切勿生搬硬套。
閱讀原文
對產品經理感興趣的朋友，可以移步“ 行業與市場分析 ”，期待共同交流。
原型prd文檔是一款軟件嗎?
prd是指產品需求文檔，全稱Product Requirement Document，類似于項目經理PM，用戶界面UI，研發RD 測試QA，目前最適合的PRD寫法就是用Axure
完整的PRD文檔包含哪些內容?
完整的PRD文檔包含的內容如下：
1、文檔概述：文檔狀態、文檔修訂記錄、名詞解釋。
2、產品概述：需求背景和需求目的、需求和功能拆分清單、產品架構圖和重要流程圖、原型交互。
3、需求詳細描述：拆分各個模塊詳細描述需求功能點，包括正常流程和異常流程。
4、非功能性需求：比如數據埋點需求和運營需求等。
PRD的主要使用對象
研發、測試、交互設計師及其他業務人員。
研發可以根據PRD獲知整個產品的邏輯，作為編碼的依據；測試可以根據PRD編寫測試用例，為正式測試做準備；交互設計師可以根據PRD設計交互細節；業務人員可以通過PRD提前了解產品，為運營和推廣做準備。

如何撰寫PRD文檔
首先，先了解清楚PRD的閱讀對象，使用者。PRD的模版中一般有如下信息： PRD預期的讀者包括：產品、開發、測試人員及相應的負責人和用戶方代表。產品、開發、測試人員會從中了解到本次需求的背景和詳細要求，以及每個需求點未來的優化方向或對用
什么是產品需求文檔
無論做什么事都講究方式方法，寫產品需求文檔(以下稱PRD文檔)也是如此，那么什么是產品需求文檔呢？下面就來簡單的說一下。
1、該文檔是產品項目由“概念化”階段進入到“圖紙化”階段的最主要的一個文檔。當然，這個定義針對的是一個全新的產品。廣義上來講，產品需求的描述，應該包含有產品的戰略和戰術，戰略是指：產品定位、目標市場、目標用戶、競爭對手等。戰術是指產品的結構、核心業務流程、具體用例描述、功能&內容描述等。
2、 PRD的主要使用對象有：開發、測試、項目經理、交互設計師、運營及其他業務人員。開發可以根據PRD獲知整個產品的邏輯；測試可以根據PRD建用例；項目經理可以根據PRD拆分工作包，并分配開發人員；交互設計師可以通過PRD來設計交互細節。PRD是項目啟動之前，必須要通過評審確定的最重要文檔。
以上就是關于什么是產品需求文檔的全部內容。
關于prd文檔是什么和prd文檔是什么格式的內容就分享到這兒！更多實用知識經驗，盡在 m.apearl.cn