需求文檔（PRD）主要作用是
1、向成員表達清楚產品的功能和性能。
2、交互設計師要參考prd來設計高保真原型，開發要參照prd來寫程序，測試也要參考prd
3、Prd沒有統一的模板，取決于公司標準、個人喜好和團隊要求，能夠讓團隊其他成員快速了解你要表達的內容的prd就是好的prd。
什么時候寫需求文檔：
列出功能結構圖、信息結構圖、功能點流程圖、頁面流程圖、產品結構圖、畫出線框圖原型，然后寫需求文檔，
寫完需求文檔后，再交給交互設計，同時讓他來優化你做出的流程圖、產品結構圖、線框圖原型圖——交互設計師做出帶有交互設計說明的高保正線框圖，產品結構圖，頁面流程圖后交給ui設計師，制作高保真原型圖并切圖標注。——開發人員參照需求文檔，帶著高保真設計圖，和其他各種圖開發。
有些公司沒有交互設計。是產品經理兼任
需求文檔相關內容
文件命名方式
1、產品名-PRD-版本號。例如，微信-PRD-1.0.0
2、微小的改動要增加版本號小數末位。微信-PRD-1.0.1
3、較小的改動要增加版本號小數點首位。微信-PRD-1.1.1
4、下個版本要增加首位。微信-PRD-2.0.0
遞交給別人的改動版本號，每個版本最好保存原稿，不要直接去改。
修訂記錄
讓他人快速知道自己所看的版本和之前都有哪些不同。用表格形式表達。
項目概述
對當前版本，項目開發時的背景，主要開發的產品功能，我們希望借此版本達到的目標，項目團隊成員做出介紹，讓團隊內其他成員能夠對項目快速了解。（個人體會：小公司不用寫這個。直接原型圖交給交互，加上功能表和時間表就好。）
滿足需要描述
說明什么用戶會在什么場景下使用我們此版本中開發的功能，滿足什么樣的需要，讓團隊成員清楚本版本對用戶的價值。
功能列表
功能點列在一個表格之中，編號并標出優先級，可以讓團隊成員快速了解本版本要實現的功能點具體都有哪些（不管什么情況，直接顯示內容的功能點可以不寫，原型圖展示）
業務流程圖。適合邏輯關系復雜的。
信息結構圖。輔助技術人員做接口
名詞解釋。比如，什么是游客（沒有注冊賬戶的用戶）
需求描述
用例圖。如果有多種用戶類型，不同用戶類型在產品中有不同的權限，使用不同的功能，從不同類型的用戶的角度來說能使用產品中的那些功能點，或者說能夠做哪些事情。一般如果一個產品的用戶只有單純的一種身份，這個用例圖就可以不用畫。
如何描述功能點。
1、按照功能主次順序來說。前置條件這種大家都明白的話不用寫。
2、從用戶使用流程的角度來描述。比如，微信的錄音方式，按住說話，松開就是發送。不寫清楚可能會點擊開始錄音，點擊發送才是發送語音。
流程包括三點：基本流程、備選流程、異常流程。
3、邏輯描述方式。跟第一點差不多，不同的是見圖。
4、把握功能點的顆粒度。不能太大不能太小。比如發送消息給朋友，這樣就太大，正確的說法是：發送文本消息、發送圖片消息、發送語音消息。如果說輸入消息文本、確認發送文本，這個顆粒度就太小了。
5、非功能需求也要寫進去。可靠性需要、接口需要、性能需要、安全需要、運行環境需要、易用性需要、可維護性需要、接口需要、數據統計需要、運營推廣需要等。
需求文檔寫完了，要開會，評審、修改、再開會、評審、修改.....直到你的需求文檔大家都比較滿意了之后。開始交給設計師和技術人員開始開發。最好進入公司要來以前的需求文檔，看他們怎么寫的，然后寫出最適合開發團隊的。
如何制作基于原型圖的需求文檔。附圖。（創業公司更偏好這種需求文檔，直接寫在原型圖里）
