需求文檔，產(chǎn)品經(jīng)理最終產(chǎn)出的文檔，也是產(chǎn)品設(shè)計最終的表述形式。本次分享呢，就是介紹如何寫好一份需求文檔。
1. 什么是需求文檔
a、需求文檔一般稱之為PRD，對應(yīng)的還有MRD、BRD
b、目的：主要說明做什么，為什么做，怎么做，做了后有什么效果
c、內(nèi)容：產(chǎn)品背景、需求、信息架構(gòu)、流程、原型圖、交互等
d、閱讀對象：設(shè)計、研發(fā)、測試
1.1 工具
a、Axure+標注：敏捷開發(fā)推崇的方式，輕文檔，基于原型與標注的結(jié)合，更便于施展，有瀏覽器就兼容
b、Word：傳統(tǒng)的需求文檔都是Word書寫，也挺好。因為原型與文檔分開，更容易進行版本控制，例如：原型文檔一旦改動就分版本存檔，需求文檔則截取其中改動部分，這樣保證原型能夠進行版本追蹤且完整
2. 為什么要寫需求文檔
a、內(nèi)部溝通的橋梁
-明確產(chǎn)品需求
-明確產(chǎn)品實現(xiàn)的要求和細節(jié)
-讓各個參與者明確實現(xiàn)和效果
b、存檔與記錄
-未來能夠找到當初的依據(jù)，有據(jù)可查
-項目調(diào)整等原因，便于后續(xù)交接
-后續(xù)更容易回顧做法和流程，復盤
3. 好的需求文檔有什么特點
a、結(jié)構(gòu)：邏輯清晰，層次分明，最好有目錄，Axure自帶目錄了
b、背景：背景描述清晰 ！
c、流程圖：業(yè)務(wù)流程、頁面流程都有
d、目標：考核指標、算法清楚
e、習慣：變更過程清楚
4. 怎么寫需求文檔
老方式了，先給流程，咱們一步一步拆解：
4.1 項目背景與需求分析
a、需求描述：誰提的需求，什么場景，遇到什么問題
b、簡要描述分析過程：決策過程和依據(jù)是什么（就是優(yōu)先級排序），解決方案
c、相關(guān)的背景數(shù)據(jù)資料：用戶調(diào)研和產(chǎn)品調(diào)研相關(guān)的數(shù)據(jù)和資料，或是自己產(chǎn)品內(nèi)部的數(shù)據(jù)
d、明確本次的需求：用戶、場景、需求、解決方案是什么？
4.2 本次需求的目的、功能列表
a、這個需求整體是什么樣子的，是否分階段？例如：整個網(wǎng)頁分四個階段，目前是第二階段的需求
b、本次需求做哪些，前后關(guān)系是什么？例如：本次階段的需求是否與之前的需求有關(guān)系，與之后的需求是否有關(guān)系
c、本次需求的功能清單有什么？逐一列清楚
d、涉及的頁面或功能有什么？例如我之前做考核及薪資系統(tǒng)，必然是要對接人事系統(tǒng)的數(shù)據(jù)，這就涉及人事系統(tǒng)的功能了
4.3 流程與所處的產(chǎn)品模塊關(guān)系
a、業(yè)務(wù)邏輯圖
b、業(yè)務(wù)流程圖
c、頁面流程圖
4.4 功能詳細描述
a、交互設(shè)計圖
b、原型圖
4.5 簡要的測試用例（取決于你們自己的工作流，有些團隊需要產(chǎn)品經(jīng)理負責，有些團隊有測試同學負責，但產(chǎn)品也一定要審查一次測試用例）
a、關(guān)鍵的用例
b、重點關(guān)注點
c、錯誤提示表等（表格）
4.6 考核指標
a、本次需求要統(tǒng)計哪些指標。例如：按鈕的頁面轉(zhuǎn)化率
b、怎么計算考核指標。例如：點擊轉(zhuǎn)化率=上一個頁面UV/按鈕跳轉(zhuǎn)頁面的UV
c、怎么埋點，埋點的計劃
看到這里，基本上就寫完咯。其實，看完了你應(yīng)該也發(fā)現(xiàn)了，需求文檔的內(nèi)容基本上都是前面咱們做過的事，只是在這份文檔中，把這些東西都整理了一下，然后展示了出來，只要之前每一步腳踏實地，最終的這份文檔也是小菜一碟啦。
最后，我整理了兩份需求文檔的資料，如果看完分享后得不到實踐機會，可以下載這兩份資料學習一下，獲取方式如下：
關(guān)注個人公眾號“我是饅頭”，回復：需求文檔資料即可領(lǐng)取
想要更多干貨分享就快來關(guān)注我的個人公眾號吧??！
花名：饅頭
個人公眾號：我是饅頭
座右銘：博學之，審問之，慎思之，明辨之，篤行之
